[Top][All Lists]

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

Re: My Summer of Code Project

From: Marco Gerards
Subject: Re: My Summer of Code Project
Date: Wed, 25 Apr 2007 18:08:08 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

"Alex Roman" <address@hidden> writes:


> 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 :(

np, you seem to have fixed it :-)


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

Perhaps the O'Reilly books about the Linux kernel internals.  Other
than that, I doubt that there are many interesting books...  But who
knows. :-)


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

Yeah, for example grub_be_to_cpu32 to convert a 32 bits BE integer to
the host format.  You can find all macros in include/grub/types.h.

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

Right, but it is only used on the PC AFAIK.  For example, Open
Firmware (the "BIOS" on the PPC Macs) have ISO 9660 support and can
read kernels and bootloaders directly from the filesystem.

>> > 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 GRUB 2 you will need to install ruby as well.  What I actually
meant with a good development environment is setting up qemu or so.
Or when you want to test things on real hardware you can better use
networking instead of messing around with floppies.  Doing things
right from the start can save you time :-).

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

Have a look at grub_dprintf.  It prints debug messages depending on a
variable.  For example, use "set debug=all" on the GRUB prompt.  I
think it is easier for you to start playing with grub-emu to
understand how things in general work.  Although it will be useless to
you when you start working on your project.


reply via email to

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