ikarso has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 264 seconds]
goliath has quit [Quit: SIGSEGV]
joeskb7 has quit [Ping timeout: 264 seconds]
joeskb7 has joined #u-boot
joeskb7 has quit [Ping timeout: 264 seconds]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
Peng_Fan has joined #u-boot
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
sakman has joined #u-boot
sakman has quit [Client Quit]
sakman has joined #u-boot
persmule has joined #u-boot
joeskb7 has joined #u-boot
thopiekar has quit [Quit: No Ping reply in 180 seconds.]
thopiekar has joined #u-boot
monstr has joined #u-boot
mckoan|away is now known as mckoan
ikarso has joined #u-boot
njha has joined #u-boot
sakman has quit [Ping timeout: 246 seconds]
thopiekar has quit [Ping timeout: 264 seconds]
thopiekar has joined #u-boot
<njha>
Hi! I'm trying to port u-boot to a new RISC-V chip. It currently crashes at "Cannot find uclass for id 118", which I think is UCLASS_SYSCON by using line numbers... but I'm increasingly less sure that this is the problem as I look into it more.
<njha>
oh wait I added a debug() right before that and that is actually not it 💀
<njha>
it is UCLASS_SYSINFO, but that actually also doesn't make sense
sszy has joined #u-boot
<njha>
oh wait that does make sense, just need to turn that on in config.. aaaaa 😭
goliath has joined #u-boot
<marex>
hehe
<xypron>
njha: This crash looks like a missing dependency in Kconfig. Enabling Kconfig options for code consuming UCLASS_SYSCON should depend on CONFIG_(SPL_TPL_)SYSCON.
<xypron>
Do you know what is consuming syscon?
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
<xypron>
apalos: ^ In write_smbios_table() we consume UCLASS_SYSINFO but CONFIG_GENERATE_SMBIOS_TABLE does not depend on CONFIG_SYSINFO || CONFIG_X86 || CONFIG_QFW_SMBIOS.
<xypron>
apalos: wouldn't it be preferable to have separate symbols for each SMBIOS generator: CONFIG_SYSINFO_SMBIOS, CONFIG_X86_SMBIOS, CONFIG_QFW_SMBIOS.
<xypron>
apalos: maybe add CONFIG_DT_SMBIOS when generating from device-tree.
prabhakarlad has joined #u-boot
prabhakar has joined #u-boot
jmasson has joined #u-boot
mmu_man has joined #u-boot
<apalos>
xypron: the idea was to fallback if the sysinfo isnt there
<apalos>
That sysinfo got merged like 4 years ago, and we support like 13 platforms
<apalos>
So we ended up with 99.9% of the boards filling these values with "unknown" eveyrwhere
dsimic has quit [Ping timeout: 264 seconds]
dsimic has joined #u-boot
pedro_pt has joined #u-boot
mmu_man has quit [Ping timeout: 256 seconds]
mmu_man has joined #u-boot
<xypron>
apalos: The fallback to DT is not yet merged?
<apalos>
xypron: it is
<xypron>
apalos: But why do fail then on missing CONFIG_SYSCON?
<apalos>
basically it's a thin layer that tries to map sysinfo -> generic DT stuff
<xypron>
CONFIG_SYSINFO
<apalos>
fail on what ?
<xypron>
Did you see njha's messages
<apalos>
ah no sec
<apalos>
I am a bit confused, is it SYSCON or SYSINFO?
<xypron>
The last thing he wrote was UCLASS_SYSINFO
<apalos>
yea but the error message doesn't seem to come from the smbios code
<xypron>
But maybe that is only a noisy message
<apalos>
that error message comes from the uclass core, when trying to add a new uclass
<xypron>
write_smbios_table() calls uclass_first_device(UCLASS_SYSINFO, &ctx.dev) and the return value is ignored.
<apalos>
yea but that path doesn't seem to have that error message no ?
<apalos>
that error message is a debug in uclass_add()
<apalos>
ah it's called by uclass_get()
<apalos>
yea that seems like a bug in write_smbios_table()
<xypron>
It seems to be a debug message: debug("Cannot find uclass for id %d:...
<apalos>
but that runs even even the sysinfo uclass is not enabled
<apalos>
but why does it crash?
<apalos>
njha: what do you mean 'crashes'
<apalos>
Do you get an abort or the board freezes?
Hypfer7 has joined #u-boot
Hypfer has quit [Ping timeout: 264 seconds]
Hypfer7 is now known as Hypfer
sakman has joined #u-boot
haritz has quit [Remote host closed the connection]
haritz has joined #u-boot
haritz has quit [Changing host]
haritz has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
<qschulz>
can someone tell me the actual use-case for env_init()?
<qschulz>
I'm concerned about the modifications of gd->env_addr and gd->env_valid in env driver init callbacks
* marex
hides
<qschulz>
so, the thing is that env_init() goes through all env drivers without stopping
<qschulz>
so we could have one env driver setting gd->env_addr to let's say 0xbee
<marex>
qschulz: because there can be multiple, yeah
<qschulz>
BUT, env_load will stop at the first one
<qschulz>
for which gd->env_addr should have been 0xcaf
<qschulz>
soooooo what should env_init do, or rather, what should the .init callback check for
<qschulz>
marex: I see you were among the last ones to contribute things there :)
<marex>
I'm not here btw
prabhakarlad has joined #u-boot
<marex>
qschulz: that code is fragile terrible piece of ....
<qschulz>
the other option is to call the init again as part of the load/store/whatever callback needs to be called first
<marex>
qschulz: isnt env_init meant to point to builtin env at board_init_f (flash) stage ?
<marex>
while env_load is the thing which loads dynamic env while DRAM is already available, from storage ?
<qschulz>
marex: why would we go through such lengths? the builtin env can only be at one place in flasg no?
<marex>
qschulz: no ... consider this obscure use case
<marex>
qschulz: that board_init_f stage may be part of U-Boot (proper), which may run from two locations ( because it could be PIE executable ) -- either really flash , or e.g. some RAM because it was loaded via JTAG there and executed
<marex>
the board_init_f is kind-of a misnomer at that point, but you do get the idea
<marex>
it could even be that board_init_f is running from RAM, because U-Boot proper is running from RAM
<marex>
now ... at that point, going back to the example with JTAG
<marex>
in normal operation mode, which the board can detect, it is desirable the load the builtin env
<marex>
in JTAG boot, which may be some commissioning or manufacturing mode, it may be desirable to load some other env or no env at all
<marex>
that's why the lengths ... I think
<qschulz>
can we at least agree that modifying the global data pointer in env_driver.init() callback is incorrect?
<qschulz>
(so I don't have to keep this in the back of my mind during the rest of the discussion :) )