Dear Lennart,
A have a new fining here.
fdisk -l -u /dev/tfa0:
debdev1:~# fdisk -l -u /dev/tfa0
Disk /dev/tfa0: 14 MB, 14680064 bytes
2 heads, 32 sectors/track, 448 cylinders, total 28672 sectors Units =
sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/ tfa0p1 57 28799 14371+ 1 FAT12
On a keen look on the above fdisk output on my 16MB SD card, you can
find the cylinder information as 448 where as my driver ioctl returns
450.
I have found from the partition table that Total n/o sector for the
primary partition is 28743 (total sectors).
But my ioctl returns total cylinders as 450 i.e. 28800 sectors.
As 28743 is NOT any multiple of 64(2*32)i.e sectors*heads, the fdisk
tried manipulates it to get multiples of 64.
So, finally the best multiple 448 cylinders (i.e. 28672 sector)
So, finally that NOT a BUG in the driver instead is a generalization
made by fdisk command.
Please find the inline comments.
>Well you can either support partitions fully by making your driver work
>like the ide and scsi and such drivers do things, or you can just make
>it simpler and only support devices without a partition table and those
>with a single partition entry in the partition table. That would
>support probably 99.99% of cards you would encounter. You just have to
>check if a partition table exists, if it doesn't, just present the
whole
>device as the disk, while if a partition table exists, scan it for a
>partition that is not a blank entry, then find the start of that
>partition and present the device to the user starting at that sector.
This is a policy & NO policy is the driver should be implemented.
I think we need NOT handle all this in the driver. The upper layer of
the mount application looks into verifying this.
>> The partition layout mentioned in the partition table is same for the
>> Windows formatted SD & CAM formatted SD. I assume partition layout
>> starts at 0x1BE.
>
>If there is a partition table then it starts there.
There is a partition table in the CAM formatted device & it looks like
there is also a partition table in the win formatted device.
The details of there at offset 0x1BE are below.
CAM formatted SD Details
------------- 0x1BE offset detailed messages (decimal no
)------------------ Reading data from sector '0' at offset
0x1BE(Partition table start addr)
bootable = 0x80 (0x1BE)
beg-chs.heads = 0x1
beg-chs.sect = 0x1A
beg-chs.cylin = 0x0
sys-type = 0x1
end-chs.heads = 0x1
end-chs.sect = 0x60
end-chs.cylin = 0xC1
start sect = 0x39
n/o sec in part = 0x7047
Win formatted SD Details
------------- 0x1BE offset detailed messages (decimal no
)------------------ Reading data from sector '0' at offset
0x1BE(Partition table start addr)
bootable = 0x6F (0x1BE)
beg-chs.heads = 0x74
beg-chs.sect = 0x68
beg-chs.cylin = 0x65
sys-type = 0x72
end-chs.heads = 0x20
end-chs.sect = 0x6D
end-chs.cylin = 0x65
start sect = 0x2E61964
n/o sec in part = 0x440A0DFF
>> >> Sfdisk -l /dev/tfa0 ( CAM & win)
>> >> Disk /dev/tfa0: 448 cylinders, 2 heads, 32 sectors/track
>> >> Units = cylinders of 32768 bytes, blocks of 1024 bytes, counting
from
>> 0
>> >>
>> >> Device Boot Start End #cyls #blocks Id System
>> >> /dev/tfa0p1 * 0+ 449 450- 14371+ 1 FAT12
>> >> /dev/tfa0p2 0 - 0 0 0 Empty
>> >> /dev/tfa0p3 0 - 0 0 0 Empty
>> >> /dev/tfa0p4 0 - 0 0 0 Empty
>> >> Warning: partition 1 extends past end of disk
>> >>
>> Can you quote your comments on the warning given by sfdisk command
>> above?
>
>The warning means the driver is broken and says the wrong number of
>cylinders for the device.
NO, I think driver is NOT broken instead the partition tables speaks SO.
sfdisk returns 448 cylinders for my 16MB SD card, where as my driver
ioctl returns 450.
I have found from the partition table that Total n/o sector for the
primary partition is 28743 (total sectors) whereas my ioctl returns
total cylinders as 450 i.e. 28800 sectors.
As 28743 is NOT any multiple of 64(2*32)i.e sectors*heads, the sfdisk
manipulates it to get multiples of 64. The best multiple is 448
cylinders (i.e. 28672 sector). This is where we are missing 128 sectors.
So, finally that NOT a BUG in the driver instead is a generalization
made by sfdisk command.
>Perhaps one of the more modern ways of getting disk size would return
>the full number of sectors instead. For example the ioctl BLKSSZGET
and
>BLKGETSIZE and BLKGETSIZE64.
I added BLKGETSIZE ioctl. When I tried to note the ioctl called at mount
time I find it is all the time HDIO_GETGEO.
At this angle it clear that sfdisk output is Not the result of BUG in
the driver instead it is a result of partition table TOTAL SECTORS
entry.
I have a doubt where Linux is treating this a separate class of device.
I heard some thing about the FS found on the Floppies.
I guess FS on win & linux SD is such kind of FS & so I am able to mount
it.
How do I verify this? I am clean about the FS on Floppies. I will try to
find it tomorrow on the NET.
As CAM SD has altogether HD like info. And that is why we are NOT able
to mount it.
Can you comment on this?
Regards,
Mukund Jampala
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |