On Thu, Dec 23, 2010 at 11:55 AM, Kfir Lavi <[email protected]> wrote:
> > > On Thu, Dec 23, 2010 at 10:25 AM, Kfir Lavi <[email protected]> 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
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 [[email protected]] 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
