It was already reported on this list that JS1 with OpenBoot 3.x resets
immediately after downloading boot.net.  If the console is on ttya you
can see "Data Access Exception" error message.

I've dug around and at the IEEE 1275 Open Firmware Home Page

    <http://playground.sun.com/1275/home.html>

have found IEEE draft std. P1275.1/D14a (sparc supplement)

    <http://playground.sun.com/1275/bindings/sparc/d14a/12751d1a.ps>

that describes the format that 'load' expects:

|   Offset  Name       Contents 
|        0  bf_magic   0x0103.0107. 
|        4  bf_text    Size of the client program's code. 
|        8  bf_data    Size of the client program's initialized data. 
|       12  bf_bss     Size of the client program's uninitialized data area. 
|       16  bf_pad1    Undefined. 
|       20  bf_origin  Client program entry address. 
|       24  bf_pad2    Undefined. 
|       28  bf_format  0xffff.ffff. 
|
| The program image immediately follows the header.  After recognizing
| this header, load allocates and maps bf_text + bf_data + bf_bss bytes
| of memory beginning at the address given by bf_origin, moves the
| program image, of size bf_text + bf_data, to that address, and zeroes
| bf_bss bytes of memory beginning at bf_origin + bf_text + bf_data.
| 
| NOTE - Some existing client programs use other values in bf_format.
| An Open Firmware implementation may implement compatibility modes to
| handle such client programs.  The details of such compatibility modes
| are outside the scope of this standard.


This is our boot.net header:

    0000000   01030107 30800007 00000000 00000000
    0000020   00000000 00000000 00000000 00000000

which is, as installboot.c, explains:

    .word   MAGIC           ! a NOP (branch never)
    ba,a    start           !
    .skip   24              ! pad
  start:


Compare that to proll:

              magic    text     data     bss
    0000000   01030107 0000cddc 00000000 0000ff94
              pad      origin   pad2     format
    0000020   00000000 00004000 00000000 00000000


So could it be that OpenBoot 3.x simply interprets the jump
(0x30800007) as the text segment size and attempts to allocate that
much memory and fails?

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen