linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Paul Smith <paul@mad-scientist.us>
To: jwboyer@linux.vnet.ibm.com
Cc: Linuxppc-embedded@ozlabs.org
Subject: Re: Creating a wrapped zImage.initrd -- can't start the trampoline?
Date: Sat, 02 Aug 2008 08:55:12 -0400	[thread overview]
Message-ID: <1217681712.6390.35.camel@homebase.localnet> (raw)
In-Reply-To: <1217680550.2328.15.camel@localhost.localdomain>

On Sat, 2008-08-02 at 08:35 -0400, Josh Boyer wrote:

> It needs the vmlinux, dtb, and initrd in a single image.  The dtb is
> required for arch/powerpc ports.

We have a dtb that we were using with uboot.  We were hoping we could
continue to do that even with the trampoline: that is, get the dtb from
the bootloader, while leaving the kernel and initrd in the downloaded
image.  We have coded up the bootloader to provide this information on
the command line and I was kind of hoping the trampoline would just pass
it through when it booted the uncompressed kernel.

It just seems to make more sense to have the dtb tied to the
hardware/firmware.

Is this possible?  If not we can do it the other way around (I found the
right targets in the Linux build system for this, I think).

> > The bootloader downloads the image (tftp) and jumps to the start address
> > in the ELF image, and immediately takes an illegal instruction.  We have
> > set the bootloader to load the image at 0x00000000 and then we look
> > through the ELF image for the start address, which (using objdump) I can
> > see is the correct address for the _zimage_start symbol from crt0.S; in
> > our case it's 0x00400204.
> > 
> > When we use a debugger to look at what's loaded at that location, it's
> > just a whole slew of 0xa bytes... obviously not right.  Is the start
> > address not the offset from the start of the ELF image?  Should we be
> > loading the image somewhere else (the previous incarnation loaded it at
> > 0x0, so we just did that too)?
> 
> Load it at the link address.  Which is 4MiB.  A normal bootloader would
> have done that.  Then the wrapper code will uncompress your kernel to
> 0x0 for you.

Ah.  OK, that's good info.  We'll give that a go.

Thanks!

  reply	other threads:[~2008-08-02 12:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-02  2:40 Creating a wrapped zImage.initrd -- can't start the trampoline? Paul Smith
2008-08-02 12:35 ` Josh Boyer
2008-08-02 12:55   ` Paul Smith [this message]
2008-08-04 17:25 ` Grant Likely
     [not found]   ` <1217878996.29051.560.camel@psmith-ubeta.netezza.com>
2008-08-04 21:30     ` Grant Likely

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=1217681712.6390.35.camel@homebase.localnet \
    --to=paul@mad-scientist.us \
    --cc=Linuxppc-embedded@ozlabs.org \
    --cc=jwboyer@linux.vnet.ibm.com \
    /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;
as well as URLs for NNTP newsgroup(s).