All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel G. Clemmensen" <DanC@Zentropix.com>
To: Frank Przybylski <Frank.Przybylski@vas-gmbh.de>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Getting the image section of the ELF file to load w/ VxWorks boot ROM
Date: Tue, 09 May 2000 11:54:59 -0400	[thread overview]
Message-ID: <391834D3.9E57B710@Zentropix.com> (raw)
In-Reply-To: 3917E2A7.6EEDDD93@vas-gmbh.de


Frank Przybylski wrote:
>
> Hi,
> I had similar problems when loading kernel images with gdb over BDM into
> an MPC.
> I have no solution (which would be a patch to the Makefile in
> /usr/src/linux/arch/ppc/mbxboot) but I try to handle the symptons:
>   powerpc-linux-objcopy \
>     --set-section-flags=image=contents,alloc,load,readonly,data \
>     --adjust-section-vma=image=$(powerpc-linux-objdump -h
> $kernel/zvmlinux | grep .bss | awk '{print "0x"$4}') \
>     $kernel/zvmlinux \
>     $kernel/zvmlinux2
>
> The first command to objcopy is to set the 'load' flag for the image
> section. Without this, gdb won't load this section.
> The second is to patch the load address of that section to be the same
> as the .bss section. I'm a little bit unsecure about the last, but it
> seems to work. I think this is what the loader expects and I hope
> someone can verify this?
>

I was able to load successfully using a variant of the second method:
I used objcopy to remove the .bss section. This appears to also make the
zImage file smaller by 60,000 bytes or so. I checked the boot code and
determined that this method WILL work if the zImage is NOT initially loaded
into the location is linked for, and WILL NOT work if the zImage IS initially
loaded into the location it is linked for. The reason: The code really does
use the location the .bss section is linked to store read/write variables.
If the image section is physically at that location, it will be damaged.
But,the code then moves itself, but not the image, to its origin location,
and then decompresses the image from its load location to its own origin location.
All of this works just fine, since in this case the image is never resident in the
compiled-in .bss location.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2000-05-09 15:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-02 17:24 Getting the image section of the ELF file to load w/ VxWorks boot ROM diekema_jon
2000-05-03  8:07 ` Arto Vuori
2000-05-09 10:04 ` Frank Przybylski
2000-05-09 15:54   ` Daniel G. Clemmensen [this message]
2000-05-09 17:51     ` Getting the image section of the ELF file to load w/ VxWorks boot diekema_jon
2000-05-17 20:30   ` Getting the image section of the ELF file to load w/ VxWorks boot ROM Dan Malek

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=391834D3.9E57B710@Zentropix.com \
    --to=danc@zentropix.com \
    --cc=Frank.Przybylski@vas-gmbh.de \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.