Hacking Hardware Picofly - a HWFLY switch modchip

  • Thread starter Thread starter mathew77
  • Start date Start date
  • Views Views 3,671,328
  • Replies Replies 17,052
  • Likes Likes 15
I've created a repository for an eMMC interface using the RPi Pico, I haven't and currently can't even test it out in reality, though in theory I currently have a CLK signal, CMD sending (48bit packages) and CMD receiving (48bit and 136bit responses, is set when sending to determine which state machine to use, though probably can be even more optimized)

I also have DAT0 receiving, receiving gets triggered through MCU code via an IRQ.

Again, I haven't tested it out at all, I was just following the documentation on the MMC 4.1 interface (downloadable for free on JEDEC's website). Two things missing: I forgot to actively pull the CMD and DAT0 lines to HIGH and also a PIO can only have 32 instructions, which is why I currently don't have DAT0 sending.

I could just load DAT0 sending into the second PIO but my idea was to have everything on one PIO, sadge..

I tried to document what I was doing in the sourcecode, but honestly it's a complete mess and there's still a lot to do.

Anyway, if anyone likes to mess with the Pico's PIOs, here's something to look at I guess:

https://github.com/Overflwn/pico_emmc
great, let's hope for a success of the project
 
  • Like
Reactions: impeeza
To sniff the bus, we'd need PIO code that reacts to the Switch's CLK signal, I haven't done that yet. This code currently produces its own CLK signal so it's more useful for reading/writing to eMMC independently from the Switch.

I'll take a look at it tomorrow, maybe I'll figure something out.
I guess one idea would be that this code is specifically for writing the payload to the eMMC (hold RESET pin so that the Switch doesn't interfere -> start CLK and write payload to the eMMC) and after writing the payload we'd have to (re-)start the Switch anyway and that's where the "sniffing PIO code" comes in.

Honestly, even though only sniffing the eMMC data shouldn't do any damage to the Switch, I'm kind of scared of trying to hook it up to an actual Switch :unsure:

The eMMC communication is basically the first important half of the Picofly and honestly I'm surprised that I couldn't find ANYTHING regarding somebody implementing the eMMC protocol on Picos as this is a public and popular type of flash storage..

Other than that, I don't know if I really should dive deeper into this topic after I've successfully implemented the eMMC protocol, big N's ninjas have eyes everywhere.
Take a look at pi pico projects which use an SD card. The emmc and sd card protocols are the same.
 
Apparently you can google better than me. I've skipped through the code and honestly I think I know the RPi too little to understand how the data actually gets transferred.

To read/write data, this file uses mmio_read / mmio_write from mmio.h/-.c, but all that these functions do it write or read a 32bit unsigned int from the specified address. The "base eMMC address" is
"#define EMMC_BASE 0x20300000"

I honestly don't know where that comes from and how the RPi actually writes/reads the data from the eMMC.
Post automatically merged:

finally bit the bullet and decided to learn c :ha:. if this project is gonna be in my mind 24/7 i might as well do something productive while I'm at it :lol:
C is pretty cool and honestly not that hard, using pointer is basically the only "hard" part about it, other than that it's more that understanding the API that you want to use (RPi Pico SDK in this case) and the hardware is the difficult part about it.
Post automatically merged:

After searching for a while I've found a repo that implements the SDIO protocol (basically the same serial protocol that we need for the eMMC) in 4bit mode using RPi Pico and PIOs:

https://github.com/ZuluSCSI/ZuluSCSI-firmware/blob/main/lib/ZuluSCSI_platform_RP2040/rp2040_sdio.pio
https://github.com/ZuluSCSI/ZuluSCSI-firmware/blob/main/lib/ZuluSCSI_platform_RP2040/rp2040_sdio.cpp
 
Last edited by Piorjade,
what I mean that on 4pda something has the fw not encrypted
Post automatically merged:

obviously if we can write the firmware from scratch it's better
 
  • Like
Reactions: binkinator
Writing a new firmware from scratch is the way to go. We don't want to be stuck with a firmware that is closed and can't be updated in the future.
You dont really need to update the firmware if it works. SX boot still works after all. But sure I do like opensource as well
 
Ubuntu work
HOS not work
 

Attachments

  • erista.jpg
    erista.jpg
    107.6 KB · Views: 215
  • mariko.jpg
    mariko.jpg
    116.8 KB · Views: 233
  • pinout.jpg
    pinout.jpg
    245.2 KB · Views: 222

Site & Scene News

Popular threads in this forum