[SeaBIOS] [RFC v2 2/3] pci_device: Add pci domain support

2018-08-08 Thread Zihan Yang
Most part of seabios assume only PCI domain 0. This patch adds support
for multiple domain in pci devices, which involves some API changes.

For compatibility, interfaces such as pci_config_read[b|w|l] still exist
so that existing domain 0 devices needs no modification, but whenever a
device wants to reside in different domain, it should add *_dom suffix to
above functions, e.g, pci_config_readl_dom(..., domain_nr) to read from
specific host bridge other than q35 host bridge. Also, the user should
check the device domain when using foreachpci() macro to fileter undesired
devices that reside in a different domain.

Signed-off-by: Zihan Yang 
---
 src/fw/coreboot.c  |   2 +-
 src/fw/csm.c   |   2 +-
 src/fw/paravirt.c  |   2 +-
 src/fw/pciinit.c   | 261 ++---
 src/hw/pci.c   |  69 +++---
 src/hw/pci.h   |  42 ++---
 src/hw/pci_ids.h   |   7 +-
 src/hw/pcidevice.c |   8 +-
 src/hw/pcidevice.h |   4 +-
 9 files changed, 227 insertions(+), 170 deletions(-)

diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c
index 7c0954b..c955dfd 100644
--- a/src/fw/coreboot.c
+++ b/src/fw/coreboot.c
@@ -254,7 +254,7 @@ coreboot_platform_setup(void)
 {
 if (!CONFIG_COREBOOT)
 return;
-pci_probe_devices();
+pci_probe_devices(0);
 
 struct cb_memory *cbm = CBMemTable;
 if (!cbm)
diff --git a/src/fw/csm.c b/src/fw/csm.c
index 03b4bb8..e94f614 100644
--- a/src/fw/csm.c
+++ b/src/fw/csm.c
@@ -63,7 +63,7 @@ static void
 csm_maininit(struct bregs *regs)
 {
 interface_init();
-pci_probe_devices();
+pci_probe_devices(0);
 
 csm_compat_table.PnPInstallationCheckSegment = SEG_BIOS;
 csm_compat_table.PnPInstallationCheckOffset = get_pnp_offset();
diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index 6b14542..ef4d487 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -155,7 +155,7 @@ qemu_platform_setup(void)
 return;
 
 if (runningOnXen()) {
-pci_probe_devices();
+pci_probe_devices(0);
 xen_hypercall_setup();
 xen_biostable_setup();
 return;
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 6e6a434..fcdcd38 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -51,6 +51,7 @@ u64 pcimem_end = BUILD_PCIMEM_END;
 u64 pcimem64_start = BUILD_PCIMEM64_START;
 u64 pcimem64_end   = BUILD_PCIMEM64_END;
 u64 pci_io_low_end = 0xa000;
+u64 pxb_mcfg_size  = 0;
 
 struct pci_region_entry {
 struct pci_device *dev;
@@ -88,9 +89,9 @@ static void
 pci_set_io_region_addr(struct pci_device *pci, int bar, u64 addr, int is64)
 {
 u32 ofs = pci_bar(pci, bar);
-pci_config_writel(pci->bdf, ofs, addr);
+pci_config_writel_dom(pci->bdf, ofs, addr, pci->domain_nr);
 if (is64)
-pci_config_writel(pci->bdf, ofs + 4, addr >> 32);
+pci_config_writel_dom(pci->bdf, ofs + 4, addr >> 32, pci->domain_nr);
 }
 
 
@@ -405,25 +406,29 @@ static void pci_bios_init_device(struct pci_device *pci)
 
 /* map the interrupt */
 u16 bdf = pci->bdf;
-int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN);
+int pin = pci_config_readb_dom(bdf, PCI_INTERRUPT_PIN, pci->domain_nr);
 if (pin != 0)
-pci_config_writeb(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, pin));
+pci_config_writeb_dom(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, 
pin),
+  pci->domain_nr);
 
 pci_init_device(pci_device_tbl, pci, NULL);
 
 /* enable memory mappings */
-pci_config_maskw(bdf, PCI_COMMAND, 0,
- PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_SERR);
+pci_config_maskw_dom(bdf, PCI_COMMAND, 0,
+ PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_SERR,
+ pci->domain_nr);
 /* enable SERR# for forwarding */
 if (pci->header_type & PCI_HEADER_TYPE_BRIDGE)
-pci_config_maskw(bdf, PCI_BRIDGE_CONTROL, 0,
- PCI_BRIDGE_CTL_SERR);
+pci_config_maskw_dom(bdf, PCI_BRIDGE_CONTROL, 0,
+ PCI_BRIDGE_CTL_SERR, pci->domain_nr);
 }
 
-static void pci_bios_init_devices(void)
+static void pci_bios_init_devices(int domain_nr)
 {
 struct pci_device *pci;
 foreachpci(pci) {
+if (pci->domain_nr != domain_nr)
+continue;
 pci_bios_init_device(pci);
 }
 }
@@ -520,6 +525,10 @@ static void pxb_mem_addr_setup(struct pci_device *dev, 
void *arg)
  * read mcfg_base and mcfg_size from it just now. Instead, we directly add
  * this item to e820 */
 e820_add(mcfg_base.val, mcfg_size, E820_RESERVED);
+
+/* Add PXBHosts so that we can can initialize them later */
+++PXBHosts;
+pxb_mcfg_size += mcfg_size;
 }
 
 static const struct pci_device_id pci_platform_tbl[] = {
@@ -532,27 +541,31 @@ static const struct pci_device_id pci_platform_tbl[] = {
 PCI_DEVICE_END
 };
 
-static void pci_bios_init_platform(void)
+static void pci_bios_init_platform(int 

[SeaBIOS] [RFC v2 0/3] Support multiple pci domains in pci_device

2018-08-08 Thread Zihan Yang
Currently seabios assumes there is only one pci domain(0), and almost
everything operates on pci domain 0 by default. This patch aims to add
multiple pci domain support for pci_device, while reserve the original
API for compatibility.

The reason to get seabios involved is that the pxb-pcie host bus created
in QEMU is now in a different PCI domain, and its bus number would start
from 0 instead of bus_nr. Actually bus_nr should not be used when in
another non-zero domain. However, QEMU only binds port 0xcf8 and 0xcfc to
bus pcie.0. To avoid bus confliction, we should use other port pairs for
busses under new domains.

Current issues:
* when trying to read config space of pcie_pci_bridge, it actually reads
  out the result of mch. I'm working on this weird behavior.

Changelog:
v2 <- v1:
- Fix bugs in filtering domains when traversing pci devices
- Reformat some hardcoded codes, such as probing the pci device in pci_setup

Zihan Yang (3):
  fw/pciinit: Recognize pxb-pcie-dev device
  pci_device: Add pci domain support
  pci: filter undesired domain when traversing pci

 src/fw/coreboot.c|   2 +-
 src/fw/csm.c |   2 +-
 src/fw/mptable.c |   1 +
 src/fw/paravirt.c|   3 +-
 src/fw/pciinit.c | 276 ++-
 src/hw/ahci.c|   1 +
 src/hw/ata.c |   1 +
 src/hw/esp-scsi.c|   1 +
 src/hw/lsi-scsi.c|   1 +
 src/hw/megasas.c |   1 +
 src/hw/mpt-scsi.c|   1 +
 src/hw/nvme.c|   1 +
 src/hw/pci.c |  69 +++--
 src/hw/pci.h |  42 +---
 src/hw/pci_ids.h |   6 +-
 src/hw/pcidevice.c   |  11 +-
 src/hw/pcidevice.h   |   8 +-
 src/hw/pvscsi.c  |   1 +
 src/hw/sdcard.c  |   1 +
 src/hw/usb-ehci.c|   1 +
 src/hw/usb-ohci.c|   1 +
 src/hw/usb-uhci.c|   1 +
 src/hw/usb-xhci.c|   1 +
 src/hw/virtio-blk.c  |   1 +
 src/hw/virtio-scsi.c |   1 +
 src/optionroms.c |   3 +
 26 files changed, 268 insertions(+), 170 deletions(-)

-- 
2.7.4


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios


[SeaBIOS] [RFC v2 1/3] fw/pciinit: Recognize pxb-pcie-dev device

2018-08-08 Thread Zihan Yang
QEMU q35 uses pxb-pcie-dev to enable multiple host bridges, this patch
recognizes such devices in seabios and add corresponding e820 entry.

MCFG base and size are already setup in QEMU, we just need to read it

Signed-off-by: Zihan Yang 
---
 src/fw/paravirt.c |  1 -
 src/fw/pciinit.c  | 17 +
 src/hw/pci_ids.h  |  1 +
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index 0770c47..6b14542 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -197,7 +197,6 @@ qemu_platform_setup(void)
 if (!loader_err)
 warn_internalerror();
 }
-
 acpi_setup();
 }
 
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 3a2f747..6e6a434 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -507,11 +507,28 @@ static void mch_mem_addr_setup(struct pci_device *dev, 
void *arg)
 pci_io_low_end = acpi_pm_base;
 }
 
+static void pxb_mem_addr_setup(struct pci_device *dev, void *arg)
+{
+union u64_u32_u mcfg_base;
+mcfg_base.lo = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR);
+mcfg_base.hi = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR + 4);
+
+// Fix me! Use another meaningful macro
+u32 mcfg_size = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR + 8);
+
+/* Skip config write here as the qemu-level objects are already setup, we
+ * read mcfg_base and mcfg_size from it just now. Instead, we directly add
+ * this item to e820 */
+e820_add(mcfg_base.val, mcfg_size, E820_RESERVED);
+}
+
 static const struct pci_device_id pci_platform_tbl[] = {
 PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82441,
i440fx_mem_addr_setup),
 PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_Q35_MCH,
mch_mem_addr_setup),
+PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PXB_HOST,
+   pxb_mem_addr_setup),
 PCI_DEVICE_END
 };
 
diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h
index 38fa2ca..35096ea 100644
--- a/src/hw/pci_ids.h
+++ b/src/hw/pci_ids.h
@@ -2265,6 +2265,7 @@
 
 #define PCI_VENDOR_ID_REDHAT   0x1b36
 #define PCI_DEVICE_ID_REDHAT_ROOT_PORT 0x000C
+#define PCI_DEVICE_ID_REDHAT_PXB_HOST  0x000B
 
 #define PCI_VENDOR_ID_TEKRAM   0x1de1
 #define PCI_DEVICE_ID_TEKRAM_DC290 0xdc29
-- 
2.7.4


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios


[SeaBIOS] [RFC v2 3/3] pci: filter undesired domain when traversing pci

2018-08-08 Thread Zihan Yang
Since pci devices could reside in different domains now, we should judge
the domain of pci devices when traversing them. Original devices still
use domain 0 for compatibility

Signed-off-by: Zihan Yang 
---
 src/fw/mptable.c |  1 +
 src/fw/pciinit.c | 10 --
 src/hw/ahci.c|  1 +
 src/hw/ata.c |  1 +
 src/hw/esp-scsi.c|  1 +
 src/hw/lsi-scsi.c|  1 +
 src/hw/megasas.c |  1 +
 src/hw/mpt-scsi.c|  1 +
 src/hw/nvme.c|  1 +
 src/hw/pcidevice.c   |  3 +++
 src/hw/pcidevice.h   |  4 
 src/hw/pvscsi.c  |  1 +
 src/hw/sdcard.c  |  1 +
 src/hw/usb-ehci.c|  1 +
 src/hw/usb-ohci.c|  1 +
 src/hw/usb-uhci.c|  1 +
 src/hw/usb-xhci.c|  1 +
 src/hw/virtio-blk.c  |  1 +
 src/hw/virtio-scsi.c |  1 +
 src/optionroms.c |  3 +++
 20 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/src/fw/mptable.c b/src/fw/mptable.c
index 47385cc..3989cb6 100644
--- a/src/fw/mptable.c
+++ b/src/fw/mptable.c
@@ -110,6 +110,7 @@ mptable_setup(void)
 
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 u16 bdf = pci->bdf;
 if (pci_bdf_to_bus(bdf) != 0)
 break;
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index fcdcd38..834540f 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -427,8 +427,7 @@ static void pci_bios_init_devices(int domain_nr)
 {
 struct pci_device *pci;
 foreachpci(pci) {
-if (pci->domain_nr != domain_nr)
-continue;
+filter_domain(pci, domain_nr);
 pci_bios_init_device(pci);
 }
 }
@@ -438,6 +437,7 @@ static void pci_enable_default_vga(void)
 struct pci_device *pci;
 
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (is_pci_vga(pci)) {
 dprintf(1, "PCI: Using %pP for primary VGA\n", pci);
 return;
@@ -545,8 +545,7 @@ static void pci_bios_init_platform(int domain_nr)
 {
 struct pci_device *pci;
 foreachpci(pci) {
-if (pci->domain_nr != domain_nr)
-continue;
+filter_domain(pci, domain_nr);
 pci_init_device(pci_platform_tbl, pci, NULL);
 }
 }
@@ -884,8 +883,7 @@ static int pci_bios_check_devices(struct pci_bus *busses, 
int domain_nr)
 // Calculate resources needed for regular (non-bus) devices.
 struct pci_device *pci;
 foreachpci(pci) {
-if (pci->domain_nr != domain_nr)
-continue;
+filter_domain(pci, domain_nr);
 if (pci->class == PCI_CLASS_BRIDGE_PCI)
 busses[pci->secondary_bus].bus_dev = pci;
 
diff --git a/src/hw/ahci.c b/src/hw/ahci.c
index 1746e7a..f825992 100644
--- a/src/hw/ahci.c
+++ b/src/hw/ahci.c
@@ -677,6 +677,7 @@ ahci_scan(void)
 // Scan PCI bus for ATA adapters
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (pci->class != PCI_CLASS_STORAGE_SATA)
 continue;
 if (pci->prog_if != 1 /* AHCI rev 1 */)
diff --git a/src/hw/ata.c b/src/hw/ata.c
index b6e073c..2273326 100644
--- a/src/hw/ata.c
+++ b/src/hw/ata.c
@@ -1024,6 +1024,7 @@ ata_scan(void)
 // Scan PCI bus for ATA adapters
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 pci_init_device(pci_ata_tbl, pci, NULL);
 }
 }
diff --git a/src/hw/esp-scsi.c b/src/hw/esp-scsi.c
index ffd86d0..17436d5 100644
--- a/src/hw/esp-scsi.c
+++ b/src/hw/esp-scsi.c
@@ -233,6 +233,7 @@ esp_scsi_setup(void)
 
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (pci->vendor != PCI_VENDOR_ID_AMD
 || pci->device != PCI_DEVICE_ID_AMD_SCSI)
 continue;
diff --git a/src/hw/lsi-scsi.c b/src/hw/lsi-scsi.c
index d5fc3e4..5748d1f 100644
--- a/src/hw/lsi-scsi.c
+++ b/src/hw/lsi-scsi.c
@@ -213,6 +213,7 @@ lsi_scsi_setup(void)
 
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (pci->vendor != PCI_VENDOR_ID_LSI_LOGIC
 || pci->device != PCI_DEVICE_ID_LSI_53C895A)
 continue;
diff --git a/src/hw/megasas.c b/src/hw/megasas.c
index d267580..1d84771 100644
--- a/src/hw/megasas.c
+++ b/src/hw/megasas.c
@@ -386,6 +386,7 @@ megasas_setup(void)
 
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (pci->vendor != PCI_VENDOR_ID_LSI_LOGIC &&
 pci->vendor != PCI_VENDOR_ID_DELL)
 continue;
