Its basically just to tell you it can boot Ubuntu..or other OS's anything that doesn't require the btc keys basicallyGuys, sorry to bother but what does the "ubuntu" stands for in the uf2 name?
Here we go, some proof it acctually works.... Just to nip this in the bud
so, i only need to isolate the pins 1 2 5 6 right?Yep the flex has mosfets on it allready, just bridge pin 3 and 4 onto the end of the flex and solder your wire to them, be careful around pin 1 2 5 6 as these are grounds.
but if i use kapton tape, don´t eliminate the risk of shorting?You will need to trim the metal heatshield the same as sx or hwfly, you may be able to squeeze it under BUT there is a big risk of shorting it out as there is a voltahe regulator on the bottom and obviously exposed points on the top
You can if you want, I didn't bother I just made sure I didn't bridge 3 or 4 of its adjacent pin.so, i only need to isolate the pins 1 2 5 6 right?
but if i use kapton tape, don´t eliminate the risk of shorting?
They aren’t all ground. One of them (2 or 5, depending from which side you count) is a sense pin, that’s used to determine console boot state. (on “hwfly”, that is)Yep the flex has mosfets on it allready, just bridge pin 3 and 4 onto the end of the flex and solder your wire to them, be careful around pin 1 2 5 6 as these are grounds.
Yep my apologies your rightThey aren’t all ground. One of them (2 or 5, depending from which side you count) is a sense pin, that’s used to determine console boot state. (on “hwfly”, that is)
do you have info on how this sense pin works?They aren’t all ground. One of them (2 or 5, depending from which side you count) is a sense pin, that’s used to determine console boot state. (on “hwfly”, that is)
Like this ?Yep the flex has mosfets on it allready, just bridge pin 3 and 4 onto the end of the flex and solder your wire to them, be careful around pin 1 2 5 6 as these are grounds.
yellow is supposed to indicate a bad D0 point. Has this console ever had an HWFLY/SX installed?well, i think i have the same issue as other it flash blue, white, and yellow and after turn off, the screen on the switch remain black
The only thing different from your setup is i'm using a Core v2 cable, will try tomorrow with a lite cable if i have one left and see
check diode readings on dat0yeh that is how i did it basically aswell.
In the same range other than clk at 515check diode readings on dat0
@TheSynthax
im getting between 400-500 on clk dat0 cmd which is inline with what i would expect to see when doing a hwfly install
I understand what your saying now about other chips.In the same range other than clk at 515
Yeah, that's what I had meant but perhaps worded it poorly. I'm thinking that this firmware isn't capable of fully preparing the eMMC by itself, which would make sense given our theory about this being a much earlier version of the firmware than the encrypted one. I wonder if it's the BCT or the SD loader or both. When you boot without an SD, is the error screen the same as HWFLY?I understand what your saying now about other chips.
this was a completely virgin firmware, i installed the rp2040 BEFORE we had the ubuntu firmware, when the original firmware wouldn't load i thought it was a good idea to check that i had installed it correctly...this is when i manually soldered up an sxcore i had lying around(flashed with hwfly) the console wouldn't train, which is when i worked out that i had messed up dat0. i fixed that, booted into Hekate then turned off and put the rp back in.
am i right in thinking you believe using the hwfly to boot has made a change to boot0 which is making my rp2040 launch...while you guys are having issues.
@Kingdedede was your install fresh..or did it have a modchip in before so we can rule this out
dont worry and im sorry for my initial reply....this does need exploring. we have 2 ways to test this now...do you have a chip that you can put it and test? if not we need someone here with a virgin system but also someone who has a chip to then test this theory...unfortunately my oled already has hwfly so thats a pointless exercise.Yeah, that's what I had meant but perhaps worded it poorly. I'm thinking that this firmware isn't capable of fully preparing the eMMC by itself, which would make sense given our theory about this being a much earlier version of the firmware than the encrypted one. I wonder if it's the BCT or the SD loader or both. When you boot without an SD, is the error screen the same as HWFLY?
Have an HWFLY on the way to see if that's the case. Do we know if running a firmware update on a stock console would wipe out all changes the chip made to the boot0 partition? That might provide a way to test that theory.dont worry and im sorry for my initial reply....this does need exploring. we have 2 ways to test this now...do you have a chip that you can put it and test? if not we need someone here with a virgin system but also someone who has a chip to then test this theory...unfortunately my oled already has hwfly so thats a pointless exercise.
and yes when you boot without an sd you get the NO SD card hekate screen.
i think its a good idea to get a list of people who have installed this(lets not worry about incorrect installs at the minute) which switch they have installed on...what is happening for them...and was the console virgin before installing.
yes it will...that's basically one of the only ways to do it i believe but someone more versed can confirm this that would be great....this lite is on 15.0 at the minute so i can only update to 16. i will do that tomorrow(getting late here) and see what happens.Have an HWFLY on the way to see if that's the case. Do we know if running a firmware update on a stock console would wipe out all changes the chip made to the boot0 partition? That might provide a way to test that theory.
No never i received it today to try thisyellow is supposed to indicate a bad D0 point. Has this console ever had an HWFLY/SX installed?