[U-Boot,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

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-platforms/atom-e660-eg20t-development-kit.html
> +[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-support-package/intel-fsp-overview.html

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