[parisc-linux] Boot messages from C3000 console

[parisc-linux] Boot messages from C3000 console

[Paul Bame]

This is long.  Thanks to Alex Williamson for this -

The short answer is once control is apparently transferred to the
kernel, the system dies hard.  Someone who can read PIM dumps
might deduce more from this log.

	-Paul Bame

Information Menu: Enter command > io


I/O MODULE INFORMATION

                                                                     IODC IODC
Path         Decimal     Type                  Location   HVER SVER  Vers Dep
- ------------ ----------- --------------------- ---------- ---- ----  ---- ----
LAN          10/0/12/0   Ethernet              built-in   0060 a200  0x02 0x00
AUDIO        10/0/13/0   Audio                 built-in   
IDE          10/0/14/0   IDE                   built-in   0060 a300  0x00 0x00
SUPERIO MISC 10/0/14/1   Bridge Device         built-in   
SERIAL_1     10/0/14/1/1 RS232 Port            built-in   0060 8c00  0x01 0x00
SERIAL_2     10/0/14/1/2 RS232 Port            built-in   0060 8c00  0x01 0x00
PARALLEL     10/0/14/1/3 Parallel Port         built-in   
USB          10/0/14/2   USB                   built-in   0060 a900  0x98 0x00
SCSI         10/0/15/0   SCSI                  built-in   0060 a300  0x00 0x00
FWSCSI       10/0/15/1   SCSI                  built-in   0060 a300  0x00 0x00
GRAPHICS(2)  10/6/2/0    Display               slot 2     0070 8500  0x01 0x00

Information Menu: Enter command > ma

- ----- Main Menu -------------------------------------------------------------

      Command                           Description
      -------                           -----------
      BOot [PRI|ALT|<path>]             Boot from specified path
      PAth [PRI|ALT|CON|KEY] [<path>]   Display or modify a path
      SEArch [DIsplay|IPL] [<path>]     Search for boot devices

      COnfiguration [<command>]         Access Configuration menu/commands
      INformation [<command>]           Access Information menu/commands
      SERvice [<command>]               Access Service menu/commands

      DIsplay                           Redisplay the current menu
      HElp [<menu>|<command>]           Display help for menu or command
      RESET                             Restart the system
- -----
Main Menu: Enter command > bo lan.15.1.55.151

Interact with IPL (Y, N, Q)?> n



Booting... 
Network Station Address 001083-354faa

System IP Address 15.1.52.165
Server IP Address 15.1.55.151


Boot IO Dependent Code (IODC) revision 2




HARD Booted.


- ------------------------------------------------------------------------------

PARISC/Linux Bootstrap Version 0.6 (non-interactive)
By Helge Deller & Jason Eckhardt
Built Thu Oct 21 12:03:52 MDT 1999 by bame@burmese

Reading parameters...done.

Loading PA-RISC/Linux Kernel...
No ramdisks available.
SOM-Kernel:
aux_header_location: 00000080
som       : 00200080
exec_dfile: 000DD000
exec_dsize: 00084000
exec_dmem : C00A9000
exec_tfile: 00044000
exec_tsize: 00098008
exec_tmem : C0010000
Code at 0x00010000, size=0x00098008
Data at 0x000A9000, size=0x00084000
BSS  at 0x0012D000.

Transferring control to kernel. (At entry point 0x00010000)



Firmware Version 1.8


Duplex Console IO Dependent Code (IODC) revision 1

- ------------------------------------------------------------------------------

   (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved

- ------------------------------------------------------------------------------


  Processor   Speed            State           Coprocessor State  I/D Cache 

  ---------  --------   ---------------------  -----------------  -------------

      0      400 MHz    Active                 Functional         512 kB/1 MB

  Central Bus Speed:                   120 MHz

  Available memory:              805306368 bytes
  Good memory required:           82538496 bytes

  Primary boot path:    FWSCSI.6.0
  Alternate boot path:  SCSI.6.0
  Console path:         GRAPHICS(2)
  Keyboard path:        USB


CPU 0
WARNING:  Self tests have been disabled as a result of FASTBOOT
          being enabled.  To enable self tests, use the FASTBOOT
          command in the CONFIGURATION menu and reboot the system.
WARNING:  Memory has been initialized, but not tested as a result of
          FASTBOOT being enabled.  To test memory, use the FASTBOOT
          command in the CONFIGURATION menu and reboot the system.



Processor is starting auto boot process.


To discontinue, press any key within 10 seconds.


\aBoot terminated.

~`\x03x

- ----- Main Menu -------------------------------------------------------------

      Command                           Description
      -------                           -----------
      BOot [PRI|ALT|<path>]             Boot from specified path
      PAth [PRI|ALT|CON|KEY] [<path>]   Display or modify a path
      SEArch [DIsplay|IPL] [<path>]     Search for boot devices

      COnfiguration [<command>]         Access Configuration menu/commands
      INformation [<command>]           Access Information menu/commands
      SERvice [<command>]               Access Service menu/commands

      DIsplay                           Redisplay the current menu
      HElp [<menu>|<command>]           Display help for menu or command
      RESET                             Restart the system
- -----
Main Menu: Enter command > ser pim



PROCESSOR PIM INFORMATION



- -----------------  Processor 0 HPMC Information ------------------


Timestamp = 
  Thu Oct  21 20:18:08 GMT 1999    (19:99:10:21:20:18:08)

HPMC Chassis Codes = 2cbf0  2500b  2cbf5  2cbfc  

General Registers 0 - 31
00-03   0000000000000000  ffffffffffffffff  00000000000100c4  0000000000504000
04-07   0000000000504010  0000000000504000  0000000000000048  00000000f0002f88
08-11   0050427700000002  000000000000004d  000000000012c320  000000000000000a
12-15   0000000000000000  00000000ffffffff  0000000000000000  00000000f0400004
16-19   000000f0f00008a4  000000f0f0000160  000000f0f0000158  fffffffffff80810
20-23   0000000003000000  0000000000001000  0000000000000000  00000000000c0000
24-27   0000000000000000  0000000000000001  00000000c0159610  ffffffffc00a8000
28-31   ffffffffffffffff  00000000000ac948  00000000000ac400  0200000000000204

<Press any key to continue (q to quit)> 


Control Registers 0 - 31
00-03   0000000000000000  0000000000000000  0000000000000000  0000000000000000
04-07   0000000000000000  0000000000000000  0000000000000000  0000000000000000
08-11   0000000000000000  0000000000000000  0000000000000000  000000000000003c
12-15   0000000000000000  0000000000000000  0000000000000000  0000000000000000
16-19   0000001d9f33c26d  0000000000000000  0000000000010184  000000000e601181
20-23   00000000a627ffff  c0000000e0380810  0000000000000009  0000000080000000
24-27   00000000fdffffff  00000000ffffffff  0000000000000002  0000000008000009
28-31   00000000fdffffff  00000000ffffffff  00000000fdffffff  00000000fdffffff
Space Registers 0 - 7

00-03   00000000          00000000          00000000          00000000
04-07   00000000          00000000          00000000          00000000

<Press any key to continue (q to quit)> 

IIA Space                    = 0x0000000000000000
IIA Offset                   = 0x0000000000010188
Check Type                   = 0x20000000
CPU State                    = 0x9e000004
Cache Check                  = 0x00000000
TLB Check                    = 0x00000000
Bus Check                    = 0x0030103b
Assists Check                = 0x00000000
Assist State                 = 0x00000000
Path Info                    = 0x00000000
System Responder Address     = 0x000000fffff80810
System Requestor Address     = 0x000000fffffa0000

Floating-Point Registers 0 - 31
00-03   ffd00fbfffffffdf  ffffffffffffffff  ffffffffffffffff  ffffffffffffffff
04-07   ffffffffffffffff  ffffffffffffffff  ffffffffffffffff  ffffffffffffffff
08-11   ffffffffffffffff  ffffffffffffffff  ffffffffffffffff  ffffffffffffffff
12-15   ffffffffffffffff  ffffffffffffffff  ffffffffffffffff  ffffffffffffffff
16-19   ffffffffffffffff  ffffffffffffffff  ffffffffffffffff  ffffffffffffffff
20-23   ffffffffffffffff  ffffffffffffffff  ffffffffffffffff  ffffffffffffffff
24-27   ffffffffffffffff  ffffffffffffffff  ffffffffffffffff  ffffffffffffffff
28-31   ffffffffffffffff  ffffffffffffffff  ffffffffffffffff  ffffffffffffffff

<Press any key to continue (q to quit)> 


'B1000/C3000/J5000/J7000 Unarchitected (per-CPU)', revision 1, 140 bytes:

Check Summary                = 0xcb81041008000000
Available Memory             = 0x0000000030000000
CPU Diagnose Register 2      = 0x0200000000000204
CPU Status Register 0        = 0x2420c20000000000
CPU Status Register 1        = 0x8002000000000000
SADD LOG                     = 0x0000000000000000
Read Short LOG               = 0xc1af00fffff80810
ERROR_STATUS                 = 0x0000000000100010
MEM_ADDR                     = 0x000001ff3fffffff
MEM_SYND                     = 0x0000000000000000
MEM_ADDR_CORR                = 0x000001ff3fffffff
MEM_SYND_CORR                = 0x0000000000000000
RUN_DATA_HIGH                = 0xc1bff0fffed08040
RUN_DATA_LOW                 = 0xc1bff0fffed08040
RUN_CTRL                     = 0x0000021c00001418
RUN_ADDR                     = 0xc1bff0fffed08040
System Responder Path        = 0x00ffffffffffffff

<Press any key to continue (q to quit)> 


- -----------------  Processor 0 LPMC Information ------------------


Check Type                   = 0x00000000
I/D Cache Parity Info        = 0x00000000
Cache Check                  = 0x00000000
TLB Check                    = 0x00000000
Bus Check                    = 0x00000000
Assists Check                = 0x00000000
Assist State                 = 0x00000000
Path Info                    = 0x00000000
System Responder Address     = 0x0000000000000000
System Requestor Address     = 0x0000000000000000



- -----------------  Processor 0 TOC Information -------------------


General Registers 0 - 31
00-03   0000000000000000  000000f0f0093000  000000f0f000b658  00000000000f4240
04-07   00000020317d230d  0000000000000004  000000f0f0407aa8  0000000000000000
08-11   000000f0f0407aa8  000000000000004d  000000000012c320  000000000000000a
12-15   0000000000000000  00000000ffffffff  0000000000000000  00000000f0400004
16-19   000000f0f00008a4  000000f0f0000160  000000f0f0000158  000000f0f0077270
20-23   000000f0f05f0068  0000000000000004  0000000000000008  000000f0f003c3ac
24-27   0000000009f9c6f0  000000003d090000  0000000017d78400  000000f0f0412000
28-31   0000000017d78400  0000000000000008  000000f0f0407d68  000000f0f00772f0

<Press any key to continue (q to quit)> 


Control Registers 0 - 31
00-03   0000000000000000  0000000000000000  0000000000000000  0000000000000000
04-07   0000000000000000  0000000000000000  0000000000000000  0000000000000000
08-11   0000000000000000  0000000000000000  0000000000000000  0000000000000005
12-15   0000000000000000  0000000000000000  000000f0f0003800  0000000000000000
16-19   000000203b7aaa7c  00000000000000f0  000000f0f000b664  00000000020008b8
20-23   000000009237c3c1  0000000001c07d10  000000ff0809cf08  0000000080000000
24-27   00000000fdffffff  00000000ffffffff  0000000000000002  0000000008000009
28-31   00000000fdffffff  00000000ffffffff  00000000fdffffff  00000000fdffffff
Space Registers 0 - 7

00-03   00000000          00000000          00000000          00000000
04-07   00000000          00000000          00000000          00000000

IIA Space                    = 0x00000000000000f0
IIA Offset                   = 0x000000f0f000b65c
CPU State                    = 0x0000004d


<Press any key to continue (q to quit)> 


Memory Error Log Information:


Timestamp = 
  Thu Oct  21 20:18:08 GMT 1999    (19:99:10:21:20:18:08)


'B1000/C3000/J5000/J7000 Memory Error Log', revision 0, 64 bytes:

   No memory errors logged




I/O Module Error Log Information:


Timestamp = 
  Thu Oct  21 20:18:08 GMT 1999    (19:99:10:21:20:18:08)


'B1000/C3000/J5000/J7000 IO Error Log', revision 0, 228 bytes:

 Rope     Word1        Word2            Word3
- ------ ------------ ------------
   0    0x00000000   0x0e0cc009   0x00000000fed30048
   1    0x00000000   0x1e0cc009   0x00000000fed32048
   2    ----------   0x2e0cc009   ------------------
   3    ----------   0x3e0cc009   ------------------
   4    0x00000000   0x4e0cc009   0x00000000fed38048
   5    ----------   0x5e0cc009   ------------------
   6    0x00000000   0x6e0cc009   0x00000000fed3c048
   7    ----------   0x7e0cc009   ------------------
Main Menu: Enter command > 
- --------------6D46321F53F67470D064CBF0--



------- End of Forwarded Message

Re: [parisc-linux] Boot messages from C3000 console

[Stan Sieler]

Re:

Don't know if this helps at all...

> kernel, the system dies hard.  Someone who can read PIM dumps
> might deduce more from this log.
...
> HPMC Chassis Codes = 2cbf0  2500b  2cbf5  2cbfc  

In a possibly not-quite-matching manual:

   cbf0 = HPMC occurred
   500b = bus timeout (slot 0, bus 0)
   cbf5 = IVA+32 was equal to 0
   cbfc = branch to os HPMC failed
 
> General Registers 0 - 31
> 00-03   0000000000000000  ffffffffffffffff  00000000000100c4  0000000000504000
> 04-07   0000000000504010  0000000000504000  0000000000000048  00000000f0002f88
> 08-11   0050427700000002  000000000000004d  000000000012c320  000000000000000a
> 12-15   0000000000000000  00000000ffffffff  0000000000000000  00000000f0400004
> 16-19   000000f0f00008a4  000000f0f0000160  000000f0f0000158  fffffffffff80810
> 20-23   0000000003000000  0000000000001000  0000000000000000  00000000000c0000
> 24-27   0000000000000000  0000000000000001  00000000c0159610  ffffffffc00a8000
> 28-31   ffffffffffffffff  00000000000ac948  00000000000ac400  0200000000000204
> 
> <Press any key to continue (q to quit)> 
> 
> 
> Control Registers 0 - 31
> 00-03   0000000000000000  0000000000000000  0000000000000000  0000000000000000
> 04-07   0000000000000000  0000000000000000  0000000000000000  0000000000000000
> 08-11   0000000000000000  0000000000000000  0000000000000000  000000000000003c
> 12-15   0000000000000000  0000000000000000  0000000000000000  0000000000000000
> 16-19   0000001d9f33c26d  0000000000000000  0000000000010184  000000000e601181
> 20-23   00000000a627ffff  c0000000e0380810  0000000000000009  0000000080000000
> 24-27   00000000fdffffff  00000000ffffffff  0000000000000002  0000000008000009
> 28-31   00000000fdffffff  00000000ffffffff  00000000fdffffff  00000000fdffffff
> Space Registers 0 - 7
> 
> 00-03   00000000          00000000          00000000          00000000
> 04-07   00000000          00000000          00000000          00000000
> 
> IIA Space                    = 0x0000000000000000
> IIA Offset                   = 0x0000000000010188
...
> System Responder Address     = 0x000000fffff80810
> System Requestor Address     = 0x000000fffffa0000


CR19 (IIR) = e601181 = LDWAS    0(0,19),1

So, looks like an absolute load was being done, using R19 as the address:

   R19 = fffffffffff80810

The "System Responder Address", whatever that is, is 0x000000fffff80810
which is suspciciously similar to what's in R19.

SS

Re: [parisc-linux] Boot messages from C3000 console

[Frank Rowand]

Paul Bame wrote:
> 
> This is long.  Thanks to Alex Williamson for this -
> 
> The short answer is once control is apparently transferred to the
> kernel, the system dies hard.  Someone who can read PIM dumps
> might deduce more from this log.
> 
>         -Paul Bame


Look in the IO ARS, under PDC_PIM() for info on decoding this stuff.
I'll decode a couple of key words, but I have to run to a meeting.


> Main Menu: Enter command > ser pim
> 
> PROCESSOR PIM INFORMATION
> 
> - -----------------  Processor 0 HPMC Information ------------------
> 
> Timestamp =
>   Thu Oct  21 20:18:08 GMT 1999    (19:99:10:21:20:18:08)
> 
> HPMC Chassis Codes = 2cbf0  2500b  2cbf5  2cbfc
> 
> General Registers 0 - 31
> 00-03   0000000000000000  ffffffffffffffff  00000000000100c4  0000000000504000
> 04-07   0000000000504010  0000000000504000  0000000000000048  00000000f0002f88
> 08-11   0050427700000002  000000000000004d  000000000012c320  000000000000000a
> 12-15   0000000000000000  00000000ffffffff  0000000000000000  00000000f0400004
> 16-19   000000f0f00008a4  000000f0f0000160  000000f0f0000158  fffffffffff80810
> 20-23   0000000003000000  0000000000001000  0000000000000000  00000000000c0000
> 24-27   0000000000000000  0000000000000001  00000000c0159610  ffffffffc00a8000
> 28-31   ffffffffffffffff  00000000000ac948  00000000000ac400  0200000000000204
> 
> <Press any key to continue (q to quit)>
> 
> Control Registers 0 - 31
> 00-03   0000000000000000  0000000000000000  0000000000000000  0000000000000000
> 04-07   0000000000000000  0000000000000000  0000000000000000  0000000000000000
> 08-11   0000000000000000  0000000000000000  0000000000000000  000000000000003c
> 12-15   0000000000000000  0000000000000000  0000000000000000  0000000000000000
> 16-19   0000001d9f33c26d  0000000000000000  0000000000010184  000000000e601181
> 20-23   00000000a627ffff  c0000000e0380810  0000000000000009  0000000080000000
> 24-27   00000000fdffffff  00000000ffffffff  0000000000000002  0000000008000009
> 28-31   00000000fdffffff  00000000ffffffff  00000000fdffffff  00000000fdffffff
> Space Registers 0 - 7
> 
> 00-03   00000000          00000000          00000000          00000000
> 04-07   00000000          00000000          00000000          00000000
> 
> <Press any key to continue (q to quit)>
> 

This should be the address of the instruction that caused the HPMC.  Use adb
against the kernel to see what this instruction is.  Then you'll probably
need to use the contents of the general registers above to figure out what
was going on:
> IIA Space                    = 0x0000000000000000
> IIA Offset                   = 0x0000000000010188

Bus check:
> Check Type                   = 0x20000000


> CPU State                    = 0x9e000004
> Cache Check                  = 0x00000000
> TLB Check                    = 0x00000000

Read timeout:
> Bus Check                    = 0x0030103b

> Assists Check                = 0x00000000
> Assist State                 = 0x00000000
> Path Info                    = 0x00000000

Someone needs to look at an address map to see what address was being accessed:
> System Responder Address     = 0x000000fffff80810

cpu 0 is the requestor:
> System Requestor Address     = 0x000000fffffa0000



Off to the meeting...

-Frank Rowand

Re: [parisc-linux] Boot messages from C3000 console

[Grant Grundler]

Paul Bame wrote:
> The short answer is once control is apparently transferred to the
> kernel, the system dies hard.  Someone who can read PIM dumps
> might deduce more from this log.

I can't find a PIM decoder for the C3000....I'll try the J5000
decoder later. Here's a few more notes by hand.
I saw Stan Sieler's reply and can fill in a few more gaps.

> HPMC Chassis Codes = 2cbf0  2500b  2cbf5  2cbfc

The bus time-out suggests the processor tried to access
0xfffff80810 and no device lives there.  The processor saw
an error condition (bus timeout) and brought the system down.

...
> IIA Space                    = 0x0000000000000000
> IIA Offset                   = 0x0000000000010188
> Check Type                   = 0x20000000
> CPU State                    = 0x9e000004
> Cache Check                  = 0x00000000
> TLB Check                    = 0x00000000
> Bus Check                    = 0x0030103b
> Assists Check                = 0x00000000
> Assist State                 = 0x00000000
> Path Info                    = 0x00000000
> System Responder Address     = 0x000000fffff80810
> System Requestor Address     = 0x000000fffffa0000

Responder is the address which was supposed to respond.
Requestor is the address of the device which started the transaction.
I would guess 0xff_fffa0000 is the processor.

What's at 0xff_fff80000?
And which driver uses offset 0x810?
(card-mode Dino does....but am pretty sure the kernel didn't get that far.)


This is the interesting part:

> 'B1000/C3000/J5000/J7000 Unarchitected (per-CPU)', revision 1, 140 bytes:
> 
> Check Summary                = 0xcb81041008000000
> Available Memory             = 0x0000000030000000
> CPU Diagnose Register 2      = 0x0200000000000204
> CPU Status Register 0        = 0x2420c20000000000
> CPU Status Register 1        = 0x8002000000000000
> SADD LOG                     = 0x0000000000000000
> Read Short LOG               = 0xc1af00fffff80810
	This is another copy of the offending address.

> ERROR_STATUS                 = 0x0000000000100010
	Broad Error on the Runway Bus
	
> MEM_ADDR                     = 0x000001ff3fffffff
> MEM_SYND                     = 0x0000000000000000
> MEM_ADDR_CORR                = 0x000001ff3fffffff
> MEM_SYND_CORR                = 0x0000000000000000
	No memory problems.

> RUN_DATA_HIGH                = 0xc1bff0fffed08040
> RUN_DATA_LOW                 = 0xc1bff0fffed08040
	Last data on runway before the error.
	0xFF_FEDO_8000 is runway bus interface register space.

> RUN_CTRL                     = 0x0000021c00001418
> RUN_ADDR                     = 0xc1bff0fffed08040
	Last ctrl/addr on the runway bus before the error.

> System Responder Path        = 0x00ffffffffffffff
	NULL path - default value. Not PCI related.
...


On K/T-class system, the I/O error log was invaluable.
Not sure how useful it is on this set of boxes.
I'm sure we'll see.

> 'B1000/C3000/J5000/J7000 IO Error Log', revision 0, 228 bytes:
> 
>  Rope     Word1        Word2            Word3
> - ------ ------------ ------------
>    0    0x00000000   0x0e0cc009   0x00000000fed30048
>    1    0x00000000   0x1e0cc009   0x00000000fed32048
>    2    ----------   0x2e0cc009   ------------------
>    3    ----------   0x3e0cc009   ------------------
>    4    0x00000000   0x4e0cc009   0x00000000fed38048
>    5    ----------   0x5e0cc009   ------------------
>    6    0x00000000   0x6e0cc009   0x00000000fed3c048
>    7    ----------   0x7e0cc009   ------------------

Grant Grundler
Unix Developement Lab
+1.408.447.7253

Re: [parisc-linux] Boot messages from C3000 console

[Frank Rowand]

Paul Bame wrote:
> 
> This is long.  Thanks to Alex Williamson for this -
> 
> The short answer is once control is apparently transferred to the
> kernel, the system dies hard.  Someone who can read PIM dumps
> might deduce more from this log.
> 
>         -Paul Bame

< detailed HPMC info deleted>


We found it...

I'm cutting this from another discussion, don't feel like re-typing it.
The file we are talking about (giving line number references) is head.S.
We calculated the the offending offset was at label "blargh" plus a bit.

The following discussion talks about how we get to the code section
where the HPMC occurs.  Earlier, we talked about hard-coding magic
addresses, which are machine specific (that's in the macro "debug",
which is what actually caused the HPMC -- line 162).


<ggg> I was looking at how we get to blargh and don't get it. Only one
  location branches there.
> yes, it compares r28 to zero
> ah, r28 is the return value from the procedure called from line 265 (duhhhh)
> r1 is loaded at line 251 (the value of MEM_PDC, from page zero)
> That should be the entry point to PDC.
> So there's an error returned by the pdc call at line 265.
> calling PDC_BLOCK_TLB().  [arg0 = 18].  PDC_BLOCK_TLB doesn't exist on a
  PA2.0 server (and I assume the same for workstations), because block TLB
  entries don't exist, we have variable size pages instead.


Then I get a little incensed at the coding style here.... (editing out other
people's responses to my tirade)


> This is a **bogus** way to write code.  Comments should be required!!!!!! 
  Is there any way to encourage that?
> But I'm *extremely* serious about that.  This code is unmaintainable in it's
  current form.  It's going to be miserable adding 2.0 support to something
  like that.
> it's important to anyone who would like to pick up head.S and be able to
  read it.  To decode the procedure call I had to know where to find
  documentation for page zero, know what PDCE_PROC is, figure out what PDC
  procedure was being called.
> For me, it was about 45 seconds instead of the two seconds it would take to
  read a comment.
> For someone who doesn't have my background, it could be hours.


Ok, tirade mode off.  This is where my newbie status becomes apparent.  Please
excuse any foot in mouth here.  I looked at the Puffin web page and didn't
notice anything about the process of making sure that code that is submitted
has some minimal level of quality.  Is it just a matter of the community
applying peer pressure?

-Frank Rowand

Re: [parisc-linux] Boot messages from C3000 console

[Jason Eckhardt]

On Thu, 21 Oct 1999, Frank Rowand wrote:

>   read it.  To decode the procedure call I had to know where to find
>   documentation for page zero, know what PDCE_PROC is, figure out what PDC
>   procedure was being called.
> This is where my newbie status becomes apparent. 

   Yes. 

> excuse any foot in mouth here.  I looked at the Puffin web page and didn't
> notice anything about the process of making sure that code that is submitted
> has some minimal level of quality.  Is it just a matter of the community
> applying peer pressure?
> 

  We could institute ECN's (engineering change notices, for those of you
  who've never worked for HP) if that would help :)...

  But seriously, this is an important concern. Normally, there would be
  a "maintainer" who would review code for accuracy, cleanliness, quality,
  etc. before allowing it to be checked in. That person was me at one time,
  but due to tremendous time pressures, I gave up on that.

  jason.
 

Re: [parisc-linux] Boot messages from C3000 console

[Alex deVries]

On Thu, 21 Oct 1999, Frank Rowand wrote:
> Ok, tirade mode off.  This is where my newbie status becomes apparent.  Please
> excuse any foot in mouth here.  I looked at the Puffin web page and didn't
> notice anything about the process of making sure that code that is submitted
> has some minimal level of quality.  Is it just a matter of the community
> applying peer pressure?

In fact, it's *ALL* about the community applying pressure.

If the code in head.S is a bit rough, remember that it was just about the
first PA-RISC assembler that Helge or Philipp had ever written, so do keep
that in mind.  Also, at the start of the project, there was a very
conscious effort to only be concerned with 1.1 code.  It doesn't surprise
me in the least that it's not 2.0 compliant.

I agree that the code is unreadable though;  I've simply passed it off on
not being able to understand parisc assembler well enough.

We'd all appreciate it if you could commit appropriate changes to make the
code clearer.

- Alex

Re: [parisc-linux] Boot messages from C3000 console

[Helge Deller]

Am Fri, 22 Oct 1999 schrieb Alex deVries:
> On Thu, 21 Oct 1999, Frank Rowand wrote:
> > Ok, tirade mode off.  This is where my newbie status becomes apparent.  Please
> > excuse any foot in mouth here.  I looked at the Puffin web page and didn't
> > notice anything about the process of making sure that code that is submitted
> > has some minimal level of quality.  Is it just a matter of the community
> > applying peer pressure?
> 
> In fact, it's *ALL* about the community applying pressure.
> 
> If the code in head.S is a bit rough, remember that it was just about the
> first PA-RISC assembler that Helge or Philipp had ever written, so do keep
> that in mind.  Also, at the start of the project, there was a very
> conscious effort to only be concerned with 1.1 code.  It doesn't surprise
> me in the least that it's not 2.0 compliant.
> 
> I agree that the code is unreadable though;  I've simply passed it off on
> not being able to understand parisc assembler well enough.
> 
> We'd all appreciate it if you could commit appropriate changes to make the
> code clearer.
> 
> - Alex

Thanks Alex,

Yes, we all know that the boot-loader really needs a complete clean-up, and as
it looks like I´m the maintainer of the bootloader. 

It´s really funny to see people from HP talking to the list and saying somthing
about code-quality, but only as a little reminder:
When I wrote the bootloader I had no documentation on bootloading from HP at
all, no knowledge of parisc and got it only working with trial & error methods
in day and night-sessions. More, it´s first goal was to get at least a kernel
booted so that the real kernel-development could start. (See my messages in the
commits) The end of this all was this really ugly bootloader with many until
now unused enhancements (ELF-loader and ramdisk-support) which can be easily
removed.

More I think there are currently MUCH MORE IMPORTANT things to be fixed in the
kernel than beautifying a (mostly) working bootloader which will be completely
rewritten in the future. When time has come and we have clean code to read
filesystems like LIF and HFS, then this can be easily integrated into a
completely rewritten PALO (PArisc-LOader).

But currently I have nearly no time at all (as many others on this list), so if
anyone has time to fix things, beautify the code and send me patches or
enhancements I really would like to integrate them at once.
SO: PLEASE don´t talk about quality of source code (we all know, that the
bootloader is bad!) , just send patches !!!!!

NB: It seems, that many people wants to talk about this over and over again.
All this was already said some weeks ago.....

Helge Deller.

Re: [parisc-linux] Boot messages from C3000 console

[Frank Rowand]

Helge Deller wrote:
> 
> Am Fri, 22 Oct 1999 schrieb Alex deVries:
> > On Thu, 21 Oct 1999, Frank Rowand wrote:
> > > Ok, tirade mode off.  This is where my newbie status becomes apparent.  Please
> > > excuse any foot in mouth here.  I looked at the Puffin web page and didn't
> > > notice anything about the process of making sure that code that is submitted
> > > has some minimal level of quality.  Is it just a matter of the community
> > > applying peer pressure?
> >
> > In fact, it's *ALL* about the community applying pressure.
> >
> > If the code in head.S is a bit rough, remember that it was just about the
> > first PA-RISC assembler that Helge or Philipp had ever written, so do keep
> > that in mind.  Also, at the start of the project, there was a very
> > conscious effort to only be concerned with 1.1 code.  It doesn't surprise
> > me in the least that it's not 2.0 compliant.
> >
> > I agree that the code is unreadable though;  I've simply passed it off on
> > not being able to understand parisc assembler well enough.
> >
> > We'd all appreciate it if you could commit appropriate changes to make the
> > code clearer.
> >
> > - Alex
> 
> Thanks Alex,
> 
> Yes, we all know that the boot-loader really needs a complete clean-up, and as
> it looks like I´m the maintainer of the bootloader.
> 
> It´s really funny to see people from HP talking to the list and saying somthing
> about code-quality, but only as a little reminder:
> When I wrote the bootloader I had no documentation on bootloading from HP at
> all, no knowledge of parisc and got it only working with trial & error methods
> in day and night-sessions. More, it´s first goal was to get at least a kernel
> booted so that the real kernel-development could start. (See my messages in the

<stuff deleted>

First, thanks to all for the gentle replies.  I like this community!!

Alex, I guess I wasn't clear enough about what my issue was.  I wasn't complaining
about the actual code (I try to avoid that, as long as code is mostly correct
(works)).  My concern was that I, with twelve years experience with PA-RISC
(including four different OSs - MPE, NextStep, HP-RT, and HP-UX), had to go to
external documentation to read what is trivial code (a PDC call) when a
one line comment would have made it obvious that the code was calling
PDC_BLOCK_TLB().  For me, just annoying - for someone who might be missing one
or two of the bits of knowledge, potentially a multi-hour sidetrack to
understand some trivial code.  I want to encourage people to make the code
easily readable so I don't have to waste a lot of time when my help is requested
to debug or contribute code.

Helge, I wasn't complaining about the boot-loader, I think you are mixing two
different threads together.  And I'm not complaining about the algorithms,
the instructions coded, correctness of code, or anything like that.  I'm just
saying that the sequence that I had to read in head.S to figure out the
cause of the HPMC on the C3000 needed at least a comment to make it readable
without having to know about and consult external documents.  (And Grant made
a good point that using defines instead of numbers can also increase
readability significantly).

And yes, I suspect that adding the comment to the code will be my first
submission to parisc linux (how embaressing to submit a comment before
submitting any code!).

Thanks all,

Frank Rowand

Re: [parisc-linux] Boot messages from C3000 console

[Philipp Rumpf]

> one line comment would have made it obvious that the code was calling
> PDC_BLOCK_TLB().  For me, just annoying - for someone who might be missing one

I agree that adding "using PDC_BLOCK_TLB" to the "setup the BTLB" comment might
have been a good idea.

> understand some trivial code.  I want to encourage people to make the code
> easily readable so I don't have to waste a lot of time when my help is requested
> to debug or contribute code.
>
> saying that the sequence that I had to read in head.S to figure out the
> cause of the HPMC on the C3000 needed at least a comment to make it readable

I somehow get the impression what you are suggesting is the author of this
code (i.e. me) wrote this code, left for some weeks and you were forced to fix
this bug.  What I did was to leave for 38 hours.  

Of course it would be nice to have as little code as possible in the tree only
the author understands, and we don't have very much, but I don't think we'll
ever get rid of the last bits of "unreadable" code (in fact, there's enough of
that in the architecture-independent parts to spend a long and busy life
ranting about it).  You found some.

Now what you could have done is comment the code, change the code to use
#defines, yell at the author, yell at the author in public, or start a
discussion on how to avoid ever having any unreadable code in the kernel at
all.

You chose (possibly among other possibilities) to have a discussion.  I am
not sure which effect you intended it to have, but I am pretty sure the effect
it is going to have, if any, is to waste lots of time that otherwise would
have gone into development, both in the discussion itself and in enforcing
any rules that we "agree upon" (i.e. about which one side gets too tired to
argue about).

My impression is we'll save a lot of time by simply yelling at each other
about bad code as long as the number of developers and users is as low as it
currently is and most likely will be within the next 6 months.

	Philipp Rumpf

Re: [parisc-linux] Boot messages from C3000 console

[Ryan Bradetich]

[-- Attachment #1: Type: text/plain, Size: 4515 bytes --]

Frank Rowand wrote:

> Helge Deller wrote:
> >
> > Am Fri, 22 Oct 1999 schrieb Alex deVries:
> > > On Thu, 21 Oct 1999, Frank Rowand wrote:
> > > > Ok, tirade mode off.  This is where my newbie status becomes apparent.  Please
> > > > excuse any foot in mouth here.  I looked at the Puffin web page and didn't
> > > > notice anything about the process of making sure that code that is submitted
> > > > has some minimal level of quality.  Is it just a matter of the community
> > > > applying peer pressure?
> > >
> > > In fact, it's *ALL* about the community applying pressure.
> > >
> > > If the code in head.S is a bit rough, remember that it was just about the
> > > first PA-RISC assembler that Helge or Philipp had ever written, so do keep
> > > that in mind.  Also, at the start of the project, there was a very
> > > conscious effort to only be concerned with 1.1 code.  It doesn't surprise
> > > me in the least that it's not 2.0 compliant.
> > >
> > > I agree that the code is unreadable though;  I've simply passed it off on
> > > not being able to understand parisc assembler well enough.
> > >
> > > We'd all appreciate it if you could commit appropriate changes to make the
> > > code clearer.
> > >
> > > - Alex
> >
> > Thanks Alex,
> >
> > Yes, we all know that the boot-loader really needs a complete clean-up, and as
> > it looks like I´m the maintainer of the bootloader.
> >
> > It´s really funny to see people from HP talking to the list and saying somthing
> > about code-quality, but only as a little reminder:
> > When I wrote the bootloader I had no documentation on bootloading from HP at
> > all, no knowledge of parisc and got it only working with trial & error methods
> > in day and night-sessions. More, it´s first goal was to get at least a kernel
> > booted so that the real kernel-development could start. (See my messages in the
>
> <stuff deleted>
>
> First, thanks to all for the gentle replies.  I like this community!!
>
> Alex, I guess I wasn't clear enough about what my issue was.  I wasn't complaining
> about the actual code (I try to avoid that, as long as code is mostly correct
> (works)).  My concern was that I, with twelve years experience with PA-RISC
> (including four different OSs - MPE, NextStep, HP-RT, and HP-UX), had to go to
> external documentation to read what is trivial code (a PDC call) when a
> one line comment would have made it obvious that the code was calling
> PDC_BLOCK_TLB().  For me, just annoying - for someone who might be missing one
> or two of the bits of knowledge, potentially a multi-hour sidetrack to
> understand some trivial code.  I want to encourage people to make the code
> easily readable so I don't have to waste a lot of time when my help is requested
> to debug or contribute code.
>
> Helge, I wasn't complaining about the boot-loader, I think you are mixing two
> different threads together.  And I'm not complaining about the algorithms,
> the instructions coded, correctness of code, or anything like that.  I'm just
> saying that the sequence that I had to read in head.S to figure out the
> cause of the HPMC on the C3000 needed at least a comment to make it readable
> without having to know about and consult external documents.  (And Grant made
> a good point that using defines instead of numbers can also increase
> readability significantly).
>
> And yes, I suspect that adding the comment to the code will be my first
> submission to parisc linux (how embaressing to submit a comment before
> submitting any code!).
>

Sorry I haven't responded to this thread earlier .... (Spent last week traveling ...)
I've been working on trying to figure out
how the boot-loader works, and get it to work on the C200+ (which is PA-RISC 2.0)  I'm
going to assume the
C3000 is also PA-RISC 2.0 also.  I've gone through and attempted to clean up clean up
the code and put in
comments so that I could understand it.  (I've attach my modified head.S.  Be gentle
.... this is my first attempt at
PA-RISC assembly)

Since there seems to be other interest in getting this to work, I'd be very interested
in sharing what I have learned,
and working with others to get this to work.

-Ryan Bradetich who is finally home again.
P.S I really want to help on this port, but I can't until it boots on the C200.

>
> Thanks all,
>
> Frank Rowand
>
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.

[-- Attachment #2: head.S --]
[-- Type: text/plain, Size: 8086 bytes --]

/*
 *
 * This file is subject to the terms and conditions of the GNU General Public
 * License.  See the file "COPYING" in the main directory of this archive
 * for more details.
 *
 * Copyright (C) 1999 by Helge Deller
 * Copyright 1999 SuSE GmbH (Philipp Rumpf, prumpf@suse.de)
 *
 * Initial Version 04-23-1999 by Helge Deller (helge.deller@ruhr-uni-bochum.de)
 */


/* ---------------------------------------------------------------------------
 *
 * $Log: head.S,v $
 * Revision 1.32  1999/08/31 19:25:23  prumpf
 * fixes
 *
 * Revision 1.30  1999/08/21 19:07:07  prumpf
 * removed the initrd stuff for now
 *
 * Revision 1.29  1999/08/21 17:08:27  prumpf
 * debugging
 *
 * Revision 1.28  1999/08/10 15:44:35  prumpf
 * changes for having the kernel virtually mapped
 *
 * Revision 1.27  1999/08/06 17:05:11  prumpf
 * cleaned up a bit
 *
 * Revision 1.26  1999/07/24 00:00:41  deller
 *
 * * first work on initrd
 *
 * Revision 1.25  1999/07/21 00:30:34  deller
 *
 * * renamed some symbols in head.S (for mmu-code)
 * * the same changes in setup.c
 * * removed irq_setup() from setup.c (not used).
 *
 * Revision 1.24  1999/07/16 10:26:41  prumpf
 * Fixed some of the obvious problems so interruptions will work again
 *
 * Revision 1.23  1999/07/15 13:52:59  deller
 *
 * * found the problem, why kernel stopped with booting via hpux-loader:
 *   the hpux-bootloader did not zero-initialized the BSS segment, so
 *   that all uninitialized variables from kernel was in undefined state.
 * * the kernel now zero-initializes the BSS segment itself
 * * the memory-adress of the first free byte is now the same, it doesn't
 *   matter if you boot via hpux-loader or our ipl-loader....
 *
 * -> Now booting all ways (network, CD, HDD, hpux) should be OK !
 *
 * Revision 1.22  1999/07/14 09:36:52  deller
 *
 * * cache will be reset, when init_cache() is called,
 * * fatal() is called, when a function from fixme.c is called,
 * * the Kernel now gets the (yet static) command-line from the bootloader.
 *
 * Revision 1.21  1999/07/13 23:33:30  deller
 *
 * next approach on Phillips' bug-report. (better, should work, but not optimal!)
 * the bogompis/irq-detection hangs when booted via hpux-bootloader,
 * it seems that some general irq-flags has to be set in head.s or irq.c (?)
 *
 * Revision 1.20  1999/07/13 20:59:29  deller
 *
 * Phillip, would you try again with this....
 * Please remove the boot/boot_code/ipl-file before (maybe it's now done
 * automatically).
 *
 * Revision 1.18  1999/07/13 01:23:25  deller
 *
 * small changes in fixme.c - (it would be good to remove that file),
 * better memory-optimization in head.S for booting from the local hpux-bootloader
 * (tested with HP-UX 10.20).
 *
 * Revision 1.17  1999/07/09 21:54:44  deller
 *
 *
 * Fixed the hpux-bootloader-problem !
 * The problem was in head.S (where I assumed, that we always start the kernel
 * from our own bootloader).
 *
 * Now you can do:
 * boot pri isl
 * hpux /stand/vmlinux
 *
 * Revision 1.16  1999/07/08 15:47:31  prumpf
 * stack alignment is 64 bytes
 *
 */

/* 			FIXME !!!
    When vmlinux was started by the hpux-bootloader, then I don't know
    the size of the BSS-Data, which follows the end of the vmlinux-file.
    I did some debugging-tests here, and it seemed, that %arg3=%r23 will get 
    the HALF of the size of BSS from the bootloader, so I implemented that !
    If anybody has real documentation, please contact me:
    Helge Deller <helge.deller@ruhr-uni-bochum.de> or <deller@gmx.de>
    
    (NB: The commands for booting are: "boot pri isl" and "hpux /stand/vmlinux").

    Maybe I should mention, that this problem does not exist, when vmlinux
    was started by our own bootloader.

    Helge Deller, 99-07-13
*/

#define	PA(x) ((x)-0xc0000000)

#include <asm/offset.h>
#include <asm/psw.h>

	.level 1.1

	.space $TEXT$
	.subspa $UNWIND_START$,QUAD=0,ALIGN=8,ACCESS=0x2C,SORT=56
	.export $UNWIND_START
$UNWIND_START
	.subspa $UNWIND_END$,QUAD=0,ALIGN=8,ACCESS=0x2C,SORT=73
	.export $UNWIND_END
$UNWIND_END

	.space $TEXT$
	.subspa $FIRST$
	.import start_parisc,code
	.import init_task_union,data
	.import fault_vector,code
	.import	$global$
	
	.export stext
	.export _stext,data		; Kernel want it this way!
	.export $START$,entry
$START$	
_stext
stext
	.proc
	.callinfo

	copy		%r0,%dp			; Debug

	ldil		L%$global$,%dp		; Initialize the global
	ldo		R%$global$(%dp),%dp	; data pointer (%dp)
	
	ldil		L%TASK_SZ_ALGN,%r13
        ldo             R%TASK_SZ_ALGN(%r13),%r13
	
	ldil		L%PA(init_task_union+TASK_SZ_ALGN),%sp
	ldo		R%PA(init_task_union+TASK_SZ_ALGN)(%sp),%sp

	copy 		%sp,%r12		; Debug
	/*
	 * There are 2 possible methods, how vmlinux was started:
	 *
	 * 1. It was started by our own ipl-bootloader:
	 *     	%arg0=Kernel_MemFreeStart ( >= offset(_bss_start)) [not used!]
	 *	%arg1=ptr to the command line
	 *	%arg3(=%r23) holds HALF(!) of the size of the BSS-Segment 
	 *
	 * 2. It was started by the hpux-bootloader:
	 *	%arg0 should then be lower than offset(_bss_start)
	 * 	%arg1= ????? [not used!]
	 *	%arg3(=%r23) holds HALF(!) of the size of the BSS-Segment 
	 */

	ldil		L%_bss_start-0xc0000000,%r10
	ldo		R%_bss_start-0xc0000000(%r10),%r10	; _bss_start

	comclr,<<	%r10,%arg0,%r0		; is %arg0 < offset _bss_start ??
	copy		%r0,%arg1	

	sh1add		%arg3,%r10,%arg0	; _bss_start + 2*(bss_size)
	depi		3,1,2, %arg0            ; 0xC0000000 + %arg0

	/* Why are we setting up the BTLB?  */
	/* setup the BTLB.  XXX: This assumes a unified BTLB */
	ldo		128(%sp),%sp
	stw		%arg0, -128(%sp)
	stw		%arg1, -124(%sp)
	stw		%arg2, -120(%sp)
	stw		%arg3, -116(%sp)

	/* What are we doing here? */
	ldo		0x388(%r0), %r1		; What is the significance of 0x388?
						; 0x388 (Page C-3) Start of MEM_PDC[32-63]

	ldwax		%r0(%r1), %r1 	 	; ldwax does not exist in PA-RISC 2.0??
						; Do we need this statement??

	ldo		18(%r0), %arg0		; (Page C-4) MEM_PF_LEN (Checksum for MEM_POW_FAIL)
	ldo		1(%r0), %arg1		; (Page C-4) MEM_POW_FAIL
	ldil		L%0xc0000, %arg3        ; What this significance of this statement?
	ldo		0(%r0), %arg2           ; (Page C-4) 0

	ldil		L%0x00000000, %r22	; Start of PAGE0 Data format (C-3)?
	stw		%r22, -52(%sp)

	ldo		4096(0), %r22		; What is the significance of 0x4096?
	stw		%r22, -56(%sp) 		; End of the PAGE0 Data format (C-3)?

	ldil		L%0x03000000, %r22	; What is the significance of 0x03000000?
	stw		%r22, -60(%sp)

	ldo		0(%r0), %r22		; We already stored 0 once ... Why again?
	stw		%r22, -64(%sp)

	ldil		L%PA(.+12),%r2	        ; Not sure what this is doing ..... 
	bv		%r0(%r1)		; %r1 is set by ldil ...	
	ldo		R%PA(.+4)(%r2), %r2	; No clue about this either ... (.+4)  -> pc-relative

	/* Restore the origional values of %arg0 - %arg3 from the stack */
	ldw		-128(%sp), %arg0
	ldw		-124(%sp), %arg1
	ldw		-120(%sp), %arg2
	ldw		-116(%sp), %arg3
	ldo		-128(%sp), %sp
	
	/* Load the fault vector into %r10 */
	ldil		L%PA(fault_vector), %r10
	ldo		R%PA(fault_vector)(%r10), %r10
	
	/* Move the fault vector into %iva (%cr14) */
	mtctl		%r10, %iva

	/* Store the following value 0xF(%sp{2..31})
	depi		3, 1, 2, %sp
	/* Store this value to a temporary control register ....
	mtctl		%r0, %cr30

	mtsm		%r0			; Disable (most) interruptions

	
	/* kernel PSW:
	 *  - no interruptions except for HPMC and TOC (which are handled by PDC)
	 *  - Q bit set (IODC / PDC interruptions)
	 *  - big-endian
	 *  - virtually mapped
	 */
#define KERNEL_PSW 0x4000a
	
	/* Set the C, Q, and D bits */
	ldil		L%KERNEL_PSW,%r10
	ldo		R%KERNEL_PSW(%r10),%r10
	mtctl		%r10,%ipsw 
	
	mtctl		%r0,%cr17		; Clear two-level IIA Space Queue
	mtctl		%r0,%cr17		;    effectively setting kernel space.
	ldil		L%start_parisc,%r10
	ldo		R%start_parisc(%r10),%r10

	mtctl		%r10,%cr18
	ldo		4(%r10),%r10
	mtctl		%r10,%cr18

	mtctl		%arg0, %cr0

	rfi
	nop
	.procend

	.space	$PRIVATE$
	.subspa	$GLOBAL$
	.export	$global$,data
	.export	_data_start,data
$global$
_data_start
	.word 0	

/* offset(_bss_start) is the start of the $BSS-segment in vmlinux */

	.space	$PRIVATE$
	.subspa $BSS$,QUAD=1,ALIGN=8,ACCESS=31,ZERO,SORT=82
	.export	_bss_start,data
_bss_start

Re: [parisc-linux] Boot messages from C3000 console

[Philipp Rumpf]

> Yes, we all know that the boot-loader really needs a complete clean-up, and as
> it looks like I´m the maintainer of the bootloader. 

This isn't bootloader code though.

Re: [parisc-linux] Boot messages from C3000 console

[Grant Grundler]

Alex deVries wrote:
...
> If the code in head.S is a bit rough, remember that it was just about the
> first PA-RISC assembler that Helge or Philipp had ever written, so do keep
> that in mind.  Also, at the start of the project, there was a very
> conscious effort to only be concerned with 1.1 code.  It doesn't surprise
> me in the least that it's not 2.0 compliant.
> 
> I agree that the code is unreadable though;  I've simply passed it off on
> not being able to understand parisc assembler well enough.

Alex,
I think you are walking around Frank's point:
	It doesn't matter which language the code is written in.
	The code should be readable by a wide audience.
	(Understanding will still be limited to a subset)

(Corallary: Because it's assembler, comments and #define's are required
for clarity and there were none.)

> We'd all appreciate it if you could commit appropriate changes to make the
> code clearer.

That's what I suggested earlier to him. My sense is the "Open Source Way"
(similar to the "HP Way") is to do, not to complain.

[ soapbox on ]
I agree with Frank's gripe too...IMHO, it would be really bad thing for
parisc-linux if he not to contribute.  My point is contributors should
remember out of 6 billion other people on the planet, a few capable ones
will choose to look at the code because they want to add functionality or
fix "bugs". And they can change their mind after the first look.

And worse would be if only-slightly-less-capable folks contribute stuff which
breaks various platforms (we'll get there). And even with well commented,
supportable code, it could take a while to sort out which code is "broken"
and which platforms it's needed on. I would prefer if someone like Frank
just did it right the first time around...but if I can't have that I'd
at least like him to help look at problems in the successive passes.
[ soapbox off ]


grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

[parisc-linux] Trying to boot on an N-Class

[Justin Hamilton]

Here's what I get when trying to boot the kernel on an N-Class:

Firmware Version  39.25

Duplex Console IO Dependent Code (IODC) revision 1

----------------------------------------------------------------------------
--
   (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved
----------------------------------------------------------------------------
--

  Processor   Speed            State           CoProcessor State  CacheSize
  Number                                       State              Inst
Data
  ---------  --------   ---------------------  -----------------  ----------
--
      1      360  MHz   Active                 Functional         512KB   1
MB
      3      360  MHz   Idle                   Functional         512KB   1
MB

  Central Bus Speed (in MHz)  :        120
  Available Memory            :    2097152  KB
  Good Memory Required        :     140844  KB

   Primary boot path:    1/10/0/0.8
   Alternate boot path:  0/0/2/1.6
   Console path:         0/0/4/0.0
   Keyboard path:        0/0/4/0.0


Processor is booting from first available device.

To discontinue, press any key within 10 seconds.

Boot terminated.

Main Menu: Enter command or menu > bo 1/10/0/0.8.1
Interact with IPL (Y, N, or Cancel)?> n

Booting...
Boot IO Dependent Code (IODC) revision 1


HARD Booted.

----------------------------------------------------------------------------
--

PARISC/Linux Bootstrap Version 0.6 (non-interactive)
By Helge Deller & Jason Eckhardt
Built Wed Oct 20 04:01:37 EDT 1999 by chris@rum

Reading parameters...done.

Loading PA-RISC/Linux Kernel...
No ramdisks available.
SOM-Kernel:
aux_header_location: 00000080
som       : 00200080
exec_dfile: 000B4000
exec_dsize: 0007F000
exec_dmem : C008A000
exec_tfile: 0003A000
exec_tsize: 00079008
exec_tmem : C0010000
Code at 0x00010000, size=0x00079008
Data at 0x0008A000, size=0x0007F000
BSS  at 0x00109000.

Transferring control to kernel. (At entry point 0x00010000)

And this is where it sits.

Is this kind of info useful to anyone?  Am I expecting too much at this
stage in development?

Justin Hamilton
Unix Systems Engineer.

Re: [parisc-linux] Trying to boot on an N-Class

[Grant Grundler]

"Justin Hamilton" wrote:
> Here's what I get when trying to boot the kernel on an N-Class:
...
> And this is where it sits.
> 
> Is this kind of info useful to anyone? 

Not to me. (yet). But I have access to N-class machines.

> Am I expecting too much at this stage in development?

Definitely. Firmware on N-class is *quite* different from the
of two flavors of PDC we have the current code talking to.
And none of the CEC (Core Electronics Complex - CPU, Mem, I/O bus
adapters) in an N-class are supported by the code in CVS today.
We are quite a ways off from implementing everything N-class needs.
The docs for that box are not (and probably won't be) published
for quite a while.

The next step in that direction is probably to write PA2.0 processor
support and support for the "ccio" bus adapter. Then try to get this
working on a C200 through C360. I know some folks are working on the
processor support but docs for "ccio" haven't been released.
(Or have they?)

thanks though,
grant

Grant Grundler
Unix Developement Lab
+1.408.447.7253

Re: [parisc-linux] Trying to boot on an N-Class

[Philipp Rumpf]

> exec_tfile: 0003A000
> exec_tsize: 00079008
> exec_tmem : C0010000
> Code at 0x00010000, size=0x00079008
> Data at 0x0008A000, size=0x0007F000
> BSS  at 0x00109000.
> 
> Transferring control to kernel. (At entry point 0x00010000)
> 
> And this is where it sits.

This looks like it is the same PA 2.0 PDC problem we see on the C class.
Could you try againg after we fixed it ?  (Don't expect the kernel to do
too much with your hardware in the near future, but at least you might
be able to get to a shell prompt).

	Philipp Rumpf

Re: [parisc-linux] Boot messages from C3000 console

[Philipp Rumpf]

> I'm cutting this from another discussion, don't feel like re-typing it.
> The file we are talking about (giving line number references) is head.S.
> We calculated the the offending offset was at label "blargh" plus a bit.
> 
> The following discussion talks about how we get to the code section
> where the HPMC occurs.  Earlier, we talked about hard-coding magic
> addresses, which are machine specific (that's in the macro "debug",
> which is what actually caused the HPMC -- line 162).

The debug macro should indeed have been empty (and is, now).  Sorry for that.

> Then I get a little incensed at the coding style here.... (editing out other
> people's responses to my tirade)
> 
> 
> > This is a **bogus** way to write code.  Comments should be required!!!!!! 
>   Is there any way to encourage that?

there is a comment on top of the section of code in question

	/* setup the BTLB.  XXX: This assumes a unified BTLB */"

which I agree isn't as verbose as it could be but it seems not to hard to me
to get to "we do a PDC_BLOCK_TLB call now" from "setup the BTLB".

> > But I'm *extremely* serious about that.  This code is unmaintainable in it's
>   current form.  It's going to be miserable adding 2.0 support to something
>   like that.

indeed it is, which is one of the reasons I proposed to wrap the virtually-mapped
kernel in a physically-mapped som binary which could do these pdc calls in C (and
would remove the need for most of head.S)

> > it's important to anyone who would like to pick up head.S and be able to
>   read it.  To decode the procedure call I had to know where to find
>   documentation for page zero, know what PDCE_PROC is, figure out what PDC
>   procedure was being called.
> > For me, it was about 45 seconds instead of the two seconds it would take to
>   read a comment.
> > For someone who doesn't have my background, it could be hours.

I cannot exactly remember whether this was based on gcc-generated code, but I
am pretty sure it was, which might explain why it doesn't use macros (of course,
it would have been a good idea to include the C code as comment in this case).

	Philipp Rumpf