umbramalison has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
camus has joined #u-boot
jclsn0 has quit [Ping timeout: 244 seconds]
camus1 has joined #u-boot
camus has quit [Ping timeout: 244 seconds]
camus1 is now known as camus
jclsn0 has joined #u-boot
jclsn0 has quit [Ping timeout: 246 seconds]
jclsn0 has joined #u-boot
jclsn0 has quit [Ping timeout: 246 seconds]
jclsn0 has joined #u-boot
jclsn0 has quit [Ping timeout: 255 seconds]
jclsn0 has joined #u-boot
jclsn0 has quit [Ping timeout: 246 seconds]
jclsn0 has joined #u-boot
jclsn07 has joined #u-boot
jclsn0 has quit [Ping timeout: 240 seconds]
jclsn07 has quit [Ping timeout: 255 seconds]
littlebobeep has quit [Ping timeout: 240 seconds]
camus has quit [Quit: camus]
jclsn07 has joined #u-boot
jclsn07 has quit [Ping timeout: 276 seconds]
jclsn07 has joined #u-boot
littlebobeep has joined #u-boot
akaWolf has quit [Ping timeout: 258 seconds]
akaWolf has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
marc2 has quit [Ping timeout: 260 seconds]
littlebobeep has joined #u-boot
vagrantc has quit [Quit: leaving]
zandar has quit [Quit: Leaving.]
akaWolf has quit [Ping timeout: 258 seconds]
littlebobeep has quit [Ping timeout: 240 seconds]
akaWolf has joined #u-boot
apritzel has joined #u-boot
apritzel has quit [Ping timeout: 240 seconds]
glembo has joined #u-boot
rvalue has quit [Ping timeout: 244 seconds]
zandar has joined #u-boot
<milkylainen>
How do I figure out what sets the mac address on a stm32mp1 dk2? Nothing in the env, nothing in the dtb(?), no randomized ethernet mac selected?
rvalue has joined #u-boot
littlebobeep has joined #u-boot
monstr has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
mmu_man has joined #u-boot
ccf has joined #u-boot
<ccf>
Hello, how to evaluate a boolean variable in u-boot shell? The variable is MYBOOL: '#define CONFIG_ENV_FLAGS_LIST_STATIC "MYBOOL:bw"' and I want test it. Is it just better to test for existance? Any ideas?
sszy has joined #u-boot
glembo54 has joined #u-boot
glembo54 has quit [Client Quit]
matthias_bgg has joined #u-boot
tre has joined #u-boot
marex has joined #u-boot
apritzel has joined #u-boot
___nick___ has joined #u-boot
prabhakarlad has joined #u-boot
sicelo has quit [Quit: Bye!]
sicelo has joined #u-boot
sicelo has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
sicelo has quit [Quit: Bye!]
sicelo has joined #u-boot
sicelo has joined #u-boot
sicelo has quit [Client Quit]
sicelo has joined #u-boot
sicelo has joined #u-boot
littlebobeep has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
persmule has quit [Remote host closed the connection]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
<milkylainen>
Hmm. If I only wanted output from a single section during boot, could I go default silent. Then !silent, do things, silent again? There is an option for silent taking immediate action iirc?
mmu_man has joined #u-boot
sicelo has quit [Quit: Bye!]
sicelo has joined #u-boot
sicelo has joined #u-boot
<ccf>
milkylainen: you could enable and disable the tx uart pin muxing :) ?
ccf has quit [Remote host closed the connection]
<milkylainen>
silent did work though. :)
Wouter0100 has joined #u-boot
<milkylainen>
silent through reloc, only silence u-boot and take action on env change. remove silent on cmd, set it again once done.
Wouter0100 has quit [Remote host closed the connection]
<cambrian_invader>
milkylainen: yeah, but doesn't the image builder know what types it needs?
prabhakarlad has quit [Quit: Client closed]
littlebobeep has quit [Ping timeout: 240 seconds]
<rfs613>
should a new memory controller driver go in drivers/ram or drivers/ddr? It seems there are DDR controllers in drivers/ram (eg. Octeon3), so I'm not clear what the distinction is. Any guidance?
tre has quit [Remote host closed the connection]
prabhakarlad has joined #u-boot
<vagrantc>
hrm. any news of firefly-rk3288 or other similar systems not booting with 2022.07-rc4? worked with 2022.04 ...
* vagrantc
fears a git bisect coming on
<rfs613>
vagrantc: you need to watch for those sneaky git bisects... the can come of nowhere and really cause a lot of headaches! :P
<cambrian_invader>
rfs613: I think it depends on whether it's UCLASS_RAM or not
<rfs613>
cambrian_invader: I had that thought too... but I see some UCLASS_RAM in drivers/ddr.. and there does not seem to be a UCLASS_DDR
<Tartarus>
rfs613: Sigh, should probably be consolidated, yes
<Tartarus>
rfs613: So, drivers/ram/ is using DM and uclass-ram which is the right path forward, drivers/ddr/ is older and while everything is hopefully migrated...
<rfs613>
Tartarus: ok thanks, so I will use drivers/ram
<rfs613>
Any preferences on where to store "calibration data" for DDR? I see some boards using header files, others place the magic numbers into device tree.
<cambrian_invader>
I thought it went into the board files?
<hanetzer>
cambrian_invader: board files are old hat
<cambrian_invader>
not for SPL :)
<hanetzer>
tru, but even then, you can use dts there; or of_plat :)
doppo_ has quit [Remote host closed the connection]
doppo has joined #u-boot
ad__ is now known as bigendian
sobkas has joined #u-boot
<rfs613>
Tartarus: related to that consolitation, maybe CONFIG_RAM should get renamed to CONFIG_DM_RAM for consistency with other DM settings?
doppo has quit [Quit: leaving]
doppo has joined #u-boot
<Tartarus>
rfs613: Ideally, "everything" uses DM and we don't need DM_FOO since there's no non-DM_FOO
<Tartarus>
(outside of SPL or something like that)
<rfs613>
Tartarus: sure, but right now each subsystem has a CONFIG_DM_xyz to enable it... my DDR driver was causing boot to fail without even getting probed... took me a while to realize it was missing CONFIG_RAM to enable DM UCLASS_RAM
behanw has quit [Quit: Connection closed for inactivity]
littlebobeep has joined #u-boot
apritzel has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
<rfs613>
is there a quick way to trace malloc() before relocation? bdinfo is reporting: