| Message ID | 1394649774-7361-2-git-send-email-michael@walle.cc |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Rini |
| Headers | show |
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? 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. > + "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. > + "bootcmd_legacy=ide reset " \ > + "&& ext2load ide ${hdpart} ${kernel_addr} " \ Add CONFIG_CMD_FS_GENERIC and just 'load' here and elsewhere (incl fatload).
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. > 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. > >> + "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. > >> + "bootcmd_legacy=ide reset " \ >> + "&& ext2load ide ${hdpart} ${kernel_addr} " \ > > Add CONFIG_CMD_FS_GENERIC and just 'load' here and elsewhere (incl > fatload). i'll have a look at it. thanks for the suggestions, -michael
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.
Am Donnerstag, 13. März 2014, 00:42:49 schrieb Tom Rini: > > >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. I've just looked at the load addresses. First, in case of the lsxl, neither initrd_high nor fdt_high is set to 0xffffffff. Therefore, the ramdisk and the fdt blob are relocated to the top of the ram. The kernel itself is relocated to whatever the uimage loadaddr is set to. In case of debian and the original uImage this is 0x8000 and both are zImages. So i can't do anything to avoid relocating in the decompressor again. So the only restrictions should be: - 0x00800000 - 0x00100000 = 7 MB for the kernel - 64 kB for the fdt Hope i get everything right :) I'll post an updated patch with the {fat,ext2}load replaced with load in the near future. -michael
diff --git a/include/configs/lsxl.h b/include/configs/lsxl.h index cc7a6ab..8f4f382 100644 --- a/include/configs/lsxl.h +++ b/include/configs/lsxl.h @@ -108,20 +108,43 @@ #define CONFIG_LOADADDR 0x00800000 #define CONFIG_BOOTCOMMAND "run bootcmd_${bootsource}" #define CONFIG_BOOTARGS "console=ttyS0,115200 root=/dev/sda2" + +#if defined(CONFIG_LSXHL) +#define CONFIG_FDTFILE "kirkwood-lsxhl.dtb" +#elif defined(CONFIG_LSCHLV2) +#define CONFIG_FDTFILE "kirkwood-lschlv2.dtb" +#else +#error "Unsupported board" +#endif + #define CONFIG_EXTRA_ENV_SETTINGS \ - "bootsource=hdd\0" \ + "bootsource=legacy\0" \ "hdpart=0:1\0" \ - "bootcmd_net=bootp 0x00100000 uImage " \ - "&& tftpboot 0x00800000 uInitrd " \ - "&& bootm 0x00100000 0x00800000\0" \ + "kernel_addr=0x00100000\0" \ + "ramdisk_addr=0x00800000\0" \ + "fdt_addr=0x007f0000\0" \ + "bootcmd_legacy=ide reset " \ + "&& ext2load ide ${hdpart} ${kernel_addr} " \ + "/uImage.buffalo " \ + "&& ext2load ide ${hdpart} ${ramdisk_addr} " \ + "/initrd.buffalo " \ + "&& bootm ${kernel_addr} ${ramdisk_addr}\0" \ + "bootcmd_net=bootp ${kernel_addr} uImage " \ + "&& tftpboot ${ramdisk_addr} uInitrd " \ + "&& tftpboot ${fdt_addr} " CONFIG_FDTFILE " " \ + "&& bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0" \ "bootcmd_hdd=ide reset " \ - "&& ext2load ide ${hdpart} 0x00100000 /uImage " \ - "&& ext2load ide ${hdpart} 0x00800000 /uInitrd " \ - "&& bootm 0x00100000 0x00800000\0" \ + "&& ext2load ide ${hdpart} ${kernel_addr} /uImage " \ + "&& ext2load ide ${hdpart} ${ramdisk_addr} /uInitrd " \ + "&& ext2load ide ${hdpart} ${fdt_addr} " \ + "/" CONFIG_FDTFILE " " \ + "&& bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0" \ "bootcmd_usb=usb start " \ - "&& fatload usb 0:1 0x00100000 /uImage " \ - "&& fatload usb 0:1 0x00800000 /uInitrd " \ - "&& bootm 0x00100000 0x00800000\0" \ + "&& fatload usb 0:1 ${kernel_addr} /uImage " \ + "&& fatload usb 0:1 ${ramdisk_addr} /uInitrd " \ + "&& fatload usb 0:1 ${fdt_addr} " \ + "/" CONFIG_FDTFILE " " \ + "&& bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0" \ "bootcmd_rescue=run config_nc_dhcp; run nc\0" \ "eraseenv=sf probe 0 " \ "&& sf erase " __stringify(CONFIG_ENV_OFFSET) \
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. Cc: Prafulla Wadaskar <prafulla@marvell.com> Signed-off-by: Michael Walle <michael@walle.cc> --- include/configs/lsxl.h | 43 +++++++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 10 deletions(-)