Diskless booting of Amiga

[Zac67]

The Deneb USB controller (A3k or 4k only, of course) can be used to load all required system software disklessly. For writable storage you could just add a USB stick. You could also use it to load any network drivers and continue booting from a share.

In theory, Kickstart supports any imaginable boot method through a suitable boot ROM - just like any bootable SCSI card.

[Mrs Beanbag]

Guess I'm missing something? but why would you want to?

There are many reasons. It is often done to install operating systems on computers that don't have optical drives, especially laptops.

I wished I could do this when I upgraded my A1200's HDD to a SSD, I had to make a boot floppy with a minimal AmiTCP/FTP on, which was a nightmare since my floppy drive was playing up.

[Dr.Bongo]

There are many reasons. It is often done to install operating systems on computers that don't have optical drives, especially laptops.

I wished I could do this when I upgraded my A1200's HDD to a SSD, I had to make a boot floppy with a minimal AmiTCP/FTP on, which was a nightmare since my floppy drive was playing up.

Fair point, I've never had to install os3.9 without an optical drive so the thought never crossed my mind. I feel that I've learnt something.

[freqmax]

Once you have a fileserver in your network. It makes upgrades etc way easier by just plugging in a network cable and just boot. Centralized backup etc.

The blocks on the disk is only needed to find where filedirectory is? and Amiga kickstart only need specific files? I have a memory it's possible to boot with an empty floppy and get CLI prompt in 320 pixel wide shell window?

So how should a expansion ROM driver that hooks into the filesystem layer look like? a SCSI ROM ought to hook itself into the block layer.
An experimental ROM could provide a preloaded boot disk from ROM just to see if it works.

[Mrs Beanbag]

you can indeed get to a shell window (hires, 640x256 I think) just by making a blank disk bootable. If you put the loadwb command on there as well and a startup-sequence, you can get a workbench as well. Workbench is in ROM and only needs a function call to activate it! It isn't very functional without all of the system tools and utilities that come on the workbench disk, but you can click on disk icons and run programs from it, so you could run software that wasn't on bootable disks.

Disk blocks are a feature of physical disks, there is no reason a RAM/ROM filesystem has to use them, although it might be convenient to do so. I've no idea how the RAM: drive is formatted in memory.

In the ROM my guess is you could have a structure internally the same as a RAM drive with files on it, and then mount it the same way you'd mount RAM or RAD, only it would have things on it already. So I think it would be very simple to do. I should get the AROS 68k source and have a play with it on an emulator.

[Zac67]

There are two different types of DOS devices: block devices with (usually) a physical structure underneath and a file system on top, and file handlers without, like a RAM disks or a network redirect. Take a look at the old mountlist entries and you get the main idea.

[Mrs Beanbag]

I was wondering just now, presumably it should be possible to make a NFS device that survives a reboot like a RAD disk does. That could be powerful.

[freqmax]

The catch is that AROS 68k doesn't run on the (E)UAE on unix..
But the AROS 68k source code could hint on the hooks required to write a driver. And perhaps some driver for MS-FAT could give enough info on how to provide a filesystem. Ie instead of calling a blockdriver it would call a network driver and supply filenames instead of sector numbers.

Anyway, looking at the nice illustration here:
http://www.jeacle.ie/pub/articles/amitcp/


It seems what has to be preloaded is:
 * SANA-II device driver for Ethernet
 * AmiTCP driver for SANA-II
 * NFS driver for AmiTCP

Such that Kickstart ask "nfs.driver" .. "dude where's my startup-sequence?" .. "dude where's my demo.lha?" etc..

Seems PUAE supports emulation of bsdsocket.library. The catch being that it may be in an unconsistent state at boot time. And will not allow itself to be preloaded..

A source for a skeleton file handler (device) that will attach itself at boot will go a long way.

[freqmax]

Some further thoughts:

MessyDOS (MSH) consists of file handler (vfat) and device driver (mfm). The source is included as well. If one removes the mfm part and rewrites the vfat. It could be a base for a network filesystem.

How would one transform it to be a expansion ROM image and show up at boot by installing it as a ROM at 0xF0 000 instead of enabling it when running the operating system?

[Mrs Beanbag]

There is already an open source Network File System for Amiga, here:

http://sourceforge.net/projects/anfs/

I wouldn't know how to get it into a ROM image though.

[Zac67]

@freqmax: A block device filesystem has little to do with a network filesystem.

@Mrs Beanbag: You could easily put everything you need for NFS into a RAD disk and reboot from that. No real need to make the device itself survive reboot.

[freqmax]

anfs seems interesting.

@freqmax: A block device filesystem has little to do with a network filesystem.

Sure, but it also has a part which handles requests for files, and that part can be used as a basis to serve files with other methods.

And I like a clean solution that makes it possible to use RAD:, RAM:, DF0: etc for other things. It might also be hard to make that RAD: if there's nothing drive at all to begin with.

[Mrs Beanbag]

@Mrs Beanbag: You could easily put everything you need for NFS into a RAD disk and reboot from that. No real need to make the device itself survive reboot.

Of course. But the aim is to be able to boot from the NFS. And that, without having any disk to boot from first. If we have NFS on a disk we don't need to put it in RAD afterall! Or if it is in ROM...

If one had in ROM a basic network capability, and a command line that requires no boot disk (RAM drive can be booted), the NFS driver could be pulled from the network first, mounted (reset-proof) and then booted.

[Mrs Beanbag]

Just got message from someone on EAB, Toni Wilen has made a Rommable version of PFS/3, see here:
http://eab.abime.net/881562-post29.html

[freqmax]

Perhaps this SCSI driver can hint on how to make things ROM:able?

http://eab.abime.net/coders-system/67067-open-source-scsi-device.html
http://wt.exotica.org.uk/test.html
http://wt.exotica.org.uk/files/test/SCSI.lzx
https://en.wikipedia.org/wiki/LZX_(algorithm)#Amiga_LZX

[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 ..?