Partition Manager

Did you self-compile it, or was it supplied with the MX6?

Was supplied with/for MX6.
Was the first (?) version. I not know if there is a newer one. Works for me so I never check this out. I only changed the partition names.
Can take a look and format an other drive with gpttest if I back at home.

Have found two versions of gpttest. The first was 2017, second 2020 but I see not really difference.
Have formated a fresh drive.

ADFS5 and 6 are back again. 7 looks right.
GPT has FileCore partitions without content (no files).

Debugfile.

GPT has FileCore partitions without content (no files).

As it’s blank, would you mind deleting one of the partitions and creating a FileCore partition with Partition Manager? I’d like to confirm if your MX6 recognises a GPT FileCore partition with a different GUID.

Once formatted, reboot and see if RISCOS can access the newly created logical drive.

As it’s blank, would you mind deleting one of the partitions and creating a FileCore partition with Partition Manager?

Have do so.
Delete one partiton delete both.
Format was successful(?) but the partitions are not accessable.
Now I have intitialze GPT in the first field and than formated… was accessable without reboot. Very nice.

Looks like it is possible to format the complete drive. I not try. Is it workng or unfinished?
If I should try any other things, feel free…

Delete one partiton delete both.
Format was successful(?) but the partitions are not accessable.

If I understand correctly, you had to reinitialise the drive and then create the FileCore partitions before RISCOS could see them? At least that means the MX6 appears to support at least two GUID’s for FileCore. I suspect it’s not even checking the GUID and is leaving FileCore to detect the contents.

Could you please reinit the drive with gpttest, delete the last partition and recreate it with Partition Manager, then grab the log file for me. I’d like to check the partition table before and after to see why FileCore wasn’t detected using the existing gpttest partition table.

Looks like it is possible to format the complete drive. I not try. Is it workng or unfinished?

Format no, it’s not implemented – it’s kind of pointless these days anyway as it’s not really formatting but blanking the drive.

You can initialise drives with MBR or GPT partition tables, or as full disc FileCore, you can create and delete partitions and FAT / FileCore partitions can be quick formatted. It has the bare minimum needed at this stage.

I have only tested on SCSI drives so far, it may not work for SDFS or ADFS drives – it needs testing.

For better understandings…
1. I format the drive on MX6 with gpttest.. after restart.

Screenshot is “wrong” because is with the “PartMgr” reformated device.

2.Plug the device to Ti USB and use a modufied partman and SCSIFS for Ti.
Try to delete the second partition, delete the complete device.
Reformat GPT … Partitions are displayed but not known and no usable.
Two unusable devices are displayed on the iconbar with the same devicenumber.

Initialize the drive and reformat… works directly. Both partitions are displayed with the device name and I can use.

Debugfile

Restart the Ti with a plugged GPT device on ADFS. Is not usable because ADFS not support this but will be displayed in PartMgr.
Delete partition and init device give the same GUID error but the partition is delete (I pressed Chancel)…

Format partitions give any “write error”…

The result is comparable to the SCSI format without intialize… not usable.

Debugfile

Hope that helps.

Try to delete the second partition

I can see an issue at this point. gpttest has created an odd sized GPT partition table with only 7 entries, that doesn’t fill a sector. I’ll modify the code to handle this as its causing the GPT CRC to be miscalculated.

0.68 now available. No major changes, just some bug fixes and I’ve added a menu option to refresh the drives.

@Raik could you retest please. Create the drive with gpttest and then delete and create another partition with this to see if it now calculates the GPT CRC correctly.

Have try any things without thinking about ;-) but forget to made screenshots…
Refresh is a very good feature.

Have formated my drive with gpttest on ARMX6 and have plugged to Titanium USB.
GPT is detected, I see two “grey” GPT partitions. And in the lower info section the device is in the list with correct size detection but without free etc.
Then I delete the second GPT partition, both are gone, initializeas GTP and reformat two partitions… works. The GPT devices now “white”. But the drive is gone from the lower info section.
It is also visible in the older screenshots…
Initialize the drive to MBR… format both to FAT works, blue devices, info section looks correct.
Format the first to ADFS… looks like it works but the first partition is not usable and also not visible in the info section.

Then I delete the second GPT partition, both are gone

It doesn’t sound like I’ve fixed the issue. Could you possibly post gpttest, so I can test locally?

Hope you have read your email ;-)

It doesn’t sound like I’ve fixed the issue.

Mmm, not sure. The GPT partition from gpttest was correct detected…

Additional Info… Have try to use the GPT device as a Linux root device. Reformat with gparted fails (more than five times in different ways)… Write a large image or zeros with DD fails… Write zeros or clone a device with CloneDisc fails… all round about in the middle of device.
Have reinit MBR with your PartMgr and format the device to FAT fixed all the problems. The device is usable again. Second try with a PenDevice killed by my daughter (not sure how but WIN could also not reformat)… successful. Please not change this :-))

The GPT partition from gpttest was correct detected

Detection isn’t the issue, it’s modifying the partition table where there’s potentially a problem. Thanks for the email.

0.69 now available, which fixes the issue Raik reported. It was corrupting the penultimate sector of the GPT, if the partition count didn’t end on a sector boundary.

Sorry, I’m a bit busy. Have not find the time try but have formated a nearly 500GB SSD on Pi4. I’m sure I have set the first Partition to 256GB but 0.69 has “formated” the complete drive to FileCore.
Is 500GB supported by RISC OS? At this time the device is working (20GB data) but is it working with more than 256GB?
I remember there was a “testformatter” (in the gpt package) for the ARMX6 to format more than 256GB but it was not working stable.

Is 500GB supported by RISC OS? At this time the device is working (20GB data) but is it working with more than 256GB?

Not for 512B sectors, no. This comes about because internally and via the older DiscOp (and SectorDiscOp) SWIs the disc address is held in a 32b value with the top 3 bits encoding 1 of 8 drives, leaving 29 bits for the byte (or sector). 2^29 bytes is 512MB and 2^29 sectors is 256GB. With 4k sectors you can get to 2TB before hitting the same limit.

DiscOp64 allows these limits to be lifted by moving the drive number out and expanding the address to 64b, but currently FileCore just translates the new API into the old so in practice the limit is the same. There’s a bounty collecting to extend the format to hold more.

I remember there was a “testformatter” (in the gpt package) for the ARMX6 to format more than 256GB but it was not working stable.

A similar broken change appeared in HForm 2.69. Just because it’s possible to conjure a format that adds up to 500GB doesn’t make it fit in 29 bits! Fortunately this was fixed in HForm 2.70, so hopefully not too many people tried formatting their drive in the 10 days in between – they’ll be surprised when half the data on their drive is inaccessible if they did.

What choices do you have with a Iyonix first drive?

Can you use a Sata adaptor with 256GB FileCore and then format the rest to Fat32?

Does the adapter work with older versions of RO 5.16? And then be able to load a newer version of RO?

Can you use a Sata adaptor with 256GB FileCore and then format the rest to Fat32?

Not sure if PartMgr support this. I would try but the complete drive was formatted.
Normally I format 256GB FileCore with HForm and than I use Antons PartiFC to do this. FileCore is normally detected, the FAT partition you have to mount with FAT32FS.

I’m sure I have set the first Partition to 256GB but 0.69 has “formated” the complete drive to FileCore.
Is 500GB supported by RISC OS? At this time the device is working (20GB data) but is it working with more than 256GB?

I assume you initialised in PartMgt as GPT, then created a 256GB FileCore partition? After a drive refresh it then appeared as full disc FileCore?

Regards 256GB+ partitions, PartMgr does not put any restrictions on what you can create; if it can write it to the drive, it will allow it. The reason for this is two fold, firstly to allow you to create drives for other systems and secondly for future proofing.

DiscOp64 allows these limits to be lifted by moving the drive number out and expanding the address to 64b, but currently FileCore just translates the new API into the old so in practice the limit is the same.

I spotted how useless DiscOp64 was and believe I added a flag at the top of !RunImage to toggle its use. If there isn’t one already, we need an OS flag that can be checked for true 64bit support as just checking for the SWI clearly isn’t going to work.

As I’ve mentioned previously, I feel we need to deprecate FileCore and put a new file system in place. I honestly don’t think it’s worth wasting a bounty on as it has too many other deficiencies…no compression support, no journaling, partitions can’t be extended, no sparse file support, no encryption, no data stream/metadata support. Then there’s the use of drive numbers for both physical and logical drives and the issues of drive reordering it creates.

Can you use a Sata adaptor with 256GB FileCore and then format the rest to Fat32?

With PartMgr and a SCSI hosted disc, in theory yes as PartMgr uses SCSI commands, not FileCore to write to the disc. FileCore won’t be able to address the 2nd partition, so it will be flagged as such; FAT32FS might though as it also doesn’t use FileCore.

I assume you initialised in PartMgt as GPT, then created a 256GB FileCore partition?

No ;-)
I try to create a normally FileCore partition and have set the size to 250GB.

DiscKnight uses DiscOp64 when it’s available, but as Jon say it gets converted to SectorOp on RISC OS. But it is useful when I build DiscKnight on other platforms as it then gets emulated by a 64 bit stdio file operation, allowing me to handle any size of physical disc or disc image.

As a bit of interest – what does commands/SWI does Fat32 use SCSI?

[Edit]
Does the Iyonix use SCSI swi’s to connect to it’s 2 internal HD’s Interfaces?

Does the Iyonix use SCSI swi’s to connect to it’s 2 internal HD’s Interfaces?

No. The IDE is driven by ADFS. No SCSI in sight anywhere. Only USB is via SCSI (as on all other RISC OS machines besides the IYONIX, apart from the Simtec MassFS stuff of course…).

ARMX6 uses SCSI for its S-ATA.

Titanium uses ADFS for its S-ATA.

No ;-)
I try to create a normally FileCore partition and have set the size to 250GB.

If you didn’t initialise the drive as GPT and then create a 256GB FileCore partition, what steps did you use?

So I’m clear, you used this software and nothing else, to initialise the drive and create a 256GB FileCore partition and it ended up filling a 512GB drive once the partition was initialised? In other words, it went from a partitioned drive before you initialised the 256GB partition to a non-partitioned full disc FileCore drive with no partition table?

The IDE is driven by ADFS

And for the purposes of this software, I’ve not tested PartMgr with ADFS and have not implemented anything specific low-level to work around its drive size limitations, due to its reliance on FileCore. I don’t actually have any modern hardware with ADFS, so testing by the community would be appreciated.

I use a “fresh” Pi4 installation and a new unboxed 500GB SSD via “SCSI”.
Start PartMgr, Menu to device, format FileCore and set the size to 256000MB … initialize… the result was a 500GB FileCore partition.

Start PartMgr, Menu to device, format FileCore and set the size to 256000MB … initialize… the result was a 500GB FileCore partition.

Did you initialise the drive partitioning as MBR or GPT before you formatted it? If not, it would have defaulted to no partitioning and resulted in a full disc FileCore drive.

Is the drive 4K? That might explain why it didn’t report write errors when initialising FileCore.