SeaBIOS April 2013

seabios@seabios.org

19 participants
28 discussions

Re: [SeaBIOS] [PATCH 2/2] pci: load memory window setup from host
by Kevin O'Connor 30 Apr '13

30 Apr '13

On Mon, Apr 29, 2013 at 06:21:40PM +0300, Michael S. Tsirkin wrote: > Load memory window setup for pci from host. > This makes it possible for host to make sure > setup matches hardware exactly: especially important > for when ACPI tables are loaded from host. > This will also make it easier to add more chipsets > down the road. > > Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> > --- > src/paravirt.c | 25 ++++++++++++++++++++++++- > src/pciinit.c | 54 ++++++++++++++++++++++++++++++++++++++++-------------- > src/util.h | 8 +++++++- > 3 files changed, 71 insertions(+), 16 deletions(-) > > diff --git a/src/paravirt.c b/src/paravirt.c > index 85aa423..067a4dc 100644 > --- a/src/paravirt.c > +++ b/src/paravirt.c > @@ -91,14 +91,35 @@ qemu_preinit(void) > dprintf(1, "Ram Size=0x%08x (0x%016llx high)\n", RamSize, RamSizeOver4G); > } > > +struct pci_mem *qemu_get_pci_mem(void) > +{ > + int psize; > + struct pci_mem *mem = romfile_loadfile("etc/pci-info", &psize); > + if (!mem) > + return NULL; > + if (psize < sizeof *mem) { Please always add parenthesis to sizeof calls. > + free(mem); > + return NULL; > + } > + mem->start32 = le64_to_cpu(mem->start32); > + mem->end32 = le64_to_cpu(mem->end32); > + mem->start64 = le64_to_cpu(mem->start64); > + mem->end64 = le64_to_cpu(mem->end64); > + return mem; > +} > + > void > qemu_platform_setup(void) > { > + struct pci_mem *mem; > + > if (!CONFIG_QEMU) > return; > > qemu_cfg_init(); > > + mem = qemu_get_pci_mem(); > + > if (runningOnXen()) { > pci_probe_devices(); > xen_hypercall_setup(); > @@ -107,7 +128,7 @@ qemu_platform_setup(void) > } > > // Initialize pci > - pci_setup(); > + pci_setup(mem); I don't understand why this code is being added to paravirt.c. Just update pciinit.c with the romfile_loadfile() calls it needs. There is no reason to change the order of initialization or to add parameters to pci_setup. Otherwise, I'm fine with having QEMU send the PCI windows explicitly to SeaBIOS. -Kevin

2 1

[PATCH 0/2] paravirt: load pci window data from host
by Michael S. Tsirkin 29 Apr '13

29 Apr '13

This makes it possible to load pci window data from host, when running on qemu. This makes it possible for host to make sure setup matches hardware exactly: especially important for when ACPI tables are loaded from host. This will also make it easier to add more chipsets down the road. Michael S. Tsirkin (2): paravirt: init qemu cfg earlier pci: load memory window setup from host src/paravirt.c | 27 ++++++++++++++++++++++++++- src/pciinit.c | 54 ++++++++++++++++++++++++++++++++++++++++-------------- src/post.c | 1 - src/util.h | 8 +++++++- 4 files changed, 73 insertions(+), 17 deletions(-) -- MST

1 2

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 2/3] acpi: load and link tables from /etc/acpi/
by Laszlo Ersek 29 Apr '13

29 Apr '13

