Re: [coreboot] New board with unsupported cpu, chipset, and superIO
Am 2014-08-28 23:38, schrieb Todd Weaver:
Comparing the blob-free versions from Intel (which are apparently
signed, so according to http://www.coreboot.org/Binary_situation are
at a 9000+ panic level), would it be possible to have blob-free
(probably through RE) that would work (meaning does not require signed
binaries) on an AMD board?
Newer chipsets (as in yet to be released) come with signed parts, but it
seems the scope of the signature is configurable somehow by AMD. There
were some mails about that a couple of days ago ("AMD PSP").
We will do what we can here. The issue is even with immense leverage,
having the source released (from AMI, or AMD, (or Intel for that
matter)) would undermine tremendous profit that these companies make
by keeping this proprietary.
AMD claims that they stopped working on open sourcing their
initialization code because it's lots of work (ie. money) with limited
return on investment. How much work that is isn't here or there (most of
that is because their internal development process is less than optimal
and, like most processes in most organizations, hard to change).
But it means that someone could make it worth their while given the
right kind of project.
What they don't provide sources for is CPU microcode updates (no one
does since it's of limited value without the microcode development
toolchain and the microcode itself that is getting updated) and various
smaller firmware (USB3 which is a licensed core, IMC, an embedded
controller, and the SMU).
For IMC and SMU there's some reverse engineering effort, partially
documented in the wiki, so by asking the right questions to the right
people in this community, plus some development, it might be possible to
get them opened up even without AMD's help.
Patrick
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cbfstool, Linux trampoline and SeaBIOS
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 :) one thing I wonder: if you can boot linux as the payload, what's the reason to use seabios? I'm missing something. Many thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] cbfstool, Linux trampoline and SeaBIOS
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
diff --git a/util/cbfstool/linux_trampoline.c b/util/cbfstool/linux_trampoline.c
index 368d63a..3ac8913 100644
--- a/util/cbfstool/linux_trampoline.c
+++ b/util/cbfstool/linux_trampoline.c
@@ -54,88 +54,101 @@ jne .headerSearch
cmp %ecx, %ebx // reached the end == not found anything?
je 2f // give up
// we assume the checksum is okay, no test
mov 4(%ecx), %ebx
add %ecx, %ebx // ebx = cb_header + header_bytes
mov 20(%ecx), %ecx // ecx = table_entries
.tableScan:
cmp $CB_TAG_FORWARD, (%ebx)
jne .testMemory
/* forward tag: assume 32bit pointer */
mov 8(%ebx), %ecx
jmp .headerSearch
.testMemory:
cmp $CB_TAG_MEMORY, (%ebx)
jne .testFramebuffer
/* memory tag: copy e820 map and entry count. also determine alt_mem_k */
mov 4(%ebx), %eax
sub $8, %eax
shr $2, %eax /* eax = number of dwords of e820 data */
cmp $(32 * 5), %eax /* linux wants at most 32 entries of 5 dwords */
jng 1f
mov $(32 * 5), %eax /* only copy 32 entries */
1:
mov %eax, %esi
mov $5, %edi
div %edi
mov %eax, (LINUX_PARAM_LOC + E820_NR_OFFSET)
mov %esi, %eax
xchg %eax, %ecx
lea 8(%ebx), %esi /* e820 data source */
mov $(LINUX_PARAM_LOC + E820_OFFSET), %edi
rep movsl
xchg %eax, %ecx
jmp .endScan
.testFramebuffer:
cmp $CB_TAG_FRAMEBUFFER, (%ebx)
jne .endScan
/* TODO: handle framebuffer tag */
.endScan:
add 4(%ebx), %ebx
dec %ecx
jnz .tableScan
+/* Setup basic code and data segment selectors for Linux */
+/* Setup code segment descriptor, selector 0x10 - execute, read */
+mov %esp, %eax
+sgdt (%eax)
+mov 2(%eax), %ebx
+movl $0x, 16(%ebx)
+movl $0x00cf9b00, 20(%ebx)
+/* Setup data segment descriptor, selector 0x18 - data, read/write */
+movl $0x, 24(%ebx)
+movl $0x00cf9300, 28(%ebx)
+
/* finally: jump to kernel */
mov $LINUX_PARAM_LOC, %esi
jmp *(LINUX_PARAM_LOC + LINUX_ENTRY_OFFSET)
2:
hlt
jmp 2b
.trampoline_end:
.global trampoline_start, trampoline_size
trampoline_start:
.long .trampoline_start
trampoline_size:
.long .trampoline_end - .trampoline_start
#endif
/* The code above is hand-crafted to fit various contraints.
* To simplify porting, the below matches the above.
* When changing any code in here, compile the above as a .S
* file, objcopy it to binary and paste the result below (minus
* the last 8 bytes which are trampoline_start and trampoline_size).
*/
const unsigned char trampoline[] = {
0xfc, 0x31, 0xd2, 0xb9, 0x00, 0x00, 0x00, 0x00, 0xbb, 0x00, 0x00, 0x01, 0x00, 0x01, 0xcb, 0x8b,
0x01, 0x3d, 0x4c, 0x42, 0x49, 0x4f, 0x74, 0x07, 0x83, 0xc1, 0x10, 0x39, 0xcb, 0x75, 0xe9, 0x39,
-0xcb, 0x74, 0x60, 0x8b, 0x59, 0x04, 0x01, 0xcb, 0x8b, 0x49, 0x14, 0x83, 0x3b, 0x11, 0x75, 0x05,
-0x8b, 0x4b, 0x08, 0xeb, 0xd3, 0x83, 0x3b, 0x01, 0x75, 0x33, 0x8b, 0x43, 0x04, 0x83, 0xe8, 0x08,
-0xc1, 0xe8, 0x02, 0x3d, 0xa0, 0x00, 0x00, 0x00, 0x7e, 0x05, 0xb8, 0xa0, 0x00, 0x00, 0x00, 0x89,
-0xc6, 0xbf, 0x05, 0x00, 0x00, 0x00, 0xf7, 0xf7, 0xa3, 0xe8, 0x01, 0x09, 0x00, 0x89, 0xf0, 0x91,
-0x8d, 0x73, 0x08, 0xbf, 0xd0, 0x02, 0x09, 0x00, 0xf3, 0xa5, 0x91, 0xeb, 0x05, 0x83, 0x3b, 0x12,
-0x75, 0x00, 0x03, 0x5b, 0x04, 0x49, 0x75, 0xb3, 0xbe, 0x00, 0x00, 0x09, 0x00, 0xff, 0x25, 0x14,
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
On Aug 28, 2014, at 2:29 PM, Carl-Daniel Hailfinger wrote: > Am 28.08.2014 23:16 schrieb Todd Weaver: >> On Aug 28, 2014, at 11:26 AM, Todd Weaver wrote: >>> On Aug 28, 2014, at 10:59 AM, ron minnich 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 :) 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. >> Per the private messages, I am asking upstream if we can switch to AMD, is >> AMD in a state where we can attain (meaning it is possible (comparing that >> to Intel)) a binary free BIOS? > > You can, but with chipsets/CPUs released in the last few months you may > be out of luck. Right now, it appears AMD does not see compelling enough > business reasons to publish the source code for the newest hardware > generations, but you may be able to get the source code for the blobs > under NDA. Thanks, that helps set the stage with AMD discussions. > That said, there are quite a few pieces of recent (and still in > production) AMD hardware which do have full coreboot support. Exceptions > from the blob-free guarantee are graphics firmware and USB3 firmware, > which are both not executed on the main CPU. Comparing the blob-free versions from Intel (which are apparently signed, so according to http://www.coreboot.org/Binary_situation are at a 9000+ panic level), would it be possible to have blob-free (probably through RE) that would work (meaning does not require signed binaries) on an AMD board? > Depending on how big your order is (not just "enthusiasts all over the > world will surely buy it", but real money spent by your > company/organization), you might have some real leverage, even for > getting code published. We will do what we can here. The issue is even with immense leverage, having the source released (from AMI, or AMD, (or Intel for that matter)) would undermine tremendous profit that these companies make by keeping this proprietary. So I’m leaning toward the direction that we’d have to RE the missing pieces (but could be wrong, thus the questions). Todd. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
Am 28.08.2014 23:16 schrieb Todd Weaver: > On Aug 28, 2014, at 11:26 AM, Todd Weaver wrote: >> On Aug 28, 2014, at 10:59 AM, ron minnich 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 :) >>> 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. > Per the private messages, I am asking upstream if we can switch to AMD, is > AMD in a state where we can attain (meaning it is possible (comparing that to > Intel)) a binary free BIOS? You can, but with chipsets/CPUs released in the last few months you may be out of luck. Right now, it appears AMD does not see compelling enough business reasons to publish the source code for the newest hardware generations, but you may be able to get the source code for the blobs under NDA. That said, there are quite a few pieces of recent (and still in production) AMD hardware which do have full coreboot support. Exceptions from the blob-free guarantee are graphics firmware and USB3 firmware, which are both not executed on the main CPU. Depending on how big your order is (not just "enthusiasts all over the world will surely buy it", but real money spent by your company/organization), you might have some real leverage, even for getting code published. Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
On Aug 28, 2014, at 11:26 AM, Todd Weaver wrote: > On Aug 28, 2014, at 10:59 AM, ron minnich 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 :) >> 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. Per the private messages, I am asking upstream if we can switch to AMD, is AMD in a state where we can attain (meaning it is possible (comparing that to Intel)) a binary free BIOS? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] apologies in advance for a question I may have asked
turns out 16 MiB will do it! Thanks all! I really am glad you are here to answer silly questions :-) ron On Thu, Aug 28, 2014 at 1:29 PM, Carl-Daniel Hailfinger wrote: > 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)(0x1ULL - 16*1024*1024)) > > should work. > > > Regards, > Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] apologies in advance for a question I may have asked
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)(0x1ULL - 16*1024*1024)) should work. Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] disabling bios usb stack
The guys found it, bit in southbridge to enable SMI interrupts, they turned it off and are now seeing a 40 hz. interrupt. It never ends. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] disabling bios usb stack
ron minnich [mailto:rminn...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
Am 28.08.2014 um 20:26 schrieb Todd Weaver: > We require blob-free and a working main board, so this sounds like a really > challenging RE effort indeed! > We cannot easily (actually it would be quite impossible) to move from the > Intel hardware at this point. In that case you will probably have to stick to GM45 or older, or Quark X1000. All other Intel chipsets require - to my knowledge - management engine firmware. Regards, Patrick signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
On Aug 28, 2014, at 10:59 AM, ron minnich 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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
On Aug 28, 2014, at 10:36 AM, David Hubbard 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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
On Thu, Aug 28, 2014 at 10:28 AM, Todd Weaver 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 :-) And you're still going to need the microcode blob, almost certainly, unless you don't like having a working mainboard. If you NEED blob-free, you may need to go ARM. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
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 signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
On Thu, Aug 28, 2014 at 11:28 AM, Todd Weaver wrote: > >> 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 :) 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. David -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
Wonderful writeup Paul, thank you. see below… On Aug 28, 2014, at 9:59 AM, Paul Wilcox-Baker 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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New board with unsupported cpu, chipset, and superIO
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. > 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/ >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 > 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! If you get a different story about this, I would love to hear it. Thanks, Paul -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
