Re: [parisc-linux] booting problems

Re: [parisc-linux] booting problems

[Jason Eckhardt]

> I think you're right.  I'm sure now that the byte order isn't a problem,
> because my header and Jason's IPL work fine.
>
> > Jason's
> > link options, "-R 0 -N", specified a text origin of 0 and data following
> > the text.  I think the default for ELF is to place the text at 0x1000 and
> > data at 0x40000000.  The gnu ld equivalent for "-R 0" would appear to
> > be "-Ttext 0".  I am not sure there is a direct equivalent for "-N".
> > Maybe, you could use "-Tdata" to set the data location.  Maps might be
> > useful to sort out what is going on.  
>
> Definitely.  This should be the next step in sorting this out.
>

  The bootstrap definately will not work with default data at 0x40000000.
  The HPMC that is occurring is undoubtedly because the data section is there.

Re: [parisc-linux] booting problems

[Alex deVries]

Jason Eckhardt wrote:
> 
> > I think you're right.  I'm sure now that the byte order isn't a problem,
> > because my header and Jason's IPL work fine.
> >
> > > Jason's
> > > link options, "-R 0 -N", specified a text origin of 0 and data following
> > > the text.  I think the default for ELF is to place the text at 0x1000 and
> > > data at 0x40000000.  The gnu ld equivalent for "-R 0" would appear to
> > > be "-Ttext 0".  I am not sure there is a direct equivalent for "-N".
> > > Maybe, you could use "-Tdata" to set the data location.  Maps might be
> > > useful to sort out what is going on.
> >
> > Definitely.  This should be the next step in sorting this out.
> >
> 
>   The bootstrap definately will not work with default data at 0x40000000.
>   The HPMC that is occurring is undoubtedly because the data section is there.

Okay, this is the same conclusion I came to.  Where should I put both
the data and text sengments?

- Alex

Re: [parisc-linux] booting problems

[John David Anglin]

> Okay, this is the same conclusion I came to.  Where should I put both
> the data and text sengments?

Try this for the ld options: -Ttext 800 -N -s.

This links all sections in low virtual memory.  VMA and LMA for the
.text section are 0x800 (the size of the LIF header, 2048).  The file
offset to the .text section is 0xa0 bytes when -N is specified.  The
size of the LIF header should be 0x800 - 0xa0 = 0x760 (1888 bytes).
The -s option strips the symbols.

The result of the link can be inspected with the command:

hppa-parisc-objdump --headers ipl

Hope this works.

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

Re: [parisc-linux] booting problems

[John David Anglin]

> 
> > Okay, this is the same conclusion I came to.  Where should I put both
> > the data and text sengments?
> 
> Try this for the ld options: -Ttext 800 -N -s.
> 
> This links all sections in low virtual memory.  VMA and LMA for the
> .text section are 0x800 (the size of the LIF header, 2048).  The file
> offset to the .text section is 0xa0 bytes when -N is specified.  The
> size of the LIF header should be 0x800 - 0xa0 = 0x760 (1888 bytes).

This last part may be unclear.  What you need to arrange is that
the offset to the .text section in the binary image is 0x800 bytes.

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

Re: [parisc-linux] booting problems

[John David Anglin]

> 
> > Okay, this is the same conclusion I came to.  Where should I put both
> > the data and text sengments?
> 
> Try this for the ld options: -Ttext 800 -N -s.

On further inspection of the generated ipl file, it appears that a
more complex script is needed to extract the section data.  Here
is the header dump of IPL created with the above link options:

ipl.N800:     file format elf32-hppa

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00001b90  00000800  00000800  000000a0  2**4
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         000064a8  00003000  00003000  000028a0  2**12
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          0000115c  0000f950  0000f950  00008d48  2**3
                  ALLOC
  3 .PARISC.unwind 000000c0  00010aac  00010aac  00009a50  2**0
                  CONTENTS
  4 .PARISC.symext 00000000  00010b6c  00010b6c  00009b10  2**2
                  CONTENTS
  5 $CODE$        00000d08  00010ba0  00010ba0  00008d48  2**3
                  CONTENTS, ALLOC, LOAD, CODE

The file offset for the .data section is ok.  However, the .bss
section must be created in the LIF image.  The $CODE$ section
is next in the file and it must be loaded at 10ba0 in the LIF
image.  Finally, the .PARISC.unwind and .PARISC.symext must be
loaded to the correct locations in the LIF image.

It might be possible with a ld script to better arrange the sections
and improve their placement in the linked file.

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

Re: [parisc-linux] booting problems

[Jeffrey A Law]

  In message <199906120323.XAA29685@hiauly1.hia.nrc.ca>you write:
  > image.  Finally, the .PARISC.unwind and .PARISC.symext must be
  > loaded to the correct locations in the LIF image.
