[ECOS] IDE + fatfs issues

[ECOS] IDE + fatfs issues

[David Brennan]

I have a couple of questions about the implementation "rules" that are
checked on both IDE and fatfs "devices".

IDE:
On or about line 372 of ide_disk.c within function ide_disk_init()
after identifying the disk, the "Type" is verified:
    if (((ide_idData->general_conf>>8)&0x1f)!=2) {
        diag_printf("IDE device %d:%d is not a hard disk!\n",
                    info->port, info->chan);
        return false;
    }
I'm not sure where to look up the specifications for this. But my 8MB
compact flash reports a "type" of 4, not 2. (If this is platform
dependent, the board is a GE VMIVME7750. I use a standard PC
configuration with some home grown VME logic.) I can hack up this to
work. But I don't know if there is a more general way to perform this
test. I am open to suggestions for a solution. I would like to get _a_
solution into the main repository so I will not have to make this
"hack" in the future.

fatfs:
On or about line 1885 of fatfs_supp.c within function fatfs_init()
after reading the boot record, a number of fields are validated:
    // Check some known boot record values
    if (0x29 != boot_rec.ext_sig       ||
        0x55 != boot_rec.exe_marker[0] ||
        0xAA != boot_rec.exe_marker[1])
        return EINVAL;

I believe the first test is not always valid. On my Compact Flash
card, formatted with FreeDOS v0.9 beta, this field is 0x00. According
to Microsoft's documentation for fatfs, Windows NT requires this to be
either 0x28 or 0x29. I found other documentation that states that if
it is 0x29, then the next 3 fields are valid, but 0x00 was also valid.
As a temporary fix, I just hacked out the first check. I can submit a
"true" patch for this if requested. But I thought I would look for
some opinions first.

Thanks
David Brennan

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] IDE + fatfs issues

[Paul D. DeRocco]

> From: David Brennan
>
> On or about line 1885 of fatfs_supp.c within function fatfs_init()
> after reading the boot record, a number of fields are validated:
>     // Check some known boot record values
>     if (0x29 != boot_rec.ext_sig       ||
>         0x55 != boot_rec.exe_marker[0] ||
>         0xAA != boot_rec.exe_marker[1])
>         return EINVAL;
>
> I believe the first test is not always valid. On my Compact Flash
> card, formatted with FreeDOS v0.9 beta, this field is 0x00. According
> to Microsoft's documentation for fatfs, Windows NT requires this to be
> either 0x28 or 0x29. I found other documentation that states that if
> it is 0x29, then the next 3 fields are valid, but 0x00 was also valid.
> As a temporary fix, I just hacked out the first check. I can submit a
> "true" patch for this if requested. But I thought I would look for
> some opinions first.

You're certainly right about this. I've seen plenty of disks, mostly old
floppies, that don't have 29 and the other fields present. In my own code,
I've always checked for the 55AA at the end, and then ensured the number of
FATs is in 1-4, ensured the sector size is some small nonzero integral
multiple of 512, ensured the number of sectors per cluster is in 1-64, and
ensured the number of sectors per FAT is nonzero. I also used to check for a
short or near jump op-code in byte 0 (E9 or EB), but I suspect dummy x86
boot code isn't really required, so it might make sense to leave this test
out nowadays.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] IDE + fatfs issues

[Frank Pagliughi]

Hey All

I'm revisiting my attempt to read a CompactFlash card using IDE/fatfs, 
and am still looking at these same issues...

David Brennan wrote:
> I have a couple of questions about the implementation "rules" that are
> checked on both IDE and fatfs "devices".
>
> IDE:
> On or about line 372 of ide_disk.c within function ide_disk_init()
> after identifying the disk, the "Type" is verified:
>     if (((ide_idData->general_conf>>8)&0x1f)!=2) {
>         diag_printf("IDE device %d:%d is not a hard disk!\n",
>                     info->port, info->chan);
>         return false;
>     }
>   
Looking at ATA specs, even going back a few years, it appears that the 
bits used to make this test are considered "retired". Therefore this 
test appears to be invalid and should be removed.

