All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Rumpf <prumpf@suse.de>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: Christopher Beard <cjbeard@istar.ca>, parisc-linux@thepuffingroup.com
Subject: Re: Building the Bootloader
Date: Tue, 1 Jun 1999 19:18:00 +0200	[thread overview]
Message-ID: <19990601191800.C25364@suse.de> (raw)
In-Reply-To: <199906011644.MAA25119@hiauly1.hia.nrc.ca>; from John David Anglin on Tue, Jun 01, 1999 at 12:44:46PM -0400

> If the IPL could be extracted from an ELF binary, then it could be produced
> on any system which supports cross compiling to HP/UX ELF format.

The problem (unless for the confused ones Christopher just showed the light)
is the GNU binutils seem to be buggy at the moment.

> There also seems to be some confusion about the kernel and its format.
> In order to debug it, it needs to be either an ELF or SOM binary with
> symbol tables, .stabs info, etc.

In practice, a System.map should be enough and we don't need to keep an ELF
binary on the disk.

> Although I haven't looked at the IPL, I would guess that it is designed to
> load an ELF binary.

It isn't. Currently the IPL is stored with a raw kernel image to load and
some pointers. Once we have something to boot, we can have a look at how
aboot and other bootloaders handle the situation (and steal their code of
course).

> > I haven't looked at this very closely, but when I attempted to generate a
> > raw binary of the bootloader code with the xcompiler/binutils it either
> > segfaulted or generated a 4 GB sparse file. There was a double free within
> > binutils which was fixed, and some minor version mismatches, but still, it
> > does not generate a working binary.

> Obviously, the bootloader will be a pain to debug.  I think that I have
> a working cross compiler running under hpux to produce ELF object files
> and binaries.  I had a problem with ld which went away when I rebuilt
> binutils with no optimization (-O0).

We need to get to the point where we can safely cross-compile for parisc machines
on i386. My experience with binutils / bfd is rather limited, so I wait for some-
one else to do it...

  reply	other threads:[~1999-06-01 17:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-01 15:58 Building the Bootloader Christopher Beard
1999-06-01 16:44 ` John David Anglin
1999-06-01 17:18   ` Philipp Rumpf [this message]
1999-06-01 18:05     ` John David Anglin
1999-06-01 19:31       ` Philipp Rumpf
1999-06-01 20:03         ` John David Anglin
  -- strict thread matches above, loose matches on Subject: below --
1999-06-01 20:44 Jason Eckhardt
1999-06-01 21:35 ` John David Anglin
1999-06-02 14:45   ` John David Anglin

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=19990601191800.C25364@suse.de \
    --to=prumpf@suse.de \
    --cc=cjbeard@istar.ca \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=parisc-linux@thepuffingroup.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 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.