coreboot August 2014

coreboot@coreboot.org

43 participants
102 discussions

Re: [coreboot] cbfstool, Linux trampoline and SeaBIOS
by Curt Brune 29 Aug '14

29 Aug '14

Hello Ron, On Thu Aug 28 16:30, ron minnich wrote: > Curt, this is super great news for me to hear, and if you can show me > how to do the linux boot with linux as payload I need to see it. I > screwed it up and it did not work for me :) If this patch and idea are acceptable I will make a proper git patch and send it along. For Linux SeaBIOS payload, it was pretty easy, most of the directions are on the coreboot and SeaBIOS wiki. The only problem I had was for the patch I sent. Here are the steps I used -- I'll take for granted you know how to build coreboot with SeaBIOS as the payload. I did all this work using the emulated i440 qemu machine with a 16Mbyte rom size. 1. once you have your coreboot.rom, use the cbfstool to add images to the rom. 2. For the Linux kernel and initramfs I built a small Linux OS from the Open Network Install Environment (ONIE) project. It is a very simple OS that just runs from a ramdisk. 3. To add a Linux payload to SeaBIOS run the cbfstool like this: ONIE_IMAGE_DIR="$HOME/onie/build/images" KERNEL="${ONIE_IMAGE_DIR}/kvm_x86_64-r0.vmlinuz" INITRD="${ONIE_IMAGE_DIR}/kvm_x86_64-r0.initrd" CMDLINE="console=tty0 console=ttyS0,115200n8 seabios" $CBFSTOOL $COREBOOT_BUILDDIR/coreboot.rom add-payload -f $KERNEL -n img/LINUX -I $INITRD -C "$CMDLINE" The only real trick is the image needs to be in the "img" directory in the cbfs for SeaBIOS to find it. See the "-n" argument above. If you need more info I'm happy to send you the .config for both coreboot and SeaBIOS. > one thing I wonder: if you can boot linux as the payload, what's the > reason to use seabios? I'm missing something. Great question! I am working on the Open Network Install Environment (ONIE) project: http://www.opencompute.org/wiki/Networking/ONIE http://opencomputeproject.github.io/onie/docs You can think of ONIE as a "Linux based PXE, with more features". Currently ONIE runs on open, bare metal networking hardware, including PowerPC and x86 machines. For x86 platforms, I want to have ONIE available in the SeaBIOS boot menu. Having ONIE boot straight from coreboot is interesting (and fast!), but that is not ONIE's sole purpose. The systems and users we are targeting still need a boot menu to select things like "boot from USB", "boot from hard disk", etc. At the end of the day the point of the networking hardware is to boot the network operating system, not boot ONIE. This is similar to the server world, where the point is to boot the server OS, not PXE. Cheers, Curt

2 1

Re: [coreboot] New board with unsupported cpu, chipset, and superIO
by Todd Weaver 29 Aug '14

29 Aug '14

On Aug 28, 2014, at 10:59 AM, ron minnich <rminnich(a)gmail.com> wrote: >> The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) > > How much time and money for the RE effort did you have again? It needs > to be a lot. Were I you I would not expect much help from the vendor > to RE their code :-) Time was measured in months. Not weeks nor years. Funds varied, which is why we are gathering interested developers to get some quotes to propose funding the effort. > And you're still going to need the microcode blob, almost certainly, > unless you don't like having a working main board. We require blob-free and a working main board, so this sounds like a really challenging RE effort indeed! > If you NEED blob-free, you may need to go ARM. We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point. Todd.

4 7

cbfstool, Linux trampoline and SeaBIOS
by Curt Brune 29 Aug '14

29 Aug '14

Hello - First time poster, so take it easy on me :) This is a great project -- I was able to get a kvm+coreboot+SeaBIOS environment going pretty easily. I started with the master branch of coreboot and went from there. I am having a problem trying to load a Linux kernel+initramfs cbfs payload from SeaBIOS. I can successfully boot the same kernel+initramfs straight from coreboot (without SeaBIOS) as a payload. I started this topic on the SeaBIOS list -- there's a lot of good background in the replies there: http://www.seabios.org/pipermail/seabios/2014-August/008215.html I now think my problem lies in the cbfstool and the Linux trampoline. Summarizing the analysis from those posts: the Linux trampoline code does not set up the segment descriptors for __BOOT_CS and __BOOT_DS as described in the Linux kernel documentation: ... a GDT must be loaded with the descriptors for selectors __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat segment; __BOOT_CS must have execute/read permission, and __BOOT_DS must have read/write permission; Now in the working coreboot case it turns out the segment descriptors at selectors 0x10 and 0x18, setup in the coreboot ramstage, match what the Linux kernel expects (see coreboot/src/arch/x86/lib/c_start.S). In the non-working SeaBIOS case the segment descriptors are configured differently and the cbfs Linux payload does not work. If the cbfs Linux payload is to be used in multiple environments should the trampoline take care of descriptors that Linux requires? Attached is a patch to util/cbfstool/linux_trampoline.c that does just that. Basically I borrowed the descriptor configs from coreboot/src/arch/x86/lib/c_start.S for selectors 0x10 and 0x18. Apologies for my poor x86 assembly coding -- first time. Cheers, Curt

2 1

Re: [coreboot] apologies in advance for a question I may have asked
by Carl-Daniel Hailfinger 28 Aug '14

28 Aug '14

Am 27.08.2014 22:07 schrieb ron minnich: > well, stefan, I was hoping not to hear that answer, but I guess that's > the way it goes :-) Well, 16 MByte are doable and also happen on real hardware, but with bigger chips you're out of luck. Both for SPI addressing reasons (24 bit addresses by default) and for legacy reasons. I heard rumors that newer x86 can handle larger flash chips, but AFAIK only with the help of PIO, not directly mapped. Similar rule for Qemu. That said, changing FLASH_MAP_BASE_MIN to #define FLASH_MAP_BASE_MIN ((hwaddr)(0x100000000ULL - 16*1024*1024)) should work. Regards, Carl-Daniel

2 1

Re: [coreboot] disabling bios usb stack
by Scott Duplichan 28 Aug '14

28 Aug '14

ron minnich [mailto:rminnich@gmail.com] wrote: ]Thanks scott! ] ]So, what does an OS do to disable USB in the operating system? We have ]seen Linux do it, we're not quite sure just what ]place it gets done. ] ]ron If I understand your question, I am not sure I know the answer. If you boot linux with grub option 'nousb', or reboot Windows after disabling usb controllers from device manager, what happens? I assume the operating system just ignores USB controllers. It seems unlikely that the OS would take some action to ensure that they are properly disabled. Does UEFI disable USB controllers before handoff to the OS loader? I do not know. Having the OS not load USB drivers should eliminate USB related interrupts, but I know EHCI can generate memory accesses even when idle. Thanks, Scott

2 1

Re: [coreboot] New board with unsupported cpu, chipset, and superIO
by Todd Weaver 28 Aug '14

28 Aug '14

On Aug 28, 2014, at 10:36 AM, David Hubbard <david.c.hubbard+coreboot(a)gmail.com> wrote: > > The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) > > The reality is that Intel has no plans to release code for Xeon E3-1200 v3 and HM86 Express. Coreboot's progress so far has been to integrate the blobs. That is helpful to know, I was considering funding coreboot development, coupled with a libreboot (to deblob it) dual effort, and now I know it will be more than just a consideration.

1 0

Re: [coreboot] New board with unsupported cpu, chipset, and superIO
by Todd Weaver 28 Aug '14

28 Aug '14

Wonderful writeup Paul, thank you. see below… On Aug 28, 2014, at 9:59 AM, Paul Wilcox-Baker <wilcoxbaker(a)gmail.com> wrote: > Dear Todd, > >> It appears (from following the instructions) that I have a new board >> with unsupported cpu, chipset, and superIO. > >> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core >> Processor DRAM Controller (rev 06) >> 00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev >> 05) > > We are interested in a BIOS for the same processor family, but a different > PCH device. Maybe we can work together in this effort, I did track down a longtime developer relationship I have, who did BIOS development for Xerox, and is available to get involved with coreboot. >> c) If there is any coreboot developers that would be willing to contract >> for hire to develop coreboot for this board? > > There is a company, Sage Engineering that ports coreboot to various > processors. We are probably going to use them. See > http://www.se-eng.com or to ask a question use: > http://www.se-eng.com/contact/ I was referred to them yesterday, and am in contact with them, we will very likely use their expertise. > From what I have been able to find out you need some binary "secret sauce" > that comes from Intel. This allows coreboot to do things like set up the > DRAM controller and video. The problem is that Intel only lets a few > people have access to this code. > > For instance, for one of the people who could get this code, they claim > the process is this simple: > http://www.coreboot.org/pipermail/coreboot/2014-July/078275.html > The above information is remarkably helpful in figuring out how to proceed! I really appreciate getting this overview. >> It appears "If it is not supported by coreboot then you will have a lot >> of work in front of you." > > This view, is based on not having the Intel code and writing your own code > to set up the DRAM controllers. I imagine that it would be very difficult > to write code for modern DRAM controllers, you have to read the EEPROMs > on the DIMMs to determine the DRAM size and other characteristics, then > set up the controller to match. Finally, DDR3 (used by this processor) has a > training phase to get data accesses aligned in time. This might be implemented > in hardware, or you might have to write code to do it. I don't know! > The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) > If you get a different story about this, I would love to hear it. > > Thanks, Paul The story I’ve heard thus far is exactly as you spell it out, even though you have provided more information in certain parts. Thanks Paul, and let me know if we can pool resources to get this to happen! Todd.

3 2

Re: [coreboot] New board with unsupported cpu, chipset, and superIO
by Patrick Georgi 28 Aug '14

28 Aug '14

Am 28.08.2014 um 18:59 schrieb Paul Wilcox-Baker: > From what I have been able to find out you need some binary "secret sauce" > that comes from Intel. This allows coreboot to do things like set up the > DRAM controller and video. The problem is that Intel only lets a few > people have access to this code. Relevant binaries for several chipsets can be found on http://www.intel.com/fsp Support for FSP on this list is limited (since we're stuck at the same binary boundaries as everyone else), but we'll try. Regards, Patrick

1 0

New board with unsupported cpu, chipset, and superIO
by Todd Weaver 28 Aug '14

28 Aug '14

It appears (from following the instructions) that I have a new board with unsupported cpu, chipset, and superIO. 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06) 00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev 05) >From this page: http://www.coreboot.org/Developer_Manual#Supporting_a_new_board_with_a_unsu… It appears "If it is not supported by coreboot then you will have a lot of work in front of you." What I need to find out is: a) If it is even possible to get coreboot to work with this board? b) How much time would it take to get coreboot to work with this board? c) If there is any coreboot developers that would be willing to contract for hire to develop coreboot for this board? It is a requirement to replace the bios with coreboot, so I am tasked with making sure it is possible (a), a rough idea of how long (b), and if we can hire somebody to develop it (c). I appreciate any replies to any parts of the above, and I am hopeful somebody would be able to have the time needed to get paid to get coreboot onto this board. Thank you! Todd Weaver

2 1

Re: [coreboot] for more working mainboards
by Mike 28 Aug '14

28 Aug '14

That puts ideas to rest. :) Thanks. No more questions from me. Have a good day, guys -Mike On 8/27/2014 1:05 PM, ron minnich wrote: > On Wed, Aug 27, 2014 at 11:11 AM, <echelon(a)free.fr> wrote: >> Hello Ron, >> Could you be more speciffic about "what is not doable" today? (and why?) >> Sorry to be annoying.. > > You are not being annoying at all. And I wish I could say more. Let me > just say that some of the hardware bugs I saw were very complex, and > very subtle, and only observable on some very expensive logic > analyzers. The resolution of them required a lot of help from the > vendors. They took lots of time with lots of engineers and resolved > down, typically, to very small changes. > > I was left feeling that the small outfits that used to do hardware in > the early days (I mean the 70s and 80s) could never make it in this > new world. It's very expensive and very hard. I realize some might see > the raspberry pi is a counterpoint, but I don't think it really is, > because the level of complexity of that system is so much less. > > ron >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2014