What a mess, Good Lord!

I am not entirely sure what you are trying to do, all of you trying to use IFWI, then Coreboot, and them U-boot. It seems to me way overkill, used for some academical purposes (as I managed to run Virtual Box VMM on Fedora VM, on the top of Virtual Box VMM on Fedora VM, on the top of VMWare Workstation, on WIN10 64). Three nested VMMs inside each other? What for (the purpose was to learn setup, and nothing more)?!

Here is what I found on the net: https://github.com/al177/edbian/wiki/edison_boot_n_dfu

Important points: IFWI is the Intel FirmWare Interface, a binary blob loaded from the eMMC boot partition that executes a secondary loader from the main eMMC. IFWI blobs for the APL-I are provided by Intel and are specific for different flavors of the MID silicon.

In this lieu, what is written here, the following is my proposal (as stated in the article):

Normal IFWI eMMC boot process

  1. On-chip boot rom inits eMMC and loads IFWI from the MMC boot partitions
  2. IFWI looks for OSIP header at top of eMMC (MBR boot block)
  3. The header directs IFWI to the start, size, load address, and entry of U-Boot in eMMC
  4. (need clarification) If u-boot is not found, try the alt u-boot image at 5MB into the eMMC
  5. U-Boot is loaded into RAM and executed
For you all, OSIP stands for OS Image Profile, and it is nothing more and less than INTEL name for very known old fashion MBR, considering DATA structure (INTEL always tend to complicate, in order to intimidate customers and force them to obey to some phony philosophy, thus making customers very dependent for the stuff which are normal and relative simplistic).

# This is what a full OSIP header contains
    # Its size is 512 bytes
    # Offset   Size (bytes) Description
    # 0x000       4         OSIP Signature "$OS$"
    # 0x004       1         Reserved
    # 0x005       1         Header minor revision
    # 0x006       1         Header major revision
    # 0x007       1         Header checksum
    # 0x008       1         Number of pointers
    # 0x009       1         Number of images
    # 0x00a       2         Header size
    # 0x00c      20         Reserved
    # 0x020      24         1st bootable image descriptor (OSII)
    # 0x038      24         2nd bootable image descriptor (OSII)
    # ...       ...         ...
    # 0x170      24         15th bootable image descriptor (OSII)
    # 0x188      48         Not used
    # 0x1B8       4         Disk signature
    # 0x1BC       2         Null (0x0000)
    # 0x1BE      16         1st primary partition descriptor
    # 0x1CE      16         2nd primary partition descriptor
    # 0x1DE      16         3rd primary partition descriptor
    # 0x1EE      16         4th primary partition descriptor
    # 0x1FE       1         0x55
    # 0x1FF       1         0xaa

Ron (Minnich), you are added to this email, since I finally start understanding from where you are coming from (I needed two years, really to clear some obstacles)! ;-)

For the rest, someone can, while using APL-I with Coreboot, and U-Boot as payload, simply skip the Coreboot phase and make his/her life much easier!

Said that, you can all conclude what is actually IFWI, and that the FSP blob is actually redundant, Coreboot is seconday bootloader in this case. Either use Coreboot, either U-boot, you do not need both!

IMHO.

Best Regards,
Zoran Stojsavljevic
_______

On Thu, Sep 28, 2017 at 6:13 PM, Cameron Craig <Cameron.Craig@exterity.com> wrote:

Hi Zoran,

 

Thanks for the advice, I had a glimpse at your config and noticed a few differences:

-You target CONFIG_BOARD_INTEL_APOLLOLAKE_RVP2 rather than CONFIG_BOARD_INTEL_LEAFHILL. Insignificant I think.

-You include a TXE blob, I do not. This may be quite significant! I have tried including a TXE blob, only to be presented with an error (txe_error.txt)

 

Once I get the FIT tool going I may be able to enable the Intel ME region and fix that error.

 

Cheers,

Cameron

   

From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com]
Sent: 27 September 2017 20:11
To: Cameron Craig; Martin Roth
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

 

Since I really want to help, and I do not have any time left for Coreboot (since I am fully/200% devoted to Fedora/RHEL/kernel.org and YOCTO), three kludge thinking from me (APL-I supposed to be my get_to_the_rich_pals_vehicle in Y2015, but mortally crashed somewhere in the process - For Good)!:

 

[1] I did assemble APL-I Coreboot based upon www.intel.com/fsp (please, choose APL-I FSP release) APL-I FSP blobs. I did at the very end very clean compilation, but there are two catches 22 to what I did (significant credits/courtesy to Martin Roth, Martin really pulled me up and survived me in this weird FSP 2.0 crazy business of INTEL's)... ;-)

     [A] The Coreboot release I played with is: [user@localhost coreboot]$ git describe ==>> 4.5-1029-g97535558f1 (NOT 4.6);

     [B] Never tested it on real HW, I do NOT have APL-I HW, Leaf Hill, Deaf Hill or you name it... But I did attach my .config/CONFIG!

[2] As my .config (attached CONFIG) suggests, please, try with some other payload (SeaBIOS as for example, which I used);

[3] You need to compare my .config with yours (I have neither any time, neither any desire to do this).

 

Good Luck, very much/totally INTEL 2.0 FSP (doomed to the bones) dependent enthusiast (I can still advise out of desperation, if you investigate and continue posting results here).

 

P.S. Martin (Roth), once again, thank you for unselfish help (I do remember)! :-)

 

Zoran

_______

 

On Wed, Sep 27, 2017 at 2:01 PM, Cameron Craig <Cameron.Craig@exterity.com> wrote:

Hi All,

 

I’m currently trying to get coreboot working on an Intel Leaf Hill development board, we are using U-Boot as a payload.

 

I have managed to create a bootable image using an out of date copy of coreboot and U-Boot, provided by Intel under NDA.

The stitching process used to generate the image is a little ugly: a set of Windows tools are provided (or pointed at) by Intel to stitch the various blobs together to create an 8MB image.

We would like to move away from this process. Using the cbfs tool it looks like we are getting a legacy image composed entirely of a single CBFS.

 

However, as far as I understand, the latest coreboot release (v4.6) should be capable of producing a 16MB working image without the use of external tools.

This is of course dependent on the provision of the correct binary blobs such as the FSP, flash descriptor and IFWI.

I have attached the descriptor of the IFWI image being used.

   

This is the process I have followed in order to generate a coreboot image:

1.       Clone coreboot (v4.6)

2.       Obtain Apollo Lake FSP from Intel (https://github.com/IntelFSP/FSP)

3.       Split FSP into its constituent parts (https://raw.githubusercontent.com/tianocore/edk2/master/IntelFsp2Pkg/Tools/SplitFspBin.py)

4.       Extract Flash Descriptor from an existing Leaf Hill UEFI image (./ifdtool --extract leaf_hill_ref_board_uefi.bin)

5.       Obtain IFWI image from Intel (Apollo Lake Technical Library)

6.       make menuconfig (config file is attached)

a.       Mainboard

                                                               i.      Mainboard vendor (Intel)

                                                             ii.      Mainboard model (Leafhill)

                                                            iii.      [*] Use IFWI Stitching

                                                           iv.      (IFWI) section in .fmd file to place IFWI blob

                                                             v.      (IFWI_SPI.bin) Path to image coming from FIT Tool

                                                           vi.      (descriptor.bin) path to descriptor.bin

                                                          vii.      (Fsp_M.fd) path to FSP-M.Fv blob

                                                        viii.      (Fsp_S.fd) path to FSP-S.Fv

b.      Payload

                                                               i.      Add a payload (U-Boot (Experimental))

                                                             ii.      U-Boot version (v2016.1)

                                                            iii.      (coreboot-x86_defconfig) U-Boot config file

c.       The rest are at Leaf Hill defaults.

7.       make

8.       Flash image to Leaf Hill SPI flash

 

As far as I can tell, this process should produce a working image.

However it does not. My most recent attempt has managed to blink the PWR_OK LED, suggesting the PMIC/PMC is working, but no serial messages.

Other than that, I currently have no working theories as to what the root cause is L

 

Is there anything obviously wrong with this process?

Are there any bugs that I should be aware of relating to coreboot on an Apollo Lake platform?

I haven’t found a lot of documentation online to describe the exact configuration and blob usage, are there any relevant sources of documentation you could point me towards?

 

Any help to answer the above, or any other advice would be greatly appreciated.

 

Cheers,

Cameron

 

Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:    
e: Cameron.Craig@exterity.com | w: www.exterity.com   

 

ISO9001

LinkedIn

Twitter

YouTube


Exterity is a leading provider of IP Video and Digital Signage solutions that helps organizations to harness the power of video to communicate, educate and entertain. Our end-to-end solutions enable you to take TV and video content directly from any source and manage its delivery, live or on demand, to any connected device via your existing network. For more information or to schedule a product demonstration, contact Exterity on +44(0)1383 828 250 or visit www.exterity.com

Legal Notice
Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.

Exterity Limited is registered in Scotland under No. 225313 with its registered office at St Davids House, St Davids Drive, Dalgety Bay, KY11 9NB


 

Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:    
e: Cameron.Craig@exterity.com | w: www.exterity.com   

 


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

 


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________