06:59 <tlwoerner> how would i begin to debug: board_boot_order: could not find /dwmmc@ff480000 in FDT

07:00 <tlwoerner> it should find that node, that node is in the device tree

11:13 <marex> tlwoerner: git grep board_boot_order maybe ?

13:47 <Forty-Bot> ok, so the problem is definitely that the fs_loader driver is 32- (or 64-) byte-aligned

13:47 <Forty-Bot> and this is caused by the DM_DRIVER_GET in get_fs_loader

14:06 <tlwoerner> marex: yes, i've printf()'ed up this board's arch/arm/mach-rockchip/spl-boot-order.c → spl_node_to_boot_device() and i see my statements getting hit, so i know i'm in the correct place

14:07 <tlwoerner> i've tweaked the u-boot,spl-boot-order to be: "same-as-spl", &sdmmc;

14:08 <tlwoerner> the code iterates through this list, but for each entry (/mmc@ff480000 and /dwmmc@ff480000) it says "could not find X in FDT"

14:10 <Tartarus> Do you _know_ it has found the FDT for real?

14:10 <Tartarus> I'd maybe do a few checks in that direction (can you find some other node you _know_ must be there, etc)

14:11 <tlwoerner> Tartarus: are there 2 different FDTs for SPL vs full U-Boot?

14:13 <tlwoerner> in any case, at the end of that function is a check and if nothing is found, i can play with which boot device to try

14:13 <marex> tlwoerner: well kind-of

14:13 <tlwoerner> i've hard-coded trying both MMC1 and MMC2 and in both cases i get:

14:13 <marex> tlwoerner: but I think Tartarus question was rather whether you are sure the SPL is processing the correct DT at all

14:14 <tlwoerner> spl: could not initialize mmc. error: -19

14:16 <tlwoerner> marex: i'm trying to guess which node would be a good one to try and would rather not try a bunch that wouldn't be in the SPL's FDT

14:17 <marex> tlwoerner: check your build output, there should be some spl/u-boot-spl.dtb

14:17 <marex> tlwoerner: dtc -s -I dtb -O dts spl/u-boot-spl.dtb | less

14:17 <marex> tlwoerner: inspect the output, is the mmc node there ?

14:18 <tlwoerner> marex: nice! good idea

14:26 <tlwoerner> nice! it's not there. ff480000 is not in the spl FDT, but ff490000 is there (which is the onboard emmc, which this board does not have)

14:27 <tlwoerner> how do i get the ff480000 entry to be included in the SPL's FDT (and maybe remove the ff490000 one)?

14:33 <Forty-Bot> and the solution is to add __aligned(4) to the ll_entry_get access

14:39 <Forty-Bot> the real question is how I got lucky with fs_loader in the first place...

14:45 <tlwoerner> is there a u-boot tag i can add to the node to get it included in the SPL's FDT?

14:46 <Tartarus> Forty-Bot: Can you throw that change at CI in Azure please? I wonder a tiny bit about LTO/LLVM

14:46 <Forty-Bot> the alignment one?

14:47 <Forty-Bot> also: maybe we should have __aligned(sizeof(void *)) ?

14:47 <f_> <tlwoerner> Tartarus: are there 2 different FDTs for SPL vs full U-Boot?

14:47 <f_> Sort-of.

14:48 <f_> In the SPL build the DT is cut down to minimum

14:48 <f_> See doc/develop/spl.rst 'Device tree'

14:49 <f_> Only mandatory nodes and nodes with bootph-all/bootph-pre-ram are left intact

14:51 <tlwoerner> thanks

14:51 <f_> Np

14:52 <f_> mainline U-Boot SPL on amlogic coming soon ;)

14:56 <Tartarus> Yeah the alignment one

14:56 <Tartarus> I recall some slight problem with LTO and/or clang and the lists

14:56 <Tartarus> Just want to be sure it doesn't get tripped up

14:57 <Forty-Bot> ok

15:02 <Kwiboo> tlwoerner: your board is a rk3308? sdmmc node already have bootph-all prop in rk3308-u-boot.dtsi, are you missing a status=okay on your sdmmc node? or you may need to add a board -u-boot.dtsi and include soc -u-boot.dtsi

15:03 <f_> hi Kwiboo :)

15:04 <Kwiboo> f_: hi :-)

15:05 <f_> Saw your RFC in my mailbox

15:06 <Forty-Bot> Tartarus: huh, you were right https://source.denx.de/u-boot/custodians/u-boot-clk/-/jobs/702115

15:06 <f_> said I was going to try and reproduce again

15:07 <f_> and for reference I also pasted the output of aarch64-gcc --version and hostcc gcc --version

15:07 <f_> hostcc isn't really necessary tbh though

15:07 <f_> (by which I mean, didn't really need to paste output of hostcc)

15:08 <f_> I don't really feel like LTO's going to stay by default either

15:09 <f_> LTO is a nice temporary solution to the size limit but I think it would be nice to shrink the size of SPL to the point where LTO isn't needed anymore for compiling to succeed.

15:09 <f_> That issue in the RFC could by caused by LTO, not sure

15:09 <f_> still need to investigate further

15:10 <f_> For now I'm cleaning up some code for easier gxl porting

15:11 <Kwiboo> the issue was still pressent with/without LTO when I tested, only using -O1 or -fno-peephole2 flag fixed the issue for me, or use of uint to remove the alignement hole

15:12 <f_> hmm

15:13 <Forty-Bot> so maybe the bug is that get_fs_loader should use DM_DRIVER_REF and not DM_DRIVER_GET?

15:13 <Tartarus> Entirely different problem, wow

15:13 <Tartarus> But, yeah

15:13 <Tartarus> CI is important for generic changes :)

