Creating RPi SD image

No luck with helping you if you don’t tell us what the error messages are :-)

(I did type the above from memory, so it wouldn’t surprise me if I got it wrong)

No luck with helping you if you don’t tell us what the error messages are :-)

Haha, and I should know better.

*Configure FileSystem SCSIFS
Filing system SCSIFS: not present

Drive is on SCSI:0

*Configure FileSystem SCSIFS
Filing system SCSIFS: not present

That should be just SCSI – I think that at the time Acorn were standardising on 4 character FS names! Hence SCSI:0!

That should be just SCSI

We’re getting there but…

*Configure Drive 0
Configure option not recognised

xD

*co. FileSystem SCSI
*co. SCSIFSDrive n

Almost there…

*Opt 4, 2
FileCore does not understand this disc

SDFS on defaults to *opt4,2 as can be seen with a *. command.

SDFS on defaults to *opt4,2 as can be seen with a *. command.

That makes sense. So what would SCSI:0 be?

So what would SCSI:0 be?

Brain reboot.

Set the filing system to SCSI then set the option

*SCSI
*OPT 4 2

or

*SCSI:OPT 4 2

That works. Thanks to both Jeffrey and Dave. Appreciate the help.

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

Let’s see. We have a filesystem that dates from the late eighties and has had some changes, but not many. Larger files, larger drives, larger names, but the base methodology is largely the same, and the concept of partitioning is unknown.¹
And we have SoCs that expect to crash headlong into a FAT filesystem from the outset. Okay, the Pi is pretty flexible (look at noobs), others are less flexible (hello OMAP 3).

The only sensible way to get two filesystems that expect to be the first thing on the media is to… Create a lovely bodge where they can both be the first thing on the media. At the same time!

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

It costs £14 – https://web.archive.org/web/20160309124823/http://piccolosystems.com:80/disctools/systemdisc

Some whois-fu should provide you with an email address that might work, if you’re interested in asking about purchasing…

¹ Third party software often handled partitioning. Morley SCSI offered a clumsy but working partition system. Simtec IDE offered a beautiful version with automount choice, ability to mount/do at will, to assign a mount to a specific drive, etc etc. Acorn? I guess they must have supported some sort of position in RISCiX. Add for RISC OS……..?

It costs £14

Surely it’s free now since it’s not available for purchase with a cursory Google search; at least that’s what abandonware sites tell me, so it must be true!

:P

The only sensible way to get two filesystems that expect to be the first thing on the media is to… Create a lovely bodge where they can both be the first thing on the media. At the same time!

I disagree with this. I think it was the easiest, but not the most elegant. Modifying FC to recognise MBR and work at an offset or behave as normal if MBR not found makes the a lot more sense.

The other possibility is HAL or ROM populates !Boot.Loader or adds address to fc table if booted from Pi.

Modifying FC to recognise MBR and work at an offset or behave as normal if MBR not found makes the a lot more sense.

Which is basically having partition support in RO

As Jeffrey said earlier:

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

least that’s what abandonware sites tell me,

That’s an understanding of copyright on par with Disney, though in the opposite direction.

Modifying FC to recognise MBR and work at an offset or behave as normal if MBR not found makes the a lot more sense.

Which…sounds a lot like partition support, does it not?

The other possibility is HAL or ROM populates !Boot.Loader

Why would it need to? RISC OS image filing systems can make non native structures (FAT disc, zip archive…) appear as “a directory with stuff inside”, so given this, it does make sense for the initial FAT area to appear in a certain place (chosen to be $.!Boot.Loader, but it could be anything anywhere). When you access that, it isn’t a copy, it’s the real FAT area.

Third party software often handled partitioning. Morley SCSI offered a clumsy but working partition system. Simtec IDE offered a beautiful version with automount choice, ability to mount/do at will, to assign a mount to a specific drive, etc etc. Acorn? I guess they must have supported some sort of position in RISCiX.

Was there a third-party IDE or SCSI solution that didn’t support partitioning? RapIDE, Simtec IDE and APDL IDE (Baildon) did, and SCSI-wise Power-tec, Yucani/MCS/ACE, Castle, Cumana, VTi, HCCS, Oak, Lingenuity also did.

It is one of the ironies of RISC OS history that only FSes without partitioning support survived.

Partitioning for a combined RISC OS/RISCiX was “Filecore first, RISCiX filing system understands filecore enough to find the offset it needs to use” IIRC.

Which…sounds a lot like partition support, does it not?

More like psueodo partition support. It would only recognise the first FC area.

When you access that, it isn’t a copy, it’s the real FAT area.

I know.

It is one of the ironies of RISC OS history that only FSes without partitioning support survived.

Sadly logical. Modern machines don’t support podules, and none of this stuff was ever released as open source…

It’s been a while since I fiddled with this kind of thing, but long ago, in the days before the Raspberry Pi, the Beagleboard was the exciting new RISC OS capable computer. SDFS had not been developed then, so it was not possible to have a card which allowed you to boot and also acted as the main drive.

It’s perfectly OK to have a small SD card to boot from, and a completely different device attached via USB to have your !Boot structure on for use once the ROM is initialised.

As for building a bootable SD-card with FileCore partition, without using SystemDisc…

I have not done this exact task, but on the Beagleboard I have a USB hard drive which has a FileCore partition for RISC OS and an ext4 partition for Linux. The SD card I boot from takes account of the user button on the board and boots into Linux if the button is depressed. To build this hybrid drive I did as follows:

1. Using gparted on Linux, created a large unallocated block at the start of the disc and occupying about half the space. The second half I placed an ext4 partition on, but I could have put a FAT partition on as well for booting from.
2. Using the tool of your choice, copy the MBR to a file elsewhere (first 512 bytes of the disc).
3. In RISC OS, use HForm to format the disc, altering the suggested geometry so that FileCore formats only the first half of the drive (the bit you marked as unallocated in gparted).
4. HForm will overwrite the MBR, so in Linux you won’t be able to see your other partitions.
5. Using the tool of your choice, restore the MBR from the file.

You should find that FileCore does not mess about with the first 512 bytes of the disc after that: it’s only cleared out by HForm, and you will then have a working FileCore partition and the partitions you created using gparted. Be careful to do your sums right as if you make the FileCore partition too big you will overlap with the other partitions.

This method does not give you a clever way of accessing the FAT boot area direct from RISC OS like SystemDisc does, but aside from that you will get the right effect.

There may be a little bit more too it than that, but that was the basic method I followed. Bear in mind I was creating a FileCore and an ext4 partition, and the board was loading its initial stuff (e.g. RISC OS ROM) from a different disc. But it might well work for a bootable FAT partition, and it is easier than mapping out defects. The only problem I can foresee is if the bootable FAT partition has to be nearer the start of the disc.

I have almost like Matthew on my Beagle, only RISC OS/Linux is an option on the µSD card (standard install, with Linux altered to be user button and RISC OS otherwise booted normally), then RISC OS picks up everything from a FileCore formatted USB device.
Since Linux takes most of the µSD, there was no need to partition the USB, it’s entirely dedicated to RISC OS.

I’ve kept the boot rom on the SD, but using a pen drive capable on 80MB/s (not that RO is capable of such speeds over USB) which was handy when my ePic arrived as I could keep all my settings.

RO’s USB system makes me want to buy a titanium board, a usb 3 PCIe card and write an xHCI interface.

RO’s USB system makes me want to buy a titanium board, a usb 3 PCIe card and write an xHCI interface.

How about claiming a bounty?

(I can dream…)

Titanium already has a XHCI driver take a look at the source

How about claiming a bounty?

I don’t know if that’s really me. It makes a lot of sense to synchronise with NetBSD and I agree with their choice but it’s not how I’d want to develop it. Always wanted to build one from scratch.

Titanium already has a XHCI driver take a look at the source

Wow, you’re right. I’d have thought they’d be happy with EHCI. That’s quite impressive. Now I have to find another project. :’(

Now I have to find another project.

Does porting a newer version of the network stack sound too ambitious?