[U-Boot] [RFC] implementation of generic distro configs

[Tom Rini <trini@ti.com>]

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).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131206/1de73ded/attachment.pgp>