Re: [coreboot] CarPC project, with MB899 MB

[Corey Osgood]

On Wed, Oct 13, 2010 at 6:15 PM, Nasa  wrote:
> ----- "Peter Stuge"  wrote:
> > Nasa wrote:
> > > All that said, I was hoping to get pointed in the right direction
> > > to being able to install this in my motherboard. The specifics of
> > > the board (in case I misread the post) are(from manual):
> > >
> > > IBASE MB899
> > > Intel 945GM Chipset
> > > GMCH: 82945GM 1466-pin Micro-FCBGA
> > > ICH7M:82801GBM 652-pin MBGA.
> >
> > Did you pick a particular CPU for the board, or did the CPU come
> > already installed when you bought the board?
> >
> > In general you're in luck because as was noted the board is supported
> > by coreboot.
> >
> > You will need a few things:
> > Cross-over serial cable (AKA null modem)
> > Spare boot flash chips
> > Patience
> >
> > You have to choose a payload for your coreboot build. coreboot does
> > hardware init but does not include any code to boot your operating
> > system. That second part is handled by a completely separate program,
> > which is stored together with coreboot in the boot flash.
> >
> > An easy first step might be to use SeaBIOS as payload. SeaBIOS is an
> > open source legacy BIOS implementation, so your system should start
> > just like before. Once everything is running well with
> > coreboot+SeaBIOS you could move on and try to optimize the boot even
> > further, using other payloads.
> > > While I am very capable of building software out of SVN (been doing
> > > that for mythtv, openmobile, etc) and linux kernel,
> >
> > Good. Note that coreboot and SeaBIOS both run before an operating
> > system environment is available, and the toolchains shipped with many
> > distributions have been patched so that they fail to correctly build
> > such software. You can try using your regular toolchain, but if you
> > have any trouble then it is recommended to build a reference
> > toolchain and use that to build coreboot. After svn checkout of the
> > coreboot tree, do:
> >
> > cd util/crossgcc
> > ./buildgcc
> > cd ../..
> > rm -f .xcompile
> >
> > The next time you run make in the coreboot directory it should pick
> > up the toolchain built by buildgcc automatically. Check the contents
> > of .xcompile to make sure.
> > > I have not played with pulling individual chips, like a BIOS.  So I
> > > don't know anything about acquiring and/or replacing one.
> >
> > Note that BIOS is the software, not so much the flash chip it is
> > stored in.
> >
> > You will need replacement flash chips. They shouldn't cost more than
> > a few USD and I recommend getting a few of them, so that you always
> > have at least one backup of the factory BIOS that you can use if
> > coreboot doesn't work straight away. (Sometimes it will, but better
> > safe than sorry, if there's a problem you can't start the system
> > anymore without a backup flash chip.)
> >
> > Warren Turkal wrote:
> > > the bios chip might be the SST thing near the white connector in
> > > the bottom left quadrant of the board.
> >
> > Yes, that's correct. This package is called PLCC32, but only
> > describes the physical format of the chip.
> > > I think it's an LPC style chip.
> >
> > Well, almost. It is connected to a bus which is electrically and
> > protocol-wise compatible with LPC, but all Intel chipsets use their
> > own memory read and write commands which are different from the LPC
> > standard commands. The flash chip type is usually called FWH,
> > Firmware Hub, since that is the name of Intel's own boot flash chips.
> >
> > Look for a couple of compatible flash chips. Some current part
> > numbers are:
> >
> > 8Mbit = 1Mbyte
> > SST49LF008A-33-4C-NHE
> > http://parts.digikey.com/1/parts/1904170-ic-flash-fwh-8mbit-33mhz-32plcc-sst...
> >
> > 16Mbit = 2Mbyte
> > SST49LF016C-33-4C-NHE
> > SST49LF016C-66-4C-NHE
> > http://parts.digikey.com/1/parts/1904173-ic-flash-ser-lpc-16mbit-32plcc-sst4...
> >
> > You can most likely use flashrom (flashrom.org, coreboot sibling
> > project) to read the factory BIOS from the chip in a running system.
> > You can then hotswap flash chips (prepare them with pushpin knobs
> > first) in the running system, put a blank chip in, and write your
> > first factory BIOS backup onto that. Then get the third flash chip,
> > repeat the hotswap, and write a coreboot image with SeaBIOS onto
> > that chip. Reboot and watch the seral port output on another
> > computer, via the null modem cable.
> >
> > //Peter
>
> Wow,
>
> Thanks a lot Peter -- that was VERY informative.
>
> I choose the CPU (a number of years ago) which is an Intel Core 2 Duo Mobile 1.66GHz.
>
> I have read a little about payloads and noted that SeaBIOS would be the easiest way to go...
> However (this being important for the flash chip), I didn't see anything about the benefits of
> putting a linux kernel as a payload.  I did read from the FAQ that most chips aren't large
> enough to have the kernel added as a payload.  If my goal is the fastest boot time possible, while
> still supporting the basic system, would going to a Linux payload be the way to go?  If so, what
> size flash chip should I get?

Most likely, you won't be able to find a flash chip large enough to
support a full-fledged linux kernel for a payload. It's been done
(like here: http://youtu.be/nuzRsXKm_NQ ), and would probably be the
fastest way to go, but you would have to give up a lot of kernel
features in order to get the kernel down to small enough of a size. If
you're going with a linux payload though, I'd look at FILO rather then
SeaBIOS, just because you don't need the legacy BIOS features that
SeaBIOS implements.

-Corey

CarPC project, with MB899 MB

[Kevin O'Connor]

On Wed, Oct 13, 2010 at 06:43:21PM -0400, Corey Osgood wrote:
> On Wed, Oct 13, 2010 at 6:15 PM, Nasa  wrote:
> > I have read a little about payloads and noted that SeaBIOS would
> > be the easiest way to go...  However (this being important for the
> > flash chip), I didn't see anything about the benefits of putting a
> > linux kernel as a payload.  I did read from the FAQ that most
> > chips aren't large enough to have the kernel added as a
> > payload.  If my goal is the fastest boot time possible, while
> > still supporting the basic system, would going to a Linux payload
> > be the way to go?  If so, what size flash chip should I get?
>
> Most likely, you won't be able to find a flash chip large enough to
> support a full-fledged linux kernel for a payload. It's been done
> (like here: http://youtu.be/nuzRsXKm_NQ ), and would probably be the
> fastest way to go, but you would have to give up a lot of kernel
> features in order to get the kernel down to small enough of a size. If
> you're going with a linux payload though, I'd look at FILO rather then
> SeaBIOS, just because you don't need the legacy BIOS features that
> SeaBIOS implements.

SeaBIOS boots much faster than filo.  The time to initialize the
legacy BIOS interface is on the order of microseconds so it doesn't
have any real impact on boot time.  On the other hand, SeaBIOS has
several optimizations that filo lacks (eg, parallel hardware init, ATA
DMA, EHCI USB).

In my tests, the fastest way I could boot my machine was to use
SeaBIOS and launch linux from an SSD.  The SSD I tried (OCZ) had no
detectable "spin up" delay, and could transfer over 100MB per second.
The built-in flash, on the other hand, could only read at 1MB per
second.  (So, for a 2MB linux flash image there could be a 2s load
delay - compare to 50K seabios flash image and 2MB Linux SSD image at
~100ms load delay.)

There is a tool in the SeaBIOS repo (tools/readserial.py) that can
generate timings from normal serial debug output.  It can be used with
SeaBIOS, Linux, and FILO.  I encourage anyone interested in boot times
to run tests and compare the results.

-Kevin

CarPC project, with MB899 MB

[Scott Duplichan]

]From: Kevin O'Connor 
]On Wed, Oct 13, 2010 at 06:43:21PM -0400, Corey Osgood wrote:
]> On Wed, Oct 13, 2010 at 6:15 PM, Nasa  wrote:
]> > I have read a little about payloads and noted that SeaBIOS would
]> > be the easiest way to go...  However (this being important for the
]> > flash chip), I didn't see anything about the benefits of putting a
]> > linux kernel as a payload.  I did read from the FAQ that most
]> > chips aren't large enough to have the kernel added as a
]> > payload.  If my goal is the fastest boot time possible, while
]> > still supporting the basic system, would going to a Linux payload
]> > be the way to go?  If so, what size flash chip should I get?
]> 
]> Most likely, you won't be able to find a flash chip large enough to
]> support a full-fledged linux kernel for a payload. It's been done
]> (like here: http://youtu.be/nuzRsXKm_NQ ), and would probably be the
]> fastest way to go, but you would have to give up a lot of kernel
]> features in order to get the kernel down to small enough of a size. If
]> you're going with a linux payload though, I'd look at FILO rather then
]> SeaBIOS, just because you don't need the legacy BIOS features that
]> SeaBIOS implements.
]
]SeaBIOS boots much faster than filo.  The time to initialize the
]legacy BIOS interface is on the order of microseconds so it doesn't
]have any real impact on boot time.  On the other hand, SeaBIOS has
]several optimizations that filo lacks (eg, parallel hardware init, ATA
]DMA, EHCI USB).
]
]In my tests, the fastest way I could boot my machine was to use
]SeaBIOS and launch linux from an SSD.  The SSD I tried (OCZ) had no
]detectable "spin up" delay, and could transfer over 100MB per second.
]The built-in flash, on the other hand, could only read at 1MB per
]second.  (So, for a 2MB linux flash image there could be a 2s load
]delay - compare to 50K seabios flash image and 2MB Linux SSD image at
]~100ms load delay.)
]
]There is a tool in the SeaBIOS repo (tools/readserial.py) that can
]generate timings from normal serial debug output.  It can be used with
]SeaBIOS, Linux, and FILO.  I encourage anyone interested in boot times
]to run tests and compare the results.
]
]-Kevin

I have worked on boot time reduction in the past, and have collected
timings for AC power off to a DOS prompt. This measurement can be
automated by reading the acpi pmtimer from a DOS autoexec utility.
The BIOS I used for one project is a stripped down AMI legacy BIOS.
The BIOS is stripped of unneeded features, yet still complete enough
to boot Win7. With USB turned off, a 5400 rpm 2.5 inch sata drive,
and a hacked vbios, the power on to DOS boot time runs around 800 ms.
USB adds as much as a couple hundred ms as I remember. An Intel x25-e
SSD drive removes 200 ms. The fastest booting system from tier 1 
commercial notebook vendor is significantly below 3 seconds. This
one uses UEFI BIOS. A well tuned Insyde UEFI BIOS boots in around 3.5
seconds. Apple's UEFI is probably among the fastest, though I have
never tested one.

For coreboot+seabios, I get a power on to DOS boot time of around 2.7
seconds. This is with USB enabled and a 5400 rpm sata drive. While 2.7
seconds is good, there is probably room for improvement. I would like
to see a bigger coreboot advantage over UEFI. All of these numbers are
for AMD hardware with family 10h processors.

You are right about bios flash chip performance. While it is improving,
it is a bottleneck and reads from the bios flash chip should be avoided.
As I remember from tests I did, the slowest is an EC ckip that reads a
parallel flash and then emulates an LPC flash. This could be read at
about 700 KB/s. A directly connected LPC flash chip reads at about
1.4 MB/s. Current generation AMD systems can read from SPI flash at about
3 MB/s. Future generations will be faster, though no match for a hard drive.

Thanks,
Scott

coreboot+seabios timings

[Kevin O'Connor]

On Sun, Oct 17, 2010 at 04:36:56PM -0500, Scott Duplichan wrote:
> For coreboot+seabios, I get a power on to DOS boot time of around 2.7
> seconds. This is with USB enabled and a 5400 rpm sata drive. While 2.7
> seconds is good, there is probably room for improvement. I would like
> to see a bigger coreboot advantage over UEFI. All of these numbers are
> for AMD hardware with family 10h processors.

Thanks.  Can you post the debug output using SeaBIOS'
tools/readserial.py program?  I'd be curious to see where the time is
spent.

Also, try the SeaBIOS options CONFIG_THREAD_OPTIONROMS and
CONFIG_ATA_DMA.  (The ATA DMA can be a little finicky though - fixing
it is on my todo list.)

-Kevin

coreboot+seabios timings

[Scott Duplichan]

]> For coreboot+seabios, I get a power on to DOS boot time of around 2.7
]> seconds. This is with USB enabled and a 5400 rpm sata drive. While 2.7
]> seconds is good, there is probably room for improvement. I would like
]> to see a bigger coreboot advantage over UEFI. All of these numbers are
]> for AMD hardware with family 10h processors.
]
]Thanks.  Can you post the debug output using SeaBIOS'
]tools/readserial.py program?  I'd be curious to see where the time is
]spent.
]
]Also, try the SeaBIOS options CONFIG_THREAD_OPTIONROMS and
]CONFIG_ATA_DMA.  (The ATA DMA can be a little finicky though - fixing
]it is on my todo list.)
]
]-Kevin

Hello Kevin,

I am not sure how to get that script to run from windows. I get:

$ python ../seabios-for-coreboot/tools/readserial.py com1 115200
Traceback (most recent call last):
  File "../seabios-for-coreboot/tools/readserial.py", line 129, in <module>
    main()
  File "../seabios-for-coreboot/tools/readserial.py", line 114, in main
    import serial
ImportError: No module named serial

But it hardly matters. I think coreboot is taking most of the time. For
example, I noticed a hesitation at:
     "copying VGA ROM Image from %p to 0x%x, 0x%x bytes\n"
Though the video option rom is tiny, it is in flash memory. Worse yet,
the variable mtrr range for caching the flash chip had already been
removed. I added that back and added an additional improvement: set
PrefetchEnSPIFromHost in the SB700. Without this setting, the SB700
reads dwords from flash memory. With this setting, the SB7000 reads 
entire cache lines.

With these two changes, boot time is reduced by 650 ms. Now the boot
time is around 2.050 seconds. That is from power switch off (standby
power on) to DOS prompt.

I will submit a patch for PrefetchEnSPIFromHost because it is safe
and easy. LPC systems are not affected, only SPI.

The MTRR change is more difficult, because it is probably best to
remove the flash memory mtrr before exiting coreboot+seabios. It
might cause trouble for flash software. With SPI, caching the flash
chip for the option rom copy is not that important, because the
PrefetchEnSPIFromHost change causes the SB700 to read full cache
lines anyway. But it might be more important systems using LPC flash.

By the way, I tried your other suggestions and did not see much
of a difference. I do need to get an SSD drive because the
randomness in the rotating drive makes precise measurements
difficult. The DMA hardly matters for DOS where only a few KB
are read from disk. But it could be very important for OS booting,
where as much as hundreds of MB are read from disk using BIOS calls.

Thanks,
Scott

coreboot+seabios timings

[Kevin O'Connor]

On Sun, Oct 17, 2010 at 08:23:57PM -0500, Scott Duplichan wrote:
> ]> For coreboot+seabios, I get a power on to DOS boot time of around 2.7
> ]> seconds. This is with USB enabled and a 5400 rpm sata drive. While 2.7
> ]> seconds is good, there is probably room for improvement. I would like
> ]> to see a bigger coreboot advantage over UEFI. All of these numbers are
> ]> for AMD hardware with family 10h processors.
> ]
> ]Thanks.  Can you post the debug output using SeaBIOS'
> ]tools/readserial.py program?  I'd be curious to see where the time is
> ]spent.
> ]
> ]Also, try the SeaBIOS options CONFIG_THREAD_OPTIONROMS and
> ]CONFIG_ATA_DMA.  (The ATA DMA can be a little finicky though - fixing
> ]it is on my todo list.)
>
> I am not sure how to get that script to run from windows. I get:
>
> $ python ../seabios-for-coreboot/tools/readserial.py com1 115200
> Traceback (most recent call last):
>   File "../seabios-for-coreboot/tools/readserial.py", line 129, in <module>
>     main()
>   File "../seabios-for-coreboot/tools/readserial.py", line 114, in main
>     import serial
> ImportError: No module named serial

Thanks for the report.  You need the pyserial package - see:
http://pyserial.sourceforge.net/

I've updated the script to make this more descriptive.
> But it hardly matters. I think coreboot is taking most of the time. For
> example, I noticed a hesitation at:
>      "copying VGA ROM Image from %p to 0x%x, 0x%x bytes\n"

It's best to let SeaBIOS run the rom - try setting CONFIG_VGA_ROM_RUN
and CONFIG_PCI_ROM_RUN to off in coreboot.  Also, set
CONFIG_DRIVERS_PS2_KEYBOARD off as well.

[...]
> With these two changes, boot time is reduced by 650 ms. Now the boot
> time is around 2.050 seconds. That is from power switch off (standby
> power on) to DOS prompt.

[...]
> By the way, I tried your other suggestions and did not see much
> of a difference. I do need to get an SSD drive because the
> randomness in the rotating drive makes precise measurements
> difficult. The DMA hardly matters for DOS where only a few KB
> are read from disk. But it could be very important for OS booting,
> where as much as hundreds of MB are read from disk using BIOS calls.

Yeah - I found the SSD to be a big win on boot times - simply because
it eliminated the spin-up delay.  I also tried USB drives and a
compact flash card with an ATA/SATA adapter, but all three exhibited
"spin-up" delays.

-Kevin

coreboot+seabios timings

[Scott Duplichan]

]> ]> For coreboot+seabios, I get a power on to DOS boot time of around 2.7
]> ]> seconds. This is with USB enabled and a 5400 rpm sata drive. While 2.7
]> ]> seconds is good, there is probably room for improvement. I would like
]> ]> to see a bigger coreboot advantage over UEFI. All of these numbers are
]> ]> for AMD hardware with family 10h processors.
]> ]
]> ]Thanks.  Can you post the debug output using SeaBIOS'
]> ]tools/readserial.py program?  I'd be curious to see where the time is
]> ]spent.
]> ]
]> ]Also, try the SeaBIOS options CONFIG_THREAD_OPTIONROMS and
]> ]CONFIG_ATA_DMA.  (The ATA DMA can be a little finicky though - fixing
]> ]it is on my todo list.)
]> 
]> I am not sure how to get that script to run from windows. I get:
]> 
]> $ python ../seabios-for-coreboot/tools/readserial.py com1 115200
]> Traceback (most recent call last):
]>   File "../seabios-for-coreboot/tools/readserial.py", line 129, in <module>
]>     main()
]>   File "../seabios-for-coreboot/tools/readserial.py", line 114, in main
]>     import serial
]> ImportError: No module named serial
]
]Thanks for the report.  You need the pyserial package - see:
]http://pyserial.sourceforge.net/
]
]I've updated the script to make this more descriptive.
]
]> But it hardly matters. I think coreboot is taking most of the time. For
]> example, I noticed a hesitation at:
]>      "copying VGA ROM Image from %p to 0x%x, 0x%x bytes\n"
]
]It's best to let SeaBIOS run the rom - try setting CONFIG_VGA_ROM_RUN
]and CONFIG_PCI_ROM_RUN to off in coreboot.  Also, set
]CONFIG_DRIVERS_PS2_KEYBOARD off as well.
]
][...]
]> With these two changes, boot time is reduced by 650 ms. Now the boot
]> time is around 2.050 seconds. That is from power switch off (standby
]> power on) to DOS prompt.
][...]
]> By the way, I tried your other suggestions and did not see much
]> of a difference. I do need to get an SSD drive because the
]> randomness in the rotating drive makes precise measurements
]> difficult. The DMA hardly matters for DOS where only a few KB
]> are read from disk. But it could be very important for OS booting,
]> where as much as hundreds of MB are read from disk using BIOS calls.
]
]Yeah - I found the SSD to be a big win on boot times - simply because
]it eliminated the spin-up delay.  I also tried USB drives and a
]compact flash card with an ATA/SATA adapter, but all three exhibited
]"spin-up" delays.
]
]-Kevin

Hello Kevin,

Thanks. I had already noticed the double KB init and turned off the
coreboot instance. I switched to seabios execution of video option 
roms and found an immediate improvement. Before, I had a problem adding
a PCI video card. It seems like coreboot would execute the uma option
rom instead of the PCI option rom. After changing to seabios execution 
of option roms, it now works correctly. I can boot either uma video or
pci video without changing my image. I probably need to get an SSD drive
at this point. I found with the drive already spinning, boot time is 
around 1.70 seconds. However I remembered a 40 ms delay inside the PCIe
training loop. I had removed it to speed up simnow execution. With the
delay restored, boot time goes up by 270 ms or so. That delay needs some
optimization. I see it is called even for non-existent PCIe devices.

Thanks,
Scott

coreboot+seabios timings

[Stefan Reinauer]

On 10/17/10 7:54 PM, Scott Duplichan wrote:
> Hello Kevin,
>
> Thanks. I had already noticed the double KB init and turned off the
> coreboot instance.

Should we add a "use SeaBIOS as payload" option that disables all that
stuff automatically?
> I switched to seabios execution of video option 
> roms and found an immediate improvement. Before, I had a problem adding
> a PCI video card. It seems like coreboot would execute the uma option
> rom instead of the PCI option rom. After changing to seabios execution 
> of option roms, it now works correctly. I can boot either uma video or
> pci video without changing my image. I probably need to get an SSD drive
> at this point. I found with the drive already spinning, boot time is 
> around 1.70 seconds. However I remembered a 40 ms delay inside the PCIe
> training loop. I had removed it to speed up simnow execution. With the
> delay restored, boot time goes up by 270 ms or so. That delay needs some
> optimization. I see it is called even for non-existent PCIe devices.

Do we need to think about cooperative multitasking?

Stefan

coreboot+seabios timings

[Carl-Daniel Hailfinger]

On 18.10.2010 05:46, Stefan Reinauer wrote:
> On 10/17/10 7:54 PM, Scott Duplichan wrote:
> > Thanks. I had already noticed the double KB init and turned off the
> > coreboot instance.
>
> Should we add a "use SeaBIOS as payload" option that disables all that
> stuff automatically?

Given that the issue crops up very often, I think this would be a major
usability improvement. I'd even go as far as defaulting it to yes.
> > I switched to seabios execution of video option 
> > roms and found an immediate improvement. Before, I had a problem adding
> > a PCI video card. It seems like coreboot would execute the uma option
> > rom instead of the PCI option rom. After changing to seabios execution 
> > of option roms, it now works correctly. I can boot either uma video or
> > pci video without changing my image. I probably need to get an SSD drive
> > at this point. I found with the drive already spinning, boot time is 
> > around 1.70 seconds. However I remembered a 40 ms delay inside the PCIe
> > training loop. I had removed it to speed up simnow execution. With the
> > delay restored, boot time goes up by 270 ms or so. That delay needs some
> > optimization. I see it is called even for non-existent PCIe devices.
>
> Do we need to think about cooperative multitasking?

It would help a lot with SATA link init. That is the biggest time waster
(few seconds) on my RS690/SB600 box because apparently my HDD only
completes link init after spinup. Kicking it early and polling for it
very late would allow coreboot to do something useful in between.

Being able to register a callback which is called directly before
payload execution would be the simplest way to do this.

Regards,
Carl-Daniel

coreboot+seabios timings

[Stefan Reinauer]

On 10/17/10 8:56 PM, Carl-Daniel Hailfinger wrote:
> It would help a lot with SATA link init. That is the biggest time waster
> (few seconds) on my RS690/SB600 box because apparently my HDD only
> completes link init after spinup. Kicking it early and polling for it
> very late would allow coreboot to do something useful in between.

We generally do a lot of waiting.. keyboard controller, azalia, cpu
init, and others too. Try searching the code for mdelay and udelay.
> Being able to register a callback which is called directly before
> payload execution would be the simplest way to do this.

what function would one register there?

coreboot+seabios timings

[Peter Stuge]

Stefan Reinauer wrote:
> Should we add a "use SeaBIOS as payload" option that disables all
> that stuff automatically?

It's a good idea, it would go in under the payload menu, and we could
then add an option for which dir to grab the payload from. We could
also do some checks on the payload file and in the long run why not
also build it automatically.

//Peter

coreboot+seabios timings

[Warren Turkal]

On Sunday, October 17, 2010 08:46:28 pm Stefan Reinauer wrote:
> On 10/17/10 7:54 PM, Scott Duplichan wrote:
> > Hello Kevin,
> >
> > Thanks. I had already noticed the double KB init and turned off the
> > coreboot instance.
>
> Should we add a "use SeaBIOS as payload" option that disables all that
> stuff automatically?

Why wouldn't SeaBIOS turn that KB init off if it's a coreboot payload since 
coreboot is technically responsible for initializing hardware. Also, other 
payloads may need the keyboard, so it kinda makes sense to me to isolate that 
logic into coreboot.

wt

coreboot+seabios timings

[ron minnich]

On Sun, Oct 17, 2010 at 10:13 PM, Warren Turkal  wrote:
> On Sunday, October 17, 2010 08:46:28 pm Stefan Reinauer wrote:
> > Should we add a "use SeaBIOS as payload" option that disables all that
> > stuff automatically?
>
> Why wouldn't SeaBIOS turn that KB init off if it's a coreboot payload since
> coreboot is technically responsible for initializing hardware. Also, other
> payloads may need the keyboard, so it kinda makes sense to me to isolate that
> logic into coreboot.

to add to this, is there ever a case where seabios might be one of
several payloads in flash?

So it might be "seabios is the ONLY Payload" option.

ron

coreboot+seabios timings

[Kevin O'Connor]

On Sun, Oct 17, 2010 at 10:38:45PM -0700, ron minnich wrote:
> On Sun, Oct 17, 2010 at 10:13 PM, Warren Turkal  wrote:
> > On Sunday, October 17, 2010 08:46:28 pm Stefan Reinauer wrote:
> > > Should we add a "use SeaBIOS as payload" option that disables all that
> > > stuff automatically?
> >
> > Why wouldn't SeaBIOS turn that KB init off if it's a coreboot payload since
> > coreboot is technically responsible for initializing hardware. Also, other
> > payloads may need the keyboard, so it kinda makes sense to me to isolate that
> > logic into coreboot.
>
> to add to this, is there ever a case where seabios might be one of
> several payloads in flash?
>
> So it might be "seabios is the ONLY Payload" option.

Linux also initializes the keyboard on its own.  I'd guess most OSes
do - it's the only way to ensure the keyboard is in a sane state when
the OS starts.  The KB init should really go into libpayload and be
removed from coreboot.

-Kevin

coreboot+seabios timings

[Peter Stuge]

Warren Turkal wrote:
> Why wouldn't SeaBIOS turn that KB init off if it's a coreboot
> payload

The only valid reason is that SeaBIOS can do a bit of multitasking,
while coreboot currently can not. It may also be the case that even
if coreboot were to gain multitasking, there would still be no other
long-running tasks within coreboot besides that keyboard init, or
that in any case the total cost of not having all long-running tasks
in one code base only would be too high.

I see two solutions:

1. move all long-running tasks from SeaBIOS into coreboot
I'm not sure if this fits our model of what coreboot should do.
E.g. option ROM init is clearly in the SeaBIOS domain.

2. remove checkpoint between coreboot and payload
Also big change in our model, but maybe the way ahead! A payload
would be ultimately responsible for the system to be initialized
correctly.

//Peter

coreboot+seabios timings

[Warren Turkal]

On Sun, Oct 17, 2010 at 10:51 PM, Peter Stuge  wrote:
> move all long-running tasks from SeaBIOS into coreboot
>
> I'm not sure if this fits our model of what coreboot should do.
> E.g. option ROM init is clearly in the SeaBIOS domain.

We could flip it around a merge coreboot functionality into SeaBIOS.

wt

coreboot+seabios timings

[Peter Stuge]

Warren Turkal wrote:
> On Sun, Oct 17, 2010 at 10:51 PM, Peter Stuge  wrote:
> > move all long-running tasks from SeaBIOS into coreboot
> >
> > I'm not sure if this fits our model of what coreboot should do.
> > E.g. option ROM init is clearly in the SeaBIOS domain.
>
> We could flip it around a merge coreboot functionality into SeaBIOS.

I don't consider that an option. It's what QEMU is doing and I think
that it is a mistake.

//Peter