15:13 <f_> Kwiboo: so I'll let others chime in :)

15:14 <Forty-Bot> but I feel like maybe DM_DRIVER_GET/REF is a footgun

15:16 <Forty-Bot> like, maybe ll_entry_get should warn if the symbol is already declared

15:17 <Kwiboo> f_: https://gist.github.com/Kwiboo/713703809ce19b34d7458fe0f21f846b <<-- this was the assembly with peephole2 enabled (bad) and with no-peephole2 (good/working), main diff is instruct order and use of store pair instruction

15:19 <f_> I wonder why nobody got that bug in U-Boot proper

15:19 <f_> or did it go unnoticed?

15:26 <Kwiboo> yeah, super strange, possible a compiler bug, or cpu errata? but seeing same issue on cortex a53 and a55, cmd.cmdidx is one value before call to mmc_send_cmd_retry() and inside it instead has the same value as data.blocksize

15:34 <Kwiboo> maybe the mixture of 32-bit and 64-bit register in "stp x21,w0,[sp, #data]" could cause the observed issue

15:37 <Xogium> please tell me it is possible to format env variable a little ? Not stuff everything on the same line...

15:37 <Xogium> this is unreadable with a screen reader

15:38 <Xogium> like that for example

15:38 <Xogium> bootcmd_stm32mp=echo "Boot over ${boot_device}${boot_instance}!";if test ${boot_device} = serial || test ${boot_device} = usb;then stm32prog ${boot_device} ${boot_instance}; else run env_check;if test ${boot_device} = mmc;then env set boot_targets "mmc${boot_instance}"; fi;if test ${boot_device} = nand || test ${boot_device} = spi-nand ;then env set boot_targets ubifs0; fi;if test ${boot_device} = nor;then

15:38 <Xogium> env set boot_targets mmc0; fi;run distro_bootcmd;fi;

15:38 <Xogium> this is nearly impossible to parse

15:41 <f_> You use a screen reader?

15:41 <Xogium> yes

15:43 <Xogium> and right now, I wish we could like, put one if/fi on multiple lines

15:43 <Xogium> like it is doable in a boot script

15:43 <Xogium> because ugh

15:45 <Xogium> at some point I'm fairly sure this becomes unreadable even when you have working eyes

15:45 <Forty-Bot> you can do it

15:45 <Forty-Bot> but people generally don't because the newline is longer to type than a space

15:46 <Forty-Bot> and there is already a newline in the config header

15:46 <f_> Xogium: pretty unreadable to me too

15:47 <Xogium> Forty-Bot: so I could store a full script in the env on multiple lines ?

15:47 <Forty-Bot> yes

15:47 <Forty-Bot> it will parse fine

15:48 <Xogium> as long as I do proper quoting, I assume

15:51 <Xogium> setenv even adds \ for you and all, that's nice

21:36 <tlwoerner> Kwiboo: yes, the rock-pi-s (rk3308) i'm pretty sure the sdmmc node is not present in the SPL's FDT

21:36 <tlwoerner> i have the cheapest rock-pi-s of the family, the one that doesn't have emmc

21:37 <tlwoerner> but i'll give the suggestions here a whirl and see where it goes

21:39 <tlwoerner> Kwiboo: it's almost like we need to split the device tree into 2: one for the devices with emmc, and one for those that don't have emmc

21:39 <tlwoerner> because all the emmc definitions in the device-tree are not valid for my rock-pi-s

21:55 <Kwiboo> tlwoerner: I have a rock-pi-s v1.3 with sd card and nand storage that I can test on, building latest u-boot master with rock-pi-s-rk3308_defconfig show both emmc and sdmmc node in spl/u-boot-spl.dtb

21:57 <Kwiboo> you probably also need https://patchwork.ozlabs.org/patch/1831790/ and build with ROCKCHIP_TPL= to have something that can boot

22:16 <tlwoerner> Kwiboo: aha, yes i see that in the code. i've been testing with v2023.07.02

22:16 <tlwoerner> (which doesn't have the bootph-all for sdmmc)

22:17 <tlwoerner> i've been using the rk3308_ddr_589MHz_uart0_m0_v1.26.bin from rockchip's rkbin as my TPL

22:17 <tlwoerner> which is an older release. it's too bad they got rid of the "uart0" with the newer releases

22:18 <tlwoerner> does anyone know what the "m0" vs "m1" means?

22:19 <tlwoerner> i'll setup a test with master, but fwiw tweaking 2023.07.02 to add the bootph-all for sdmmc gets a little further. it now finds the node but then complains:

22:20 <tlwoerner> unable to select a mode

22:20 <tlwoerner> spl: mmc init failed with error: -524

22:20 <tlwoerner> as they say: a different error message still represents progress ;-)

22:35 <tlwoerner> Kwiboo: wonderful! using master u-boot worked like a charm, no patches required

22:36 <tlwoerner> i seem to have a console issue with the Linux kernel. the heartbeat led is blinking happily, but there's no console on uart0

22:36 <tlwoerner> perhaps it's on uart2?

22:50 <tlwoerner> w00T!!! w00T!

22:51 <tlwoerner> there it is, brilliant! thanks for the help everyone