From: Tom Rini Date: Wed, 12 Mar 2014 19:42:49 -0400 Subject: [U-Boot] [PATCH 2/2] lsxl: rework boot scripts In-Reply-To: <81a4c73f149ccbfad0c80bdde5f6464f@walle.cc> References: <1394649774-7361-1-git-send-email-michael@walle.cc> <1394649774-7361-2-git-send-email-michael@walle.cc> <20140312213234.GE16805@bill-the-cat> <81a4c73f149ccbfad0c80bdde5f6464f@walle.cc> Message-ID: <20140312234249.GF16805@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Mar 12, 2014 at 11:51:41PM +0100, Michael Walle wrote: > Hi Tom, > > Am 2014-03-12 22:32, schrieb Tom Rini: > >On Wed, Mar 12, 2014 at 07:42:54PM +0100, Michael Walle wrote: > > > >>Move addresses for kernel, ramdisk and fdt blob to own > >>variables. Add dtb > >>blob loading to all existing boot scripts, dtb filenames were > >>taken from > >>vanilla kernel. Introduce new boot script bootcmd_legacy, which > >>only loads > >>a kernel and a ramdisk. Make this the default boot script. This > >>should also > >>restore the behaviour of the original bootloader. > > > >How much memory do these platforms have? > > LS-CHLv2 has 64MB and LS-XHL has 256MB. The kernel_addr and > ramdisk_addr are the value which was also used in the original > bootloader. OK, so we don't have to worry about relocation to bad places... > >Having just spent a bunch of > >time issues about where to load what on TI platforms, I'm a little > >worried about some of the locations: > > > >>+ "kernel_addr=0x00100000\0" \ > > > >Below 32MB which isn't optimal. > > why is that? iirc the kernel is unpacked to 0x8000, isn't it? ok > there might be some problems unpacking the kernel. Documentation/arm/Booting in the kernel suggests above 32MB to avoid relocation. > >>+ "ramdisk_addr=0x00800000\0" \ > >>+ "fdt_addr=0x007f0000\0" \ > > > >This doesn't leave a whole lot of space for the kernel before > >overwriting either of these. > > I must admit i've never worried about where to put these. Any > suggestions? initrd at the end of the ram? although i'd like to keep > both platforms the same, eg. i'd take 64MB as the end of ram. Well, I guess it comes down to how much you worry about things like Fedora or SuSE running on the system. I'd suggest moving the above to 32MB/just below 32MB to allow a fairly bigish kernel to still work as that's one of the thing that will bite commodity distro kernels. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: