[U-Boot] [PATCH 25/25] x86: Add a README.x86 for U-Boot on x86 support
Signed-off-by: Bin Meng bmeng.cn@gmail.com --- doc/README.x86 | 123 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 doc/README.x86
diff --git a/doc/README.x86 b/doc/README.x86 new file mode 100644 index 0000000..a79f510 --- /dev/null +++ b/doc/README.x86 @@ -0,0 +1,123 @@ +# +# Copyright (C) 2014, Simon Glass sjg@chromium.org +# Copyright (C) 2014, Bin Meng bmeng.cn@gmail.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + +U-Boot on x86 +============= + +This document describes the information about U-Boot running on x86 targets, +including supported boards, build instructions, todo list, etc. + +Status +------ +U-Boot supports running as a coreboot [1] payload on x86. So far only link +(Chromebook pixel) has been tested, but it should work with minimal adjustments +on other x86 boards since coreboot deals with most of the low-level details. + +U-Boot also supports booting directly from x86 reset vector without coreboot, +aka raw support or bare support. Currently Google Chromebook link and Intel +Crown Bay board support running U-Boot 'bare metal'. + +As for loading OS, U-Boot supports directly booting a 32-bit or 64-bit Linux +kernel as part of a FIT image. It also supports a compressed zImage. + +Build Instructions +------------------ +Building U-Boot as a coreboot payload is just like building U-Boot for targets +on other architectures, like below: + +$ make coreboot-x86_defconfig +$ make all + +Building rom version U-Boot (hereafter referred to as u-boot.rom) is a little +bit tricky, as generally it requires several binary blobs which are not shipped +in the U-Boot source tree. Due to this reason, the u-boot.rom build is not +turned on by default in the U-Boot source tree. Firstly, you need turn it on +by uncommenting the following line in the main U-Boot Makefile: + +# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom + +Google Chromebook link specific instructions: + +Firstly, you need the following binary blobs: + +* descriptor.bin - Intel flash descriptor +* me.bin - Intel Management Engine +* mrc.bin - Memory Reference Code, which sets up SDRAM +* video ROM - sets up the display + +You can get these binary blobs by: + +$ git clone http://review.coreboot.org/p/blobs.git +$ cd blobs + +Find the following files: + +* ./mainboard/google/link/descriptor.bin +* ./mainboard/google/link/me.bin +* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin + +The 3rd one should be renamed to mrc.bin. +As for the video ROM, you can get it here [2]. + +Now you can build U-Boot and obtain u-boot.rom: + +$ make chromebook_link_defconfig +$ make all + +Intel Crown Bay specific instructions: + +U-Boot support of Intel Crown Bay board [3] relies on a binary blob called +Firmware Support Package [4] to perform all the necessary initialization steps +as documented in the BIOS Writer Guide including initialization of the CPU, +memory controller, chipset and certain bus interfaces. + +Downalod the Intel FSP for Atom E6xx series and Platform Controller Hub EG20T, +install it on your host and locate the FSP binary blob. Note this platform +also requires a Chipset Micro Code (CMC) state machine binary to be present in +the SPI flash where u-boot.rom resides, and this CMC binary blob can be found +in this FSP package too. + +* ./FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd +* ./Microcode/C0_22211.BIN + +Now you can build U-Boot and obtaim u-boot.rom + +$ make crownbay_defconfig +$ make menuconfig # points FSP and CMC binary path to the correct one +$ make all + +CPU Microcode +------------- +Modern CPU usually requires a special bit stream called microcode [5] to be +loaded on the processor after power up in order to function properly. U-Boot +has already integrated these as hex dumps in the source tree. + +Driver Model +------------ +x86 has been converted to use driver model for serial and GPIO. + +Device Tree +----------- +x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to +be turned on. Not every device on the board is configured via devie tree, but +more and more devices will be added as time goes by. Check out the directory +arch/x86/dts/ for these device tree source files. + +TODO List +--------- +- MTRR support (for performance) +- Audio +- Chrome OS verified boot +- SMI and ACPI support, to provide platform info and facilities to Linux + +References +---------- +[1] http://www.coreboot.org +[2] http://www.coreboot.org/~stepan/pci8086,0166.rom +[3] http://www.intel.com/content/www/us/en/embedded/design-tools/evaluation-plat... +[4] http://www.intel.com/fsp +[5] http://en.wikipedia.org/wiki/Microcode
Hi Bin,
On 4 December 2014 at 08:04, Bin Meng bmeng.cn@gmail.com wrote:
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 123 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 doc/README.x86
diff --git a/doc/README.x86 b/doc/README.x86 new file mode 100644 index 0000000..a79f510 --- /dev/null +++ b/doc/README.x86 @@ -0,0 +1,123 @@ +# +# Copyright (C) 2014, Simon Glass sjg@chromium.org +# Copyright (C) 2014, Bin Meng bmeng.cn@gmail.com +# +# SPDX-License-Identifier: GPL-2.0+ +#
+U-Boot on x86 +=============
Very nice!
+This document describes the information about U-Boot running on x86 targets, +including supported boards, build instructions, todo list, etc.
+Status +------ +U-Boot supports running as a coreboot [1] payload on x86. So far only link +(Chromebook pixel) has been tested, but it should work with minimal adjustments +on other x86 boards since coreboot deals with most of the low-level details.
+U-Boot also supports booting directly from x86 reset vector without coreboot, +aka raw support or bare support. Currently Google Chromebook link and Intel +Crown Bay board support running U-Boot 'bare metal'.
+As for loading OS, U-Boot supports directly booting a 32-bit or 64-bit Linux +kernel as part of a FIT image. It also supports a compressed zImage.
+Build Instructions +------------------ +Building U-Boot as a coreboot payload is just like building U-Boot for targets +on other architectures, like below:
+$ make coreboot-x86_defconfig +$ make all
+Building rom version U-Boot (hereafter referred to as u-boot.rom) is a little +bit tricky, as generally it requires several binary blobs which are not shipped +in the U-Boot source tree. Due to this reason, the u-boot.rom build is not +turned on by default in the U-Boot source tree. Firstly, you need turn it on +by uncommenting the following line in the main U-Boot Makefile:
+# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+Google Chromebook link specific instructions:
+Firstly, you need the following binary blobs:
+* descriptor.bin - Intel flash descriptor +* me.bin - Intel Management Engine +* mrc.bin - Memory Reference Code, which sets up SDRAM +* video ROM - sets up the display
+You can get these binary blobs by:
+$ git clone http://review.coreboot.org/p/blobs.git +$ cd blobs
+Find the following files:
+* ./mainboard/google/link/descriptor.bin +* ./mainboard/google/link/me.bin +* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin
+The 3rd one should be renamed to mrc.bin. +As for the video ROM, you can get it here [2].
+Now you can build U-Boot and obtain u-boot.rom:
+$ make chromebook_link_defconfig +$ make all
+Intel Crown Bay specific instructions:
+U-Boot support of Intel Crown Bay board [3] relies on a binary blob called +Firmware Support Package [4] to perform all the necessary initialization steps +as documented in the BIOS Writer Guide including initialization of the CPU, +memory controller, chipset and certain bus interfaces.
+Downalod the Intel FSP for Atom E6xx series and Platform Controller Hub EG20T, +install it on your host and locate the FSP binary blob. Note this platform +also requires a Chipset Micro Code (CMC) state machine binary to be present in +the SPI flash where u-boot.rom resides, and this CMC binary blob can be found +in this FSP package too.
Can we just put them in the board directory with standard names?
+* ./FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd +* ./Microcode/C0_22211.BIN
+Now you can build U-Boot and obtaim u-boot.rom
+$ make crownbay_defconfig +$ make menuconfig # points FSP and CMC binary path to the correct one
Best if we can avoid that step.
+$ make all
+CPU Microcode +------------- +Modern CPU usually requires a special bit stream called microcode [5] to be +loaded on the processor after power up in order to function properly. U-Boot +has already integrated these as hex dumps in the source tree.
+Driver Model +------------ +x86 has been converted to use driver model for serial and GPIO.
+Device Tree +----------- +x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to +be turned on. Not every device on the board is configured via devie tree, but +more and more devices will be added as time goes by. Check out the directory +arch/x86/dts/ for these device tree source files.
+TODO List +--------- +- MTRR support (for performance)
I'm interested - does the lack of this make your board slow?
+- Audio +- Chrome OS verified boot +- SMI and ACPI support, to provide platform info and facilities to Linux
+References +---------- +[1] http://www.coreboot.org +[2] http://www.coreboot.org/~stepan/pci8086,0166.rom +[3] http://www.intel.com/content/www/us/en/embedded/design-tools/evaluation-plat... +[4] http://www.intel.com/fsp
+[5] http://en.wikipedia.org/wiki/Microcode
1.8.2.1
Regards, Simon
Hi Simon,
On Fri, Dec 5, 2014 at 8:03 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:04, Bin Meng bmeng.cn@gmail.com wrote:
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 123 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 doc/README.x86
diff --git a/doc/README.x86 b/doc/README.x86 new file mode 100644 index 0000000..a79f510 --- /dev/null +++ b/doc/README.x86 @@ -0,0 +1,123 @@ +# +# Copyright (C) 2014, Simon Glass sjg@chromium.org +# Copyright (C) 2014, Bin Meng bmeng.cn@gmail.com +# +# SPDX-License-Identifier: GPL-2.0+ +#
+U-Boot on x86 +=============
Very nice!
+This document describes the information about U-Boot running on x86 targets, +including supported boards, build instructions, todo list, etc.
+Status +------ +U-Boot supports running as a coreboot [1] payload on x86. So far only link +(Chromebook pixel) has been tested, but it should work with minimal adjustments +on other x86 boards since coreboot deals with most of the low-level details.
+U-Boot also supports booting directly from x86 reset vector without coreboot, +aka raw support or bare support. Currently Google Chromebook link and Intel +Crown Bay board support running U-Boot 'bare metal'.
+As for loading OS, U-Boot supports directly booting a 32-bit or 64-bit Linux +kernel as part of a FIT image. It also supports a compressed zImage.
+Build Instructions +------------------ +Building U-Boot as a coreboot payload is just like building U-Boot for targets +on other architectures, like below:
+$ make coreboot-x86_defconfig +$ make all
+Building rom version U-Boot (hereafter referred to as u-boot.rom) is a little +bit tricky, as generally it requires several binary blobs which are not shipped +in the U-Boot source tree. Due to this reason, the u-boot.rom build is not +turned on by default in the U-Boot source tree. Firstly, you need turn it on +by uncommenting the following line in the main U-Boot Makefile:
+# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+Google Chromebook link specific instructions:
+Firstly, you need the following binary blobs:
+* descriptor.bin - Intel flash descriptor +* me.bin - Intel Management Engine +* mrc.bin - Memory Reference Code, which sets up SDRAM +* video ROM - sets up the display
+You can get these binary blobs by:
+$ git clone http://review.coreboot.org/p/blobs.git +$ cd blobs
+Find the following files:
+* ./mainboard/google/link/descriptor.bin +* ./mainboard/google/link/me.bin +* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin
+The 3rd one should be renamed to mrc.bin. +As for the video ROM, you can get it here [2].
+Now you can build U-Boot and obtain u-boot.rom:
+$ make chromebook_link_defconfig +$ make all
+Intel Crown Bay specific instructions:
+U-Boot support of Intel Crown Bay board [3] relies on a binary blob called +Firmware Support Package [4] to perform all the necessary initialization steps +as documented in the BIOS Writer Guide including initialization of the CPU, +memory controller, chipset and certain bus interfaces.
+Downalod the Intel FSP for Atom E6xx series and Platform Controller Hub EG20T, +install it on your host and locate the FSP binary blob. Note this platform +also requires a Chipset Micro Code (CMC) state machine binary to be present in +the SPI flash where u-boot.rom resides, and this CMC binary blob can be found +in this FSP package too.
Can we just put them in the board directory with standard names?
Yes, will do it in v2.
+* ./FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd +* ./Microcode/C0_22211.BIN
+Now you can build U-Boot and obtaim u-boot.rom
+$ make crownbay_defconfig +$ make menuconfig # points FSP and CMC binary path to the correct one
Best if we can avoid that step.
I will update the instructions to use the standard binary blob names, so that this step can be omitted.
+$ make all
+CPU Microcode +------------- +Modern CPU usually requires a special bit stream called microcode [5] to be +loaded on the processor after power up in order to function properly. U-Boot +has already integrated these as hex dumps in the source tree.
+Driver Model +------------ +x86 has been converted to use driver model for serial and GPIO.
+Device Tree +----------- +x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to +be turned on. Not every device on the board is configured via devie tree, but +more and more devices will be added as time goes by. Check out the directory +arch/x86/dts/ for these device tree source files.
+TODO List +--------- +- MTRR support (for performance)
I'm interested - does the lack of this make your board slow?
I believe the FSP binary blob already has the MTRR support, and U-Boot running on my board is pretty fast.
[snip]
Regards, Bin
Hi Simon, Bin,
u-boot-bounces@lists.denx.de wrote on 12/04/2014 04:03:54 PM:
From: Simon Glass sjg@chromium.org To: Bin Meng bmeng.cn@gmail.com Cc: U-Boot Mailing List u-boot@lists.denx.de Date: 12/04/2014 04:04 PM Subject: Re: [U-Boot] [PATCH 25/25] x86: Add a README.x86 for U-Boot on x86 support Sent by: u-boot-bounces@lists.denx.de
Hi Bin,
On 4 December 2014 at 08:04, Bin Meng bmeng.cn@gmail.com wrote:
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 123 ++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++
1 file changed, 123 insertions(+) create mode 100644 doc/README.x86
diff --git a/doc/README.x86 b/doc/README.x86 new file mode 100644 index 0000000..a79f510 --- /dev/null +++ b/doc/README.x86 @@ -0,0 +1,123 @@ +# +# Copyright (C) 2014, Simon Glass sjg@chromium.org +# Copyright (C) 2014, Bin Meng bmeng.cn@gmail.com +# +# SPDX-License-Identifier: GPL-2.0+ +#
+U-Boot on x86 +=============
Very nice!
This is all really great work.
I do have a question though, and if it's already been asked/answered and I missed the thread I apologize for the noise. Part of the reason we've held off on doing this project (other than resources of course :) ) was a concern about licensing. U-boot is released under the GPL and we're worried that by linking in Intel's FSP we're creating a "derived work" that would then require Intel to release the source for the FSP, which they aren't going to do and would leave us open to law suits. Doing it by calls into an opaque blob can loosely be defined as a dynamically linked library and therefore fall under the GPL exception clause, but our legal department considers that a dangerous assumption on our part.
Has anyone considered this issue? I'm not a lawyer so I get lost in the legalize of licences pretty fast.
Thanks again for all the work.
V/r Bruce
[snip]
Hi Bruce,
On 5 December 2014 at 11:34, Bruce_Leonard@selinc.com wrote:
Hi Simon, Bin,
u-boot-bounces@lists.denx.de wrote on 12/04/2014 04:03:54 PM:
From: Simon Glass sjg@chromium.org To: Bin Meng bmeng.cn@gmail.com Cc: U-Boot Mailing List u-boot@lists.denx.de Date: 12/04/2014 04:04 PM Subject: Re: [U-Boot] [PATCH 25/25] x86: Add a README.x86 for U-Boot on x86 support Sent by: u-boot-bounces@lists.denx.de
Hi Bin,
On 4 December 2014 at 08:04, Bin Meng bmeng.cn@gmail.com wrote:
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 123 ++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++
1 file changed, 123 insertions(+) create mode 100644 doc/README.x86
diff --git a/doc/README.x86 b/doc/README.x86 new file mode 100644 index 0000000..a79f510 --- /dev/null +++ b/doc/README.x86 @@ -0,0 +1,123 @@ +# +# Copyright (C) 2014, Simon Glass sjg@chromium.org +# Copyright (C) 2014, Bin Meng bmeng.cn@gmail.com +# +# SPDX-License-Identifier: GPL-2.0+ +#
+U-Boot on x86 +=============
Very nice!
This is all really great work.
I do have a question though, and if it's already been asked/answered and I missed the thread I apologize for the noise. Part of the reason we've held off on doing this project (other than resources of course :) ) was a concern about licensing. U-boot is released under the GPL and we're worried that by linking in Intel's FSP we're creating a "derived work" that would then require Intel to release the source for the FSP, which they aren't going to do and would leave us open to law suits. Doing it by calls into an opaque blob can loosely be defined as a dynamically linked library and therefore fall under the GPL exception clause, but our legal department considers that a dangerous assumption on our part.
Has anyone considered this issue? I'm not a lawyer so I get lost in the legalize of licences pretty fast.
Thanks again for all the work.
Well if you a legal department, that's what you pay them for and they should be able to figure this out. Clearly if it were not permitted to use the binary blobs in open source software then the blobs wouldn't be very useful. But I'm not a lawyer either and am not qualified to provide legal advice! It would be useful if you could post what you find either way. And if for some reason there is a problem, we could take it up with Intel.
You can get to the license here:
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-su...
This is what it says today:
The terms of the software license agreement included with any software you download will control your use of the software.
INTEL SOFTWARE LICENSE AGREEMENT
IMPORTANT - READ BEFORE COPYING, INSTALLING OR USING. Do not use or load this software and any associated materials (collectively, the "Software") until you have carefully read the following terms and conditions. By loading or using the Software, you agree to the terms of this Agreement. If you do not wish to so agree, do not install or use the Software.
LICENSES: Please Note: - If you are a network administrator, the "Site License" below shall apply to you. - If you are an end user, the "Single User License" shall apply to you. - If you are an original equipment manufacturer (OEM), the "OEM License" shall apply to you.
SITE LICENSE. You may copy the Software onto your organization's computers for your organization's use, and you may make a reasonable number of back-up copies of the Software, subject to these conditions:
1. This Software is licensed for use only in conjunction with Intel component products. Use of the Software in conjunction with non-Intel component products is not licensed hereunder. 2. You may not copy, modify, rent, sell, distribute or transfer any part of the Software except as provided in this Agreement, and you agree to prevent unauthorized copying of the Software. 3. You may not reverse engineer, decompile, or disassemble the Software. 4. You may not sublicense or permit simultaneous use of the Software by more than one user. 5. The Software may include portions offered on terms in addition to those set out here, as set out in a license accompanying those portions.
SINGLE USER LICENSE. You may copy the Software onto a single computer for your personal, noncommercial use, and you may make one back-up copy of the Software, subject to these conditions:
1. This Software is licensed for use only in conjunction with Intel component products. Use of the Software in conjunction with non-Intel component products is not licensed hereunder. 2. You may not copy, modify, rent, sell, distribute or transfer any part of the Software except as provided in this Agreement, and you agree to prevent unauthorized copying of the Software. 3. You may not reverse engineer, decompile, or disassemble the Software. 4. You may not sublicense or permit simultaneous use of the Software by more than one user. 5. The Software may include portions offered on terms in addition to those set out here, as set out in a license accompanying those portions.
OEM LICENSE: You may reproduce and distribute the Software only as an integral part of or incorporated in Your product or as a standalone Software maintenance update for existing end users of Your products, excluding any other standalone products, subject to these conditions:
1. This Software is licensed for use only in conjunction with Intel component products. Use of the Software in conjunction with non-Intel component products is not licensed hereunder. 2. You may not copy, modify, rent, sell, distribute or transfer any part of the Software except as provided in this Agreement, and you agree to prevent unauthorized copying of the Software. 3. You may not reverse engineer, decompile, or disassemble the Software. 4. You may only distribute the Software to your customers pursuant to a written license agreement. Such license agreement may be a "break-the- seal" license agreement. At a minimum such license shall safeguard Intel's ownership rights to the Software. 5. The Software may include portions offered on terms in addition to those set out here, as set out in a license accompanying those portions.
NO OTHER RIGHTS. No rights or licenses are granted by Intel to You, expressly or by implication, with respect to any proprietary information or patent, copyright, mask work, trademark, trade secret, or other intellectual property right owned or controlled by Intel, except as expressly provided in this Agreement.
OWNERSHIP OF SOFTWARE AND COPYRIGHTS. Title to all copies of the Software remains with Intel or its suppliers. The Software is copyrighted and protected by the laws of the United States and other countries, and international treaty provisions. You may not remove any copyright notices from the Software. Intel may make changes to the Software, or to items referenced therein, at any time without notice, but is not obligated to support or update the Software. Except as otherwise expressly provided, Intel grants no express or implied right under Intel patents, copyrights, trademarks, or other intellectual property rights. You may transfer the Software only if the recipient agrees to be fully bound by these terms and if you retain no copies of the Software.
LIMITED MEDIA WARRANTY. If the Software has been delivered by Intel on physical media, Intel warrants the media to be free from material physical defects for a period of ninety days after delivery by Intel. If such a defect is found, return the media to Intel for replacement or alternate delivery of the Software as Intel may select.
EXCLUSION OF OTHER WARRANTIES. EXCEPT AS PROVIDED ABOVE, THE SOFTWARE IS PROVIDED "AS IS" WITHOUT ANY EXPRESS OR IMPLIED WARRANTY OF ANY KIND INCLUDING WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE. Intel does not warrant or assume responsibility for the accuracy or completeness of any information, text, graphics, links or other items contained within the Software.
LIMITATION OF LIABILITY. IN NO EVENT SHALL INTEL OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, OR LOST INFORMATION) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF INTEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME JURISDICTIONS PROHIBIT EXCLUSION OR LIMITATION OF LIABILITY FOR IMPLIED WARRANTIES OR CONSEQUENTIAL OR INCIDENTAL DAMAGES, SO THE ABOVE LIMITATION MAY NOT APPLY TO YOU. YOU MAY ALSO HAVE OTHER LEGAL RIGHTS THAT VARY FROM JURISDICTION TO JURISDICTION.
TERMINATION OF THIS AGREEMENT. Intel may terminate this Agreement at any time if you violate its terms. Upon termination, you will immediately destroy the Software or return all copies of the Software to Intel.
APPLICABLE LAWS. Claims arising under this Agreement shall be governed by the laws of California, excluding its principles of conflict of laws and the United Nations Convention on Contracts for the Sale of Goods. You may not export the Software in violation of applicable export laws and regulations. Intel is not obligated under any other agreements unless they are in writing and signed by an authorized representative of Intel.
GOVERNMENT RESTRICTED RIGHTS. The Software is provided with "RESTRICTED RIGHTS." Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor. Use of the Software by the Government constitutes acknowledgment of Intel's proprietary rights therein. Contractor or Manufacturer is Intel 2200 Mission College Blvd., Santa Clara, CA 95052.
Regards, Simon
Hi Simon,
sjg@google.com wrote on 12/05/2014 11:05:30 AM:
From: Simon Glass sjg@chromium.org To: Bruce_Leonard@selinc.com Cc: Bin Meng bmeng.cn@gmail.com, U-Boot Mailing List <u- boot@lists.denx.de>, u-boot-bounces@lists.denx.de Date: 12/05/2014 11:05 AM Subject: Re: [U-Boot] [PATCH 25/25] x86: Add a README.x86 for U-Boot on x86 support Sent by: sjg@google.com
Hi Bruce,
On 5 December 2014 at 11:34, Bruce_Leonard@selinc.com wrote:
Hi Simon, Bin,
u-boot-bounces@lists.denx.de wrote on 12/04/2014 04:03:54 PM:
From: Simon Glass sjg@chromium.org To: Bin Meng bmeng.cn@gmail.com Cc: U-Boot Mailing List u-boot@lists.denx.de Date: 12/04/2014 04:04 PM Subject: Re: [U-Boot] [PATCH 25/25] x86: Add a README.x86 for U-Boot on x86 support Sent by: u-boot-bounces@lists.denx.de
Hi Bin,
On 4 December 2014 at 08:04, Bin Meng bmeng.cn@gmail.com wrote:
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 123 ++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++
1 file changed, 123 insertions(+) create mode 100644 doc/README.x86
diff --git a/doc/README.x86 b/doc/README.x86 new file mode 100644 index 0000000..a79f510 --- /dev/null +++ b/doc/README.x86 @@ -0,0 +1,123 @@ +# +# Copyright (C) 2014, Simon Glass sjg@chromium.org +# Copyright (C) 2014, Bin Meng bmeng.cn@gmail.com +# +# SPDX-License-Identifier: GPL-2.0+ +#
+U-Boot on x86 +=============
Very nice!
This is all really great work.
I do have a question though, and if it's already been asked/answered
and I
missed the thread I apologize for the noise. Part of the reason we've
held
off on doing this project (other than resources of course :) ) wasa
concern
about licensing. U-boot is released under the GPL and we're worried
that by
linking in Intel's FSP we're creating a "derived work" that would then require Intel to release the source for the FSP, which they aren't
going to
do and would leave us open to law suits. Doing it by calls into an
opaque
blob can loosely be defined as a dynamically linked library and
therefore
fall under the GPL exception clause, but our legal department
considers that
a dangerous assumption on our part.
Has anyone considered this issue? I'm not a lawyer so I get lost in
the
legalize of licences pretty fast.
Thanks again for all the work.
Well if you a legal department, that's what you pay them for and they should be able to figure this out. Clearly if it were not permitted to use the binary blobs in open source software then the blobs wouldn't be very useful. But I'm not a lawyer either and am not qualified to provide legal advice! It would be useful if you could post what you find either way. And if for some reason there is a problem, we could take it up with Intel.
Thanks for the info. We were sort of hoping that either the u-boot community or Denx SE may have already addressed this. Probably what we'll have to do is get an Intel lawyer on the phone with a copy of both the GPL and the FSP licences and just go through them item by item. We'll feedback to the list what we find out.
Have a good weekend!
V/r Bruce
Hi Bruce,
On Sat, Dec 6, 2014 at 4:02 AM, Bruce_Leonard@selinc.com wrote:
Hi Simon,
sjg@google.com wrote on 12/05/2014 11:05:30 AM:
From: Simon Glass sjg@chromium.org To: Bruce_Leonard@selinc.com Cc: Bin Meng bmeng.cn@gmail.com, U-Boot Mailing List <u- boot@lists.denx.de>, u-boot-bounces@lists.denx.de Date: 12/05/2014 11:05 AM Subject: Re: [U-Boot] [PATCH 25/25] x86: Add a README.x86 for U-Boot on x86 support Sent by: sjg@google.com
Hi Bruce,
On 5 December 2014 at 11:34, Bruce_Leonard@selinc.com wrote:
Hi Simon, Bin,
u-boot-bounces@lists.denx.de wrote on 12/04/2014 04:03:54 PM:
From: Simon Glass sjg@chromium.org To: Bin Meng bmeng.cn@gmail.com Cc: U-Boot Mailing List u-boot@lists.denx.de Date: 12/04/2014 04:04 PM Subject: Re: [U-Boot] [PATCH 25/25] x86: Add a README.x86 for U-Boot on x86 support Sent by: u-boot-bounces@lists.denx.de
Hi Bin,
On 4 December 2014 at 08:04, Bin Meng bmeng.cn@gmail.com wrote:
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 123 ++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++
1 file changed, 123 insertions(+) create mode 100644 doc/README.x86
diff --git a/doc/README.x86 b/doc/README.x86 new file mode 100644 index 0000000..a79f510 --- /dev/null +++ b/doc/README.x86 @@ -0,0 +1,123 @@ +# +# Copyright (C) 2014, Simon Glass sjg@chromium.org +# Copyright (C) 2014, Bin Meng bmeng.cn@gmail.com +# +# SPDX-License-Identifier: GPL-2.0+ +#
+U-Boot on x86 +=============
Very nice!
This is all really great work.
I do have a question though, and if it's already been asked/answered and I missed the thread I apologize for the noise. Part of the reason we've held off on doing this project (other than resources of course :) ) wasa concern about licensing. U-boot is released under the GPL and we're worried that by linking in Intel's FSP we're creating a "derived work" that would then require Intel to release the source for the FSP, which they aren't going to do and would leave us open to law suits. Doing it by calls into an opaque blob can loosely be defined as a dynamically linked library and therefore fall under the GPL exception clause, but our legal department considers that a dangerous assumption on our part.
Has anyone considered this issue? I'm not a lawyer so I get lost in the legalize of licences pretty fast.
Thanks again for all the work.
Well if you a legal department, that's what you pay them for and they should be able to figure this out. Clearly if it were not permitted to use the binary blobs in open source software then the blobs wouldn't be very useful. But I'm not a lawyer either and am not qualified to provide legal advice! It would be useful if you could post what you find either way. And if for some reason there is a problem, we could take it up with Intel.
Thanks for the info. We were sort of hoping that either the u-boot community or Denx SE may have already addressed this. Probably what we'll have to do is get an Intel lawyer on the phone with a copy of both the GPL and the FSP licences and just go through them item by item. We'll feedback to the list what we find out.
Have a good weekend!
V/r Bruce
Actually coreboot supports Intel FSP as well on several other platforms already. There was once a thread talking about integrating FSP which might be helpful on your questions. Check it out @ http://www.coreboot.org/pipermail/coreboot/2013-December/076801.html. Looks Intel is OK to have coreboot to integrate the FSP binary blobs in the coreboot source tree, but coreboot maintainers don't do that.
Regards, Bin
Hi!
+Status +------ +U-Boot supports running as a coreboot [1] payload on x86. So far only link +(Chromebook pixel) has been tested, but it should work with minimal adjustments
Link is codeword for Chromebook Pixel? I'd write "Chromebook Pixel (Link)" if so.
+on other x86 boards since coreboot deals with most of the low-level details.
+U-Boot also supports booting directly from x86 reset vector without coreboot, +aka raw support or bare support. Currently Google Chromebook link and Intel
Should this me "Chromebook Pixel"?
+Building rom version U-Boot (hereafter referred to as u-boot.rom) is a little
"ROM version of" ?
+bit tricky, as generally it requires several binary blobs which are not shipped +in the U-Boot source tree. Due to this reason, the u-boot.rom build is not +turned on by default in the U-Boot source tree. Firstly, you need turn it on +by uncommenting the following line in the main U-Boot Makefile:
+# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+Google Chromebook link specific instructions:
"link -> Pixel"?
+Firstly, you need the following binary blobs:
Firstly->First
+You can get these binary blobs by:
+$ git clone http://review.coreboot.org/p/blobs.git +$ cd blobs
+Find the following files:
+* ./mainboard/google/link/descriptor.bin +* ./mainboard/google/link/me.bin +* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin
+The 3rd one should be renamed to mrc.bin.
Should there be instruction where to put those files? Perhaps a script doing this and getting ROM would be nice?
+As for the video ROM, you can get it here [2].
+Now you can build U-Boot and obtain u-boot.rom:
+$ make chromebook_link_defconfig +$ make all
+Intel Crown Bay specific instructions:
+U-Boot support of Intel Crown Bay board [3] relies on a binary blob called +Firmware Support Package [4] to perform all the necessary initialization steps +as documented in the BIOS Writer Guide including initialization of the CPU,
"Guide, "
+Downalod the Intel FSP for Atom E6xx series and Platform Controller
-> Download.
Thanks, Pavel
Hi Pavel,
On Tue, Dec 16, 2014 at 6:34 AM, Pavel Machek pavel@denx.de wrote:
Hi!
+Status +------ +U-Boot supports running as a coreboot [1] payload on x86. So far only link +(Chromebook pixel) has been tested, but it should work with minimal adjustments
Link is codeword for Chromebook Pixel? I'd write "Chromebook Pixel (Link)" if so.
+on other x86 boards since coreboot deals with most of the low-level details.
+U-Boot also supports booting directly from x86 reset vector without coreboot, +aka raw support or bare support. Currently Google Chromebook link and Intel
Should this me "Chromebook Pixel"?
+Building rom version U-Boot (hereafter referred to as u-boot.rom) is a little
"ROM version of" ?
+bit tricky, as generally it requires several binary blobs which are not shipped +in the U-Boot source tree. Due to this reason, the u-boot.rom build is not +turned on by default in the U-Boot source tree. Firstly, you need turn it on +by uncommenting the following line in the main U-Boot Makefile:
+# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+Google Chromebook link specific instructions:
"link -> Pixel"?
+Firstly, you need the following binary blobs:
Firstly->First
+You can get these binary blobs by:
+$ git clone http://review.coreboot.org/p/blobs.git +$ cd blobs
+Find the following files:
+* ./mainboard/google/link/descriptor.bin +* ./mainboard/google/link/me.bin +* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin
+The 3rd one should be renamed to mrc.bin.
Should there be instruction where to put those files? Perhaps a script doing this and getting ROM would be nice?
+As for the video ROM, you can get it here [2].
+Now you can build U-Boot and obtain u-boot.rom:
+$ make chromebook_link_defconfig +$ make all
+Intel Crown Bay specific instructions:
+U-Boot support of Intel Crown Bay board [3] relies on a binary blob called +Firmware Support Package [4] to perform all the necessary initialization steps +as documented in the BIOS Writer Guide including initialization of the CPU,
"Guide, "
+Downalod the Intel FSP for Atom E6xx series and Platform Controller
-> Download.
Most issues fixed in the v4 patch @ http://patchwork.ozlabs.org/patch/422203/, except the Chromebook Pixel (link) issue which will need Simon to comment.
Regards, Bin
Hi Pavel,
On 15 December 2014 at 15:34, Pavel Machek pavel@denx.de wrote:
Hi!
+Status +------ +U-Boot supports running as a coreboot [1] payload on x86. So far only link +(Chromebook pixel) has been tested, but it should work with minimal adjustments
Link is codeword for Chromebook Pixel? I'd write "Chromebook Pixel (Link)" if so.
+on other x86 boards since coreboot deals with most of the low-level details.
+U-Boot also supports booting directly from x86 reset vector without coreboot, +aka raw support or bare support. Currently Google Chromebook link and Intel
Should this me "Chromebook Pixel"?
Yes we should either say 'Chromebook Pixel' or link. I will tidy this up when applying.
+Building rom version U-Boot (hereafter referred to as u-boot.rom) is a little
"ROM version of" ?
+bit tricky, as generally it requires several binary blobs which are not shipped +in the U-Boot source tree. Due to this reason, the u-boot.rom build is not +turned on by default in the U-Boot source tree. Firstly, you need turn it on +by uncommenting the following line in the main U-Boot Makefile:
+# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+Google Chromebook link specific instructions:
"link -> Pixel"?
+Firstly, you need the following binary blobs:
Firstly->First
+You can get these binary blobs by:
+$ git clone http://review.coreboot.org/p/blobs.git +$ cd blobs
+Find the following files:
+* ./mainboard/google/link/descriptor.bin +* ./mainboard/google/link/me.bin +* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin
+The 3rd one should be renamed to mrc.bin.
Should there be instruction where to put those files? Perhaps a script doing this and getting ROM would be nice?
+As for the video ROM, you can get it here [2].
+Now you can build U-Boot and obtain u-boot.rom:
+$ make chromebook_link_defconfig +$ make all
+Intel Crown Bay specific instructions:
+U-Boot support of Intel Crown Bay board [3] relies on a binary blob called +Firmware Support Package [4] to perform all the necessary initialization steps +as documented in the BIOS Writer Guide including initialization of the CPU,
"Guide, "
+Downalod the Intel FSP for Atom E6xx series and Platform Controller
-> Download.
Regards, Simon
participants (4)
-
Bin Meng -
Bruce_Leonard＠selinc.com -
Pavel Machek -
Simon Glass