01:07 <clever> azonenberg: 1: https://www.flashrom.org/Serprog i could implement this into recovery.bin, and then flashrom can access the chips directly, even on a bricked board

01:07 <clever> the current way to un-brick is a closed-source recovery.bin that can just fail with no way to diagnose why

01:08 <clever> azonenberg: 2: i dont yet know how to bring the ddr4 or arm online, but you can stick to the 128kb L2 cache, and treat the rpi4 like an arduino, program the SPI flash, and let it run something dumb on boot!

01:08 <clever> azonenberg: 3: the ultimate goal, replace the SPI firmware, with open-source code to bring the dram online, and boot linux (perhaps using uefi for example)

01:09 <clever> azonenberg: without the key, you must start at the star4.elf stage, where dram is already online, you need an SD card, and you already relied on 1 blob to get this far

01:09 <azonenberg> interesting

01:10 <azonenberg> i say have fun :p

01:10 <clever> i have been :D

01:10 <clever> https://ext.earthtools.ca/videos/private/rpi/lk.bin

01:10 <clever> if you rename this to recovery.bin and pop it into an rpi4, you get a 115200 baud shell, with little-kernel being fully interactive

01:11 <clever> i'm mostly worried about what broadcom might try, if i was to leak the key

01:13 <clever> azonenberg: i also need to better understand how this key is generated, knowing that may greatly simplify cracking future models, and also allow codesigning on the older models

10:16 <jn__> clever: serprog support would be fun

15:02 <clever> jn__: there is also a user from #raspberrypi that has a broken rpi4 board, recovery.bin fails to hash files correctly and refuses to re-flash things, and the spi fails the hmac checks, causing it to fall thru to usb-device mode

15:03 <clever> jn__: if i had serprog, we could write to the flash and dump it back out, and see exactly how it differs

15:03 <jn__> yep

15:03 <jn__> flashrom would even *tell* you how many bytes in which range are wrong

16:35 <clever> jn__: while the stock recovery.bin, reads the file&hash from the sd card, then complains that the hash isnt right, and fails, with zero interaction

16:36 <clever> which implies to me, that something went wrong with the SD card routines

16:36 <clever> but the devs cant really be bothered to play 20 questions with a broken board, lol

16:36 <jn__> hmm

16:36 <clever> and i wouldnt want to force them to

19:54 <tnt> daveshah: by any chance to you have any clue how to use the serdes refclk as input for a pll ? I don't see a 'REFCLK' block in the NX libraries reference guid.

19:54 <daveshah> Haven't looked at the SERDES at all, but let me peek at the routing graph

19:56 <tnt> (I mean I'm not really trying to use the serdes at al but on the nx evn board the clock is connected there ...)

19:56 <daveshah> Assuming by serdes you mean pcie btw?

19:57 <tnt> yes.

19:57 <tnt> It's called serdes everywhere in the EVN user manual.

19:57 <daveshah> I think you would need to instantiate the core and use one of the core clock outputs to get at the refclk

19:58 <daveshah> I don't think there is an obvious direct path for the refclk anywhere

19:59 <tnt> Damn that's inconvenient :/

19:59 <daveshah> At least there is an internal oscillator for blinky

20:01 <tnt> Sure but I wanted to see if I could make the CDR work better there than on my custom board.

20:29 <sensille> i'm trying to find a way to dynamically resolve symbols within a verilator testbench. I already found i can statically access them in the top level object