narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - official channel moved from Freenode - publicly logged on https://libera.irclog.whitequark.org/linux-amlogic
jacobk has joined #linux-amlogic
montjoie has quit [Ping timeout: 244 seconds]
montjoie has joined #linux-amlogic
jacobk has quit [Ping timeout: 248 seconds]
jacobk has joined #linux-amlogic
hexdump0815 has quit [Ping timeout: 240 seconds]
hexdump0815 has joined #linux-amlogic
hexdump0815 has quit [Ping timeout: 255 seconds]
hexdump0815 has joined #linux-amlogic
<narmstrong> Kwiboo: damn this is awesome 😎
f_ has joined #linux-amlogic
<f_> Kwiboo: Nice!
<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_> I doubt loading images would work anyway
<Kwiboo> and on g12a it hang because of 'u32 boot_device = readl(SEC_AO_SEC_GP_CFG0)' in spl_boot_device, with https://github.com/Kwiboo/u-boot-rockchip/commit/09d1b08b98c81ebc4f77554ede6ada1b818ad7c0 both could get until no more boot devices
<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_> *too
<f_> you have the KII Pro defconfig in your tree
<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_> F3 is what the check() function returns
<f_> It can return 0xf3 for multiple reasons
* f_ looks up notes in the git repo
<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
<f_> Meh, that's for ARC
<f_> Ah.
<f_> I didn't expect it to hang at pll init
<Kwiboo> f_: https://github.com/Kwiboo/u-boot-rockchip/commit/afe3915c2dc68f31e5b5679c91b068909e4b75ff should help make a bootable u-boot-amlogic.bin, amlimage.c need some comments and a few convert of magic numbers to constants
<f_> Awesome
<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>)`...
<f_> I swapped the arguments :P
<Kwiboo> Hehe :-D
<f_> Sleepy brain I guess :S
<f_> Should work now :S
<f_> Nice, it loops now.
<f_> and I know exactly why.
<f_> wr_reg(AM_DDR_PLL_CNTL, rd_reg(AM_DDR_PLL_CNTL)&(~(1<<29)));
<f_> ^ I need to add this
<f_> And PLL init done!
<f_> Now let's troubleshoot....the rest, hehe
<f_> Got further!
<f_> Kwiboo: At this point I get mostly the same logs as you, with the dram logs however
<f_> And I encounter the same problem as you do
<f_> *did
<f_> which is weird.
<f_> Kwiboo: ah, forgot bootph-all :P
<f_> You added it to meson-gxbb-odroidc2-u-boot.dtsi, but I'm adding it to meson-gxbb-u-boot.dtsi instead
<f_> (I created that file)
<Kwiboo> Hehe, yeah I just added it to the most convenient file to test
<f_> Understandable.
<f_> While at it I'll do the same for any other nodes it complains about.
<Kwiboo> I pushed an update to the amlimage code, mainly code style and comment changes, also moved copy of data from datafile out of the set_header function, https://github.com/Kwiboo/u-boot-rockchip/blob/meson-gxbb-spl/tools/amlimage.c
<Kwiboo> Will you pick it and eventually send it upstream or should I try to send it upstream in current state?
<f_> Perhaps send it to me first?
<f_> Because initially it won't serve any purpose without SPL being set up.
<Kwiboo> Sure, yeah, without your SPL work it have no real purpose, will prepare a proper patch later :-)
<f_> When ready, `git send-email` to vitali64pmemail -at- domain -dot- com
<f_> s/domain/protonmail/
<f_> (http bot spammers, thank you!)
<f_> When I'll send a proper patch for adding SPL support, I'll probably include your patch :)
jacobk has quit [Quit: No Ping reply in 180 seconds.]
jacobk has joined #linux-amlogic
<f_> We did great work today.
<f_> I'll go. Tomorrow I'll push what I currently have.
f_ has quit [Ping timeout: 246 seconds]
GNUtoo has quit [Ping timeout: 246 seconds]
GNUtoo has joined #linux-amlogic
<Kwiboo> f_: I will send you a patch tomorrow, thanks and great work!
vagrantc has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-amlogic
BlueMatt_ has joined #linux-amlogic
montjoie_ has joined #linux-amlogic
montjoie has quit [*.net *.split]
BlueMatt has quit [*.net *.split]
Lyude has quit [*.net *.split]
Lyude has joined #linux-amlogic
jacobk has quit [Ping timeout: 255 seconds]
jacobk has joined #linux-amlogic