Partition Manager

could you now please post the output from: listpartitions 1

*listpartitions 1

Found 2 disc partitions
SCSI ID:01 Start 00000004 Size 07397ffb SCSIFSdisc 1
SCSI ID:01 Start 07397fff Size 07398000 SCSIFSdisc 1
*

That makes no sense, not only do the partitions reported by PartMan not match the partition table, its given the same SCSIFS drive number to both partitions.

The bold figures below are taken straight from the partition table:

SCSI ID:01 Start 00000004 Size 07397ffb SCSIFSdisc 1
Start LBA =&000000003
End LBA =&007397FFD (size in LBA=&007397FFA)

SCSI ID:01 Start 07397fff Size 07398000 SCSIFSdisc 1
Start LBA =&007397FFE
End LBA =&00E72FFF8 (size in LBA=&007397FFA)

Can anyone explain the discrepancy? The “out-by-one” LBA start sounds like a bug in PartMan, as LBA’s start at 0. I can’t figure out how it’s getting the size wrong though.

EDIT: Please try 0.47 where I’ve done a +1 when calling SCSIFS_Partitions

That makes no sense, not only do the partitions reported by PartMan not match the partition table, its given the same SCSIFS drive number to both partitions.

What is about to be reported makes no sense either!!!

*listpartitions 1

Found 2 disc partitions
SCSI ID:01 Start 00000003 Size 07397ffb SCSIFSdisc -1
SCSI ID:01 Start 07397ffe Size 07398001 SCSIFSdisc -1
*

Though that now shows start LBAs that match the values in debug/txt, why is it doing that when it had been consistently reporting the first start LBAs as one more than expected!!

What changed!!

All that has happened on the Titanium is that !Boot has been fully updated to the latest beta.

Just to rub the weirdness in both partitions are now shown as -1!!

Just to rub the weirdness in both partitions are now shown as -1!!

I suspect SCSIFS_Partitions has failed to find the drive – which isn’t surprising when the start LBA isn’t correct!

The code that builds the array of drives for *listpartitions is here

Line 607 and 617 look suspect to me.

I don’t understand why it’s calculating the size, instead of using the size from the partition table :|

Could someone else with a Titanium please try 0.47 and check the output of *listpartitions

Could someone else with a Titanium please try 0.47 and check the output of *listpartitions

How about adding these useful listing options to the generated debug/txt test file for everyone as you come across them? Using an X version, of course!

Also, for those of us using (the apparently inadequate) NetSurf (tho’ it works for my own downloads!) could you incorporate the version number in, say, the titlebar in the template file (or wherever you define the window characteristics) so that, in the absense of other clues, we can easily differentiate versions!

Using a PartMan module built with :-

607 bp[i+1].start=bp[i].start+capacity;

N.B. The suggestion above is now withdrawn.

*listpartitions 1

Found 2 disc partitions
SCSI ID:01 Start 00000003 Size 07397ffb SCSIFSdisc 1
SCSI ID:01 Start 07397ffe Size 0e72ffff SCSIFSdisc 1

Negative drive numbers are an artefact associated with the PartMan aware SCSIFS module, required to see the second partition.

SCSIFSSA softloaded.

*listpartitions 1

Found 2 disc partitions
SCSI ID:01 Start 00000003 Size 07397ffb SCSIFSdisc -1
SCSI ID:01 Start 07397ffe Size 0e72ffff SCSIFSdisc -1
*

The size of the second partition is a bit out.

A report from PartMgr 0.47 is here

Yes, having looked at its code again it’s somehow calculating the partition size off the disk capacity, instead of just reporting the partition size from the partition table. That explains why the sizes don’t match actual values.

I’ve removed my code suggestion above as on reflection listpartitions needs a complete rewrite; I expect there’s a reason it’s not using the partition table values, but it’s not clear to me why or explained in the code.

The fact listpartitions also doesn’t show the correct SCSIFS drive number is frustrating, as I wanted to cross-check using it. The partition start flipping between correct and +1 is of particular concern, which I can’t explain. Essentially the output from listpartitions can’t be trusted.

Negative drive numbers are an artefact associated with the PartMan aware SCSIFS module

Looking at your 0.47 debug/txt and the listpartitions above…are you definitely running a version of SCSIFS compiled for PartMan? It’s returned the same SCSIFS disc for two different R2 values (R2=start LBA) – this would also explain why listpartitions is not reporting the SCSIFS drive number correctly.

Inserting the pen after the PartMan and PartMan aware SCSIFS 1.35 modules were softloaded gets the disc numbers correctly.

*help scsifs
==> Help on keyword SCSIFS
Module is: SCSIFS          1.35 (20 Jul 2018)

*listpartitions 2

Found 2 disc partitions
SCSI ID:02 Start 00000003 Size 07397ffb SCSIFSdisc 2
SCSI ID:02 Start 07397ffe Size 07398001 SCSIFSdisc 3
*

(Negative disc numbers seem occur if the disc is already plugged in at startup and then the modules are softloaded.)

A full report is here

Negative disc numbers seem occur if the disc is already plugged in at startup and then the modules are softloaded

Phew…had me worried there for a minute. PartMan relies on the insert to take over and allocated drives etc. so it probably needs loading during POST Module init.

From your 0.47a logs it looks like softloading it is breaking something, could you possibly upload both Modules and the tool for creating the test drive, so I can test locally.

gpttest, with the mod to stop spurious partitions appearing, is here

The modules are here

There is a suggestion to load them in PreDesk with an Obey file. That did not work here but double clicking on the modules, in the right order PartMan then SCSIFS does. Presumably something needs a little time to happen.

Thanks, I’ll test during the week and try to get it working correctly.

v0.48 up which appears to detect PartMan partitioned drives correctly from my testing.

I’m now going to make a start on initialising drives and creating partitions.

Hi Jon,

Thanks for the update and I can confirm it works on my ARMX6 and Iyonix as well.

I take it IDEFS is still out of scope for the moment?

Can’t wait to test the partition support and have a drive ready to test on.

v0.48 up which appears to detect PartMan partitioned drives correctly from my testing.

It does indeed. Very good.

Thank you all for the testing and debug reports thus far.

I take it IDEFS is still out of scope for the moment?

IDEFS is out of scope until I’ve implemented GPT, MBR partitioning and FileFore formatting. I created a request for information thread on StarDot to start collecting information; I’d need copies of every IDEFS Module so I can figure out how to distinguish between them, and see if they support low level access. Documentation would also be useful, but from what I’ve seen so far support is going to be very limited – if at all.

Could someone possibly confirm which combination of FileCore attributes are valid from RO 3.0 thru RO 5.x when formatting a drive. Is it:

D, Old map, New dir
E, New map, New dir
E+, Big map, Big dir

Hi Jon,

I am not too sure what you are asking here.

But I can say that 0.48 shows that the mSATA Filecore on this Pi 4 is
E+. Boot, Big Map

And that this ‘disc’ was formatted on the Pi and works in all known respects.

Filecore version is 3.75

And typing *Map shows that the current ‘disc’ is
big map, big directories

I’m trying to figure out a list of “Format FileCore Volume” options to present to the user, and default to the most appropriate for the FileCore version it’s running on, With FileCore 1.x for example, “D, Old map, New dir” might be the only valid usable option.

What I’m unclear about is which combinations of all three options are valid and on which FileCore versions they are usable.

OK, I have edited my post (immediately above) to make it a bit clearer.

But you obviously need someone with more knowledge than me.

I’ve tried v0.48 on A5000, RiscPC and Iyonix, all three see the discs but report as either unrecognised or unallocated. Debug logs here

What I’m unclear about is which combinations of all three options are valid and on which FileCore versions they are usable.

Up to and including RISC OS 3.1, D (old map, new dir) and E (new map, new dir) are supported. RISC OS 3.5 and above offically ceased support for D format harddiscs (according to PRM 5a – D format floppies remain supported), but I think the code was still there and it worked.

RISC OS 3.8 and later added E+ format (big dir). Depending on LFAU/idlen, it is either new map or big map. E format remains officially supported.

The Ursula docs say that the code to handle e.g. L format floppies and D format harddiscs remain in FileCore, but are unsupported and of course deprecated.

D Format is an Arthur invention IIRC, and E Format started with RISC OS 2.

I’ve tried v0.48 on A5000, RiscPC and Iyonix, all three see the discs but report as either unrecognised or unallocated

Thanks for the logs. I’ve grabbed them and will investigate later.