Partition Manager

Thanks for the feedback.

I did not find a Cmos file, so I copied one from elsewhere

As RISC OS doesn’t generate one if it doesn’t exist (I’m sure it did in the past), I’ll need to put something into the !Boot sequence to create it.

Bootcode.bin/Start.elf/Fixup.dat is not needed on a Pi 4, so I deleted it.

The Pi should select the correct firmware for the device. The FAT partition should be in a state where you can move the SD between Pi revisions and it will boot to RISC OS.

I replaced…config.txt

What specifically was wrong with CONFIG.TXT? I pulled that one from a ROOL SD image, so it should contain the bare minimum required to boot to an EDID detected monitor. I do plan to add an option to select the default hardware resolution when EDID isn’t used.

I replaced…fixup4.dat, start4.elf

The firmware it pulls down is either the official “latest” or “stable” from GitHub. Are you saying neither worked on a Pi4? I tested all combinations of RO/Pi firmware/HD4 on a Pi3 and they all booted to a usable desktop.

The screen was fixed at an workable low resolution

Was EDID ticked when you initialised the SD and was CMDLINE.TXT missing “disable_mode_changes”? I’m sure I checked all three combinations of CMDLINE.TXT, but will re-check.

I had no trouble with hot swapping the SDcard for the download

Did it prompt for the initial Boot drive at all during the download stage? I’ve set the URL calls to ignore Cookies, but I’m wondering if AcornURL is still trying to open the Cookie file whenever a connection is initiated. It also does some jiggery-pokery in the !Scrap folder, which I think is what was causing all my attempts to fail.

I did try pointing Choices and Scrap at a RAM drive, but it still refused to connect so I don’t think I’m going to get away without a bespoke AcornURL Module that doesn’t have the !Boot dependency.

Once you’ve created the new RISC OS SD card, do you have to copy all the files from the old card by swapping it in to the Pi’s SD slot multiple times, like we did to copy floppy discs on a single drive system back in the day? :-)

USB SD card reader is your friend there!

As RISC OS doesn’t generate one if it doesn’t exist (I’m sure it did in the past), I’ll need to put something into the !Boot sequence to create it.

The CMOS file on the Raspberry Pi can – at present – be stored in two different places: as $.CMOS (if the SD card only has a FAT16 partition) or as $.!Boot.Loader.CMOS (if the SD card has a FileCore partition as well as a FAT16 partition). The “FAT16-only location” seems to be a hold-over from the now-defunct “RISC OS Pico” build, but is advantageous for people who wish to boot from SD while having the FileCore partition on SSD. If you’re making adjustments to !Boot you will have to do it in such a way that the user can still change their mind about where the CMOS file is located.

Rather than try to create a CMOS file on-the-fly, it may be easier to copy a known-good CMOS file from somewhere else (e.g. from a recent “RISC OS Pi” image) when populating the FAT16 partition.

If you do wish to persevere with adjusting the !Boot sequence, the command you want is:

*SaveCMOS SDFS::$.!Boot.Loader.CMOS

Be aware that any other configuration changes you wish to make (e.g. “MonitorType EDID”) will need to be done before you save the CMOS file, or they will be lost.¹

¹ RISC OS “remembers” that a CMOS file wasn’t present on boot, so won’t try to update it if you create one and subsequently issue *Configure commands in the same session.

What specifically was wrong with …?

Having discoved that the CMOS file was missing, I replaced the other files as a short cut to getting it working.

Did it prompt for the initial Boot drive at all during the download stage?

No. but my system uses only the minimum 5 boot files on a standard FAT SDcard. Everything else is on SSD.

Was EDID ticked when you initialised the SD?

I did not see anything to tick. I do remember, a long time ago, having to change something on my standard build so that it would run headless (or not). Was that in config.txt?

do you have to copy all the files from the old card by swapping it in to the Pi’s SD slot multiple times

For that true retro feel!

No. It stream-extracts all the ZIP’s direct from their respective sites to the new SD. The issue is AcornURL has a dependency on !Boot when it attempts a connection, that causes RO to prompt for the original SD to be put back in so it can access Scrap and Choices (which would be really bad if you did actually do that!) AcornURL then aborts the connection if it can’t access !Boot – although I have noticed the connection works if you’ve previously connected. Regardless, I need to come up with a workaround.

USB SD card reader

Quite…if only I could find my one…its here somewhere! Not really practical for most people though.

If you do wish to persevere with adjusting the !Boot sequence, the command you want is

To be clear, I don’t want to adjust the !Boot sequence. Ideally I’d like to extract a Pi specific HD4 ZIP from here, but there’s only a generic HD4 at the moment that isn’t suited for a Pi without changes.

I’ll probably add an Obey to the Hook folders which creates CMOS if it doesn’t exist in the FAT partition and then forces a reboot so it’s picked up.

RISC OS “remembers” that a CMOS file wasn’t present on boot

That sounds like an odd design choice. Ideally it should check if CMOS exists when writing to the CMOS.

Everything else is on SSD

That will be why it worked without prompts, !Boot would have been available to AcornURL whilst PM was streaming all the ZIP files.

I did not see anything to tick

If you didn’t see it, it would have defaulted to EDID enabled. There’s two tick boxes in the “Boot area” section to configure EDID and Gamma.

Jon, I have a USB drive (HardDisc0) which reports as allocated under version .98 (SCSI 0:1). However under .99 it reports that it’s unallocated. RPI4B (RO 5.29 13-Dec-22)

Regardless, I need to come up with a workaround.

