Flash Drives Incorrectly Identified as Not DOS

[ashbc1]

I'm using an MQX4.2 port with MFS.   I'm having problems with various different USB flash drives, partly because of the following, taken from MFS_Mount_drive_internal in mfs_mount.c

if ((boot_sector[0] != MFS_DOS30_JMP) && (boot_sector[0] != MFS_DOS30_B))
{
result = MFS_NOT_A_DOS_DISK;
}

On a lot of devices boot_sector[0] does not match either of the allowed values (0xEB or 0xE9) so we drop out.   If I expand this check to allow for other values - I've seen 0x33 and 0xFA so far - the code below causes the same return value:

bpb_sector_size = mqx_dtohs(bpb_ptr->SECTOR_SIZE);
if (bpb_sector_size % drive_ptr->SECTOR_SIZE)
{
result = MFS_NOT_A_DOS_DISK;
}

The disks in question are actually perfectly valid FAT32 formatted devices.   I'm not an MFS expert and I'm struggling to find a reliable definition of the values in question or what values are legitimate.   Some information on either would be welcome.   Has anybody else had a similar problem?

Thanks in advance

[ashbc1]

This is clearly connected to the disk file system.  Disks that work are in adherence to the FAT system on the wiki page danielchen.   The way the boot_sector array has a structure overlaid (something that would be in breach of most coding standards BTW) lines up nicely - dump below from debug:

bpb_ptr 0x3f021260 0x3f014c50 36 bios_param_struct_disk
JMPBOOT "\353X" 0x3f021260 3 uint8_t[3]
[0] 0xeb 0x3f021260 1 unsigned char
[1] 0x58 0x3f021261 1 unsigned char
[2] 0x90 0x3f021262 1 unsigned char
OEMNAME "MSDOS5." 0x3f021263 8 uint8_t[8]
SECTOR_SIZE "" 0x3f02126b 2 uint8_t[2]
[0] 0x00 0x3f02126b 1 unsigned char
[1] 0x02 0x3f02126c 1 unsigned char
SECTORS_PER_CLUSTER "" 0x3f02126d 1 uint8_t[1]
[0] 0x08 0x3f02126d 1 unsigned char
NUMBER_OF_FAT "" 0x3f021270 1 uint8_t[1]
[0] 0x02 0x3f021270 1 unsigned char
ROOT_ENTRIES "" 0x3f021271 2 uint8_t[2]

A dump from a disk that fails does not fit so well, which given the number of options is not really surprising:

bpb_ptr 0x3f021260 0x3f014c50 36 bios_param_struct_disk
JMPBOOT "3\300" 0x3f021260 3 uint8_t[3]
[0] 0x33 0x3f021260 1 unsigned char
[1] 0xc0 0x3f021261 1 unsigned char
[2] 0x8e 0x3f021262 1 unsigned char
OEMNAME "\320\274" 0x3f021263 8 uint8_t[8]
[0] 0xd0 0x3f021263 1 unsigned char
[1] 0xbc 0x3f021264 1 unsigned char
[2] 0x00 0x3f021265 1 unsigned char
[3] 0x7c 0x3f021266 1 unsigned char
[4] 0xfb 0x3f021267 1 unsigned char
[5] 0x50 0x3f021268 1 unsigned char
[6] 0x07 0x3f021269 1 unsigned char
[7] 0x50 0x3f02126a 1 unsigned char
SECTOR_SIZE "\037" 0x3f02126b 2 uint8_t[2]
[0] 0x1f 0x3f02126b 1 unsigned char
[1] 0xfc 0x3f02126c 1 unsigned char
SECTORS_PER_CLUSTER "" 0x3f02126d 1 uint8_t[1]
[0] 0xbe 0x3f02126d 1 unsigned char
NUMBER_OF_FAT "" 0x3f021270 1 uint8_t[1]
[0] 0xbf 0x3f021270 1 unsigned char

My suspicion is that, despite being nominally FAT32 formatted, they are in fact exFAT.   I can find no definitions for any of the values I read from any disks that fail.

This is not Assumed Answered, far from it

[danielchen]

Hi Ashley Clarke

I would suggest you contact with Embedded Access, the owner of MQX, to see whether they have a solution for this.

http://embedded-access.com/ 

Regards

Daniel

[rbphilip]

Daniel.. This is a serendipitous question indeed, as I have just experienced the same problem. A transcend USB drive does *not* have a "jump" instruction. Any thoughts on how to inspire MFS to treat this (perfectly valid FAT32 USB drive) as it should? 

[ashbc1]

Thanks Rob.  Interesting.   Have you managed to progress this?

[danielchen]

Hi Ashley:

For Boot sector, common structure of the first 11 bytes used by most FAT versions for IBM compatible x86-machines since DOS2.0 are:

Byte Offset	Length (bytes)	Description
0x000	3	Jump instruction. If the boot sector has a valid signature residing in the last two bytes of the boot sector (tested by most boot loaders residing in the System BIOS or the MBR) and this volume is booted from, the prior boot loader will pass execution to this entry point with certain register values, and the jump instruction will then skip past the rest of the (non-executable) header. See Volume Boot Record. Since DOS 2.0, valid x86-bootable disks must start with either a short jump followed by a NOP (opstring sequence 0xEB 0x?? 0x90[11][12] as seen since DOS 3.0[nb 3]—and on DOS 1.1[13][14]) or a near jump (0xE9 0x?? 0x??[11][12] as seen on most (Compaq, TeleVideo) DOS 2.x formatted disks as well as on some (Epson, Olivetti) DOS 3.1 disks). For backward compatibility MS-DOS, PC DOS and DR-DOS also accept a jump (0x69 0x?? 0x??)[11][12][15] on removable disks. On hard disks, DR DOS additionally accepts the swapped JMPS sequence starting with a NOP (0x90 0xEB 0x??),[15] whereas MS-DOS/PC DOS do not. (See below for Atari ST compatibility.) The presence of one of these opstring patterns (in combination with a test for a valid media descriptor value at offset 0x015) serves as indicator to DOS 3.3 and higher that some kind of BPB is present (although the exact size should not be determined from the jump target since some boot sectors contain private boot loader data following the BPB), while for DOS 1.x (and some DOS 3.0) volumes, they will have to fall back to the DOS 1.x method to detect the format via the media byte in the FAT (in logical sector 1).

More details, please refer to below link.

Design of the FAT file system - Wikipedia 

Regards

Daniel

[ashbc1]

Daniel.  I've had to leave this for a while due to other priorities, but we are now at a point where I need a solution.  Your answer may well be correct information but I'm afraid it does nothing to solve the issue.   It is noteworthy that I am not alone in seeing this problem.   I have also just recreated it on a tower board to eliminate any potential H/W issues.  This is somewhere in the depths of MQX!!