SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Start a nNew thread

Re: [SeaBIOS] [PATCH] geodevga: make use of readl and writel for mmio access
by ron minnich 18 Jul '12

18 Jul '12

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 18 Jul '12

18 Jul '12

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 18 Jul '12

18 Jul '12

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 17 Jul '12

17 Jul '12

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 17 Jul '12

17 Jul '12

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 17 Jul '12

17 Jul '12

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 17 Jul '12

17 Jul '12

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 16 Jul '12

16 Jul '12

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

Re: [SeaBIOS] Plan to add POST memory manager (PMM) support
by Fred . 15 Jul '12

15 Jul '12

Good luck with it! :) Hope to hear back soon how it goes with it, and patches contributed back upstreams. On Sun, Jul 15, 2012 at 6:14 AM, Darmawan Salihun <darmawan.salihun(a)gmail.com> wrote: > Hi Fred, > > Yes, I need it to test something at work. It's not very urgent at the moment. > > Regards, > > Darmawan > > On 7/15/12, Fred . <eldmannen(a)gmail.com> wrote: >> Darmawan, will you be implementing PnP support in SeaBIOS? >> >> On Sat, Jul 14, 2012 at 9:50 PM, Darmawan Salihun >> <darmawan.salihun(a)gmail.com> wrote: >>> On 7/15/12, Kevin O'Connor <kevin(a)koconnor.net> wrote: >>>> On Sun, Jul 15, 2012 at 02:20:42AM +0700, Darmawan Salihun wrote: >>>>> First, I made a mistake, I was actually referring to the PnP support >>>> >>>> On Sat, Jul 14, 2012 at 10:57:00PM +0700, Darmawan Salihun wrote: >>>>> Is there any plan to add this feature in the near future? >>>>> I have a plan to add the feature if it's not there yet, but I want to >>>>> know first whether >>>>> there's already plan for that. >>>> >>>> I have no plans to implement PnP, and I have not heard of any plans >>>> from anyone else. To the best of my knowledge, nothing really uses >>>> the PnP interface anymore. The stubs are in SeaBIOS to make some >>>> option roms (namely gpxe) recognize that the BBS spec is supported. >>>> >>>> Feel free to send patches. >>>> >>>> -Kevin >>>> >>> >>> OK. Thanks for the info. >>> >>> Regards, >>> >>> Darmawan >>> >>> -- >>> -------------------------------------------------------------------- >>> -= Human knowledge belongs to the world =- >>> >>> _______________________________________________ >>> SeaBIOS mailing list >>> SeaBIOS(a)seabios.org >>> http://www.seabios.org/mailman/listinfo/seabios >> > > > -- > -------------------------------------------------------------------- > -= Human knowledge belongs to the world =-

1 0

Re: [SeaBIOS] [Qemu-devel] [QEMU PATCH 2/7] hw/apic.c: rename bit functions to not conflict with bitops.h
by Gleb Natapov 15 Jul '12

15 Jul '12

On Sat, Jul 14, 2012 at 09:09:23AM +0000, Blue Swirl wrote: > On Fri, Jul 13, 2012 at 6:07 PM, Eduardo Habkost <ehabkost(a)redhat.com> wrote: > > On Thu, Jul 12, 2012 at 07:24:35PM +0000, Blue Swirl wrote: > >> On Tue, Jul 10, 2012 at 8:22 PM, Eduardo Habkost <ehabkost(a)redhat.com> wrote: > >> > Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com> > >> > >> Maybe the bitops functions should be renamed instead, for example > >> prefixed by 'qemu_'. That may be safer if one day the kernel find > >> their way to system headers too. > > > > Well, if there's any risk the kernel functions will conflict with the > > QEMU function names, that would be an additional reason to rename the > > apic.c functions too, so they don't conflict with the kernel functions > > either. > > Yes, that could be the case too. > Than it would be Linux headers problem and will be fixed there. > > > > Personally, I would never sent a patch to rename the bitops.h functions, > > as the current names work perfectly to me. > > > >> > >> > --- > >> > hw/apic.c | 34 +++++++++++++++++----------------- > >> > 1 file changed, 17 insertions(+), 17 deletions(-) > >> > > >> > diff --git a/hw/apic.c b/hw/apic.c > >> > index 60552df..d322fe3 100644 > >> > --- a/hw/apic.c > >> > +++ b/hw/apic.c > >> > @@ -50,7 +50,7 @@ static int ffs_bit(uint32_t value) > >> > return ctz32(value); > >> > } > >> > > >> > -static inline void set_bit(uint32_t *tab, int index) > >> > +static inline void apic_set_bit(uint32_t *tab, int index) > >> > { > >> > int i, mask; > >> > i = index >> 5; > >> > @@ -58,7 +58,7 @@ static inline void set_bit(uint32_t *tab, int index) > >> > tab[i] |= mask; > >> > } > >> > > >> > -static inline void reset_bit(uint32_t *tab, int index) > >> > +static inline void apic_reset_bit(uint32_t *tab, int index) > >> > { > >> > int i, mask; > >> > i = index >> 5; > >> > @@ -66,7 +66,7 @@ static inline void reset_bit(uint32_t *tab, int index) > >> > tab[i] &= ~mask; > >> > } > >> > > >> > -static inline int get_bit(uint32_t *tab, int index) > >> > +static inline int apic_get_bit(uint32_t *tab, int index) > >> > { > >> > int i, mask; > >> > i = index >> 5; > >> > @@ -183,7 +183,7 @@ void apic_deliver_pic_intr(DeviceState *d, int level) > >> > case APIC_DM_FIXED: > >> > if (!(lvt & APIC_LVT_LEVEL_TRIGGER)) > >> > break; > >> > - reset_bit(s->irr, lvt & 0xff); > >> > + apic_reset_bit(s->irr, lvt & 0xff); > >> > /* fall through */ > >> > case APIC_DM_EXTINT: > >> > cpu_reset_interrupt(s->cpu_env, CPU_INTERRUPT_HARD); > >> > @@ -379,13 +379,13 @@ void apic_poll_irq(DeviceState *d) > >> > > >> > static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode) > >> > { > >> > - apic_report_irq_delivered(!get_bit(s->irr, vector_num)); > >> > + apic_report_irq_delivered(!apic_get_bit(s->irr, vector_num)); > >> > > >> > - set_bit(s->irr, vector_num); > >> > + apic_set_bit(s->irr, vector_num); > >> > if (trigger_mode) > >> > - set_bit(s->tmr, vector_num); > >> > + apic_set_bit(s->tmr, vector_num); > >> > else > >> > - reset_bit(s->tmr, vector_num); > >> > + apic_reset_bit(s->tmr, vector_num); > >> > if (s->vapic_paddr) { > >> > apic_sync_vapic(s, SYNC_ISR_IRR_TO_VAPIC); > >> > /* > >> > @@ -405,8 +405,8 @@ static void apic_eoi(APICCommonState *s) > >> > isrv = get_highest_priority_int(s->isr); > >> > if (isrv < 0) > >> > return; > >> > - reset_bit(s->isr, isrv); > >> > - if (!(s->spurious_vec & APIC_SV_DIRECTED_IO) && get_bit(s->tmr, isrv)) { > >> > + apic_reset_bit(s->isr, isrv); > >> > + if (!(s->spurious_vec & APIC_SV_DIRECTED_IO) && apic_get_bit(s->tmr, isrv)) { > >> > ioapic_eoi_broadcast(isrv); > >> > } > >> > apic_sync_vapic(s, SYNC_FROM_VAPIC | SYNC_TO_VAPIC); > >> > @@ -445,7 +445,7 @@ static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, > >> > int idx = apic_find_dest(dest); > >> > memset(deliver_bitmask, 0x00, MAX_APIC_WORDS * sizeof(uint32_t)); > >> > if (idx >= 0) > >> > - set_bit(deliver_bitmask, idx); > >> > + apic_set_bit(deliver_bitmask, idx); > >> > } > >> > } else { > >> > /* XXX: cluster mode */ > >> > @@ -455,11 +455,11 @@ static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, > >> > if (apic_iter) { > >> > if (apic_iter->dest_mode == 0xf) { > >> > if (dest & apic_iter->log_dest) > >> > - set_bit(deliver_bitmask, i); > >> > + apic_set_bit(deliver_bitmask, i); > >> > } else if (apic_iter->dest_mode == 0x0) { > >> > if ((dest & 0xf0) == (apic_iter->log_dest & 0xf0) && > >> > (dest & apic_iter->log_dest & 0x0f)) { > >> > - set_bit(deliver_bitmask, i); > >> > + apic_set_bit(deliver_bitmask, i); > >> > } > >> > } > >> > } else { > >> > @@ -502,14 +502,14 @@ static void apic_deliver(DeviceState *d, uint8_t dest, uint8_t dest_mode, > >> > break; > >> > case 1: > >> > memset(deliver_bitmask, 0x00, sizeof(deliver_bitmask)); > >> > - set_bit(deliver_bitmask, s->idx); > >> > + apic_set_bit(deliver_bitmask, s->idx); > >> > break; > >> > case 2: > >> > memset(deliver_bitmask, 0xff, sizeof(deliver_bitmask)); > >> > break; > >> > case 3: > >> > memset(deliver_bitmask, 0xff, sizeof(deliver_bitmask)); > >> > - reset_bit(deliver_bitmask, s->idx); > >> > + apic_reset_bit(deliver_bitmask, s->idx); > >> > break; > >> > } > >> > > >> > @@ -557,8 +557,8 @@ int apic_get_interrupt(DeviceState *d) > >> > apic_sync_vapic(s, SYNC_TO_VAPIC); > >> > return s->spurious_vec & 0xff; > >> > } > >> > - reset_bit(s->irr, intno); > >> > - set_bit(s->isr, intno); > >> > + apic_reset_bit(s->irr, intno); > >> > + apic_set_bit(s->isr, intno); > >> > apic_sync_vapic(s, SYNC_TO_VAPIC); > >> > apic_update_irq(s); > >> > return intno; > >> > -- > >> > 1.7.10.4 > >> > > >> > > >> > > > > -- > > Eduardo -- Gleb.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS