<njha>
apalos, xypron: It turns out that the SYSINFO thing just gets printed out in debug and wasn't the actual problem. The actual crash was unrelated (and I am still debugging).
<njha>
it's calling ofnode_find_subnode with a -1 node offset and subnode_name = "bios"... although I don't think there's a "bios" in my device tree
<njha>
oh and by crash I mean an assert fails (since node is -1) and then it tries to reset
<njha>
oh tat
joeskb7 has quit [Ping timeout: 264 seconds]
<njha>
*oh that wasn't so hard either, it was just SMBIOS shouldn't be enabled if I have none in hardware
joeskb7 has joined #u-boot
joeskb7 has quit [Client Quit]
mmu_man has quit [Ping timeout: 246 seconds]
<njha>
yay, u-boot boots :)
<njha>
now I just have to figure out how to compile it with Linux included in a way such that it can boot from memory
sakman has joined #u-boot
vfazio has quit [Remote host closed the connection]
sakman has quit [Ping timeout: 240 seconds]
Leopold has quit [Remote host closed the connection]
Leopold has joined #u-boot
sakman has joined #u-boot
persmule has quit [Remote host closed the connection]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
flyback has quit [Quit: Leaving]
flyback has joined #u-boot
flyback has quit [Remote host closed the connection]
flyback has joined #u-boot
flyback has quit [Remote host closed the connection]
flyback has joined #u-boot
flyback has quit [Remote host closed the connection]
flyback has joined #u-boot
flyback has quit [Remote host closed the connection]
flyback has joined #u-boot
sakman has quit [Ping timeout: 264 seconds]
camus has quit [Remote host closed the connection]
camus has joined #u-boot
sakman has joined #u-boot
Clamor has joined #u-boot
mmu_man has joined #u-boot
sakman has quit [Ping timeout: 256 seconds]
Stat_headcrabed has joined #u-boot
Stat_headcrabed has quit [Client Quit]
Stat_headcrabed has joined #u-boot
Stat_headcrabed has quit [Quit: Stat_headcrabed]
mmu_man has quit [Ping timeout: 276 seconds]
Stat_headcrabed has joined #u-boot
dlan has quit [Remote host closed the connection]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
camus has quit [Quit: camus]
ezulian has joined #u-boot
Clamor has quit [Ping timeout: 268 seconds]
Clamor has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
ezulian has quit [Remote host closed the connection]
goliath has joined #u-boot
Stat_headcrabed has joined #u-boot
dsimic has quit [Ping timeout: 256 seconds]
urja has quit [Read error: Connection reset by peer]
dsimic has joined #u-boot
Stat_headcrabed has quit [Quit: Stat_headcrabed]
urja has joined #u-boot
mmu_man has joined #u-boot
flokli has quit [Ping timeout: 268 seconds]
<apalos>
njha: it should crash with SMBIOS enabled though, even if nothing exists
<apalos>
Ifso if you can share
<apalos>
1. the u-boot config,
<apalos>
2. the DT
<apalos>
and try to pinpoint exactly where the crash is we should fix it
zsoltiv_ has quit [Ping timeout: 268 seconds]
flokli has joined #u-boot
flokli has quit [Client Quit]
Stat_headcrabed has joined #u-boot
persmule has joined #u-boot
persmule has quit [Remote host closed the connection]
<marex>
tlwoerner: what is your cluster size, 16k ?
<marex>
tlwoerner: I would expect if the env is in file, it should make no difference what the size is and whether it spans multiple clusters
<tlwoerner>
marex: i would have thought that too
<tlwoerner>
3 days ago
<tlwoerner>
will U-Boot tell me the cluster size? "mmc info" doesn't
<tlwoerner>
"fatinfo mmc 1:6" doesn't either
<marex>
tlwoerner: it is somewhere in fs/*fat*
<marex>
tlwoerner: grep for 'cluster' , I dont think it is exposed to users though
<marex>
but there is FS_FAT_MAX_CLUSTSIZE
<marex>
default is 64k , which should cover just about everything except for UFS with custom VFAT on it
<marex>
tlwoerner: try and write a file on that VFAT which is larger than cluster size and then 'load' it with the 'load' command and calculate its checksum, does it work ?
<tlwoerner>
my board (rock-3a) doesn't override the cluster size, and the default is 65k
<tlwoerner>
right, 64k
<tlwoerner>
any thoughts on the bootmeth ordering?
<marex>
tlwoerner: that is sjg1 topic
<tlwoerner>
it's the last step i need to get rauc working ;-)
<marex>
tlwoerner: so yeah, I havent used env in FAT because possible patent problems, but loading of files should use the same path, see if that works on your platform
<marex>
tlwoerner: which u-boot version is that ?
<tlwoerner>
2024.01, i think, yocto master
<tlwoerner>
i thought the FAT patents were safe now, due to time/age (expired?)
<marex>
tlwoerner: are they ? tbh there are better options, like ext, so why bother
<tlwoerner>
this board puts /boot in a FAT partition, then uses EXT4 for /
<tlwoerner>
for rauc a suggestion is to put the environment in the /boot partition (so there's only 1) then make 2 EXT4 partitions for the A/B
<tlwoerner>
so i'm just trying to fit rauc in with minimal changes
<CounterPillow>
the last FAT patent, US6286013, expired in 2013 apparently.
<marex>
tlwoerner: ugh
<marex>
four years before that there was a lawsuit
<marex>
so even if they were all expired, there simply are better options without this problem since ... years
<marex>
CounterPillow: thanks for the pointer though
<marex>
tlwoerner: can you try and load file from vfat + do a checksum with the 'load' command and see if that works for you ?
<tlwoerner>
yes it does, and it should. the fitImage is there and that loads fine (which i replicated by hand and crc32'd just to verify)
<tlwoerner>
but with the environment stored on the same filesystem, the system boots with a default environment, the rauc script adds a bunch more variables to the environment and saves it
<tlwoerner>
but when i print the environment (either in u-boot or in linux) there are variables missing. most of the new variables that the rauc scripts add aren't there, and the checksum is always bad
<tlwoerner>
in fact i think only 1 extra variable from rauc gets added
<tlwoerner>
wait, let me check something
<marex>
tlwoerner: try => setenv foo bar ; saveenv ; reset ... after reset do => printenv foo
<marex>
is that env variable there ? if so, maybe the updater corrupts the env ?
<tlwoerner>
marex: yes, interesting. if i do the steps of the script by hand, then reset, everything works
<tlwoerner>
although... when the script is done it doesn't reset, it loads+runs the linux kernel
<tlwoerner>
i've got other priorities now, but i'll investigate by poking at the script and seeing where the magic lies
<tlwoerner>
if only i could get the bootmeth ordering right...
<tlwoerner>
one work-around is to remove extlinux bootmeth handling
<tlwoerner>
marex: is there a way to get yocto to generate the initial env file with the correct CRC?
<marex>
tlwoerner: could it be the env magic is corrupted ?