booting problems
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
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 | | [email protected] |
Quoted 5 lines · Kirk Bresniker
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.
Quoted 11 lines
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.
Quoted 4 lines
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?
Quoted 5 lines
Chassis codes, see the
PDC_CHASSIScall 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
| | 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 | | [email protected] |
Re:
Quoted 1 line
| No, we don't have remote manatement cards, but it sounds like they'd be
...
Quoted 3 lines
display the chassis codes sent by the
PDC_CHASSIScall. 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?
Quoted 5 lines
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)
Signature · 2 lines
Stan Sieler [email protected] http://www.allegro.com/sieler.html
Re:
Quoted 2 lines
Quoted 2 lines
Chassis codes, see the
PDC_CHASSIScall in your pdc32.pdf documentation), are displayed on the 25th line of an HPTERM compatible
...
Quoted 4 lines
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?
Signature · 2 lines
Stan Sieler [email protected] http://www.allegro.com/sieler.html
Quoted 12 lines
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)?> nBooting...
Network Station Address 001039-037944 System IP Address 192.168.1.56 Server IP Address 192.168.1.52
Quoted 7 lines
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.
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Quoted 4 lines · Alex deVries
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
Quoted 17 lines · 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/zeroexisting 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)?> nBooting...
Network Station Address 001039-037944
System IP Address 192.168.1.56
Server IP Address 192.168.1.52
Quoted 6 lines
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
In message <[email protected]>you write:
Quoted 4 lines
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
Quoted 7 lines
In message <[email protected]>you write:
Quoted 4 lines
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
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Quoted 11 lines · John David Anglin
Quoted 8 lines
In message <[email protected]>you write:
Quoted 4 lines
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.
Quoted 7 lines
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 at0x1000and data at0x40000000. 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.
Quoted 4 lines
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
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 | | [email protected] |