Re: [parisc-linux] ld problem workaround

Re: [parisc-linux] ld problem workaround

[Jason Eckhardt]

> Is there any reason not to let this stay in the kernel tree ? I think being able
> to make the necessary changes in the CVS tree instead of sending them to you would
> be convenient. (Or is the "official version" the CVS one ?)
>

  Currently I am behind a firewall and cannot use CVS through it. This
  will be remedied shortly. In any case, a slightly older version of the
  bootloader is in the CVS tree. The mentioned file is the newest version,
  though, and should probably be used instead.
  What code are you proposing to add to the bootloader? ext2 support is
  underway.
  Jason.

Re: [parisc-linux] ld problem workaround

[Philipp Rumpf]

>   What code are you proposing to add to the bootloader? ext2 support is
>   underway.

If it works, I propose to let it unchanged (of course, e2fs would be nice).
I concentrate on the kernel for now (and think we might get interrupt(ion)s
RSN).

Re: [parisc-linux] ld problem workaround

[Jason Eckhardt]

> On Thu, 6 May 1999, Philipp Rumpf wrote:
> > 
> > Where are the bootloader sources atm ?
> > 
>
> Jason's sources are at:
>
> ftp://puffin.external.hp.com/pub/parisc/src/boot_rel_0.2.tar.gz
>
> I'm not quite sure how complete they are.  The pain is that because of our
> lack of ELF32 in binutils these really need to be linked on an HPUX box.
>


  The source is fairly complete in the sense that the bootstrap can load
  a kernel image and transfer control to it. If we had a linux kernel, it could
  be booted today.
  The source can also be considered less
  than complete in that it just reads the kernel from a fixed location on
  the media -- for simplicity, to get linux up and running. Alex and
  chris have suggested (and this was a thought all along) to have the booter
  load the kernel from an ext2 file system. With more time, that can be
  done. It's a bit painful since it involves a stand alone extfs (read only)
  implementation. Hopefully, we can re-use much of the standard linux code,
  but I haven't thought about this in detail yet.

  Jason.

Re: [parisc-linux] ld problem workaround

[Ulrich Drepper]

Jason Eckhardt <jason@equator.com> writes:

> Hopefully, we can re-use much of the standard linux code,
>   but I haven't thought about this in detail yet.

Take a look at MILO, the Alpha bootloader.  No need to repeat the work.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: [parisc-linux] ld problem workaround

[Steve Ball]

SILO took the same approach, for the SPARC.

----------------------******-------------------
Steve Ball
NMT EE Department System and Network Admistrator

C/S 3392		|	Work: (505) 835-5330
Socorro, NM 87801	|	Shop: (505) 835-5923 (Solar Racing Shop)
hamster@arctic.nmt.edu	|       Home: (505) 835-6325 (South 335)
www.ee.nmt.edu/~hamster	|	www.nmt.edu/~nmtcaver

The secret of flying is simple: Throw yourself at the ground and miss.
Boy, backups sure are a lot faster since i linked /dev/st0 to /dev/null...
----------------------******-------------------


On 6 May 1999, Ulrich Drepper wrote:

> Jason Eckhardt <jason@equator.com> writes:
> 
> > Hopefully, we can re-use much of the standard linux code,
> >   but I haven't thought about this in detail yet.
> 
> Take a look at MILO, the Alpha bootloader.  No need to repeat the work.
> 
> -- 
> ---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
> Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
> Cygnus Solutions `--' drepper at cygnus.com   `------------------------
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
> 
> 

Re: [parisc-linux] ld problem workaround

[Martin K. Petersen]

>>>>> "Ulrich" == Ulrich Drepper <drepper@cygnus.com> writes:

Ulrich> Jason Eckhardt <jason@equator.com> writes:
>> Hopefully, we can re-use much of the standard linux code, but I
>> haven't thought about this in detail yet.

Ulrich> Take a look at MILO, the Alpha bootloader. 

Or SILO, the SPARC bootloader.

-- 
Martin Kasper Petersen			BOFH, IC1&2, Aalborg University, DK
mailto:mkp@SunSITE.auc.dk		http://SunSITE.auc.dk/~mkp/

Re: [parisc-linux] ld problem workaround

[Philipp Rumpf]

>   The source is fairly complete in the sense that the bootstrap can load
>   a kernel image and transfer control to it. If we had a linux kernel, it could
>   be booted today.

Is there any reason not to let this stay in the kernel tree ? I think being able
to make the necessary changes in the CVS tree instead of sending them to you would
be convenient. (Or is the "official version" the CVS one ?)

[parisc-linux] ld problem workaround

[Philipp Rumpf]

There is now an ugly workaround in the CVS tree that allows us to
use 0x8000 as kernel entry point.

Re: [parisc-linux] ld problem workaround

[Alex deVries]

On Thu, 6 May 1999, Philipp Rumpf wrote:

> There is now an ugly workaround in the CVS tree that allows us to
> use 0x8000 as kernel entry point.

So if I understand it correctly, we should be able to fix the bootloader
to jump to 0x8000 and actually load the kernel.

Chris, how far off that are we?

- Alex

Re: [parisc-linux] ld problem workaround

[Philipp Rumpf]

> > There is now an ugly workaround in the CVS tree that allows us to
> > use 0x8000 as kernel entry point.
> 
> So if I understand it correctly, we should be able to fix the bootloader
> to jump to 0x8000 and actually load the kernel.

The other way round preferably.

> Chris, how far off that are we?

Where are the bootloader sources atm ?

Re: [parisc-linux] ld problem workaround

[Alex deVries]

On Thu, 6 May 1999, Philipp Rumpf wrote:
> 
> Where are the bootloader sources atm ?
> 

Jason's sources are at:

ftp://puffin.external.hp.com/pub/parisc/src/boot_rel_0.2.tar.gz

I'm not quite sure how complete they are.  The pain is that because of our
lack of ELF32 in binutils these really need to be linked on an HPUX box.

The Puffin Group is working with HP to have a box called
puffinpa.external.hp.com to act first as an HPUX build machine to solve
the problem of not everyone having access to HPUX yet.

- Alex