<LeSpocky>
wyre: I've done exactly in the past, getting some binary images (e.g. ubi or kernel image) through tftp and write it to nand flash
<LeSpocky>
I had configured mtdparts before, then you need to erase the nand flash, tftp to some free memory area, and use nandwrite then
<LeSpocky>
I can look for actual examples tomorrow when I'm back at the office
<LeSpocky>
bbl
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #u-boot
matthias_bgg has quit [Ping timeout: 255 seconds]
<Wizzup>
win 45
<Wizzup>
oops... sor.y
milkylainen_ has joined #u-boot
LeSpocky has quit [Quit: reboot]
<xypron>
Hello Tom, concerning 12178b51c22d07 checkpatch.pl: Make fdt / initrd relocation disabling an error. Why should we relocate an initrd?
<xypron>
Tartarus ^
<xypron>
Relocation on HiFive Unmatched overwrites the U-Boot binary.
<Tartarus>
Yes, I've wondered what's going on with riscv as it's failing to sanely relocate device tree / initrd, when those aren't disabled.
<Tartarus>
It should obey bootm_size, etc, but instead somehow always ends up blowing up and failing
<Tartarus>
And the reason we do relocate initrd is similar to why we relocate device tree, we can often see overlap with the kernel+bss because everything got placed too close.
<xypron>
Tartarus: you mean the ramdisk_addr_r is sometimes poorly chosen?
<Tartarus>
Or not used
<Tartarus>
(Or not applicable)
<xypron>
But that is defined for the Hifive Unmatched
<Tartarus>
But, set that aside please.
<Tartarus>
The problem is relocation causes failure, right?
<xypron>
I simply want to boot my HiFive Unmatched with upstream U-Boot.
<xypron>
yes it relocates into the U-boot binary
<Tartarus>
It shouldn't do that.
<xypron>
relocaddr = 0x00000000fff60000
<xypron>
Moving Image from 0x84000000 to 0x80200000, end=81f11000
<Tartarus>
Check out on ARM, we relocate and not in to the U-Boot binary
<Tartarus>
Which is I think the missing crumb from when I tried to debug this a bit with pdp7 over on the beaglev slack, as it too was seeing that problem.
<Tartarus>
Figure out why it's relocating in to U-Boot and that'll solve a bunch of problems I bet, and let us drop those fdt_high=0xffffffff that all the riscv platforms have and that I really really wish I had seen at the time.
<Tartarus>
Yes, there are examples of arm platforms disabling it, but it's a boot time optimization.
<Tartarus>
Unmatched is disabling device tree relocation too, yes?
<xypron>
not yet
<xypron>
but when I disable it, I can boot
<xypron>
But why do you think U-Boot can figure out a better address the $ramdisk_addr_r?
<xypron>
than ...
<xypron>
I simply do not understand why we move anything.
<xypron>
It does not provide any benefit and costs time.
<Tartarus>
If you're using $ramdisk_addr_r then initrd_high=0xfffffff is fine, but that's not always case. I'm unsure how often even that is the case, and how many cases ramdisk_addr_r is really good enough.
<Tartarus>
Things are better than they used to be, in that final regard
<Tartarus>
But I think there's still boards coming in with bad copypasta addresses
<Tartarus>
That we still get new platforms coming in where kernel/device tree/ramdisk addresses are too close and lead to overlap and then only found because someone dug enough to see that it was overlapping, but since relocation was disabled, it wasn't fixed, is part of my concern here.
<Tartarus>
the last new platform I saw that on was 2 months ago?
<Tartarus>
Maybe a bit more, but still recently.
<Tartarus>
xypron: Looking at the unmatched addresses, that's a good example of why relocation is by default
<Tartarus>
"ramdisk_addr_r=0x88300000\0" \
<Tartarus>
"kernel_comp_addr_r=0x90000000\0" \
<Tartarus>
So we'll just go and uncompress the kernel into the middle of the ramdisk? Not a good idea :)
<xypron>
What is kernel_comp_addr_r used for?
<Tartarus>
Automatic decompression of Image.{gz,lzo,lz4,...}
<cambrian_invader>
couldn't we keep track of these with lmbs?
<cambrian_invader>
instead of trying and crashing?
<Tartarus>
I'm also not 100% sure if:
<Tartarus>
"kernel_addr_r=0x84000000\0" \
<Tartarus>
"fdt_addr_r=0x88000000\0" \
<Tartarus>
is enough space for maximal kernel image
<Tartarus>
cambrian_invader: Yes, that riscv crashes here is because there's a bug
<xypron>
Doesn't normally the kernel provide the decompression routine?
<Tartarus>
Possibly a missing lmb :)
<Tartarus>
xypron: No
<Tartarus>
aarch64/riscv did not copy the games arm32 does
<Tartarus>
Decompression is kicked up the chain instead.
<hanetzer>
Slimey: yo.
xypron has quit [Quit: xypron]
<Tartarus>
xypron: I want to point to https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/ti_armv7_common.h#L32 and note / lament that RISCV does not have the same level of detail in the kernel documentation about booting that arm/aarch64 do, but I'm still pretty sure 64MB for kernel is space before ramdisk is too small to be safe 100% of the time. But that may also depend on where the image must be relocated to, to actually
<Tartarus>
run, or at least what range that is (for KASLR stuff?)
<Tartarus>
All of that is still a tangent / aside to needing to see and fix why riscv will happily relocate the initrd in to U-Boot and thus crash the system.
xypron has joined #u-boot
jwillikers has quit [Remote host closed the connection]