You can throw away the unwind & symext sections.  While one day you might want
the unwinders in your lif image, you'll never want the symext.

In the ELF tools, you shouldn't never end up with anything in $CODE$.  If
you do, that's a bug in either the compiler or the assembler.  It should
have mapped $CODE$ into .text.

jeff

Re: [parisc-linux] booting problems

[Alex deVries]

Jeffrey A Law wrote:
> 
>   In message <199906120323.XAA29685@hiauly1.hia.nrc.ca>you write:
>   > image.  Finally, the .PARISC.unwind and .PARISC.symext must be
>   > loaded to the correct locations in the LIF image.
> You can throw away the unwind & symext sections.  While one day you might want
> the unwinders in your lif image, you'll never want the symext.
> 
> In the ELF tools, you shouldn't never end up with anything in $CODE$.  If
> you do, that's a bug in either the compiler or the assembler.  It should
> have mapped $CODE$ into .text.

Okay.  So this means there's a problem with the GNU ld code. Jeff, do
you know approximately where within the ld code we should be looking to
fix this?

I confess I'm starting to get a little lost with the segment placings. 
Everything I'm trying is producing nothing at all.  The latest I've
tried is linking with:

parisc-linux-ld -m hppaelf -Ttext 0x1000 -N -s \
     ipl_s.o ipl_c.o rom_interface.o ../../../lib/milli.o -o ipl

You can inspect this kernel, it's at
ftp://puffin.external.hp.com/pub/parisc/binaries/kernels/Image-19990612-1

The IPL starts at 0x1000.

It would be very helpful to get a PIM dump as Kirk had provided earlier.

- Alex

Re: [parisc-linux] booting problems

[Jeffrey A Law]

  In message <3761EBB0.26A1931C@thepuffingroup.com>you write:
  > > In the ELF tools, you shouldn't never end up with anything in $CODE$.  If
  > > you do, that's a bug in either the compiler or the assembler.  It should
  > > have mapped $CODE$ into .text.
  > 
  > Okay.  So this means there's a problem with the GNU ld code. Jeff, do
  > you know approximately where within the ld code we should be looking to
  > fix this?
No, it's in either gas or gcc, not gld.

To find it you first need to find the offending .o file.  Then we'll look at
the .s it's built from, then possibly walk backwards to the compiler itself
depending on what we find.

To find the offending .o file with a $CODE$ use something like

objdump -h *.o ../../../lib/milli.o > /tmp/BLAH

Then search for $CODE$ in the resulting /tmp/BLAH.  We'll work backwards from
what you find.

  > It would be very helpful to get a PIM dump as Kirk had provided earlier.
Look at trap.c in the Utah code.   It had some of this kind of stuff.  Though
it assumes that you can run long enough to get your own trap handlers
installed.

jeff

[parisc-linux] booting problems

[James Waterhouse]

Hello everyone,
	I'm seem to be having trouble booting into linux on my 712/60. I hope 
someone can help. I have built a new kernel (from cvs) and also set up 
an nfs root. When I try to boot the linux boots up to the point where it 
says "Cleaning: /tmp/ /var/lock /var/run" and then it just hangs. Any 
idea what is cause it to hang? Could there be a problem with the nfsroot?

James

Re: [parisc-linux] booting problems

[Jeffrey A Law]

  In message <3761F335.ADA76678@thepuffingroup.com>you write:
  > This is a multi-part message in MIME format.
  > > Then search for $CODE$ in the resulting /tmp/BLAH.  We'll work backwards 
  > from
  > > what you find.
  > 
  > The offending files are:
  > 
  > ipl_c.o:     file format elf32-hppa
[ ... ]

  >   4 $CODE$        00000210  00000000  00000000  000002b0  2**3
  >                   CONTENTS, ALLOC, LOAD, RELOC, CODE
  >   5 $CODE$        000001f8  00000000  00000000  000004c0  2**3
  >                   CONTENTS, ALLOC, LOAD, RELOC, CODE
  >   6 $CODE$        000003d8  00000000  00000000  000006b8  2**3
  >                   CONTENTS, ALLOC, LOAD, RELOC, CODE
OK.  This is actually enough to identify the problem.

This is one of those stupid problems that will go away when we revamp the tools
to do ELF in a more traditional fashion -- in particular dumping all the dumb
HP names for spaces/subspaces and sticking with standard names.

The problem is in the assembler's handling of .nsubspa.  It is not honoring the
$CODE$ -> .text translation for that case.

in gas/tc-hppa.c::pa_subspace there should be code like this:

     /* If this is an existing subspace, then we want to use the
         segment already associated with the subspace.

         FIXME NOW!  ELF BFD doesn't appear to be ready to deal with
         lots of sections.  It might be a problem in the PA ELF
         code, I do not know yet.  For now avoid creating anything
         but the "standard" sections for ELF.  */
      if (create_new)
        section = subseg_force_new (ss_name, 0);
      else if (ssd)
        section = ssd->ssd_seg;
      else if (alias)
        section = subseg_new (alias, 0);
      else if (!alias && USE_ALIASES)
        {
          as_warn (_("Ignoring subspace decl due to ELF BFD bugs."));
          demand_empty_rest_of_line ();
          return;
        }
      else
        section = subseg_new (ss_name, 0);


You'll note the FIXME NOW!.  It's about 5 years old :(  Though it will be
zapped as we drop the $CODE$ nonsense.


Anyway I think you may be able to fix this bug by changing the subseg_force_new
call to look something like:

  subseg_force_new (alias ? alias : ss_name, 0);


Though I'm a little confused.  I thought y'all were dropping the existing ELF
stuff -- I would strongly recommend it.  We're not even planning to keep the
existing elf32-hppa stuff building in gas/binutils as we work on the rewrite.
You're working with a totally dead and unsupported toolchain at this point.

jeff

Re: [parisc-linux] booting problems

[Alex deVries]

Jeffrey A Law wrote:
> 

<snip>

Okay, I can make that change, unless someone beats me to it.

> 
> Though I'm a little confused.  I thought y'all were dropping the existing ELF
> stuff -- I would strongly recommend it.  We're not even planning to keep the
> existing elf32-hppa stuff building in gas/binutils as we work on the rewrite.
> You're working with a totally dead and unsupported toolchain at this point.

Let me clear this up.

Yes, we are absolutely dropping any use of the current broken
instantiation of elf32-hppa.

However, there's this time gap between now and when we actually have the
new toolchain from Cygnus.  During this time, the only thing that we
expect to work on is the kernel and bootloader.  Having just those two
components building with the current gcc and linker are important.

When Cygnus delivers a new toolchain, we'll go for that.

If we don't do it this way, the only toolchain we'll have is hosted on
HPUX, which I want to avoid if I possibly can.  The
fix-build-boot-restart cycle is muuuuch faster if you can cross compile
and netboot, particularly for those people who only have one HPUX
machine and slow connectivity to the HPUX box that HP has online for us.

Does that make sense?

- Alex

Re: [parisc-linux] booting problems

[John David Anglin]

> Jeffrey A Law wrote:
> > 
> 
> <snip>
> 
> Okay, I can make that change, unless someone beats me to it.
> 
> > 
> > Though I'm a little confused.  I thought y'all were dropping the existing ELF
> > stuff -- I would strongly recommend it.  We're not even planning to keep the
> > existing elf32-hppa stuff building in gas/binutils as we work on the rewrite.
> > You're working with a totally dead and unsupported toolchain at this point.
> 
> Let me clear this up.
> 
> Yes, we are absolutely dropping any use of the current broken
> instantiation of elf32-hppa.

As I see it, it is a question of priorities.  The existing elf32-hppa
tools are the only ones which currently allow cross development
due to the lack of gnu linker supporting SOM.  If a SOM linker were
available, cross development could be done using the more developed
and tested SOM tools.  However, according to the comments in binutils/bfd,
the bfd architecture is incapable of performing all types of SOM
relocations.  A SOM linker also needs to be stream based.  Thus,
it appears difficult (impossible?) to build a SOM linker using the
bfd architecture.  On the other hand, the elf32-hppa tools have serious
deficiencies and are about to be completely rewritten.  Might it not be
better to develop a SOM linker rather than rewrite the elf stuff?

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

Re: [parisc-linux] booting problems

[Alan Cox]

> relocations.  A SOM linker also needs to be stream based.  Thus,
> it appears difficult (impossible?) to build a SOM linker using the
> bfd architecture.  On the other hand, the elf32-hppa tools have serious
> deficiencies and are about to be completely rewritten.  Might it not be
> better to develop a SOM linker rather than rewrite the elf stuff?

Writing a linker, especialyl for something complex like SOM is not trivial
in the slightest.

Alan

Re: [parisc-linux] booting problems

[Jeffrey A Law]

  In message <E10sse6-0004NC-00@the-village.bc.nu>you write:
  > Writing a linker, especialyl for something complex like SOM is not trivial
  > in the slightest.
  > 
One hell of an understatement.  Time is better spent _rewriting_ the ELF tools
to work in a reasoanble manner.

I'm not talking about tweaking the ELF tools, I'm talking about starting from
scratch.  The elf32-hppa code was the first elf backend that tried to deal
with linker generated code.

We've learned a lot since that code was written -- both about the generic
issues behind linker generated code and PA specific issues.  Enough to 
realize that what we tried to do in elf32-hppa.c was horribly bad and
needs to be scrapped and replaced.


jeff

Re: [parisc-linux] booting problems

[Matthew Wilcox]

On Sat, Jun 12, 1999 at 07:36:44PM +0100, Alan Cox wrote:
> > relocations.  A SOM linker also needs to be stream based.  Thus,
> > it appears difficult (impossible?) to build a SOM linker using the
> > bfd architecture.  On the other hand, the elf32-hppa tools have serious
> > deficiencies and are about to be completely rewritten.  Might it not be
> > better to develop a SOM linker rather than rewrite the elf stuff?
> 
> Writing a linker, especialyl for something complex like SOM is not trivial
> in the slightest.

Yes, if you really want to support SOM properly and follow the spec.
It probably isn't if you want to just deal with what actually exists in
the world.  If you look at page 6-125 of the `32-bit PA-RISC Run-Time
Architecture Document 11.0 Version 1.0', it says that all conforming
executable SOM files must have the `exec auxiliary header (also known as
the HP-UX header with Hewlett-Packard)'.

So in the binfmt_som loader I take this opportunity to ignore the
wonderfully flexible and expressive structure that is contained in the SOM
file format and just map the text, data and bss segments from the file.
I imagine that a SOM linker which did just enough to get a kernel up
and running would not be too hard to write.  On the other hand, I can
think of a dozen more interesting and productive things to do.

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] booting problems

[Jeffrey A Law]

  In message <19990612213649.Y31472@mencheca.ch.genedata.com>you write:
  > Yes, if you really want to support SOM properly and follow the spec.
  > It probably isn't if you want to just deal with what actually exists in
  > the world.  If you look at page 6-125 of the `32-bit PA-RISC Run-Time
  > Architecture Document 11.0 Version 1.0', it says that all conforming
  > executable SOM files must have the `exec auxiliary header (also known as
  > the HP-UX header with Hewlett-Packard)'.
The headers are the easy part.  Really.  It's the relocations that are such
a bear.


  > So in the binfmt_som loader I take this opportunity to ignore the
  > wonderfully flexible and expressive structure that is contained in the SOM
  > file format and just map the text, data and bss segments from the file.
  > I imagine that a SOM linker which did just enough to get a kernel up
  > and running would not be too hard to write.  On the other hand, I can
  > think of a dozen more interesting and productive things to do.
If you look at the SOM exec aux header, it effectively gives you the old
traditional text, data, bss.   That's its purpose in life -- to glom together
all the readonly loadable things into ".text", read-write initialized into
".data" and everything else into .bss.   The ELF folks in the crowd will
recognize this as the program vs object viewpoints of an ELF file.


While "just a kernel linker" does simplify things (no need for shared libraries
and the shitloads of stubs they involve), you've still got a large, nontrivial
project on your hands.  It would *still* be easier to sit down and rewrite the
elf32 tools than to do a kernel-only SOM linker.

If you're really sadistic, look at the way calls relocs are handled.



jeff

Re: [parisc-linux] booting problems

[Jeffrey A Law]

  In message <37624146.A7B5F0FE@thepuffingroup.com>you write:
  > Jeffrey A Law wrote:
  > > 
  > 
  > <snip>
  > 
  > Okay, I can make that change, unless someone beats me to it.
Let me know if it helps.  That change is just an educated guess :-)


  > However, there's this time gap between now and when we actually have the
  > new toolchain from Cygnus.  During this time, the only thing that we
  > expect to work on is the kernel and bootloader.  Having just those two
  > components building with the current gcc and linker are important.
OK.  But note Cygnus is _NOT_ currently scheduled or contracted to provide a
32bit ELF toolchain.  Cygnus will be providing a 64bit ELF toolchain which
folks can use to derive much of the 32bit toolchain.
  > 
  > If we don't do it this way, the only toolchain we'll have is hosted on
  > HPUX, which I want to avoid if I possibly can.  The
  > fix-build-boot-restart cycle is muuuuch faster if you can cross compile
  > and netboot, particularly for those people who only have one HPUX
  > machine and slow connectivity to the HPUX box that HP has online for us.
I understand.  I'm still skeptical that you're going to end up burning
more time fighting those lame elf tools than you would by building with
SOM tools.

Of course, if you had two HP machines, then this is a non-issue :-)

jeff

Re: [parisc-linux] booting problems

[John David Anglin]

> Anyway I think you may be able to fix this bug by changing the subseg_force_new
> call to look something like:
> 
>   subseg_force_new (alias ? alias : ss_name, 0);

Just to through a little "gas" on the discussion, I installed Jeff's
patch and rebuilt.  The patch sucessfully merges $CODE$ into .text.

Here are the kernel headers:

vmlinux:     file format elf32-hppa

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000759b0  00008000  00008000  00001000  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         0000f260  0007d9b0  0007d9b0  000769b0  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          0001ac6c  0008e000  0008e000  00086000  2**4
                  ALLOC
  3 .PARISC.unwind 00006be0  000a8c6c  000a8c6c  00086000  2**0
                  CONTENTS
  4 .PARISC.symext 00000000  000af84c  000af84c  0008cbe0  2**2
                  CONTENTS

Here are the headers for ipl linked with "-Ttext800 -N":

ipl:     file format elf32-hppa

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000028a0  00000800  00000800  00000080  2**4
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         000064a8  00004000  00004000  00003880  2**12
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          0000115c  00010950  00010950  00009d28  2**3
                  ALLOC
  3 .PARISC.unwind 000000c0  00011aac  00011aac  00009d28  2**0
                  CONTENTS
  4 .PARISC.symext 00000000  00011b6c  00011b6c  00009de8  2**2
                  CONTENTS

I think that we are real close to being able to generate a bootable
kernel with the existing elf32 tools.

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

Re: [parisc-linux] booting problems

[Alex deVries]

John David Anglin wrote:
>
> 
> I think that we are real close to being able to generate a bootable
> kernel with the existing elf32 tools.
>

Okay, I'll give this one more try with my current setup and see what
happens...

In the meantime, I've started private talks with HP about the
possibility of releasing an HPUX ld cross compiler hosted on i386-linux.

- alex

Re: [parisc-linux] booting problems

[Richard J. Rauenzahn]

The "HP Remote Management (access port) interface card" is Product # A3342A

-----Original Message-----
From: Stan Sieler <sieler@allegro.com>
To: Kirk Bresniker <kirkb@chrome.rose.hp.com>
Cc: adevries@thepuffingroup.com <adevries@thepuffingroup.com>;
parisc-linux@thepuffingroup.com <parisc-linux@thepuffingroup.com>
Date: Thursday, June 10, 1999 10:11 AM
Subject: Re: [parisc-linux] booting problems


>Re:
>
>> | No, we don't have remote manatement cards, but it sounds like they'd be
>...
>> display the chassis codes sent by the PDC_CHASSIS call. The remote
>> management card, however, has the benefits of saving a history of the
>> chassis codes, as well as providing the remote reset/TOC functions.
>
>Do you have a part number for this card?

Re: [parisc-linux] booting problems

[Stan Sieler]

Hi,

Re:

> On some X-Windows servers on PCs, pressing F9 will toggle the "25th" line
...

Oops...forgot that I'd customized my keyboard map.

My keyboard map, which tries to add the missing HP keys to a PC keyboard
(running Reflection X) is at:

http://www.allegro.com/sieler/custom.kmp.html

If you use a different X server on a PC (or Mac or Sun or whatever),
you might be interested in a couple of the keycodes that are less
common ... they're listed on the above page.

-- 
Stan Sieler                                          sieler@allegro.com
                                     http://www.allegro.com/sieler.html

[parisc-linux] booting problems

[Alex deVries]

Okay, I've committed a couple of fixes to make the building of the
bootable image go a bit smoother.  Thanks to John for his patch that
doesn't require /dev/zero existing to create the sparse file.

And now it passes the LIF magic and checksum, and dies.  Here's a
hand-typed copy of the console:

"
Main Menu: Enter command > boot p2
Interact with IPL (Y, N, or Cancel)?> n

Booting...
Network Station Address 001039-037944
System IP Address 192.168.1.56
Server IP Address 192.168.1.52

Boot IO Dependant Code (IODC) revision 2


SOFT Booted.
"

And then absolutely nothing.  The cute little heart on the front panel
is stuck on. According to the inside of the top cover (oh, what a great
place to put debug info), this means: "System board fault, HPMC or
Unknown fault".  At this point I'm going for the third.

Looks like we just need to compare a large chunk of the bootable binary
to figure out what's happening.

- Alex

Re: [parisc-linux] booting problems

[Kirk Bresniker]

Alex --
| is stuck on. According to the inside of the top cover (oh, what a great
| place to put debug info), this means: "System board fault, HPMC or
| Unknown fault".  At this point I'm going for the third.
| 
| Looks like we just need to compare a large chunk of the bootable binary
| to figure out what's happening.
| 

Not so fast, there is probably more data to be had. Discounting the system
board or unknown faults, you code has caused an HPMC, High Priority
Machine Check. This could be several things, but a good guess would be
either execution of an invalid instruction (you jumped into data), or
you attempted to read a address where there is no hardware to respond.

The way to check is to reboot the system through self-test and when you
reach the boot console handler execute a "SER PIM" command.  PIM is an
area of non-volatile memory that is filed in by the routine which
handled the HPMC and is filled with the state of the machine when the
HPMC was encountered.  From this you should be able to obtain the
address of the instruction which was executing when the problem occured,
and should be able to determine what type of problem occured (illegal
instruction, bad memory reference, etc.)  The PIM dumps are timestamped,
so make sure that your system time is up to date and that that the PIM
is from your crash.

Do your systems include remote management cards? The remote management
cards offer the ability to force a PIM dump through a TC (Transfer of
Control) command, or to force a reset. They also will display chassis
codes. Chassis codes, see the PDC_CHASSIS call in your pdc32.pdf
documentation), are displayed on the 25th line of an HPTERM compatible
terminal or web console session. They are communicated to the management
cards over a dedicated hardware interface, and so inserting them into
your code gives a very low level way to display debug data.

KMB


--
+============================================================+
|       Kirk Bresniker    	(916) 785-5677		     |
|       8000 Foothills Blvd                                  |
|       Roseville, CA 95747-5649                             |
|       kirkb@rose.hp.com                                    |

Re: [parisc-linux] booting problems

[Alex deVries]

Kirk Bresniker wrote:
> Discounting the system
> board or unknown faults, you code has caused an HPMC, High Priority
> Machine Check. This could be several things, but a good guess would be
> either execution of an invalid instruction (you jumped into data), or
> you attempted to read a address where there is no hardware to respond.

It's likely the bootstrap code jumping to some random bit of data.

> 
> The way to check is to reboot the system through self-test and when you
> reach the boot console handler execute a "SER PIM" command.  PIM is an
> area of non-volatile memory that is filed in by the routine which
> handled the HPMC and is filled with the state of the machine when the
> HPMC was encountered.  From this you should be able to obtain the
> address of the instruction which was executing when the problem occured,
> and should be able to determine what type of problem occured (illegal
> instruction, bad memory reference, etc.)  The PIM dumps are timestamped,
> so make sure that your system time is up to date and that that the PIM
> is from your crash.

All that looks very helpful, and it's the first time I'd heard about it.

I tried that, and I got no error codes, and completely blank registers.
I tried booting a file I knew would break IPL, and I got no error codes
back from it either.

> Do your systems include remote management cards? The remote management
> cards offer the ability to force a PIM dump through a TC (Transfer of
> Control) command, or to force a reset. They also will display chassis
> codes. 

No, we don't have remote manatement cards, but it sounds like they'd be
very useful for this kind of thing.  I know the LCD panels on the D270
displays these, is this a similiar device?


> Chassis codes, see the PDC_CHASSIS call in your pdc32.pdf
> documentation), are displayed on the 25th line of an HPTERM compatible
> terminal or web console session. They are communicated to the management
> cards over a dedicated hardware interface, and so inserting them into
> your code gives a very low level way to display debug data.

Putting the error on the 25th line is a really good idea, but I can't
see the 25th line because of the terminal control buttons ("Line
Modify", "Modify All", etc).  I can't seem to get rid of them either.
What's the trick?

My suspicion is that the problem with our cross compiling bootloader is
somehow related to byte order of the build system.  Jason did his
originally on HPUX (big), and I'm doing my work on i386 (little).  To
check this I'm going to build the kernel on this sparc I have.

- Alex

Re: [parisc-linux] booting problems

[Kirk Bresniker]

| 
| No, we don't have remote manatement cards, but it sounds like they'd be
| very useful for this kind of thing.  I know the LCD panels on the D270
| displays these, is this a similiar device?
| 

Yes, the LCD panel and the display on the 25th line of the HPTERM both
display the chassis codes sent by the PDC_CHASSIS call. The remote
management card, however, has the benefits of saving a history of the
chassis codes, as well as providing the remote reset/TOC functions. 

| > cards over a dedicated hardware interface, and so inserting them into
| > your code gives a very low level way to display debug data.
| 
| Putting the error on the 25th line is a really good idea, but I can't
| see the 25th line because of the terminal control buttons ("Line
| Modify", "Modify All", etc).  I can't seem to get rid of them either.
| What's the trick?

For the X11 hpterm client on an HP-style keyboard, hitting the Menu key
will cause the softkey labels to be toggled on/off.  On a PC-style
keyboard, the PrintScreen/SysRq key toggles the labels. If you have a
remote management card, then the chassis codes will automatically toggle
thte softkey labels off. 

KMB

--
+============================================================+
|       Kirk Bresniker    	(916) 785-5677		     |
|       8000 Foothills Blvd                                  |
|       Roseville, CA 95747-5649                             |
|       kirkb@rose.hp.com                                    |

Re: [parisc-linux] booting problems

[Stan Sieler]

Re:

> | No, we don't have remote manatement cards, but it sounds like they'd be
...
> display the chassis codes sent by the PDC_CHASSIS call. The remote
> management card, however, has the benefits of saving a history of the
> chassis codes, as well as providing the remote reset/TOC functions. 

Do you have a part number for this card?
 
> For the X11 hpterm client on an HP-style keyboard, hitting the Menu key
> will cause the softkey labels to be toggled on/off.  On a PC-style
> keyboard, the PrintScreen/SysRq key toggles the labels. If you have a
> remote management card, then the chassis codes will automatically toggle
> thte softkey labels off. 

On some X-Windows servers on PCs, pressing F9 will toggle the "25th" line
display between not showing and showing the user function keys.
Pressing F11 will display the 25th line, showing the
device/modes function keys.  Pressing F12 will display the 25th line
showing the user function keys.   (At least, that's what Reflection X
is doing for me, connection to HP-UX 10.20 running CDE)

-- 
Stan Sieler                                          sieler@allegro.com
                                     http://www.allegro.com/sieler.html

Re: [parisc-linux] booting problems

[Stan Sieler]

Re:

> > Chassis codes, see the PDC_CHASSIS call in your pdc32.pdf
> > documentation), are displayed on the 25th line of an HPTERM compatible
...
> Putting the error on the 25th line is a really good idea, but I can't
> see the 25th line because of the terminal control buttons ("Line
> Modify", "Modify All", etc).  I can't seem to get rid of them either.
> What's the trick?

On an 800 system console (i.e., a real HP terminal (or compatible/emulator)),
you'd press control-B and then you'd see the PDC status displayed on
line 25.  (you'll also get a command prompt)

To stop seeing it, enter "CO"<return>    (no quotes)

I've never tried it via the remote card mentioned earlier...I presume there's
a mechanism for doing the control-B signal...perhaps pressing control-B?
 
-- 
Stan Sieler                                          sieler@allegro.com
                                     http://www.allegro.com/sieler.html

Re: [parisc-linux] booting problems

[John David Anglin]

> And now it passes the LIF magic and checksum, and dies.  Here's a
> hand-typed copy of the console:
> 
> "
> Main Menu: Enter command > boot p2
> Interact with IPL (Y, N, or Cancel)?> n
> 
> Booting...
> Network Station Address 001039-037944
> System IP Address 192.168.1.56
> Server IP Address 192.168.1.52
> 
> Boot IO Dependant Code (IODC) revision 2
> 
> 
> SOFT Booted.
> "
> 
> And then absolutely nothing.  The cute little heart on the front panel

It is my guess that ipl has been incorrectly linked (i.e., the relocation
information for text and data are wrong for the LIF image).  Take a
look at the ld script hppaelf.sc in binutils.

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

Re: [parisc-linux] booting problems

[Alex deVries]

Alex deVries wrote:
> 
> Looks like we just need to compare a large chunk of the bootable binary
> to figure out what's happening.
> 

For kicks, I tried building the boot structure as it exists in the
kernel, and the kernel itself on HPUX.  I was thinking that maybe there
was a byte order probelm in the boot image generation tools.  I get
pretty much the same thing though, the parisc box just dies without even
entering the IPL code.

It's time to start digging deeper.  If someone else wants look over the
boot code in the kernel, it'd be appreciated.  I'm sure it's a simple
mistake.

The gist of it is this:

- Jason's existing prebuilt bootstrap binary does work
- my copy of his code with some build scripts used to generate a
bootstrap does not



- Alex

Re: [parisc-linux] booting problems

[Alex deVries]

Alex deVries wrote:
> 
> Okay, I've committed a couple of fixes to make the building of the
> bootable image go a bit smoother.  Thanks to John for his patch that
> doesn't require /dev/zero existing to create the sparse file.
> 
> And now it passes the LIF magic and checksum, and dies.  Here's a
> hand-typed copy of the console:
> 
> "
> Main Menu: Enter command > boot p2
> Interact with IPL (Y, N, or Cancel)?> n
> 
> Booting...
> Network Station Address 001039-037944
> System IP Address 192.168.1.56
> Server IP Address 192.168.1.52
> 
> Boot IO Dependant Code (IODC) revision 2
> 
> SOFT Booted.
> "
> 
> And then absolutely nothing.  

Okay, I'm a bit better off now.  I've at least located the problem.  I
copied the IPL straight out of Jason's binary, rebuilt, and it boots. 
The next task is to figure out why the cross compiled version of ipl is
broken, and how to fix it.

An immediate solution in my mind is just to distribute a binary version
of the ipl in the kernel tree...

The IPL can't seem to load and locate the kernel, but we'll get to this
later.

- Alex

Re: [parisc-linux] booting problems

[Jeffrey A Law]

  In message <3760CF80.887DA4C3@thepuffingroup.com>you write:
  > Okay, I'm a bit better off now.  I've at least located the problem.  I
  > copied the IPL straight out of Jason's binary, rebuilt, and it boots. 
  > The next task is to figure out why the cross compiled version of ipl is
  > broken, and how to fix it.
It could well be an endianness problem in the ELF tools if that's what you
are using to build stuff.

While we did at one point try to squash them, we may have missed some --
over the long haul dos-x-hppa-elf did not turn out to be all that popular
of a host-x-target combination (what a surprise).

BTW, did I mention that probably the first thing your kernel should do is
start mucking around with the leds?  They're an awful primitive, but highly
valuable debugging tool.

jeff

Re: [parisc-linux] booting problems

[John David Anglin]

>   In message <3760CF80.887DA4C3@thepuffingroup.com>you write:
>   > Okay, I'm a bit better off now.  I've at least located the problem.  I
>   > copied the IPL straight out of Jason's binary, rebuilt, and it boots. 
>   > The next task is to figure out why the cross compiled version of ipl is
>   > broken, and how to fix it.
> It could well be an endianness problem in the ELF tools if that's what you
> are using to build stuff.

While there could be an endianness problem, I think it more likely that
it is how IPL is being linked and extracted into the LIF image.  Jason's
link options, "-R 0 -N", specified a text origin of 0 and data following
the text.  I think the default for ELF is to place the text at 0x1000 and
data at 0x40000000.  The gnu ld equivalent for "-R 0" would appear to
be "-Ttext 0".  I am not sure there is a direct equivalent for "-N".
Maybe, you could use "-Tdata" to set the data location.  Maps might be
useful to sort out what is going on.  Also, the SOM and ELF headers at the
beginning of each binary may differ in size.  When I tried "-Ttext 0",
the size of the ELF header seemed to change in size.  I think there
is info in the header about its size, etc.

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

Re: [parisc-linux] booting problems

[Alex deVries]

John David Anglin wrote:
> 
> >   In message <3760CF80.887DA4C3@thepuffingroup.com>you write:
> >   > Okay, I'm a bit better off now.  I've at least located the problem.  I
> >   > copied the IPL straight out of Jason's binary, rebuilt, and it boots.
> >   > The next task is to figure out why the cross compiled version of ipl is
> >   > broken, and how to fix it.
> > It could well be an endianness problem in the ELF tools if that's what you
> > are using to build stuff.
> 
> While there could be an endianness problem, I think it more likely that
> it is how IPL is being linked and extracted into the LIF image.  

I think you're right.  I'm sure now that the byte order isn't a problem,
because my header and Jason's IPL work fine.

> Jason's
> link options, "-R 0 -N", specified a text origin of 0 and data following
> the text.  I think the default for ELF is to place the text at 0x1000 and
> data at 0x40000000.  The gnu ld equivalent for "-R 0" would appear to
> be "-Ttext 0".  I am not sure there is a direct equivalent for "-N".
> Maybe, you could use "-Tdata" to set the data location.  Maps might be
> useful to sort out what is going on.  

Definitely.  This should be the next step in sorting this out.

> Also, the SOM and ELF headers at the
> beginning of each binary may differ in size.  When I tried "-Ttext 0",
> the size of the ELF header seemed to change in size.  I think there
> is info in the header about its size, etc.

I was thinking that object formats wouldn't really matter in the end; in
the end we're doing straight binary with no loading information.

- Alex

Re: [parisc-linux] booting problems

[Kirk Bresniker]

Here's the offending code segment:

# adb Image-19990611-1

0x2000,10?i
2000:           LDO             -4(r31),r31
                LDIL            L%0x40008000,r1
                BE              1792(sr4,r1)      ; 0x40008000 + 1792 = 0x40008700 
                                                  ; this is the evil branch past
                                                  ; the end of memory identified
						  ; in the PIM dump
                OR              r31,r0,r2
                LDO             -4(r31),r31
                LDIL            L%0x2000,r1
                BE              228(sr4,r1)
                OR              r31,r0,r2
                LDO             -4(r31),r31
                LDIL            L%0x2000,r1
                BE              316(sr4,r1)
                OR              r31,r0,r2
                LDO             -4(r31),r31
                LDIL            L%0x2000,r1
                BE,N            1528(sr4,r1)
                LDO             -4(r31),r31
$q

KMB
--
+============================================================+
|       Kirk Bresniker    	(916) 785-5677		     |
|       8000 Foothills Blvd                                  |
|       Roseville, CA 95747-5649                             |
|       kirkb@rose.hp.com                                    |