About ISO 9660 volume descriptors, path tables etc sizes

[hdhzero]

Hi everyone o/

I'm trying to boot my OS from CD created by misofs, using el-torito with no-emulation. In order to learn ISO 9660, I was programming in C a simple program that parses an ISO image and shows the contents. The program shows correctly primary volumes descriptors, but it doesn't get even closer to show path tables and/or directories and files.

For instance, program shows that LBA of path table is in sector 0x15, but using hexdump it shows that it appears to be in sector 0x18. So my first question is: are LBA and sector numbers equivalents? E.g LBA 0 is sector 0, LBA 1 is sector 1 and so on. If there's no equivalency, how can I convert from sectors to LBA and from LBA to sectors? I've searched about CHS, but I could not found how many heads and cylinders a CD has, only the sector's size, that was 2048 bytes (which is also the size reported by the primary volume descriptor)

My other question is: is it possible to a path table, a directory or file to not start in the beginning of a sector?

Some other info:
- using x86, so I am reading the LSB fields
- to generate the iso, i used: mkisofs -R -b boot.img -no-emul-boot -boot-load-size 4 -o cd.iso DIR/

The output of the above command was:
I: -input-charset not specified, using utf-8 (detected in locale settings)
Size of boot image is 4 sectors -> No emulation
Total translation table size: 2048
Total rockridge attributes bytes: 414
Total directory bytes: 616
Path table size(bytes): 10
Max brk space used 0
898 extents written (1 MB)

And here is the output of hexdumpc: http://pastebin.com/18cJxYJ0

[shikhin]

Hi,

I was programming in C a simple program that parses an ISO image and shows the contents.

Since no one I know here appears to be psychic, the source of the program would surely help.

But using hexdump it shows that it appears to be in sector 0x18.

While my hexdump observing skills are surely poor, it appears to me that both the values are wrong, and according to the hex dump, the path table is located at LBA 0x14.

The location of the little endian path table is at offset 140 (0x8C) in the primary volume descriptor. The PVD appears to be at 0x8000, and at 0x808C is 0x14.

So my first question is: are LBA and sector numbers equivalents?

Nope.

How can I convert from sectors to LBA and from LBA to CHS?

http://wiki.osdev.org/ATA_in_x86_RealMo ... LBA_to_CHS documents that really well.

I'm still not sure why you might want to convert LBA to CHS in the CD bootsector, though. Int 0x13 extensions allow you to read sectors off the disk by just the LBA.

My other question is: is it possible to a path table, a directory or file to not start in the beginning of a sector?

Nope.

Regards,
Shikhin

[Brendan]

Hi,

Doh - Shikhin beat me to it. Please ignore stuff I've said that Shikhin already mentioned!

For instance, program shows that LBA of path table is in sector 0x15, but using hexdump it shows that it appears to be in sector 0x18.

Which path table? There are 2 of them (one for big-endian and another for little-endian).

Sector 0x15 starts at offset 0xA800 in the hexdump. This sector is empty (full of zeros) and is therefore not a path table.
Sector 0x18 starts at offset 0xC000 in the hexdump. This isn't a path table either.

The primary volume descriptor (at offset 0x8084 in the hexdump) says that the "type L path table" is at LBA 0x00000014. This means the path table is at offset 0xA000 in the hexdump. This does look like a path table for a disk that has no directories (it contains one entry for the root directory only). The root directory starts in sector 0x18 (offset 0xC000 in the hexdump). I'm too lazy to decode the root directory for you (but it looks like there's only 3 files - "BOOT.CAT", "BOOT.IMG" and "HELLO.TXT").

So my first question is: are LBA and sector numbers equivalents?

