Hacking Hardware Picofly - a HWFLY switch modchip

  • Thread starter Thread starter mathew77
  • Start date Start date
  • Views Views 3,678,040
  • Replies Replies 17,052
  • Likes Likes 15
Hey there, long time no see guys. I was installing an RP 2040 tiny to a v1 patched console but for some reason I keep getting the *== No eMMC CMD1 request (poor wiring, or dead CPU).
The switch boots normally after the error shows up. I've tried 3 different flex cables, but nothing seems to change. I initially used shielded 36awg wire, but nothing seems to change. then switched to enamel wire but it all stays the same.

If this is in the FAQ sorry but I didn't see it, but what should I try next?
I've had that similiar error and turned out I had too much solder on my mosfet drain. Got any pics of your soldering on the cpu flex?
 
But that would be grounding the CLK line, not RST. That's why I believe it's not the only problem.
That's what I'm thinking. The angle of the photo makes it look like it's grounding but it isn't. I assure you that. I'll clean the flux around it and hope for the best.
 
Hey there, long time no see guys. I was installing an RP 2040 tiny to a v1 patched console but for some reason I keep getting the *== No eMMC CMD1 request (poor wiring, or dead CPU).
The switch boots normally after the error shows up. I've tried 3 different flex cables, but nothing seems to change. I initially used shielded 36awg wire, but nothing seems to change. then switched to enamel wire but it all stays the same.

If this is in the FAQ sorry but I didn't see it, but what should I try next?
I received an OLED with *==. when checking the points the clk was high, from around .890 to 1,500. Fixed the clk everything perfect
 
I've had that similiar error and turned out I had too much solder on my mosfet drain. Got any pics of your soldering on the cpu flex?
I Uninstalled it and left it without it last time, I even knocked a neighboring capacitor off the board by mistake which I have to re-attach lol. But 3 times I re-did the writing from scratch and it's just not working, so I doubt the soldering work is failing. I've done over 50 installations by now and this is the first that behaves like this to me
 
I Uninstalled it and left it without it last time, I even knocked a neighboring capacitor off the board by mistake which I have to re-attach lol. But 3 times I re-did the writing from scratch and it's just not working, so I doubt the soldering work is failing. I've done over 50 installations by now and this is the first that behaves like this to me
Have you also tried using another RP2040 board?
 
Hi!, I got someone with experience to install a picofly on switch OLED, at the time he asked me if I wanted the switch to always go directly into emuNAND on boot, I thought he meant something like AutoRCM so I said yes, thinking I could always switch it back later in a config file.

Once I got the switch back, as it turned out, what he meant was that I was never going to be able to boot into sysNAND, I asked if we could change it back so that I could jump between emuNAND and sysNAND, his response was that this "configuration" was now essentially embedded in the picofly board, which meant he would have to desolder the board and solder a new one entirely to do so. I was willing to pay again to re-do it so I could gain access to sysNAND, but he said he did not recommend doing so as re-soldering the picofly had risk of damaging the switch motherboard.

I've looked and read around but the only info I've been able to find as to why someone wouldn't be able to boot into sysNAND is if you used a different kind of resistors, he said he did used the right values, he appears experienced as he runs a shop for videogames hardware mod, which leaves me a bit stuck about going back to him.

Am I'm forever locked out of sysNAND? or would someone know if there is something I can still do to boot back into sysNAND?, Perhaps updating the picofly board firmware or with picofly toolbox?, I'd love to learn more about this picofly "permanent boot directly into emuNAND" configuration, but not sure where to look. Would really appreciate if anyone has any pointers or info to direct me on this.
 
Last edited by gst0,
Hi!, I got someone with experience to install a picofly on switch OLED, at the time he asked me if I wanted the switch to always go directly into emuNAND on boot, I thought he meant something like AutoRCM so I said yes, thinking I could always switch it back later in a config file.

Once I got the switch back, as it turned out, what he meant was that I was never going to be able to boot into sysNAND, I told him if we could change it back so that I could jump between emuNAND and sysNAND, his response was that this "configuration" was now essentially embedded in the picofly board, which meant he would have to desolder the board and solder a new one entirely to do so. I was willing to pay again to re-do it so I could gain access to sysNAND, but he said he did not recommend doing so as re-soldering the picofly had risk of damaging the switch motherboard.

I've looked and read around but the only info I've been able to find as to why someone wouldn't be able to boot into sysNAND is if you used a different kind of resistors, he said he did used the right values, he seems experienced as he runs a shop for videogames hardware mod, which leaves me a bit stuck.

Am I'm forever locked out of sysNAND? or would someone know if there is something I can still do to boot back into sysNAND?, Perhaps updating the picofly board firmware or with picofly toolbox?, I'd love to learn more about this picofly "permanent boot directly into emuNAND" configuration, but not sure where to look. Would really appreciate if anyone has any pointers or info to direct me on this.
Most likely autoboot is configured in your Hekate_ipl.ini file in your bootloader folder. I would plug it up to a PC and check that first. I've never heard of anyone programming the picofly chips with anything else other than the software to run the glitch.
 
Most likely autoboot is configured in your Hekate_ipl.ini file in your bootloader folder. I would plug it up to a PC and check that first. I've never heard of anyone programming the picofly chips with anything else other than the software to run the glitch.
Thank you :)
Autoboot is definitively off, I can log into Hekate and emummc every time without issues, its the stock sysnand that won't boot.
 
Hello,

My v2 with picofly can only boot to atmosphere emunand, if i try to boot stock from hekate, it will not pass the nintendo switch logo. Is there something i can do ? I can still boot hekate and i have an emummc in sd parition.

1- If i restore emuMMC to eMMC, then remove the chip, put back the eMMC directly on the console, i can boot !
2- But if try to put back the chip and glitch one single time, i will be unable to boot from eMMC.
3 - If i want to boot, i am forced to do step one again...

I think the chip corrupts the eMMC...
I've tried with 3 different chips, not better

Thanks à lot
 
Got an OLED picofly install that's giving me problems. Was working fine for the past week, now it won't boot up. Took it apart to check all the wiring and diode values. Everything checked out fine. Still doesn't want to boot up when I plugged it back in. Then out of curiosity I started checking for shorts. 3.3v and ground were shorted together somehow. Removed the chip, maybe some solder underneath the chip got shorted somehow. Nothing there and I didn't see anything on top of the chip that would've shorted them together. Plugged in the battery with the chip removed and it showed the Nintendo logo then battery symbol in the corner but nothing after that. Is it fried? Thanks in advance
@bvang913 , Did you figure this one out? Was it the USB-C?
 
Do you Kapton the entire back side of the tiny when doing your Installs? But good idea to remove everything and see if stock works. If not, might be a battery control ic. Possibly. Then start looking around chips for shorts. Let's see what we get.

Update on my error. Removed the rp2040 tiny dupe I had. Started into ofw fine. Flashed a real waveshare tiny. Works this time but I'm getting the check mosfet error. Things is, I have a rear mosfet install. I've gotten better with the front install on one cap and that's all I've done recently. Can I just tape off the wire coming from behind the motherboard from that mosfet or should I remove it. Looking to avoid taking out the motherboard if I don't need to
Post automatically merged:

@bvang913 , Did you figure this one out? Was it the USB-C?
Just responded to your other post. Lol
 
Update on my error. Removed the rp2040 tiny dupe I had. Started into ofw fine. Flashed a real waveshare tiny. Works this time but I'm getting the check mosfet error. Things is, I have a rear mosfet install. I've gotten better with the front install on one cap and that's all I've done recently. Can I just tape off the wire coming from behind the motherboard from that mosfet or should I remove it. Looking to avoid taking out the motherboard if I don't need to
Post automatically merged:


Just responded to your other post. Lol
If you got a stray wire connected to a mosfet on the back of the board, better to remove it. Its drawing power so last thing you want is months down the line a messy recall. When it comes to the FPC Screen connector that can break, I always douse it with IPA and the remove the ribbon cable. It slips in and out better and when putting it back in, screw in the motherboard so its lower down and secure. That way when you resit the connector and ribbon, no pins get whacked around from any upward/downward/diagonal awkward angles.
Good stuff, goes to show its better to go official with the chips than cheaper ones.
 
If you got a stray wire connected to a mosfet on the back of the board, better to remove it. Its drawing power so last thing you want is months down the line a messy recall. When it comes to the FPC Screen connector that can break, I always douse it with IPA and the remove the ribbon cable. It slips in and out better and when putting it back in, screw in the motherboard so its lower down and secure. That way when you resit the connector and ribbon, no pins get whacked around from any upward/downward/diagonal awkward angles.
Good stuff, goes to show its better to go official with the chips than cheaper ones.
Cool. Thanks for the advice. I'll get that taken care of.
 
  • Like
Reactions: Takezo-San
I've looked and read around but the only info I've been able to find as to why someone wouldn't be able to boot into sysNAND is if you used a different kind of resistors, he said he did used the right values, he appears experienced as he runs a shop for videogames hardware mod, which leaves me a bit stuck about going back to him.
I presume that he removed the sysNAND option in order to prevent users from accidentally booting into the OFW and
getting a visit by Nintendo Ninjas in the middle of the night and
customers complaining that their pirated games won't work suddenly.
There is some discussion here on how to do that so likely you can also undo that.
https://gbatemp.net/threads/any-way-to-remove-the-sys-cfw-stock-boot-hekate-icons.549219/
 
I presume that he removed the sysNAND option in order to prevent users from accidentally booting into the OFW and
getting a visit by Nintendo Ninjas in the middle of the night and
customers complaining that their pirated games won't work suddenly.
There is some discussion here on how to do that so likely you can also undo that.
https://gbatemp.net/threads/any-way-to-remove-the-sys-cfw-stock-boot-hekate-icons.549219/
Thanks for the suggestion!, unfortunately seems to be something deeper than that. I do have the sysNAND option in Hekate, I can initiate the process, but it freezes in a black screen.
I've even created and configured a complete new emunand from scratch in a new sd card and still doesn't work. What is even more odd is that not even emunand works on a new sd card, it only works the way he configured the old sd card :wacko:
 
Thanks for the suggestion!, unfortunately seems to be something deeper than that. I do have the sysNAND option in Hekate, I can initiate the process, but it freezes in a black screen.
I've even created and configured a complete new emunand from scratch in a new sd card and still doesn't work. What is even more odd is that not even emunand works on a new sd card, it only works the way he configured the old sd card :wacko:
Read the hekate documentation on the github and you will learn how to edit and modify the hekate_ipl.ini https://github.com/CTCaer/Hekate/#boot-entry-keyvalue-combinations
 
Read the hekate documentation on the github and you will learn how to edit and modify the hekate_ipl.ini https://github.com/CTCaer/Hekate/#boot-entry-keyvalue-combinations
Thank you, while I'm not familiar with everything in the documentation I did look at the ini file and thought that there was nothing particularly odd about it.
Specially since I created my own .ini file from scratch based on latest guidelines and still isn't working with the picofly in this switch.

I'll keep reading on it and trying to figure out, wanted to ask here as I wanted to double check that there really wasn't anything blocking me from entering sysNAND on the hardware level (so something I can fix on the SD card).

This is my current hekate_ipl.ini, seems like he got it from a pre-made pack somewhere, but nothing particular odd seems there to me that would prevent me from booting sysNAND
 

Attachments

  • Screen Shot 2024-08-01 at 10.56.36 PM.png
    Screen Shot 2024-08-01 at 10.56.36 PM.png
    153.1 KB · Views: 57
In the console i work in finally i finish mod nintendo switch oled after meny info from here help thank so much i was use dat2 by mistake then i grind dat0 kimkaze so long time and use magnate wier in the point conect all wier and mosfet working perfect and nice no error no more adapter fult.
 
  • Like
Reactions: QuiTim
Once I got the switch back, as it turned out, what he meant was that I was never going to be able to boot into sysNAND, I asked if we could change it back so that I could jump between emuNAND and sysNAND, his response was that this "configuration" was now essentially embedded in the picofly board, which meant he would have to desolder the board and solder a new one entirely to do so. I was willing to pay again to re-do it so I could gain access to sysNAND, but he said he did not recommend doing so as re-soldering the picofly had risk of damaging the switch motherboard.
Picofly doesn't decide whether its boot to sysNAND or emuNAND.

Picofly jobs only modify the boot sequence such that it will load payload.bin on the microsd. Thats all.

Its hekate (that usually use as the payload.bin) which responsible on booting to sysNAND or emuNAND. My guess is the hos in the emmc is corrupted, thats why it couldn't boot. Or wrong fuse count number. Or less probable scenario, wrong hekate configuration.

What is IMPORTANT for you to do first is backup your raw emmc then backup the key (prodkey, etc), its unique on your device. If you lose these key, your only option is use the shared key on the internet which is a banned one (you can't use nintendo shop, etc).

I think the safest advise i could give is try to reinstall the hekate on different microsd.
Use this https://rentry.org/SwitchHackingIsEasy as reference.

The other option like rebuild the hos, or install the atmosphere to sysnand, or update the fuse count, all have risk of breaking your system, and need further advance method to solve.

DONT try to update your picoly firmware.
It might break, and you need to take out the picofly and reupload the firmware, if it did break. Taking out the picofly is not as easy as it seems to. You might break the pad, and the solution will be like hell difficult.
 
Picofly doesn't decide whether its boot to sysNAND or emuNAND.

Picofly jobs only modify the boot sequence such that it will load payload.bin on the microsd. Thats all.

Its hekate (that usually use as the payload.bin) which responsible on booting to sysNAND or emuNAND. My guess is the hos in the emmc is corrupted, thats why it couldn't boot. Or wrong fuse count number. Or less probable scenario, wrong hekate configuration.

What is IMPORTANT for you to do first is backup your raw emmc then backup the key (prodkey, etc), its unique on your device. If you lose these key, your only option is use the shared key on the internet which is a banned one (you can't use nintendo shop, etc).

I think the safest advise i could give is try to reinstall the hekate on different microsd.
Use this https://rentry.org/SwitchHackingIsEasy as reference.

The other option like rebuild the hos, or install the atmosphere to sysnand, or update the fuse count, all have risk of breaking your system, and need further advance method to solve.

DONT try to update your picoly firmware.
It might break, and you need to take out the picofly and reupload the firmware, if it did break. Taking out the picofly is not as easy as it seems to. You might break the pad, and the solution will be like hell difficult.

Thank you for your detailed reply, it makes a lot of sense and gives me great pointers. I have backed up my EMMC and prod keys, no issues on backing EMMC but I actually got errors when trying to backup the keys, see image (unsure if it did it successfully). I also get an "Your EMMC is initialized in slowed mode, this might mean hardware issues" warning on Hekate when creating the EMUNAND.

I've checked my fuses and they seem to be OK, I got 19 and am on 17.0.0

As per your suggestion and after seeing those errors, it kinda seems like it is a corruption with HOS and EMMC?. I have again created an entire SD and EMUNAND from scratch but still failing to boot into OFW, it just freezes in black screen after the Nintendo logo. This time around however it did manage to boot into EMUNAND with a completely fresh SD, does this means the EMMC is not corrupted since I was able to create the EMUNAND in Hekate from the system EMMC ?

That was a lot of progress, thank you for you help :)
 

Attachments

  • Screen Shot 2024-08-02 at 1.08.32 PM.jpg
    Screen Shot 2024-08-02 at 1.08.32 PM.jpg
    870.6 KB · Views: 40
Last edited by gst0,

Site & Scene News

Popular threads in this forum