[coreboot] GSoC project(SCSI boot)__status report

[独败]

2008/6/18 Kevin O'Connor <kevin at koconnor.net>:
> Currently all of the 16bit and 32bit code fits in the 64K segment at
> 0xf0000.  Just load the elf into that area and jump to it.
>
>> Is there a way to produce a "bios.bin" image that can be copied to
>> 0xe0000 or 0xf0000 and still has all the coreboot stuff in it?
>
> The elf file (bios.bin.elf) is just a wrapper around a 64K blob
> (bios.bin) with a specified entry point.  So, if one wants the blob
> and not the elf then the file bios.bin can be used.
>

"bios.bin" is also produced after building of LegacyBIOS?
So we can just copy the "bios.bin" to 0xf0000?
and then how can we call the post() function?


>> > Is there a particular reason you'd want to return to coreboot?
> [...]
>> The current option rom handling in post() may not be sufficient to
>> initialize all option roms in a system, as the current coreboot v3 code
>> is able to load an option rom for a given device from the "lar" archive,
>> copy it to the option rom area and execute it from there. This way we
>> can easily support an arbitrary number of onboard devices with option
>> roms.
>
> So, why not have coreboot load all the option roms from the lar into
> ram and then launch LegacyBIOS?

This is another choise?



>>But when jumping into LegacyBIOS, not all option roms may be
>> visible in the address space at the same time.
>
> This is surprising.  If all the option roms don't fit, how would a
> normal BIOS boot the system?  If one were to swap out an option rom,
> how could one be sure the option rom didn't "hook" a 16bit int
> handler?
>
>> I guess what I am suggesting is to split the bootmenu + OS loader
>> (int19) part from the init part.
>
> I have no issue with doing this - it's trivial to implement multiple
> entry points.  One need only implement a "__start2" type function that
> called a subset of the init code.
>
> I do think it is conceptually simpler if coreboot did its thing and
> then launched LegacyBIOS as a payload.  Then LegacyBIOS could do its
> thing and then launch the OS.
>
>> This way we can still provide the option rom initialization via
>> LegacyBIOS' intXX callbacks but do not force the user to also use its
>> int19 boot code, but can instead jump into another payload - for example
>> UEFI or GRUB2 in flash.
>
> I think it would be cool to teach LegacyBIOS how to read the lar.
> That way one could boot floppy, cdrom, hard drive, or lar payload.
> Something like LegacyBIOS+Bayou.
>
> I'm not tied to anything though - whatever works.
>

There is two method:
1. use LegacyBIOS code in coreboot.
2. coreboot --> LegacyBIOS --> other payload(OS or "bootloader")

Which one to choose?
question:
1. use LegacyBIOS code in coreboot.
we should figure out how to use LegacyBIOS code within coreboot.

2. coreboot --> LegacyBIOS --> other payload(OS or "bootloader")
we should find a way to pass more information from coreboot to
LegacyBIOS, such as the option rom in lar.
Will the adding one more layer between coreboot and other payload cost
more time in the booting process?
Or maybe the it cost almost equally that one more layer and the
copying of code in LegacyBIOS to 0xf0000?

I think both way will work in the end and both need time to solve some problem.
So we should have a decision as early as possible and give more time
to the thinking of how to solve the problem of the decision.

Any more suggestions?


Zhang Rui