Re: Building the Bootloader

Re: Building the Bootloader

[Christopher Beard]

> Hm.  Okay then.  So what we need to do is fix the cross compiling of
> mkipl.  I'll have a look at this.
          
There is some confusion here. The IPL does not have to be SOM, in fact, it
wouldn't work correctly if it was. It's a raw binary format created using
HP's linker by passing parameters to give it a zero offset, etc. (And
which Jason Eckardt suggests could also be extracted from a valid ELF
format binary given the right script.)

The confusion exists as currently, it can only be produced under HP/UX as
there are still some issues with the xcompiler/binutils under x86 for the
PA-RISC target. 

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.

Before even trying to compile the kernel and getting it booting with the
current xcompiler/binutils, building a working IPL with the xcompiler
environment should be done.  This will tell us that yes in fact it is
doing the Right Thing and it will be far easier to debug. 

Chris

Re: Building the Bootloader

[John David Anglin]

> > Hm.  Okay then.  So what we need to do is fix the cross compiling of
> > mkipl.  I'll have a look at this.
>           
> There is some confusion here. The IPL does not have to be SOM, in fact, it
> wouldn't work correctly if it was. It's a raw binary format created using
> HP's linker by passing parameters to give it a zero offset, etc. (And
> which Jason Eckardt suggests could also be extracted from a valid ELF
> format binary given the right script.)

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.

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.  Although I haven't looked at the
IPL, I would guess that it is designed to load an ELF binary.  There
are also file system issues.

> The confusion exists as currently, it can only be produced under HP/UX as
> there are still some issues with the xcompiler/binutils under x86 for the
> PA-RISC target. 
> 
> 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).

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

Re: Building the Bootloader

[Philipp Rumpf]

> 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...

Re: Building the Bootloader

[John David Anglin]

> > 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.

The question is in what way.  I have been using gas for a long time
with gcc with no major problems.  Possibly, there are problems with ld.
The source at puffin is quite a bit out of date.  Maybe the hppa-linux
support should be integrated into 2.9.4.

> 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...

I think that I may have been able to successfully cross compile ipl to an
elf binary with text starting at offset 0.  Note that this requires that
libgcc.a has been built successfully for hppa-linux.  This requires a
few patches to gcc.  I think that I have comparable linker flags but I
am not quite sure.   I can make the binary available if someone wants to
try it.  Here are the diffs:

*** Makefile.hp	Thu Mar 11 16:52:20 1999
--- Makefile.gnu	Tue Jun  1 13:55:34 1999
***************
*** 13,22 ****
  #
  
  
! CC	= /usr/local/bin/gcc		# gcc
! LD	= /bin/ld                       # HP's linker
! LDFLAGS = -R 0 -N			#
! AS	= /usr/local/bin/as             # gas
  CFLAGS	= -fwritable-strings -mdisable-fpregs
  
  all:    ipl
--- 13,24 ----
  #
  
  
! CC	= hppa-linux-gcc		# gcc
! LD	= hppa-linux-ld                 #
! # LDFLAGS = -Wl,-Ttext -Wl,0 -Wl,-N -nostartfiles -nostdlib -v
! LDFLAGS = -Ttext 0 -N
! LDLIBS  = -L/ehic/a/lib/gcc-lib/hppa-linux/egcs-2.91.60 -lgcc
! AS	= hppa-linux-as                 # gas
  CFLAGS	= -fwritable-strings -mdisable-fpregs
  
  all:    ipl
***************
*** 41,47 ****
  
  #
  ipl: ipl_s.o ipl_c.o rom_interface.o
! 	$(LD) $(LDFLAGS) ipl_s.o ipl_c.o rom_interface.o -o ipl
  
  
  #
--- 43,49 ----
  
  #
  ipl: ipl_s.o ipl_c.o rom_interface.o
! 	$(LD) $(LDFLAGS) ipl_s.o ipl_c.o rom_interface.o $(LDLIBS) -o ipl
  
  
  #

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

Re: Building the Bootloader

[Philipp Rumpf]

> I think that I may have been able to successfully cross compile ipl to an
> elf binary with text starting at offset 0.  Note that this requires that

offset 0 sounds bad as we may not corrupt page 0 (the PDC puts some data we
need there).

Re: Building the Bootloader

[John David Anglin]

> > I think that I may have been able to successfully cross compile ipl to an
> > elf binary with text starting at offset 0.  Note that this requires that
> 
> offset 0 sounds bad as we may not corrupt page 0 (the PDC puts some data we
> need there).

This is easily changed but seems consistent with the "-R 0" option to
the hp linker used in Jason Eckhardt's Makefile.  It would appear that
mkipl builds the actual image.  On the otherhand, no care was taken
to compile using pic so there may be a relocation problem.

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

Re: Building the Bootloader

[Jason Eckhardt]

> > > I think that I may have been able to successfully cross compile ipl to an
> > > elf binary with text starting at offset 0.  Note that this requires that
> > 
> > offset 0 sounds bad as we may not corrupt page 0 (the PDC puts some data we
> > need there).
>
> This is easily changed but seems consistent with the "-R 0" option to
> the hp linker used in Jason Eckhardt's Makefile.  It would appear that
> mkipl builds the actual image.  On the otherhand, no care was taken
> to compile using pic so there may be a relocation problem.
>

  Care was taken -- the ipl is position independent with the chosen 
  combination of flags and code design. The ipl makes no assumption about the
  location it will be loaded into by the ROM (see ipl_s.s). Text offset zero 
  is correct for linking in the scheme I have chosen. The bootloader determines
  where is was loaded at runtime and sets the dp and sp accordingly. All of
  this should be obvious from the code.

  The specific combination of flags allowed me to get something resembling
  a straight binary image (by ignoring the header) and position independence.
  For some reason I can't remember now, -fpic didn't get the job done
  (perhaps a compiler defect).

  In any case, I expect later that we will just link the ipl as a standard
  ELF and then extract the "actual" binary image from it (as chris mentioned
  earlier, and as mentioned in the HILO README). The point was to get a 
  simple bootloader going, which I did (there were no cross tools at that
  time, I therefore just used gcc on HPUX). Any number of tweaks can easily be
  made as needed.

  jason.

Re: Building the Bootloader

[John David Anglin]

>   Care was taken -- the ipl is position independent with the chosen 
>   combination of flags and code design. The ipl makes no assumption about the
>   location it will be loaded into by the ROM (see ipl_s.s). Text offset zero 
>   is correct for linking in the scheme I have chosen. The bootloader determines
>   where is was loaded at runtime and sets the dp and sp accordingly. All of
>   this should be obvious from the code.

It is not obvious to me that the C code is position independent.

>   The specific combination of flags allowed me to get something resembling
>   a straight binary image (by ignoring the header) and position independence.
>   For some reason I can't remember now, -fpic didn't get the job done
>   (perhaps a compiler defect).

When -fpic is used, $global$ is not used as an offset to access data
variables.  Gnu ld doesn't seem to like $global$ not being used:

624 (hiauly1)dave> make
hppa-linux-as                  ipl_s.s -o ipl_s.o
ipl_s.s: Assembler messages:
ipl_s.s:65: Warning: Ignoring subspace decl due to ELF BFD bugs.
ipl_s.s:68: Warning: Ignoring subspace decl due to ELF BFD bugs.
ipl_s.s:83: Warning: Ignoring subspace decl due to ELF BFD bugs.
ipl_s.s:243: Warning: Ignoring subspace decl due to ELF BFD bugs.
hppa-linux-gcc           -fwritable-strings -mdisable-fpregs -fpic -c ipl_c.c
hppa-linux-gcc           -fwritable-strings -mdisable-fpregs -fpic -c rom_interf
ace.c
hppa-linux-ld                  -Ttext 0 -N ipl_s.o ipl_c.o rom_interface.o -L/eh
ic/a/lib/gcc-lib/hppa-linux/egcs-2.91.60 -lgcc -o ipl
ipl_c.o: In function `IPL_main':
ipl_c.o($CODE$+0x60): undefined reference to `$global$'
make: *** [ipl] Error 1

Inspection of ipl_c.o shows that there is no actual reference to $global$
in ipl_c.o.  No errors occur if -fpic is removed.  

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

Re: Building the Bootloader

[John David Anglin]

> It is not obvious to me that the C code is position independent.
> 
> >   The specific combination of flags allowed me to get something resembling
> >   a straight binary image (by ignoring the header) and position independence.
> >   For some reason I can't remember now, -fpic didn't get the job done
> >   (perhaps a compiler defect).
> 
> When -fpic is used, $global$ is not used as an offset to access data
> variables.  Gnu ld doesn't seem to like $global$ not being used:
> 
> 624 (hiauly1)dave> make
> hppa-linux-as                  ipl_s.s -o ipl_s.o
> ipl_s.s: Assembler messages:
> ipl_s.s:65: Warning: Ignoring subspace decl due to ELF BFD bugs.
> ipl_s.s:68: Warning: Ignoring subspace decl due to ELF BFD bugs.
> ipl_s.s:83: Warning: Ignoring subspace decl due to ELF BFD bugs.
> ipl_s.s:243: Warning: Ignoring subspace decl due to ELF BFD bugs.
> hppa-linux-gcc           -fwritable-strings -mdisable-fpregs -fpic -c ipl_c.c
> hppa-linux-gcc           -fwritable-strings -mdisable-fpregs -fpic -c rom_interf
> ace.c
> hppa-linux-ld                  -Ttext 0 -N ipl_s.o ipl_c.o rom_interface.o -L/eh
> ic/a/lib/gcc-lib/hppa-linux/egcs-2.91.60 -lgcc -o ipl
> ipl_c.o: In function `IPL_main':
> ipl_c.o($CODE$+0x60): undefined reference to `$global$'
> make: *** [ipl] Error 1

Here are Jeff Law's comments on using elf32-hppa with PIC: