Creating RPi SD image

Is there a way to create an SD without SystemDisk tool? 2GB is too small.

If you can understand the FileCore layout, and look at the FC and FAT boot/root/folder entries, you may well be able to work out how things fit together to roll your own.

I took a look, got fed up trying to rationalise a 2GB device formatted in 2016 with documentation written in ~1992. I mean, I still haven’t found where the FC boot block is, ‘cos it ain’t where it used to be…

…so I threw in the towel and purchased SystemDisc. It’s kind of a “need it once” tool, rather than something you’ll use daily, but it does exactly what it was supposed to with no fuss or aggravation.

I’d still like to know where the boot block is, though, as it might be interesting to try walking the filesystem (like *Checkmap) to see how it all fits together. The very first few bytes on the disc (track=head=sector=0) are some bytes followed by a short ID that just screams RISC OS. I’m certain those bytes point to the FileCore information, I just don’t know how. There’s so many permutations… Sector? Address shifted? What?

Where can I find the outdated docs?

Boot block might be documented here: http://www.riscos.com/support/developers/prm/filecore.html#44373

General filecore info (old filecore, i.e. pre RO4 as well as pro RO3.6) is found in PRM Vol.2: http://www.riscos.com/support/developers/prm/filecore.html or use the PDF (where’s the download?). Chapter 28.

And the “Ursula” update: http://www.marutan.net/wikiref/Acorn%20Registered%20Developer%20REFERNC/RO4/API/HTML/FILECORE.HTM

Thank you, Steffen. Fascinating filesystem. I’d never have imagined something like this.

It’s a bit annoying Acorn documented a lot in asm. Although I am quite familiar with asm, I am not with ARM, so this is going to be a headache.

I forgot: RO3.6 filecore extension is documented here: http://www.riscos.com/support/developers/prm/filecorenew.html

Thank you for the references. The problem I’m having is…

Hard discs contain a 512 byte boot block at disc address &C00,

There’s nothing there that looks like a RISC OS boot block, in examining a dump of a 2GB Pi image, and using Zap to do sector reads of my current 8GB device. There’s a lot of wasted space for the FAT part nearby. But FileCore…?

Is there a way to create an SD without SystemDisk tool? 2GB is too small.

Yes, it’s possible.
1/ create an ADFS partition, but on a part of the disc (for example 90%)
2/ create a FAT partition (bootable) on the remaining of the disc (here, 9,99%, to avoid some possible overlap, since geometry of the disc is different on hform / fdisk).
3/ put the needed files on the FAT partition

What !SystemDisc does for you is to overlap the two partitions so that the FAT partition is visible within the filecore partition as the image file !Boot.Loader.

So I’ve been reading the docs and took a hex editor to RO img and it looks like the best thing to do is !HForm with a very large defect. Create an MBR partition table and add a tiny FAT16 partition.

This is an educated guess as I haven’t quite got my head around !HForm or FileCore defects. xD

So no luck so far. Boot block seems massive according to !HForm errors and I’m having a tough time aligning docs with what I’m seeing.