> fatfs:
> On or about line 1885 of fatfs_supp.c within function fatfs_init()
> after reading the boot record, a number of fields are validated:
>     // Check some known boot record values
>     if (0x29 != boot_rec.ext_sig       ||
>         0x55 != boot_rec.exe_marker[0] ||
>         0xAA != boot_rec.exe_marker[1])
>         return EINVAL;
>
> I believe the first test is not always valid. On my Compact Flash
> card, formatted with FreeDOS v0.9 beta, this field is 0x00. According
> to Microsoft's documentation for fatfs, Windows NT requires this to be
> either 0x28 or 0x29. I found other documentation that states that if
> it is 0x29, then the next 3 fields are valid, but 0x00 was also valid.
> As a temporary fix, I just hacked out the first check. I can submit a
> "true" patch for this if requested. But I thought I would look for
> some opinions first.
To me it appears that the code is reading the disk's MBR and *not* the 
FAT boot sector of the first partition. For a hard drive, doesn't the 
code need to read the first sector of the drive (the MBR), parse the 
partition table contained therein, then read in the sector indicated by 
the partition table? Or am I reading this wrong?

- Frank

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] IDE + fatfs issues

[Jürgen Lambrecht]

  On 16/06/2008 20:58, Frank Pagliughi wrote:
> Hey All
>
> I'm revisiting my attempt to read a CompactFlash card using IDE/fatfs, 
> and am still looking at these same issues...
>
> David Brennan wrote:
>> I have a couple of questions about the implementation "rules" that are
>> checked on both IDE and fatfs "devices".
>>
>> IDE:
>> On or about line 372 of ide_disk.c within function ide_disk_init()
>> after identifying the disk, the "Type" is verified:
>>     if (((ide_idData->general_conf>>8)&0x1f)!=2) {
>>         diag_printf("IDE device %d:%d is not a hard disk!\n",
>>                     info->port, info->chan);
>>         return false;
>>     }
> Looking at ATA specs, even going back a few years, it appears that the 
> bits used to make this test are considered "retired". Therefore this 
> test appears to be invalid and should be removed.
Could be.
For Compact Flash support, we just added an extra check to be 4, and it 
works already for many years now for many types of CF cards:

     //JL: standard CF has 0x848A ID, but not all types
     if ( (((ide_idData->general_conf>>8)&0x1f)!=2) &&
          (((ide_idData->general_conf>>8)&0x1f)!=4) ) {
         diag_printf("IDE device %d:%d is not a hard disk or compact 
flash card!\n",

(maybe I should mail a patch?)
>
>> fatfs:
>> On or about line 1885 of fatfs_supp.c within function fatfs_init()
>> after reading the boot record, a number of fields are validated:
>>     // Check some known boot record values
>>     if (0x29 != boot_rec.ext_sig       ||
>>         0x55 != boot_rec.exe_marker[0] ||
>>         0xAA != boot_rec.exe_marker[1])
>>         return EINVAL;
>>
>> I believe the first test is not always valid. On my Compact Flash
>> card, formatted with FreeDOS v0.9 beta, this field is 0x00. According
>> to Microsoft's documentation for fatfs, Windows NT requires this to be
>> either 0x28 or 0x29. I found other documentation that states that if
>> it is 0x29, then the next 3 fields are valid, but 0x00 was also valid.
>> As a temporary fix, I just hacked out the first check. I can submit a
>> "true" patch for this if requested. But I thought I would look for
>> some opinions first.
> To me it appears that the code is reading the disk's MBR and *not* the 
> FAT boot sector of the first partition. For a hard drive, doesn't the 
> code need to read the first sector of the drive (the MBR), parse the 
> partition table contained therein, then read in the sector indicated 
> by the partition table? Or am I reading this wrong?
You are right, see my next mail.
Kind regards,
>
> - Frank
>


-- 
Jürgen Lambrecht
R&D Associate
Tel: +32 (0)51 303045    Fax: +32 (0)51 310670
http://www.televic-rail.com
Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium
Company number 0825.539.581 - RPR Kortrijk



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss