Diskless booting of Amiga

[freqmax]

Perhaps this is homing in on how to do it:
archive.org: 1993 Thomson randy Rhett anderson Mapping Amiga 2nd edition

"Here is a sample structure, Resident, which is used to make programs that can
survive a reboot."

If it's simple as making a program resident when running the computer under normal conditions. And when it works just write it to a ROM memory area. It would be very simple indeed. Perhaps this is the way RAD: survives too?

Include File: exec/resident.h

elowar.com: exec/resident.h

Code: [Select]

struct Resident {
    UWORD rt_MatchWord; /* word to match on (ILLEGAL) */
    struct Resident *rt_MatchTag; /* pointer to the above */
    APTR  rt_EndSkip; /* address to continue scan */
    UBYTE rt_Flags; /* various tag flags */
    UBYTE rt_Version; /* release version number */
    UBYTE rt_Type; /* type of module (NT_XXXXXX) */
    BYTE  rt_Pri; /* initialization priority */
    char  *rt_Name; /* pointer to node name */
    char  *rt_IdString; /* pointer to identification string */
    APTR  rt_Init; /* pointer to init code */
};
And a dissembly of the ramdrive.device RAD: for comparision with above:
wandel.ca: ramdrive_disassembly.txt (Commodore-Amiga Ram Drive 1.0 1988-04-06)

Code: [Select]

000004  4AFC                         RT_MATCHWORD
000006  0000 0004                    RT_MATCHTAG - pointer back to above
00000A  0000 026C                    RT_ENDSKIP
00000E  01                           RT_FLAGS - RTF_COLDSTART is set
00000F  01                           RT_VERSION
000010  03                           RT_TYPE - NT_DEVICE
000011  14                           RT_PRI - Priority 20
000012  0000 0142                    RT_NAME
000016  0000 0152                    RT_IDSTRING
00001A  0000 026C                    RT_INIT
Is it as simple to just put the above structure in a EEPROM and make it available in the 68k memory space ..?

[Zac67]

If you don't want to a 'boot from elsewhere but then stay resident and survive a reboot' scenario the Resident structure is useless.
You'll need either a boot ROM or a modified Kickstart with integrated drivers. Why not use a boot ROM with flash memory that's already there and easy to use?

[delshay]

One of many good point of a bootable PCMCIA slot is you can boot direct from OS3.1 or OS3.9 if a accelerator is present or even 4.x with small changes for compact flash. You maybe can even use part of the compact flash as fast ram. I don't know if the above is possible but its worth a look.

If you wanted to throw everything in you could add sockets for FastATA chips as well,so you could end up with a single board that flash the roms,support 4x clockport,support FastATA and anything their care to add via a single board.

ALL MODIFICATION AT YOUR OWN RISK AND I AM NOT RESPONSIBLE FOR WHAT USER(S) DO.

[freqmax]

So where do I find the source code for a boot ROM ..?

Anyway it seems the RAD: calls AddDevice(), MakeDOSNode(), Enqueue(), OpenLibrary()/RT_INIT to add itself to the system after reboot.
(MakeLibrary()?)

Found this amigaos.net/../Example_Device but it's still a block one.

http://wandel.ca/homepage/amiga_sw/scsi/autoboot.txt

(2) Get "ramkick" from the 1.4 Alpha 16 (or higher) release, and use it
    to install the module "bootstrap".  This is untested, as I don't have
    1.4 Alpha 16, and therefore don't have "ramkick".

This wandel.ca/../devices_doc.txt says it:

Devices in ROM are found during a scan of the entire ROM for RomTag
structures.

[Mrs Beanbag]

I think the main requirement for making code ROMmable is that it be pure. In other words it doesn't store variables inside its own code but always uses the stack or allocated memory. Which is kind of obvious, really. If something is in ROM it can't write to itself so it would get a bit stuck. Apparently anything written in C should be safe as long as you don't use global variables. I have been moving towards this approach in my own code, I should aim to make Mr Beanbag "pure" as a matter of principle.

[freqmax]

So is NetFS "clean" ?

[Mrs Beanbag]

I don't know, try this on it, see if it works:
http://aminet.net/package/util/boot/LoadModule

Whether that is enough for it to survive a reboot remains to be seen. And I doubt it would be bootable without modification in any case.

[Mrs Beanbag]

See also this thread that I started on EAB, (well, that a mod started by moving my posts! which was fair enough)
http://eab.abime.net/support-other/69540-bootable-network-file-system-rom-amiga.html

[freqmax]

anfs + LoadModule seems neat but looking at the anfs source code deeply. One can see that it uses a global variable Global_T defined for use in nfs_handler.c. The next catch is that one needs to tell nfs_handler what to do ie "anfs server:/amigasystem BOOT:".

Perhaps some "Global_T *g" combined with "g = (Global_T *)malloc(..)" and instead of ParseArgs() one can write DCHP_Args() or DummyArgs(). Would solve these issues?

So perhaps this would work:
 * Make globals allocated with malloc()
 * Write static ParseArgs()
 * Call "LoadModule"
 * Save the module from RAM to a file
 * Write said file onto a EEPROM
 * Done?


Something I just can't get is how it uses FindDosEntry() just to collision detect the local devicename and then go on with AddDosEntry() and be able to receive (DOS) packets with Wait() for said local volume, ie if one open() a file or similar. But how does Wait() know which filesystem eg "BOOT:" that is sought? nfs_handler.c has to supply it somewhere?

(FindDosEntry() and AddDosEntry() seems to use struct DevInfo for "name" info)

Perhaps dosextens.h define is the solution to dos.library existance early in the boot process?:

#define DLT_LATE   3   /* late-binding assign */

(Source code for the DLT_LATE seems to be possible to read at label "AssignLate" in the DOS.lzx archive of dos.library.asm)

[freqmax]

Regarding the thread at abime.net:

The following has to be present in ROM:
 * SANA-II driver (for network hardware)
 * IP + UDP stack
 * NFS client

He says dos.library has to be present. Perhaps one could rather add a hook that will be activated when said library is present? it could then initialize SANA-IP-UDP-NFS in one go.

If there absolutely has to be a "disk" present. One could create a few kB "ROM:" with a bootblock and directory entry. Once dos.library feels to show up one does a switch-and-bait and changes this so that it will access the NFS server instead. Just like one can replace files on a live filesystem under NFS/unix.

[freqmax]

Found this nice example in comp.os.research in 1993:
User-level Filesystems (was Re: Plan 9)

Nice example.  For comparison, I'll post an AmigaDOS filesystem.  I'm
writing this off the top of my head, so it probably would need tweaking to
compile.  AmigaDOS, like QNX, converts requests into messages sent to a user-
level process.  I'll try to keep it short and leave out non-relevant parts,
including most of the error-checking.

        Note: this is for a ram disk.  Also, for historical reasons from
Tripos and BCPL, many DOS pointers are BPTR's (longword offsets; i.e. pointers
shifted right by 2.  Ugh.)

Code: [Select]

#include <various header files>

struct DosPacket {
   struct Message *dp_Link;      /* EXEC message              */
   struct MsgPort *dp_Port;      /* Reply port for the packet */
                                 /* Must be filled in each send. */
   LONG dp_Action;               /* See ACTION_... below and
   LONG dp_Res1;                 /* For file system calls this is the result
                                  * that would have been returned by the
                                  * function, e.g. Write returns actual
                                  * length written */
   LONG dp_Res2;                 /* For file system calls this is what would
                                  * have been returned by IoErr() */
   LONG dp_Arg1;                    
   LONG dp_Arg2;
   LONG dp_Arg3;
   ...

};

struct node *root;
struct lock *lock_list;
struct MsgPort *MyPort;
LONG res1,fileerr;

main (struct DosPacket *dp) {
        struct Message    *msg;
        struct DeviceList *devnode,*newnode;
        struct node *node;
        ULONG arg1;

        /* various shared library opens/inits */
        ...

        MyPort = &(FindTask(NULL)->pr_MsgPort);

        root = (struct node *) AllocVec(sizeof(struct node),MEMF_CLEAR);
        root->type = ST_USERDIR;
        strcpy(root->name,&quot;Ram Disk&quot;);
        lock_list  = NULL;
        spaceused  = 1;

        /* add our volume entry to the system */
        newnode = MakeDosEntry(&quot;Ram Disk&quot;,DLT_VOLUME);
        newnode->dl_Task     = MyPort;
        newnode->dl_DiskType = ID_DOS_DISK;
        DateStamp(&(newnode->dl_VolumeDate));
        AddDosEntry(newnode);

        /* our Device node already exists - BPTR */
        devnode = (struct DeviceList *) (dp->dp_Arg3 << 2);
        devnode->dl_Task = MyPort;

        /* init finished successfully, tell system we're ready */
        ReplyPkt(dp,DOS_TRUE,0);

        while (1) {
            sigs = Wait(1L << MyPort->mp_SigBit);

            /* handle dospackets */
            while ((msg = GetMsg(MyPort)) != NULL)
            {
                dp = (struct DosPacket *) msg->mn_Node.ln_Name;

                /* set result to failure, clear secondary result */
                res1 = fileerr = 0;

                /* used by most functions-usually BPTR to filehandle or lock */
                arg1 = dp->dp_Arg1 << 2;       /* save space, do it once */

                switch (dp->dp_Action) {
                case ACTION_WRITE:      /* Write(fh,buffer,len) */
                        res1 = write((struct lock *) arg1,
                                     (CPTR) dp->dp_Arg2, dp->dp_Arg3);
                        break;
                case ACTION_READ:       /* Read(fh,buffer,len */
                        res1 = read((struct lock *) arg1,
                                    (CPTR) dp->dp_Arg2, dp->dp_Arg3);
                        break;
                case MODE_NEWFILE:      /* fh = Open(name,MODE_NEWFILE) */
                        flag = 0;
open:
                        res1 = openmakefile(
                                       (struct FileHandle *) arg1,
                                       (struct lock *) (dp->dp_Arg2 << 2),
                                       BtoC(str1,dp->dp_Arg3),
                                       flag);
                        break;
                case ACTION_END:        /* aka Close(fh) */
                        res1 = closefile((struct lock *) arg1);
                        break;
                etc...

                case ACTION_INHIBIT:
                case ACTION_GET_BLOCK:
                case ACTION_MORE_CACHE:
                default:
                        fileerr = ERROR_ACTION_NOT_KNOWN;
                } /* switch */

                /* we've handled the packet, return it */
                ReplyPkt(dp,res1,fileerr);

            } /* while GetMsg */
        } /* while 1 */
}

Hint at function replacements over kickstart versions?
abime.net/attachment.php?attachmentid=33641&d=1356876093

To reduce code size, can use V36+ functions like LockDosList() instead of Forbid()/Permit(), and MakeDosEntry(). Also use RemDosEntry() and FreeDosEntry() to replace most of code in RemoveFreeDosEntry routine at offset $3352.

[Zac67]

The RKRM chapter 27 pretty much explains it all.

[freqmax]

So RKRM - ROM Kernel Reference Manuals..
"Chapter 27 Graphics Primitives" seems wrong?

Page 702 "ROM Based and Autoboot Drivers" seems interesting however..

Of the three stages DIAG, ROMTAG INIT and BOOT. The last one perhaps is the deal.

Need to figure these out, especially how the first one finds out the name of the volume in the source code:
http://gega.homelinux.net/AmigaDevDocs/dos.html#adddosentry() in nfs_handler.c main()

MakeDosEntry(g->g_VolumeName, DLT_VOLUME) in nfs_handler.c G_Init()

MakeDosEntry(g->g_DeviceName, DLT_DEVICE) in nfs_handler.c G_Init()

[freqmax]

I read the discussion at eabime and I think Toni makes some assumptions about implementation that isn't required. Ie one can make SANA-II + UDP/IP driver that manages being in ROM and it can collect any configuration information from DHCP. And TCP isn't even needed.

So it would go something like this:
 * Called via da_DiagPoint
 * Network ROM allocates RAM for variables etc (likely be EEPROM in reality)
 * Hooks Resident structure
 * Quits
 * ....
 * Called via Resident structure
 * Hooks eb_MountList
 * Quits
 * ....
 * Called via eb_MountList
 * Initializes SANA-II driver
 * Initializes IP driver
 * Requests it's own IP+mask+gateway+DNS+fileserver etc by sending DHCP request
 * Initializes UDP driver
 * Initializes NFS driver
 * Creates boot volume assign to BOOT: (or whatever DHCP told it too)
 * DOS can now happily read S:Startup-sequence etc..

The only worry would be this:

- DOS gets initialized (via BootPoint "bootblock")

Because a filesystem (not blocksystem) well.. won't have any blocks.

Amiga ROM Kernel Reference Manual: Libraries, 3rd edition, page 702 mentions DIAG, ROMTAG INIT and BOOT. Which seems to be about:

DIAG:

will also include the da_DiagPoint ROM/diagnostic routine, a Resident structure (romtag), a device driver (or at least the device initialization tables or structures which need patching), and the da_BootPoint routine.

(p703)

ROMTAG INIT:

most resident system modules (for example graphics) are initialized. /../ the board’s device driver is initialized.

(p709)
(this is likely the stage at which Picasso96 etc will start generating video etc)

BOOT:

will examine the eb_MountList; find the highest priority BootNode structure at the head of the List; validate the BootNode; determine which ConfigDev is associated with this BootNode; find its DiagArea; and call its da_BootPoint function in the ROM "image" to bootstrap the appropriate DOS. Generally, the BootPoint code of a ROM driver will perform the same function as the boot code installed on a floppy disk, i.e., it will FindResident() the dos.library, and jump to its RT_INIT vector. The da_BootPoint call, if successful, should not return.

(p709)
I assume this means dos.library is available..

For network this should translate into:
DIAG: Allocate memory
ROMTAG INIT: Tell network hardware to enable itself, hook into eb_MountList.
BOOT: First call to the network driver da_BootPoint routine fires up any missing parts that requires dos.library

[Mrs Beanbag]

I don't know what is meant by a bootblock for non-block devices but you can definitely boot from RAD which isn't a block device.

NFS doesn't need TCP? Really?

[freqmax]

NFS only need TCP if you configure it too. It can use any protocoll.

Some common missconceptions:
 * You need IP to communicate. No you can use MAC layer directly just like ARP does
 * TCP/IP stack is required. Infact quite a lot can be done with just IP, like ICMP_ECHO. Which some trojans used to "phone-home".
 * And TCP/IP usually refer to IP + UDP + TCP in that complication order. But IP is the only one required to support UDP or TCP.
 * Most things can be done with UDP which is really simple to implement, it's just that TCP makes things a lot easier.
 * NFS can be configured to use either UDP or TCP. Eliminating TCP saves some codes of programming.

So a minimalistic approach would be to use MAC layer directly with the SANA driver. Very incompatible, but it could do the job.