Hi,
One of the qemu developers added AHCI support to SeaBIOS. This
support has been tested on qemu, but not on real hardware. It would
be great if folks with coreboot supported hardware could also test it.
(Unfortunately, my coreboot board doesn't have AHCI.)
To test, grab the latest seabios git (see: http://seabios.org/Download
), edit src/config.h and enable CONFIG_AHCI. (Be sure to also set the
other coreboot settings - see: http://www.coreboot.org/SeaBIOS .)
Thanks,
-Kevin
Hello.
This patch works for me but needs a small function calc_id_buffer for
each board/cpu/whatever. I only made one for amd quadcore because it
is what I have. My board does not get to ramstage, so it might not
work there. It works for my serial console but should work for net or
usb if I'm not mistaken. Also my tree is not up to date with svn
head. Likely things could be placed elsewhere or done better, so it
is mostly an idea.
But I'm unlikely to have more time for it and it works for me so far,
so I'm sending it so that it does not get lost and in case somebody
likes the idea and wants to commit or do it better.
Signed-off-by: Xavi Drudis Ferran <xdrudis(a)tinet.cat>
My problem was with having serial output like
[...]
init node: 00 cores: 03
Start other core - nodeid: 00 cores: 03
start_other_cores() retuPPPrOOOnSSSeTTTd:::
P000OxxxST3:330 00
0
x3 7cc
cosootrrraeeexxxr:::t e d-- --a---p-- {{a{ p iAAAPPPcIIIiCCdCI:IID DD === 000231 NNNOOODDDEEEIIIDDD === 000000 CCCOOORRREEEIIIDDD === 000312}}} ---------
[...]
So I changed it because I like it better like this:
[...]
����������������������������������������������������������������
[...]
which is ugly, slow, etc. but I can pipe it to a little script which turns it back into
almost the original ("boooh!!!" :( )
or writes it a little nicer ( :) )
[...]
core0:init node: 00 cores: 03
core0:Start other core - nodeid: 00 cores: 03
core0:start_other_cores() returned
core1:POST:
core2:POST:
core3:POST:
core0:POST:
core1: 0x30
core2: 0x30
core3: 0x30
core0:0
core0:x37
core2: c
core3: c
core0:started ap apicid:
core1:corex: --- { APICID = 01 NODEID = 00 COREID = 01} ---
core2:orex: --- { APICID = 02 NODEID = 00 COREID = 02} ---
core3:orex: --- { APICID = 03 NODEID = 00 COREID = 03} ---
[...]
or even ( :) )
[...]
init node: 00 cores: 03| | |
| | |
Start other core - nodei| | |
d: 00 cores: 03 | | |
start_other_cores() retu|P |P |P
rned |OST: |OST: |OST:
POST: | 0x30 | 0x30 | 0x30
0 | | |
| | |
x37 | | c | c
started ap apicid: |corex: --- { APICID = 0|orex: --- { APICID = 02|orex: --- { APICID = 03
|1 NODEID = 00 COREID = 0| NODEID = 00 COREID = 0 | NODEID = 00 COREID = 03
|1} --- |2} --- |} ---
| | |
[...]
or other options to if you fancy.
I observed characters from each core got mixed but bits from each
character not, so the superIO or someone probably did alreday
synchronize bytes correctly. So I could split each byte in two, add a
4 bit buffer id and pretend each core has a different serial port and
I'm multiplexing up to 16 channels for up to 16 cores into one
physical serial port, by sending together the channel/buffer id with
the character (4 bits buffer id, 4 bits half character). Then a small
perl script demultiplexes each channel into a different buffer and
formats output. If someone has more than 16 cores does she really
want to see ouput from all at a time? Redefining the weak function
calc_id_buffer you can choose to have some of them mix into the same
buffer or just filter out the output for some of them.
Hope the patch is simple enough, else I can explain more later.
I must leave now.
Hello,
Attached patch fixes the LPC decode ranges of SB700. We enable early only
Serial/SIO/RTC. Everything else needs to be done by lpc.c Problem was that early
settings survived, because the lpc.c is doing ORs only...
Hence we decode quite a lot and even strange ranges like IO port 0x4600 etc...
Also, if some port which does not fit to predefined set is requested, like 0x290
for Hardware monitor, the wide port is done, but in our case it has range 512
bytes which means we decode in fact 0x290 - 0x490. And if we hit GPU in the
0x3bx range I receive MCE exception if I do isadump -f 0x300 which is bad.
Therefore If I detect that the requested range is small (16 bytes) I
additionally set the small wide io region so only 16 bytes is decoded.
While at it, I fix spelling typos and I init the regs so we don't write random
garbage to regs even if we don't enable them later.
Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz>
Thanks,
Rudolf
Hello!
I've tried to install Coreboot/SeaBIOS on my ASRock 939A785GMH/128M
motherboard [1], leaving it totally unbootable: no beeps, no VGA output :-(
I followed installation instructions from coreboot.org with SVN checkout,
"make menuconfig" and "make". The payload is SeaBIOS stable.
BTW, what makes me suspicious is a build process, the first "make" failed
with:
<...>
Compiling (16bit) out/code16.o
Building ld scripts (version "0.6.1.2-20110129_195624-innsmouth")
Building ld scripts (version "0.6.1.2-20110129_195624-innsmouth")
Building ld scripts (version "0.6.1.2-20110129_195624-innsmouth")
Traceback (most recent call last):
File "./tools/layoutrom.py", line 436, in <module>
main()
File "./tools/layoutrom.py", line 428, in main
keep16[0], keep32seg[0], keep32flat[0])
File "./tools/layoutrom.py", line 161, in doLayout
locs16fixed, firstfixed = fitSections(fixedsections, textsections)
File "./tools/layoutrom.py", line 141, in fitSections
firstfixed = fixedsections[0][0]
IndexError: list index out of range
make[2]: *** [out/romlayout16.lds] Error 1
make[2]: *** Waiting for unfinished jobs....
Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2%
16bit size: 39872
32bit segmented size: 2529
32bit flat size: 54383
Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2%
16bit size: 39872
32bit segmented size: 2529
32bit flat size: 54383
make[2]: *** wait: Нет дочерних процессов. Stop.
make[1]: *** [seabios] Error 2
make: *** [seabios] Error 2
However, the subsequent "make clean" and "make" ended up with success:
<...>
Compiling (16bit) out/code16.o
Building ld scripts (version "0.6.1.2-20110129_200005-innsmouth")
Building ld scripts (version "0.6.1.2-20110129_200005-innsmouth")
Building ld scripts (version "0.6.1.2-20110129_200005-innsmouth")
Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2%
16bit size: 39872
32bit segmented size: 2529
32bit flat size: 54383
Building ld scripts (version "0.6.1.2-20110129_200005-innsmouth")
Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2%
16bit size: 39872
32bit segmented size: 2529
32bit flat size: 54383
Linking out/rom16.o
Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2%
16bit size: 39872
32bit segmented size: 2529
32bit flat size: 54383
Linking out/rom32seg.o
Stripping out/rom32seg.strip.o
Stripping out/rom16.strip.o
Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2%
16bit size: 39872
32bit segmented size: 2529
32bit flat size: 54383
Linking out/rom.o
Prepping out/bios.bin
Total size: 96784 Free space: 34288 Percent used: 73.8% (128KiB rom)
CBFS coreboot.rom
PAYLOAD SeaBIOS (internal, compression: LZMA)
CBFSPRINT coreboot.rom
After that I copied build/coreboot.rom onto USB flash and installed it on
motherboard's flash successfully using "flashrom -w coreboot.rom". The
motherboard's chip is Winbond W25Q80, 1024 KB (this size is a default in
menuconfig, so I didn't changed it).
I will answer more questions if it's needed.
I'd also appreciate any help or hints on recovery, because now I can't even
boot. I tried that trick with AMIBOOT.ROM on USB flash and <Ctrl>+<Home>, but
it didn't worked for me.
Thanks in advance for your help!
[1] http://www.coreboot.org/ASRock_939A785GMH-128M
Dear coreboot readers!
This is the automatic build system of coreboot.
The developer "oxygene" checked in revision 6320 to
the coreboot repository. This caused the following
changes:
Change Log:
Replace special rules for auxiliary files by cbfs-files-y entries
VGABIOS, Intel MBI and the bootsplash image were added with special
build rules. These are replaced by generic cbfs-files-y entries now.
Signed-off-by: Patrick Georgi <patrick.georgi(a)secunet.com>
Acked-by: Peter Stuge <peter(a)stuge.se>
Build Log:
Compilation of compaq:deskpro_en_sff_p600 has been fixed
If something broke during this checkin please be a pain
in oxygene's neck until the issue is fixed.
If this issue is not fixed within 24h the revision should
be backed out.
Best regards,
coreboot automatic build system
