From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] lsxl: rework boot scripts
Date: Wed, 12 Mar 2014 19:42:49 -0400 [thread overview]
Message-ID: <20140312234249.GF16805@bill-the-cat> (raw)
In-Reply-To: <81a4c73f149ccbfad0c80bdde5f6464f@walle.cc>
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: <http://lists.denx.de/pipermail/u-boot/attachments/20140312/08a9e6b2/attachment.pgp>
next prev parent reply other threads:[~2014-03-12 23:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-12 18:42 [U-Boot] [PATCH 1/2] lsxl: use 64bit for LBA48 to support 4 TB drives Michael Walle
2014-03-12 18:42 ` [U-Boot] [PATCH 2/2] lsxl: rework boot scripts Michael Walle
2014-03-12 21:32 ` Tom Rini
2014-03-12 22:51 ` Michael Walle
2014-03-12 23:42 ` Tom Rini [this message]
2014-03-14 19:04 ` Michael Walle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140312234249.GF16805@bill-the-cat \
--to=trini@ti.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox