Am 10.03.2012 11:49, schrieb Jaspal Dhillon:

I was going through the coreboot.org and I am definitely interested in it.

Welcome to coreboot, then!

So wanted to ask couple of things.
I have not read the source code yet but tried it out in this way :
1.Checked out latest version of coreboot on 32bit Fedora 15. make config with settings as :
MainBoard Vendor : Emulation , Model : Qemu , ROM Size : 256KB , Payload : SeaBIOS
make was successful .

Since my laptop is a old one and does not have hardware virtualization support , I use a lab pc ( 64 bit Fedora 15 ) for some of my experiments.

qemu requires no hardware virtualization extensions (only kvm does, which is an extended version), and for basic tests it's usually fast enough.

Installation of CentOS ( Minimum installation ) was successful and at the end , it asked me to reboot. When I clicked on reboot option , coreboot got stuck in an infinite loop and I was getting this (in a loop) on the stdio :

Changing serial settings was 0/0 now 3/0
In resume (status=0)
In 32bit resume
Attempting a hard reboot

These are seabios messages, so its reboot handler doesn't seem to work correctly. Unfortunately, there are ~6 different ways of rebooting an x86 machine (not all of which are available on any given system), so it's possible that CentOS triggered the "wrong" one in seabios, which in turn tries to use a method not supported by qemu (or something like that).

Could you give me some pointers as to where to begin for GSoC or some little hacks that I should attempt out ? I am trying different payloads in the meantime.

Different payloads is a good start. Ultimately, there so much you could do, that it's better if you specify what area you're most interested in.

I read about mkelfImage command and also tried it out but the resultant size of linux.elf is ~5MB which exceeds the size of ROM chip , declared in Qemu. Can I use a kernel payload ( any other ) without hacking Qemu ? ( I think not but want to know , if yes , how ) .

Only by reducing the kernel size - kernel images are usually already compressed, so there's not much we can do.
Fortunately, when putting the kernel in flash, you usually know rather well what kind of hardware you're running it on - so you can reduce kernel/initrd to just the drivers required to access the disk, and go from there.

I think current qemu versions are more tolerant with flash sizes - you probably can't go above 4MB, but that should be enough to contain an optimized kernel.

Regards,
Patrick