July 2012 - SeaBIOS - mail.coreboot.org

Re: [SeaBIOS] [PATCH] geodevga: make use of readl and writel for mmio access
by ron minnich July 18, 2012

July 18, 2012

Memory slowly returns. The "key idea" of the geode was that certain hardware was implemented in the very complex software that is always running underneath. Hence, many registers are always virtual. Hence, certain types of register writes trigger SMI-like behaviour. I'd be very careful about messing with this code. ron

1 0

Re: [SeaBIOS] [PATCH] geodevga: make use of readl and writel for mmio access
by Christian Gmeiner July 18, 2012

July 18, 2012

2012/7/18 ron minnich <rminnich(a)gmail.com>: > The change worried me too, but I have not done Geode for a long time. > I have looked through the lx800 datasheet [1] and did not found any hint about SMI triggering. If that would be the case linux would need to do this too?! But okay... as I need to get flat panel support working really soon, I will go an other way and will leave this and build wrapper functions like read_vp(..) - similar to the linux ones. In the end I would like to use most of the code from the linux fb driver. On the other hand I will try to find someone how uses the vgabios on a geode with a vga connector. I know that geode vbios was created during gsoc and I am wondering if there are any documentations or anything else available? [1] http://wiki.laptop.org/images/a/a1/Lx_databook.pdf greets --- Christian Gmeiner, MSc

1 0

Re: [SeaBIOS] [PATCH] geodevga: make use of readl and writel for mmio access
by ron minnich July 18, 2012

July 18, 2012

The change worried me too, but I have not done Geode for a long time. ron

1 0

Re: [SeaBIOS] [PATCH] geodevga: make use of readl and writel for mmio access
by Kevin O'Connor July 17, 2012

July 17, 2012

On Tue, Jul 17, 2012 at 12:08:59PM +0200, Christian Gmeiner wrote: > This commit just simplifies some code. The old code looked to be triggering some kind of SMI to perform the action. Is it really that simple to just replace it with a direct memory access? -Kevin

2 1

Re: [SeaBIOS] Bootorder Failover (Patch)
by Kevin O'Connor July 17, 2012

July 17, 2012

On Tue, Jul 17, 2012 at 07:40:13AM -0600, Steve Goodrich wrote: > There's certainly no reason to add an artificial limitation. Right, we'll continue to treat the f-segment as read-only after POST even on coreboot. > However, I'm happy to change the implementation if someone can help me > figure out how to read a sector directly (i.e. without using the int 13h > calls). Populate a "struct disk_op_s" and then call process_op() on it. (You will need to remove the ASSERT16 call from process_op.) You can look at cdrom_boot for an example (it calls cdb_read instead of process_op, but the process is the same). -Kevin

1 0

Re: [SeaBIOS] Bootorder Failover (Patch)
by Kevin O'Connor July 17, 2012

July 17, 2012

On Mon, Jul 16, 2012 at 07:18:01AM -0600, Steve Goodrich wrote: > Thanks for the feedback, Kevin. > > > I don't think I understand the use case you are trying to address. > > The use case is one I've got with a few customers who do not want end users > to be able to change the boot order manually -- USB is a "last ditch" > option, only to be used if all other devices fail, but they don't want users > booting from their own USB drives if the other boot options are still > functional. Also, these customers all have the same expectation with > respect to bootorder: if the first drive is not bootable (even if it is > present), then the next drive in the bootorder will be attempted. Thus, if > the first drive is present but has no MBR (or its MBR has become corrupt), > they expect the second drive to boot. Of course, the second drive can't > boot in the current implementation since only the first drive can ever be > 0x80. If checking for an MBR is sufficient to determine if the drive is "bootable" then I'd suggest adding an option to read and validate the MBR in the POST phase prior to assigning a drive id to it. [...] > Why is it not safe to alter the IDMap in the boot phase? Is it unsafe to > allow it to change before the device has actually booted, or is it only > unsafe to change once the device has transferred execution to the OS? The BIOS specs call for making the f-segment read-only after the POST phase ends. This is implemented under QEMU (and only on QEMU). The "IDMap" variable (along with all variables marked with VAR16) is stored in the f-segment. -Kevin

3 3

[rfc patch seabios 0/3] s3 improvements
by Gerd Hoffmann July 17, 2012

July 17, 2012

Hi, This patch series carries the dsdt updates needed for the qemu patch series just posted. cheers, Gerd Gerd Hoffmann (3): wakeup: kbd & mouse wakeup: serial wakeup: uhci src/acpi-dsdt.dsl | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 60 insertions(+), 0 deletions(-)

1 3

[rfc patch qemu 0/4] s3 improvements
by Gerd Hoffmann July 17, 2012

July 17, 2012

Hi, This patch series (and the seabios patch series following in a minute) improve s3 support in qemu. The patches allocates a bunch of acpi gpe bits for s3 wakeup of piix chipset devices (ps/2 keyboard, ps/2 mouse, serial port, uhci controller) and does the windup needed so the guest can enable+disable wakeup per device using apci. With this patch series applied /proc/acpi/wakeup inside the guest looks like this ... Device S-state Status Sysfs node UHCI S3 *enabled pci:0000:00:01.2 KBD S3 *enabled pnp:00:02 MOU S3 *disabled pnp:00:03 COM1 S3 *disabled pnp:00:05 ... and you can use "echo $device > /proc/acpi/wakeup" to toggle enabled/disabled. comments? Gerd Gerd Hoffmann (4): wakeup: add acpi gpe wakeup reasons wakeup: make ps/2 configurable wakeup: make serial configurable wakeup: uhci support hw/acpi.c | 26 ++++++++++++++++++++++++++ hw/ps2.c | 4 ++-- hw/serial.c | 10 +++++++++- hw/usb/hcd-uhci.c | 35 +++++++++++++++++++++++++++++++++++ sysemu.h | 4 ++++ 5 files changed, 76 insertions(+), 3 deletions(-)

