This would work with a raspberry pi pico? I have a switch lite lying around ready to be resurrected . If yes any diagram available? . Thanks
Hopely, will work.
By the way somebody knows a way to connect the MMC of a switch directely to a PC using a "SD Card" adapter? and using something like https://github.com/eliboa/NxNandManager to edit the Boot 0 and recover from a V2 or Lite with AutoRCM enabled?
read this post: https://gbatemp.net/threads/pikofly-a-probably-fake-hwfly-modchips-or-not.622701/post-10072054 @binkinator is our hero!This would work with a raspberry pi pico? I have a switch lite lying around ready to be resurrected . If yes any diagram available? . Thanks
You assume I know what I’m doing!read this post: https://gbatemp.net/threads/pikofly-a-probably-fake-hwfly-modchips-or-not.622701/post-10072054 @binkinator is our hero!
I assume very little and follow random instructions I find online without hesitation like a true GBATemper.You assume I know what I’m doing!
Before or after we end up with a megathread dedicated to one topic?I assume very little and follow random instructions I find online without hesitation like a true GBATemper.
Therefore your instructions are now law.
I've said this before, but this is exactly what HWFLY-NX does too.Now when I flashed the hwfly boot0 and rebooted before attempting to launch in HOS I was greated with the white led again as if this was it's first boot, this makes me believe its coded to rewrite boot0 If the data/checksum whatever doesn't match its own code.
This is actually a good thing.I've said this before, but this is exactly what HWFLY-NX does too.
At boot it verifies that the BCTs are the same of the HWFLY, if not, it re-flashes them. Afterwards it does the same for the actual payload (SD loader).
This whole BEK thing is probably happening in the payload/SD loader, which is why it's useless to try to fix boot0 from Hekate, as the boot0 gets rewritten by the firmware before Hekate boots.
From my understanding, you use this things to "clone" your emmc and replace by one more bigger.I did this for my eMMC upgrade. Based on @evil_santa ’s recommend I used one of these:
https://www.aliexpress.us/item/3256803361643934.html
View attachment 352786
It worked great for a direct copy from my original eMMC to my big one.
Have also heard good things about this one but haven’t used one myself:
https://www.tindie.com/products/ignas/emmc-reader-for-hac-emmc/
This software works for both:
https://github.com/ignasurba/mmcblkNX
Yeah, exactly. But this is the reason we won't be able to make the current half-working firmware work via Hekate shenanigans. Either somebody somehow finds the payload in the binary .uf2 file and overwrites it, or we write this thing from scratch, which will take some time.This is actually a good thing.
During a HOS firmware update boot0 gets overwritten. If the rp2040 chip doesn't check boot0 and overwrite it when it is different we will not be able to boot into hekate after a fw update.
seems that is what is being said, though that is completely unnecessary as you can just do everything through hekate, clone your nand bkp onto the larger emmc and then expand the partition. I put a 256gb in mine without anything other than the emmc board and a big microsd.From my understanding, you use this things to "clone" your emmc and replace by one more bigger.
Is that right?!
Yeah, exactly. But this is the reason we won't be able to make the current half-working firmware work via Hekate shenanigans. Either somebody somehow finds the payload in the binary .uf2 file and overwrites it, or we write this thing from scratch, which will take some time.
As long as you’re on a V1, this is correct.seems that is what is being said, though that is completely unnecessary as you can just do everything through hekate, clone your nand bkp onto the larger emmc and then expand the partition. I put a 256gb in mine without anything other than the emmc board and a big microsd.
We can find the payload that was written in the boot0 if somebody provides a boot0 dump after using the current firmware. We can look at the BCTs in the boot0 dump and find out where the payload was written. Then we'll need to look for the same payload in the .uf2 firmware.I think we could do both.
If we know what exact payload it is writing to the emmc we can start looking for it in the uf2 or bin file.
It is better to have an rp2040 which can be updated from the beginning though incase there is some logic in this closed firmware which was badly coded.
Good! Then we are all on the same page.We can find the payload that was written in the boot0 if somebody provides a boot0 dump after using the current firmware. We can look at the BCTs in the boot0 dump and find out where the payload was written. Then we'll need to look for the same payload in the .uf2 firmware.
I don't know personally, but can't Hekate dump boot0 itself? That way no eMMC removing will be needed.Good! Then we are all on the same page.
If someone here has a switch with a removable emmc who wants to dump the firmware after attaching the waveshare board let us all know!
Good! Then we are all on the same page.
If someone here has a switch with a removable emmc who wants to dump the firmware after attaching the waveshare board let us all know!
So, this only work in switch V1? In V2 that is not possible?!As long as you’re on a V1, this is correct.
V1 can boot up and act as an SD Card reader with a blank eMMC in place because you can inject a payload. Can’t do this with a Mariko. With Mariko you need a working eMMC so catch-22. This is where the cheap SDCard to eMMC reader comes in.So, this only work in switch V1? In V2 that is not possible?!