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:[email protected]] 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): [Inline image 1] http://www.intel.com/content/www/us/en/embedded/products/bay-trail/software-and-drivers.html<http://www.intel.com/content/www/us/en/embedded/products/bay-trail/software-and-drivers.html> Hope this helps also, Zoran On Thu, Jul 14, 2016 at 9:51 PM, Testerman, Brett (US COM) <[email protected]<mailto:[email protected]>> 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<https://embedded.communities.intel.com/thread/12354> Hope this helps! Brett From: coreboot [mailto:[email protected]<mailto:[email protected]>] 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 <[email protected]<mailto:[email protected]>> [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: [email protected]<mailto:[email protected]> https://www.coreboot.org/mailman/listinfo/coreboot<https://www.coreboot.org/mailman/listinfo/coreboot> -- coreboot mailing list: [email protected]<mailto:[email protected]> https://www.coreboot.org/mailman/listinfo/coreboot<https://www.coreboot.org/mailman/listinfo/coreboot>
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
