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 trini@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 trini@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.