Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Zoran Stojsavljevic]

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 
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:[e-mail]]
> *Sent:* 27 September 2017 20:11
> *To:* Cameron Craig; Martin Roth
> *Cc:* [e-mail]
> *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 
> 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:
>   Clone coreboot (v4.6)
>
>   Obtain Apollo Lake FSP from Intel (https://github.com/IntelFSP/
>
> FSP)
>   Split FSP into its constituent parts (https://raw.
>
> githubusercontent.com/tianocore/edk2/master/IntelFsp2Pkg/Tools/
> SplitFspBin.py)
>   Extract Flash Descriptor from an existing Leaf Hill UEFI image
>
> (./ifdtool --extract leaf_hill_ref_board_uefi.bin)
>   Obtain IFWI image from Intel (Apollo Lake Technical Library)
>
>   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.
>   make
>
>   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: [phone] <+44%201383%20828250> | fax:
> e: [e-mail] | w: www.exterity.com
>
> http://www.exterity.com
>
> [image: ISO9001] http://www.exterity.com/iso9001
>
> [image: LinkedIn] http://www.linkedin.com/company/exterity
>
> [image: Twitter] http://www.twitter.com/exterity
>
> [image: YouTube] http://www.youtube.com/user/exterityiptv
>
> 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 <+44%201383%20828250> 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: [phone] <+44%201383%20828250> | fax:
> e: [e-mail] | 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
> ______________________________________________________________________
>
> 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
> ______________________________________________________________________