That depends how you number sectors (for no sane reason, people have a habit of saying the first sector is sector #1 and not sector #0). The first sector is LBA 0 at offset 0 in the hexdump; the second sector is LBA 1 at offset 2048 in the hexdump, etc.

I've searched about CHS, but I could not found how many heads and cylinders a CD has, only the sector's size, that was 2048 bytes (which is also the size reported by the primary volume descriptor)

For a CD, there's only one head/side and one long spiral track that can cover the entire disk.

My other question is: is it possible to a path table, a directory or file to not start in the beginning of a sector?

No. They always start at the beginning of a sector.

This doesn't mean that (for e.g.) a directory with 1234 directory entries doesn't have a some directory entries that cross sector boundaries though.


Cheers,

Brendan

[hdhzero]

Thanks for your reply!

I will fix my code and post it here.

Yeah, my program shows that path table's LBA is at 0x14, but when I look for the output generated by hexdump, only in 0xC4000 (which is sector 0x18) that I found chars with stuff like BOOT.IMG;1.

One of the fields of path table is
8 (variable) Directory Identifier (name) in d-characters.
But when I look at LBA 0x14, there are no printable characters, so I though there was something wrong with my code

I know that BIOS can read by using the LBA directly, but as I was working with an iso image, all I had was a group of bytes (the iso image is stored in a char v[]) . I knew the sector size, but i did'nt know the number of cylinders and heads, so I could'n convert from LBA to CHS. I wanted the conversion to map from LBA to CHS and then to a position to index in char[]. What I really wanted was a way to convert from LBA to an index in a char[].

That depends how you number sectors (for no sane reason, people have a habit of saying the first sector is sector #1 and not sector #0). The first sector is LBA 0 at offset 0 in the hexdump; the second sector is LBA 1 at offset 2048 in the hexdump, etc.

For a CD, there's only one head/side and one long spiral track that can cover the entire disk.

When I said sector, I forgot about the fact that sectors start from 1. For my own purposes, I was interpreting the iso image like this:

typedef struct { char data[2048]; } Sector;

int main() {
Sector* ptr; //stores the iso
/* read and store the iso image in ptr */
....
}

So when I asked about LBA and sector equivalency, I wanted to know if LBA N == ptr[N]. Sorry for the confusion, it's the habit of starting counting from zero

[shikhin]

Hi,

Doh - Shikhin beat me to it.

Certainly a first.

Yeah, my program shows that path table's LBA is at 0x14, but when I look for the output generated by hexdump, only in 0xC4000 (which is sector 0x18) that I found chars with stuff like BOOT.IMG;1.

Brendan's post explains the answer to this - for the lazy:

The primary volume descriptor (at offset 0x8084 in the hexdump) says that the "type L path table" is at LBA 0x00000014. This means the path table is at offset 0xA000 in the hexdump. This does look like a path table for a disk that has no directories (it contains one entry for the root directory only). The root directory starts in sector 0x18 (offset 0xC000 in the hexdump). I'm too lazy to decode the root directory for you (but it looks like there's only 3 files - "BOOT.CAT", "BOOT.IMG" and "HELLO.TXT").

Just as a quick note, the path table only points to directories, not all files. Moreover, the "root" directory is also present as a directory. For a ISO image with no directories, you'd find only one entry in the path table, with no name (which is the reason you couldn't find any printable characters in the path table), which is the root directory.

I know that BIOS can read by using the LBA directly, but as I was working with an iso image, all I had was a group of bytes (the iso image is stored in a char v[]) . I knew the sector size, but i did'nt know the number of cylinders and heads, so I could'n convert from LBA to CHS. I wanted the conversion to map from LBA to CHS and then to a position to index in char[]. What I really wanted was a way to convert from LBA to an index in a char[].

I'm not sure I got that right, but to me, it seems as if you're confusing stuff in there. LBA is simply a way of specifying the location of data on the disk. The disk is, "logically", divided into little blocks of 2048 bytes each.

So, LBA 0 would be the first block of these little blocks, and the index into the area where you read the ISO would be 0 * 2048. For LBA 1, it would be the second block of the little blocks, and the index into the area would be 1 * 2048. Similarly, for LBA N, the index into the area would be N * 2048.

CHS is certainly a lot messier than that - so why would you want to do "LBA to CHS and then to the index" - rather than simply "LBA to the index"?

I forgot about the fact that sectors start from 1.

Well, sectors start from 0, and that's what Brendan says. I'm not sure you interpreted him correctly.

Regards,
Shikhin

[hdhzero]

Thanks, Shikhin and Brendan!

I'm not sure I got that right, but to me, it seems as if you're confusing stuff in there. LBA is simply a way of specifying the location of data on the disk. The disk is, "logically", divided into little blocks of 2048 bytes each.

I wasn't sure if a LBA always "pointed" to a block of 2048 bytes (or whatever the size specified in the volume descriptor).

Just as a quick note, the path table only points to directories, not all files.

Didn't know that. I thought that it would show something like "/BOOT.IMG" or "/HELLO.TXT".

Now everything is ok