<f_>
I won't be working on SM1/G12A for now though, but nice to see it loads to..something.
<f_>
I completly overlooked the stack because I expected SPL to work up until that point, because in my earlier upstream TF-A BL2 adventures I didn't need to do any of that.
<f_>
Don't know why I thought that...clearly that was stupid :X
<f_>
Kwiboo: You told me it hangs and resets, because of the watchdog
<f_>
the watchdog actually only seems to make the board reset when it hangs
<f_>
*when an instruction hangs
<f_>
And writing to a DDR address (anything between 0x0 and 0xBFFFFFFF) without it being initialised just so happens to make it hang
<f_>
(but I doubt that's what you got)
<f_>
Either way, thanks a lot!
<f_>
I appreciate the help.
<f_>
Also, I didn't implement board_init_f() for now. I'll implement it today
<f_>
It will be common to all Amlogic SoCs, but I'll mostly put weak function definitions, which will get overridden by e.g. dram-gx.c.
<f_>
or dram-axg.c, or dram-g12a.c, etc..
<f_>
I'll also clean up the mess I made :/
<f_>
I'm well aware that there's a lot of stuff I didn't do the way it's supposed to be intended
<f_>
I have to admit that what I've done was pretty dirty.
<f_>
As for g12a boards, ¯\_(ツ)_/¯ could perhaps reuse some of the i.MX8MQ DRAM init code as it seems like they use the same/similar firmware.
<Kwiboo>
f_: after digging some more, instead of sleeping ;-), I found out what my issues was and why it reset
<f_>
Yeah I saw the logs changed
<f_>
Before sleeping I saw your messages in the public logs and saw the gist you linked
<f_>
it looks a little bit different from yesterday
<Kwiboo>
on gxbb after 'gd->flags |= GD_FLG_SERIAL_READY', nothing more was written to uart, so I thought it did not get any longer, but it continued until it it ran out of boot devices, just not printing anything, stopped and reset by watchdog
<f_>
Yeah I should've used meson_get_boot_device();
<f_>
Dirty work :X
<Kwiboo>
yeah, it need your magic DRAM init before it has a chance of working :-)
<f_>
Magic™
<f_>
Honestly only initialise_dram_pctl is magic, the rest is......understandable
<f_>
But still somehow magic.
<f_>
Kwiboo: But thank you for your help!
<Kwiboo>
Hehe, to me anything that low level is magic :-)
<f_>
As long as there's no magic smoke it should work.
<f_>
Also needs a custom board_init_f() function, the default one doesn't load dram_init()
<Kwiboo>
no problem, was fun digging into this again, I cannot understand how I managed to get the old sd+emmc hack working back in 2016, beside lots of guessing, trail and errors, information I learnt then still seem to hold true
<f_>
HardKernel+Amlogic nonsense
<f_>
But you did a nice work in 2016
<f_>
I can see you're using a very recent U-Boot oo
<f_>
(I sent patches for supporting that set-top box and they just recently got merged)
<f_>
either way, nice work!
<Kwiboo>
btw, a few notes: 1. meson64-tools call the digest_size field block_size, so my note that this could change to 32 byte may not be valid, 2. ensure you add bootph- props on devices you need in spl, not sure why the vpu node have bootph-all, maybe it was needed in u-boot proper pre-relocation
<f_>
Sure
<Kwiboo>
Yeah, my tree was latest upstream master + bunch of rockchip patch, was going to send out a few patches yesterday but was more fun playing with this :-)
<f_>
:)
<Kwiboo>
Have you already started on a binman/mkimage tool that can "sign"? else I wouldn't mind seeing what I can come up with today, thinking of extending mkimage and use the mkimage etype node for binman, similar how it is done for rockchip today
<f_>
I started yesterday
<f_>
If you want though you can work on mkimage :)
<f_>
For now I'm painfully using amlbootsig without do_fip() and manually writing the rest with dd, updating checksums with aml_chksum
<f_>
but extending mkimage looks like a great idea
<f_>
(better than rewriting a new tool from scratch I'd say)
<Kwiboo>
Hehe, yes, I will see what I can do, adding a U_BOOT_IMAGE_TYPE and similar code that what amlbootsig does should be pretty simple, and help automate your continued endevour
<f_>
Thanks!
<f_>
By the way your amlbootsig doesn't write the rest either
<f_>
If you use u-boot-gxbb-with-spl.bin with amlbootsig it's not going to write the other image entries
<f_>
Only until 0xb000, requiring you to write the rest with `dd`.
<Kwiboo>
yeah, I stripped it to only do what I needed it to do for minimal testing purposes, wanted to see I could change bl1 CHK:F3 into CHK:0
<f_>
It runs header_check() which is actually the one returning 0xf3
<Kwiboo>
then I did not understand if it continued to run code or just stopped, so added a small void save_boot_params(void) that just writel into uart tx fifo reg, and a small dot showed up on screen so code was running
<Kwiboo>
cool, thanks for hints, btw, do you know if bl1 will try to look for @AML at any other offsets?
<f_>
doubt it
<f_>
but that BL1 decompilation is pretty new and very much incomplete.
<f_>
More incomplete than the gxbb BL2 decomp
<f_>
But I don't see any other offsets it checks
<f_>
*any other offsets other than offset 0 and 512
<f_>
oh, by the way, I didn't mention the fact that these files in that repo can be imported in ghidra
<f_>
Kwiboo: By the way the thing you commented only runs if CONFIG_SPL_SERIAL_PRESENT is set
<f_>
that option enables a full UART driver
<Kwiboo>
yes, it need SPL_DM, SPL_SERIAL. SPL_DM_SERIAL or the meson serial driver does not compile or provide debug_uart functions
<f_>
SPL_SERIAL_PRESENT seems to be optional
<Kwiboo>
I tired to copy minimal for debug_uart into spl.c but then there is other code that look for SPL_SERIAL or puts/putc will be empty inline functions
<Kwiboo>
did not dig deeper
<f_>
Sure
<Kwiboo>
then I think there was complains about dev_read_ functions, so SPL_DM was needed
<Kwiboo>
on rockchip rk35xx that I have done most work recently we only have DRAM init code in external blobs so in SPL we have full DRAM ready and code size limit is up to 256kb, so I have not needed to care that much about code size and can enable most things ;)
<f_>
Rockchip cheats
<f_>
I think these also use Synopsys DDR controllers, right?
<f_>
Synopsys DDR init is always magic.
<Kwiboo>
yes rockchip cheats :), and that 256kb limit is only because bootrom loads SPL to 0x0 and SPL will try to load TF-A to 0x40000, so there may be ways to get around such size limit
<Kwiboo>
possible, have not looked into that, I just use the provided ddr and tf-a blobs, they could easily be replaced once there is full open source alternatives
<f_>
Lots of SoCs use Synopsys DDRC, including Amlogic SoCs, sunxi SoCs and some NXP SoCs
<f_>
so I wouldn't be surprised if the Rockchip SoCs you've been working on used Synopsys DDRC too.
<f_>
Synopsys is everywhere :)
<f_>
Kwiboo: For signing I presume you just used your modified amlbootsig and dd to the SD card, right?
<f_>
Ah you wrote how you did it in aa gist comment
<f_>
Oh great
<f_>
I have a much shorter log than yours but I got something
<f_>
(because I didn't set LOG_DEBUG in log.h)
<Kwiboo>
yes, I did something to that affect, yeah defining LOG_DEBUG in log.h or at make will result in lot more logs
<f_>
But I do get that '### ERROR ### Please RESET the board ###'
<f_>
I didn't expect it to work anyway because, while my DRAM init code got compiled in, well, nothing calls dram_init so it never gets ran.
<Kwiboo>
cool, so it has done all it was trying to do and failed, it could not load and jump to next stage
<f_>
It couldn't initialise the MMC
<f_>
I added more stuff than you
<f_>
It does detect from which MMC device to boot (in this case, MMC2 so, SD card) so that's good.
<f_>
Just for the sake of having fun let's load U-Boot SPL from USB!
<Kwiboo>
Great! :-D
<f_>
For the sake of having fun and seeing it panic
<f_>
:D
<f_>
MMC is the reason why I started working on U-Boot SPL instead of TF-A BL2
<f_>
well..also because of binman and nice U-Boot stuff
<f_>
Now it just outputs '<debug_uart>'
<f_>
that is, unless I stick a `printf("hi\n");` at the beginning of board_init_f(), in which case it also outputs 'hi'
<f_>
90% sure it's a DRAM init issue
<f_>
It *is* a DRAM init issue
<f_>
commenting out the function that inits the DRAM makes it go through, until '### ERROR ### Please RESET the board ###'.
<f_>
What
<f_>
I didn't expect seeing a Synopsys copyright header in U-Boot
<Kwiboo>
but the tool seem to work and produce same result that the amlbootsig tool that I used yesterday
<f_>
You forgot copyright header though ;)
<f_>
But nice work!
<Kwiboo>
should also be possible to print header with "tools/dumpimage -l u-boot-amlogic.bin" and extract payload with "tools/dumpimage -T amlimage -o u-boot-spl.bin u-boot-amlogic.bin"
<f_>
So we go from a bazillion commands to a simple `make` :)
<Kwiboo>
Hehe, yeah, very helful to just run make and then have blobs that is ready to be flashed
<f_>
Indeed
<f_>
Nice work! I'll put that in my tree
<f_>
I'll perhaps try on one of my gxl boards too.
<Kwiboo>
Thanks, and cool, I was hopin that there was a soc family config option that could be used but did not look like it, on rockchip we have a single binman config and use: args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
<f_>
Perhaps `#if CONFIG_MESON_GXBB` / `#endif`?
<Kwiboo>
not sure what names are used, but tested differenet like axg and g12b in libreelec amlogic-boot-fip repo, and they all signed similar to the 3 modes included in amlimage
<Kwiboo>
so those 3 combos are the ones I could find, v1.0 with 0xb000 payload, v1.1 with 0xb000 payload, and v1.1 with 0xf000 payload
<f_>
Yeah as long as they blindly boot BL2 it should be fine
<f_>
(assuming secureboot isn't enabled)
<f_>
Seems like I got the DRAM clock wrong!
<f_>
I set it to 950 when it was supposed to be (according to ACSBaby output on WP2 acs.bin) 912 lol
<f_>
Not sure why it would not work though
<f_>
Let me check
<f_>
Nope.
<f_>
Obvious mistake...
<f_>
I wrote `writel(AM_DDR_PLL_CNTL0, <thing>)`...