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/ONIEhttp://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
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.
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
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
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
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.
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.
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
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_un...
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
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
>
