Embedded Intel Atom® Processors
Technological Conversations about Intel Atom® Hardware, Software, Firmware, Graphics
1149 Discussions

Bay Trail (E3815) boot-up problems...

THart3
Novice
3,984 Views

Hi. My apologies in advance if this is the wrong place for this sort of post/question. (And if so, I'd welcome any/all pointers as to what would be a better venue.)

We're doing a design with the E3815. This is a truly embedded (bare metal) design (RYO bootloader, OS, etc.) I have a SPI flash descriptor set up, and the processor comes out of reset and I switch from 16-bit real mode to 32-bit protected mode. We have one of the GPIOs connected to a hardware watchdog, and I've gotten the E3815 to spit out a 1KHz square wave.

Our design uses HSUART1 (PCI Dev30/Fcn3) for its console port.. but I'm really, REALLY, struggling trying to get any activity on the HSUART.

  1. I setup the IOBASE (Dev30/Fcn0/offset 0x4c) (and set the EN bit)
  2. I setup the (memory-mapped I/O) "Uart1 Txd Pad Configuration"
  3. I setup the "Uart1 Rxd Pad Configuration"
  4. I setup the SIO HSUART (Dev30/Fcn3) BAR and CMD
  5. On the HSUART, I setup the "Private Clock Params" so that Sclock = 1.8432MHz
  6. Then I setup the HSUART's LCR, baudrate divisor, etc. ("normal" UART stuff)
  7. Then, finally, I try sending characters to the HSUART (in polled mode).

I'm more than happy to provide the real source code I'm using.. but I'm hoping someone is familiar enough with this stuff to either (1) point out the "obvious" step(s) I'm missing, or (2) ask a few questions.

As an aside, we're using the FSP framework. And it doesn't seem to matter whether the GPIO initialization is done before of after invoking FSP's TempRamInit routine. (It works either way.) But.. before or after.. I can't get anywhere with the HSUART. (And we have limited hardware debugging tools.. so being able to print stuff to the console port is pretty important!)

Thanks and regards,

Tom

0 Kudos
16 Replies
Adolfo_S_Intel
Moderator
1,774 Views

Hello, Tom_Hartnett

First make sure that you have enable the UART on the FSP binary using the Binary Configuration Tool.

The tool can be donwloaded here: https://github.com/IntelFsp/bct https://github.com/IntelFsp/bct

The latest FSP can be downloaded here: https://github.com/IntelFsp/FSP https://github.com/IntelFsp/FSP

The second thing you need to check is the TXE

If you have access to the TXE firmware and the FITC tool? If that is the case, please check that UART port has been enabled on the STRAPS.

Another alternative is to extract the TXE adn SPI descriptor from a previous existing image (that enable UART debugging) http://wiki.minnowboard.org/Coreboot http://wiki.minnowboard.org/Coreboot

Other step that you can perform is check the Coreboot Source code to see if you are missing some configuration steps.

I can sent you additional Firmware documentation if you get a Priviledge Access account for the Embedded Forum.

I hope this information is useful for your case.

Best regars,

Adolfo Sanchez

0 Kudos
THart3
Novice
1,774 Views

Adolfo,

Thanks for the comments/suggestions. I'm actually away from the office for the holiday week, but I wanted to get you some feedback sooner than that.

1. We DO enable HSUSART0 with the BCT. I notice that, in the BCT, they talk about HSUART0 and HSUART1,.. but in the E3815 datasheet, they talk about HSUART1 and HSUART2. (I'm assuming (?) that BCT/FSP HSUART0 is the same as datasheet HSUART1 (i.,e., PCI Dev 30 Fcn 3).

2. We are NOT using the TXE stuff. (I don't recall exactly, but I think there was some pull-up the hardware guy put on the processor that disables that.)

3. You mentioned "UART debugging." Do they use the HSUART? (Or the iLB/UART? Or the "debug UART" that's part of the USBdevice?)

4. A little more background.. Why am I trying to enable/use the HSUART? I'm trying to go through the various (4) FSP steps. We seem to make it through TempRamInit okay. (At least it "returns" control to where I think it should.) But then the subsequent call to FspInit does not fare so well. So I'm trying to enable/use the HSUART between the FSP TempRamInit call and the FspInit call. (Again, I have pretty limited hardware debugging tools/skills (basically an oscilloscope) available.)

Regards,

Tom

Adolfo_S_Intel
Moderator
1,774 Views

Hello Tom_Hartnett

Regarding your questions:

1. I think this is also a related to different naming in the documentation, however I will doublecheck with the next support level for confirmation

2. The TXE firmware is mandatory, TXE can be temporary disable for testing/debugging issues, but TXE cannot be disabled on a release to the customer.

3. I am not familiar with all of the Minnowboard features, you should check their specs to see what they use to debugging, and see if their TXE firmware could be compatible with your board.

Thanks for your explanation on the background.

I would recommend trying to apply for privilege account: https://www-ssl.intel.com/content/www/us/en/forms/design/registration-privileged.html Register for a Privileged Intel Account

By having a privilege account you would be able to access Intel Confidential information that can be useful for your case.

The privilege account can also be used, to request a review and feedback of your board desing, by Intel Hardware Engineers.

Could you please provide the following information?

1-What firmware solution are you using with FSP? EDK II, Coreboot, or a different one?

2-Do you have a PORT 80 or any I/O port available that could be used to read POST CODES?

In the meantime you can check the following alternative sources of information that could be useful for your issue:

Intel Firmware Page: https://firmware.intel.com/

Coreboot support channel:mailto:coreboot@coreboot.org coreboot@coreboot.org

EDK-II support: mailto:edk2-devel@lists.01.org edk2-devel@lists.01.org

Best regards,

Adolfo Sanchez

0 Kudos
THart3
Novice
1,774 Views

Adolfo,

I'm pretty sure I do have privileged account. Many of the documents we access (e.g., BWGs) are restricted.. and we don't have a problem with accessing them. But I will double check.

Again, thanks for your help (and patience). I'm new to the E3815/FSP world. (The last design I did this kind of stuff for was an Atom "Crown Beach / Menlow" design with the US15W SCH. And in that case, I used Intel's BLDK.) As far as what we're using "with" the FSP.. we expected to have to write our own bootloader (which would incorporate FSP in its front-end). And the RYO bootloader will boot the (again RYO) functional/operational software. Again, this design is an embedded processor that mainly has a decent amount of memory and access to a couple of PCIe devices (DSPs, ethernet switches, ...). We will user the USB Host Controller (EHCI) to deal with a handful of on-board ARMs (that don't have PCIe support). And, of course, we're using the HSUART as a console interface.

Some things to clear up.. in case our wires are getting crossed.. This is not a Minnowboard (or other) "reference design."

And the hardware designer did not bring out the LPC,.. so I don't have port 80 for post codes.. or the iLB.. or the PCU/UART.

We are trying to go down the FSP "path." But that has (at least for me) not been nearly as straightforward as the "training document" (328095) (or the FSP External Architecture Specification (332394)) would have me believe. For example, the E3815 (538136), says that if the SOC firmware doesn't find a valid flash descriptor signature (at offset 10), then it will use the flash in non-descriptor mode. I don't think that is true. So we built a descriptor.. mostly with all the correct opcodes for the SPI flash we're using. There are a few more minor differences between what we're using and the default values from the Bay Trail SPI Flash Programming Guide (514482).

But what's really confusing me about your comments is the "mandatory" nature of the TXE "stuff" (?) (Which, I admit, I don't have an adequate understanding of.) I really thought that the FSP (and by inclusion, the microcode) were the sum total of what I needed to build my bootloader around.

Regards,

Tom

0 Kudos
Adolfo_S_Intel
Moderator
1,774 Views

Hello Tom_Hartnett

On CDI document 514482, on section 2.1 you can read the following information:

"SPI Flash on Bay Trail SoC has two operational modes: Descriptor and Non-descriptor. Bay Trail Platform supports descriptor mode only.

Non-descriptor mode is not supported in due to all Bay Trail platforms require Intel TXE FW."

As you can see this corroborates the mandatory nature of the TXE firmware.

On the same document on Appendix B, you can see the Software STRAPS that must be enabled to activate the UART

FSP is not the only firmware that you need to create and FSP based firmware, other elements that are necessary includes

VBIOS/GOP (depening on the type of bootloader you are going to implement)

TXE firmware or ME firmware (depending on the architecture of the processor)

This can be corroborated here: http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fsp-iot-royalty-free-firmware-solution-paper.pdf http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fsp-iot-royalty-free-firmware-solution-paper.pdf on page 4, section Other Ingredients of Firmware Stacks Based on Intel® FSP

I am aware that you are not using a reference design, and that you are using your own board. I pointed to Minnowboard as an example, because you can observe their source code and get information of how they enabled their debug port.

Since you have access to Intel Documentation Please take a look at Chapter 38 of document 514148 to see if you are missing any step to the SIO HSUART configuration.

Document CDI# 554416 contains a Sample Implementation of an FSP firmware integrated with Coreboot for the Bayley Bay CRB.

Regarding your Privilege access status, our internal database show that this account only has basic access (Could it be possible that you have privilege access with a different account?)

Best regards,

Adolfo Sanchez

0 Kudos
THart3
Novice
1,774 Views

Adolpho,

I do remember reading (the Bay Trail SPI Flash Programming Guide) 2.1 of 514482 (Mar 2016). But 31.2.1 of (the newer, E3815 Datasheet) 538136 (Jul 2016) is where I got my information about supporting both descriptor mode and non-descriptor mode (if no valid signature is found at offset 10).

Thanks for the pointer (link) to the white paper. I'll absorb it as soon as possible.

I have a few "Intel Embedded" logins. But our privileged "status" needs to be updated because we were recently (October) purchased by another company, and we need to update the NDAs between us and Intel.

Regards,

Tom

0 Kudos
BTest
Novice
1,774 Views

Tom,

I have spent the last 18 months bringing up a custom E3815 design and feel your pain. Before I can really help though I need a couple of questions answered:

1. did you base your design on one of the references, either the BayleyBay (chip down) or BakerSport (socketed memory)?

2. did you put an XDP port in your design?

3. do you have access to the PCU UART pins?

4. are you writing your own bootloader or are you using coreboot?

5. what are you using for PCI Base Addresses for the HSUART? Where did you put IOBASE?

A couple of quick points:

1. You do not need to sign your images or create a manifest but you really do need the TXE image in there. You are better off using the SLIM TXE (543572) and not the full featured one (543570).

2. The earlier E3800 docs stated that you didn't need descriptor based flash (and the earlier steppings allowed this) but a paragraph was added right below that statement saying that you do.

3. There is a debug version of the FSP out there which gives a little (not much) additional information as to why the FSP is failing.

4. The PCU UART, because it is IO mapped, is the best choice for debugging. No PCI setup needed.

5. Even if you are not using it, coreboot it's still a great reference on some of the quirks of this chip. Check out all the files in the fsp_baytrail directory.

Brett

THart3
Novice
1,774 Views

Brett,

Thanks for the reply!

I just got back from vacation.. and I haven't had any time (today) to dive back into this stuff. (I'll dive back in tomorrow.) But I wanted to answer as many of your questions as possible.. as soon as possible. (Most of them are probably NOT what you would have hopped to hear.)

1. It's a memory-down design.

2. XDP port.. No.

3. PCU UART.. No. Only the SIO HSUART.

4. Bootloader.. rolling our own. (But we are familiar with coreboot.)

5. Presently.. the SIO HSUART (Dev30.Fcn3.BAR(10)) is E7000000, and the IOBASE (Dev31.Fcn0.IOBASE(4C)) is E8000000.

I understand about the descriptor for the boot flash. But it's just frustrating that the NEWEST document (I have access to), i.e., the Rev. 4.1 (July 2016) version of the E3815 datasheet, does NOT reflect/incorporate the changes made to the (older) SPI Flash Programming Manual. (And, as an aside, I spent a LOT of time trying to compare differences between the "Datasheet" and the Bay Train "External Design Specification". I came to the conclusion (and I may be completely wrong) that the Datasheet always trumps the EDS.)

I'm really confused about the role of the TXE in the whole architecture. I thought (?) - my words here - that there is, in effect, a microcontroller on the SOC that "gets in the middle" of the whole boot process... and that the TXE is the firmaware for that microcontroller.. but we - I think correctly - coded our descriptor to tell said microcontroller (via the Flash Master Base Address 2 (TXE)) that there is, effectively, no TXE. And our software DOES come out of reset.. and I can do all sorts of things with the GPIO lines that we have brought out on the board.. for as long as I want. (Please understand.. I'm not trying to "argue" the TXE "thing".. I'm just trying to "understand" it.)

Hopefully, I'll have more info tomorrow.

Regards.. and Happy New Year,

Tom

0 Kudos
Adolfo_S_Intel
Moderator
1,774 Views

Hello Tom_Hartnett

The microcontroller is the TXE HW, the main fucntion is to prevent BIOS tampering, the binary is the TXE FW (you can find additional information abot TXE architecture on the CDI544255 document)

Please also make sure that you set the correct FW straps to enable the HS UART.

I hope this information is useful for you.

Best regards,

Adolfo Sanchez

0 Kudos
BTest
Novice
1,774 Views

Hi Tom,

I go back and forth with the TXE. I think you are correct that you don't absolutely have to have it by my guess is someone from Intel will say you do. I do know that the XDP port access to the CPU is locked out without it. There is no harm in having it in there, and the TXE package comes with the Flash Image Tool which is really nice in getting the descriptor table correct and setting the straps. So please take the time to get it from Intel. I think it will save you grief in the long run. All you have to do is have the binary image in there. You do not have to enable any of the features like hashing the images or a manifest table.

As for stating that you have to use descriptor mode, they moved the message around but at the beginning of chapter 31 there is a note that says:

Note:SPI must operate in descriptor mode for correct operation of the SoC.

Live and learn, but I strongly recommend for anyone doing custom hardware: put the XDP port in the design, at least in the prototypes. It has allowed me to do things like beak on writes to IO port 0x80 and see the post codes. Also, use the legacy UART for debug, not the HSUART. (To be fair, our hardware guys did the same thing, wired up the HSUART instead of the legacy. Luckily the legacy UART pins were used for other functions, allowing us to do a bunch of cuts and jumps.)

So drilling down to your HSUART problem, lets start with is it really enabled. Chapter 27.7.10 (pg 4238) of E3800 v4.1 defines the FUNC_DIS register. Make sure that the bits for the HSUART are clear (enabled).

I am assuming you do have copies of the BIOS writers guide - did you go through it in regards to initializing the HSUARTS?

This might be better to take out of the discussion group. Is it possible to PM someone on this site? I have never done it but if so please send me one. Also, what time zone are you in?

Brett

0 Kudos
THart3
Novice
1,774 Views

Brett,

Thanks for the feedback. I had looked at the FUNC_DIS.. and, according to the datasheet, that register defaults to 00000000 (ie, the HSUARTs are enabled). But I'll make SURE they're clear.

I agree that it might be nice to take this "offline" via PM. But I don't see a way of doing that in the context of the embedded.communities.intel.com forum. And I don't know if there are protocol/etiquette issues with me simply giving you my e-mail. (In the interest of (and benefit to) the forum "community," I'd be happy to summarize my experience as part of a historical record.) So.. barring any "you're NOT allowed/supposed to do that" from the forum today, I'll shoot you my e-mail tonight. And I'm in the eastern time zone (GMT-5).

Tom

0 Kudos
THart3
Novice
1,774 Views

You said: "I am assuming you do have copies of the BIOS Writers Guide"

I have documents 514147 and 514148. I'm told that these are the BWGs I need. (Though neither actually mentions the E38xx.)

And I did try enabling the HSUART (Fcn3) in the Function Disable Register. It didn't seem to help.

0 Kudos
BTest
Novice
1,774 Views

Yes, those are the correct BWG. There is also an addendum, 526998.

So by your statement its implying that the HSUART was turned off when you looked at that register, correct?

You mentioned earlier about sending the code, or at least the binary. We are really past the point of debugging this in a public forum. Can you please email me at mailto:brett.testerman@cobham.com brett.testerman@cobham.com (hopefully that didn't violate forum rules!) and we can work on the next steps.

Brett

0 Kudos
THart3
Novice
1,774 Views

Update...

So I've been having no end of fun trying to get our system (E3815 Bay Trail w/ FSP) booted. I was able to talk to the GPOIs (which we use for a watchdog), but couldn't get anything from the HSUART. So I wrote some bit-banging code for the GPIO to turn it into a pseudo (transmit only) UArT.

After a lot of peeking and poking, I finally DID get the HSUART going! It sort of all came down to an error and an omission.

The error was that memory-mapped PCI configuration access (ECAM) (which is the SoC transaction router register BECREG {335}) - whose default is supposed to be 0x00000000 (ie, not assigned and NOT enabled) - was 0xe0000001 (assigned AND enabled).. who knew? At any rate, that conflicted with my choices for the HSUART BAR (0xe7000000) {4188} and the PBASE (0xe6000000) {4539}. I moved them "out of harm's way" and the HSUART registers were at least "visible." (But still not working..)

The omission was that I (evidently) needed to reset the HSUART Reset register (HSUART1 offset 0x804) {4224}. And once I reset the HSUART, it started spewing out characters!

So now my status is that I do FSP's TempRamInit.. it returns a good status (and a reasonable stack base and top). I still program the GPIO (for our watchdog), and I setup the HSUART just to print out some system information (CPUID, select PCI Device/Function configuration data, select MSRs, and a handful of SoC Transaction Router registers).. then I setup the structures to call FSP's FspInit.. then NOTHING! The board just hangs and I eventually get an external watchdog.

Any comments, questions, suggestions welcomed/appreciated!

Regards,

Tom

JBak
Beginner
1,774 Views

Dear Tom:

Thank you for posting your progress in this project. All of this detail will be very helpful for a future project.

Keep fighting the good fight!

0 Kudos
JDood
Novice
1,774 Views

Hi Tom,

My organisation, Ircona (www.ircona.com), area design consultancy firm who have been developing hardware and BIOS solutions for our customer for over 15 years and provide design support for companies who run into difficulties in the development or bring-up of their x86 platforms. We are also an ecosystem partner with Intel for their FSP project and so have a lot of experience with assisting customers who are developing solutions in this area. The fact that we have also successfully completed a large number of x86 motherboard hardware designs mean that we have all the capabilities in-house to assist a speedy resolution to your issues.

If you would like to discuss how Ircona can assist you, please email me at mailto:john.doody@ircona.com john.doody@ircona.com

Thanks

John Doody

CEO

Ircona

0 Kudos
Reply