[parisc-linux] A quick update

[parisc-linux] A quick update

[Alex deVries]

After an enormous amount of frustration (with fault only to me, I should
have thought that there was a second bootpserver on my network), the
kernel tree in CVS actually builds on HPUX.  This is really just Jason's
work glued into the kernel tree.

Next:

- we need an HPUX ld linker script to resolve the vmlinux building,
what's the format for this?

- we need to figure out why the bootloader gives an error when loading
the kernel into memory

- Alex

-- 
Alex deVries
Vice President of Engineering
The Puffin Group

Re: [parisc-linux] A quick update

[Jeffrey A Law]

  In message <3769F3AD.DF068942@thepuffingroup.com>you write:
  > - we need an HPUX ld linker script to resolve the vmlinux building,
  > what's the format for this?
No such animal that I'm aware of.

There is some rough ordering control using the space/subspace sort keys, but
you don't get absolute control over where stuff ends up in memory.

In what ways do you need to control the layout of stuff in memory?

jeff

Re: [parisc-linux] A quick update

[John David Anglin]

You probably want to use the same link options as Jason used for the IPL:

-N -R address.

The address specified should match the location where the kernel is
loaded into the LIF image.  The -N places the $DATA$ section after
the $CODE$ section in low memory.  The +n option that was being used
in the Makefile has the $DATA$ section in the 0x40000000 quadrant.  
This is wrong for the kernel.

After the kernel is built, take a look at where the sections start
in SOM executable.  Each section must be copied to its corresponding
starting address in the LIF image.  Space must be reserved for the bss
data if there is a section after it that contains necessary data.

Dave

> 
> 
> After an enormous amount of frustration (with fault only to me, I should
> have thought that there was a second bootpserver on my network), the
> kernel tree in CVS actually builds on HPUX.  This is really just Jason's
> work glued into the kernel tree.
> 
> Next:
> 
> - we need an HPUX ld linker script to resolve the vmlinux building,
> what's the format for this?
> 
> - we need to figure out why the bootloader gives an error when loading
> the kernel into memory
> 
> - Alex
> 
> -- 
> Alex deVries
> Vice President of Engineering
> The Puffin Group
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
> 
> 


-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] A quick update

[Jeffrey A Law]

  In message <199906181305.JAA06811@hiauly1.hia.nrc.ca>you write:
  > After the kernel is built, take a look at where the sections start
  > in SOM executable.  Each section must be copied to its corresponding
  > starting address in the LIF image.  Space must be reserved for the bss
  > data if there is a section after it that contains necessary data.
Right.  Use the exec header to find a.out-like boundaries for text, data & bss.

Do not try to build up a memory image using the space/subspace stuff.  You'll
be bitterly disappointed to find out that the info on the space/subspaces is
not wholly accurate in an executable image.

jeff

Re: [parisc-linux] A quick update

[Alex deVries]

Alex deVries wrote:
> Next:
> 
> - we need an HPUX ld linker script to resolve the vmlinux building,
> what's the format for this?

Thomas Bogendorfer solved this for us.

> 
> - we need to figure out why the bootloader gives an error when loading
> the kernel into memory

It looks like an IPL problem...

- Alex

-- 
Alex deVries
Vice President of Engineering
The Puffin Group

Re: [parisc-linux] A quick update

[Alex deVries]

John David Anglin wrote:
> You probably want to use the same link options as Jason used for the IPL:
> -N -R address.

Ah, okay.

> After the kernel is built, take a look at where the sections start
> in SOM executable.  Each section must be copied to its corresponding
> starting address in the LIF image.  Space must be reserved for the bss
> data if there is a section after it that contains necessary data.

Should I be using objcopy to cut these sections out of my SOM executable
and into the LIF image?

Two other problems I have:

1. The kernel doesn't build yet, it fails to link and dies with:


ld -e stext arch/parisc/kernel/head.o arch/parisc/kernel/init_task.o
init/main.o init/version.o \
        arch/parisc/kernel/kernel.o arch/parisc/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o \
        fs/filesystems.a \
        net/network.a \
        drivers/block/block.a drivers/char/char.a  drivers/net/net.a \
        /usr/src/linux/arch/parisc/lib/lib.a /usr/src/linux/lib/lib.a
/usr/src/linux/arch/parisc/lib/lib.a \
        -o vmlinux
ld: Unsatisfied symbols:
   swapper_pg_dir (data)
   _stext (data)

I haven't yet figured out how to solve this.

2. The bootloader within the kernel tries to load the vmlinux into
memory, but dies by returning -6 at the P0_BOOTDEV_iodc_io() call within
bootdev_sread() in rom _interface.c.  I should be able to figure out
what's going on here...


- A
-- 
Alex deVries
Vice President of Engineering
The Puffin Group

Re: [parisc-linux] A quick update

[John David Anglin]

> 
> 
> John David Anglin wrote:
> > You probably want to use the same link options as Jason used for the IPL:
> > -N -R address.
> 
> Ah, okay.
> 
> > After the kernel is built, take a look at where the sections start
> > in SOM executable.  Each section must be copied to its corresponding
> > starting address in the LIF image.  Space must be reserved for the bss
> > data if there is a section after it that contains necessary data.
> 
> Should I be using objcopy to cut these sections out of my SOM executable
> and into the LIF image?

I don't think so.  While I haven't checked all the options of objcopy,
its basic function is to copy object modules from one file to another.
If it understood the LIF format, it might work but I don't think it
does.  If I understand the situation,  the LIF image gets loaded directly
into memory.  Thus, the code that builds the LIF image must simulate
a loader, putting each section into it appropriate location in the image.
You must assure when the kernel and ipl are linked that the relocation
address of each section agrees with where it is placed in the LIF image
so that all symbols are appropriately relocated.  IPL doesn't do
anything fancy.  It looks like it just loads the kernel after itself
into memory.

After linking, the executable files for the kernel and ipl each have
a header that describe what kind object file they are.  The header also has
info about the sections in the executable.  Ideally, the program that
builds the LIF image would look at the headers in the ipl and kernel
and build the LIF image.  However, you can probably get away with
using a simple program to copy the ipl and kernel files.

You must watch out for the size of the header on each file (file
offset).  The linker script for the ELF format kernel set the origin
for .text to 0x8000.  The corresponding option for the HP linker
would be "-N -R 8000".  When I do this, the file offset to the
start of the $TEXT$ section (the first section in the file) is
0x28000.  Thus, you want to copy starting from 0x28000 in vmlinux
to 0x8000 in the LIF image.

The $BSS$ section is not in the executables since it loads as all
zeros.  However, since it is the last section in the executables
you simply have to ensure that there is enough space between the
kernel and ipl.  You need enough space for the ipl bss data and
its dynamically allocated stack.

> Two other problems I have:
> 
> 1. The kernel doesn't build yet, it fails to link and dies with:
> 
> 
> ld -e stext arch/parisc/kernel/head.o arch/parisc/kernel/init_task.o
> init/main.o init/version.o \
>         arch/parisc/kernel/kernel.o arch/parisc/mm/mm.o kernel/kernel.o
> mm/mm.o fs/fs.o ipc/ipc.o \
>         fs/filesystems.a \
>         net/network.a \
>         drivers/block/block.a drivers/char/char.a  drivers/net/net.a \
>         /usr/src/linux/arch/parisc/lib/lib.a /usr/src/linux/lib/lib.a
> /usr/src/linux/arch/parisc/lib/lib.a \
>         -o vmlinux
> ld: Unsatisfied symbols:
>    swapper_pg_dir (data)
>    _stext (data)

You want to export swapper_pg_dir in head.S.  I think in init/main.c,
you should change the declaration for _stext to "extern void _stext ();"
and "&_stext" to "_stext".  The linker thinks _stext is a reference
to data rather than text.  The other option would be to put the address
label _stext into a an exported word in the data section of head.S.  
Main.c could then determine the start of text from this location.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] A quick update

