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