<sjg1>
Tartarus: You have said for a while that we should have more defaults for boards / archs. I think that is a better approach than config fragments. After all, this is what Kconfig is designed to handle
<marex>
sjg1: I can see the use for config fragments, just maybe not in boards/ or all over the code base
<Tartarus>
And yes, I think it'll be a lot easier if we have the config fragments for a board in their board directory, rather than the top-level config directory
<Lightsword>
I'm trying to boot a fit image with a ramdisk over fastboot and am getting a "ERROR: new format image overwritten" error, I assume it's something related to misconfigured fastboot buffer address and/or the fit load/entry address https://gist.github.com/jameshilliard/bd58769419b4711a5e07799bf516c249 any ideas what I'm doing wrong here?
<marex>
Lightsword: $loadaddr is wrong and overlaps one of the /image node images address
<Lightsword>
marex, do I need to change the load address in the fit.its or somewhere else?
<marex>
yeah
<marex>
either that, or CONFIG_FASTBOOT_BUF_ADDR=0x12000000
<marex>
I believe they should not match
<marex>
you should be able to load the kernel anywhere within 128 MiB of start of DRAM on arm32
<Lightsword>
marex, hmm, so does double the ram get used that way, or is there a way to load directly from the fastboot buffer?, ie do I need a fastboot buffer in addition to a second copy when extracted from the buffer or something?
<Lightsword>
0x12000000 is the normal load address when not using fastboot so I assume I should change the fastboot buffer address maybe? would I put that at a higher address or something? not sure how to determine what to set that to
<marex>
afaict the fitImage is loaded at CONFIG_FASTBOOT_BUF_ADDR and then interpreted by the fit loading code in uboot which places the blob in the fitimage /images node to final destination address (load address)
<Lightsword>
marex, yeah, so I guess I just need to figure out how to calculate a high enough CONFIG_FASTBOOT_BUF_ADDR to not conflict with the images extracted to load address?
<marex>
Lightsword: isnt there some way to instruct fastboot to allocate the buffer memory on heap ?
<Lightsword>
marex, not sure, I didn't notice a way to do that
hanetzer has quit [Ping timeout: 245 seconds]
<marex>
Lightsword: might be a nice feature to add
hanetzer has joined #u-boot
torez has joined #u-boot
sng has joined #u-boot
soxrok2212 has quit [Ping timeout: 240 seconds]
sng has quit [Remote host closed the connection]
sng has joined #u-boot
torez has quit [Ping timeout: 264 seconds]
<Lightsword>
marex, so now I'm getting stuck at "Booting kernel.." after setting CONFIG_FASTBOOT_BUF_ADDR=0x20000000, any ideas why that might be?
jsmolic_ is now known as jsmolic
soxrok2212 has joined #u-boot
naoki has joined #u-boot
mmu_man has quit [Quit: reboot]
naoki has quit [Client Quit]
alan_o has quit [Remote host closed the connection]
alan_o has joined #u-boot
ikarso has joined #u-boot
camus has quit [Quit: camus]
mncheck has quit [Ping timeout: 250 seconds]
<Tartarus>
marex: I'm not happy with where the dts are either, honestly, but now that upstream seems to have sorted the ARM ones by vendor to match arm64...
<Tartarus>
dtsi files make things a little more complex, but I don't think that actual board dts files being in the board directory is a terrible idea at first
monstr has quit [Remote host closed the connection]
sng has quit [Ping timeout: 240 seconds]
sng has joined #u-boot
sng has quit [Read error: Connection reset by peer]
<Tartarus>
sjg1: Ah, well comparing with https://source.denx.de/u-boot/u-boot/-/jobs/655730 the problems are (a) some lack of dependencies within the tests, so that they should instead be skipped, maybe? And then some missing / wrong perms with the runner itself, as the network tests shouldn't be skipped
<Tartarus>
Or maybe the other skips are due to those failing tests
<Tartarus>
otoh, bill-the-cat is privileged = false so maybe not
<Tartarus>
What happens if you just run the tests on kaka, outside of gitlab?
matthias_bgg has quit [Quit: Leaving]
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
vagrantc has joined #u-boot
vagrantc has quit [Ping timeout: 246 seconds]
jaganteki has quit [Ping timeout: 246 seconds]
<sjg1>
Tartarus: I see that test_cat fails, for example, when run locally. I seem to have that problem a lot
<sjg1>
Tartarus: For the qemu-x86 tests "Valid Link not detected" with networking
<sjg1>
Tartarus: Re the configs, I didn't know about that. Is it documented somewhere?
<sjg1>
Tartarus: But yes, putting the files in a board dir makes sense
<sjg1>
Tartarus: Having said that, don't we first need to make these boards work with buildman and add some docs?
marc1 has quit [Ping timeout: 246 seconds]
marc1 has joined #u-boot
goliath has joined #u-boot
Leopold has quit [Ping timeout: 250 seconds]
Leopold has joined #u-boot
<Tartarus>
sjg1: Config fragments are not well documented, no, we do need to see if there's something we can borrow from linux about that, in general
<Tartarus>
But also no, I'm not going to hold up making use of fragments on figuring out what buildman needs, in order to start using them, so long as the base defconfigs build and are useful.
<Tartarus>
And I get "test/py/tests/test_net.py ..ss.s.s" for when I run those network tests on qemu-x86 locally
<Tartarus>
Which I think comes down to
<Tartarus>
SKIPPED [1] test/py/tests/test_net.py:136: No static network configuration is defined
<Tartarus>
which is right, we have dhcp set instead
<Tartarus>
and I just use the CI python config parts for qemu, locally
<Tartarus>
Or, ok, I take that back, I based py/bill-the-cat/u_boot_boardenv_qemu_x86_na.py on all my other boards so it too knows what files I have for tftpboot and their checksums
sng_ has joined #u-boot
sng has quit [Read error: Connection reset by peer]
Gravis has quit [Ping timeout: 245 seconds]
Gravis has joined #u-boot
sng_ has quit [Remote host closed the connection]
alpernebbi has quit [Read error: Connection reset by peer]