public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] lsxl: rework boot scripts
Date: Fri, 14 Mar 2014 20:04:00 +0100	[thread overview]
Message-ID: <201403142004.00451.michael@walle.cc> (raw)
In-Reply-To: <20140312234249.GF16805@bill-the-cat>

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

      reply	other threads:[~2014-03-14 19:04 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
2014-03-14 19:04         ` Michael Walle [this message]

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=201403142004.00451.michael@walle.cc \
    --to=michael@walle.cc \
    --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