Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2024.01 is OUT / Merge Window is OPEN, next branch is CLOSED / Release v2024.04 is scheduled for 02 April 2024 / Channel archives at https://libera.irclog.whitequark.org/u-boot
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> yea the call chain is
<apalos> uclass_first_device -> uclass_find_first_device -> uclass_get -> uclass_add
<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 :) )
iprusov has quit [Quit: WeeChat 3.5]
<sjg1> calebccff: OK it seems like a different problem. I filed this: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/17
iprusov has joined #u-boot
mmu_man has quit [Ping timeout: 246 seconds]
pedro_pt has quit [Quit: Client closed]
<marex> qschulz: lemme check
<marex> qschulz: you mean this ?
<marex> 340 if (ret == -ENOENT) {
<marex> 341 gd->env_addr = (ulong)&default_environment[0];
<marex> ^ ?
<qschulz> all the changes to gd
nohit has quit [Ping timeout: 268 seconds]
nohit has joined #u-boot
mmu_man has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
bswartz has quit [Remote host closed the connection]
jfsimon1981 has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
bswartz has joined #u-boot
Clamor has joined #u-boot
pedro_pt has joined #u-boot
thopiekar has quit [Quit: No Ping reply in 180 seconds.]
thopiekar has joined #u-boot
pedro_pt has quit [Quit: Client closed]
mmu_man has quit [Ping timeout: 276 seconds]
jmasson has quit [Remote host closed the connection]
<marex> qschulz: so yeah, I suspect env_init(void) should really be env_init(int *valid, uintptr_t *addr)
<marex> qschulz: and then the env core can decide what to do
<marex> qschulz: what do you think ?
<qschulz> I agree, the question is now what env_init should decide for the core :)
<qschulz> marex: also, some env init do set the redund stuff and all
<qschulz> gimme a sec, not sure I'm not lying for the last one
mmu_man has joined #u-boot
<qschulz> yes, that was not true
<qschulz> so yes I agree, but what should the core do then?
<qschulz> how should it decide which one to use for gd->env_addr?
<qschulz> probably the first one?
<qschulz> but there may be some work required in env drivers to make this work as well?
<qschulz> e.g. env/nand.c checks gd->env_valid for ENV_VALID/ENV_REDUND
<qschulz> in env_nand_save
rvalue has quit [Remote host closed the connection]
rvalue has joined #u-boot
<marex> qschulz: sec
<marex> qschulz: isnt there some env_get_location() calls ?
<qschulz> env_get_location returns an enum of boot medium TYPE
<qschulz> so not really an address or something
<qschulz> this is used with env_driver_lookup() which is used when trying to loop over all possible env drivers
<marex> qschulz: I think env_get_location() is used as the board-side selector of env storage
<marex> isnt it ?
<qschulz> arch_env_get_location yes
<marex> see end of board/renesas/stout/stout.c for example
<qschulz> but still only a **type**
<qschulz> so emmc and sd card should return ENVL_MMC for example
<marex> sigh
<marex> I see
<marex> qschulz: but I guess it could be extended ?
<qschulz> marex: i'm not too sure what we're talking about anymore tbh?
<qschulz> extended to do what?
<qschulz> why is env_get_location being discussed? it was more about env_init
<qschulz> the issue about doing changes in env_get_location is that it is called in many palces, simply to loop over all possible env "locations"
<qschulz> (which return an enum env_location which is basically just a type as I said earlier
<qschulz> do you have anything specific in mind?
stefanro has quit [Quit: Leaving.]
<marex> qschulz: because you could init only the env you care about, and you can find out which env to init by doing some env_get_location(), no ?
Stat_headcrabed has joined #u-boot
Stat_headcrabed has quit [Client Quit]
Stat_headcrabed has joined #u-boot
<qschulz> marex: I'm not too worried about my own case :)
<qschulz> I do override arch_env_get_location to only return one value, so this wouldn't impact me
<qschulz> But what I'm doing doesn't make the Rockchip maintainer too happy so I tried something else :)
<qschulz> which made me hit this code path, which I couldn't really make sense of
zsoltiv_ has joined #u-boot
mckoan is now known as mckoan|away
monstr has quit [Remote host closed the connection]
ikarso has joined #u-boot
<marex> qschulz: huh
<marex> qschulz: time to clean it up and document it once and for all ? :)
Stat_headcrabed has quit [Quit: Stat_headcrabed]
pbsds has quit [Ping timeout: 276 seconds]
pbsds has joined #u-boot
mmu_man has quit [Ping timeout: 264 seconds]
flyback has quit [Remote host closed the connection]
mmu_man has joined #u-boot
urja has joined #u-boot
flyback has joined #u-boot
sszy has quit [Ping timeout: 276 seconds]
mripard has quit [Quit: mripard]
Leopold has quit [Remote host closed the connection]
Clamor has quit [Ping timeout: 264 seconds]
Clamor has joined #u-boot
Leopold has joined #u-boot
sakman has quit [Ping timeout: 264 seconds]
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
sakman has joined #u-boot
sakman1 has joined #u-boot
sakman has quit [Ping timeout: 268 seconds]
sakman1 is now known as sakman
umbramalison has quit [Remote host closed the connection]
Clamor has quit [Ping timeout: 260 seconds]
umbramalison has joined #u-boot
Clamor has joined #u-boot
umbramalison has quit [Remote host closed the connection]
umbramalison has joined #u-boot
Leopold has quit []
thopiekar has quit [Ping timeout: 252 seconds]
___nick___ has quit [Ping timeout: 246 seconds]
thopiekar has joined #u-boot
Leopold has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
___nick___ has joined #u-boot
wyre has quit [Quit: ZNC 1.8.2 - https://znc.in]
wyre has joined #u-boot
___nick___ has quit [Ping timeout: 264 seconds]
ezulian has quit [Ping timeout: 264 seconds]
sakman1 has joined #u-boot
sakman has quit [Ping timeout: 264 seconds]
sakman1 is now known as sakman