coreboot July 2016

coreboot@coreboot.org

47 participants
135 discussions

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 18 Jul '16

18 Jul '16

The ASUS KGPE-D16 fails verification for branch master as of commit e19d9af9eed7540f52d39d746314877ab6e0bfe5 The following tests failed: BOOT_FAILURE Commits since last successful test: e19d9af elog: Use rdev_mmap to find offset of ELOG d83b0e9 mainboard/amd: add support for F2950 system board 3a96ac4 acpi: Change API called to write the name for ACPI_DP_TYPE_CHILD 6101dfb buildgcc: Update the revision to 1.41 9b4be0f intel/amenia: Add wake-up from lid open <118 commits skipped> 70cd543 AMD k8 fam10: Drop excessive spinlock initialization b5664de Romstage spinlocks require EARLY_CBMEM_INIT d113190 AMD k8 fam10: Fix romstage handoff 880b458 google/chromeec: Update EC command header 1f83ffa gru: include ram_code in coreboot table See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] How to read the gpio status?
by Zoran Stojsavljevic 18 Jul '16

18 Jul '16

> But DS is said to me that SC_GP_LVL is WR register. So, as I assumed, SC_GP_LVL is WR ONLY register. If it always works and puts out values, and retains them (which is another of mine assumption), the solution to RD problem is simplistic. Immediately after the: outl(GPIO, gpiobase + GPIO_SC_GP_LVL); Please, always remember the I/O data value you outl() into some heap global variable (which will always retain the latest outl() data value). If you need it back, read this variable. Best Regards, Zoran On Mon, Jul 18, 2016 at 7:20 AM, 김유석 <poplinux0(a)gmail.com> wrote: > Dear Sir. > > I was test with by your advise. But SC_GP_LVL is always read 0x00 > > source code & result is see below. > > u32 read_gpio_level(const struct soc_gpio_map *gpio) > { > > u16 gpiobase __attribute__((unused)) = pci_read_config16(SOC_LPC_DEV, > GBASE) & ~0xf; > > printk(BIOS_DEBUG, "%s() : Start\n", __FUNCTION__); > printk(BIOS_DEBUG, " GPIO_SC_USE_SEL : 0x%x\n", inl(gpiobase + > GPIO_SC_USE_SEL)); > printk(BIOS_DEBUG, " GPIO_SC_IO_SEL : 0x%x\n", inl(gpiobase + > GPIO_SC_IO_SEL)); > printk(BIOS_DEBUG, " GPIO_SC_GP_LVL : 0x%x\n", inl(gpiobase + > GPIO_SC_GP_LVL)); > printk(BIOS_DEBUG, "%s() : End\n\n", __FUNCTION__); > > return 0; > } > > int set_gpio_level(const struct soc_gpio_map *gpio, > const int num, > const int lvl) > { > u16 gpiobase __attribute__((unused)) = pci_read_config16(SOC_LPC_DEV, > GBASE) & ~0xf; > u32 GPIO = 0; > > GPIO = setBit(GPIO, num); > > printk(BIOS_DEBUG, "%s() : GPIO set value 0x%x\n", __FUNCTION__, GPIO); > outl(GPIO, gpiobase + GPIO_SC_GP_LVL); > > return 0; > } > > > void early_mainboard_romstage_entry(void) > { > setup_soc_gpios(&gpio_map); > set_gpio_level(&gpio_map, 12, 1); > mdelay(500); > read_gpio_level(&gpio_map); > > set_gpio_level(&gpio_map, 13, 1); > mdelay(500); > read_gpio_level(&gpio_map); > > set_gpio_level(&gpio_map, 14, 1); > mdelay(500); > read_gpio_level(&gpio_map); > }; > > > > ================================================================================== > coreboot-NexG-59a9b0a6 Mon Jul 18 05:09:30 UTC 2016 romstage starting... > set_gpio_level() : GPIO set value 0x1000 > read_gpio_level() : Start > GPIO_SC_USE_SEL : 7000 > GPIO_SC_IO_SEL : 0 > GPIO_SC_GP_LVL : 0 > read_gpio_level() : End > > set_gpio_level() : GPIO set value 0x2000 > read_gpio_level() : Start > GPIO_SC_USE_SEL : 7000 > GPIO_SC_IO_SEL : 0 > GPIO_SC_GP_LVL : 0 > read_gpio_level() : End > > set_gpio_level() : GPIO set value 0x4000 > read_gpio_level() : Start > GPIO_SC_USE_SEL : 7000 > GPIO_SC_IO_SEL : 0 > GPIO_SC_GP_LVL : 0 > read_gpio_level() : End > > > > > > And I was re-view the DS of C2000. > > But DS is said to me that SC_GP_LVL is WR register. > > > > Please help me. > > Thank you. > > > > > 2016-07-13 오후 4:40에 Zoran Stojsavljevic 이(가) 쓴 글: > > *> When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from SC_GP_LVL. > everytime.* > > Please, try to do the following exercise: > > [1] WR 0x1000 to SC_GP_LVL, then RD the value out of it: what it is? > [2] WR 0x2000 to SC_GP_LVL, then RD the value out of it: what it is? > [3] WR 0x4000 to SC_GP_LVL, then RD the value out of it: what it is? > > If you have all 0x0, most likely it does mean that Rangeley's SC_GP_LVL > register isd WR ONLY (when you read it, all 0s). > > To verify this, you should fetch the following document: > > http://www.intel.com/content/www/us/en/processors/atom/atom-c2000-microserv… > > And read Chapter 25 - General Purpose I/O (GPIO). > > Best Regards, > Zoran > > On Wed, Jul 13, 2016 at 6:39 AM, 김유석 <poplinux0(a)gmail.com> wrote: > >> Dear Sir. >> >> >> I want to control the GPIO pin that pin number is 12, 13, 14 >> >> >> DataSheet(P 1909) and coreboot source >> code(src/southbridge/intel/fsp_rangeley/gpio.c, gpio.h) is said to me that >> "It is very easy" >> >> >> If i want to set the HIGH to 12, 13, 14 >> >> Just setup the some register, is see below. >> >> SC_USE_SEL = 0x7000(b0111 0000 0000 0000) >> >> Is mean, the 12, 13, 14 is config to GPIO mode.(enable GPIO) >> >> SC_IO_SEL = 0x00(b0000 0000 0000 0000) >> >> Is mean, the 12, 13, 14 is output mode >> >> SC_GP_LVL = 0x7000(b0111 0000 0000 0000) >> >> Is mean, the 12, 13, 14 is set to HIGH level(1) >> >> >> src/southbridge/intel/fsp_rangeley/gpio.h >> >> /* Core GPIO */ >> const struct soc_gpio soc_gpio_mode = { >> .gpio12 = GPIO_MODE_GPIO, /* Board ID GPIO */ >> .gpio13 = GPIO_MODE_GPIO, /* Board ID GPIO */ >> .gpio14 = GPIO_MODE_GPIO, /* Board ID GPIO */ >> }; >> >> const struct soc_gpio soc_gpio_direction = { >> .gpio12 = GPIO_DIR_OUTPUT, >> .gpio13 = GPIO_DIR_OUTPUT, >> .gpio14 = GPIO_DIR_OUTPUT, >> }; >> >> const struct soc_gpio soc_gpio_level = { >> .gpio12 = GPIO_LEVEL_HIGH, >> .gpio13 = GPIO_LEVEL_HIGH, >> .gpio14 = GPIO_LEVEL_HIGH, >> }; >> >> >> Yes, It is perfectley running. >> >> The 12, 13, 14 PIN is goto active-HIGH.(I was check this pin use by >> oscilloscope.) >> >> >> And I'm try to read the SC_GP_LVL register for check current >> status/config of gpio pins >> >> I was *respected* the read value is *0x7000*, because i was writed the >> *0x7000* to SC_GP_LVL. >> >> >> But, every time readed the *0x00* from SC_GP_LVL register. >> >> >> *When write 0x7000 write to SC_USE_SEL, Can read the 0x7000 from >> SC_USE_SEL.* >> >> *When write 0x00 write to SC_IO_SEL, Can read the 0x00 from SC_IO_SEL.* >> >> >> But, >> >> >> *When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from SC_GP_LVL. >> everytime.* >> >> >> I don't understand this sistuation. >> >> >> Please advise to me. >> >> >> Thank you. >> >> >> >> >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > > >

1 0

How to read the gpio status?
by 김유석 18 Jul '16

18 Jul '16

Dear Sir. I want to control the GPIO pin that pin number is 12, 13, 14 DataSheet(P 1909) and coreboot source code(src/southbridge/intel/fsp_rangeley/gpio.c, gpio.h) is said to me that "It is very easy" If i want to set the HIGH to 12, 13, 14 Just setup the some register, is see below. SC_USE_SEL = 0x7000(b0111 0000 0000 0000) Is mean, the 12, 13, 14 is config to GPIO mode.(enable GPIO) SC_IO_SEL = 0x00(b0000 0000 0000 0000) Is mean, the 12, 13, 14 is output mode SC_GP_LVL = 0x7000(b0111 0000 0000 0000) Is mean, the 12, 13, 14 is set to HIGH level(1) src/southbridge/intel/fsp_rangeley/gpio.h /* Core GPIO */ const struct soc_gpio soc_gpio_mode = { .gpio12 = GPIO_MODE_GPIO, /* Board ID GPIO */ .gpio13 = GPIO_MODE_GPIO, /* Board ID GPIO */ .gpio14 = GPIO_MODE_GPIO, /* Board ID GPIO */ }; const struct soc_gpio soc_gpio_direction = { .gpio12 = GPIO_DIR_OUTPUT, .gpio13 = GPIO_DIR_OUTPUT, .gpio14 = GPIO_DIR_OUTPUT, }; const struct soc_gpio soc_gpio_level = { .gpio12 = GPIO_LEVEL_HIGH, .gpio13 = GPIO_LEVEL_HIGH, .gpio14 = GPIO_LEVEL_HIGH, }; Yes, It is perfectley running. The 12, 13, 14 PIN is goto active-HIGH.(I was check this pin use by oscilloscope.) And I'm try to read the SC_GP_LVL register for check current status/config of gpio pins I was *respected* the read value is *0x7000*, because i was writed the *0x7000* to SC_GP_LVL. But, every time readed the *0x00* from SC_GP_LVL register. _When write 0x7000 write to SC_USE_SEL, Can read the 0x7000 from SC_USE_SEL._ _When write 0x00 write to SC_IO_SEL, Can read the 0x00 from SC_IO_SEL._ But, *_When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from SC_GP_LVL. everytime._* I don't understand this sistuation. Please advise to me. Thank you.

3 3

Re: [coreboot] TXE and Descriptor bin management in Coreboot
by Zoran Stojsavljevic 18 Jul '16

18 Jul '16

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(a)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(a)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(a)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(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > > >

1 0

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 17 Jul '16

17 Jul '16

The ASUS KGPE-D16 fails verification for branch master as of commit 3a96ac44e275eca84baea513bc0802f62fe83fd3 The following tests failed: BOOT_FAILURE Commits since last successful test: 3a96ac4 acpi: Change API called to write the name for ACPI_DP_TYPE_CHILD 6101dfb buildgcc: Update the revision to 1.41 9b4be0f intel/amenia: Add wake-up from lid open 89e7b49 soc/intel/apollolake: Consolidate ISH enabling d779605 soc/intel/apollolake: Properly disable PCIe root ports <116 commits skipped> 70cd543 AMD k8 fam10: Drop excessive spinlock initialization b5664de Romstage spinlocks require EARLY_CBMEM_INIT d113190 AMD k8 fam10: Fix romstage handoff 880b458 google/chromeec: Update EC command header 1f83ffa gru: include ram_code in coreboot table See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] TXE and Descriptor bin management in Coreboot
by Testerman, Brett (US COM) 16 Jul '16

16 Jul '16

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): [Inline image 1] http://www.intel.com/content/www/us/en/embedded/products/bay-trail/software…<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(a)cobham.com<mailto: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<https://embedded.communities.intel.com/thread/12354> Hope this helps! Brett From: coreboot [mailto:coreboot-bounces@coreboot.org<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(a)aricent.com<mailto: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(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot<https://www.coreboot.org/mailman/listinfo/coreboot> -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot<https://www.coreboot.org/mailman/listinfo/coreboot>

1 0

How to use properly the GRUB payload?
by Ioannis Koutras 15 Jul '16

15 Jul '16

Hello, I have just flashed coreboot (git commit: 89e7b49) on a Lenovo X220 with GRUB2 as payload and when I boot the machine, I am getting GRUB's command line. I am trying to boot a systemd-boot (previously known as gummiboot?) payload from my disk partition, but I am getting unrecognised payload. Any idea what's the issue there? Additionally, could anyone help me set it up properly, as in searching for grub.cfg in disks and looking to boot from USB? Many thanks in advance, Ioannis

1 0

Output of superiotool for the Nuvoton NCT6791D
by Omar Pakker 15 Jul '16

15 Jul '16

As requested by Paul Menzel, here is the output of `superiotool -deV` for the NCT6791D. Related Gerrit commit: https://review.coreboot.org/#/c/15252/ Regards, Omar superiotool r4.4-515-ge813c15 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Exar Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Exar Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0x0000, id=0x03c8 Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for ITE Super I/O (init=standard) at 0x20e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x20e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x20e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x20e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x20e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=standard) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=standard) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id=0xc803, rev=0xf Probing for ITE Super I/O (init=standard) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8661f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8671f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x4e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x15c... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x164e... Failed. Returned data: port=0xff, port+1=0xff Probing for Nuvoton Super I/O at 0x164e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x2e... Found Nuvoton NCT6791D (id=0xc803) at 0x2e Register dump: idx 07 10 11 13 14 1a 1b 1c 1d 20 21 22 24 25 26 27 28 2a 2b 2c 2f val 0b ff ff 00 00 0a 26 00 00 c8 03 ff 00 00 10 00 00 40 00 00 03 def 00 ff ff 00 00 30 70 10 00 c5 62 ff 04 00 MM 00 00 c0 00 01 MM LDN 0x01 (Parallel Port) idx 30 60 61 70 74 f0 val 00 03 78 07 04 3f def 01 03 78 07 04 3f LDN 0x02 (UART A) idx 30 60 61 70 f0 f2 val 01 03 f8 04 00 00 def 01 03 f8 04 00 00 LDN 0x03 (UART B, IR) idx 30 60 61 70 f0 f1 f2 val 00 02 f8 03 00 00 00 def 01 02 f8 03 00 00 00 LDN 0x05 (Keyboard Controller) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 0c 82 def 00 00 00 00 00 00 00 83 LDN 0x06 (Consumer IR) idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 08 09 32 00 def 00 00 00 00 08 09 32 00 LDN 0x07 (GPIO 6, GPIO 7, GPIO 8) idx 30 e0 e1 e2 e3 e4 e5 e6 e7 ec ed f4 f5 f6 f7 f8 val 02 7f 06 00 00 ff ff ff ff 00 ff ff ff ff ff ff def 00 7f 00 00 00 ff 00 00 00 00 00 ff 00 00 00 00 LDN 0x08 (WDT1, WDT_MEM, GPIO 0, GPIO 1) idx 30 60 61 e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fe ff val 82 00 00 ff 80 00 00 00 b7 76 00 00 00 ff 00 ff ff 00 ff 00 00 def 00 00 00 ff 00 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 LDN 0x09 (GPIO 2, GPIO 3, GPIO 4, GPIO 5) idx 30 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ee f0 f1 f2 f4 f5 f6 f7 fe val 0f ff f0 00 00 7f 10 00 00 00 00 00 00 00 ff 36 00 ff f0 00 00 00 def 00 ff 00 00 00 7f 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 00 00 LDN 0x0a (ACPI) idx e0 e1 e2 e3 e4 e5 e6 e7 e9 ec ed ee f0 f2 f3 f4 f6 f7 fc fe val 01 00 00 00 00 02 1a 11 00 80 03 10 00 5d 00 00 00 c0 80 00 def 01 00 00 00 00 02 1a 00 00 00 00 00 10 5c 00 00 00 c0 00 00 LDN 0x0b (Hardware Monitor, Front Panel LED) idx 30 60 61 62 63 70 e0 e1 e2 e3 e4 e6 e7 f0 f1 f2 f5 f6 f7 f8 f9 fa fb val 01 02 90 02 c0 00 7f 7f ff ff ff 09 ff 7e 00 00 10 00 87 47 00 00 00 def 00 00 00 00 00 00 7f 7f ff ff ff 08 ff 00 00 00 10 00 87 47 00 00 00 LDN 0x0d (BCLK, WDT2, WDT_MEM) idx e0 e1 e7 e8 eb ed f0 f3 val 00 cc 00 32 14 00 00 00 def 00 MM 00 32 14 00 00 00 LDN 0x0e (CIR Wake-Up) idx 30 60 61 70 val 00 00 00 00 def 00 00 00 00 LDN 0x0f (GPIO Push-Pull or Open-Drain selection) idx e0 e1 e2 e3 e4 e5 e6 e7 e9 f0 f1 f2 val b6 ff 6f bf fa ff 77 ff ff 9d 00 00 def ff ff 7f ff ff ff 0f ff ff 9d 00 00 LDN 0x14 (Port 80 UART) idx e0 e1 e2 e3 e4 val 80 00 00 10 00 def 80 00 00 10 00 LDN 0x16 (Deep Sleep) idx 30 e0 e1 e2 e3 val 20 20 04 05 01 def 20 20 04 05 01 Probing for Nuvoton Super I/O at 0x4e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x4e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id/oldid=0xc8/0x0f, rev=0x03 Probing for Winbond Super I/O (init=0x88) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for VIA Super I/O at 0x3f0... PCI device 1106:0686 not found. Probing for AMD EC Super I/O at 0xaa... Probing for Server Engines Super I/O at 0x2e... Failed. Returned data: id=0xffff, rev=0xff Probing for Infineon Super I/O at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for Infineon Super I/O at 0x4e... Failed. Returned data: id=0xff, rev=0xff

1 0

Re: [coreboot] how to debug without com port
by Martin Roth 15 Jul '16

15 Jul '16

Hi Cheng, Without knowing your platform, what you actually have available. and what your budget is, and where you're stuck, it's hard to say, but here are some directions you could look: - If you're making it to an OS but something's wrong, use the CBMEM console. - EHCI debug could be the best way if you're trying to get a full console: https://www.coreboot.org/EHCI_Debug_Port https://www.coreboot.org/BBB_screwdriver - There's also a way to get the console over the PC speaker: https://www.coreboot.org/Spkmodem - If you have a pcie slot, or mpcie slot, you can add a serial port (Oxford OXPCIe952 is supported) https://www.amazon.com/StarTech-com-Profile-Native-Express-PEX1S952LP/dp/B0… https://www.amazon.com/StarTech-com-RS232-Express-Serial-MPEX2S952/dp/B003O… - If you have post code leds or a way to read from port 80h, put out a value and debug it that way. For more information, you can use 'rolling post codes', where you put out a known value or two, then a series of values with a delay in between, just in a loop. "BA BA 99 01 03 7F BA BA 99 01 03 7F ..." - You can use a rom emulator and the spi console: http://www.dediprog.com/pd/spi-flash-solution/em100pro https://review.coreboot.org/#/admin/projects/em100 - If you have an LED attached to a GPIO, you can use that to help figure out how far you're getting, and then answer yes/no type questions. - If your board is hanging, you can get some visibility by resetting the board or powering it down. This also allows you to debug slowly, and get answers to yes/no questions. Note that these are just suggestions and thoughts, and I'd suggest you investigate some more before buying any additional hardware. I've used some, but not all of these methods. For instance I've never tested the spkmodem debugging. Hope this helps. Martin On Fri, Jul 15, 2016 at 8:20 AM, cheng yichen <blessyichen(a)gmail.com> wrote: > Hi all > > Could you please share how to debug without com port out ? Thank you > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

how to debug without com port
by cheng yichen 15 Jul '16

15 Jul '16

Hi all Could you please share how to debug without com port out ? Thank you

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2016