Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Cameron Craig]

Hi Tahnia,

> I am unfortunately not able to help you, since I myself am still new to 
> coreboot (and to BIOS development in general).
No worries, we'll get there eventually :)

> When you ran the Intel-provided version (stitched with the Windows tool), did 
> you experience any similar problems with the USB controller in U-Boot? If so, 
> did you manage to solve it?
We are looking at this at the moment. Early investigation suggests that U-Boot 
needs a device tree for Leaf Hill. Without that, U-Boot isn't aware of ant USB 
controllers, SPI Flash, PCI devices or anything.
That's all I know at the moment, you might be better asking in the U-Boot 
mailing list.

Unfortunately it looks like Intel don't bother providing a device tree for 
Leafhill. So we may end up writing our own, which I hear is a bit pernickety.

Cheers,
Cameron


Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:  | mobile:
e: cameron.cr...@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

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Tahnia Lichtenstein]

Hi Cameron,

I am unfortunately not able to help you, since I myself am still new to
coreboot (and to BIOS development in general).

However, I have also tried to produce a bootable image with the outdated
Intel provided release of coreboot and U-Boot for Leafhill. The image does
run, but U-Boot cannot start the USB controller, so I cannot load an OS
(Yocto, in this case) via USB. When I run the U-Boot "usb start" command,
it says "No controllers found".

When you ran the Intel-provided version (stitched with the Windows tool),
did you experience any similar problems with the USB controller in U-Boot?
If so, did you manage to solve it?

I am not sure where to start debugging this problem! I tried to build
U-Boot myself and changed the U-Boot configuration to include USB
controllers (which is disabled in the config provided by the Intel patch),
but this produced a lot of "redeclaration of symbols" warnings and made no
difference to what I see in run-time. (Modified config attached).

Like Peter said earlier... "Firmware development is lots of fun! :)"

Best regards,
Tahnia




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:
>
> 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 

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Paul Penz]

Hi Cameron,

I don’t think that the „boot performance“ is our issues. I understand section 
3.5.4 that it would be very slow, but does not hang.
My console log is very similar to yours, but I have additional a post code 
logger and see after the 0x93 some postcodes from the FSP:

34 92 00 02 7F 10 00 50 7F
30s pause (FSP_M)
00 2F 98 13 79 39 80 70 71 93
FSP_S:
00 0F 31 36 61 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 7F 30 31 36 0E 12 37

I opened an intel support case and hope they could help.

Regards,
Paul

Von: Cameron Craig [mailto:cameron.cr...@exterity.com]
Gesendet: Dienstag, 3. Oktober 2017 17:52
An: Paul Penz; 'coreboot@coreboot.org'
Betreff: RE: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi all,

I have enabled post codes and all the debug config options in coreboot that 
looked useful.

As Paul has already done, I have narrowed down the latest issue to the 
FspSiliconInit() stage (FSP-S).
The 0x93 post code is the last message I get on the serial console, and 
signifies that FspSiliconInit() has started but not completed.
See 
(https://github.com/coreboot/coreboot/blob/master/src/include/console/post_codes.h).

I have attached the full serial log.

I can’t see how the actual FSP blob could be at fault here.

I don’t know if this is of help, but I came across this document:
https://github.com/IntelFsp/FSP/raw/ApolloLake/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf

Specifically section 3.5.4:
“It is expected that boot loader will program MTRRs for SBSP as needed after 
TempRamExit but before entering FspSiliconInit. If MTRRs are not programmed 
properly, the boot performance might be impacted.”

This “boot performance” may be part of the issue?

Any thoughts would be appreciated, this mailing list has been helpful so far!

Cheers,
Cameron




Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:
e: cameron.cr...@exterity.com<mailto:cameron.cr...@exterity.com> | w: 
www.exterity.com<http://www.exterity.com>



From: Cameron Craig
Sent: 02 October 2017 11:19
To: Cameron Craig; 'Paul Penz'; 
coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: RE: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Paul,

Those changes to the IFWI blob worked great, thanks!
I have attached the serial console log. It looks like we are in similar 
situations now.

I got a hang of around 45s at “MRC: region file invalid in 'RW_VAR_MRC_CACHE”,
and then it hangs indefinitely at the end of the log.

I tracked the MRC cache message down to this line:
https://github.com/coreboot/coreboot/blob/master/src/soc/intel/common/mrc_cache.c#L272

I’m stuck again for the moment. Thanks again Paul for getting me one step 
closer.

Cheers,
Cameron

From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Cameron Craig
Sent: 28 September 2017 16:51
To: 'Paul Penz'; coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Paul,

Great to hear I’m not the only one in this situation ☺

I’ve just been using the IWFI file from Intel with no modifications,  so I’ll 
look out the FIT tool and give that a go.

Thanks,
Cameron




Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:
e: cameron.cr...@exterity.com<mailto:cameron.cr...@exterity.com> | w: 
www.exterity.com<http://www.exterity.com>


From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Paul Penz
Sent: 28 September 2017 15:35
To: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Cameron,

I had the same problem.

Had you modified the intel IFWI file ?

If not, I had done this additional:

Download 522538_apl txe hf 3.0.11.1131 (th2 & rs1).zip from intel
Start fit.exe
Load the IFWI file
Change at Platform Protection/Platform Integrity OOEM Public Key Hash => 00..00
Change at Platform Protection/Boot Guard Configuration/ Boot profile 2 => 0
Save

Now I get output on the console and postcodes, but during FSP_M a long pause of 
ca. 45s exists and it hangs later during FSP_P initialization.

Good luck
Paul



Paul Penz
Dipl.-Ing. (FH)
Senior Hardware Engineer

ELTEC Elektronik AG, Mainz
_

Fon  +49 6131 918 335
Fax  +49 6131 918 195
Email   pp...@eltec.de<mailto:pp...@eltec.de>
Web www.eltec.de<http://www.eltec.de/>




*
ELTEC Elektronik AG
Galileo-Galilei-Straße 11
D-55129 Mainz

Vorstand: Peter Albert
Aufsichtsratsvorsitzender: Andreas Kochhäuser

Registergericht: Amtsgericht Mainz
Registernummer: HRB 7038
Ust-ID: DE 149 049 790
*
Wichtiger Hinweis:
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige 
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Cameron Craig]

Hi all,

I have enabled post codes and all the debug config options in coreboot that 
looked useful.

As Paul has already done, I have narrowed down the latest issue to the 
FspSiliconInit() stage (FSP-S).
The 0x93 post code is the last message I get on the serial console, and 
signifies that FspSiliconInit() has started but not completed.
See 
(https://github.com/coreboot/coreboot/blob/master/src/include/console/post_codes.h).

I have attached the full serial log.

I can’t see how the actual FSP blob could be at fault here.

I don’t know if this is of help, but I came across this document:
https://github.com/IntelFsp/FSP/raw/ApolloLake/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf

Specifically section 3.5.4:
“It is expected that boot loader will program MTRRs for SBSP as needed after 
TempRamExit but before entering FspSiliconInit. If MTRRs are not programmed 
properly, the boot performance might be impacted.”

This “boot performance” may be part of the issue?

Any thoughts would be appreciated, this mailing list has been helpful so far!

Cheers,
Cameron




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




From: Cameron Craig
Sent: 02 October 2017 11:19
To: Cameron Craig; 'Paul Penz'; coreboot@coreboot.org
Subject: RE: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Paul,

Those changes to the IFWI blob worked great, thanks!
I have attached the serial console log. It looks like we are in similar 
situations now.

I got a hang of around 45s at “MRC: region file invalid in 'RW_VAR_MRC_CACHE”,
and then it hangs indefinitely at the end of the log.

I tracked the MRC cache message down to this line:
https://github.com/coreboot/coreboot/blob/master/src/soc/intel/common/mrc_cache.c#L272

I’m stuck again for the moment. Thanks again Paul for getting me one step 
closer.

Cheers,
Cameron

From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Cameron Craig
Sent: 28 September 2017 16:51
To: 'Paul Penz'; coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Paul,

Great to hear I’m not the only one in this situation ☺

I’ve just been using the IWFI file from Intel with no modifications,  so I’ll 
look out the FIT tool and give that a go.

Thanks,
Cameron




Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:
e: cameron.cr...@exterity.com<mailto:cameron.cr...@exterity.com> | w: 
www.exterity.com<http://www.exterity.com>


From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Paul Penz
Sent: 28 September 2017 15:35
To: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Cameron,

I had the same problem.

Had you modified the intel IFWI file ?

If not, I had done this additional:

Download 522538_apl txe hf 3.0.11.1131 (th2 & rs1).zip from intel
Start fit.exe
Load the IFWI file
Change at Platform Protection/Platform Integrity OOEM Public Key Hash => 00..00
Change at Platform Protection/Boot Guard Configuration/ Boot profile 2 => 0
Save

Now I get output on the console and postcodes, but during FSP_M a long pause of 
ca. 45s exists and it hangs later during FSP_P initialization.

Good luck
Paul



Paul Penz
Dipl.-Ing. (FH)
Senior Hardware Engineer

ELTEC Elektronik AG, Mainz
_

Fon  +49 6131 918 335
Fax  +49 6131 918 195
Email   pp...@eltec.de<mailto:pp...@eltec.de>
Web www.eltec.de<http://www.eltec.de/>




*
ELTEC Elektronik AG
Galileo-Galilei-Straße 11
D-55129 Mainz

Vorstand: Peter Albert
Aufsichtsratsvorsitzender: Andreas Kochhäuser

Registergericht: Amtsgericht Mainz
Registernummer: HRB 7038
Ust-ID: DE 149 049 790
*
Wichtiger Hinweis:
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige 
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich 
erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung 
oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Evtl. 
Anhänge dieser Nachricht wurden auf Viren überprüft!
Jede Form von Vervielfältigung, Abänderung, Verbreitung oder Veröffentlichung 
dieser E-Mail Nachricht ist untersagt! Das Verwenden von Informationen aus 
dieser Nachricht für irgendwelche Zwecke ist strengstens untersagt.
Es gelten unsere Allgemeinen Geschäftsbedingungen, zu finden unter 
www.eltec.de<http://www.eltec.de>.

__
This email has been scanned by the Symantec Email Security.cloud service.
For more i

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Cameron Craig]

Hi Paul,

Those changes to the IFWI blob worked great, thanks!
I have attached the serial console log. It looks like we are in similar 
situations now.

I got a hang of around 45s at “MRC: region file invalid in 'RW_VAR_MRC_CACHE”,
and then it hangs indefinitely at the end of the log.

I tracked the MRC cache message down to this line:
https://github.com/coreboot/coreboot/blob/master/src/soc/intel/common/mrc_cache.c#L272

I’m stuck again for the moment. Thanks again Paul for getting me one step 
closer.

Cheers,
Cameron




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




From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Cameron Craig
Sent: 28 September 2017 16:51
To: 'Paul Penz'; coreboot@coreboot.org
Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Paul,

Great to hear I’m not the only one in this situation ☺

I’ve just been using the IWFI file from Intel with no modifications,  so I’ll 
look out the FIT tool and give that a go.

Thanks,
Cameron




Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:
e: cameron.cr...@exterity.com<mailto:cameron.cr...@exterity.com> | w: 
www.exterity.com<http://www.exterity.com>



From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Paul Penz
Sent: 28 September 2017 15:35
To: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Cameron,

I had the same problem.

Had you modified the intel IFWI file ?

If not, I had done this additional:

Download 522538_apl txe hf 3.0.11.1131 (th2 & rs1).zip from intel
Start fit.exe
Load the IFWI file
Change at Platform Protection/Platform Integrity OOEM Public Key Hash => 00..00
Change at Platform Protection/Boot Guard Configuration/ Boot profile 2 => 0
Save

Now I get output on the console and postcodes, but during FSP_M a long pause of 
ca. 45s exists and it hangs later during FSP_P initialization.

Good luck
Paul



Paul Penz
Dipl.-Ing. (FH)
Senior Hardware Engineer

ELTEC Elektronik AG, Mainz
_

Fon  +49 6131 918 335
Fax  +49 6131 918 195
Email   pp...@eltec.de<mailto:pp...@eltec.de>
Web www.eltec.de<http://www.eltec.de/>




*
ELTEC Elektronik AG
Galileo-Galilei-Straße 11
D-55129 Mainz

Vorstand: Peter Albert
Aufsichtsratsvorsitzender: Andreas Kochhäuser

Registergericht: Amtsgericht Mainz
Registernummer: HRB 7038
Ust-ID: DE 149 049 790
*
Wichtiger Hinweis:
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige 
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich 
erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung 
oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Evtl. 
Anhänge dieser Nachricht wurden auf Viren überprüft!
Jede Form von Vervielfältigung, Abänderung, Verbreitung oder Veröffentlichung 
dieser E-Mail Nachricht ist untersagt! Das Verwenden von Informationen aus 
dieser Nachricht für irgendwelche Zwecke ist strengstens untersagt.
Es gelten unsere Allgemeinen Geschäftsbedingungen, zu finden unter 
www.eltec.de<http://www.eltec.de>.

__
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
__

__
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

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Cameron Craig]

Hi Peter,

> What does a current cbfstool print output for that image?

See the attached cbfs output, it doesn’t look very useful.

> I would suggest reducing variables. So start with the same size. And reuse as
> many bits and pieces (descriptors, blobs, etc.) as possible from the working
> image.

Yeah, I think I've ruled out the flash descriptor being the problem.

> What about the flash descriptor from the working forked coreboot build?

I tried the flash descriptor from the working coreboot flash image, still 
nothing.

> Firmware development is lots of fun! :)

I'm beginning to see that :)

> I would recommend to focus on increasing debug capability. If all else fails
> then even looking at the SPI flash clock and data signals with a scope or 
> logic
> analyzer can be useful.

If I exhaust my options then yes, I'll have to dance with the electrons :)

> If there's a speaker on the board then you can try spkmodem. It's noisy, but
> fun, and works early.

No speaker unfortunately, it does found like fun.

Cheers,
Cameron


>

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


-Original Message-
> From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of
> Peter Stuge
> Sent: 27 September 2017 20:44
> To: coreboot@coreboot.org
> Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble
>
> Hi Cameron,
>
> Cameron Craig wrote:
> > I have managed to create a bootable image using an out of date copy of
> > coreboot and U-Boot, provided by Intel under NDA.
>
> coreboot code is always covered by the GPL, regardless of where it came
> from. If Intel tries to bind you in a contradictory agreement I don't think 
> that
> holds. Check with a lawyer.
>
> I think U-Boot is GPL-licensed too.
>
>
> > 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.
>
> What does a current cbfstool print output for that image?
>
>
> > 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.
>
> I would suggest reducing variables. So start with the same size. And reuse as
> many bits and pieces (descriptors, blobs, etc.) as possible from the working
> image.
>
>
> > 4.   Extract Flash Descriptor from an existing Leaf Hill UEFI image 
> > (./ifdtool
> --extract leaf_hill_ref_board_uefi.bin)
>
> What about the flash descriptor from the working forked coreboot build?
>
>
> > Other than that, I currently have no working theories as to what the
> > root cause is ☹
>
> Firmware development is lots of fun! :)
>
>
> > Is there anything obviously wrong with this process?
>
> If the flash descriptors match and bar the added variables then no, not 
> really.
>
>
> I would recommend to focus on increasing debug capability. If all else fails
> then even looking at the SPI flash clock and data signals with a scope or 
> logic
> analyzer can be useful.
>
> If there's a speaker on the board then you can try spkmodem. It's noisy, but
> fun, and works early.
>
>
> //Peter
>
> --
> 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
__
$ ./cbfstool ~/coreboot_images/Apl_Bx_SPI.bin print
W: Multiple (3) CBFS headers found, using the first one.
Apl_Bx_SPI.bin: 8192 kB, bootblocksize 912, romsize 32768, offset 0x0
alignment: 64 bytes, architecture: x86

Name   Offset Type Size
$ ./cbfstool ~/coreboot_images/Apl_Bx_SPI.bin layout
This is a legacy image composed entirely of a single CBFS.
ccraig@hadron:~/git/coreboot-leafhill/util/cbfstool$ 

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

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 (0x)
# 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.cr...@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.stojsavlje...@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, M

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Cameron Craig]

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.stojsavlje...@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<http://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<http://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.cr...@exterity.com<mailto:cameron.cr...@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_de

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Cameron Craig]

Hi Paul,

Great to hear I’m not the only one in this situation ☺

I’ve just been using the IWFI file from Intel with no modifications,  so I’ll 
look out the FIT tool and give that a go.

Thanks,
Cameron




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




From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Paul Penz
Sent: 28 September 2017 15:35
To: coreboot@coreboot.org
Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble

Hi Cameron,

I had the same problem.

Had you modified the intel IFWI file ?

If not, I had done this additional:

Download 522538_apl txe hf 3.0.11.1131 (th2 & rs1).zip from intel
Start fit.exe
Load the IFWI file
Change at Platform Protection/Platform Integrity OOEM Public Key Hash => 00..00
Change at Platform Protection/Boot Guard Configuration/ Boot profile 2 => 0
Save

Now I get output on the console and postcodes, but during FSP_M a long pause of 
ca. 45s exists and it hangs later during FSP_P initialization.

Good luck
Paul



Paul Penz
Dipl.-Ing. (FH)
Senior Hardware Engineer

ELTEC Elektronik AG, Mainz
_

Fon  +49 6131 918 335
Fax  +49 6131 918 195
Email   pp...@eltec.de<mailto:pp...@eltec.de>
Web www.eltec.de<http://www.eltec.de/>




*
ELTEC Elektronik AG
Galileo-Galilei-Straße 11
D-55129 Mainz

Vorstand: Peter Albert
Aufsichtsratsvorsitzender: Andreas Kochhäuser

Registergericht: Amtsgericht Mainz
Registernummer: HRB 7038
Ust-ID: DE 149 049 790
*
Wichtiger Hinweis:
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige 
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich 
erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung 
oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Evtl. 
Anhänge dieser Nachricht wurden auf Viren überprüft!
Jede Form von Vervielfältigung, Abänderung, Verbreitung oder Veröffentlichung 
dieser E-Mail Nachricht ist untersagt! Das Verwenden von Informationen aus 
dieser Nachricht für irgendwelche Zwecke ist strengstens untersagt.
Es gelten unsere Allgemeinen Geschäftsbedingungen, zu finden unter 
www.eltec.de<http://www.eltec.de>.

__
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
__
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Paul Penz]

Hi Cameron,

I had the same problem.

Had you modified the intel IFWI file ?

If not, I had done this additional:

Download 522538_apl txe hf 3.0.11.1131 (th2 & rs1).zip from intel
Start fit.exe
Load the IFWI file
Change at Platform Protection/Platform Integrity OOEM Public Key Hash => 00..00
Change at Platform Protection/Boot Guard Configuration/ Boot profile 2 => 0
Save

Now I get output on the console and postcodes, but during FSP_M a long pause of 
ca. 45s exists and it hangs later during FSP_P initialization.

Good luck
Paul



Paul Penz
Dipl.-Ing. (FH)
Senior Hardware Engineer

ELTEC Elektronik AG, Mainz
_

Fon  +49 6131 918 335
Fax  +49 6131 918 195
Email   pp...@eltec.de
Web www.eltec.de




*
ELTEC Elektronik AG
Galileo-Galilei-Straße 11
D-55129 Mainz

Vorstand: Peter Albert
Aufsichtsratsvorsitzender: Andreas Kochhäuser

Registergericht: Amtsgericht Mainz
Registernummer: HRB 7038
Ust-ID: DE 149 049 790
*
Wichtiger Hinweis:
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige 
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich 
erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung 
oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Evtl. 
Anhänge dieser Nachricht wurden auf Viren überprüft!
Jede Form von Vervielfältigung, Abänderung, Verbreitung oder Veröffentlichung 
dieser E-Mail Nachricht ist untersagt! Das Verwenden von Informationen aus 
dieser Nachricht für irgendwelche Zwecke ist strengstens untersagt.
Es gelten unsere Allgemeinen Geschäftsbedingungen, zu finden unter www.eltec.de.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Peter Stuge]

Hi Cameron,

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

coreboot code is always covered by the GPL, regardless of where it came
from. If Intel tries to bind you in a contradictory agreement I don't
think that holds. Check with a lawyer.

I think U-Boot is GPL-licensed too.


> 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.

What does a current cbfstool print output for that image?


> 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.

I would suggest reducing variables. So start with the same size. And
reuse as many bits and pieces (descriptors, blobs, etc.) as possible
from the working image.


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

What about the flash descriptor from the working forked coreboot build?


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

Firmware development is lots of fun! :)


> Is there anything obviously wrong with this process?

If the flash descriptors match and bar the added variables then no,
not really.


I would recommend to focus on increasing debug capability. If all
else fails then even looking at the SPI flash clock and data signals
with a scope or logic analyzer can be useful.

If there's a speaker on the board then you can try spkmodem. It's
noisy, but fun, and works early.


//Peter

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

Re: [coreboot] Intel Leaf Hill Coreboot Trouble

[Zoran Stojsavljevic]

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:
>
> 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 

[coreboot] Intel Leaf Hill Coreboot Trouble

[Cameron Craig]

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 ☹

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.cr...@exterity.com | w: www.exterity.com

[cid:image2640ac.PNG@354fb716.4f862c23]
[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