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.tester...@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.stojsavlje...@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-and-drivers.html > > > > Hope this helps also, > > > > Zoran > > > > > > > > On Thu, Jul 14, 2016 at 9:51 PM, Testerman, Brett (US COM) < > brett.tester...@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-boun...@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.tendul...@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 > > >
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot