<cyrozap>
Ohhhhh, I see what you're tring to do now. In one of the reverted commits in that series: "RPi4's VideoCore OS contains both the non public firmware load logic and the VL805 firmware blob. This function triggers the aforementioned process."
<cyrozap>
clever: Out of curiosity, where could I find that unstripped .elf you were talking about? Now I'm kind of interested in that "non public firmware load logic".
kristianpaul has quit [Read error: Connection reset by peer]
<clever>
cyrozap: i already tried to decompile it as VC4 (which is arc based), and it comes out as garbage
<clever>
one sec
horizon has quit [Read error: Connection reset by peer]
<clever>
cyrozap: this user was "helpful" enough to complain when the firmware size doubled, because somebody forgot to strip
<clever>
cyrozap: if you then dig enough, youll find that commit 4f63c3bdd4d9ca4f308e683fe7e70501b4ac3232 from the firmware repo contains those binaries
noknok has quit [Ping timeout: 256 seconds]
<clever>
cyrozap: on original pi4b boards, the vl805 has its own spi flash chip
<clever>
cyrozap: the normal xhci scratch space (xhci steals some host dram), is used to hold its own firmware, and the vl805 basically has an L1 cache, and will use pci bus-mastering upon cache miss
<clever>
upon pci-e reset, it reads spi->hostram to re-initialize itself
<clever>
cyrozap: the vl805 binary (linux, static) and recovery.bin binary (vpu, static), will poke at the address+data registers, to remotely trigger MMIO within the vl805, hijacking its spi controller, to relfash things
<clever>
cyrozap: on more recent rpi4b boards, the vl805 flash is missing (penny pinching), and the same addr+data registers are used to manually write a loader into the vl805 addr space, and start up the firmware
<clever>
cyrozap: but they didnt want to document it, and you have to manually re-init it after moving that scratch space, so after linux moves it, you have to poke the firmware via the mailbox
<cyrozap>
clever: Uh, are you _sure_ VC4 is based on ARC?
<cyrozap>
Also, I just found some VL805 firmware, and it's unmistakably 8051 code. I didn't even have to run it through cpu_rec since it had the standard 8051 vector table.
<clever>
cyrozap: several sources say VC4 is arc based, but one says they modified it heavily to support 80bit opcodes
<clever>
cyrozap: i have 3 different vl805 files, vl805hub.bin and vl805mcu.bin are used when the eeprom is missing
<clever>
cyrozap: vl805-000137ad.bin vl805-000138a1.bin are vl805 spi flash images
<clever>
let me try loading all of them as 8051...
<clever>
cyrozap: 8051 looks to be 16bit based? so it would have trouble with a 97kb flash image...
<cyrozap>
Ohh, wait, I may have been looking at a wrong firmware...
<clever>
cyrozap: these are the eeprom images for the dedicated vl805 flash
<clever>
but those only work on the original rpi4b boards (and dedicated pci-e cards)
<clever>
i have talked to one user, that successfully flashed a pi .bin file to an x86 card, and it fixed a uas bug
<clever>
but it also disabled 2 usb ports
q3k1 has joined ##openfpga
<cyrozap>
clever: Yeah, I'm looking at those now. I actually still think it's an 8051, since both binwalk (using cpu_rec) and at51 (https://github.com/8051Enthusiast/at51) both identified the first few 8kB or so as 8051 code, and the rest just looks like data. And despite being an 8-bit micro with a 16-bit bus for accessing "external data", many 8051 implementations use an SFR byte as a "page select", so you can
<cyrozap>
effectively have 24 address bits, which is generally "good enough" for most 8051 applications.
<cyrozap>
But to disassemble, you'll want to relocate the file so address zero is at file offset 0x80, since that's where the code starts.
<clever>
i can see that the irq0 code is clearly pushing a bunch of state onto the stack, calling the real handler, then popping once more
<clever>
thats pretty unique, and would let you figure out the load offset
<clever>
since the vector table is using absolute jumps
<cyrozap>
Unfortunately, this code doesn't look very fun to RE, since there are no strings, no guarantee of there being any kind of UART peripheral to interact through, and no point of reference to figure out the memory map.
<clever>
cyrozap: there is an spi controller, and i think its already been RE'd
<clever>
cyrozap: there is a pair of pci registers at offset 0x78 and 0x7c, 78 is a 16bit addr, and 7c is an 8bit? addr
<clever>
cyrozap: that lets you peek/poke any address within the 16bit space of the vl805
<clever>
0x400d0 and 0x400e0 are the register for the pending spi output byte, and the last spi byte in
<clever>
0x400f0 will trigger an spi byte exchange upon a certain write
<cyrozap>
For the ASM1142 (and related chips), there's strings in the binary, UART exposed on the chip, and I already had memory read/write capability through PCIe, which I was able to use to dump the mask ROM and XRAM/XDATA, and I was able to probe the XDATA address space by making strategic writes to the PCI address space of the chip.
<cyrozap>
clever: Oh, good, so you also are able to read and write memory from the chip's firmware's point of view through PCIe.
<clever>
ah, starting to read the reset function, and i'm seeing familiar patterns, it looks like its zeroing out the internal ram, starting at 0x7f, and working down to 0x00
<clever>
and only when thats done, does it set SP=0x60
Mimoja has quit [Remote host closed the connection]
<clever>
now that i know its 8051, lets see what the other 2 vl805 blobs say...
Mimoja has joined ##openfpga
<clever>
vl805hub.bin, has a pair of ljmp's to 0x2191 and 236c, starting at offsets 1&4...
<clever>
but the file isnt that big...
Mimoja has quit [Remote host closed the connection]
Mimoja has joined ##openfpga
<clever>
i cant find that irq0 save/restore pattern in either hub or mcu
<clever>
but there is a chance compression may be getting in the way