On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote:
> > On Sat, Feb 20, 2010 at 9:05 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> >> Should a kernel fail during boot, I'd suspect it doesn't like one of
> >> the apm/pcibios callbacks, or it doesn't like one of the
> >> smbios/mptable/acpi tables. You could try compiling the SeaBIOS code
> >> (see http://seabios.org/Download ) and increasing the debugging by
> >> modifying src/config.h. Specifically, you could increase
> >> CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to
> >> 1. Also, you could try disabling some of the features to see if that
> >> prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS /
> >> CONFIG_MPTABLE).
> >
>
> I have narrowed it down to SMBIOS. If I disable CONFIG_SMBIOS the
> image boots up fine.
Gleb, have you seen this thread?
Some of the recent changes to smbios that look like possible culprits
are:
Make SMBIOS table pass MS SVVP test
Use MaxCountCPUs during building of per cpu tables.
Add malloc_high/fseg() and rework bios table creation to use them.
There were other changes, but the comments indicate they were only
ports of changes already in bochs. I suppose it's also possible the
lack of smbios is turning off some other feature in the guest (eg,
acpi) that's the real culprit.
-Kevin
Without this BIOS fails to remap 0xf0000 memory from ROM to RAM so writes
to F-segment modify ROM content instead of memory copy. Since QEMU does
not reloads ROMs during reset on next boot modified copy of BIOS is used.
Signed-off-by: Gleb Natapov <gleb(a)redhat.com>
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 933ad86..0bf435d 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -99,10 +99,6 @@ static void i440fx_update_memory_mappings(PCII440FXState *d)
int i, r;
uint32_t smram, addr;
- if (kvm_enabled()) {
- /* FIXME: Support remappings and protection changes. */
- return;
- }
update_pam(d, 0xf0000, 0x100000, (d->dev.config[I440FX_PAM] >> 4) & 3);
for(i = 0; i < 12; i++) {
r = (d->dev.config[(i >> 1) + (I440FX_PAM + 1)] >> ((i & 1) * 4)) & 3;
--
Gleb.
Hi,
I add one config 'IDE_TO_AHCI' in 'src\Kconfig' and modify 'src\ata.c'.
Please help me to review and check-in.
This 'IDE_TO_AHCI' function can let SeaBIOS handle AHCI controller as
IDE controller when 'ATA' enable, and also let Windows OS to load AHCI
inbox driver or chipset vender's AHCI driver. In other words, it means
that SATA Hard Disk ran as IDE mode in SeaBIOS but AHCI mode in Windows
OS.
Attached file: A.patch B.patch.
Signed-off-by: Alex Chuang <Alex.Chuang(a)amd.com>
Best regards,
Alex
Hi,
This patch set switches seabios to a two-pass pci initialization.
The first pass figures the memory requirements which are then used by
the second pass to pack the regions.
I've splitted it into two patches to make it easy to check out. The
first patch does all the calculations and prints what it would do to the
debug log. The second patch switches the new allocation code live.
The patches have been tested with the upcoming q35 emulation for qemu.
They are based on the q35 seabios too, but rebasing to master shouldn't
be hard.
Below you can see the allocations created by the patch.
Comments?
cheers,
Gerd
========== /proc/iomem ==============
00000000-00000fff : reserved
00001000-0009e7ff : System RAM
0009e800-0009ffff : reserved
000c0000-000c8bff : Video ROM
000c9000-000c97ff : Adapter ROM
000f0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-3fffcfff : System RAM
01000000-014e5a17 : Kernel code
014e5a18-01ba42ef : Kernel data
01ce4000-01f474e3 : Kernel bss
3fffd000-3fffffff : reserved
e0000000-efffffff : PCI MMCONFIG 0 [00-ff]
e0000000-efffffff : reserved
fa000000-fbffffff : 0000:00:02.0
fa000000-fbffffff : cirrusfb
fc000000-fc3fffff : PCI Bus 0000:0c
fc000000-fc0fffff : PCI Bus 0000:0d
fc100000-fc1fffff : PCI Bus 0000:0e
fc200000-fc2fffff : PCI Bus 0000:0f
fc300000-fc3fffff : PCI Bus 0000:10
fc400000-fc4fffff : PCI Bus 0000:01
fc500000-fc5fffff : PCI Bus 0000:02
fc600000-fc6fffff : PCI Bus 0000:03
fc600000-fc6fffff : PCI Bus 0000:04
fc600000-fc6fffff : PCI Bus 0000:05
fc700000-fc7fffff : PCI Bus 0000:06
fc800000-fc8fffff : PCI Bus 0000:07
fc900000-fc9fffff : PCI Bus 0000:08
fca00000-fcafffff : PCI Bus 0000:09
fcb00000-fcbfffff : PCI Bus 0000:0a
fcc00000-fccfffff : PCI Bus 0000:0b
fdc00000-fdffffff : PCI Bus 0000:0c
fdc00000-fdcfffff : PCI Bus 0000:0d
fdd00000-fddfffff : PCI Bus 0000:0e
fde00000-fdefffff : PCI Bus 0000:0f
fdf00000-fdffffff : PCI Bus 0000:10
fe000000-fe0fffff : PCI Bus 0000:01
fe100000-fe1fffff : PCI Bus 0000:02
fe200000-fe2fffff : PCI Bus 0000:03
fe200000-fe2fffff : PCI Bus 0000:04
fe200000-fe2fffff : PCI Bus 0000:05
fe300000-fe3fffff : PCI Bus 0000:06
fe400000-fe4fffff : PCI Bus 0000:07
fe500000-fe5fffff : PCI Bus 0000:08
fe600000-fe6fffff : PCI Bus 0000:09
fe700000-fe7fffff : PCI Bus 0000:0a
fe800000-fe8fffff : PCI Bus 0000:0b
fe900000-fe90ffff : 0000:00:02.0
fe910000-fe91ffff : 0000:00:03.0
fe920000-fe920fff : 0000:00:02.0
fe920000-fe920fff : cirrusfb
fe921000-fe921fff : 0000:00:03.0
fe921000-fe921fff : virtio-pci
fe922000-fe922fff : 0000:00:1f.2
fe922000-fe922fff : ahci
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
fee00000-fee00fff : Local APIC
feffc000-feffffff : reserved
fffc0000-ffffffff : reserved
Hello:
I was instructed to send mail to you by Carebear from #coreboot.
I have some issues to report based on the "Golden Image" I received from
him, which was created for the ASRock E350M1.
The first is with hard drive detection - there is a reliability problem
here - only once out of every 5 to 12 times the machine posts will it
detect the hard drive successfully.
The hard drive is a Corsair F120 SSD. I do have another, smaller 16GB
Kingston SSD I can test with.
The second problem is that on booting, GRUB (I do not have the version
on hand -- whatever gentoo is shipping as stable at this point) behaves
very, very strangely with my USB keyboard.
I should point out that it does not work 100% correctly on another
machine under Fedora's grub, so this may bear further testing with
another keyboard.
The following video demonstrates the issue - this is very reproduceable
(I gave exactly this input on the keyboard: "<down>, e, hello there,
test, one, two, three", and only once. You can hear the clicking of my
keyboard.)
http://www.lucidmachines.com/coreboot/weird-usb-in-grub.avi
I will be traveling until May 31st, and so unable to reply to mail until
then, but I do look forward to working with you all on this.
Thank you!
-Marshall Buschman
As you may know we (the Xen project) are hoping to transition to SeaBIOS
at the same time as we transition to the recently upstreamed qemu
support for Xen.
The following patches add very basic support for running SeaBIOS as the
BIOS for a Xen HVM (fully virtualised) guest.
These patches really do very little but they are sufficient to allow me
to boot an HVM Linux guest to a prompt. SeaBIOS boots indirectly as an
hvmloader payload with the first patch and directly if using the second
(this second case requires a short patch series on the Xen side, see
[0]).
This is presented more as a proof of concept since it's not obvious yet
which approach will be best from either Xen or SeaBIOS's point of view.
I'm generally leaning towards the second option since much of the setup
currently done in hvmloader appears to be more down to the limitations
of ROMBIOS than any particular design decision. For example SeaBIOS is
perfectly happy loading option ROMS from the appropriate BAR so that
aspect of hvmloader goes away entirely, similarly with building ACPI,
SMBIOS, MP tables etc. I'd be glad to hear any opinions from either side
on the matter.
One problem I have with the first patch is that I'm lacking the
vocabulary to describe the configuration which is currently represented
by COREBOOT=n. I wanted to switch the coreboot option to a Kconfig
choice (so I can add XEN as another option) so I needed a name for the
other option. I went with GENERIC but I've no idea if that is accurate.
Is "EMULATOR" more accurate? Suggestions welcome.
FWIW I expect (however naive it might be to make such predictions) the
majority of the work to integrate SeaBIOS into Xen (other than test,
test and more test with different OSes) will be to understand he
differences in the various BIOS tables and figure out what is "just
because", what represents real bug fixes on one side or the other, what
is actually down to implementation details in Xen and what is down to
differences between the old qemu-xen and upstream qemu. Having worked
through all that I hope that actually finding a clean way to integrate
the differences with SeaBIOS (or possibly qemu) will be comparatively
trivial...
Ian.
[0]
http://lists.xensource.com/archives/html/xen-devel/2011-05/msg00770.html
Sven Schnelle <svens(a)stackframe.org> writes:
> Hi Setfan,
>
> Stefan Reinauer <stefan.reinauer(a)coreboot.org> writes:
>
>> * Sven Schnelle <svens(a)stackframe.org> [110503 21:41]:
>>> Stefan Reinauer <stefan.reinauer(a)coreboot.org> writes:
>>> > Can you do a new analysis on where the boot time goes now? It would be
>>> > nice to see if there are more optimizations we can do...
>>>
>>> Will do. But right now i have the problem that the Keyboard isn't
>>> working on cold boot - seabios is probably started so early that some
>>> hardware parts are not finished with reset or similar things.
>>>
>>> Just enabling debug output in coreboot slows down things enough to
>>> make the Keyboard working again.
>>
>> Does just putting in a delay of some 100ms fix the issue, too? Do you do
>> keyboard init in coreboot? Did you do it before?
>> Just want to make sure there are no side effects coming in through
>> debugging. However, having an EC/SuperIO that needs more than 200ms to boot up
>> does not sound too unlikely.
>
> I do not initialize the Keyboard in coreboot, i'll leave that to
> seabios. (Enabling it in coreboot doesn't help either).
>
>>> The original Vendor BIOS talks after around ~1s to the Keyboard
>>> controller, so that's quite different to coreboot (coreboot is handing
>>> over to seabios after ~200ms)
>>
>> Getting through all of coreboot in as little as 200ms? This is totally
>> awesome!
>>
>>> So i want to figure out first if there's some
>>> 'i-finished-reset-you-can-talk-to-me' flag, or if that problem is caused
>>> by another reason.
>>
>> Does the keyboard init code get any type of timeout?
>
>
> Well, i've enabled some debugging in seabios, and it's pretty obvious
> what's happening here. SeaBIOS sends command 0xff (which is RESET i
> think), and SeabIOS gets 0xfe as response (which is RESEND, but seabios
> handles that as NAK, and doesn't resend the command).
>
> You can find the boot log here:
>
> http://stackframe.org/seriallog-20110503_175245.log
I've just modified seabios to resend commands when 0xfe is received as a
quick hack. It makes my keyboard working again. I'm not sure if SeabIOS
should handle 0xfe as RESEND or not - have not monitored much Keyboards,
and don't know wether this has any side effects.
The boot log can be found here:
http://stackframe.org/seriallog-20110504_100837.log
The diff i've made to seabios is: (beware, it's just an ugly hack just for
testing)
diff --git a/src/ps2port.c b/src/ps2port.c
index d1e6d48..a4cd4de 100644
--- a/src/ps2port.c
+++ b/src/ps2port.c
@@ -186,7 +186,8 @@ ps2_recvbyte(int aux, int needack, int timeout)
static int
ps2_sendbyte(int aux, u8 command, int timeout)
{
- dprintf(7, "ps2_sendbyte aux=%d cmd=%x\n", aux, command);
+resend:
+ dprintf(7, "ps2_sendbyte aux=%d cmd=%x\n", aux, command);
int ret;
if (aux)
ret = i8042_aux_write(command);
@@ -199,6 +200,8 @@ ps2_sendbyte(int aux, u8 command, int timeout)
ret = ps2_recvbyte(aux, 1, timeout);
if (ret < 0)
return ret;
+ if (ret == 0xfe)
+ goto resend;
if (ret != PS2_RET_ACK)
return -1;
@@ -232,7 +235,7 @@ __ps2_command(int aux, int command, u8 *param)
ret = i8042_command(I8042_CMD_CTL_WCTR, &newctr);
if (ret)
goto fail;
-
+resend:
if (command == ATKBD_CMD_RESET_BAT) {
// Reset is special wrt timeouts and bytes received.
@@ -243,10 +246,14 @@ __ps2_command(int aux, int command, u8 *param)
// Receive parameters.
ret = ps2_recvbyte(aux, 0, 4000);
+ if (ret == 0xfe)
+ goto resend;
if (ret < 0)
goto fail;
param[0] = ret;
ret = ps2_recvbyte(aux, 0, 100);
+ if (ret == 0xfe)
+ goto resend;
if (ret < 0)
// Some devices only respond with one byte on reset.
ret = 0;
@@ -261,6 +268,8 @@ __ps2_command(int aux, int command, u8 *param)
// Receive parameters.
ret = ps2_recvbyte(aux, 0, 500);
+ if (ret == 0xfe)
+ goto resend;
if (ret < 0)
goto fail;
param[0] = ret;
@@ -268,6 +277,8 @@ __ps2_command(int aux, int command, u8 *param)
|| ret == 0x60 || ret == 0x47) {
// These ids (keyboards) return two bytes.
ret = ps2_recvbyte(aux, 0, 500);
+ if (ret == 0xfe)
+ goto resend;
if (ret < 0)
goto fail;
param[1] = ret;
@@ -291,6 +302,8 @@ __ps2_command(int aux, int command, u8 *param)
// Receive parameters (if any).
for (i = 0; i < receive; i++) {
ret = ps2_recvbyte(aux, 0, 500);
+ if (ret == 0xfe)
+ goto resend;
if (ret < 0)
goto fail;
param[i] = ret;
It is theorectically possible for a system to have more than
one pci vga card. In particular, I am interested in the use of SGAbios
as a pci device, alongside of a normal vga bios in QEMU.
This patch makes seabios continue searching the pci range looking for
vga cards, even if it finds one. The first card to be found is assigned
to VGAbdf, being the main one. The others, just have their initializatiom
roms called and are listed in the pci bus.
Signed-off-by: Glauber Costa <glommer(a)redhat.com>
---
src/optionroms.c | 11 ++++++++---
src/pci.c | 6 ++++--
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index 37a4e6c..2d0a258 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -462,13 +462,18 @@ vga_setup(void)
// Option roms are already deployed on the system.
init_optionrom((void*)BUILD_ROM_START, 0, 1);
} else {
+ int bdf;
// Clear option rom memory
memset((void*)RomEnd, 0, _max_rom() - RomEnd);
// Find and deploy PCI VGA rom.
- int bdf = VGAbdf = pci_find_vga();
- if (bdf >= 0)
- init_pcirom(bdf, 1, NULL);
+ do {
+ bdf = pci_find_vga();
+ if (!VGAbdf)
+ VGAbdf = bdf;
+ if (bdf >= 0)
+ init_pcirom(bdf, 1, NULL);
+ } while ((bdf >= 0))
// Find and deploy CBFS vga-style roms not associated with a device.
run_file_roms("vgaroms/", 1, NULL);
diff --git a/src/pci.c b/src/pci.c
index 944a393..6f124cf 100644
--- a/src/pci.c
+++ b/src/pci.c
@@ -107,7 +107,9 @@ pci_next(int bdf, int *pmax)
int
pci_find_vga(void)
{
- int bdf = 0x0000, max = 0x0100;
+ static int bdf;
+ int max = 0x0100;
+
for (;;) {
if (bdf >= max) {
if (CONFIG_PCI_ROOT1 && bdf <= (CONFIG_PCI_ROOT1 << 8))
@@ -132,7 +134,7 @@ pci_find_vga(void)
u16 cmd = pci_config_readw(bdf, PCI_COMMAND);
if (cmd & PCI_COMMAND_IO && cmd & PCI_COMMAND_MEMORY)
// Found active vga card
- return bdf;
+ return bdf++;
}
// Check if device is a bridge.
--
1.7.4.2
Hi,
I add one config 'IDE_TO_AHCI' in 'seabios\src\Kconfig' and modify
'seabios\src\ata.c'. Please help me to review and check-in.
This 'IDE_TO_AHCI' function can let SeaBIOS handle AHCI controller as
IDE controller when 'ATA' enable, and also let Windows OS to load AHCI
inbox driver or chipset vender's AHCI driver. In other words, it means
that SATA Hard Disk ran as IDE mode in SeaBIOS but AHCI mode in Windows
OS.
Best regards,
Alex
In 'seabios\src\Kconfig':
menu "Hardware support"
config ATA
depends on DRIVES
bool "ATA controllers"
default y
help
Support for IDE disk code.
config ATA_DMA
depends on ATA
bool "ATA DMA"
default n
help
Detect and try to use ATA bus mastering DMA controllers.
config ATA_PIO32
depends on ATA
bool "ATA 32bit PIO"
default n
help
Use 32bit PIO accesses on ATA (minor optimization on PCI
transfers).
config IDE_TO_AHCI
<- New add.
depends on ATA
<- New add.
bool "IDE to AHCI support"
<- New add.
default n
<- New add.
help
<- New add.
Handle AHCI controller as ATA controller when POST. <- New
add.
config AHCI
depends on DRIVES
bool "AHCI controllers"
default n
help
Support for AHCI disk code.
In 'seabios\src\ata.c':
static void
ata_init(void)
{
// Scan PCI bus for ATA adapters
int count=0, pcicount=0;
int bdf, max;
foreachpci(bdf, max) {
pcicount++;
if (pci_config_readw(bdf, PCI_CLASS_DEVICE) !=
PCI_CLASS_STORAGE_IDE)
if ((! CONFIG_IDE_TO_AHCI) ||
(pci_config_readw(bdf, PCI_CLASS_DEVICE) != 0x0106)) <- New add.
continue;
u8 pciirq = pci_config_readb(bdf, PCI_INTERRUPT_LINE);
u8 prog_if = pci_config_readb(bdf, PCI_CLASS_PROG);
if (CONFIG_IDE_TO_AHCI && (pci_config_readw(bdf,
PCI_CLASS_DEVICE) == 0x0106)) <- New add.
prog_if = 0x8F;
<- New add.
int master = 0;
