Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: freqmax on June 06, 2013, 09:05:10 PM
-
Is it possible to network boot an Amiga without any disk system whatsoever? (no floppy, hdd etc) Especially is there any code in Kickstart to support this?
Some systems just can't be without their boot blocks.
Like PXE on PCs.
-
no
-
maybe a custom ROM could be made. that could be interesting actually. You could boot from the network if you could do that.
-
Kind of reminds me of harddisk controllers. They often have a boot-ROM. Perhaps pre-loading filesystem via a ROM driver is the only way to do it?
Guess that would be:
CPU loads cold boot vector
Kickstart runs
Kickstart jumps to expansion ROM that set jump table to filesystem driver
Kickstart resumes to boot fully
User see boot screen
?
-
Someone is looking if its possible to boot direct from the A1200 PCMCIA slot via custom roms.
Being able to boot direct into OS3.1 without a hardrive/floppy would be interesting if possible.
-
Someone who was developing the AROS 68k ROM (I forget who) once told me he accidentally made the RAM: disk bootable once and it booted it. You can also boot from RAD disk (I tried this once, I effectively net booted using a boot floppy to pull an image of my workbench partition off the network and unpack it into RAD). So yes it is possible with only small changes, since a device doesn't need to correspond to a physical drive to be bootable.
All you need is a bootable disk with LoadWB on it to get a basic workbench, which is only a few kb. I suggested the idea of a ROM disk once. It would be interesting to be able to go straight to workbench from the boot menu, and could be very useful. Especially if there were room in ROM for such things as AmiTCP.
-
in case you didnt see this yesterday ...
http://lotharek.pl/product.php?pid=102
maybe there is some scope for this ?
-
The old EB920 (http://www.bboah.com/index.php?action=artikel&cat=67&id=2923&artlang=en) cards had network boot ROM sockets, but I don't think the chips were ever developed.
Now that FlashROMs are fairly common, I imagine one could conceivably develop a mini TCP/IP stack and associated pieces that would mount a NW0: device in time to be selected from Early Startup Control. Would probably require reflashing every time you wanted to change the parameters of NW0:, though.
@ delshay
The 1200 can be booted from PCMCIA with standard ROMs - it's the CC0: device. The only catch is that the actual media has to be one of the 4MB or smaller SRAM cards. Yes, booting CompactFlash or such attached to PCMCIA would require reworked ROMs. If compactflash.device were ROMable, I think that would just about handle it if the CF media was set up as an Amiga RDB disk instead of fat95 via a mountlist.
-
there is also this:
http://eab.abime.net/hardware-mods/66815-custom-flashrom-design-amigas.html
-
Ok so the recpipe is an extension (EEP)ROM that contains hardware driver, UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol)/IP stack, NFS (https://en.wikipedia.org/wiki/Network_File_System) driver.
So does existing hardware drivers, UDP/IP, NFS etc support being ROM:ed ?
Found this ROM collection that perhaps can be used for decompilation:
http://amigaromarchives.limewebs.com/
-
It would probably be easier to create a ROMable RAD driver which mounts a ROMed disk image (ADF).
In order to access files via NFS you need DOS sooner or later. At the time when ROM modules are activated, DOS is not yet active. So it's better to let the ROM module add a BootNode to the system and let DOS boot from the RAD disk.
The other advantage is that you can use existing software for TCP/IP, SANA-II and NFS and don't need to care whether they are ROMable or not. You only need to make one new ROMable module.
-
Catch, I like a clean solution without extra drives clogging up the memory ;)
Ie a computer environment with only NET: not RAD: + NET:
Exec from kickstart v1.2 hints about expansion ROM at 0xF0 0000:
http://wandel.ca/homepage/execdis/exec_disassembly.txt
Perhaps useful:
http://wiki.amigaos.net/index.php/Expansion_Library#The_Expansion_Sequence
Amiga device driver guide:
http://wandel.ca/homepage/execdis/devices_doc.txt
RAM drive disassembly:
http://wandel.ca/homepage/execdis/ramdrive_disassembly.txt
Anyone found source code for a ROM:able driver?
-
ROM: drive wouldn't need to take up memory, you could essentially have a RAM-like, read only drive pre-populated in the ROM, mount that and boot from it. So you could put anything you wanted in there.
-
Guess I'm missing something? but why would you want to?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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/
(http://www.jeacle.ie/pub/articles/amitcp/amitcp1.gif)
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 (https://github.com/GnoStiC/PUAE/blob/master/docs/bsdsocket.txt) 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.
-
Some further thoughts:
MessyDOS (MSH) consists of file handler (vfat) and device driver (mfm). The source (http://aminet.net/package/disk/misc/MSH-1.58#contents) 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?
-
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.
-
@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.
-
anfs (http://sourceforge.net/p/anfs/code/5/tree//trunk/src/) 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: 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.
-
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
-
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
-
Perhaps this is homing in on how to do it:
archive.org: 1993 Thomson randy Rhett anderson Mapping Amiga 2nd edition (http://archive.org/stream/1993-thomson-randy-rhett-anderson/1993-thomson-randy-rhett-anderson-mapping-amiga-2nd-edition_djvu.txt)
"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 (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node00A0.html)
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 (http://wandel.ca/homepage/execdis/ramdrive_disassembly.txt) (Commodore-Amiga Ram Drive 1.0 1988-04-06)
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 ..?
-
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?
-
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.
-
So where do I find the source code for a boot ROM ..?
Anyway it seems the RAD: calls AddDevice() (http://www.ummon.eu/En/Amiga/API/AmigaOS/Libraries/exec.library/AddDevice.html), MakeDOSNode() (http://www.ummon.eu/En/Amiga/API/AmigaOS/Libraries/expansion.library/MakeDosNode.html), Enqueue() (http://www.ummon.eu/En/Amiga/API/AmigaOS/Libraries/exec.library/Enqueue.html), OpenLibrary() (http://www.ummon.eu/En/Amiga/API/AmigaOS/Libraries/exec.library/OpenLibrary.html)/RT_INIT to add itself to the system after reboot.
(MakeLibrary() (http://www.ummon.eu/En/Amiga/API/AmigaOS/Libraries/exec.library/MakeLibrary.html)?)
Found this amigaos.net/../Example_Device (http://wiki.amigaos.net/index.php/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 (http://wandel.ca/homepage/execdis/devices_doc.txt) says it:
Devices in ROM are found during a scan of the entire ROM for RomTag
structures.
-
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.
-
So is NetFS "clean" ?
-
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.
-
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
-
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() (http://www.ummon.eu/En/Amiga/API/AmigaOS/Libraries/dos.library/FindDosEntry.html) and AddDosEntry() (http://www.ummon.eu/En/Amiga/API/AmigaOS/Libraries/dos.library/AddDosEntry.html) seems to use struct DevInfo (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node05D9.html) for "name" info)
Perhaps dosextens.h (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node05D9.html) 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 (http://wt.exotica.org.uk/files/test/DOS.lzx) archive of dos.library.asm)
-
Regarding the thread at abime.net (http://eab.abime.net/support-other/69540-bootable-network-file-system-rom-amiga.html):
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.
-
Found this nice example in comp.os.research in 1993:
User-level Filesystems (was Re: Plan 9) (http://groups.google.com/group/comp.os.research/msg/b58e62180bdb2847)
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.)
#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,"Ram Disk");
lock_list = NULL;
spaceused = 1;
/* add our volume entry to the system */
newnode = MakeDosEntry("Ram Disk",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 (http://eab.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.
-
The RKRM chapter 27 pretty much explains it all.
-
So RKRM - ROM Kernel Reference Manuals (http://www.maquinitas.org/app/download/5373668759/Amiga+Rom+Kernel+Reference+Manual+(www.maquinitas.org).pdf)..
"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() (http://AddDosEntry((struct DosList *) g->g_Device)) in nfs_handler.c main()
MakeDosEntry (http://gega.homelinux.net/AmigaDevDocs/dos.html#makedosentry())(g->g_VolumeName, DLT_VOLUME (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node05D9.html)) in nfs_handler.c G_Init()
MakeDosEntry(g->g_DeviceName, DLT_DEVICE) in nfs_handler.c G_Init()
-
I read the discussion at eabime (http://eab.abime.net/support-other/69540-bootable-network-file-system-rom-amiga.html) 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 (http://gega.homelinux.net/AmigaDevDocs/lib_32.html#32-3-3-1), ROMTAG INIT (http://gega.homelinux.net/AmigaDevDocs/lib_32.html#32-3-3-2) and BOOT (http://gega.homelinux.net/AmigaDevDocs/lib_32.html#32-3-3-3). 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
-
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?
-
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.
-
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.
RAD *is* a block device.
-
RAD *is* a block device.
Is it? I wonder why. It doesn't need to be.
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.
Are RAD and RAM different internally then?
-
RAD: is essentially a emulated floppy
RAM: behaves very much like a network drive
From what I remember.
-
hm, RAD is arbitrary size though, I copied my whole workbench partition to it once. Elsewhere is telling me that it is a fixed size, weird *is confused*. The OS shouldn't need to know anything about the geometry anyway though.
Also it is possible to boot from RAM: as well, Toni Wilen did it once by accident.
-
hm, RAD is arbitrary size though, I copied my whole workbench partition to it once. Elsewhere is telling me that it is a fixed size, weird *is confused*. The OS shouldn't need to know anything about the geometry anyway though.
Also it is possible to boot from RAM: as well, Toni Wilen did it once by accident.
The DOSDriver for RAD: requires you to set the number of blocks for the device. By default, it's floppy-sized (80 blocks), but you could make it much larger. It's not dynamic like RAM:. Maybe there's a way to mount something on ramdrive.device and still have it be dynamic, but I'm not sure. There are also a bunch of other recoverable RAM disks (RAD-like) out there. Maybe one of them is dynamic.
-
As I recall the RAD: device only allocate sectors when they are used. Thus it's dynamic to a certain degree.
-
Also it is possible to boot from RAM: as well, Toni Wilen did it once by accident.
That sounds like he's not using the standard ram handler, because it's not recoverable.
There was a 3rd part recoverable ram drive that was variable sized and recoverable.
The only reason the original rad: was fixed size was because it's easier to make it resident if it doesn't keep changing size. The source was also used as an example of a block device.
A network boot wouldn't be hard, you just need to write a device that fetches an image across the network when it starts & decompresses into ram. From then on it can just memcpy when asked to read. You could use something like this http://web.mit.edu/~mkgray/afs/bar/afs/net/dev/project/cgw/misc/tinytcp/ and store the image on an ftp server. Once you've got the code written then making sure it's rommable and making it auto boot at startup is a bit of work, but not too hard. You'd need to have the file system in rom as well.
Configuration for stuff like this is usually done using DHCP and files are provided by TFTP, but people generally don't have a TFTP server & DHCP is a bit of a pain to setup. Obviously you can just burn the settings into an eprom if you're doing it for yourself, but for something commercial you'd probably want to either go through the pain of DHCP or use some other form of broadcast that communicates with software on a pc.
If you want to only fetch files as they are used to reduce on ram usage then it's going to be more complex as you'll need to write a file system, a better network implementation and it's likely to be slower because of latency. You'll also need to use the same tcp/ip stack at bootup as you're using when running your computer, so that would also have to be rommable as well (which because of settings etc none currently are) or come up with some shim that allows both your mini tcpip stack and the main tcpip stack to run at the same time.
-
A fixed-sized RAD: is much easier to recover on boot because everything is in a single memory chunk.
A RAM:ish flexible device is much harder because you need to track down all the memory allocations and re-allocate them. This may also let you end up with fragmented memory directly after bootup.
-
it was an empty RAM disk, so it didn't need to be recoverable, but somehow mounted during exec/dos initialisation. I don't know the details. I think it was Toni Wilen. It was while developing the AROS 68k boot ROM so it might not have been exactly the standard RAM handler.
-
So RKRM - ROM Kernel Reference Manuals (http://www.maquinitas.org/app/download/5373668759/Amiga+Rom+Kernel+Reference+Manual+(www.maquinitas.org).pdf)..
"Chapter 27 Graphics Primitives" seems wrong?
Yes, expansion.library has been in chapter 27 in the 2nd edition, sorry.
-
it was an empty RAM disk, so it didn't need to be recoverable, but somehow mounted during exec/dos initialisation. I don't know the details. I think it was Toni Wilen. It was while developing the AROS 68k boot ROM so it might not have been exactly the standard RAM handler.
If you're making your own boot rom then you can cause any file system to be mounted.
-
If you're making your own boot rom then you can cause any file system to be mounted.
That's the idea.