What use are reserved blocks?

[Heiroglyph]

What is the intended use of reserved blocks at the beginning of Amiga partitions?

Does anything use them?

[Toni Wilen]

At least one reserved block is always needed to store partition's dostype (first 4 bytes, contains identifier like "DOS\1" etc).

Second reserved block is not technically needed but I guess default is 2 because floppies have 2 reserved blocks (=bootblock is stored in 2 first blocks)

[Locutus]

Another reason you would want more reserved blocks is for one of the third party OS bootloaders that can live in the bootblock.

NetBSD still had a bootloader that can start execution from there and boot a kernel directly from a BSD slice.

I think AMIX does the same.

[Heiroglyph]

Thanks, that's good to know.

In your opinion, how viable would it be to store data in additional reserved blocks?

As you know, I'm working on a bootable SD card driver.

While I was adding the custom loadseg, etc. needed to load filesystems, I realized that it would not be a huge leap to load ROM-type modules extremely early in the boot process to save the reboot needed when using loadmodule from the startup sequence.

If these reserved blocks are rarely if ever used, I think this would be a safe place to put modules.

Devices that don't support it would ignore it.
Devices that might have some special use for this area should already check that they have valid expected data.
The size of the area is easily determined by the user when partitioning with normal partition tools like HDToolbox.
It's easily wiped out by a normal format tool.
It can be written/modified by a special tool without tinkering with the RDB. Less potential for data loss.

So I would propose a new header type very similar to a FileSystemHeaderBlock with an ID of 'KIKM' for Kick Module. 'KICK' seems like a misnomer and is probably used elsewhere.
This would have versioning, module name, relevant flags, etc so that it would be easy to check that it's the newest version prior to loading.

This linked list of kick module headers would point to regular loadseg blocks containing the modules to be loaded.

I'd want a way to optionally disable loading these. Possibly some mouse button down or key down check would cause it to not scan for modules in case you added a bad one and needed to recover.

I don't think it should be limited to only the current boot drive since you might (especially in my case, an SD card) want to use a removable device to hold these while booting from your normal boot device.
All devices that support this would load what they detect as long as it's newer than what is currently in the list of modules.
In practice I think users would have one disk with this information stored on it though.

If partition reserved blocks are basically unused currently, this seems very compatible, Amiga-ish and as safe as you could reasonably make it.

The alternative is to put it into the RDB in one of the remaining reserved spaces, but I dislike mixing low-level partitioning data with system file storage. Filesystems, drive specific startup code and even the AOS4 addition of boot code is slightly different to me in that they are required for reading the disk and booting while this is completely optional, somewhat user accessible and just feels like it should not be part of the disk layout itself.

I'd hate to have users tinkering with the RDB constantly when trying out new modules.

This driver and tools will be open source, so anyone else could potentially do the same. That's one reason I'm trying to be very careful to think this through.

Edit: In the big picture, this would act like the flash ROM of a Deneb. You could load anything you want at boot. USB drivers for example or essentially have your own easily replaced custom ROM of nearly unlimited size.

[Toni Wilen]

It is not extremely early. HD drivers init usually quite late, before early boot menu (boot priority 0-20 or so), about <0.1s before dos strap starts.

Unless driver is one of the weird ones that does detection in diag init routine.

Reserved blocks probably can be used for this kind of extra storage that does not need filesystem help to access but IMHO proper in-circuit programmable, with boot selector/recovery, with banking, flash rom replacement is the correct choice. (which no one has made..)

EDIT: Go on, I don't mind and this seems weird enough way to make it interesting

[Heiroglyph]

It's not actually an autoconfig board, so I don't have the luxury of a diag init routine.

My current driver is in our custom kickstart and works similarly to scsi.device in that I just know where my device is located in the memory map and I come up as RTF_COLDSTART.

I have to build my own ConfigDev structure during autoinit because there is no board for Expansion to find.

Since I'm in a custom ROM I could do anything by making a new module, but I wanted this process to potentially be reusable by others and not rely on a custom Kickstart hack even if that means that some modules may not be replaceable using this method.

I'm shooting for a pretty much OS legal solution that anyone could add to their driver if they wanted.

If there is a better way for any of this I'm open to suggestions.

[Heiroglyph]

Actually I was given a suggestion that is even better and won't mess with the reserved blocks or RDB.