Hi all,
indeed, I think I misinterpreted the original issue, which is
not solely due to the wrong/lack of microcode being loaded.
I did not get any output on port 80 ( all zeros ).
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.
I’ve been in contact with someone outside of the list who
sent me a working image after my initial e-mail.
I flashed the build with microcode over the top 2MB of his
image, after which my build worked fine.
I assumed it was the microcode, when it was actually (partly)
due to the wrong txe/fd.
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.
Right now I’m not really sure what the differences are
between the working fd/txe I have, and the non-working fd/txe.
If there is any particular version of the txe/fd that is
working while others aren’t, then I’d love to know.
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.
Gerald
Hi Marc,
There is indeed a port80 4 digit hex display on that
board, so Gerald should be getting something from that.
Hi Gerald,
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:
CONFIG_CONSOLE_SERIAL=y
CONFIG_TTYS0_BASE=0x3f8
CONFIG_CONSOLE_SERIAL_115200=y
CONFIG_TTYS0_BAUD=115200
CONFIG_TTYS0_LCS=3
CONFIG_POST_IO=y
CONFIG_POST_DEVICE=y
CONFIG_POST_DEVICE_NONE=y
CONFIG_POST_IO_PORT=0x80
Regardless of these settings, FSP will send info to the
port80 so something should have shown.
Other things you can check:
1) Properly configured FSP for BayleyBay with the bct
program. BayleyBay is a non-ECC RAM board and won't boot
with ECC FSP.
2) Have the appropriate microcode for your stepping of
CPU. B0 steppings are harder to get correct and the
microcode is not in git.
Cheers,
Sean
On 06/11/2014 03:04 AM, Marc Jones wrote:
Gerald,
Does the crb have a port80? You should get early
postcodes from
coreboot and the FSP. You are also correct that there
might be
something different in the descriptor.bin that isn't
anticipated. You
may want to use the coreboot util/ifdtool to get a look
at the entire
image.
Marc
On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter <gerald.otter@gmail.com>
wrote:
Hi all,
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.
This crb uses the bay trail I (now atom e3800) soc
from intel.
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.
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.
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.
The issue I’m running into is that I have no idea if
anything is running at all.
There is no output on the VGA/HDMI ports or uart.
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.
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.
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.
Unfortunately, this is about all the information I
have, so I hope I am missing something obvious when
building the image / flashing it, etc.
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.
Thanks in advance!
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list:
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot