[gentoo-embedded] boot linux without a bios on intel platform

[gentoo-embedded] boot linux without a bios on intel platform

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 195 bytes --]

Hi,
I'm facing a problem.
I have an intel board, and the bios boots after 22sec.
Is it possible to boot the linux without a bios.
Maybe have grub jump from an eeprom or something.

Regards,
Kfir

[-- Attachment #2: Type: text/html, Size: 249 bytes --]

Re: [gentoo-embedded] boot linux without a bios on intel platform

[Manuel Lauss]

On Thu, Dec 23, 2010 at 9:25 AM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
> Hi,
> I'm facing a problem.
> I have an intel board, and the bios boots after 22sec.
> Is it possible to boot the linux without a bios.
> Maybe have grub jump from an eeprom or something.

Is coreboot an option for your system?

Manuel

Re: [gentoo-embedded] boot linux without a bios on intel platform

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Thu, Dec 23, 2010 at 11:20 AM, Manuel Lauss
<manuel.lauss@googlemail.com>wrote:

> On Thu, Dec 23, 2010 at 9:25 AM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
> > Hi,
> > I'm facing a problem.
> > I have an intel board, and the bios boots after 22sec.
> > Is it possible to boot the linux without a bios.
> > Maybe have grub jump from an eeprom or something.
>
> Is coreboot an option for your system?
>
> Manuel
>
> There is a support for a kontron board, but my guess is that I would need
to integrate a new support.
This is something I don't want to do if it's hard and will take time.
I have also an option to ask for lean bios. I think they are able to reduce
bios code.
What I'm still not sure is if just the dram and the ide/sata is enough for
linux.

Regards,
Kfir

[-- Attachment #2: Type: text/html, Size: 1270 bytes --]

Re: [gentoo-embedded] boot linux without a bios on intel platform

[Peter Stuge]

Kfir Lavi wrote:
> What I'm still not sure is if just the dram and the ide/sata is
> enough for linux.

It is nowhere near enough. Firmware must also initialize and
enumerate all system busses, which usually means the CPU-chipset
interconnect, and PCI. And if you want video you must run the binary
blob that is the VGA BIOS.


//Peter

[gentoo-embedded] Re: boot linux without a bios on intel platform

[Kfir Lavi]

[-- Attachment #1.1: Type: text/plain, Size: 510 bytes --]

On Thu, Dec 23, 2010 at 10:25 AM, Kfir Lavi <lavi.kfir@gmail.com> wrote:

> Hi,
> I'm facing a problem.
> I have an intel board, and the bios boots after 22sec.
> Is it possible to boot the linux without a bios.
> Maybe have grub jump from an eeprom or something.
>
> Regards,
> Kfir
>

I have spoke in irc #gentoo-embedded with landley and he explained some
stuff about my question regarding coreboot, uboot on x86.
I have attached the log, because I think its very valuable what landley
said.

Regards,
Kfir

[-- Attachment #1.2: Type: text/html, Size: 851 bytes --]

[-- Attachment #2: coreboot.uboot.and.x86 --]
[-- Type: application/octet-stream, Size: 9514 bytes --]

10:47 < kipibenkipod> good morning
10:48 < landley> Morning.
10:56 < kipibenkipod> can someone refer me to a good source for: loading linux without bios
10:57 <+bonsaikitten> kipibenkipod: I am unsure what you are trying to do
10:57 <+bonsaikitten> can you explain a bit more?
10:57 < kipibenkipod> yes
10:58 < kipibenkipod> I have an intel board with AMI bios that loads for 22 seconds
10:58 < kipibenkipod> sorry, kontron board that have intel dual core chip
10:58 < kipibenkipod> As I understand linux don't need the bios
10:59 < kipibenkipod> Its just need the kernel running, and the kernel will initialize all the hardware. Am I right?
10:59 < landley> I wrote a long rant on this topic once, let me dig it up...
10:59 < kipibenkipod> landley: tnx
10:59 <+chithead> kipibenkipod: I don't think you got that right. but you can replace the bios with coreboot if your mobo is supported
11:00 < kipibenkipod> chithead: I'm now on corebood's website
11:00 < kipibenkipod> Does coreboot preform fast?
11:00 <+chithead> yes
11:01 < landley> Darn it, the rant was on the aboriginal mailing list mark destroyed when he took down the server.
11:01 < landley> Ok, there are two functions x86 bioses perform:
11:01 < kipibenkipod> listening
11:01 < landley> The first (performed by coreboot) is basically to initialize the DRAM controller.
11:01 < kipibenkipod> ok
11:01 < landley> Until that happens and the DRAM controller is clocked up, stabilized, and properly refreshing memory, nothing you write to DRAM will stay long enough to read it back.
11:02 < max_posedon> the most popular bootloader for platforms without bios - uboot - I think
11:02 < landley> It may initialize other hardware, but that's the big one you have to program very carefully to get going.
11:02 < landley> The second task is providing hardware information to the OS.
11:02 < landley> On x86 this is done by the int 13 callback (implemented by the bochs bios).  On other platforms it's done with device tree blobs.
11:03 < landley> So to get an x86 bios, you glue together coreboot and bochs bios.  QEMU needs the bochs bios but doesn't need coreboot (because the DRAM it provides doesn't need refresh, so it doesn't bother to emulate a dram controller needing initialization.  The host takes care of that).
11:04 < landley> On real hardware, you're GOING to need a coreboot equivalent.  The bochs equivalent you can ignore by statically linking a device tree into your kernel with the layout for your hardware.
11:04 < kipibenkipod> oh thats a good point 
11:05 < landley> The third part is a bootloader.  On x86 bioses it loads a single sector "boot sector" from some device and hands off control to it.  Or offers equivalent methods like PXE to load boot code from the network.
11:05 -!- Appleman1234 [~Appleman1@CPE-60-226-179-130.qld.bigpond.net.au] has quit [Ping timeout: 250 seconds]
11:06 < landley> This boot code is often something like grub, which then loads the real OS.  Or it could be like the old linux floppy boot sector that loads the kernel itself by hand.  Either way, they tend to use the bochs-level callbacks to request specific sectors from the boot device, or else contain their own device drivers to drive the hardware they're loading from.
11:06 < landley> (Or you have your kernel in flash or ROM, in which case the coreboot level took care of mapping it at some known location and you just copy or jump to it.)
11:07 < kipibenkipod> can I put the kernel in the bios flash?
11:07 < landley> kipibenkipod if there's room.  Usually there isn't.
11:07 < kipibenkipod> landley: yes, I understand 
11:07 < landley> BIOS flash tends to be around 256k and the smallest 2.6 kernel you can get is around a meg.
11:08 < kipibenkipod> but I maybe able to ask for this feature
11:08 < landley> You need "early boot" (coreboot) calling a "payload" (bochs).
11:08 < kipibenkipod> landley: You are an ACE!
11:09 < kipibenkipod> pitty I don't remember how to record on irssi
11:09 < landley> Your payload can be the linux kernel, and that's the simplest boot you're going to get, but usually you want some kind of bootloader ala grub or uboot in there because otherwise it's way too easy to brick the device and you need a jtag to get it back.
11:10 < landley> Plus if early boot doesn't work, you get ZERO diagnostic information as to why not.  (Again, a jtag hooked up to gdb can help with this.)
11:10 < kipibenkipod> So, if coreboot is not supported for my board, how hard is to add my board?
11:10 < landley> Dunno?
11:10 < landley> Keep in mind that u-boot is an integrated all-in-one solution.
11:10 < landley> All three of the stages I mentioned (dram init, hardware drivers/manifest, bootloader with shell prompt) are in the uboot source.
11:11 < landley> Your .config file for uboot is a lot like a kernel .config.  It's hideously complicated and insanely device specific.
11:11 < kipibenkipod> does uboot can handle intel platform?
11:11 < landley> In theory, yes?  In practice, I haven't tried it?
11:11 < landley> It's all open source.  I stopped paying attention U-boot when it went <strike>CDDL2</strike> GPLv3, but it's got an active community.  So does coreboot.
11:12 < landley> (Coreboot used to be called "Linuxbios", but they renamed it because you can boot freedos and stuff too.)
11:12 < landley> The hard part is understanding what the steps are.  Mixing and matching stuff to handle each step is then a lot easier, because there's multiple options for each one and you just have to get ONE of them to work.
11:12 < kipibenkipod> so eather way I need a specific support for my hardwar.
11:13 <+chithead> kipibenkipod: you can see in the coreboot compatibility list if other mobos with the same chipset are already supported. if not, then it will probably be a major effort
11:13 < landley> (Of course "easier" is a relative term... :)
11:13 < landley> Early boot is very hardware specific.  There's no way around that so far.
11:13 < landley> Kinda designed in, that.
11:15 < kipibenkipod> chithead: my guess is that most of the work have been done, because my board seems to be having all the qualities of regular pc. 
11:15 <+chithead> as landley already said, in the early initialization you will find many things which are specific to a particular piece of hardware
11:16 < kipibenkipod> landley: from all your explenation, I can request kontron to (maybe) diable all the initialization of the peripherals, and just start the dram and jump to the hard drive?
11:16 <+chithead> that is why you cannot just flash a bios from one mobo to a different model
11:16 < landley> The DRAM controller initialization is non-negotiable, and has to happen first.
11:17 < kipibenkipod> landley: it is possible that I will be able to take stuff off the AMI bios (maybe). Is this a way to go?
11:17 < landley> coreboot uses a nifty trick to do that in C rather than in assembly, they set up a TLB entry to only write back data from L1 cache to DRAM when it needs to flush the TLB, and then they zero out that cache line and set the stack pointer to point to the start of it.
11:18 < landley> Then they jump to a C function and very carefully never use any globals, or more of the stack than that cache line can hold, until the DRAM controller is up and running.  Thus they never touch DRAM from the dram init routine, they use the L1 cache for stack instead. :)
11:19 < landley> Other than the DRAM controller, you need to be able to load your kernel and jump to it.  so either it has to be in flash, or you have to initialize the boot device you're loading it from (including any PCI controllers and such between you and it).
11:20 < kipibenkipod> so if its a sata or an ide, then I need to initialize the sata/ide and then jump to it. Linux will do the rest?!
11:20 < landley> Once Linux loads, it needs to know a few more things about the system such as the memory layout table and where to find the busses it knows how to probe.
11:21 < landley> The device tree stuff is a platform-independent way to do it that's used on sparc and powerpc and stuff and being ported to arm and mips and sh4 and so on.
11:21 < kipibenkipod> and this is the tree we talked about earlyer 
11:21 < landley> But x86 has its own PC-centric way that's been grandfathered in.
11:21 < landley> Yup.
11:22 < landley> Oddly, the device tree documentation is at http://kernel.org/doc/Documentation/powerpc/booting-without-of.txt which is a CRAZY place to put it, but historical reasons...
11:22 < landley> Look for the "dtc" directry in the kernel, that's the device tree compiler.  Converts a human readable ascii representation into the binary blob format the kernel and bootloaders use.
11:22 < landley> All those *.dtc files in the kernel are examples.
11:22 < landley> No reason you _can't_ use a device tree on x86...
11:23 < landley> Talk to Grant Likely, he's the guy porting device tree support to ARM.  He gave a nice talk on it at CELF this spring.
11:24 < kipibenkipod> I have asked this question on the mailing list. I think I'll post this discussion to the thread, as it is very very valuable. Is it ok with you?
11:25 < landley> Grant has a video at http://free-electrons.com/blog/elc-2010-videos/ by the way.  Google finds PDFs and the patch series he submitted...
11:25 < landley> Go for it. :)
11:25 < landley> Don't mistake me for an expert, though. Just somebody who asks a lot of stupid questions and tries to collect answers...
11:25 < kipibenkipod> yes i'm a bot too ;-P
11:26 < kipibenkipod> don't underestimate yourself

[gentoo-embedded] Re: boot linux without a bios on intel platform

[Kfir Lavi]

[-- Attachment #1.1: Type: text/plain, Size: 662 bytes --]

On Thu, Dec 23, 2010 at 11:55 AM, Kfir Lavi <lavi.kfir@gmail.com> wrote:

>
>
> On Thu, Dec 23, 2010 at 10:25 AM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>
>> Hi,
>> I'm facing a problem.
>> I have an intel board, and the bios boots after 22sec.
>> Is it possible to boot the linux without a bios.
>> Maybe have grub jump from an eeprom or something.
>>
>> Regards,
>> Kfir
>>
>
> I have spoke in irc #gentoo-embedded with landley and he explained some
> stuff about my question regarding coreboot, uboot on x86.
> I have attached the log, because I think its very valuable what landley
> said.
>
> Regards,
> Kfir
>
Sorry, I'll attach it as a txt document

Kfir

[-- Attachment #1.2: Type: text/html, Size: 1328 bytes --]

[-- Attachment #2: 2010.12.23.coreboot.uboot.and.x86.chat.on.irc.gentoo-embedded.txt --]
[-- Type: text/plain, Size: 9514 bytes --]

10:47 < kipibenkipod> good morning
10:48 < landley> Morning.
10:56 < kipibenkipod> can someone refer me to a good source for: loading linux without bios
10:57 <+bonsaikitten> kipibenkipod: I am unsure what you are trying to do
10:57 <+bonsaikitten> can you explain a bit more?
10:57 < kipibenkipod> yes
10:58 < kipibenkipod> I have an intel board with AMI bios that loads for 22 seconds
10:58 < kipibenkipod> sorry, kontron board that have intel dual core chip
10:58 < kipibenkipod> As I understand linux don't need the bios
10:59 < kipibenkipod> Its just need the kernel running, and the kernel will initialize all the hardware. Am I right?
10:59 < landley> I wrote a long rant on this topic once, let me dig it up...
10:59 < kipibenkipod> landley: tnx
10:59 <+chithead> kipibenkipod: I don't think you got that right. but you can replace the bios with coreboot if your mobo is supported
11:00 < kipibenkipod> chithead: I'm now on corebood's website
11:00 < kipibenkipod> Does coreboot preform fast?
11:00 <+chithead> yes
11:01 < landley> Darn it, the rant was on the aboriginal mailing list mark destroyed when he took down the server.
11:01 < landley> Ok, there are two functions x86 bioses perform:
11:01 < kipibenkipod> listening
11:01 < landley> The first (performed by coreboot) is basically to initialize the DRAM controller.
11:01 < kipibenkipod> ok
11:01 < landley> Until that happens and the DRAM controller is clocked up, stabilized, and properly refreshing memory, nothing you write to DRAM will stay long enough to read it back.
11:02 < max_posedon> the most popular bootloader for platforms without bios - uboot - I think
11:02 < landley> It may initialize other hardware, but that's the big one you have to program very carefully to get going.
11:02 < landley> The second task is providing hardware information to the OS.
11:02 < landley> On x86 this is done by the int 13 callback (implemented by the bochs bios).  On other platforms it's done with device tree blobs.
11:03 < landley> So to get an x86 bios, you glue together coreboot and bochs bios.  QEMU needs the bochs bios but doesn't need coreboot (because the DRAM it provides doesn't need refresh, so it doesn't bother to emulate a dram controller needing initialization.  The host takes care of that).
11:04 < landley> On real hardware, you're GOING to need a coreboot equivalent.  The bochs equivalent you can ignore by statically linking a device tree into your kernel with the layout for your hardware.
11:04 < kipibenkipod> oh thats a good point 
11:05 < landley> The third part is a bootloader.  On x86 bioses it loads a single sector "boot sector" from some device and hands off control to it.  Or offers equivalent methods like PXE to load boot code from the network.
11:05 -!- Appleman1234 [~Appleman1@CPE-60-226-179-130.qld.bigpond.net.au] has quit [Ping timeout: 250 seconds]
11:06 < landley> This boot code is often something like grub, which then loads the real OS.  Or it could be like the old linux floppy boot sector that loads the kernel itself by hand.  Either way, they tend to use the bochs-level callbacks to request specific sectors from the boot device, or else contain their own device drivers to drive the hardware they're loading from.
11:06 < landley> (Or you have your kernel in flash or ROM, in which case the coreboot level took care of mapping it at some known location and you just copy or jump to it.)
11:07 < kipibenkipod> can I put the kernel in the bios flash?
11:07 < landley> kipibenkipod if there's room.  Usually there isn't.
11:07 < kipibenkipod> landley: yes, I understand 
11:07 < landley> BIOS flash tends to be around 256k and the smallest 2.6 kernel you can get is around a meg.
11:08 < kipibenkipod> but I maybe able to ask for this feature
11:08 < landley> You need "early boot" (coreboot) calling a "payload" (bochs).
11:08 < kipibenkipod> landley: You are an ACE!
11:09 < kipibenkipod> pitty I don't remember how to record on irssi
11:09 < landley> Your payload can be the linux kernel, and that's the simplest boot you're going to get, but usually you want some kind of bootloader ala grub or uboot in there because otherwise it's way too easy to brick the device and you need a jtag to get it back.
11:10 < landley> Plus if early boot doesn't work, you get ZERO diagnostic information as to why not.  (Again, a jtag hooked up to gdb can help with this.)
11:10 < kipibenkipod> So, if coreboot is not supported for my board, how hard is to add my board?
11:10 < landley> Dunno?
11:10 < landley> Keep in mind that u-boot is an integrated all-in-one solution.
11:10 < landley> All three of the stages I mentioned (dram init, hardware drivers/manifest, bootloader with shell prompt) are in the uboot source.
11:11 < landley> Your .config file for uboot is a lot like a kernel .config.  It's hideously complicated and insanely device specific.
11:11 < kipibenkipod> does uboot can handle intel platform?
11:11 < landley> In theory, yes?  In practice, I haven't tried it?
11:11 < landley> It's all open source.  I stopped paying attention U-boot when it went <strike>CDDL2</strike> GPLv3, but it's got an active community.  So does coreboot.
11:12 < landley> (Coreboot used to be called "Linuxbios", but they renamed it because you can boot freedos and stuff too.)
11:12 < landley> The hard part is understanding what the steps are.  Mixing and matching stuff to handle each step is then a lot easier, because there's multiple options for each one and you just have to get ONE of them to work.
11:12 < kipibenkipod> so eather way I need a specific support for my hardwar.
11:13 <+chithead> kipibenkipod: you can see in the coreboot compatibility list if other mobos with the same chipset are already supported. if not, then it will probably be a major effort
11:13 < landley> (Of course "easier" is a relative term... :)
11:13 < landley> Early boot is very hardware specific.  There's no way around that so far.
11:13 < landley> Kinda designed in, that.
11:15 < kipibenkipod> chithead: my guess is that most of the work have been done, because my board seems to be having all the qualities of regular pc. 
11:15 <+chithead> as landley already said, in the early initialization you will find many things which are specific to a particular piece of hardware
11:16 < kipibenkipod> landley: from all your explenation, I can request kontron to (maybe) diable all the initialization of the peripherals, and just start the dram and jump to the hard drive?
11:16 <+chithead> that is why you cannot just flash a bios from one mobo to a different model
11:16 < landley> The DRAM controller initialization is non-negotiable, and has to happen first.
11:17 < kipibenkipod> landley: it is possible that I will be able to take stuff off the AMI bios (maybe). Is this a way to go?
11:17 < landley> coreboot uses a nifty trick to do that in C rather than in assembly, they set up a TLB entry to only write back data from L1 cache to DRAM when it needs to flush the TLB, and then they zero out that cache line and set the stack pointer to point to the start of it.
11:18 < landley> Then they jump to a C function and very carefully never use any globals, or more of the stack than that cache line can hold, until the DRAM controller is up and running.  Thus they never touch DRAM from the dram init routine, they use the L1 cache for stack instead. :)
11:19 < landley> Other than the DRAM controller, you need to be able to load your kernel and jump to it.  so either it has to be in flash, or you have to initialize the boot device you're loading it from (including any PCI controllers and such between you and it).
11:20 < kipibenkipod> so if its a sata or an ide, then I need to initialize the sata/ide and then jump to it. Linux will do the rest?!
11:20 < landley> Once Linux loads, it needs to know a few more things about the system such as the memory layout table and where to find the busses it knows how to probe.
11:21 < landley> The device tree stuff is a platform-independent way to do it that's used on sparc and powerpc and stuff and being ported to arm and mips and sh4 and so on.
11:21 < kipibenkipod> and this is the tree we talked about earlyer 
11:21 < landley> But x86 has its own PC-centric way that's been grandfathered in.
11:21 < landley> Yup.
11:22 < landley> Oddly, the device tree documentation is at http://kernel.org/doc/Documentation/powerpc/booting-without-of.txt which is a CRAZY place to put it, but historical reasons...
11:22 < landley> Look for the "dtc" directry in the kernel, that's the device tree compiler.  Converts a human readable ascii representation into the binary blob format the kernel and bootloaders use.
11:22 < landley> All those *.dtc files in the kernel are examples.
11:22 < landley> No reason you _can't_ use a device tree on x86...
11:23 < landley> Talk to Grant Likely, he's the guy porting device tree support to ARM.  He gave a nice talk on it at CELF this spring.
11:24 < kipibenkipod> I have asked this question on the mailing list. I think I'll post this discussion to the thread, as it is very very valuable. Is it ok with you?
11:25 < landley> Grant has a video at http://free-electrons.com/blog/elc-2010-videos/ by the way.  Google finds PDFs and the patch series he submitted...
11:25 < landley> Go for it. :)
11:25 < landley> Don't mistake me for an expert, though. Just somebody who asks a lot of stupid questions and tries to collect answers...
11:25 < kipibenkipod> yes i'm a bot too ;-P
11:26 < kipibenkipod> don't underestimate yourself

Re: [gentoo-embedded] Re: boot linux without a bios on intel platform

[Peter Stuge]

Kfir Lavi wrote:
> > I have an intel board, and the bios boots after 22sec.
> > Is it possible to boot the linux without a bios.

coreboot is your only alternative to a BIOS. I'm active in the
project since some years. Instead of coreboot you could of course
also consider buying licenses for a custom BIOS from AMI but that
is often prohibitively expensive.


> I have spoke in irc #gentoo-embedded with landley and he explained
> some stuff about my question regarding coreboot, uboot on x86.

uboot is not widely used on x86 so far. There has been some talk
between coreboot and uboot because the two could complement each
other well, but not yet.

You're of course welcome to stop by #coreboot and talk to us, and/or
check out some of the talks.

http://www.coreboot.org/Screenshots#Videos

I'd recommend "Beyond The Final Frontier" from 25C3 as a start:

http://www.coreboot.org/Screenshots#Chaos_Communication_Congress_2008_.2825C3.29:_coreboot:_Beyond_The_Final_Frontier

coreboot completes it's task in a few hundred milliseconds. Some more
complicated boards (lots of busses and CPUs) take longer, maybe a
second or even two.

We have a list of supported mainboards:

http://www.coreboot.org/Supported_Motherboards

If your board is not listed it may be easy or it may be hard. When
talking to us about it please be sure to provide very specific
information about your hardware. "intel board" is e.g. useless, we
need details for CPU, chipset, superio and the boot flash.

As a general rule, NVIDIA and Intel are the worst possible targets
for coreboot, because they will not release documentation.

NVIDIA is simply impossible. Intel can be done, but you need a strong
business case with promise of many many units, and you need to sign
two NDAs in order to access the required, but insufficient,
documentation. The docs have some information but not all. It's
generally neccessary to reverse engineer parts of the factory BIOS in
order to actually get a board fully working.

On the opposite end of the spectrum is AMD, who have engineers
actively contributing code to coreboot. AMD recently let us know that
they will be adding AGESA support to coreboot, as well as releasing
AGESA under open source license, which means that coreboot will be
able to initialize many if not all AMD platforms with the code
written by AMD themselves, which is also being used by commercial
BIOS vendors. (AGESA is a firmware plugin system for AMD systems.)
This is of course really great news! :)

There was mention of BOCHS BIOS in the chat log. coreboot does not
want to be a BIOS, because BIOS is a 30 year old concept. There is
clean separation between coreboot and what we call a payload.
coreboot does hardware init, the payload starts the operating system.
I rant about ACPI a bit in the talks.

Payloads can be bootloaders or even a kernel. But for maximum
performance you will want to use SeaBIOS, an open source BIOS
implementation, as payload - because it supports ATA DMA, and boot
flash is much slower than that. (See http://stuge.se/pc2010.png - the
flash chip is *far* away from the CPU, on a slow bus.)

SeaBIOS was originally forked from BOCHS BIOS, but is very much a
project of it's own by now, is continually being updated, and is also
the default BIOS shipped with QEMU since some versions back.


Hope this helps clarify a bit.

//Peter

Re: [gentoo-embedded] Re: boot linux without a bios on intel platform

[Kfir Lavi]

[-- Attachment #1.1: Type: text/plain, Size: 4041 bytes --]

On Thu, Dec 23, 2010 at 1:53 PM, Peter Stuge <peter@stuge.se> wrote:

> Kfir Lavi wrote:
> > > I have an intel board, and the bios boots after 22sec.
> > > Is it possible to boot the linux without a bios.
>
> coreboot is your only alternative to a BIOS. I'm active in the
> project since some years. Instead of coreboot you could of course
> also consider buying licenses for a custom BIOS from AMI but that
> is often prohibitively expensive.
>
>
> > I have spoke in irc #gentoo-embedded with landley and he explained
> > some stuff about my question regarding coreboot, uboot on x86.
>
> uboot is not widely used on x86 so far. There has been some talk
> between coreboot and uboot because the two could complement each
> other well, but not yet.
>
> You're of course welcome to stop by #coreboot and talk to us, and/or
> check out some of the talks.
>
> http://www.coreboot.org/Screenshots#Videos
>
> I'd recommend "Beyond The Final Frontier" from 25C3 as a start:
>
>
> http://www.coreboot.org/Screenshots#Chaos_Communication_Congress_2008_.2825C3.29:_coreboot:_Beyond_The_Final_Frontier
>
> coreboot completes it's task in a few hundred milliseconds. Some more
> complicated boards (lots of busses and CPUs) take longer, maybe a
> second or even two.
>
> We have a list of supported mainboards:
>
> http://www.coreboot.org/Supported_Motherboards
>
> If your board is not listed it may be easy or it may be hard. When
> talking to us about it please be sure to provide very specific
> information about your hardware. "intel board" is e.g. useless, we
> need details for CPU, chipset, superio and the boot flash.
>
> As a general rule, NVIDIA and Intel are the worst possible targets
> for coreboot, because they will not release documentation.
>
> NVIDIA is simply impossible. Intel can be done, but you need a strong
> business case with promise of many many units, and you need to sign
> two NDAs in order to access the required, but insufficient,
> documentation. The docs have some information but not all. It's
> generally neccessary to reverse engineer parts of the factory BIOS in
> order to actually get a board fully working.
>
> On the opposite end of the spectrum is AMD, who have engineers
> actively contributing code to coreboot. AMD recently let us know that
> they will be adding AGESA support to coreboot, as well as releasing
> AGESA under open source license, which means that coreboot will be
> able to initialize many if not all AMD platforms with the code
> written by AMD themselves, which is also being used by commercial
> BIOS vendors. (AGESA is a firmware plugin system for AMD systems.)
> This is of course really great news! :)
>
> There was mention of BOCHS BIOS in the chat log. coreboot does not
> want to be a BIOS, because BIOS is a 30 year old concept. There is
> clean separation between coreboot and what we call a payload.
> coreboot does hardware init, the payload starts the operating system.
> I rant about ACPI a bit in the talks.
>
> Payloads can be bootloaders or even a kernel. But for maximum
> performance you will want to use SeaBIOS, an open source BIOS
> implementation, as payload - because it supports ATA DMA, and boot
> flash is much slower than that. (See http://stuge.se/pc2010.png - the
> flash chip is *far* away from the CPU, on a slow bus.)
>
> SeaBIOS was originally forked from BOCHS BIOS, but is very much a
> project of it's own by now, is continually being updated, and is also
> the default BIOS shipped with QEMU since some versions back.
>
>
> Hope this helps clarify a bit.
>
> //Peter
>
> Hi Peter,
Thanks for your lengthy replay. Very interesting talk.
I loved the push pins idea. Now I'm asking myself,
how I didn't thought about it myself. I used a paper clip, but it is
awkward.
I have a kontron board with an intel cpu. How can I get the spec with the
parts
in order to check if I will be able to use coreboot?
Attached is the lspci of the board.
I would also like to know (if it is possible) how hard is to create support
for this
board myself.

Regards,
Kfir

[-- Attachment #1.2: Type: text/html, Size: 5114 bytes --]

[-- Attachment #2: lspci.txt --]
[-- Type: text/plain, Size: 1755 bytes --]

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

Re: [gentoo-embedded] Re: boot linux without a bios on intel platform

[Peter Stuge]

Kfir Lavi wrote:
> Thanks for your lengthy replay. Very interesting talk.

I'm glad you liked it!


> I loved the push pins idea.

Hehe, yes, it's really handy. :)


> Now I'm asking myself, how I didn't thought about it myself. I used
> a paper clip, but it is awkward.

Yep. I like the pushpin idea a lot but I actually continue to use a
small screwdriver myself.


> I have a kontron board with an intel cpu. How can I get the spec
> with the parts in order to check if I will be able to use coreboot?
> Attached is the lspci of the board.
> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)

lspci is a good first bit of info! This chipset is not supported at
all. The only modern-ish Intel chipset that is supported is the i945.
Compare the other Kontron with Intel in the list of supported boards.


> I would also like to know (if it is possible) how hard is to create
> support for this board myself.

For an experienced coreboot developer I would estimate an absolute
minimum of eight man-months of work. This assumes that Intel NDAs and
document retrieval requests are processed instantly. It took 9 months
just to get NDAs processed for the coreboot developer who went
through that process. On the other hand, one Intel FAE I talked to
mentioned only weeks needed in some of his projects.

You will also benefit from test equipment that will allow you to
study DRAM signals, and CPU state. These are 100k pricetag items.

Learning how to initialize CPU, northbridge and memory controller
takes significant effort, and FAEs usually can not help.

Is this Mobile 4 Series chipset (whatever that means, you could try
to look for some more low-level product codes for the chipset) part
of Intel's Embedded division? If so, you may be able to find much
inforation at edc.intel.com, but only after going through some
approval process there.

It can certainly be worthwhile to do the coreboot work also for
something completely unsupported like this, but you need a fairly
large series production.

On the other hand, maybe you can just choose a different board that
is already supported. I would try hard to do just that.


//Peter

Re: [gentoo-embedded] Re: boot linux without a bios on intel platform

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 2672 bytes --]

On Fri, Dec 24, 2010 at 10:16 AM, Peter Stuge <peter@stuge.se> wrote:

> Kfir Lavi wrote:
> > Thanks for your lengthy replay. Very interesting talk.
>
> I'm glad you liked it!
>
>
> > I loved the push pins idea.
>
> Hehe, yes, it's really handy. :)
>
>
> > Now I'm asking myself, how I didn't thought about it myself. I used
> > a paper clip, but it is awkward.
>
> Yep. I like the pushpin idea a lot but I actually continue to use a
> small screwdriver myself.
>
>
> > I have a kontron board with an intel cpu. How can I get the spec
> > with the parts in order to check if I will be able to use coreboot?
> > Attached is the lspci of the board.
> > 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
> Controller Hub (rev 07)
>
> lspci is a good first bit of info! This chipset is not supported at
> all. The only modern-ish Intel chipset that is supported is the i945.
> Compare the other Kontron with Intel in the list of supported boards.
>
>
> > I would also like to know (if it is possible) how hard is to create
> > support for this board myself.
>
> For an experienced coreboot developer I would estimate an absolute
> minimum of eight man-months of work. This assumes that Intel NDAs and
> document retrieval requests are processed instantly. It took 9 months
> just to get NDAs processed for the coreboot developer who went
> through that process. On the other hand, one Intel FAE I talked to
> mentioned only weeks needed in some of his projects.
>
> You will also benefit from test equipment that will allow you to
> study DRAM signals, and CPU state. These are 100k pricetag items.
>
> Learning how to initialize CPU, northbridge and memory controller
> takes significant effort, and FAEs usually can not help.
>
> Is this Mobile 4 Series chipset (whatever that means, you could try
> to look for some more low-level product codes for the chipset) part
> of Intel's Embedded division? If so, you may be able to find much
> inforation at edc.intel.com, but only after going through some
> approval process there.
>
> It can certainly be worthwhile to do the coreboot work also for
> something completely unsupported like this, but you need a fairly
> large series production.
>
> On the other hand, maybe you can just choose a different board that
> is already supported. I would try hard to do just that.
>
>
> //Peter
>
> Hi Peter,
Time is very short for my project. I think replacing the board is the best
and quickest option.
Hope in this stage, I'll be able to do it. It is my advice but not my
decision.

Another way is to reduce boot time of the bios by kontron.
Is it possible to achive good boot times with ami bios?

Thanks,
Kfir

[-- Attachment #2: Type: text/html, Size: 3418 bytes --]