06:41 <hurricos> chenv TCR save.l ${reg_tcr}; setenv TSR 0xE0000000; chenv TSR save.l ${reg_tsr};

06:41 <hurricos> oops

18:15 <hurricos> I have two mpc85xx-based boards from the same vendor and the same year. One chooses not to relocate the fdt (I don't have the u-boot source for it), and one does (I do have the source for it).

18:16 <hurricos> Problem: the one which relocates it relocates it too high for the early Linux kernel to read the memory, thus causing a very early panic.

18:16 <hurricos> This u-boot does not care what I set fdt_high to. It uses something called lmb (I'm guessing linux memory somesuch?) to determine where to move the fdt to.

18:17 <hurricos> I'm thinking non-relocating board believes the fdt is within the bootm_mapsize, and relocating board believes it is not (thus moving it).

18:20 <hurricos> This u-boot does allow you to step through the bootm steps individually -- that is, `bootm start $addr $initrd $fdt`, `bootm loados`. So it is possible for me to avoid relocation entirely, but if relocation does not occur, u-boot on the relocating board believes it does not have enough space in the device tree to make changes / add nodes sa it needs to. (The changes made by both boards are very

18:20 <hurricos> similar.)

18:21 <hurricos> on that note, could someone help me understand what changes I could make to the fdt's layout to convince the bootloader it has enough space?

18:22 <hurricos> I know this must sound weird considering one would usually, you know, *rebuild* u-boot rather than playing footsie with a non-mainline vendor fork from '12.

19:05 <Tartarus> Alright, so, fdt_high=0xffffffff should just disable relocation, is that not working?

19:06 <Tartarus> Which is not a great thing to do, but can be useful in some situations

19:15 <hurricos> The U-boot verison is too old to check fdt_high; it doesn't even mention that string anywhere in the source: https://downloads.laboratoryb.org/dumps/AP3825i_10_41_21_0001.zip

19:16 <hurricos> (the .zip contains both a linux-2.6 tree and the U-boot tree in p102x_p1)

19:20 <hurricos> I might be able to avoid relocation if I could figure out which check common/image.c::boot_relocate_fdt is succeeding to suggest relocation on the non-working board (AP3825i) while failing to suggest relocation on the AP3710i

19:22 <hurricos> It would be enough for the AP3825i to want a greater CONFIG_SYS_FDT_PAD than AP3710i, but I don't have the source for the latter to verify

19:24 <hurricos> though I could probably disassemble each u-boot, find the same function in each and see if I can spot the difference in the inlined values

19:36 <Tartarus> Ah, hummmm

19:45 <hurricos> Is there an environment variable override for CONFIG_SYS_BOOTM_LEN?

19:45 <hurricos> Wait, yes, I think it's bootm_size; and CONFIG_SYS_BOOTMAPSZ is bootm_mapsize.

19:46 <hurricos> I just can't figure out why setting bootm_size would limit the amount of memory the Linux kernel would then be able to acquire later on, then.

19:50 <hurricos> I do have one board, AP330, which has CONFIG_SYSM_BOOTM_LEN set to 15M, yet it allocates all of its memory afterwards just fine. I guess bootm_size, if used as a variable override, might also affect what gets sent to the kernel. Let me check the fdt post-boot.

19:57 <hurricos> Yep, u-boot mangles in a memory { ... } to limit the amount of system memory. So if I can figure out a way to squash that I can just ignore this and use bootm_size

20:14 <marex> hurricos: note that u-boot is GPL, you can ask your vendor for matching sources

20:21 <hurricos> I had success with the WS-AP3825i only after 2 months; the WS-AP3710i has been EOL for much longer, so I doubt it :\

20:22 <hurricos> My goal is just to port OpenWrt; maintainers there also do not usually find rebuilding u-boot to be a palatable solution

20:22 <hurricos> I think I can hack through this by fixing up the memory node very early in the platform file

20:23 <hurricos> that should be it

20:24 <hurricos> marex: But yes, well noted. I only did get this far by using rights under the GPL, so I shouldn't be so dismissive.

23:03 <marex> oh well