| Message ID | 1439382002-8054-1-git-send-email-igor.stoppa@intel.com |
|---|---|
| State | Accepted |
| Delegated to: | Simon Glass |
| Headers | show |
Hi Igor, On Wed, Aug 12, 2015 at 8:20 PM, Igor Stoppa <igor.stoppa@intel.com> wrote: > Explicitly list the targets supported in each section of the instructions > from the x86 README. > Nits: we should put tags in the patch/commit title, eg: x86: Add clarifications to the x86 README > Signed-off-by: Igor Stoppa <igor.stoppa@intel.com> > --- > doc/README.x86 | 17 ++++++++++------- > 1 file changed, 10 insertions(+), 7 deletions(-) > > diff --git a/doc/README.x86 b/doc/README.x86 > index af2459c..1105afe 100644 > --- a/doc/README.x86 > +++ b/doc/README.x86 > @@ -19,14 +19,15 @@ 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 Link, QEMU x86 targets and all > -Intel boards support running U-Boot 'bare metal'. > +aka raw support or bare support. U-Boot becomes a replacement for the BIOS. > +Currently Link, QEMU x86 targets and all Intel boards support running U-Boot > +'bare metal'. > > As for loading an 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 > ------------------- > +Build Instructions for U-Boot as coreboot payload > +------------------------------------------------- > Building U-Boot as a coreboot payload is just like building U-Boot for targets > on other architectures, like below: > > @@ -48,6 +49,8 @@ Change the 'Board configuration file' and 'Board Device Tree Source (dts) file' > to point to a new board. You can also change the Cache-As-RAM (CAR) related > settings here if the default values do not fit your new board. > > +Build Instructions for U-Boot as BIOS replacement (raw/bare mode) > +----------------------------------------------------------------- > Building a ROM version of 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 > @@ -87,7 +90,7 @@ Now you can build U-Boot and obtain u-boot.rom: > $ make chromebook_link_defconfig > $ make all > > -Intel Crown Bay specific instructions: > +Intel Crown Bay specific instructions (raw mode): I think we don't need add (raw mode) as you already added a section header above. > > U-Boot support of Intel Crown Bay board [4] relies on a binary blob called > Firmware Support Package [5] to perform all the necessary initialization steps > @@ -122,7 +125,7 @@ Now you can build U-Boot and obtain u-boot.rom > $ make crownbay_defconfig > $ make all > > -Intel Minnowboard Max instructions: > +Intel Minnowboard Max instructions (raw mode): Ditto. > > This uses as FSP as with Crown Bay, except it is for the Atom E3800 series. > Download this and get the .fd file (BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd at > @@ -189,7 +192,7 @@ Offset Description Controlling config > Overall ROM image size is controlled by CONFIG_ROM_SIZE. > > > -Intel Galileo instructions: > +Intel Galileo instructions (raw mode): Ditto. > > Only one binary blob is needed for Remote Management Unit (RMU) within Intel > Quark SoC. Not like FSP, U-Boot does not call into the binary. The binary is > -- Regards, Bin
Hi Igor, On 12 August 2015 at 07:27, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Igor, > > On Wed, Aug 12, 2015 at 8:20 PM, Igor Stoppa <igor.stoppa@intel.com> wrote: >> Explicitly list the targets supported in each section of the instructions >> from the x86 README. >> > > Nits: we should put tags in the patch/commit title, eg: > > x86: Add clarifications to the x86 README > >> Signed-off-by: Igor Stoppa <igor.stoppa@intel.com> >> --- >> doc/README.x86 | 17 ++++++++++------- >> 1 file changed, 10 insertions(+), 7 deletions(-) >> >> diff --git a/doc/README.x86 b/doc/README.x86 >> index af2459c..1105afe 100644 >> --- a/doc/README.x86 >> +++ b/doc/README.x86 >> @@ -19,14 +19,15 @@ 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 Link, QEMU x86 targets and all >> -Intel boards support running U-Boot 'bare metal'. >> +aka raw support or bare support. U-Boot becomes a replacement for the BIOS. >> +Currently Link, QEMU x86 targets and all Intel boards support running U-Boot >> +'bare metal'. >> >> As for loading an 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 >> ------------------- >> +Build Instructions for U-Boot as coreboot payload >> +------------------------------------------------- >> Building U-Boot as a coreboot payload is just like building U-Boot for targets >> on other architectures, like below: >> >> @@ -48,6 +49,8 @@ Change the 'Board configuration file' and 'Board Device Tree Source (dts) file' >> to point to a new board. You can also change the Cache-As-RAM (CAR) related >> settings here if the default values do not fit your new board. >> >> +Build Instructions for U-Boot as BIOS replacement (raw/bare mode) >> +----------------------------------------------------------------- >> Building a ROM version of 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 >> @@ -87,7 +90,7 @@ Now you can build U-Boot and obtain u-boot.rom: >> $ make chromebook_link_defconfig >> $ make all >> >> -Intel Crown Bay specific instructions: >> +Intel Crown Bay specific instructions (raw mode): > > I think we don't need add (raw mode) as you already added a section > header above. I prefer 'bare mode' to 'raw mode'. It suggests that U-Boot is running on the bare metal. Perhaps we should drop the word 'raw' and use 'bare' instead, for consistency? > >> >> U-Boot support of Intel Crown Bay board [4] relies on a binary blob called >> Firmware Support Package [5] to perform all the necessary initialization steps >> @@ -122,7 +125,7 @@ Now you can build U-Boot and obtain u-boot.rom >> $ make crownbay_defconfig >> $ make all >> >> -Intel Minnowboard Max instructions: >> +Intel Minnowboard Max instructions (raw mode): > > Ditto. > >> >> This uses as FSP as with Crown Bay, except it is for the Atom E3800 series. >> Download this and get the .fd file (BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd at >> @@ -189,7 +192,7 @@ Offset Description Controlling config >> Overall ROM image size is controlled by CONFIG_ROM_SIZE. >> >> >> -Intel Galileo instructions: >> +Intel Galileo instructions (raw mode): > > Ditto. > >> >> Only one binary blob is needed for Remote Management Unit (RMU) within Intel >> Quark SoC. Not like FSP, U-Boot does not call into the binary. The binary is >> -- > > Regards, > Bin Regards, Simon
Hi Bin, On 12 August 2015 at 16:27, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Igor, > > On Wed, Aug 12, 2015 at 8:20 PM, Igor Stoppa <igor.stoppa@intel.com> wrote: >> Explicitly list the targets supported in each section of the instructions >> from the x86 README. >> > > Nits: we should put tags in the patch/commit title, eg: > > x86: Add clarifications to the x86 README ok, will fix it [...] >> -Intel Crown Bay specific instructions: >> +Intel Crown Bay specific instructions (raw mode): > > I think we don't need add (raw mode) as you already added a section > header above. This was intentional. You are absolutely right that it's redundant, but I was trying to make the doc more friendly toward someone (like yours truly :-) who approaches it for the first time. Reading it, sometimes I had the feeling I wasn't 100% sure of what a certain section was referring to. Some sections are not exactly short. But if you still think it should be removed, I'll do so.
Hi Simon, On 12 August 2015 at 16:31, Simon Glass <sjg@chromium.org> wrote: > I prefer 'bare mode' to 'raw mode'. It suggests that U-Boot is running > on the bare metal. Perhaps we should drop the word 'raw' and use > 'bare' instead, for consistency? Yes, I could do it for the entire doc, if this is what you are suggesting. Also from a new reader's perspective, referring to the same thing by using 2 names can be confusing.
Hi Igor, On Wed, Aug 12, 2015 at 9:40 PM, Stoppa, Igor <igor.stoppa@intel.com> wrote: > Hi Bin, > > On 12 August 2015 at 16:27, Bin Meng <bmeng.cn@gmail.com> wrote: >> Hi Igor, >> >> On Wed, Aug 12, 2015 at 8:20 PM, Igor Stoppa <igor.stoppa@intel.com> wrote: >>> Explicitly list the targets supported in each section of the instructions >>> from the x86 README. >>> >> >> Nits: we should put tags in the patch/commit title, eg: >> >> x86: Add clarifications to the x86 README > > ok, will fix it > > [...] > >>> -Intel Crown Bay specific instructions: >>> +Intel Crown Bay specific instructions (raw mode): >> >> I think we don't need add (raw mode) as you already added a section >> header above. > > This was intentional. You are absolutely right that it's redundant, > but I was trying to make the doc more friendly toward someone (like > yours truly :-) who approaches it for the first time. > Reading it, sometimes I had the feeling I wasn't 100% sure of what a > certain section was referring to. I am OK, Simon? > > Some sections are not exactly short. > > But if you still think it should be removed, I'll do so. > Regards, Bin
Hi, On 12 August 2015 at 07:59, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Igor, > > On Wed, Aug 12, 2015 at 9:40 PM, Stoppa, Igor <igor.stoppa@intel.com> wrote: >> Hi Bin, >> >> On 12 August 2015 at 16:27, Bin Meng <bmeng.cn@gmail.com> wrote: >>> Hi Igor, >>> >>> On Wed, Aug 12, 2015 at 8:20 PM, Igor Stoppa <igor.stoppa@intel.com> wrote: >>>> Explicitly list the targets supported in each section of the instructions >>>> from the x86 README. >>>> >>> >>> Nits: we should put tags in the patch/commit title, eg: >>> >>> x86: Add clarifications to the x86 README >> >> ok, will fix it >> >> [...] >> >>>> -Intel Crown Bay specific instructions: >>>> +Intel Crown Bay specific instructions (raw mode): >>> >>> I think we don't need add (raw mode) as you already added a section >>> header above. >> >> This was intentional. You are absolutely right that it's redundant, >> but I was trying to make the doc more friendly toward someone (like >> yours truly :-) who approaches it for the first time. >> Reading it, sometimes I had the feeling I wasn't 100% sure of what a >> certain section was referring to. > > I am OK, Simon? Yes. > >> >> Some sections are not exactly short. >> >> But if you still think it should be removed, I'll do so. >> > > Regards, > Bin Regards, Simon
diff --git a/doc/README.x86 b/doc/README.x86 index af2459c..1105afe 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -19,14 +19,15 @@ 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 Link, QEMU x86 targets and all -Intel boards support running U-Boot 'bare metal'. +aka raw support or bare support. U-Boot becomes a replacement for the BIOS. +Currently Link, QEMU x86 targets and all Intel boards support running U-Boot +'bare metal'. As for loading an 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 ------------------- +Build Instructions for U-Boot as coreboot payload +------------------------------------------------- Building U-Boot as a coreboot payload is just like building U-Boot for targets on other architectures, like below: @@ -48,6 +49,8 @@ Change the 'Board configuration file' and 'Board Device Tree Source (dts) file' to point to a new board. You can also change the Cache-As-RAM (CAR) related settings here if the default values do not fit your new board. +Build Instructions for U-Boot as BIOS replacement (raw/bare mode) +----------------------------------------------------------------- Building a ROM version of 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 @@ -87,7 +90,7 @@ Now you can build U-Boot and obtain u-boot.rom: $ make chromebook_link_defconfig $ make all -Intel Crown Bay specific instructions: +Intel Crown Bay specific instructions (raw mode): U-Boot support of Intel Crown Bay board [4] relies on a binary blob called Firmware Support Package [5] to perform all the necessary initialization steps @@ -122,7 +125,7 @@ Now you can build U-Boot and obtain u-boot.rom $ make crownbay_defconfig $ make all -Intel Minnowboard Max instructions: +Intel Minnowboard Max instructions (raw mode): This uses as FSP as with Crown Bay, except it is for the Atom E3800 series. Download this and get the .fd file (BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd at @@ -189,7 +192,7 @@ Offset Description Controlling config Overall ROM image size is controlled by CONFIG_ROM_SIZE. -Intel Galileo instructions: +Intel Galileo instructions (raw mode): Only one binary blob is needed for Remote Management Unit (RMU) within Intel Quark SoC. Not like FSP, U-Boot does not call into the binary. The binary is
Explicitly list the targets supported in each section of the instructions from the x86 README. Signed-off-by: Igor Stoppa <igor.stoppa@intel.com> --- doc/README.x86 | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)