Re: My Summer of Code Project

[Alex Roman]

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 :)
>
> Yeah.
>
> btw, do you know http://www.osdever.net?

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
http://en.wikipedia.org/wiki/El_Torito_(CD-ROM_standard)

> > 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...

> --
> Marco
>
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel


--
Alex Roman <address@hidden>