[U-Boot] [PATCH] arm64: Add Xilinx ZynqMP support

[Sören Brinkmann]

On Mon, 2015-03-02 at 04:07PM +0100, Michal Simek wrote:
> On 03/02/2015 03:23 PM, Tom Rini wrote:
> > On Mon, Mar 02, 2015 at 09:24:45AM +0100, Michal Simek wrote:
> >> On 03/02/2015 08:32 AM, Michal Simek wrote:
> >>> On 02/27/2015 06:13 PM, Tom Rini wrote:
> >>>> On Tue, Feb 24, 2015 at 09:02:09AM +0100, Michal Simek wrote:
> >>>>
> >>>>> Add basic Xilinx ZynqMP arm64 support.
> >>>>> Serial and SD is supported.
> >>>>> It supports emulation platfrom ep108 and QEMU.
> >>>>>
> >>>>> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
> >>>> [snip]
> >>>>> +/* Miscellaneous configurable options */
> >>>>> +#define CONFIG_SYS_LOAD_ADDR		0x8000000
> >>>>> +
> >>>>> +/* Initial environment variables */
> >>>>> +#define CONFIG_EXTRA_ENV_SETTINGS \
> >>>>> +	"ethaddr=00:0a:35:00:01:22\0" \
> >>>>
> >>>> No, you can't hard-code an ethaddr in.
> >>>
> >>> ah yeah.
> >>>
> >>>>
> >>>>> +	"kernel_addr=0x200000\0" \
> >>>>> +	"initrd_addr=0xa00000\0" \
> >>>>> +	"initrd_size=0x2000000\0" \
> >>>>
> >>>> These are really close together.  And I imagine mirror the usual values
> >>>> on 32bit platforms.  Maybe it's time to move them around a bit for more
> >>>> space?
> >>>
> >>> Currently I haven't had any problem with these values but I just don't know
> >>> what will happen in future.
> > 
> > Right.  That's partly why I moved as much of the TI ARMv7 parts to the
> > Linux kernel defined limits a while back, people managed to bump into
> > overruns doing valid things.  I'd really like to see things default to
> > something closer to the defined limits to start with and avoid those
> > kind of problems a few years down the line.  8MB is fine for now but I
> > can see people running over that and going "why does my initrd boot
> > fail".
> 
> We will use FIT image and all these values won't be needed but
> they are need to be here.
> I have removed unused initrd_X in v2 because it is completely unused.

Well, I haven't used FIT images so far and don't see why I should. Can we
please put the initrd at the highest address amongst kernel, DT and
initrd? The initrd is most prone grow. My current one is beyond 100MB.
Let's just spread things out, there should be enough memory for this.

	Sören