* Re: [hppa-linux] Booting issues.
@ 1999-02-16 16:32 Jason Eckhardt
1999-02-16 18:01 ` Alex deVries
1999-02-16 18:12 ` Richard J. Rauenzahn
0 siblings, 2 replies; 10+ messages in thread
From: Jason Eckhardt @ 1999-02-16 16:32 UTC (permalink / raw)
To: hppa-linux; +Cc: jason
>
> I was hoping someone could explain how booting works on HPs in the
> following ways:
>
> - booting from disk; is it possible to put our boot image onto an existing
> hpux disk, and boot from that image?
>
By "boot image" do you mean the bootstrap program or the kernel? I think
we could load the (future) kernel from an HPUX disk via HP's ISL, but it
would probably have to be in SOM format. Of course, I don't know for sure.
Over the weekend I got a simple bootstrap program up on a clean, non-HPUX
disk. It doesn't do much:
It simply prints a message "HPPA/Linux bootstrap version 0.00" and then
waits in a spin loop.
It is a small step in that I now understand the
boot process and can actually get the PDC to load and execute a bootstrap
code. There is a small assembly stub which sets up a C-friendly runtime
environment and then invokes a C subroutine to do I/O, etc.
I wrote a simple utility (like lifinit) which takes the bootstrap object,
prepends a LIF header, and then places it on the boot sector.
The next step is to get the simple bootstrap to load a kernel image. Maybe
someone can help me understand what to do next. Issues:
1. Should the bootloader be very simple and just load the kernel image
from a known place on the disk, such as immediately following the
bootstrap code (I believe the i386 version works this
way, correct me if I'm wrong) or should we instead load the kernel from
a Linux filesystem. The later
is a bit of a pain as it means we must have a standalone version
of a filesystem code in the bootloader (at least open, close, read,
seek, stat). The Mklinux works this way -- the boot code is huge...it
seems to me to be unnecessarily large and complex for a bootloader.
The first idea is much easier, since we just read from the already
open boot device (opened by the PDC) from a fixed location and then
branch to the kernel code.
Comments?
2. How are disks "partitioned" on HPs. The bootloader, if it uses the
scheme of loading the kernel from a linux filesystem, will have to
also "understand" the partition of the disk.
Does anyone know how the partitions are setup (i.e. partition table,
or equivalent)? Is the partition scheme imposed by hardware or
is this just a software convention?
Thanks for your help, jason.
----------------------------------------------------------------------
To unsubscribe: send e-mail to hppa-linux-request@puffingroup.com with
`unsubscribe' as the subject.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [hppa-linux] Booting issues.
1999-02-16 16:32 [hppa-linux] Booting issues Jason Eckhardt
@ 1999-02-16 18:01 ` Alex deVries
1999-02-16 19:01 ` Bill Katz
1999-02-16 18:12 ` Richard J. Rauenzahn
1 sibling, 1 reply; 10+ messages in thread
From: Alex deVries @ 1999-02-16 18:01 UTC (permalink / raw)
To: hppa-linux; +Cc: jason
On Tue, 16 Feb 1999, Jason Eckhardt wrote:
> > I was hoping someone could explain how booting works on HPs in the
> > following ways:
> > - booting from disk; is it possible to put our boot image onto an existing
> > hpux disk, and boot from that image?
>
> By "boot image" do you mean the bootstrap program or the kernel? I think
> we could load the (future) kernel from an HPUX disk via HP's ISL, but it
> would probably have to be in SOM format. Of course, I don't know for sure.
Well, I meant kernel, but that may not have ben what I should have been
asking.
What's SOM?
> Over the weekend I got a simple bootstrap program up on a clean, non-HPUX
> disk. It doesn't do much:
> It simply prints a message "HPPA/Linux bootstrap version 0.00" and then
> waits in a spin loop.
> It is a small step in that I now understand the
> boot process and can actually get the PDC to load and execute a bootstrap
> code. There is a small assembly stub which sets up a C-friendly runtime
> environment and then invokes a C subroutine to do I/O, etc.
> I wrote a simple utility (like lifinit) which takes the bootstrap object,
> prepends a LIF header, and then places it on the boot sector.
That's cool. You might also want to have a look at openbsd's mkboot
utility; I know it prepares the LIF header, although the details are a
little complex. I'll port it to Linux if you think it will help.
> The next step is to get the simple bootstrap to load a kernel image. Maybe
> someone can help me understand what to do next. Issues:
> 1. Should the bootloader be very simple and just load the kernel image
> from a known place on the disk, such as immediately following the
> bootstrap code (I believe the i386 version works this
> way, correct me if I'm wrong) or should we instead load the kernel from
> a Linux filesystem. The later
> is a bit of a pain as it means we must have a standalone version
> of a filesystem code in the bootloader (at least open, close, read,
> seek, stat). The Mklinux works this way -- the boot code is huge...it
> seems to me to be unnecessarily large and complex for a bootloader.
>
> The first idea is much easier, since we just read from the already
> open boot device (opened by the PDC) from a fixed location and then
> branch to the kernel code.
>
> Comments?
I'd say start with the first, then worry about the second later. Having
the boot loader be able to read ext2 would be cool, but large.
> 2. How are disks "partitioned" on HPs. The bootloader, if it uses the
> scheme of loading the kernel from a linux filesystem, will have to
> also "understand" the partition of the disk.
> Does anyone know how the partitions are setup (i.e. partition table,
> or equivalent)? Is the partition scheme imposed by hardware or
> is this just a software convention?
I'd much prefer to use the partitioning scheme of HP-UX for Linux disks,
particularly because this would let us install Linux on disks that already
had HPUX on them. However, just using pc-partitioning might be a quick
hack to make it work.
I imagine there's partition read code in either openbsd or mklinux.
- Alex
--
Alex deVries <puffin@redhat.com>
Red Hat Contrib Net maintainer
Ottawa, Canada
HPPA/Linux Porting Team
----------------------------------------------------------------------
To unsubscribe: send e-mail to hppa-linux-request@puffingroup.com with
`unsubscribe' as the subject.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [hppa-linux] Booting issues.
1999-02-16 18:01 ` Alex deVries
@ 1999-02-16 19:01 ` Bill Katz
0 siblings, 0 replies; 10+ messages in thread
From: Bill Katz @ 1999-02-16 19:01 UTC (permalink / raw)
To: hppa-linux
>
> On Tue, 16 Feb 1999, Jason Eckhardt wrote:
> > > I was hoping someone could explain how booting works on HPs in the
> > > following ways:
> > > - booting from disk; is it possible to put our boot image onto an existing
> > > hpux disk, and boot from that image?
> >
> > By "boot image" do you mean the bootstrap program or the kernel? I think
> > we could load the (future) kernel from an HPUX disk via HP's ISL, but it
> > would probably have to be in SOM format. Of course, I don't know for sure.
>
> Well, I meant kernel, but that may not have ben what I should have been
> asking.
>
> What's SOM?
Spectrum Object Module. The format of PA-RISC executables. It dates
from the early days, when the project to produce the "HP Precision
Architecture" was known as the "SPectrum" project.
> > The next step is to get the simple bootstrap to load a kernel image. Maybe
> > someone can help me understand what to do next. Issues:
> > 1. Should the bootloader be very simple and just load the kernel image
> > from a known place on the disk, such as immediately following the
> > bootstrap code (I believe the i386 version works this
> > way, correct me if I'm wrong) or should we instead load the kernel from
> > a Linux filesystem. The later
> > is a bit of a pain as it means we must have a standalone version
> > of a filesystem code in the bootloader (at least open, close, read,
> > seek, stat). The Mklinux works this way -- the boot code is huge...it
> > seems to me to be unnecessarily large and complex for a bootloader.
> >
> > The first idea is much easier, since we just read from the already
> > open boot device (opened by the PDC) from a fixed location and then
> > branch to the kernel code.
> >
> > Comments?
>
> I'd say start with the first, then worry about the second later. Having
> the boot loader be able to read ext2 would be cool, but large.
HPUX uses the second approach, and if there is a goal to allow Linux
and HPUX to reside on the same physical mechanism, you'd need to
duplicate that facility in the Linux secondary loader. One could
then include both the HPUX and Linux secondary loaders in the LIF
volume, and boot wither from the BootROM command line. We call
that the BCH or Boot Console Handler.
-Bill
----------------------------------------------------------------------
To unsubscribe: send e-mail to hppa-linux-request@puffingroup.com with
`unsubscribe' as the subject.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [hppa-linux] Booting issues.
1999-02-16 16:32 [hppa-linux] Booting issues Jason Eckhardt
1999-02-16 18:01 ` Alex deVries
@ 1999-02-16 18:12 ` Richard J. Rauenzahn
1999-02-16 18:47 ` Michael Marxmeier
1 sibling, 1 reply; 10+ messages in thread
From: Richard J. Rauenzahn @ 1999-02-16 18:12 UTC (permalink / raw)
To: hppa-linux; +Cc: jason
> 2. How are disks "partitioned" on HPs. The bootloader, if it uses the
> scheme of loading the kernel from a linux filesystem, will have to
> also "understand" the partition of the disk.
> Does anyone know how the partitions are setup (i.e. partition table,
> or equivalent)? Is the partition scheme imposed by hardware or
> is this just a software convention?
Software convention. Pre 10.x, people used whole disks, after 10.x we
have Logical Volume Manager which lets you put a set of disks into a
Volume Group and create Logical Volumes using the space within that
Volume Group. You then newfs the Logical Volumes..
/dev/vg01/lvol1
/dev/vg01/rlvol1
...
A logical volume might span one disk, or multiple disks, or stripe
across all the disks.. and you can extend the filesystems later, and
they don't have to be contiguous. Pretty handy -- I've wished Linux had
it as I hate PC partition schemes that aren't resizable..
I'm not sure how the root directory logical volume is handled -- I
believe it has to be the first volume on the root volume group, and has
to be contiguous.
Rich
----------------------------------------------------------------------
To unsubscribe: send e-mail to hppa-linux-request@puffingroup.com with
`unsubscribe' as the subject.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [hppa-linux] Booting issues.
1999-02-16 18:12 ` Richard J. Rauenzahn
@ 1999-02-16 18:47 ` Michael Marxmeier
0 siblings, 0 replies; 10+ messages in thread
From: Michael Marxmeier @ 1999-02-16 18:47 UTC (permalink / raw)
To: hppa-linux; +Cc: jason
> Software convention. Pre 10.x, people used whole disks, after 10.x we
> have Logical Volume Manager which lets you put a set of disks into a
> Volume Group and create Logical Volumes using the space within that
> Volume Group. You then newfs the Logical Volumes..
>
> /dev/vg01/lvol1
> /dev/vg01/rlvol1
For older systems (read pre-LVM) fixed partitions (calls "sections")
were used which were defined in /etc/disktab and hard-coded
in the driver. With the LVM this has changed.
AFAIR only a small boot area (/stand) or for other configurations
the root file system is required to be in hfs format and must be
contiguous. There should be a pointer towards it somewhere in the
LVM data structures. All other file systems can be VxFS.
> A logical volume might span one disk, or multiple disks, or stripe
> across all the disks.. and you can extend the filesystems later, and
> they don't have to be contiguous. Pretty handy -- I've wished Linux had
> it as I hate PC partition schemes that aren't resizable..
It has. http://linux.msede.com/lvm (alpha code)
> I'm not sure how the root directory logical volume is handled -- I
> believe it has to be the first volume on the root volume group, and has
> to be contiguous.
Yes.
Michael
--
Michael Marxmeier Marxmeier Software GmbH
E-Mail: mike@msede.com Besenbruckstrasse 9
Voice : +49 202 2431440 42285 Wuppertal, Germany
Fax : +49 202 2431420 http://www.msede.com/
----------------------------------------------------------------------
To unsubscribe: send e-mail to hppa-linux-request@puffingroup.com with
`unsubscribe' as the subject.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [hppa-linux] Booting issues.
@ 1999-02-16 1:48 Alex deVries
1999-02-16 6:06 ` Bill Katz
0 siblings, 1 reply; 10+ messages in thread
From: Alex deVries @ 1999-02-16 1:48 UTC (permalink / raw)
To: hppa-linux
I was hoping someone could explain how booting works on HPs in the
following ways:
- booting from disk; is it possible to put our boot image onto an existing
hpux disk, and boot from that image?
- booting over the network: if I understand correctly, my 715 can't do
bootp, but does some other sort of network protocol. What is it? I'm
told mklinux had a server hacked that could handle this, what is it, and
where do we get it?
- Alex
--
Alex deVries <puffin@redhat.com>
Red Hat Contrib Net maintainer
Ottawa, Canada
HPPA/Linux Porting Team
----------------------------------------------------------------------
To unsubscribe: send e-mail to hppa-linux-request@puffingroup.com with
`unsubscribe' as the subject.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [hppa-linux] Booting issues.
1999-02-16 1:48 Alex deVries
@ 1999-02-16 6:06 ` Bill Katz
1999-02-16 17:18 ` Alex deVries
0 siblings, 1 reply; 10+ messages in thread
From: Bill Katz @ 1999-02-16 6:06 UTC (permalink / raw)
To: hppa-linux
>
>
> I was hoping someone could explain how booting works on HPs in the
> following ways:
>
> - booting from disk; is it possible to put our boot image onto an existing
> hpux disk, and boot from that image?
It certainly should be. A few notes on the booting process:
The bootROM, known as PDC only knows:
How to move bytes in from the disk (it starts at the beginning), to
look thorugh those first bytes, and find the header for a LIF volume,
and to launch a program. The program usually launched is ISL.
ISL knows more about LIF volumes, and can read an AUTOEXECUTE file
(a text file, call "AUTO" that contains the commands to execute
to boot. In the case of HPUX, it reads typically reads and executes
a file called "HPUX" which is the secondary loader. Note that
with in HP this loader is often called "mongoose".
WHen we want to make a dual boot system, we can include both HPUX
and LILO (for instance) in the LIF volume, and then launch either
operating system.
HPUX know about the hpux file systems, and is able to find /hp-ux,
/stand/vmunix, or /linux-kernel or any other file within the
file system. To use this as a method of booting Linux, Linux
may need to be taught about hte hpux file system. Or at least
somehow know how to find another partition.
>
> - booting over the network: if I understand correctly, my 715 can't do
> bootp, but does some other sort of network protocol. What is it? I'm
> told mklinux had a server hacked that could handle this, what is it, and
> where do we get it?
THe protocol is called RMP, and the requests are normally handled
by rbootd. From the rbootd man page:
+ RMP/BOOTP:
The RMP clients are the older s700 workstations and all DTCs:
workstations: 705, 710, 715, 720, 725, 730, 735, 750, 755
The BOOTP clients are the s712 and future workstations.
I don't know where to get documents on this protocol, but there
must be something around.
-Bill
----------------------------------------------------------------------
To unsubscribe: send e-mail to hppa-linux-request@puffingroup.com with
`unsubscribe' as the subject.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [hppa-linux] Booting issues.
1999-02-16 6:06 ` Bill Katz
@ 1999-02-16 17:18 ` Alex deVries
1999-02-16 18:23 ` Bill Katz
1999-02-16 18:35 ` Richard J. Rauenzahn
0 siblings, 2 replies; 10+ messages in thread
From: Alex deVries @ 1999-02-16 17:18 UTC (permalink / raw)
To: hppa-linux
On Mon, 15 Feb 1999, Bill Katz wrote:
> ISL knows more about LIF volumes, and can read an AUTOEXECUTE file
> (a text file, call "AUTO" that contains the commands to execute
> to boot. In the case of HPUX, it reads typically reads and executes
> a file called "HPUX" which is the secondary loader. Note that
> with in HP this loader is often called "mongoose".
Right. We should look at getting Linux to be able to write to LIF
volumes. I imagine the structure is reasonably simple.
How do you write to a LIF volume from hpux right now?
> HPUX know about the hpux file systems, and is able to find /hp-ux,
> /stand/vmunix, or /linux-kernel or any other file within the
> file system. To use this as a method of booting Linux, Linux
> may need to be taught about hte hpux file system. Or at least
> somehow know how to find another partition.
That shouldn't be too difficult; I'm told HPUX uses BSD 4.2 filesystems,
which I think we have drivers for already.
Thanks for the pointers.
- Alex
--
Alex deVries <puffin@redhat.com>
Red Hat Contrib Net maintainer
Ottawa, Canada
HPPA/Linux Porting Team
----------------------------------------------------------------------
To unsubscribe: send e-mail to hppa-linux-request@puffingroup.com with
`unsubscribe' as the subject.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [hppa-linux] Booting issues.
1999-02-16 17:18 ` Alex deVries
@ 1999-02-16 18:23 ` Bill Katz
1999-02-16 18:35 ` Richard J. Rauenzahn
1 sibling, 0 replies; 10+ messages in thread
From: Bill Katz @ 1999-02-16 18:23 UTC (permalink / raw)
To: hppa-linux
>
> On Mon, 15 Feb 1999, Bill Katz wrote:
> > ISL knows more about LIF volumes, and can read an AUTOEXECUTE file
> > (a text file, call "AUTO" that contains the commands to execute
> > to boot. In the case of HPUX, it reads typically reads and executes
> > a file called "HPUX" which is the secondary loader. Note that
> > with in HP this loader is often called "mongoose".
>
> Right. We should look at getting Linux to be able to write to LIF
> volumes. I imagine the structure is reasonably simple.
>
> How do you write to a LIF volume from hpux right now?
Typically you build a LIF volume in an ordinary UNIX file using
the LIF utilities: lifinit, lifcp, lifls, etc. The following
script builds a bootable LIF for offline diagnostics:
#! /bin/ksh -x
LIF_FILE=uxbootlf
/bin/rm -f $LIF_FILE
lifinit `./iplopt ISL` -v8000000 -d32 -nL2DIAG -K2 -s4096 $LIF_FILE
lifcp -r -T-12800 -K2 ISL $LIF_FILE:ISL
lifcp -r -T-12289 -K2 AUTO $LIF_FILE:AUTO
lifcp -r -T-12928 -K2 HPUX $LIF_FILE:HPUX
lifcp -r -T-12960 -K2 ODE $LIF_FILE:ODE
lifcp -r -T-12277 -K2 MAPFILE $LIF_FILE:MAPFILE
lifcp -r -T-12280 -K2 SYSLIB $LIF_FILE:SYSLIB
lifcp -r -T-12276 -K2 SLMOD $LIF_FILE:SLMOD
liffcp -r -T-12279 -K2 LASIDIAG $LIF_FILE:LASIDIAG
lifcp -r -T-12279 -K2 L2DIAG $LIF_FILE:L2DIAG
lifcp -r -T-12279 -K2 MAPPER $LIF_FILE:MAPPER
Notice that there are different file types specified by the "-T"
switch to lifcp. The types for ISL, AUto (and the rest, for that
matter) are important.
ISL must be the first thing in the lif.
> > HPUX know about the hpux file systems, and is able to find /hp-ux,
> > /stand/vmunix, or /linux-kernel or any other file within the
> > file system. To use this as a method of booting Linux, Linux
> > may need to be taught about hte hpux file system. Or at least
> > somehow know how to find another partition.
>
> That shouldn't be too difficult; I'm told HPUX uses BSD 4.2 filesystems,
> which I think we have drivers for already.
I believe the HPUX HFS is basically the BSD fast file system. Obviously
the JFS, which is the Veritas journalled file system is different.
I believe 10.3 (which was never released for workstations) and 11.0
are the only versions that know how to boot from JFS.
>
> Thanks for the pointers.
>
Anything I can do to help.
-Bill
----------------------------------------------------------------------
To unsubscribe: send e-mail to hppa-linux-request@puffingroup.com with
`unsubscribe' as the subject.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [hppa-linux] Booting issues.
1999-02-16 17:18 ` Alex deVries
1999-02-16 18:23 ` Bill Katz
@ 1999-02-16 18:35 ` Richard J. Rauenzahn
1 sibling, 0 replies; 10+ messages in thread
From: Richard J. Rauenzahn @ 1999-02-16 18:35 UTC (permalink / raw)
To: hppa-linux
> Right. We should look at getting Linux to be able to write to LIF
> volumes. I imagine the structure is reasonably simple.
>
> How do you write to a LIF volume from hpux right now?
The tools are included in the OS..
$ man -k lif
instl_combine(1M) - Combine a LIF file and file system for use on CD-ROM
lif(4) - logical interchange format description
lifcp(1) - copy to or from LIF files
lifinit(1) - write LIF volume header on file
lifls(1) - list contents of a LIF directory
lifrename(1) - rename LIF files
lifrm(1) - remove a LIF file
> That shouldn't be too difficult; I'm told HPUX uses BSD 4.2 filesystems,
> which I think we have drivers for already.
They probably were referring only to HFS filesystems (which is the only
FS we support booting the kernel off of). I suspect JFS (Journaled)
(a.k.a. VXFS (Veritas)) is nothing like BSD 4.2.
> Thanks for the pointers.
May none of them be null =-)
Rich
----------------------------------------------------------------------
To unsubscribe: send e-mail to hppa-linux-request@puffingroup.com with
`unsubscribe' as the subject.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~1999-02-16 19:01 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1999-02-16 16:32 [hppa-linux] Booting issues Jason Eckhardt
1999-02-16 18:01 ` Alex deVries
1999-02-16 19:01 ` Bill Katz
1999-02-16 18:12 ` Richard J. Rauenzahn
1999-02-16 18:47 ` Michael Marxmeier
-- strict thread matches above, loose matches on Subject: below --
1999-02-16 1:48 Alex deVries
1999-02-16 6:06 ` Bill Katz
1999-02-16 17:18 ` Alex deVries
1999-02-16 18:23 ` Bill Katz
1999-02-16 18:35 ` Richard J. Rauenzahn
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.