On Thu, Dec 05, 2013 at 08:18:10PM -0600, Dennis Gilmore wrote:
As a followup to http://lists.denx.de/pipermail/u-boot/2013-August/160080.html ive put together what i Think is a reasonable starting point for defining a unified set of features and options.
There are some things that really need some more work yet. mostly to do with austomatically loading of the dtb. All of these patches are currently enabled in Fedora's u-boot builds.
the wandboard in particular has received a lot of testing using sysboot command to load a extlinux.conf file. which did pick up bugs in teh pxe.c code early on. I would appreciate some feedback from a wider audience as we move to making this be a default configuration.
I think you've got the breakdown in relative locations wrong. And, per the email I sent out after this, I think we should start using fdt_high at least for its intended purpose, moving the DT out of the way of what we know about.
The breakdown I see in your series is (or similar):
- "fdt_addr_r=0x81100000\0" \
- "fdt_addr=0x81200000\0" \
- "pxefile_addr_r=0x81300000\0" \
- "kernel_addr_r=0x81400000\0" \
- "ramdisk_addr_r=0x83400000\0" \
Now the issues we have to deal with are: 1) zImage running into ramdisk. There's 32MiB here, so that's unlikely, hopefully, for a while at least. 2) When the zImage runs, it will unpack the kernel to top of memory and then BSS follows. You've only left ~17MiB for that, and that's iffy. When you start enabling function tracing and some other stuff, that's close, on a single platform image. I bet a multi-platform runs into the DT.
#2 is why the defaults on these platforms place the DT in memory after the kernel image, before the ramdisk. I think we can get a better situation out of this by saying the u-boot used parts (pxefile) are as low as we can (start of memory), throw in the reasonable size, then place the kernel, 32MiB gap, 1MiB gap for each DT (which I really hope is more than enough..), then the ramdisk.
This just leaves the worry of 32MiB for a kernel + BSS being an uncaught conflict. One could stop worrying about this, largely I think, if we set fdt_high to memory base + 512MiB and then do some corner case testing to make sure that we do not relocate on top of the end of a large ramdisk, and that the only cases which simply do not work are the cases where you flat out do not have enough memory for what you're trying to load (giant kernel + giant ramdisk on a nowadays-small 128MiB DDR system for example).