Not sure how much it counts, but I personally can agree with you on this direction :) One note below: > @@ -603,8 +604,72 @@ acpi_setup(void) > if (! CONFIG_ACPI) > return; > > + int acpi_generate = 1; > + > dprintf(3, "init ACPI tables\n"); > > + struct romfile_s *file = NULL; > + for (;;) { > + file = romfile_findprefix("/etc/acpi/", file); > + if (!file) > + break; > + > + /* > + * Disable ACPI table generation. All ACPI tables must come from > + * etc/acpi/ romfile entries. > + */ > + acpi_generate = 0; > + [...] > + } > + > + linker_link("/etc/linker-script"); > + > + if (!acpi_generate) { > + return; > + } > + > + dprintf(3, "generate ACPI tables\n"); > + > // This code is hardcoded for PIIX4 Power Management device. > struct pci_device *pci = pci_find_init_device(acpi_find_tbl, NULL); > if (!pci) Are you deliberately calling linker_link() independently from "acpi_generate"? My hunch is that linker_link() only makes sense if acpi_generate == 0 (ie. qemu has passed down at least one table to repoint some pointer to), but I may be missing a use case. Thanks Laszlo

2 1

[PATCH] ps2: disable the keyboard and mouse before flushing the queue
by Anthony Liguori 26 Apr '13

26 Apr '13

If SeaBIOS is run as a payload via coreboot (and presumably as a CSM), then it's possible the keyboard or mouse will still be enabled. This can lead to data being queued even after the flush function attempts to clear the queue. Disabling the keyboard/mouse prior to flushing is pretty standard in DOS programming so it's not surprising that it's needed here. I believe this problem manifests with the Chromebook Pixel. People have reported that sometimes the 'ESC to Select Boot Devices' doesn't work. I can reproduce this faithfully by holding 'Ctrl-L' in the firmware screen during SeaBIOS initialization. I can't test this fix on an actual Pixel because I don't know how to update SeaBIOS but I have tested the patch under QEMU. Signed-off-by: Anthony Liguori <aliguori(a)us.ibm.com> --- src/ps2port.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/ps2port.c b/src/ps2port.c index 9b760fd..2169171 100644 --- a/src/ps2port.c +++ b/src/ps2port.c @@ -55,6 +55,12 @@ static int i8042_flush(void) { dprintf(7, "i8042_flush\n"); + + /* Disable the keyboard and mouse to prevent additional data from + * being queued. */ + outb(0xad, PORT_PS2_STATUS); + outb(0xa7, PORT_PS2_STATUS); + int i; for (i=0; i<I8042_BUFFER_SIZE; i++) { u8 status = inb(PORT_PS2_STATUS); -- 1.8.0

2 4

Re: [SeaBIOS] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios
by Michael S. Tsirkin 26 Apr '13

26 Apr '13

On Thu, Apr 25, 2013 at 08:19:48PM +0200, Fred . wrote: > With ACPI moved out of SeaBIOS to QEMU, how will ACPI work when using SeaBIOS > without QEMU? > > Like if using SeaBIOS with Boch, KVM or Coreboot? KVM merged with QEMU, so it will use romfiles too. Others will have two options: - keep using that tables in seabios. With time we will be able to drop qemu-specific stuff in the tables which should make life easier for Bochs/coreboot. - add ACPI through romfiles like QEMU will do. Which one will be chosen will be up to relevant projects, but note how they benefit in any case. > > On Thu, Apr 25, 2013 at 11:02 AM, Michael S. Tsirkin <mst(a)redhat.com> wrote: > > Untested yet, but I thought I'd share the > BIOS bits so we can agree on direction. > > In particular check out ROM sizes: > - Before patchset with DSDT enabled > Total size: 127880 Fixed: 59060 Free: 3192 (used 97.6% of 128KiB rom) > - Before patchset with DSDT disabled > Total size: 122844 Fixed: 58884 Free: 8228 (used 93.7% of 128KiB rom) > - After patchset: > Total size: 128776 Fixed: 59100 Free: 2296 (used 98.2% of 128KiB rom) > - Legacy disabled at build time: > Total size: 119836 Fixed: 58996 Free: 11236 (used 91.4% of 128KiB > rom) > > As can be seen from this, most size savings come > from dropping DSDT, but we do save a bit by removing > other tables. Of course the real reason to move tables to QEMU > is so that ACPI can better match hardware. > > This patchset adds an option to move all code for formatting acpi tables > out of BIOS. With this, QEMU has full control over the table layout. > All tables are loaded from the new "/etc/acpi/" directory. > Any entries in this directory cause BIOS to disable > ACPI table generation completely. > A generic linker script, controlled by QEMU, is > loaded from "/etc/linker-script". It is used to > patch in table pointers and checksums. > > BIOS still has limited ability to parse the tables, > for the following purposes: > - locate resume vector > - allocate RSDP in FSEG > - allocate FACS at an aligned address > > -- > MST > > > Michael S. Tsirkin (3): > linker: utility to patch in-memory ROM files > acpi: load and link tables from /etc/acpi/ > acpi: add an option to disable builtin tables > > Makefile | 2 +- > src/Kconfig | 12 +++++++- > src/acpi.c | 67 +++++++++++++++++++++++++++++++++++++++++++- > src/linker.c | 90 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > src/linker.h | 50 +++++++++++++++++++++++++++++++++ > src/util.h | 1 + > 6 files changed, 219 insertions(+), 3 deletions(-) > create mode 100644 src/linker.c > create mode 100644 src/linker.h > > -- > MST > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > >

2 1

Re: [SeaBIOS] Updating SeaBIOS on a Chromebook (Was: [PATCH] ps2: disable the keyboard and mouse before flushing the queue)
by Anthony Liguori 25 Apr '13

25 Apr '13

Thanks Stefan! I'll give it a try this evening. Regards, Anthony Liguori Stefan Reinauer <reinauer(a)google.com> writes: > Hi Anthony, > > In order to build a working SeaBIOS for the Pixel, you should use our > ChromeOS tree because unfortunately we have not been able to upstream all > the patches we carry around yet. > > $ git clone > https://gerrit.chromium.org/gerrit/p/chromiumos/third_party/seabios.git > $ cd seabios > $ git checkout origin/chromeos-2012.05.12 > > Build it with: > $ cp default.config .config > $ make > > Then create a CBFS > > # get the PCI option rom > $ wget http://www.coreboot.org/~stepan/pci8086,0166.rom > # Create a dummy bootblock to make cbfstool happy > $ dd if=/dev/zero of=bootblock count=1 bs=64 > # Create empty CBFS > $ cbfstool seabios.cbfs create -s $(( 2*1024*1024 )) -B bootblock -m x86 > # Add SeaBIOS binary to CBFS > $ cbfstool seabios.cbfs add-payload -f out/bios.bin.elf -n payload -c lzma > # Add VGA option rom to CBFS > $ cbfstool seabios.cbfs add -f pci8086,0166.rom -n pci8086,0166.rom -t > optionrom > # Add additional configuration > $ cbfstool seabios.cbfs add -f bootorder -n bootorder -t raw > $ cbfstool seabios.cbfs add -f boot-menu-wait -n boot-menu-wait -t raw > # Print CBFS inventory > $ cbfstool seabios.cbfs print > # Fix up CBFS to live at 0xffc00000. The last four bytes of a CBFS > # image are a pointer to the CBFS master header. Per default a CBFS > # lives at 4G - rom size, and the CBFS master header ends up at > # 0xffffffa0. However our CBFS lives at 4G-4M and is 2M in size, so > # the CBFS master header is at 0xffdfffa0 instead. The two lines > # below correct the according byte in that pointer to make all CBFS > # parsing code happy. In the long run we should fix cbfstool and > # remove this workaround. > /bin/echo -ne \\0737 | dd of=seabios.cbfs seek=$(( (2*1024*1024) - 2 )) > bs=1 conv=notrunc > > That's it. :-) > > I also uploaded an image with your change to > > http://www.coreboot.org/~stepan/seabios.cbfs.bz2 > > > Flash it on the ChromeBook with: > > # cd /tmp > # flashrom -r image.rom > # dd if=seabios.cbfs of=image.rom seek=2 bs=2M conv=notrunc > # flashrom -w image.rom -i RW_LEGACY > > On Thu, Apr 25, 2013 at 9:15 AM, ron minnich <rminnich(a)gmail.com> wrote: > >> stefan, how do we fix this? >> >> On Wed, Apr 24, 2013 at 6:36 PM, Anthony Liguori <aliguori(a)us.ibm.com> >> wrote: >> > >> > Hi Ron, >> > >> > I just got a lovely new Pixel and noticed the following problem with >> > SeaBIOS. Any chance you know how I can update the SeaBIOS firmware to >> > test this? Or perhaps the person to poke to get fixes included in the >> > shipped SeaBIOS? >> > >> > Regards, >> > >> > Anthony Liguori >> > >> > >> > >> > ---------- Forwarded message ---------- >> > From: "Anthony Liguori" <aliguori(a)us.ibm.com> >> > To: "" <seabios(a)seabios.org> >> > Cc: "Kevin O'Connor" <kevin(a)koconnor.net> , "Anthony Liguori" < >> aliguori(a)us.ibm.com> >> > Date: Wed, 24 Apr 2013 20:32:09 -0500 >> > Subject: [PATCH] ps2: disable the keyboard and mouse before flushing the >> queue >> > If SeaBIOS is run as a payload via coreboot (and presumably as a >> > CSM), then it's possible the keyboard or mouse will still be >> > enabled. This can lead to data being queued even after the flush >> > function attempts to clear the queue. >> > >> > Disabling the keyboard/mouse prior to flushing is pretty standard >> > in DOS programming so it's not surprising that it's needed here. >> > >> > I believe this problem manifests with the Chromebook Pixel. People >> > have reported that sometimes the 'ESC to Select Boot Devices' >> > doesn't work. I can reproduce this faithfully by holding 'Ctrl-L' >> > in the firmware screen during SeaBIOS initialization. >> > >> > I can't test this fix on an actual Pixel because I don't know how >> > to update SeaBIOS but I have tested the patch under QEMU. >> > >> > Signed-off-by: Anthony Liguori <aliguori(a)us.ibm.com> >> > --- >> > src/ps2port.c | 6 ++++++ >> > 1 file changed, 6 insertions(+) >> > >> > diff --git a/src/ps2port.c b/src/ps2port.c >> > index 9b760fd..2169171 100644 >> > --- a/src/ps2port.c >> > +++ b/src/ps2port.c >> > @@ -55,6 +55,12 @@ static int >> > i8042_flush(void) >> > { >> > dprintf(7, "i8042_flush\n"); >> > + >> > + /* Disable the keyboard and mouse to prevent additional data from >> > + * being queued. */ >> > + outb(0xad, PORT_PS2_STATUS); >> > + outb(0xa7, PORT_PS2_STATUS); >> > + >> > int i; >> > for (i=0; i<I8042_BUFFER_SIZE; i++) { >> > u8 status = inb(PORT_PS2_STATUS); >> > -- >> > 1.8.0 >> > >> > >> >> > > > -- > Stefan Reinauer > Google Inc. > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios

1 0

Re: [SeaBIOS] Updating SeaBIOS on a Chromebook (Was: [PATCH] ps2: disable the keyboard and mouse before flushing the queue)
by Stefan Reinauer 25 Apr '13

25 Apr '13

Hi Anthony, In order to build a working SeaBIOS for the Pixel, you should use our ChromeOS tree because unfortunately we have not been able to upstream all the patches we carry around yet. $ git clone https://gerrit.chromium.org/gerrit/p/chromiumos/third_party/seabios.git $ cd seabios $ git checkout origin/chromeos-2012.05.12 Build it with: $ cp default.config .config $ make Then create a CBFS # get the PCI option rom $ wget http://www.coreboot.org/~stepan/pci8086,0166.rom # Create a dummy bootblock to make cbfstool happy $ dd if=/dev/zero of=bootblock count=1 bs=64 # Create empty CBFS $ cbfstool seabios.cbfs create -s $(( 2*1024*1024 )) -B bootblock -m x86 # Add SeaBIOS binary to CBFS $ cbfstool seabios.cbfs add-payload -f out/bios.bin.elf -n payload -c lzma # Add VGA option rom to CBFS $ cbfstool seabios.cbfs add -f pci8086,0166.rom -n pci8086,0166.rom -t optionrom # Add additional configuration $ cbfstool seabios.cbfs add -f bootorder -n bootorder -t raw $ cbfstool seabios.cbfs add -f boot-menu-wait -n boot-menu-wait -t raw # Print CBFS inventory $ cbfstool seabios.cbfs print # Fix up CBFS to live at 0xffc00000. The last four bytes of a CBFS # image are a pointer to the CBFS master header. Per default a CBFS # lives at 4G - rom size, and the CBFS master header ends up at # 0xffffffa0. However our CBFS lives at 4G-4M and is 2M in size, so # the CBFS master header is at 0xffdfffa0 instead. The two lines # below correct the according byte in that pointer to make all CBFS # parsing code happy. In the long run we should fix cbfstool and # remove this workaround. /bin/echo -ne \\0737 | dd of=seabios.cbfs seek=$(( (2*1024*1024) - 2 )) bs=1 conv=notrunc That's it. :-) I also uploaded an image with your change to http://www.coreboot.org/~stepan/seabios.cbfs.bz2 Flash it on the ChromeBook with: # cd /tmp # flashrom -r image.rom # dd if=seabios.cbfs of=image.rom seek=2 bs=2M conv=notrunc # flashrom -w image.rom -i RW_LEGACY On Thu, Apr 25, 2013 at 9:15 AM, ron minnich <rminnich(a)gmail.com> wrote: > stefan, how do we fix this? > > On Wed, Apr 24, 2013 at 6:36 PM, Anthony Liguori <aliguori(a)us.ibm.com> > wrote: > > > > Hi Ron, > > > > I just got a lovely new Pixel and noticed the following problem with > > SeaBIOS. Any chance you know how I can update the SeaBIOS firmware to > > test this? Or perhaps the person to poke to get fixes included in the > > shipped SeaBIOS? > > > > Regards, > > > > Anthony Liguori > > > > > > > > ---------- Forwarded message ---------- > > From: "Anthony Liguori" <aliguori(a)us.ibm.com> > > To: "" <seabios(a)seabios.org> > > Cc: "Kevin O'Connor" <kevin(a)koconnor.net> , "Anthony Liguori" < > aliguori(a)us.ibm.com> > > Date: Wed, 24 Apr 2013 20:32:09 -0500 > > Subject: [PATCH] ps2: disable the keyboard and mouse before flushing the > queue > > If SeaBIOS is run as a payload via coreboot (and presumably as a > > CSM), then it's possible the keyboard or mouse will still be > > enabled. This can lead to data being queued even after the flush > > function attempts to clear the queue. > > > > Disabling the keyboard/mouse prior to flushing is pretty standard > > in DOS programming so it's not surprising that it's needed here. > > > > I believe this problem manifests with the Chromebook Pixel. People > > have reported that sometimes the 'ESC to Select Boot Devices' > > doesn't work. I can reproduce this faithfully by holding 'Ctrl-L' > > in the firmware screen during SeaBIOS initialization. > > > > I can't test this fix on an actual Pixel because I don't know how > > to update SeaBIOS but I have tested the patch under QEMU. > > > > Signed-off-by: Anthony Liguori <aliguori(a)us.ibm.com> > > --- > > src/ps2port.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/src/ps2port.c b/src/ps2port.c > > index 9b760fd..2169171 100644 > > --- a/src/ps2port.c > > +++ b/src/ps2port.c > > @@ -55,6 +55,12 @@ static int > > i8042_flush(void) > > { > > dprintf(7, "i8042_flush\n"); > > + > > + /* Disable the keyboard and mouse to prevent additional data from > > + * being queued. */ > > + outb(0xad, PORT_PS2_STATUS); > > + outb(0xa7, PORT_PS2_STATUS); > > + > > int i; > > for (i=0; i<I8042_BUFFER_SIZE; i++) { > > u8 status = inb(PORT_PS2_STATUS); > > -- > > 1.8.0 > > > > > > -- Stefan Reinauer Google Inc.

1 0

Re: [SeaBIOS] [RFC][PATCH 1/2] acpi: add ASL for Embedded Controller
by li guang 18 Apr '13

18 Apr '13

在 2013-04-17三的 07:46 -0600，Marc Jones写道： > What EC is this for? The device and interface is defined by the spec, > but the offsets and methods are custom for every EC. > > you're mostly right, the specific content ACPI space will vary for different boards, this one just for a common case > > > Marc > > > On Wed, Apr 17, 2013 at 1:22 AM, liguang <lig.fnst(a)cn.fujitsu.com> > wrote: > defined at ACPI SPEC v5 chapter 12: > "ACPI Embedded Controller Interface Specification" > > Signed-off-by: liguang <lig.fnst(a)cn.fujitsu.com> > --- > src/acpi-dsdt-ec.dsl | 106 > ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 106 insertions(+), 0 deletions(-) > create mode 100644 src/acpi-dsdt-ec.dsl > > diff --git a/src/acpi-dsdt-ec.dsl b/src/acpi-dsdt-ec.dsl > new file mode 100644 > index 0000000..6bd8edd > --- /dev/null > +++ b/src/acpi-dsdt-ec.dsl > @@ -0,0 +1,106 @@ > +/* > + * This program is free software; you can redistribute it > and/or modify > + * it under the terms of the GNU General Public License as > published by > + * the Free Software Foundation; version 2 of the License. > + * > + * This program is distributed in the hope that it will be > useful, > + * but WITHOUT ANY WARRANTY; without even the implied > warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See > the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public > License > + * along with this program; if not, write to the Free > Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > 02110-1301 USA > + */ > + > + > +Device (EC0) > +{ > + Name (_HID, EISAID ("PNP0C09")) > + Name(_UID, 1) > + > + Method(_CRS, 0) > + { > + Name(BFFR, ResourceTemplate() > + { > + IO(Decode16, 0x62, 0x62, 0, 1) // ACPI > DATA IN/OUT > + IO(Decode16, 0x66, 0x66, 0, 1) // CMD/STS > + IRQ(Edge, ActiveHigh, Exclusive) {0x0B} > + }) > + Return(BFFR) > + } > + > + OperationRegion(ECF0, EmbeddedControl, 0, 0xFF) > + Field(ECF2, ByteAcc, Lock, Preserve) > + { > + Offset(1), > + STMP, 8, // 1, Sensor Temperature > + ACPW, 8, // 2, AC Power (AC > Present = 1, else 0) > + LIDS, 8, // 3, Lid State (Lid Open > = 1, else 0) > + PBNS, 8, // 4, Power Button State > (Pressed = 1, else 0) > + BTST, 8, // 5, Battery Status > + BTCR, 8, // 6, Battery Current > Rate > + BTCC, 8, // 7, Battery Current > Capacity > + BTVT, 8, // 8, Battery Voltage > + offset(0x10), > + SPTR, 8, // 5, SMBus Protocol > Register > + SSTS, 8, // 5, SMBus Status > Register > + SADR, 8, // 6, SMBus Address > Register > + SCMD, 8, // 7, SMBus Command > Register > + SBFR, 256, // 8, SMBus Block Buffer > + SCNT, 8, // 40, SMBus Block Count > + } > + > + Method(_REG, 2) > + { > + } > + > + /* AC status: present */ > + Method(_Q01, 0, NotSerialized) > + { > + Notify (AC, 0x80) > + } > + > + /* AC status: dispear*/ > + Method(_Q02, 0, NotSerialized) > + { > + Notify (AC, 0x80) > + } > + > + Method(_Q04, 0, NotSerialized) > + { > + Notify(LID, 0x80) > + } > + > + Method(_Q04, 0, NotSerialized) > + { > + Notify(LID, 0x80) > + } > + > + Device(AC) > + { > + Name(_HID, "ACPI0003") > + Name(_UID, 0x00) > + Name(_PCL, Package() { \_SB } ) > + > + Method(_PSR, 0, NotSerialized) > + { > + return (ACPW) > + } > + > + Method(_STA, 0, NotSerialized) > + { > + Return (0x0f) > + } > + } > + > + Device(LID) > + { > + Name(_HID, "PNP0C0D") > + > + Method(_LID, 0, NotSerialized) > + { > + return (LIDS) > + } > + } > +} > -- > 1.7.2.5 > > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > > > > > -- > http://se-eng.com

1 0

Re: [SeaBIOS] [RFC][PATCH 2/2] hw: add Embedded Controller chip emulation
by li guang 18 Apr '13

18 Apr '13

No, sorry. As this is RFC patch, I sent it only for demo my thought. 在 2013-04-17三的 12:41 +0200，Mark Marshall写道： > Hi. > > > At least one major bug (noted below), have you tested all of this yet? > > > MM > > > On 17 April 2013 09:23, liguang <lig.fnst(a)cn.fujitsu.com> wrote: > this work implemented Embedded Controller chip emulation > which was defined at ACPI SEPC v5 chapter 12: > "ACPI Embedded Controller Interface Specification" > > commonly Embedded Controller will emulate keyboard, > mouse, handle ACPI defined operations and some > low-speed devices like SMbus. > > Signed-off-by: liguang <lig.fnst(a)cn.fujitsu.com> > --- > hw/ec.c | 113 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > hw/ec.h | 20 +++++++++++ > 2 files changed, 133 insertions(+), 0 deletions(-) > create mode 100644 hw/ec.c > create mode 100644 hw/ec.h > > diff --git a/hw/ec.c b/hw/ec.c > new file mode 100644 > index 0000000..69c92cf > --- /dev/null > +++ b/hw/ec.c > @@ -0,0 +1,113 @@ > +#include "ec.h" > +#include "hw/hw.h" > +#include "hw/isa/isa.h" > +#include "sysemu/sysemu.h" > + > +#define TYPE_EC_DEV > +#define EC_DEV(obj) \ > + OBJECT_CHECK(ECState, (obj), TYPE_EC_DEV) > + > +static char ec_acpi_space[EC_ACPI_SPACE_SIZE] = {0}; > + > +typedef struct ECState { > + ISADevice dev; > + char cmd; > + char status; > + char data; > + char irq; > + char buf; > + MemoryRegion io; > +} ECState; > + > + > +static void io62_write(void *opaque, hwaddr addr, uint64_t > val, unsigned size) > +{ > + ECState *s = opaque; > + char tmp = val & 0xff; > + > + if (s->status & EC_ACPI_CMD) { > + s->buf = tmp; > + s->status &= ~EC_ACPI_CMD; > + } else { > + if (tmp < EC_ACPI_SPACE_SIZE) { > + ec_acpi_space[s->buf] = tmp; > + } > + } > +} > + > +static uint64_t io62_read(void *opaque, hwaddr addr, unsigned > size) > +{ > + return s->data; > +} > + > +static void io66_write(void *opaque, hwaddr addr, uint64_t > val, unsigned size) > +{ > + ECState *s = opaque; > + > + s->status = EC_ACPI_CMD | EC_ACPI_IBF; > + > + switch (val & 0xff) { > + case EC_ACPI_CMD_READ: > + case EC_ACPI_CMD_WRITE: > + case EC_ACPI_CMD_BURST_EN: > + s->statu |= EC_ACPI_BST; > + case EC_ACPI_CMD_BURST_DN: > + s->statu &= ~EC_ACPI_BST; > + case EC_ACPI_CMD_QUERY: > + s->cmd = val & 0xff; > + case default: > + break; > + } > +} > > You've missed 'break' here a few times. > > > + > +static uint64_t io66_read(void *opaque, hwaddr addr, unsigned > size) > +{ > + ECState *s = opaque; > + > + return s->status; > +} > + > +static const MemoryRegionOps io62_io_ops = { > + .write = io62_write, > + .read = io62_read, > + .endianness = DEVICE_NATIVE_ENDIAN, > + .impl = { > + .min_access_size = 1, > + .max_access_size = 1, > + }, > +}; > + > +static const MemoryRegionOps io66_io_ops = { > + .write = io66_write, > + .read = io66_read, > + .endianness = DEVICE_NATIVE_ENDIAN, > + .impl = { > + .min_access_size = 1, > + .max_access_size = 1, > + }, > +}; > + > +static void ec_realizefn(DeviceState *dev, Error **err) > +{ > + ISADevice *isadev = ISA_DEVICE(dev); > + ECState *s = EC_DEV(dev); > + > + isa_init_irq(isadev, &s->irq, 0xb); > + > + memory_region_init_io(&s->io, &io62_io_ops, NULL, > "ec-acpi-data", 1); > + isa_register_ioport(isadev, &s->io, 0x62); > + > + memory_region_init_io(&s->io, &io66_io_ops, NULL, > "ec-acpi-cmd", 1); > + isa_register_ioport(isadev, &s->io, 0x66); > + > + s->status = 0; > + s->data = 0; > +} > + > +static void ec_class_initfn(ObjectClass *klass, void *data) > +{ > + DeviceClass *dc = DEVICE_CLASS(klass); > + > + dc->realize = ec_realizefn; > + dc->no_user = 1; > +} > diff --git a/hw/ec.h b/hw/ec.h > new file mode 100644 > index 0000000..110ce04 > --- /dev/null > +++ b/hw/ec.h > @@ -0,0 +1,20 @@ > +#inndef __EC_H > +#define __EC_H > + > +#define EC_ACPI_SPACE_SIZE 0x80 > + > +#define EC_ACPI_CMD_PORT 0x66 > +#define EC_ACPI_DATA_PORT 0x62 > + > +#define EC_ACPI_OBF 0x1 > +#define EC_ACPI_IBF 0x2 > +#define EC_ACPI_CMD 0x8 > +#define EC_ACPI_BST 0x10 > + > +#define EC_ACPI_CMD_READ 0x80 > +#define EC_ACPI_CMD_WRITE 0x81 > +#define EC_ACPI_BURST_EN 0x82 > +#define EC_ACPI_BURST_DN 0x83 > +#define EC_ACPI_CMD_QUERY 0x84 > + > +#endif > -- > 1.7.2.5 > > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > >

1 0

Re: [SeaBIOS] [RFC][PATCH 0/2] Embedded Controller chip emulation
by li guang 18 Apr '13

18 Apr '13

Oh, No, that's a private interface for Intel's AMT, this is a chip embedded in mainboard. 在 2013-04-17三的 11:04 +0200，Fred .写道： > HECI ? > http://en.wikipedia.org/wiki/Host_Embedded_Controller_Interface > > > > On Wed, Apr 17, 2013 at 9:32 AM, li guang <lig.fnst(a)cn.fujitsu.com> > wrote: > Embedded Controller chip could commonly be found > at platforms for laptop, it generally does > power management, keyboard and mouse simulation, > ACPI defined operation, low-speed devices handling ... > It talks with OS via io-port 0x60/0x54, 0x62/0x66, > the first pair is for i8042 compatible, the last > pair is for ACPI functions. > As QEMU has done power management, i8042 emulation, > this RFC patch will only focus on ACPI functions. > you can find standard description a ACPI SPEC > "ACPI Embedded Controller Interface Specification" > > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS April 2013