diff --git a/src/hw/mpt-scsi.c b/src/hw/mpt-scsi.c
index 1faede6..e89316b 100644
--- a/src/hw/mpt-scsi.c
+++ b/src/hw/mpt-scsi.c
@@ -310,6 +310,7 @@ mpt_scsi_setup(void)
 
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (pci->vendor == PCI_VENDOR_ID_LSI_LOGIC
 && (pci->device == PCI_DEVICE_ID_LSI_53C1030
 || pci->device == PCI_DEVICE_ID_LSI_SAS1068
diff --git a/src/hw/nvme.c b/src/hw/nvme.c
index e6d739d..d7b5183 100644
--- a/src/hw/nvme.c
+++ b/src/hw/nvme.c
@@ -633,6 

[SeaBIOS] enable log path of devices in seabios

2018-08-08 Thread zahra rahimkhani
Hello Friends

I want to enable a log that show path of devices that by  seabios was
recognize  .
this paths are different from boot default paths.

Could you suggest me a advice?

Thank you,
Zahra
___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH] pci: add RedHat PCI BRIDGE capability

2018-08-08 Thread Liu, Jing2



On 8/8/2018 6:44 PM, Laszlo Ersek wrote:

On 08/08/18 05:24, Liu, Jing2 wrote:

On 8/7/2018 7:43 PM, Laszlo Ersek wrote:

On 08/07/18 09:20, Jing Liu wrote:


[snip]


-    if (pci_config_readw(bdf, PCI_VENDOR_ID) == PCI_VENDOR_ID_REDHAT &&
-    pci_config_readw(bdf, PCI_DEVICE_ID) ==
-    PCI_DEVICE_ID_REDHAT_ROOT_PORT) {
+    u16 vendor_id = pci_config_readw(bdf, PCI_VENDOR_ID);
+    u16 device_id = pci_config_readw(bdf, PCI_DEVICE_ID);


[snip]


(5) Regarding the code: I'm not sure how careful SeaBIOS is about
  unnecessary config space accesses (i.e., unnecessary traps to the
  host). Personally I would prefer if we didn't unconditionally read
  the device ID post-patch either -- that is, if the vendor ID doesn't
  match, we shouldn't read the device ID. Something like:


Do you mean we need prevent the compiler read device ID in advanced when
vendor ID does not matched?
If not, why the original codes will read device ID when the vendor Id
check fails?


What I mean is that the original code (see in the context above) uses
the "logical and" (&&)  operator; if the Vendor ID does not match
PCI_VENDOR_ID_REDHAT, then the Device ID is not read from config space
at all. After the patch (see above again), the Device ID is read
unconditionally, even if we later find that the Vendor ID is a mismatch,
and so throw away the Device ID. In that case, the Device ID read (which
is a trap from the guest to KVM to QEMU) is wasted.

It's likely not extremely important to be as frugal as possible with
config space accesses (traps); however, if it's not a big complication
code-wise to avoid possibly wasted reads (traps), then I think we should
be frugal.
Ah, yes! I didn't realize that and I aggree with you! Will change that 
in new version later.


Jing


Thanks
Laszlo



___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[SeaBIOS] Fwd: [RFC 0/2] (Ongoing)Support multiple pci domains in pci_device

2018-08-08 Thread Zihan Yang
[forgot to cc to the mail list]

Kevin O'Connor  于2018年8月8日周三 下午10:14写道:
>
> On Thu, Aug 02, 2018 at 10:39:13AM +0800, Zihan Yang wrote:
> > NOTE: This patch set is still ongoing and does not fully function
> > as its goal. But it involves some API changes, therefore I post them for
> > comments before moving on to make sure I'm on the right path.
> >
> > The corresponding qemu part can be found at
> > https://gitlab.com/WhoisZihan/qemu-pci-domain/tree/master/qemu
> > I will submit it to qemu list later.
> >
> > Currently seabios assumes there is only one pci domain(0), and almost
> > everything operates on pci domain 0 by default. This patch aims to add
> > multiple pci domain support for pci_device, while reserve the original
> > API for compatibility.
>
> Thanks.  I understand the desire to support multiple PCI domains in
> QEMU and the guest OS.  However, what is the high level reason for
> wanting the BIOS to be able to interact with the secondary PCI
> domains?

The pxb-pcie host bus is put into a separated domain, so are the devices
under the pxb host bus. I think we should also initialize busses in other
domains and probe those devices during bios initialization. But currently
qemu only binds port 0xcf8 and 0xcfc to q35 host's conf_mem and data_mem,
if we want to read the config space of pxb host, we should use another port.
I use port range 0x1000 and 0x1004 for a temporary workaround because they
seem to be 'free' now.

Please correct me if I misunderstand it.

P.S. Maybe you would want to ignore this patch set as there are a few bugs
that I fix later, and I will soon send a v2 patch (v2 is not working
either, but I
think I find where the current problem is), soon after I fix my
network proxy issue...

Thanks
Zihan

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] Problem with boot coreboot

2018-08-08 Thread Mike Banon
Dear friend, have you tried this advice (given at your coreboot thread) :

For the beginning, I recommend you to check if you could boot anything
at all. In example, try making an Ubuntu LiveUSB from a spare USB
flash drive,
and using SeaBIOS try booting from it. If it is working, you could
also try installing Ubuntu to a spare Hard Drive and also try booting
for it.
If all this is working (means the SeaBIOS booting capabilities are
fully functional both for USB and SATA interfaces) - while booting
FreeBSD still doesn't work - that means something is wrong either with
FreeBSD installation or (more likely) its partition table or maybe
GRUB2 is corrupted. Then you could try restoring GRUB2, by following
these instructions for example -
https://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd

If yes, it didn't help you?

Best regards,
Mike Banon

On Wed, Aug 8, 2018 at 6:57 PM, zahra rahimkhani
 wrote:
> Hello friends
>
> I compiled coreboot and seabios based on
> https://review.coreboot.org/cgit/board-status.git/plain/intel/minnowmax/4.5-306-g00ad7ff/2016-11-17T17_00_43Z/
>
> but my Freebsd or grub2 or Debian or ubuntu  did not boot and it  shows
> this message.
>
> Running option rom at c000:0003
> Turning on vga text mode console
> SeaBIOS (version rel-1.11.2-0-gf9626cc)
> EHCI init on dev 00:1d.0 (regs=0xd061e020)
> WARNING - Timeout at i8042_flush:71!
> AHCI controller at 00:13.0, iobase 0xd061d000, irq 10
> Searching bootorder for: /pci@i0cf8/*@12
> Found 0 lpt ports
> Found 1 serial ports
> Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/storage@1/*@0/*@0,0
> Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/usb-*@1
> USB MSC vendor='UFD 2.0' product='Silicon-Power8G' rev='1100' type=0
> removable=1
> USB MSC blksize=512 sectors=15730688
> Initialized USB HUB (1 ports used)
> All threads complete.
> Scan for option roms
>
> Press ESC for boot menu.
>
> Searching bootorder for: HALT
> drive 0x000f62c0: PCHS=0/0/0 translation=lba LCHS=979/255/63 s=15730688
> Space available for UMB: cd800-ed800, f5b60-f62c0
> Returned 253952 bytes of ZoneHigh
> e820 map has 18 items:
>   0:  - 0009fc00 = 1 RAM
>   1: 0009fc00 - 000a = 2 RESERVED
>   2: 000f - 0010 = 2 RESERVED
>   3: 0010 - 2000 = 1 RAM
>   4: 2000 - 2010 = 2 RESERVED
>   5: 2010 - 7ad9c000 = 1 RAM
>   6: 7ad9c000 - 8000 = 2 RESERVED
>   7: e000 - f000 = 2 RESERVED
>   8: feb0 - fec01000 = 2 RESERVED
>   9: fed01000 - fed02000 = 2 RESERVED
>   10: fed03000 - fed04000 = 2 RESERVED
>   11: fed05000 - fed06000 = 2 RESERVED
>   12: fed08000 - fed09000 = 2 RESERVED
>   13: fed0c000 - fed1 = 2 RESERVED
>   14: fed1c000 - fed1d000 = 2 RESERVED
>   15: fee0 - fee01000 = 2 RESERVED
>   16: fef0 - ff00 = 2 RESERVED
>   17: ff80 - 0001 = 2 RESERVED
> enter handle_19:
>   NULL
> Booting from Hard Disk...
> Booting from :7c00
>
> I would be grateful if you guide me .
>
> Thanks,
> Zahra
>
>
>
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> https://mail.coreboot.org/mailman/listinfo/seabios

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios


Re: [SeaBIOS] Marvell 88SE9230 passthrough in KVM takes long time to boot

2018-08-08 Thread Alex Williamson
On Wed, 8 Aug 2018 14:11:16 +0200
Gerd Hoffmann  wrote:

> On Sun, Jul 29, 2018 at 01:49:10PM +0200, Konrad Eisele wrote:
> > I'm passing through a Marvell 88SE9230 card to a KVM guest under
> > Ubuntu 18.04. The card is a Sata controller with 4 ports.
> > The option rom of the Marvell 88SE9230 card shows on a normal boot a
> > bios screen. When pressing CTRL-m quick enough, you  can interrupt the
> > bootprocess and enter a menue wherer you can define raid
> > arrays.
> > 
> > When booting seabios inside KVM the bootprocess is very slow.
> > There is a 1 min holdtime where the cpu is about 30%. The screen is
> > black with only the seabios version string shown. I suspect that
> > the passed-through Marvell 88SE9230 cards option roms causes this
> > behaviour.
> > Maybe the scanning for option rom cause the slow bootprocess?
> > 
> > In the seabios boot case no bios menue is shown, after
> > around 1 min the boot continues.
> > 
> > Is it possible to disable the options rom processing? Is there some
> > documentation about this (How can I configure it for Ubuntu) ?  
> 
> Set the romfile option to the empty string (for vfio-pci, on the qemu
> command line) should do that (qemu will not expose the rom to the guest
> then).

Typically rombar=0 on the QEMU command line is how to disable the option
ROM for an assigned device, or



in libvirt.  Thanks,

Alex

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios


[SeaBIOS] Problem with boot coreboot

2018-08-08 Thread zahra rahimkhani
Hello friends

I compiled coreboot and seabios based on
https://review.coreboot.org/cgit/board-status.git/plain/intel/minnowmax/4.5-306-g00ad7ff/2016-11-17T17_00_43Z/

but my Freebsd or grub2 or Debian or ubuntu  did not boot and it  shows
this message.

Running option rom at c000:0003
Turning on vga text mode console
SeaBIOS (version rel-1.11.2-0-gf9626cc)
EHCI init on dev 00:1d.0 (regs=0xd061e020)
WARNING - Timeout at i8042_flush:71!
AHCI controller at 00:13.0, iobase 0xd061d000, irq 10
Searching bootorder for: /pci@i0cf8/*@12
Found 0 lpt ports
Found 1 serial ports
Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/storage@1/*@0/*@0,0
Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/usb-*@1
USB MSC vendor='UFD 2.0' product='Silicon-Power8G' rev='1100' type=0
removable=1
USB MSC blksize=512 sectors=15730688
Initialized USB HUB (1 ports used)
All threads complete.
Scan for option roms

Press ESC for boot menu.

Searching bootorder for: HALT
drive 0x000f62c0: PCHS=0/0/0 translation=lba LCHS=979/255/63 s=15730688
Space available for UMB: cd800-ed800, f5b60-f62c0
Returned 253952 bytes of ZoneHigh
e820 map has 18 items:
  0:  - 0009fc00 = 1 RAM
  1: 0009fc00 - 000a = 2 RESERVED
  2: 000f - 0010 = 2 RESERVED
  3: 0010 - 2000 = 1 RAM
  4: 2000 - 2010 = 2 RESERVED
  5: 2010 - 7ad9c000 = 1 RAM
  6: 7ad9c000 - 8000 = 2 RESERVED
  7: e000 - f000 = 2 RESERVED
  8: feb0 - fec01000 = 2 RESERVED
  9: fed01000 - fed02000 = 2 RESERVED
  10: fed03000 - fed04000 = 2 RESERVED
  11: fed05000 - fed06000 = 2 RESERVED
  12: fed08000 - fed09000 = 2 RESERVED
  13: fed0c000 - fed1 = 2 RESERVED
  14: fed1c000 - fed1d000 = 2 RESERVED
  15: fee0 - fee01000 = 2 RESERVED
  16: fef0 - ff00 = 2 RESERVED
  17: ff80 - 0001 = 2 RESERVED
enter handle_19:
  NULL
Booting from Hard Disk...
Booting from :7c00

I would be grateful if you guide me .

Thanks,
Zahra
___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC 0/2] (Ongoing)Support multiple pci domains in pci_device

2018-08-08 Thread Kevin O'Connor
On Thu, Aug 02, 2018 at 10:39:13AM +0800, Zihan Yang wrote:
> NOTE: This patch set is still ongoing and does not fully function
> as its goal. But it involves some API changes, therefore I post them for
> comments before moving on to make sure I'm on the right path.
> 
> The corresponding qemu part can be found at
> https://gitlab.com/WhoisZihan/qemu-pci-domain/tree/master/qemu
> I will submit it to qemu list later.
> 
> Currently seabios assumes there is only one pci domain(0), and almost
> everything operates on pci domain 0 by default. This patch aims to add
> multiple pci domain support for pci_device, while reserve the original
> API for compatibility.

Thanks.  I understand the desire to support multiple PCI domains in
QEMU and the guest OS.  However, what is the high level reason for
wanting the BIOS to be able to interact with the secondary PCI
domains?

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios


Re: [SeaBIOS] Marvell 88SE9230 passthrough in KVM takes long time to boot

2018-08-08 Thread Gerd Hoffmann
On Sun, Jul 29, 2018 at 01:49:10PM +0200, Konrad Eisele wrote:
> I'm passing through a Marvell 88SE9230 card to a KVM guest under
> Ubuntu 18.04. The card is a Sata controller with 4 ports.
> The option rom of the Marvell 88SE9230 card shows on a normal boot a
> bios screen. When pressing CTRL-m quick enough, you  can interrupt the
> bootprocess and enter a menue wherer you can define raid
> arrays.
> 
> When booting seabios inside KVM the bootprocess is very slow.
> There is a 1 min holdtime where the cpu is about 30%. The screen is
> black with only the seabios version string shown. I suspect that
> the passed-through Marvell 88SE9230 cards option roms causes this
> behaviour.
> Maybe the scanning for option rom cause the slow bootprocess?
> 
> In the seabios boot case no bios menue is shown, after
> around 1 min the boot continues.
> 
> Is it possible to disable the options rom processing? Is there some
> documentation about this (How can I configure it for Ubuntu) ?

Set the romfile option to the empty string (for vfio-pci, on the qemu
command line) should do that (qemu will not expose the rom to the guest
then).

cheers,
  Gerd


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios


Re: [SeaBIOS] [PATCH] pci: add RedHat PCI BRIDGE capability

2018-08-08 Thread Laszlo Ersek
On 08/08/18 05:24, Liu, Jing2 wrote:
> On 8/7/2018 7:43 PM, Laszlo Ersek wrote:
>> On 08/07/18 09:20, Jing Liu wrote:

[snip]

>>> -    if (pci_config_readw(bdf, PCI_VENDOR_ID) == PCI_VENDOR_ID_REDHAT &&
>>> -    pci_config_readw(bdf, PCI_DEVICE_ID) ==
>>> -    PCI_DEVICE_ID_REDHAT_ROOT_PORT) {
>>> +    u16 vendor_id = pci_config_readw(bdf, PCI_VENDOR_ID);
>>> +    u16 device_id = pci_config_readw(bdf, PCI_DEVICE_ID);

[snip]

>> (5) Regarding the code: I'm not sure how careful SeaBIOS is about
>>  unnecessary config space accesses (i.e., unnecessary traps to the
>>  host). Personally I would prefer if we didn't unconditionally read
>>  the device ID post-patch either -- that is, if the vendor ID doesn't
>>  match, we shouldn't read the device ID. Something like:
>>
> Do you mean we need prevent the compiler read device ID in advanced when
> vendor ID does not matched?
> If not, why the original codes will read device ID when the vendor Id
> check fails?

What I mean is that the original code (see in the context above) uses
the "logical and" (&&)  operator; if the Vendor ID does not match
PCI_VENDOR_ID_REDHAT, then the Device ID is not read from config space
at all. After the patch (see above again), the Device ID is read
unconditionally, even if we later find that the Vendor ID is a mismatch,
and so throw away the Device ID. In that case, the Device ID read (which
is a trap from the guest to KVM to QEMU) is wasted.

It's likely not extremely important to be as frugal as possible with
config space accesses (traps); however, if it's not a big complication
code-wise to avoid possibly wasted reads (traps), then I think we should
be frugal.

Thanks
Laszlo

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios