If the version and low/high capabilities flags of a sdcard controller are
invalid (0xFFFF), assume the controller address is invalid, and exit setup
before attempting to reset the controller, which would introduce an
unnecessary
delay, since the reset would ultimately fail after timing out.
This eliminates the delay in displaying the boot menu message on Baytrail
ChromeOS devices, where multiple /etc/sdcard entries are present in a
single
payload to cover the range of eMMC controller addresses used.
Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com>
---
src/hw/sdcard.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/hw/sdcard.c b/src/hw/sdcard.c
index 38d05c4..e6090b8 100644
--- a/src/hw/sdcard.c
+++ b/src/hw/sdcard.c
@@ -486,9 +486,13 @@ sdcard_controller_setup(struct sdhci_s *regs, int prio)
if (!(present_state & SP_CARD_INSERTED))
// No card present
return;
- dprintf(3, "sdhci@%p ver=%x cap=%x %x\n", regs
- , readw(®s->controller_version)
- , readl(®s->cap_lo), readl(®s->cap_hi));
+ u16 ver = readw(®s->controller_version);
+ u32 cap_lo = readl(®s->cap_lo);
+ u32 cap_hi = readl(®s->cap_hi);
+ dprintf(3, "sdhci@%p ver=%x cap=%x %x\n", regs, ver, cap_lo, cap_hi);
+ if (ver == 0xffff && cap_lo == 0xffffffff && cap_hi == 0xffffffff)
+ //invalid controller address
+ return;
sdcard_reset(regs, SRF_ALL);
writew(®s->irq_signal, 0);
writew(®s->irq_enable, 0x01ff);
--
2.5.0
Some BayTrail ChromeOS devices have the eMMC controller hidden (thus
requiring the use of etc/sdcard), while others do not, making it
problematic to have a single payload which serves all devices
properly. Therefore, if the CBFS contains etc/sdcard entries, skip
detection of any visible PCI sdhci controllers in order to avoid
duplicate entries in the boot menu.
patch implementation suggested by Kevin O'Connor :)
Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com>
---
src/hw/sdcard.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/hw/sdcard.c b/src/hw/sdcard.c
index 7e0875f..38d05c4 100644
--- a/src/hw/sdcard.c
+++ b/src/hw/sdcard.c
@@ -550,18 +550,23 @@ sdcard_setup(void)
return;
struct romfile_s *file = NULL;
+ int num_romfiles = 0;
for (;;) {
file = romfile_findprefix("etc/sdcard", file);
if (!file)
break;
run_thread(sdcard_romfile_setup, file);
+ num_romfiles++;
}
- struct pci_device *pci;
- foreachpci(pci) {
- if (pci->class != PCI_CLASS_SYSTEM_SDHCI || pci->prog_if >= 2)
- // Not an SDHCI controller following SDHCI spec
- continue;
- run_thread(sdcard_pci_setup, pci);
+ //only scan for PCI controllers if etc/sdcard not used
+ if (num_romfiles == 0) {
+ struct pci_device *pci;
+ foreachpci(pci) {
+ if (pci->class != PCI_CLASS_SYSTEM_SDHCI || pci->prog_if >= 2)
+ // Not an SDHCI controller following SDHCI spec
+ continue;
+ run_thread(sdcard_pci_setup, pci);
+ }
}
}
--
2.5.0
>>> On 16.03.16 at 14:15, <konrad.wilk(a)oracle.com> wrote:
> On Wed, Mar 16, 2016 at 12:22:32PM +0000, Ian Campbell wrote:
>> On Wed, 2016-03-16 at 20:13 +0800, Shannon Zhao wrote:
>> >
>> > On 2016/3/16 19:20, Ian Campbell wrote:
>> > >
>> > > (nb, my citrix.com email is no longer valid)
>> > > On Wed, 2016-03-16 at 11:33 +0800, Shannon Zhao wrote:
>> > > >
>> > > > >
>> > > > > Hi,
>> > > > >
>> > > > > I noticed there are some efforts to add Xen PV block device support in
>> > > > > Seabios in a GSoC project and there is a wiki page [1] for it. I found
>> > > > > some patches [2] to add Xenstore R/W support for Seabios. But I didn't
>> > > > > find the patches to add PV block device driver in Seabios.
>> > > > >
>> > > > > If you know please tell me where I can find these patches. And I noticed
>> > > > > that the patches [2] and this GSoC project work didn't get applied to
>> > > > > Seabios eventually, is there any reason? Does it mean that there are
>> > > > > some difficulties to support Xen PV block device in Seabios?
>> > > This work was never finished, IIRC (and it was a long time ago so this
>> > > might be a faulty recollection) the main stumbling block was that there
>> > > is no reasonable BIOS level event which could be used to tear down the
>> > > PV interfaces in order to hand them over to the OS (unlike, say, EFI
>> > > where there is ExitBootServices).
>> > >
>> > Ian, thanks for your reply! It looks like the problem is how and when to
>> > clear PV resources in seabios before handing over to guest. But I wonder
>> > why virtio works in seabios. Does seabios using virtio need to clear
>> > things like vrings? Or seabios doesn't clear the things and guest just
>> > covers the configuration with new values?
>>
>> I think virtio covered this use case from day 1 by having the reset,
>> but also by not having a xenstore ring etc.
>>
>> > > So making this work would require something like a complete set of
>> > > parallel PV infrastructure (devices, corresponding xenstore nodes,
>> > > grant table) for the use of the BIOS firmware, or perhaps a (tricky
>> > > to
>> > > retrofit in a backwards compatible manner) PV facility for the
>> > > guest to
>> > > reset everything before starting to use them.
>> > >
>> > Like guest front-end driver checks if the backend state is
>> > XenbusStateInitWait, if not, tell the backend to reset to
>> > XenbusStateInitWait state?
>>
>> Before it can do this the guest needs to recover the xenbus ring (which
>> was used by SeaBIOS) into a usable state -- so you need to be thinking
>> at least one layer further down before you can start to think about
>> individual devices, and don't forget the grant table (which may have in
>> use entries from the BIOS) and event channels (which the BIOS may have
>> setup).
>>
>> I'm afraid I don't have any concrete answer for what exactly needs to
>> be done to make this work, but I do know that it is a (IMHO very) non-
>> trivial amount of investigation, prototyping and coding.
>
> But it does work with OVMF. That is it implements the full PV driver
> for block. So it surely is possible.
And grub2, iirc.
Jan
Hi,
I noticed there are some efforts to add Xen PV block device support in
Seabios in a GSoC project and there is a wiki page [1] for it. I found
some patches [2] to add Xenstore R/W support for Seabios. But I didn't
find the patches to add PV block device driver in Seabios.
If you know please tell me where I can find these patches. And I noticed
that the patches [2] and this GSoC project work didn't get applied to
Seabios eventually, is there any reason? Does it mean that there are
some difficulties to support Xen PV block device in Seabios?
Thanks in advance!
[1] http://wiki.xenproject.org/wiki/SeaBIOS
[2] http://www.seabios.org/pipermail/seabios/2011-August/002214.html
--
Shannon
Some BayTrail ChromeOS devices have the eMMC controller hidden (thus
requiring the use of etc/sdcard), while others do not, making it
problematic to have a single payload which serves all devices properly.
Therefore, if the CBFS contains etc/sdcard entries, skip detection of
any visible PCI sdhci controllers in order to avoid duplicate entries in
the boot menu.
patch implementation suggested by Kevin O'Connor :)
Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com>
---
src/hw/sdcard.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/hw/sdcard.c b/src/hw/sdcard.c
index 7e0875f..32cdb14 100644
--- a/src/hw/sdcard.c
+++ b/src/hw/sdcard.c
@@ -557,11 +557,14 @@ sdcard_setup(void)
run_thread(sdcard_romfile_setup, file);
}
- struct pci_device *pci;
- foreachpci(pci) {
- if (pci->class != PCI_CLASS_SYSTEM_SDHCI || pci->prog_if >= 2)
- // Not an SDHCI controller following SDHCI spec
- continue;
- run_thread(sdcard_pci_setup, pci);
+ //only scan for PCI controllers if etc/sdcard* not used
+ if (file == NULL) {
+ struct pci_device *pci;
+ foreachpci(pci) {
+ if (pci->class != PCI_CLASS_SYSTEM_SDHCI || pci->prog_if >= 2)
+ // Not an SDHCI controller following SDHCI spec
+ continue;
+ run_thread(sdcard_pci_setup, pci);
+ }
}
}
--
2.5.0
Some BayTrail ChromeOS devices have the eMMC controller hidden (thus
requiring the use of etc/sdcard), while others do not, making it
problematic to have a single payload which serves all devices
properly. Therefore, if the CBFS contains etc/sdcard entries, skip
detection of
any visible PCI sdhci controllers in order to avoid duplicate entries in
the boot menu.
patch implementation suggested by Kevin O'Connor :)
Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com>
---
src/hw/sdcard.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/hw/sdcard.c b/src/hw/sdcard.c
index 7e0875f..38d05c4 100644
--- a/src/hw/sdcard.c
+++ b/src/hw/sdcard.c
@@ -550,18 +550,23 @@ sdcard_setup(void)
return;
struct romfile_s *file = NULL;
+ int num_romfiles = 0;
for (;;) {
file = romfile_findprefix("etc/sdcard", file);
if (!file)
break;
run_thread(sdcard_romfile_setup, file);
+ num_romfiles++;
}
- struct pci_device *pci;
- foreachpci(pci) {
- if (pci->class != PCI_CLASS_SYSTEM_SDHCI || pci->prog_if >= 2)
- // Not an SDHCI controller following SDHCI spec
- continue;
- run_thread(sdcard_pci_setup, pci);
+ //only scan for PCI controllers if etc/sdcard not used
+ if (num_romfiles == 0) {
+ struct pci_device *pci;
+ foreachpci(pci) {
+ if (pci->class != PCI_CLASS_SYSTEM_SDHCI || pci->prog_if >= 2)
+ // Not an SDHCI controller following SDHCI spec
+ continue;
+ run_thread(sdcard_pci_setup, pci);
+ }
}
}
--
2.5.0
On Thu, Mar 10, 2016 at 11:11:59AM -0600, Ben Gardner wrote:
> Hi Kevin,
>
> I plan to have the default CBFS contain only coreboot and SeabIOS and
> a few payloads (coreinfo, memtest86, PXE) that I don't intend to
> change often.
> That would be protected with a hash and would be kept small for
> performance reasons.
> ChromeOS appears to do something similar and take it a step further
> and write-protect that "read only" region of flash.
>
> The other CBFS would contain larger images that I'm likely to change,
> such as Linux.
>
> There is a chance of name conflicts and that may cause problems.
> In my use case, the answer is "don't do that".
>
> From a random sampling of FMD files in the coreboot tree
> (google/glados/chromeos.fmd), I see that ChromeOS uses three:
> FW_MAIN_A, FW_MAIN_B, and the default COREBOOT.
> Assuming FW_MAIN_A and FW_MAIN_B contain files with similar names,
> that would cause confusion if they use SeaBIOS.
> But I think that ChromeOS is switching to use the Depthcharge bootloader.
>
> So, maybe this wouldn't work well for everyone.
Thanks. If this may not work for everyone, then I suggest adding a
build time (kconfig) or runtime (cbfs) setting to enable/disable it.
Normally runtime settings are preferred, but that may not work here.
-Kevin
Hi,
> My name is Miodrag and I am coordinator of MAME project
> (www.mamedev.org), we would like to distribute seabios roms if
> possible together with our binaries to show PC capable emulation. All
> is free and project is under GPL2+ license.
seabios is GPL, so this is perfectly fine as long as you also provide
the source code used to build the binaries (as required by GPL).
If you are using seabios unmodified I'd recommend to place a upstream
git mirror next to the mame repos @ github. qemu does the same on
http://git.qemu.org/, for GPL compliance reasons, and also because it's
more convenient that way for the seabios submodule we have in qemu.
If you have patched seabios you have to publish the changes too of
course, and I recommend to sent the patches for review and upstream
merge to the seabios mailing list (which I've added to Cc).
thanks,
Gerd