1 4

[PATCH] geodevga: make use of readl and writel for mmio access
by Christian Gmeiner July 17, 2012

July 17, 2012

This commit just simplifies some code. Signed-off-by: Christian Gmeiner <christian.gmeiner(a)gmail.com> --- vgasrc/geodevga.c | 48 +++++++++--------------------------------------- 1 file changed, 9 insertions(+), 39 deletions(-) diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c index 5c6caf0..4e3d912 100644 --- a/vgasrc/geodevga.c +++ b/vgasrc/geodevga.c @@ -52,37 +52,6 @@ static void geode_msrWrite(u32 msrAddr,u32 andhi, u32 andlo, u32 orhi, u32 orlo) ); } -static u32 geode_memRead(u32 addr) -{ - u32 val; - asm __volatile__ ( - "movw $0x0AC1C, %%dx \n" - "movl $0xFC530001, %%eax \n" - "outl %%eax, %%dx \n" - "addb $2, %%dl \n" - "inw %%dx, %%ax \n" - : "=a" (val) - : "b"(addr) - : "cc" - ); - - return val; -} - -static void geode_memWrite(u32 addr, u32 and, u32 or ) -{ - asm __volatile__ ( - "movw $0x0AC1C, %%dx \n" - "movl $0xFC530001, %%eax \n" - "outl %%eax, %%dx \n" - "addb $2, %%dl \n" - "outw %%ax, %%dx \n" - : - : "b"(addr), "S" (and), "D" (or) - : "%eax","cc" - ); -} - static int legacyio_check(void) { int ret=0; @@ -249,7 +218,8 @@ static int dc_setup(void) */ int vp_setup(void) { - u32 reg,vp; + u32 reg; + void *vp; dprintf(2,"VP_SETUP\n"); /* set output to crt and RGB/YUV */ @@ -259,23 +229,23 @@ int vp_setup(void) geode_msrWrite(VP_MSR_CONFIG_LX, ~0, ~0xf8, 0, 0); /* get vp register base from pci */ - vp = pci_config_readl(GET_GLOBAL(VgaBDF), PCI_BASE_ADDRESS_3); + vp = (void *)pci_config_readl(GET_GLOBAL(VgaBDF), PCI_BASE_ADDRESS_3); /* Set mmio registers * there may be some timing issues here, the reads seem * to slow things down enough work reliably */ - reg = geode_memRead(vp+VP_MISC); + reg = readl(vp+VP_MISC); dprintf(1,"VP_SETUP VP_MISC=0x%08x\n",reg); - geode_memWrite(vp+VP_MISC,0,VP_BYP_BOTH); - reg = geode_memRead(vp+VP_MISC); + writel(vp+VP_MISC,VP_BYP_BOTH); + reg = readl(vp+VP_MISC); dprintf(1,"VP_SETUP VP_MISC=0x%08x\n",reg); - reg = geode_memRead(vp+VP_DCFG); + reg = readl(vp+VP_DCFG); dprintf(1,"VP_SETUP VP_DCFG=0x%08x\n",reg); - geode_memWrite(vp+VP_DCFG, ~0,VP_CRT_EN+VP_HSYNC_EN+VP_VSYNC_EN+VP_DAC_BL_EN+VP_CRT_SKEW); - reg = geode_memRead(vp+VP_DCFG); + writel(vp+VP_DCFG,VP_CRT_EN+VP_HSYNC_EN+VP_VSYNC_EN+VP_DAC_BL_EN+VP_CRT_SKEW); + reg = readl(vp+VP_DCFG); dprintf(1,"VP_SETUP VP_DCFG=0x%08x\n",reg); return 0; -- 1.7.11.rc2.5.g68f532f

1 0

Re: [SeaBIOS] Bootorder Failover (Patch)
by Kevin O'Connor July 16, 2012

July 16, 2012

On Fri, Jul 13, 2012 at 09:32:21AM -0600, Steve Goodrich wrote: > Legacy MBRs on HDDs and USB MSCs allow booting only from device id 0x80. > This is OK for platforms that have only one HDD or USB device to boot from, > but causes problems if the end user wants to have more than one HDD or USB > MSC device in the boot order (and if those devices are present, but not > bootable). [...] > With the code in this patch, the system would behave like this: > * Assign HDD1 as device 0x80 and attempt to boot > * boot fails because the device is not bootable > * Rotate the boot order to be HDD2, Floppy, USB1, USB2, HDD1, making HDD2 > device 0x80 The problem with this approach is that there is no way to change the drive id of hard drives controlled via option roms (eg, scsi drives). So, if a scsi drive is made 0x80 this scheme does not work at all, and if a scsi drive is not 0x80 there is no way to boot from it. > Thoughts? I don't think I understand the use case you are trying to address. If a user has a stable set of drives attached they can configure the boot order via the bootorder file. If the user is attaching drives for one-off boots, they can hit F12 and choose which drive to boot from. What is the use case for a user that does not have a stable attachment of drives and is unable to hit F12? On a technical note, the patch has some implementation issues: the use of "#if"s is undesirable - the compiler can weed out unused code and variables; SeaBIOS no longer uses the EBDA for internal storage - use global variables with the "VARLOW" decoration instead; it's not safe to alter IDMap in the boot phase as global variables are read-only after POST phase ends. -Kevin

2 1