On 12/06/2013 01:31 PM, Tom Rini wrote: > On Fri, Dec 06, 2013 at 08:28:04PM +0100, Albert ARIBAUD wrote: >> Hi Tom, >> >> On Fri, 6 Dec 2013 12:18:13 -0500, Tom Rini <tr...@ti.com> wrote: >> >>> On Fri, Dec 06, 2013 at 05:59:37PM +0100, Albert ARIBAUD wrote: >>>> Hi Tom, >>>> >>>> On Fri, 6 Dec 2013 10:48:50 -0500, Tom Rini <tr...@ti.com> wrote: >>>> >>>>> Hey all, >>>>> >>>>> I've been thinking. We've had a thread on i.MX platforms about fdt >>>>> being overwritten and needing to be moved to another address. And I've >>>>> also had an internal problem about fdt being overwritten. So, how about >>>>> as a rule of thumb we start setting fdt_high (in configs) to >>>>> memory-start + 512MiB, as that's the lowmem limit we should always have >>>>> available. This will fix the problem of BSS overwriting the DT, which >>>>> is the problem we won't catch in normal bootm/bootz usage. Thoughts? >>>> >>>> Not sure I'm getting the issue clear, and I would like to avoid (me and >>>> others) having to switch back and forth between threads. Can you sketch >>>> the failure scenario in a couple of lines? >>> >>> Sure. Lets take am335x_evm builds (so Beaglebone Black/White, etc). >>> If you start enabling all of the tracing options in the kernel (function >>> tracing, graphs, etc), you get an uncompressed kernel and BSS that will >>> use up the first ~16MiB of DDR. We default to placing the DT at about >>> 15MiB into memory. So the kernel runs, clears BSS and eats the DT. >>> System now hangs, and depending on debug options set you may or may not >>> see anything at all from the kernel. U-Boot couldn't detect this >>> failure because we don't know how big the kernel BSS is, only how big >>> the zImage is (and where it is) and how big the fdt is and where it is. >>> No overlaps, go ahead and run. >> >> Thanks. >> >> The only issue I have with the RFC is that the +512 MiB value will only >> work with targets which have more than 512 MiB DDR, right? But since >> you're suggesting this should be set in configs, you are only suggesting >> +512 MiB, and any target could actually specify a lower value as long as >> it's greater than or eqal to 16 MiB. Correct? > > fdt_high is only an upper bound on what we may relocate to (setting > aside the magic value of 0xffffffff which means no relocation). I just > confirmed this too: > U-Boot# bdi > ... > boot_params = 0x80000100 > DRAM bank = 0x00000000 > -> start = 0x80000000 > -> size = 0x40000000 > ... > U-Boot# setenv fdt_high 0xe0000000 > ... > U-Boot# bootz $loadaddr - $fdtaddr > Kernel image @ 0x80200000 [ 0x000000 - 0x3e5068 ] > ## Flattened Device Tree blob at 80f80000 > Booting using the fdt blob at 0x80f80000 > Loading Device Tree to bf62a000, end bf630d9a ... OK > > Of course, 0xbf62a000 is a bad address in that it won't be seen by the > kernel, but it was in the higher-than-we-have-memory-at limit I set.
I haven't really followed this thread since I just noticed it tangentially, but on Tegra... Since commit 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ" all Tegra boards define BOOTMAPSZ to influence where the DTB gets relocated. I wonder what's the benefit of using BOOTMAPSZ vs. defining a default value for $fdt_high? And couldn't you just move $fdt_addr_r high enough in RAM so even if the DTB wasn't relocated it'd never overlap BSS? Tegra's $kernel_addr_r and $fdt_addr_r are likely set up that way already, although I didn't check. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot