CHS to LBA conversion - How to get CHS and SPT on uSD card?

[Zaher]

I need to do conversion between CHS addressing to LBA using the following formula:

LBA = (( C x HPC ) + H ) x SPT + S - 1

where,

• C, H and S are the cylinder number, head number, and the sector number
• LBA is the logical block address
• HPC is the number of heads per cylinder
• SPT is the number of sectors per track

but I just don't know where and how to get those from a uSD card? Is there any way to get them using the MMC/SDIO HAL library or FATFS?

[Tesla DeLorean]

The cards use logical block addressing

The cylinder, head and sector parameters can inferred from the MBR and BPB

Typically 63 SPT and 255 HPC

[Zaher]

Clive,

Thank you for the quick answer. However, these values (SPT & HPC) are fixed for all types of SD cards? And how to get them from MBR and BPB? Is there any LL functions to access them?

Thanks again!

[Tesla DeLorean]

CHS has been irrelevant for 20+ years, the values are maximal and you end up well beyond 1023 cylinders.

They are not LL parameters, pull them directly from the structures in the relevant sectors. The logical block count comes out of the SD/MMC card's CSD REGISTER

[Zaher]

That’s true, but when it comes to SCSI, it is still relevant so I’m forced to adopt it in my code as I’m working on a SCSI project.

Getting block count from CSD register is no problem, but where or what structures are used to get the other values concerned?

I’m on my mobile device now, but I might need to look at the MMC/SD HAL driver once I’m back to my PC. Meanwhile, it would help a lot if you can provide more on how to get those values.

Thanks again!

[Zaher]

OK, I believe the "diskio" layer of the FATFS provides this function to read sectors off the medium:

/**
 * @brief Reads Sector(s) 
 * @param pdrv: Physical drive number (0..)
 * @param *buff: Data buffer to store read data
 * @param sector: Sector address (LBA)
 * @param count: Number of sectors to read (1..128)
 * @retval DRESULT: Operation result
 */
DRESULT disk_read (
	BYTE pdrv,		/* Physical drive nmuber to identify the drive */
	BYTE *buff,		/* Data buffer to store read data */
	DWORD sector,	 /* Sector address in LBA */
	UINT count		/* Number of sectors to read */
)

I did not try it yet, but I think reading the first sector one could get those values from MBR/BPB. Or there's another approach to do it?

[Tesla DeLorean]

The DISKIO is entirely LBA, similarly USBSTOR/MSC which can use SCSI READ6 or READ10 type command formats.

The MBR is typically at sector zero, and you can pull the BPB sector from the partition table. On "Floppy Format" media, the BPB is at sector zero and you dispense with the MBR.

[Zaher]

@Community member​ 

I guess if LBA<>CHS conversion was added, one can use the MSD SCSI functions' set as glue/wrapper functions for most of the disk-type SCSI commands. Or what do you think?

"The DISKIO is entirely LBA" so, it is the best way to access the storage device (SD card) at the block level or you suggest something else? How you read the 512 bytes below?

[Zaher]

You read sectors 0 and 1? I don't see any difference!

[Zaher]

@Community member​ 

Clive,

You're right, and I might not need it after all. But if you don't mind me asking, back in the day when you were working on a SCSI project, how you were handling the addressing of storage device (probably a hard drive) in commands like Read Capacity(10) , Read/write, Format Unit? Also when you need to provide parameters for disk geometry, like those you find on format page, how you would specify them?

You know, I started this project almost two years ago. At the time, I had thousands of questions and I had to spend months reading tons of material about SCSI, as well as, the SPC I'm using, until I became well-founded in the subject. Now, all I need to get done is to adopt the functions needed to format/read/write the medium.

Any input is highly appreciated!

[Tesla DeLorean]

SCSI and SASI before that always used BLOCK addresses. You could often program the geometry into the controller and it would store the configuration and bad block lists onto a maintenance cylinder, ie -1

I think the constraints you are labouring under are a result of register sizes used by the PC BIOS INT13 parameter.

The concept of cylinder, heads and records/sectors died a long while ago, storage media isn't that uniform, you can store far more data on the outer tracks than the inner ones.

I've worked with HD, TAPE, CD, DVD, etc and in more recent years with SD cards, NAND and eMMC devices.

READ/GET CAPACITY just tells you the number and size of blocks. FORMAT would lay down header and sector data on the blank media, which would otherwise be randomly magnetized.

[Zaher]

I think the constraints you are labouring under are a result of register sizes used by the PC BIOS INT13 parameter.

But what the PC BIOS had to do about it and what was the INT13 parameter?

[Zaher]

@Community member​ 

Turns out it's not needed for read/write accesses. It's only needed for format mode page.

[Zaher]

Well, for some reason non of the following returns a correct value: SDCardInfo.CardCapacity and SDCardInfo.CardBlockSize

Any idea?