04:35 <lvrp16> for the hell of it I added support for all bpw between 1 and 64 to support those oddball transfers like mipi dbi 9 bpw. both pio and dma work although dma for > 8 bits only.

07:57 <narmstrong> lvrp16: :shipit: !

07:59 <lvrp16> https://github.com/libre-computer-project/libretech-linux/commit/80d6cb9bbf39e4a2690a2d9e6f34f759839e9c02

08:00 <lvrp16> Still need to update the comments and clean up thr debug code.

08:02 <lvrp16> spicc performance is pretty good against RK and allwinner. I can get 150MHz real out of it.

08:02 <lvrp16> It is by far the fastest for SPI displays.

08:03 <lvrp16> About 50%+ faster than RK.

17:26 <funderscore> nice

17:27 <funderscore> I think I managed to reverse-engineer most of the logic behind firmware loading/running. Indeed, aml_ddr.fw is ARM code, but I have some other discoveries to share

17:27 <funderscore> first of all, piei.fw is not just one firmware, it's actually 4 of them packed into one file :p

17:28 <funderscore> and BL2 iterates through them to know which one is which (hence the "PIEI prepare done" message over UART)

17:28 <funderscore> the "fastboot data" stuff I did not bother, as it turns out it fails on librecomputer-alta 🙃

17:30 <funderscore> Regarding firmware, what is done is the following: aml_ddr.fw is loaded at 0xfffb4000 (*NOT* 0xfffd0000, I believe that location is just some kind of buffer), after all the useless verification done on that thing. That's the first "🙃

17:31 <funderscore> oops. ...That's the first "Load ddrfw from SPI ..." message over UART. Then it loads piei.fw to *checks notes* 0xfffcc000 (once again, after all the verification and such), then like I said it iterates on it to figure out which one is which (since there's in total 4 firmware binaries in that thing). That's the second "Load ddrfw from SPI ..." message.

17:32 <funderscore> though I will say I don't know why they weren't any more creative with the names they give over uart, just ddrfw ddrfw ddrfw...

17:33 <funderscore> after the piei stuff it first runs `ddr_init_pll()` from aml_ddr.fw, then it loads `lpddr4_1d.fw` (on alta and iirc bpi-cm4 too) and runs some function from aml_ddr.fw I haven't yet figured out

17:33 <funderscore> rince/repeat for `lpddr4_2d.fw`

17:35 <funderscore> then it runs some ddr test stuff and writes to some register to "Enable ddr reg access" and then you're done

17:36 <funderscore> now, regarding this: 17:50 <xdarklight> to all reverse engineering interested people here wanting to take a look at the DDR firmware blobs on G12A and newer SoCs: $ dd if=aml_ddr.fw bs=1 skip=96 | lz4 > foo.bin.dec

17:36 <funderscore> the lz4 step compresses the firmware. All you really need is to strip the @DFM

17:37 <funderscore> then load in ghidra with base address 0xfffb4000

17:45 <funderscore> lvrp16: ^ if you're thinking of trying to save more space maybe you could try trimming piei.fw a bit (disclaimer: I haven't tried that, but it seems BL2 doesn't do any checks on how many piei firmware's there are afaict)

17:45 <funderscore> (it just blindly looks at the magic, e.g. dl44 for lpddr4)

17:48 <funderscore> Another thing I noticed, at the start of aml_ddr.fw (if you trim the header...) there are various pointers to functions: these are the functions BL2 runs afaik

20:17 <lvrp16> funderscore: What is PIEI exactly?

20:18 <lvrp16> They have a few hooks to setup GPIOs, PWMs

21:00 <funderscore> PHY Init Engine Image iirc

21:01 <funderscore> lvrp16: and yes I saw these hooks :)