Hello Brett and Coreboot community,
This'll be my last email in this particular thread (unless somebody asks me a question). I'll try to be short and punctual, and try to cover the most for BYT (considering Brett's last email), since I had some time to re-think about BYT TXE and recall some things, not mentioned here.
[1] HW straps. HW straps are for schematic HW designers, highly classified INTEL info, so I'll assume this is done correctly for the BYT boards (you all should check with your BYT board designers); [2] Yes, BYT could be brought up without TXE FW (not using TXE HW), but then XDP will be disabled (maybe some other TXE related features); [3] In order to make XDP to work, FW IOTG designers introduced so-called slim TXE, which is real TXE reduced to 1,5MB, in nutshell this TXE allows all the features, but disables main one: BIOS tampering; [4] I remember one specific IOTG slim TXE: 1.1.1.1120 (it could be that there is slim TXE 1.1.1.1127 and newer), you should go to INTEL VIP site www.platformsw.intel.com to check/get them (you have to have access to it); [5] Or you can also go here: http://www.win-raid.com/t832f39-Intel-Engine-Firmware-Repositories.html and try to find it; [6] BYT Power Rails: there are 14 of them, if you reduce/not use Power Management, number reduces (example, if you use only CPU's C0 and C1 -> platform's S0, you need at most 5 main power rails (highly HW topic);
Lot of the decisions for the platform HW design are on your own perils, please, never forget this. INTEL reference boards are HW and SW guidance, not a must to follow up with them, but INTEL tries to comply with most complex customer wishes (example: to show all the advantages for C0, C1... C3, C6, C7, C8, C9 etc. PM CPU/SoC states in newest CPUs/SoCs, such as ATOM APL-I).
It just depends what are the particular requirements (referring as example to [6]). 14 Power Rails are there for BYT, but there are so handful to use, depending upon HW PM design. :-)
Zoran _______
On Sat, Jul 16, 2016 at 12:45 AM, Testerman, Brett (US COM) < Brett.Testerman@cobham.com> wrote:
Hi Zoran,
I am running a Bay Trail-I processor, an E3815 to be specific, and really had to jump through a lot of hoops to initially bring it up. I did everything I could think of from a software standpoint, including creating signed images and a manifest table. I sought support on the Intel forums and it was there that I was shown I could boot that processor without the TXE. We are using the processor in an embedded device where things like preventing BIOS tampering just gets in the way as we are not running Linux or Windows, and even if we did there is no network connectivity or any other reason for anyone to hack into it. Thankfully it seems for the E3800 family Intel does not strictly enforce security. I do not have experience with the other CPU family members to know if that is true across the board.
So empirically I found that yes, I can boot coreboot without the TXE binary in flash. However when I attached the XDP probe I could only see the boundary scan device. The CPU device had an address of all 0’s and the probe could not attach to it. I did not change any of the soft straps nor am I asserting the Security Flash Descriptors override hardware strap. All I did was remove the TXE from the boot flash.
I also found that I don’t have to generate hashes on my binaries or a manifest table in order for it to boot. There is supposed to be a secure boot fuse to force that but we obviously are not setting it.
Documents I reviewed to get to the point I am:
540009 Intel® Atom™ Processor E3800 Product Family – Intel® Trusted Execution Engine (Intel® TXE) Firmware Bring-Up Guide
528703 Secure Boot Implementation in the Sample Boot Loader using Intel® FSP for Bay Trail Platforms README
539374 Secure Boot Sample Implementation for Intel® Atom™ Processor E3800 Product Family README
Among others. I haven’t look at this for over a year
As for the soft straps, the document I referenced originally:
514482 Bay Trail-T/I SoC SPI Flash Programming Guide - Application Note
covers them along with the layout of the descriptor table. I did just do a quick web search and it looks like Intel has locked down that document. I am sorry to see that. The last time I check it was unlocked.
As frustrating it has been bringing up this processor I will say it has worked solid once we got through all the hardware design issues. I think the HW engineer said there are 27 different power rails. I am still booting the version of coreboot I used to bring the chip up a year ago and we have done all of our application design as a payload to it. I just saw that Intel released a reference coreboot for the Bayley Bay platform, which is chip-down Bay Trail, in March of this year so I will probably migrate to it and lock it there.
I will say if anyone needs help with bringing up a design the embedded community forums should be the place to start:
https://embedded.communities.intel.com/community/en
Sorry for the long email. If my experiences can help others I will try to respond, time permitting. My way of thanking B.O. and others who helped me when I was in the same position.
Brett
*From:* Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] *Sent:* Thursday, July 14, 2016 10:06 PM *To:* Testerman, Brett (US COM) *Cc:* coreboot; Martin Roth; Mayuri Tendulkar; Stefan Reinauer
*Subject:* Re: [coreboot] TXE and Descriptor bin management in Coreboot
*** Please note that the Sender of this email is from outside the Cobham NA IT Hub ** *
Hello Brett,
Having overall experience with INTEL, I should say that the Truth is a bit more complicated. ;-)
In the simplified view, there are two points when bringing any INTEL CPU from reset, i should say. The first is: HW strap conditions, and these need to be set appropriately, depending upon what the HW config will be. This point I mentioned since I am not sure if XDP port only depends upon TXE, I do not really know with certainty for BYT, but I do know for some other families HW straps also need to be set properly for XDP to be enabled. Maybe there are two requirements for XDP to be enabled, so I am really not sure about this, this is why I am writing this email.
So, the question I have here is: does BYT have to have one of the HW straps properly set (maybe it is already set by default design) for XDP to be enabled?
The another point why TXE HW/FW engine is mainly used is the following: TXE Firmware, the Trusted eXecution Engine, provide features to prevent BIOS tampering, however information about TXE is considered Intel Confidential and require that you have CNDA account.
Usually, FSP + Coreboot (as you have mention already), is built on the top of normal BIOS (last 2M, maybe these days 3M, since FSP and Coreboot are growing) , since normal BIOS includes SW straps (second point), which are also set by default (in BIOS). In this scenario, FIT (formerly FITC) tool is not required (if satisfied with default SW straps, which 99% developers are).
Here is INTEL site where there are overall set of BYT documents, but many of them are locked (as well as 514482):
[image: Inline image 1]
http://www.intel.com/content/www/us/en/embedded/products/bay-trail/software-...
Hope this helps also,
Zoran
On Thu, Jul 14, 2016 at 9:51 PM, Testerman, Brett (US COM) < Brett.Testerman@cobham.com> wrote:
Mayuri,
Your best bet with all of this is to contact Intel and get a privileged access account. If that is not possible or practical then you need to do some reverse engineering.
First of all, go get this document from Intel’s web site:
514482_ByTti_SoC_SPIFlashProgGuide_Rev1p0.pdf
I don’t have a specific link to it but I know it is publically accessible. Search on the leading 6 digit number or “SPI Flash Programming Guide”. This document fully describes the descriptor tables and how to use them. The FITC tool is the preferred way but you can bit-bang them with the info provided in that doc.
As for the TXE you will need to get that from Intel – it is not publically available. But I can say if you are running on the E3800 family (Bay Trail) then you don’t need it. The chip will boot without it but the XDP port will be locked out. You can also use the information from the programming guide to locate a TXE image in a 3rd party boot image and extract it out of that. I think that is what the idftool does.
The coreboot image will need to be located at the very end of flash because that is where the hardware reset vector is. The nice thing about that is once you have set up the descriptors you don’t have to rebuild/reprogram the entire flash image every time. For example, if your coreboot image is only 1MB in size then you only need to reprogram the last 1 megabyte of flash and leave the rest alone. Saves a ton of time.
There has been a lot of talk about this issue on Intel’s embedded communities forums. Check out this thread:
https://embedded.communities.intel.com/thread/12354
Hope this helps!
Brett
*From:* coreboot [mailto:coreboot-bounces@coreboot.org] *On Behalf Of *Stefan Reinauer *Sent:* Wednesday, July 13, 2016 4:30 PM *To:* Mayuri Tendulkar *Cc:* Martin Roth; coreboot *Subject:* Re: [coreboot] TXE and Descriptor bin management in Coreboot
*** Please note that the Sender of this email is from outside the Cobham NA IT Hub ** *
- Mayuri Tendulkar mayuri.tendulkar@aricent.com [160714 00:50]:
Ok, so do we need to ask Intel if we use Intel baytrail processor? How
we can create this descriptor.bin?
Please have a look at util/ifdtool and util/ifdfake for our tools dealing with Intel Firmware Descriptors. The most comprehensive way of producing the information you need is by using Intel's fitc tool, however.
If you are willing to put some development effort into this, we could use help, merging ifdtool and ifdfake, as well as incorporating more fitc like capabilities into the tool.
Stefan
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
-
Zoran Stojsavljevic