jclsn7 has quit [Quit: Ping timeout (120 seconds)]
jclsn7 has joined #u-boot
jclsn7 has quit [Ping timeout: 252 seconds]
jclsn7 has joined #u-boot
cbmuser_ has quit [Ping timeout: 250 seconds]
cbmuser_ has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
persmule has quit [Ping timeout: 240 seconds]
persmule has joined #u-boot
sbach has joined #u-boot
tpw_rules has quit [Ping timeout: 240 seconds]
tpw_rules has joined #u-boot
redbrain has quit [Ping timeout: 252 seconds]
persmule has quit [Ping timeout: 240 seconds]
persmule has joined #u-boot
sughosh has joined #u-boot
thopiekar has quit [Ping timeout: 250 seconds]
thopiekar has joined #u-boot
ekathva_ has joined #u-boot
ekathva_ has quit [Remote host closed the connection]
frieder has joined #u-boot
persmule has quit [Ping timeout: 240 seconds]
persmule has joined #u-boot
persmule has quit [Ping timeout: 240 seconds]
persmule has joined #u-boot
fdanis_away is now known as fdanis
mckoan|away is now known as mckoan
zibolo has joined #u-boot
matthias_bgg has joined #u-boot
sszy has joined #u-boot
Pali has joined #u-boot
m5zs7k has quit [Read error: Connection reset by peer]
m5zs7k_ has joined #u-boot
matthias_bgg has quit [Read error: Connection reset by peer]
m5zs7k_ is now known as m5zs7k
sughosh has quit [Read error: Connection reset by peer]
matthias_bgg has joined #u-boot
milkylainen has quit [Quit: Connection closed]
<jelle>
hey, is anyone around who's familiar with uboot's DMI implementation?
<jelle>
for the RPI on Fedora Server, all the exposed dmi fields are kinda useless and I'm wondering if uboot can set the correct fields from device tree
tnovotny has joined #u-boot
camus has quit [Ping timeout: 252 seconds]
camus has joined #u-boot
mmu_man has joined #u-boot
milkylainen has joined #u-boot
baltazar has quit [Ping timeout: 256 seconds]
baltazar has joined #u-boot
Zapy has quit [Ping timeout: 272 seconds]
Zapy has joined #u-boot
lucaceresoli has quit [Quit: Leaving]
<Tartarus>
jelle: poke xypron or sjg1 ? I feel like there's some "fun" around that kind of stuff
<Tartarus>
But early, no coffee and time for a meeting here.
prabhakarlad has quit [Quit: Client closed]
<apalos>
jelle: DMI specifically or the smbios part?
<jelle>
apalos: DMI but I think that comes from smbios.c right?
<apalos>
yea i think so
<apalos>
So I am kind of responsible :P
<jelle>
basically on the RPI with u-boot on Fedora Server it's: cat /sys/class/dmi/id/product_name => Unknown Product
<apalos>
you are referring to the "Unknown Product" values?
<apalos>
yea
<jelle>
cat /proc/device-tree/model => Raspberry Pi 3 Model B Rev 1.2
<apalos>
so there was a breakage a while ago
<apalos>
the tl;dr was that the smbios table was completely broken
<jelle>
oh yeah sorry, haven't tested it with u-boot main
<apalos>
the behavior is still the same
<apalos>
git show 70e80666f26a5
<jelle>
aha
<apalos>
so I kinda fixed the smbios generation, but was expecting vendors to go and fix the actual values
<apalos>
smbios_add_prop_si() is supposedly trying to read some values of the DT
mmu_man has quit [Ping timeout: 252 seconds]
<apalos>
specifically the "product"
<apalos>
so there's some logic plugged in already to match DT values <-> smbios values
<apalos>
I haven't looked into the actual DT though
<jelle>
aha! That's what I was wondering
<apalos>
So the fix I did was basically to add an annoying value for broken DT's
<apalos>
hoping someone will notice, patches welcome :D
<apalos>
but seriously now, maybe the values we search in the DT are wrong to begin with
<apalos>
./s/are wrong/might be wrong/
<jelle>
apalos: what values does it look in? As I also see 33041972727
<jelle>
although I have uboot 2021.10
<apalos>
manufacturer, product, version is what I can see on a quick read
<apalos>
oh and 'serial'
<apalos>
so if any of those are available as nodes, we'll go add them in the smbios tables
<jelle>
I don't see them :)
<apalos>
yea hence all the 'Unknown' garbage
<jelle>
so it sounds like this is something which can be supported, but needs some debugging so I'll setup a debug env :)
<apalos>
I'd start by looking at the DT first
<apalos>
maybe the parsting of those values are wrong from the uboot side to begin with
* jelle
was wondering which device tree values are looked at yeah
<apalos>
So if there's another node that identifies the device and it's part of the DT spec
<apalos>
we might want to change our parsing to that
<apalos>
it's been a while but iirc those used to be Kconfig values in u-boot
<jelle>
if it looks at the "model =" field in dts then there should be something hmmm
<apalos>
so it's matter of parseing the proper values
<apalos>
if it's supposed to be model instead of product we might as well change that
<apalos>
of alternatively check product -> if null -> check model
<jelle>
thanks for the information apalos, I guess I'll CC you when I have time to patch / test it?
<apalos>
sure
persmule has joined #u-boot
<jelle>
also wondering if systemd should be thaught about these "bad values" as hostnamectl now does not fall back to device tree
mmu_man has joined #u-boot
akaWolf has quit [Ping timeout: 252 seconds]
akaWolf has joined #u-boot
akaWolf has quit [Ping timeout: 252 seconds]
torez has joined #u-boot
marc2 has quit [Ping timeout: 250 seconds]
marc2 has joined #u-boot
YCN has joined #u-boot
<YCN>
Hi yall, I've been struggling with my uboot for a while now, basically what's happening is that I'm trying to boot my Linux kernel from emmc but nothing happens after "Starting kernel ..."
<YCN>
Basically I'm moving from IMX6s to IMX6d but that's not a really easy journey...
<YCN>
I'm able to flash my emmc fine, and now I'd like to boot from it, but then not really much
<YCN>
if some of you might have been through those troubles please give a sign to a desperate fellow !
persmule has quit [Ping timeout: 240 seconds]
akaWolf has joined #u-boot
<apalos>
jelle: I wouldn't do that, I don't see why systemd should understand firmware-specific strings
<jelle>
good point
persmule has joined #u-boot
<apalos>
otoh systemd is turing complete, so whatever floats their boat :D
tnovotny has quit [Quit: Leaving]
<Tartarus>
YCN: If you get nothing after starting kernel.. check your bootargs to make sure you're giving the kernel a valid console, and then if needed, enable earlycon in the kernel
<Tartarus>
That message comes from Linux, not U-Boot, so we've handed things off
<YCN>
Tartarus: ok fair point, I'll try on that ! Normally the console is valid but I'll dig into that
<kettenis>
sjg1: oh, I may actually be able to attend this time
cambrian_invader has quit [Ping timeout: 250 seconds]
lucaceresoli has joined #u-boot
cambrian_invader has joined #u-boot
<YCN>
Tartarus : actually this line comes from uboot : ./arch/arm/lib/bootm.c: printf("\nStarting kernel ...%s\n\n"
zibolo has quit [Ping timeout: 252 seconds]
camus1 has joined #u-boot
camus has quit [Remote host closed the connection]
camus1 is now known as camus
<marex>
YCN: isnt mx6s and mx6d basically the same soc, with one core off ?
<marex>
YCN: which version of u-boot is that btw ?
<marex>
YCN: also, look at earlycon and earlyprintk (kernel bootargs) and matching EARLY_PRINTK in kernel config -> kernel debugging , that might give you extra hints what went wrong
redbrain has joined #u-boot
<YCN>
Yeah that supposed to be the same thing indeed
<YCN>
the only difference is supposed ot be the additionnal core, but there's really two family : (imx6solo + duallight) and (imx6quad + dual)
<YCN>
so stuff might differ a little more than that but yes that's not supposed to do that much differences
davlefou has quit [Ping timeout: 250 seconds]
<Tartarus>
YCN: er, right, yes, but it's what we do before kicking it out, more or less. The next lines should be kernel/decompressor
davlefou has joined #u-boot
ldevulder_ has joined #u-boot
ldevulder has quit [Ping timeout: 250 seconds]
mckoan is now known as mckoan|away
lucaceresoli has quit [Remote host closed the connection]
camus has quit [Remote host closed the connection]
camus has joined #u-boot
sobkas has quit [Ping timeout: 252 seconds]
camus has quit [Ping timeout: 240 seconds]
camus has joined #u-boot
sobkas has joined #u-boot
mszyprow has quit [Ping timeout: 252 seconds]
sobkas has quit [Client Quit]
sobkas has joined #u-boot
sobkas has quit [Ping timeout: 272 seconds]
sobkas has joined #u-boot
___nick___ has quit [Ping timeout: 252 seconds]
camus has quit [Remote host closed the connection]
camus has joined #u-boot
sobkas has quit [Ping timeout: 240 seconds]
mthall_ has quit [Ping timeout: 240 seconds]
mthall has joined #u-boot
macromorgan has quit [Quit: Leaving]
redbrain has quit [Ping timeout: 240 seconds]
mthall has quit [Ping timeout: 272 seconds]
lucaceresoli has quit [Ping timeout: 240 seconds]
mthall has joined #u-boot
Finde has joined #u-boot
<Finde>
I'm trying to understand, for FIT/ITB, is there a way to have a config that simply takes the FDT from the earlier boot stage, e.g. whatever was used and filtered by SPL, rather than having to package in the FDT?
<Finde>
I had a look at some of the examples under doc/uImage.FIT but couldn't see one representative of this case
mthall has quit [Ping timeout: 240 seconds]
lucaceresoli has joined #u-boot
darkapex has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<marex>
For the new multi component uImage format (FIT) addresses must be extended to include component or configuration unit name: addr:<subimg_uname> - direct component image specification addr#<conf_uname> - configuration specification Use iminfo command to get the list of existing component images and configurations.
<marex>
hmmmm ... well, run help bootm on your board , you will get that ^ with better formating
<marex>
notice the 'addr:<subimg_uname>' and 'addr#<conf_uname>' part
frieder has quit [Remote host closed the connection]
<marex>
For the new multi component uImage format (FIT) addresses must be extended to include component or configuration unit name: addr:<subimg_uname> - direct component image specification addr#<conf_uname> - configuration specification Use iminfo command to get the list of existing component images and configurations.
<marex>
hmmmm ... well, run help bootm on your board , you will get that ^ with better formating
<marex>
notice the 'addr:<subimg_uname>' and 'addr#<conf_uname>' part