[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: My Summer of Code Project

From: Alex Roman
Subject: Re: My Summer of Code Project
Date: Wed, 25 Apr 2007 10:20:28 -0400

On 25/04/07, Marco Gerards <address@hidden> wrote:
"Alex Roman" <address@hidden> writes:

Hi Alex,

Please don't top quote, it is confusing ;-).
GMail is doing it... Sorry :(

> Interesting piece of code... Yet another example of showing how to
> implement an ATA/IDE controller driver :)


btw, do you know

The site looks familiar, I think I've been there before sometime... It
looks interesting, thank you for the link!

If you are looking for even more information, I could have a look at
which books about this subject I can recommend.

IIRC someone was saying that GSoC students will get an O'Reilly Safari
books account. If that's so, hopefully books there will be useful.

> Right now I'm pondering whether it is worth implementing a BIOS calls
> CDROM boot support, or whether I should just go right ahead and do it
> all with the ATA controller.

Both are important!  Really...

You should know GRUB 2 is designed to be portable and runs on lots of
different systems.

When the firmware gives access to the CDROM drive, this is usually a
nice feature to have.  One thing is that you have support for it, even
if it is SCSI (which you won't implement) or something else which is
terribly obscure :-).

Another nice reason you want this is that usually the firmware tells
you which drive you booted from.  For example, when you boot from a
CDROM drive it is easy to figure out which drive to load all files
from.  Think of livecds, etc.

Actually, an IDE driver is a terrible thing to have.  But it is
required for broken systems like the PC.  Some BIOSes do not have
CDROM support.  Other don't give you access to the CDROM drive when
you do not use it for booting.

I see, yes. It makes sense why we would want a BIOS calls driver too

> I'm not sure how IDE controllers work on PPC, since I've unfortunately
> never used the architecture...

If you make sure you keep endianess in mind, you usually will be doing
the right thing.  Besides that, on the PPC all IO is memory mapped.
You can have a look at linux to see how it deals with IO access.

I might need a bit of help as to how I should keep the endianness at
bay... Are there macros or functions currently in GRUB2 that are
architecture dependent and convert a number to the right endianness?
Are there other mechanisms?

> Technically, if the ATA/IDE driver is there, implementing the ATAPI
> command set to "talk" to the CDROM and interpreting the El-Torito spec
> shouldn't be that hard.

Yeah :)

> If CD-ROM drives are ATAPI on all platforms (where they use ATA), and
> the ATA code is there, the ATAPI and El Torito layer should stay
> cross-platform. The interesting bit will be making it so that
> "plugging in" a SCSI driver will require the least amount of code
> change.

El Torito is PC only, no?

From what I've read, it seems like El Torito is just a standard for
the layout of the ISO, it shows how the boot image is stored in the
iso9660 image. Wikipedia knows all :P

> Anyways, I'm kind of rambling for now... Until the official "code
> start" day I'll do some more reading and investigating how it would be
> best to tie the code into GRUB2 to give the most elegant solution.

One good way to start is by just fixing random things in GRUB 2.  Play
with grub-emu, make a floppy image with GRUB 2 on it and boot it from
qemu.  Setup a good development environment (talking about this is
perhaps a smart thing to do, if you lack the experience).

Yes, I need to do that. Setting one up shouldn't be a problem. I've
built GRUB1 before on linux... And besides vim (don't want flame wars,
to each their own!), GNU devel tools (gcc, make, binutils, etc) and a
shell, what else do I need? :-)

For some other summer of code projects (like ffmpeg), the students we
required to send in patched before they were qualified.  IOW: you
couldn't be accepted, unless you sent in patches that were good enough
to make it into SVN.  By doing this they showed they are capable
enough to work on the project.  But besides that, and that is what I
am trying to say, is that it usually helps if you poke around a bit
and play with the code, you don't even have to do something useful.
And ask lots and lots of questions :-)

I should perhaps add some debugging messages to see how code is
executed, the general flow of the bootloader...


Grub-devel mailing list

Alex Roman <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]