[Alex deVries]

John David Anglin wrote:
> 
> 
> After linking, the executable files for the kernel and ipl each have
> a header that describe what kind object file they are.  The header also has
> info about the sections in the executable.  Ideally, the program that
> builds the LIF image would look at the headers in the ipl and kernel
> and build the LIF image.  However, you can probably get away with
> using a simple program to copy the ipl and kernel files.

That all exists in the tools in linux/arch/parisc/hp/boot/boot_tools. 

> 
> You must watch out for the size of the header on each file (file
> offset).  The linker script for the ELF format kernel set the origin
> for .text to 0x8000.  The corresponding option for the HP linker
> would be "-N -R 8000".  When I do this, the file offset to the
> start of the $TEXT$ section (the first section in the file) is
> 0x28000.  Thus, you want to copy starting from 0x28000 in vmlinux
> to 0x8000 in the LIF image.

Oh, okay.  The linker stuff has all been sorted out (and is in CVS now).

So, here's how you can boot this bootloader:
- on HPUX, install gnu gcc and binutils
- check out the latest kernel tree
- do a 'make config ; make dep ; make vmlinux; make Image'
- boot linux/arch/parisc/hp/boot/Image

It should boot and end with:


Loading kernel...done.
Transferring control to the kernel. (At entry point 0x00008000)

and then hang completely.

The next step is to develop a small mini kernel that we can use to test
the launching. It should just print "Hello world" to the screen using
IODC.  There's lots of example code in the bootloader, so this should be
pretty simple.

- Alex "white water rafting this weekend, far away from PA RISC
equipment" deVries
-- 
Alex deVries
Vice President of Engineering
The Puffin Group

Re: [parisc-linux] A quick update

[Jeffrey A Law]

  In message <376A51F5.D38ECFFC@thepuffingroup.com>you write:
  > Should I be using objcopy to cut these sections out of my SOM executable
  > and into the LIF image?
No, I doubt objcopy knows about LIF (I've certainly never bothered to 
describe LIF to objcopy/bfd).

Utah's releases had code to do this kind of thing.  Or you might be able to use
the lif tools on hpux (ls /usr/bin/lif*).


jeff

Re: [parisc-linux] A quick update

[Cary Coutant]

>The -N places the $DATA$ section after
>the $CODE$ section in low memory.  The +n option that was being used
>in the Makefile has the $DATA$ section in the 0x40000000 quadrant.  
>This is wrong for the kernel.

The opposite of -N is -n, not +n. The +n option tells the linker to 
search archive libraries iteratively, which I believe is needed for the 
Linux kernel.

The -N option tells the linker to build a "non-shareable" executable, so 
it puts text and data together in one segment. The -n option is the 
default, where shareable text is placed in the first quadrant and data is 
placed in the second quadrant.


Cary Coutant
Hewlett-Packard Co.
Application Delivery Lab

Re: [parisc-linux] A quick update

[John David Anglin]

> 
> >The -N places the $DATA$ section after
> >the $CODE$ section in low memory.  The +n option that was being used
> >in the Makefile has the $DATA$ section in the 0x40000000 quadrant.  
> >This is wrong for the kernel.
> 
> The opposite of -N is -n, not +n. The +n option tells the linker to 
> search archive libraries iteratively, which I believe is needed for the 
> Linux kernel.

Thanks for the information on the +n option.  My old system doesn't
document +n.  However, with the simple configuration that is being
tested, it doesn't seem necessary to link the kernel with +n.  Possibly,
+n will be required when more modules are configured in the kernel.

> The -N option tells the linker to build a "non-shareable" executable, so 
> it puts text and data together in one segment. The -n option is the 
> default, where shareable text is placed in the first quadrant and data is 
> placed in the second quadrant.

Based on the code in the IPL that is being used, it looks like -N
is the correct choice.  The IPL doesn't try to load kernel data
into the second quadrant as far as I can tell.

-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)