ext2 boot sector

[stonedzealot]

Hi again, everyone! I was just wondering this time if anyone could find a ext2 bootloader anywhere. I'm trying to write one, but I don't have any examples so all I know is that my method is *theoretically* right (I hope). btw, if anyone has a good knowledge of the ext2 fs, then take a look at this and tell me if you see any problems (other than the fact that it's incomplete)

You can find the code here:
http://www.geocities.com/osdevmd/bootloader.asm
Thanks alot everyone!

[Pype.Clicker]

One thing that looks like a limit, imho, is that readSector assume the whole filesystem is starting at sector 2, track 0, head 0. But on a floppy it shouldn't be too harmful -- as i assume you're not hardcoding the location of your EXT2 partition in a bootsector, this must be a floppy-located bootsector.


so, if i try to make things clear,

superblock -> 1000:0000
has block size, revision level, blocks per group and free blocks/inode counters. also has the pointer to the first inode

maybe you should check blocksize is indeed 1024 before you go on and show an error otherwise (at least halt).

group descriptor -> 1000:0000
has the block number for the inode table of group 0 (i guess you assume your kernel.bin will be in group 0 -- i'm not 100% sure it's wise, but maybe floppy EXT2 have just one group, in which case ...)

I see you have sector = block *2. Remember BIOS starts with boot == sector 1 (sector 0 is invalid). How does EXT2 starts counting blocks ? i.e. what is the block number of superblock in group 0 ?
You load it as BIOS sector #3, what is on sector #2 ? I think you miss something like "ADD CL,<constant>" before you call readsectors.

moreover, i fear you will *not* successfully 46 sectors in one BIOS call (as for floppies, you're limited to 18 sectors in a row for technical reasons) -- btw, what makes you think the inode table is 46 sectors long ?

and, oh dear ... i can't see any error checking in your readsectors function ...geez j00r g0nn4 b3 1n tr0ubl3 ... Remember floppy calibration may require up to 3 attemps to find a sector. Yeah, it suxx, but that's the way it is.

after this, i'm lost.
i had understood the inode table was a list of blocks numbers. and the root directory seems to be described by inode #2 (if i can trust
http://www.nondot.org/sabre/os/files/Fi ... 2fs_7.html)

from there, you need to scan the root directory for your name ... and this mean you must first scan the inode for blocks holding the directory data...

If i were you, i would rather use reserved sectors (see the superblock descriptions) to store my kernel.bin: i fear the loading process will be too complex for a single-stage bootloader ...

[stonedzealot]

Thanks pype, here are some responses:

I start at sector 2 because sectors 0-1 are used for boot sector and boot record...and yes, this is a floppy bootsector.

superblock: yeah, that sounds good to check the blocksize

group descriptor: yep, the ext2 floppy has a single block group. Ah, okay, the superblock is block 2 (beginning at 1024 bytes) but since the BIOS won't recognize the bootsector, it'd start at sector 2 rather than three...

Okay, the floppy reads I didn't know you had a 18 track limit
::) something I would've found out I guess...but I know that the inode table is 46 sectors long because the standard ext2 format makes it so (from block 5 - 28 = 23 blocks = 46 sectors)

Then....well...in the overview of ext2 I was reading, it made it sound like the inode table was a list of inodes, followed by all the data blocks...I'll have to look into this further.

Finally, as for scanning the root directory, I can't do that. Just because I have no idea what hash algorithm linux or ext2 used to hash the names. I thought is was Reiser's r5, so I wrote a small prog to hash a given name, then searched for that in the hexdump of the floppy and no mas. This is the real problem I have: the name isn't just sitting there in the code, like it is in a FAT partition. All the other things I would've figured out eventually (though you've sped the process by lightyears/s)...

Thanks alot pype

[stonedzealot]

Well, I took a look at your version of the ext2 overview and realized that it is (c) 1994 and keeps mentioning ext2fs v.5. Most of the information is the same, but none of the second revision things are (the revision with dynamic inodes) and it doesn't cover any of the hashing (because the original ext2fs used linked directories which are very slow and cumbersome for searching, but also very easy to search). I'll see what I can do with your suggestions but if anyone can still tell me what hash alg linux/ext2fs uses, I'd be a happy man.

Alternatively, I may just find a mkext2fs program from back in the day and format it in the old structure. Problem with that is that other people using the OS (which there won't be any for now) would have to do that as well...provided I didn't provide a floppy image...

[Pype.Clicker]

translated quoting from "programmation Linux 2.0":

Other directory management functions are located in the file fs/ext2/namei.c

I think the hashing is only used when the directory becomes too large ...

[stonedzealot]

whoa, that's some heavy code right there. It's gonna take me awhile to parse through that. The only things is...if it's not hashed until the directory is too big...why couldn't I see kernel bin written in the hexdump, like I could with the defacto directory lost + found?

Another note: Would you say that book you quoted from is very useful? I think I may have to purchase a copy if it covers the linux kernel very well...

EDIT: Well, my fault, I thought that directories=files, and of course I'm wrong again!

[Pype.Clicker]

yes, i would say it worth buying if you plan to dig the linux kernel ... it is a really good reference, documenting the concepts, the API, etc. Most graphics i saw on Operating System Resource Center about EXT2FS, for instance, come straight from that book.

It has very complete description of the internals and functions aswell a kind of 2-levels book: either stay in "overview mode" or dive in "tech details", for each chapter ...

[stonedzealot]

Okay, so here's the revised plan of attack. I ditch the scanning of the entire inode table and just find the root inode (second on in the table). I then use the i_block structure to scan the first twelve blocks of the directory for my file (and more blocks if needed).

The problem that I have now is that...what's the structure of a file reference (e.g. what I'll find in the root directory data, not the inode). I used to think that directory=file (see above) but !true. Then I figured I'd track down the struct file in the linux source but I haven't been able to find where that is...

[Tim]

I think I should point out that a typical Linux boot loader (i.e. LILO) hard-codes the kernel block locations. That is, a normal Linux program looks up the block numbers for the kernel file image and writes them to the boot loader. If you move the kernel, you must run the program to rewrite the boot loader.

This is also how GRUB works, when it loads the second stage loader: the first stage loader (boot sector) doesn't know about any file system, but just loads the sectors it's told to load.

[stonedzealot]

Yeah. Quickly this FS work is becoming cumbersome withing a 512 byte structure...maybe I'll see if I can do that...

What "normal linux program" would look up the block?

[stonedzealot]

Okay, I just answered my own question! ext2fsprog's ext2ed works very well...for a floppy...on an intel. With this, I know that my kernel is on inode 12 and takes up blocks 41-45. Excellent. Also, I found out that the ext2 block count begins at 0 (so the superblock is on block 1), that the block listed in the root inode gives you all of the directory entries, their names and their respective inodes (which will then give you their blocks)! All in all a very informative program for disks < 2GB on intel (little endian) machines!