Biggest problem is those docs only hint at filecore format, but mostly document API on RO which doesn’t help me. I still haven’t got my (working) ePic so don’t have DDE :(

This is helpful http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252efmt.txt but I still don’t have the specifics and Acorn’s document it in ARM Assembly is slowing me down from getting filecore format in my head.

I have heard hints of partitions on RO. I doubt you’re using MBR or GPT, so what partition table does RO use, assuming it uses one?

I have heard hints of partitions on RO. I doubt you’re using MBR or GPT, so what partition table does RO use, assuming it uses one?

It doesn’t; that’s the main reason why the Pi SD cards are such a mess.

The FileCore disc format is a mystery to me as well, but the way the Pi SD cards are set up is basically as follows:

• FileCore thinks its partition covers sectors 0…N
• However FileCore doesn’t actually touch the first sector or two of the disc, allowing us to squeeze in a (MBR?) partition table
• The MBR partition table contains an entry for a DOS partition which maps onto the sectors used by the “Loader” file in the FileCore partition
• IIRC the space used by the rest of the FileCore partition also has an entry in the MBR (to prevent it being overwritten if you e.g. want to add an ext4 partition to any spare space at the end of the disc)

Since RISC OS doesn’t understand partition tables, FileCore gets first look at the contents of the disc, sees a valid FileCore boot block, and mounts it as a FileCore drive. Other systems will see the MBR and mount the loader partition it as a DOS drive. If you do anything to the Loader file to change which disc sectors it’s held in (delete it, shrink it, expand it, etc.) then it will break.

Ugh, this means fdisk voodoo

And that didn’t work. When I did the defect method, I had errors say couldn’t find !Boot

When I I reduced filecore size buy 636 cylinders and dumped a 45MB FAT16 on the end, its boots with the error asking if disk has been formatted!

The ROOL RPi image has the FAT16 partition right at the beginning of the image. :/

The ROOL RPi image has the FAT16 partition right at the beginning of the image. :/

SoC bootloaders tend to be pretty simple. There’s a reason the first part of the device is a FAT partition…

The FileCore disc format is a mystery to me as well,

Oh. My. God.

Well, if Jeffrey doesn’t know, we might as well just admit defeat now!

SoC bootloaders tend to be pretty simple. There’s a reason the first part of the device is a FAT partition…

Interestingly RO rom loads in both locations

If you do anything to the Loader file to change which disc sectors it’s held in (delete it, shrink it, expand it, etc.) then it will break.

This seems to be my problem. What is this loader file you speak of?

If you do anything to the Loader file to change which disc sectors it’s held in (delete it, shrink it, expand it, etc.) then it will break.

This seems to be my problem. What is this loader file you speak of?

!Boot.Loader. It’s a file of type DOSDisc, which represents a DOS/FAT partition. In the old days, DOSDisc files were used with the PC emulator to store the PC filesystem. But, more importantly, DOSFS is an “image filing system” – which means that the OS can treat DOSDisc files as both files and directories. So if you double-click on it then you’ll be able to see and interact with the contents of the FAT partition. Zip files are another example of image files; it’s clearly a file, but if you double-click on it then SparkFS will mount it as a filing system and show you the contents, and regular filing system APIs will be able to access the contents as if it was just a regular folder.

So the key thing is that !Boot.Loader isn’t a link to the FAT partition which contains the ROM + firmware; it is the partition that contains the ROM + firmware.

(and if you haven’t worked out how to get to !Boot.Loader – it’s time for another lesson. Applications on RISC OS are just directories whose name starts with a “!”. You can shift- double-click on them in order to open them as a directory)

From the OS’s perspective, it should be able to boot fine without the special Loader file being present. The most important thing is that the Pi’s boot ROM has a valid FAT partition to load the firmware + ROM image from (and that FileCore won’t clobber the FAT partition if you fill up your drive). But having the firmware accessible from RISC OS is useful for upgrading ROM/firmware, and also the CMOS RAM emulation works by writing a file to the partition (so if you don’t have it accessible under !Boot.Loader, the OS won’t be able to save the CMOS settings).

I did wonder how to get into the folders, so thanks.

Is .loader auto populated by the kernel on boot? Or is it a hardcoded location?

It’s a hardcoded location. It needs to be set up correctly when the disc image is created.

There are much better ways to implement this. This feels like a massive bodge instead of a nice solution. Cost of legacy, I suppose.

So my only choice is to figure out FileCore and manually edit the table address or build something that does it for me.

There are much better ways to implement this. This feels like a massive bodge instead of a nice solution. Cost of legacy, I suppose.

Yes.

There are plans to do things properly, but so far nobody’s been tempted by the bait.

So my only choice is to figure out FileCore and manually edit the table address or build something that does it for me.

Or buy SystemDisc which is a tried-and-proven piece of software. Of course this option takes the fun out of trying to figure out FileCore :-)

Or buy SystemDisc

Except Piccolo is down and I have no idea how much it costs.

Of course, if you’re happy with using a USB drive as your main storage, you can set things up so that the SD card is only used for the ROM + firmware and a USB drive is used for all the FileCore stuff. E.g.:

• Format an SD card to have a moderately-sized FAT partition (no larger than 4GB; DOSFS is limited to this due to the fact it’s an image filing system) and put the ROM + firmware files on it
• Extract the standard RISC OS hard disc zip archive, or copy the contents of an SD card containing the Pi image onto a FileCore-formatted USB drive
• Boot from the FAT SD card (so the CMOS settings will be saved there – the SDCMOS module has two paths it will check when trying to discover where to save the file), and configure RISC OS to boot from USB:

*Configure FileSystem SCSIFS
*Configure Drive 0      (or 4 if it's shown up as SCSI::4)
*Opt 4, 2

No luck with that. Shell only gives error messages.