<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div></div><div><br></div><div><div><div>On 11 Jun 2014, at 12:12, Sean McNeil <<a href="mailto:seanmcneil3@gmail.com">seanmcneil3@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Gerald,<br>
<br>
You should either erase the TXE area or replace it with the
correct one from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE within BIOS
will not play nice with anything except the BIOS.<br>
<br>
Cheers,<br>
Sean<br>
<br>
On 06/11/2014 03:16 PM, Gerald Otter wrote:<br>
</div>
<blockquote cite="mid:7834352D-A01D-461B-BE79-50F8AD6B8050@gmail.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Hi all,
<div><br>
</div>
<div>indeed, I think I misinterpreted the original issue, which is
not solely due to the wrong/lack of microcode being loaded.</div>
<div>I did not get any output on port 80 ( all zeros ). </div>
<div><br>
</div>
<div>I just found out this had to do with the particular intel
flash descriptor/txe I’ve been using, which doesn’t seem to play
nice with my coreboot build.</div>
<div>I’ve been in contact with someone outside of the list who
sent me a working image after my initial e-mail. </div>
<div>I flashed the build with microcode over the top 2MB of his
image, after which my build worked fine. </div>
<div>I assumed it was the microcode, when it was actually (partly)
due to the wrong txe/fd. </div>
<div>When the wrong microcode is loaded, the 4digit display
alternates between 0x66 and 0x07, so you’re right that there
should be output in that case as well.</div>
<div><br>
</div>
<div>Right now I’m not really sure what the differences are
between the working fd/txe I have, and the non-working fd/txe. </div>
<div>If there is any particular version of the txe/fd that is
working while others aren’t, then I’d love to know. </div>
<div>Another option is to erase the fd and txe and just start it
in non-descriptor mode. There are apparently some downsides to
that, but I haven’t looked into the details of that just yet.</div>
<div> </div>
<div>Gerald</div>
<div><br>
</div>
<div>
<div>
<div>On 11 Jun 2014, at 04:09, Sean McNeil <<a moz-do-not-send="true" href="mailto:seanmcneil3@gmail.com">seanmcneil3@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">Hi Marc,<br>
<br>
There is indeed a port80 4 digit hex display on that
board, so Gerald should be getting something from that.<br>
<br>
Hi Gerald,<br>
<br>
If you had serial output from the BIOS, then I think you
probably have the UART connected properly. I always use
the microUSB connector, though, with a standard phone
cable to get serial from those boards. It has an on-board
usb to serial adapter. Coreboot usually sets baud rate to
115200, but it is configurable. Check your .config:<br>
<br>
CONFIG_CONSOLE_SERIAL=y<br>
CONFIG_TTYS0_BASE=0x3f8<br>
CONFIG_CONSOLE_SERIAL_115200=y<br>
CONFIG_TTYS0_BAUD=115200<br>
CONFIG_TTYS0_LCS=3<br>
CONFIG_POST_IO=y<br>
CONFIG_POST_DEVICE=y<br>
CONFIG_POST_DEVICE_NONE=y<br>
CONFIG_POST_IO_PORT=0x80<br>
<br>
Regardless of these settings, FSP will send info to the
port80 so something should have shown.<br>
<br>
Other things you can check:<br>
<br>
1) Properly configured FSP for BayleyBay with the bct
program. BayleyBay is a non-ECC RAM board and won't boot
with ECC FSP.<br>
2) Have the appropriate microcode for your stepping of
CPU. B0 steppings are harder to get correct and the
microcode is not in git.<br>
<br>
Cheers,<br>
Sean<br>
<br>
On 06/11/2014 03:04 AM, Marc Jones wrote:<br>
<blockquote type="cite">Gerald,<br>
<br>
Does the crb have a port80? You should get early
postcodes from<br>
coreboot and the FSP. You are also correct that there
might be<br>
something different in the descriptor.bin that isn't
anticipated. You<br>
may want to use the coreboot util/ifdtool to get a look
at the entire<br>
image.<br>
<br>
Marc<br>
<br>
<br>
On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter <<a moz-do-not-send="true" href="mailto:gerald.otter@gmail.com">gerald.otter@gmail.com</a>>
wrote:<br>
<blockquote type="cite">Hi all,<br>
<br>
I am trying to run coreboot + seabios payload on the
bayley bay crb with the recently committed FSP
integration, but have had no luck so far.<br>
This crb uses the bay trail I (now atom e3800) soc
from intel.<br>
<br>
Following the instructions from commit d75800c7f , I
have built a 2MB image and flashed it to the upper 2MB
of the 8MB flash, leaving the TXE / flash descriptor
intact.<br>
I have added the config from the build. The FSP I used
is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together
with the flash descriptor and TXE from the 80.21 bios
provided by intel, and vga bios 36.2.2.<br>
Fwiw, I have tried both the 32bit and 64bit releases
of the bios, even though the flash descriptor and TXE
binary seem to be exactly the same.<br>
<br>
The issue I’m running into is that I have no idea if
anything is running at all.<br>
There is no output on the VGA/HDMI ports or uart.<br>
<br>
The legacy uart referred to in the source is working
correctly with the original intel bios, but does not
produce any output with the coreboot image.<br>
I have tried the most common baud rates (115200,
19200, 9600 ) and did some measurements with a scope
in case I got the baud rate wrong, but no cigar.<br>
The uart I’m using is the PCU uart, as opposed to
hsuart1/2 and the superIO uart. This matches with the
configuration in coreboot when compared to the
datasheet, so I’m assuming I got this set up
correctly.<br>
Unfortunately, this is about all the information I
have, so I hope I am missing something obvious when
building the image / flashing it, etc.<br>
<br>
I have also used intel’s flash image tool (fitc) to
build a complete image, thinking that maybe the flash
descriptor needed to contain some specific information
regarding the coreboot image (size/checksums), but
given the original instructions I wasn’t surprised
this didn’t work.<br>
<br>
Thanks in advance!<br>
<br>
<br>
--<br>
coreboot mailing list: <a moz-do-not-send="true" href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a moz-do-not-send="true" href="http://www.coreboot.org/mailman/listinfo/coreboot">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
--<span class="Apple-converted-space"> </span><br>
coreboot mailing list:<span class="Apple-converted-space"> </span><a moz-do-not-send="true" href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a moz-do-not-send="true" href="http://www.coreboot.org/mailman/listinfo/coreboot">http://www.coreboot.org/mailman/listinfo/coreboot</a></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br></div></body></html>