Hacking Hardware Picofly - a HWFLY switch modchip

[Adran_Marit]

Can I dual boot Ubuntu and stock HOS fw 16 ?

Yeah if you got them keys

 

[Raugo]

Yeah if you got them keys

Keys are not needed, ubuntu don't need it and is possible to desactivate the chip to go to OFW

 

[rulles]

Keys are not needed, ubuntu don't need it and is possible to desactivate the chip to go to OFW

Can you explain how to do that?!

 

[Raugo]

Can you explain how to do that?!

Pressing Vol+ and Vol- during boot disable the chip and launch OFW.

 

[crysmx]

Do BS

 

[TheSynthax]

I don't know what's up with this, but nothing I do results in this chip booting Hekate or any other Mariko payload. Always the same LED pattern, always indicating success, never actually booting. Resoldered all points 4 times, tried with and without resistors, even tried exFAT vs FAT32, no difference whatsoever. Removing one point results in the Switch booting normally (then bootlooping as the chip tries to reset it) but with all lines soldered it's the same blue > light blue > white > green and the screen remains black. Payload is always named payload.bin and placed on the root of the SD card. Without it, I don't get a "no SD" screen either.

 

[kimitoboku101]

I don't know what's up with this, but nothing I do results in this chip booting Hekate or any other Mariko payload. Always the same LED pattern, always indicating success, never actually booting. Resoldered all points 4 times, tried with and without resistors, even trief exFAT vs FAT32, no difference whatsoever. Removing one point results in the Switch booting normally (then bootlooping as the chip tries to reset it) but with all lines soldered it's the same blue > light blue > white > green and the screen remains black. Payload is always named payload.bin and placed on the root of the SD card. Without it, I don't get a "no SD" screen either.

so you success to boot to hekate with RP2040 ??

 

[TheSynthax]

@Tafty Was the console you installed yours in modded previously with an HWFLY?

 

[ifgfgfgfgfgfg]

This would fit inside I think inside v2 Mariko.. og pic has usb de-soldered

 

[TheSynthax]

This would fit inside I think…

Buttons are still too tall, it can't stick up past the height of the speaker.

 

[ifgfgfgfgfgfg]

Buttons are still too tall, it can't stick up past the height of the speaker.

Switch lite has no space yes

 

[TheSynthax]

Same problem here. Flashed .uf2 (1.1 unlocked Ubuntu one), soldered all points correctly to switch lite… aaaaand yellow led at the end . Tried several times, several rp2040, with and without resistors (0806 smd 47ohm) same thing. Used np2016dr mosfet (taken from hwfly V2 flex) - soldered with enameled magnet wires according to the diagram provided - no hekate, just a black screen with no backlight. With hwfly V2 flex and hwfly lite flex - ALL the same yellow led at the end of chip working . After all, I’ve soldered the same wires directly to hwfly lite chip and it all worked like a charm (so it is not the soldering problems ((
It was yesterday and I gave up, decided to wait for new firmware with HOS support.

Hey, did you happen to bridge the "GRB / RGB LED mode" pads on the back?

That's two people now who are skilled chip installers with exactly the same result after installing an rp2040 with this firmware, so either we both fucked up in similar ways (kinda doubt) or this is looking kinda sus. (the "ubuntu" firmware, that is)

 

[achm3t]

Hey, did you happen to bridge the "GRB / RGB LED mode" pads on the back?

That's two people now who are skilled chip installers with exactly the same result after installing an rp2040 with this firmware, so either we both fucked up in similar ways (kinda doubt) or this is looking kinda sus. (the "ubuntu" firmware, that is)

Hi, no the only one thing that was not made is bridging led mode pins, but I really think it will not affect at all. May be length and thickness of wires can really be the problem. In original photos from first leak, we saw short and thick wire going to the cpu flex from rp2040, soldering was very poor, but wires were massive )). I used 36awg and it was about 4cm long. Seems that can be a problem. Anyway, I left any attempts for future, nowadays I have too much switches to mod with existing hwfly options
P.S. But if community needs my help, I can use any of 4 existing models (erista and 3 different mariko’s) as a guinea pig for testing and experimenting purposes with rp2040. I have all switches and multiple rp2040 in hand.

 

[Kingdedede]

Hi, no the only one thing that was not made is bridging led mode pins, but I really think it will not affect at all. May be length and thickness of wires can really be the problem. In original photos from first leak, we saw short and thick wire going to the cpu flex from rp2040, soldering was very poor, but wires were massive )). I used 36awg and it was about 4cm long. Seems that can be a problem. Anyway, I left any attempts for future, nowadays I have too much switches to mod with existing hwfly options
P.S. But if community needs my help, I can use any of 4 existing models (erista and 3 different mariko’s) as a guinea pig for testing and experimenting purposes with rp2040. I have all switches and multiple rp2040 in hand.

make sure the diagrams are right and everything works perfectly installed on mariko

 

[rulles]

Pressing Vol+ and Vol- during boot disable the chip and launch OFW.

Yes, but how I boot Ubuntu?!
It's only possible boot Ubuntu or work another Linux distros?!

 

[Adran_Marit]

Keys are not needed, ubuntu don't need it and is possible to desactivate the chip to go to OFW

We aren't trying to boot off tho, and boot cfw we need the firmware to not clear the key slots

Speaking of... if anyone who can analyse the firmware, can you compare it to say a modded version of hekate that has the keyslot cleared.

 

[renoob]

Maybe silly question but is there anywhere online how ubuntu payload looks like (hex pattern)?

 

[binkinator]

Maybe silly question but is there anywhere online how ubuntu payload looks like (hex pattern)?

This is what most people will be using:

https://wiki.switchroot.org/en/Linux/Ubuntu-Install-Guide

specifically this download:

https://download.switchroot.org/ubuntu/

 

[Tafty]

@Tafty Was the console you installed yours in modded previously with an HWFLY?

its a lite and yes it had an SX lite in before.

Post automatically merged: Feb 22, 2023

Hey, did you happen to bridge the "GRB / RGB LED mode" pads on the back?

That's two people now who are skilled chip installers with exactly the same result after installing an rp2040 with this firmware, so either we both fucked up in similar ways (kinda doubt) or this is looking kinda sus. (the "ubuntu" firmware, that is)

i can film it in action if you want, i can ensure you...you guys have installed it wrong.....ive done probably well over 100 modchip installs now for reference across mariko/lite and oleds

 

[TheSynthax]

its a lite and yes it had an SX lite in before.

I'm wondering if there's some preparation step the SX/WHFLY performs that the "Ubuntu" version isn't programmed to do. Or, the firmware is *really* flaky about detecting successful glitching for some reason and just stops trying. Looks like we'll need to narrow down the variables here, which would be so much easier with an open firmware with a serial debug console.

Post automatically merged: Feb 22, 2023

Hi, no the only one thing that was not made is bridging led mode pins, but I really think it will not affect at all. May be length and thickness of wires can really be the problem. In original photos from first leak, we saw short and thick wire going to the cpu flex from rp2040, soldering was very poor, but wires were massive )). I used 36awg and it was about 4cm long. Seems that can be a problem. Anyway, I left any attempts for future, nowadays I have too much switches to mod with existing hwfly options
P.S. But if community needs my help, I can use any of 4 existing models (erista and 3 different mariko’s) as a guinea pig for testing and experimenting purposes with rp2040. I have all switches and multiple rp2040 in hand.

Interesting. I had the exact symptoms you did (yellow/orange LED and black screen) but only when the LED jumper was closed. If yours was closed also I would have assumed we were seeing the same error. Oddly, the only difference the LED jumper makes in LED color seems to be the final LED color after what I assume to be the "preparation stage". Even weirder, I can't get it to show a specific error based on removal of a specific line, leading me to think that the error lights list we have is for a different firmware version than we have, one with significantly more error checking and error recovery.