Partition Manager
711 posts, 56 voices
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ... 29
Jon Abbott (1421)
2651 posts
|
This will be fixed in the release. It’s a 4K drive, but I was miscalculating the sector size.
Doug, I need to see debug/txt to find the root cause. Could you also try putting a CD/DVD into both drives to see if it then works. |
David Pitt (3386)
1248 posts
|
Ah! That reminds me of a conversation with sprow a while ago, 4 years ago. He was looking for a 4k disc and it seemed like this disc might be such but the conclusion was that it was “fibbing”. > > Sadly it's not a 4k native drive after all! > > FWIW this is what Windows had to say about the drive :- > > C:\Windows\system32>fsutil fsinfo ntfsinfo E: > > Bytes Per Sector : 4096 <--- should be 512 > Bytes Per Physical Sector : 4096 <--- agree > Bytes Per Cluster : 4096 <--- possible, but unusual > Bytes Per FileRecord Segment : 4096 <--- not sure > Clusters Per FileRecord Segment : 1 <--- agrees with above FileRecord It looks to be telling fibs about the first sector value, based on what the drive tells us. > The SSD had been in a Windows laptop formatted as NTFS, a clone of the HD > it was about to replace. DiscKnight has it as 512 sectors. HTH |
|
Jon Abbott (1421)
2651 posts
|
Its a 4K drive with a 512 byte logical sector size. Sprow will be after a 4K/4K drive. Bit 12 of word 106 determines if the logical sector size is >256 words |
Doug Webb (190)
1180 posts
|
Jon,
Debug sent by email as previously.
Gives the same error but have sent before and after debug text to help. |
|
Jon Abbott (1421)
2651 posts
|
Thanks for the logs Doug, it appears the documentation I added for ADFS_IDEDeviceInfo from the ADFS4 documentation may be incorrect for ADFS_IDEDeviceInfo 0. I’ll check the ADFS source, correct the documentation and update my code. |
|
Jon Abbott (1421)
2651 posts
|
Doug/David, please try v0.37 and let me know if it fixes your respective issues. |
|
David Pitt (3386)
1248 posts
|
0.37 is fine, all three ADFS discs are correctly described. TRhanks. |
Andrew McCarthy (3688)
605 posts
|
v0.36 works fine, it also produces a debug file |
|
Andrew McCarthy (3688)
605 posts
|
v0.37 works fine, it also produces a debug file |
|
Doug Webb (190)
1180 posts
|
Hi Jon, 0.37 gives “Division by Zero at line 564” with or without DVD’s in both drives. Debug code sent. |
Anton Reiser (471)
63 posts
|
4Kn drive: In PROCadfs_ide() I added Now the capacity of the 2TB 4Kn drive is shown correctly with 1.81 TB! FAT: Latest tests done with 0.37. |
|
Anton Reiser (471)
63 posts
|
Version 0.37 with an old drive from a win7/linux system:
|
|
Jon Abbott (1421)
2651 posts
|
I’m not sure that’s correct. From the T13 spec: Word 106 Physical sector size / Logical Sector Size I believe Word 106 should be %0111 0000 0000 0011 for a 4K drive with 4K logical sectors. I need to see the debug/txt log from the drive to see what it’s actually reporting. Bare in mind some drive incorrectly report the sector size in 106.
RISCOS 4 uses partition type 7 for FileCore, so it checks ADFS_FreeSpace64 and ADFS_DescribeDisc for responses. In your case neither are returning an error, so it assumes its a valid FileCore drive. What is odd is the FreeSpace returned value. I suspect that’s an undocumented return value if it can’t read the freespace.
Your slave drive isn’t reporting a size. I’ve added a check to stop the error, but need to investigate why there’s no size in the IDENTIFY response. |
|
Anton Reiser (471)
63 posts
|
To my understanding, if word 106 is valid and if bit 12 = 1, then the logical sector size field ist valid. Here the response from my two 4Kn drives (and my modified copy for LBA size)
So a check of the FileCore Boot Record data for validity may be sensible. |
|
Jon Abbott (1421)
2651 posts
|
Looking at your word 106, I’d be inclined to agree. It’s unfortunate that the spec isn’t clear on when 117 is valid. David Pitt’s drive has &6003 in 106 and 117 is not valid, which implies: if bit 12=1 and bit 13=0, sector size=(word 117/118) The ambiguity is around: if bit 12=1 and bit 13=1, sector size=512<<(bits 0-3) ??? illegal perhaps? RISCOS 4 uses partition type 7 for FileCore, so it checks ADFS_FreeSpace64 and ADFS_DescribeDisc for responses. In your case neither are returning an error, so it assumes its a valid FileCore drive. Yes, as we can’t trust FileCore SWI results I might need to look at the partition contents in a similar way to how it validating FAT. I will however look at the ADFS4 source and see if ADFS_FreeSpace64 returning R0=0 R1=-1 is a magic number that needs documenting. Does the drive show up with a Filer icon? EDIT: R0=0 R1=-1 is a magic number in my own code. I’ve now switched the FileCore detection to use OS_FSControl instead of *_FreeSpace |
|
Doug Webb (190)
1180 posts
|
OK one off the wall thought is that the drive is an old one that I may have run the available Linux set up from it that Castle supplied many years ago, still got LinLoader etc on there. I can’t be sure when it was last formatted either so it has got to be a few years old now. Update: Just tried IscaFS and it says not a valid ext2 image on drive but then again… |
|
Jon Abbott (1421)
2651 posts
|
If anyone wants to four-eyes the drive, its the Slave drive in this post which is reporting it supports LBA, doesn’t support LBA48, but has no LBA value set in words 60/61. I’ll add a check for 60/61 being zero and fall back to CHS instead – we’ll see if that works. EDIT: It’s CHS values aren’t valid either. What size is the drive? |
|
Doug Webb (190)
1180 posts
|
128GB, 117GB used and it was identified correctly before with earlier versions of PartMgr. HForm says the following if it helps Configuration 16383 Cylinders, 16 heads, 63 sectors/tracks Could it be a larger drive that was formatted down to 128GB limit for DMA? To check that I would have to dismantle the Iyoinix but if it helps let me know. |
|
Anton Reiser (471)
63 posts
|
To my interpretation bit 13=1 indicates a 512e (e for emulation) disc, with the internal sector size in bits 0-3, and bit 12=1 a non emulated sector size > 512 So word 106 = 0×6003 describes a 4K/512e disc.
So not illegal, but there will never be real hardware with emulated sectorsize <> 512. Knowing the physical sector size at 512e is useful to align partitions, clusters … at sector boundaries.
Yes |
|
Doug Webb (190)
1180 posts
|
So dismantled my Iyonix and it is indeed a larger drive, 160GB Seagate Barracuda, formatted down to 128GB ADFS so as not to breach the DMA limit. The drive is set for Cable Select. So I have a drive recovered from a PC , 80GB Western Digitial, which I have formatted and now placed in the Iyonix. Running PartMgr 0.37 gives the same error "Division by Zero at line 564” Debug code sent to Jon. |
Alan Adams (2486)
1149 posts
|
V0.37 works nicely here. |
Bryan (8467)
468 posts
|
V0.37 also works nicely here, although I can not upload a graphic However some comments on the information for a 1.00 GB spinning rust drive from an old Archimedies A410 currently connected via IDE/USB adapter to a Pi4 may be useful: SCSI::4 Filecore is an mSATA reporting as expected Which leads me to asking:-
Correction: this system boots from the mSATA as the spinning rust is too slow, but if I replace it with an SSD then the Pi will boot from the wrong disk. |
|
Jon Abbott (1421)
2651 posts
|
v0.38 is up, with some fixes for reported issues. @Doug Webb, your 160GB Seagate Barracuda is not returning a valid INQUIRY. There are many issues with it, such as being reported as a Flash drive, no CHS or LBA size details @David Pitt, your SCSI::2 drive that is showing 2xFileCore and several odd partitions. I’ve modified the FileCore code so it shouldn’t detect these as FileCore (I think they’re Linux?). As for the odd partitions at the end, the GPT partition table has less entries in it than described in the partition table count. @Alan Adams, it’s not picking up the volume name from the RootDir on your FAT32 drive, I’ll check the code @Anton Reiser, I’ve rewritten the 4K code based on your feedback, if you would like to confirm it gets your drive size correct
There’s two issues on this point: 1. I might be wrong on this, but my understanding is that RISCOS attempts to boot from the first valid drive it finds with a !Boot file/folder (on the defined FileSystem in CMOS. ADFS also supports a Drive parameter). If it’s a FileCore partition it checks the Boot option to see if should actually run/load/exec it. FAT partitions are treated slightly differently in that there’s no Boot flag to check, so it just runs it anyway. 2. MBR has a bootable flag on the partitions, but GPT does not. For GPT, either the partition GUID can imply bootable/non bootable, or the partition entry attributes can be used. There’s no formal standard, so its down to the OS maintainer to decide how The Partition bounty should cover bootable flag, as its specified to use GPT and knowing how to handle a partition is a basic requirement. So far as Partition Manager goes, I will implement setting the Boot flag within FileCore and the Bootable flag on MBR partitions. Once the Partition bounty starts its RFC process and we know how it’s going to be implemented, I can modify to handle GPT partitions. |
|
Andrew McCarthy (3688)
605 posts
|
Testing v.038. Partition Manager windows opens as expected, debug text: Log deleted. |
|
Bryan (8467)
468 posts
|
Thanks for that information, Jon Back to Partition Manager… The next one for you is a 516 MB Rust from a RiscPC600 The Pi reads, writes and verifies it OK, but PartMgr sees it as 516 MB Unallocated. add_partitions_GPT read_bytes_SCSIFS(0,&0,&0,..,&200) Address : 0 1 2 3 4 5 6 7 8 9 A B C D E F add_partitions_MBR Address : 0 1 2 3 4 5 6 7 8 9 A B C D E F Unallocated block Two more working discs from the same RiscPC600 give the same reports – as do yet two more from a RiscPC700, albeit with differing sizes. |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ... 29
