English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 18 October 2016, 08:29   #1
Heiroglyph
Registered User
 
Join Date: Jun 2010
Location: USA
Posts: 88
What use are reserved blocks?

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

Does anything use them?
Heiroglyph is offline  
Old 18 October 2016, 20:39   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,562
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)
Toni Wilen is offline  
Old 18 October 2016, 20:45   #3
Locutus
Registered User

 
Join Date: Jul 2014
Location: Finland
Posts: 1,003
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.
Locutus is offline  
Old 18 October 2016, 20:59   #4
Heiroglyph
Registered User
 
Join Date: Jun 2010
Location: USA
Posts: 88
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.

Last edited by Heiroglyph; 18 October 2016 at 21:11.
Heiroglyph is offline  
Old 19 October 2016, 14:31   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,562
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

Last edited by Toni Wilen; 19 October 2016 at 16:09.
Toni Wilen is offline  
Old 19 October 2016, 18:37   #6
Heiroglyph
Registered User
 
Join Date: Jun 2010
Location: USA
Posts: 88
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 is offline  
Old 21 October 2016, 17:04   #7
Heiroglyph
Registered User
 
Join Date: Jun 2010
Location: USA
Posts: 88
Actually I was given a suggestion that is even better and won't mess with the reserved blocks or RDB.
Heiroglyph is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
How to shrink an area of reserved memory Mrs Beanbag Coders. System 4 05 July 2013 23:35
Enable RDB mode and Surfaces/Sectors/Reserved mark_k support.WinUAE 1 17 February 2013 18:51
check HDD bad blocks rare_j support.Apps 3 21 February 2006 01:04
Puzzle Game with blocks being pushed by a tractor? zardoz Looking for a game name ? 2 21 January 2005 17:08
Problem with disk blocks already in use Giana support.Hardware 34 14 August 2002 20:20

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 07:46.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.11702 seconds with 13 queries