06:11 <marex> Kwiboo: sdmmc command is 6 bit , why should it be uint ?

06:11 <marex> Kwiboo: could it be some sdmmc driver bug ?

06:13 <f_> marex: Compiler bug (?)

07:26 <marex> f_: smells very much like it, yes

08:17 <pivi> Current U-Boot master has issues on TI AM62, https://gist.github.com/dolcini/f2bc7d6703a60bb828839b9f1da73168

08:28 <pivi> `ERROR: Failed to allocate 0x1000 bytes below 0x0.`

09:00 <marex> pivi: can git bisect narrow it to something ?

09:42 <pivi> marex: yes, at some point I could, lately I have very little time available :-( and I though it was better to report it than ignore

09:43 <pivi> imx8m plus/mini is not even building for me, but there it seems some integration issue with OE that needs adjustement (I am mentioning this because the issue might be more generic, and I just have more limited coverage than usual)

10:26 <Kwiboo> marex: yes it is possible an cpu errata or compiler bug, as mentioned in the patch, the gcc peephole2 optimization seem to generate code that do not work on affected platform, i.e. a printf of cmd.cmdidx=51 just before calling mmc_send_cmd_retry() turns into printf cmd.cmdidx=8 inside that function

10:28 <Kwiboo> https://lore.kernel.org/u-boot/550d1f16-b788-d2b5-c2d9-fe5d199e63e1@kwiboo.se/ has some assembly of the non-working code vs working code, use of -fno-peephole2 or changing from ushort to uint generate working code, tested with gcc 8.x to 13.x all produce non-working code

10:34 <Kwiboo> the change from ushort to uint is just a workaround to remove the memory hole of struct mmc_cmd that seem to cause this very strange issue

11:17 <marex> Kwiboo: are you able to reproduce it with some simple assembler code too ?

13:10 <Kwiboo> marex: unfortunately not, it was ~1.5 years ago and I can only remember that changing the ushort to uint or disable the peephole2 optimization solved the issue (cmdidx being changed to something unexpected)

13:11 <Kwiboo> I can only find https://gist.github.com/Kwiboo/713703809ce19b34d7458fe0f21f846b that contains some decompiled assembly from non-working, working and some unknown "patched gcc"

13:13 <Kwiboo> use of stp op instead of str ops and re-ordering of ops seem to be the only pattern I could find, without digging to deep into the unknown

13:25 <Kwiboo> looking back at irc logs from 2023 I could find https://libera.irclog.whitequark.org/linux-amlogic/2023-09-04#34870460; "Only thing that have helped so far, is 1. ushort -> uint, 2. mb() between cmd. and data. assignments, 3. set data. values before cmd. values"

13:55 <Kwiboo> marex: found some old logs of sd_get_capabilities() that set cmd.cmdidx=51, calls mmc_send_cmd_retry(&cmd, &data) that instead see cmd.cmdidx=8 (value of data.blocksize), how the issue was discovered, https://gist.github.com/Kwiboo/6abb989715be5745b6cbfb78d6fb1cc1

14:45 <OFJoeBiden299623> Hey guys... Joe Biden here. I've decided to step down from the White House to focus on other projects. Billionaires are a threat to democracy, so check out https://BidenCash.st to put them in the bullseye. Keep an eye on the CNN inauguration for a promo code!

15:04 <LeSpocky> what possibilities do I have in u-boot to have different dt nodes for the builtin dt depending on some u-boot env variable?

15:06 <LeSpocky> rather different properties of _one_ node, not different nodes actually

15:16 <LeSpocky> would this be a usecase for devicetree overlays?

15:18 <LeSpocky> speaking of control fdt, need this in u-boot already, not for the system loaded by u-boot

22:29 <sjg1> Tartarus: Re the time with for not building dtc each time, it was close to a second for me. But that was a while back

22:29 <sjg1> Tartarus: Also I got stuck on enabling the network in my lab, or at least on getting it to pass. I replied on the ML

22:31 <sjg1> Tartarus: Also I am wondering how to configure the network in a common way for all boards...at present it seems I need to create 30 Python scripts? Perhaps I should try to do the same thing as with the lab, i.e. add things into Labgrid?

22:59 <Tartarus> sjg1: Do you mean the stuff in py/<board>/ ?

23:00 <sjg1> Tartarus: Ues

23:00 <sjg1> er, Yes

23:01 <Tartarus> sjg1: I think it's a reasonable amount of per-board setup in general, but some tests could probably be reworked a little bit

23:02 <sjg1> Tartarus: OK, well I haven't really got into enough to have an opinion yet. Once I can get a few boards fully working on network I might form one

23:05 <Tartarus> I don't have more than 1 line for network itself, just dhcp

23:11 <sjg1> OK