I suggested something three days ago.

That sounds like an odd design choice.

I think the logic is “if there’s a CMOS file, we ought to keep it up to date”.
However, if there is no CMOS file, it needs to be explicitly *SaveCMOSed by the user.

I’ll probably add an Obey to the Hook folders which creates CMOS if it doesn’t exist in the FAT partition and then forces a reboot so it’s picked up.

One thing to watch out for: Recent Pi4 EEPROMs toggle the power to the SD card during a reboot. It may be necessary to add a short delay before rebooting so that the SD writes happen properly.

It’s good practice to have a delay anyway. My little shutdown handler (traps ^Break) automatically pauses for three seconds to give the SD card time to flush writes to the flash.

I have a USB drive (HardDisc0) which reports as allocated under version .98 (SCSI 0:1). However under .99 it reports that it’s unallocated

I’ll need to see the debug log. Hold ALT when you launch PM, then email or post DEBUG/TXT please. My eMail is at the bottom of the Help file.

Thanks, Jon. I’ve sent an e-mail.

I have a USB drive (HardDisc0) which reports as allocated under version .98 (SCSI 0:1). However under .99 it reports that it’s unallocated

Should hopefully be fixed in the latest upload

For anyone else that has downloaded 0.99, grab the latest version as this issue was being caused by SCSIFS addressing the wrong drive.

I’ve also added the Obey file to the Hook folders that saves the CMOS to the FAT partition on 1st boot.

Thanks, Jon. The update resolved the issue I saw.

An observation around the column labels for the drives. On my Icon Bar I have an SD card, and two SCSI devices, these are identified as

 :1     :0      :0
(SCSI) (SCSI) (SDcard)<- used for illustration purposes.

Yet in the upper part of the Partition Manager window, these are identified as SCSI 0:0, SCSI 0:1 and SDFS 0. I’ve mapped them below to illustrate what I see.

  :1       :0      :0
SCSI 0:0 SCSI 0:1 SDFS 0 

The lower part of the window has the expected labels, but curiously the upper part doesn’t.

An observation around the column labels for the drives

The upper region shows the physical drive ID (ie the value the driver is using for low-level access). For many filesystems you’re unaware of the physical drive ID, although I think *SCSIDevices might show it in this case.

The bottom region shows logical drive numbers, which should marry up with the drive Filer icons.

If you send me an updated DEBUG/TXT I’ll double check they’re both correct. Please include a screenshot if you can.

If you send me an updated DEBUG/TXT I’ll double check they’re both correct. Please include a screenshot if you can.

Thanks, Jon. I’ve sent those to you. Hopefully, the log will show an error message for a 32Gb card I used yesterday to create bootable media for a different machine (Pi3B- RO 5.28); it’s good to see all that free space. :)

For anyone else that has downloaded 0.99, grab the latest version as this issue was being caused by SCSIFS addressing the wrong drive.

It seems my “fix” broke writing to SCSI devices. I’ve just uploaded a corrected build.

Hopefully, the log will show an error message for a 32Gb card I used yesterday

Andrew, I did try replying via email but it’s being rejected. Hopefully the issue you had was the one I just fixed, if not let me know how to reproduce it and I’ll add additional debug info if required.

With regard to your query about the device ID’s not matching up. Your log show SCSI ID 1 (Generic device) maps to logical SCSI::1 and SCSI ID 2 (SanDisk Ultra) maps to SCSI::0 which both look okay to me.

It seems my “fix” broke writing to SCSI devices. I’ve just uploaded a corrected build.

The corrected build does the job. I’ve also sent an email with some observations.

There’s a new build up which adds all the additional Pi controls such as resolution, overscan, audio via jack etc.

I’ve also rewritten the !Internet Startup so it detects which Ethernet is being used and configures itself appropriately. It there’s no Ethernet, it should hopefully avoid the lock during boot on Pi Zero’s – although I’ve not tested.

There an updated 0.99 build available which fixes a number if issues I’ve spotted whilst testing this week, the serious one being a potential Zone overrun when allocating FileCore Map entries to the PiBoot FAT area.

It’s probably my stupidity again, but when I run !PartMgr, I get a completely different window than the one in your description, Jon. Mine doesn’t have buttons, only menus. But I don’t dare clicking on any entry because of what might happen in my ignorance.
Here’s that window:

(that’s on a 4té2, RO 5.29)

when I run !PartMgr, I get a completely different window than the one in your description

That screenshot looks okay to me. If you’re referring to the “Initialise Pi Boot drive” dialogue on the linked download page, you’re only going to see that if you Menu on a drive and select it from the menu.

I don’t dare clicking on any entry because of what might happen in my ignorance

I’m pretty sure anything that will write to the drive will show a dialogue first.

PM replaces HForm and just about every Partitioning/Format tool that came with a Podule since RISC OS 3, so unless you’re just curious to see how drives are partitioned, this tool would only ever be needed when you want to initialise a new drive or modify partitions on an existing drive.

Thank you, Jon, for this explanation. The accompanying !Help file is a bit sparse and assumes quite some knowledge on the forehand.

The accompanying !Help file is a bit sparse

I’ve not actually written a !Help file yet. That file is only there so testers know what is and isn’t supported and how to produce a debug log.

I also need to review and include the low-level documentation, which covers how to add support for additional filesystems.

There’s an updated build available which resolves an issue with the FileCore end disc marker – noted by !DiscKnight and fixed with David Ruck’s help. I’ve also added some addition checks and a fall-back for SCSI devices which return an invalid READ CAPACITY (16) result.