On Mon, Mar 02, 2015 at 09:10:26AM -0800, Sören Brinkmann wrote:
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@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.
Only along with doing bootm_size so that however data is passed in, we make sure it ends up (a) not overlapping and (b) where the kernel will see it.