SeaBIOS June 2012

seabios@seabios.org

23 participants
35 discussions

[RFC][PATCH 0/2] Use extra stack for all regular real-mode entry points
by Kevin O'Connor 14 Jun '12

14 Jun '12

This simple series changes SeaBIOS to use its extra stack for all regular real-mode software interrupt entry points. This has the advantage of using significantly less stack space, which can make old programs more likely to run. As an example, SeaBIOS can boot and run DOS 1.0 with this series applied. However, by using the extra stack (which resides in the e-segment), the code will likely not work for any code that invokes the real-mode software interrupts while in 16bit protected mode. I don't believe that is common, but it is difficult to know if there are any users. I will send a separate email on that topic. -Kevin Kevin O'Connor (2): Check for and handle PCI BIOS calls separately from handle_1a path. Jump into extra stack for all regular real-mode software irq entry points. src/clock.c | 2 +- src/config.h | 2 +- src/pcibios.c | 12 ++++++++-- src/post.c | 2 +- src/romlayout.S | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++---- src/util.h | 1 - 6 files changed, 76 insertions(+), 11 deletions(-) -- 1.7.10.2

1 2

[PATCH] Support USB MSC devices with multiples LUNs
by Sven Schnelle 14 Jun '12

14 Jun '12

There are USB Mass storage devices which have more than one device. Examples are CD Changers, or USB sticks which are partitioned in a CDROM and Harddisk device. Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/usb-msc.c | 100 +++++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 72 insertions(+), 28 deletions(-) diff --git a/src/usb-msc.c b/src/usb-msc.c index c53a1f5..6025a03 100644 --- a/src/usb-msc.c +++ b/src/usb-msc.c @@ -16,6 +16,7 @@ struct usbdrive_s { struct drive_s drive; struct usb_pipe *bulkin, *bulkout; + int lun; }; @@ -78,7 +79,7 @@ usb_cmd_data(struct disk_op_s *op, void *cdbcmd, u16 blocksize) cbw.dCBWTag = 999; // XXX cbw.dCBWDataTransferLength = bytes; cbw.bmCBWFlags = cdb_is_read(cdbcmd, blocksize) ? USB_DIR_IN : USB_DIR_OUT; - cbw.bCBWLUN = 0; // XXX + cbw.bCBWLUN = GET_GLOBAL(udrive_g->lun); cbw.bCBWCBLength = USB_CDB_SIZE; // Transfer cbw to device. @@ -117,6 +118,47 @@ fail: return DISK_RET_EBADTRACK; } +static int +usb_msc_maxlun(struct usb_pipe *pipe, unsigned char *maxlun) +{ + if (!CONFIG_USB_MSC) + return -1; + + struct usb_ctrlrequest req; + req.bRequestType = USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE; + req.bRequest = 0xfe; + req.wValue = 0; + req.wIndex = 0; + req.wLength = 1; + return send_default_control(pipe, &req, maxlun); +} + +static int usb_msc_init_lun(struct usb_pipe *inpipe, + struct usb_pipe *outpipe, + struct usbdevice_s *usbdev, + int lun) +{ + // Allocate drive structure. + struct usbdrive_s *udrive_g = malloc_fseg(sizeof(*udrive_g)); + if (!udrive_g) { + warn_noalloc(); + return -1; + } + memset(udrive_g, 0, sizeof(*udrive_g)); + udrive_g->drive.type = DTYPE_USB; + udrive_g->lun = lun; + + udrive_g->bulkin = inpipe; + udrive_g->bulkout = outpipe; + + if (scsi_init_drive(&udrive_g->drive, + "USB MSC", bootprio_find_usb(usbdev))) { + dprintf(1, "Unable to configure USB MSC device.\n"); + free(udrive_g); + return -1; + } + return 0; +} /**************************************************************** * Setup @@ -126,6 +168,11 @@ fail: int usb_msc_init(struct usbdevice_s *usbdev) { + struct usb_pipe *inpipe = NULL, *outpipe = NULL; + struct usb_endpoint_descriptor *indesc, *outdesc; + unsigned char maxlun, lun; + int pipesused = 0; + if (!CONFIG_USB_MSC) return -1; @@ -140,39 +187,36 @@ usb_msc_init(struct usbdevice_s *usbdev) return -1; } - // Allocate drive structure. - struct usbdrive_s *udrive_g = malloc_fseg(sizeof(*udrive_g)); - if (!udrive_g) { - warn_noalloc(); - goto fail; - } - memset(udrive_g, 0, sizeof(*udrive_g)); - udrive_g->drive.type = DTYPE_USB; - // Find bulk in and bulk out endpoints. - struct usb_endpoint_descriptor *indesc = findEndPointDesc( - usbdev, USB_ENDPOINT_XFER_BULK, USB_DIR_IN); - struct usb_endpoint_descriptor *outdesc = findEndPointDesc( - usbdev, USB_ENDPOINT_XFER_BULK, USB_DIR_OUT); - if (!indesc || !outdesc) - goto fail; - udrive_g->bulkin = usb_alloc_pipe(usbdev, indesc); - udrive_g->bulkout = usb_alloc_pipe(usbdev, outdesc); - if (!udrive_g->bulkin || !udrive_g->bulkout) + if (!(indesc = findEndPointDesc(usbdev, USB_ENDPOINT_XFER_BULK, + USB_DIR_IN))) goto fail; - int prio = bootprio_find_usb(usbdev); - int ret = scsi_init_drive(&udrive_g->drive, "USB MSC", prio); - if (ret) + if (!(outdesc = findEndPointDesc(usbdev, USB_ENDPOINT_XFER_BULK, + USB_DIR_OUT))) goto fail; + if (!(inpipe = usb_alloc_pipe(usbdev, indesc))) + goto fail; + + + if (!(outpipe = usb_alloc_pipe(usbdev, outdesc))) + goto fail; + + if (usb_msc_maxlun(usbdev->defpipe, &maxlun)) + maxlun = 0; + + for(lun = 0; lun < maxlun + 1; lun++) { + if (!usb_msc_init_lun(inpipe, outpipe, usbdev, lun)) + pipesused = 1; + } + + if (!pipesused) + goto fail; + return 0; fail: - dprintf(1, "Unable to configure USB MSC device.\n"); - if (udrive_g) { - free_pipe(udrive_g->bulkin); - free_pipe(udrive_g->bulkout); - free(udrive_g); - } + free_pipe(inpipe); + free_pipe(outpipe); return -1; } -- 1.7.10

3 8

[PATCH] EHCI: Add support for 64 bit capability
by Sven Schnelle 14 Jun '12

14 Jun '12

Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/usb-ehci.c | 6 ++---- src/usb-ehci.h | 9 ++++++--- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/src/usb-ehci.c b/src/usb-ehci.c index 4cb3e6a..8267a63 100644 --- a/src/usb-ehci.c +++ b/src/usb-ehci.c @@ -334,10 +334,6 @@ ehci_init(struct pci_device *pci, int busid, struct pci_device *comppci) u32 baseaddr = pci_config_readl(bdf, PCI_BASE_ADDRESS_0); struct ehci_caps *caps = (void*)(baseaddr & PCI_BASE_ADDRESS_MEM_MASK); u32 hcc_params = readl(&caps->hccparams); - if (hcc_params & HCC_64BIT_ADDR) { - dprintf(1, "No support for 64bit EHCI\n"); - return -1; - } struct usb_ehci_s *cntl = malloc_tmphigh(sizeof(*cntl)); if (!cntl) { @@ -349,6 +345,8 @@ ehci_init(struct pci_device *pci, int busid, struct pci_device *comppci) cntl->usb.pci = pci; cntl->usb.type = USB_TYPE_EHCI; cntl->caps = caps; + if (hcc_params & HCC_64BIT_ADDR) + cntl->regs->ctrldssegment = 0; cntl->regs = (void*)caps + readb(&caps->caplength); dprintf(1, "EHCI init on dev %02x:%02x.%x (regs=%p)\n" diff --git a/src/usb-ehci.h b/src/usb-ehci.h index b295c78..924bbd8 100644 --- a/src/usb-ehci.h +++ b/src/usb-ehci.h @@ -102,7 +102,7 @@ struct ehci_qh { u32 alt_next; u32 token; u32 buf[5]; - // u32 buf_hi[5]; + u32 buf_hi[5]; } PACKED; #define QH_CONTROL (1 << 27) @@ -140,8 +140,11 @@ struct ehci_qtd { u32 alt_next; u32 token; u32 buf[5]; - //u32 buf_hi[5]; -} PACKED; + u32 buf_hi[5]; + /* keep struct size a multiple of 32 Bytes, as we're allocating + arrays. Without this padding, the second qtd would have the + wrong alignment. */ +} PACKED __aligned(32); #define QTD_TOGGLE (1 << 31) #define QTD_LENGTH_SHIFT 16 -- 1.7.10

2 6

[PATCH] pci: runtime i/o window sizing
by Gerd Hoffmann 14 Jun '12

14 Jun '12

Update the pci i/o windows at runtime, depending on the amount memory the machine has. The 32bit window starts above low memory and ends at the ioapic map address, the 64bit window is placed above high memory. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/pciinit.c | 21 +++++++++++++++------ 1 files changed, 15 insertions(+), 6 deletions(-) diff --git a/src/pciinit.c b/src/pciinit.c index dc33f83..68f302a 100644 --- a/src/pciinit.c +++ b/src/pciinit.c @@ -592,6 +592,8 @@ static void pci_region_map_entries(struct pci_bus *busses, struct pci_region *r) static void pci_bios_map_devices(struct pci_bus *busses) { + pcimem_start = RamSize; + if (pci_bios_init_root_regions(busses)) { struct pci_region r64_mem, r64_pref; r64_mem.list = NULL; @@ -604,14 +606,21 @@ static void pci_bios_map_devices(struct pci_bus *busses) if (pci_bios_init_root_regions(busses)) panic("PCI: out of 32bit address space\n"); - r64_mem.base = pcimem64_start; - u64 sum = pci_region_sum(&r64_mem); - u64 align = pci_region_align(&r64_pref); - r64_pref.base = ALIGN(r64_mem.base + sum, align); - if (r64_pref.base + pci_region_sum(&r64_pref) > pcimem64_end) - panic("PCI: out of 64bit address space\n"); + u64 sum_mem = pci_region_sum(&r64_mem); + u64 sum_pref = pci_region_sum(&r64_pref); + u64 align_mem = pci_region_align(&r64_mem); + u64 align_pref = pci_region_align(&r64_pref); + + r64_mem.base = ALIGN(0x100000000LL + RamSizeOver4G, align_mem); + r64_pref.base = ALIGN(r64_mem.base + sum_mem, align_pref); + pcimem64_start = r64_mem.base; + pcimem64_end = r64_pref.base + sum_pref; + pci_region_map_entries(busses, &r64_mem); pci_region_map_entries(busses, &r64_pref); + } else { + // no bars mapped high -> drop 64bit window (see dsdt) + pcimem64_start = 0; } // Map regions on each device. int bus; -- 1.7.1

2 1

One ROM for multiple devices
by Steve Goodrich 13 Jun '12

13 Jun '12

Please be aware that this is cross-posted to both the SeaBIOS and coreboot mailing lists. I know this is generally frowned upon, but I believe the subject is valid for discussion in both forums. I have a coreboot/SeaBIOS image containing an option ROM that works for multiple graphics devices (seven or eight of them). These graphics devices come from the same vendor but each device has its own (unique) PCI Device ID. If I'm going to load the driver from SeaBIOS, I need to have a copy of the option ROM file, each with the name of the target PCI device (e.g. "pci1234,5678.rom"). Having seven or eight copies in the BIOS image file is a waste of space. Stefan R. submitted a solution to coreboot to enable mapping one ROM's vendor/device ID to another and this solution has worked well for coreboot-centric uses. Unfortunately, this does not address the problem in SeaBIOS. I have started working on a solution that extends what Stefan has done, but moves the data into a single "translate" file in CBFS. This file contains simple data to allow coreboot and/or SeaBIOS to take a PCI device's vendor/device info and retrieve alternate vendor/device values. Since both coreboot and SeaBIOS understand CBFS, the basic translation code would be identical. The data file consists of sets of four 16-bit binary values: u16 vendor1, device1; // translate FROM this PCI v/d u16 vendor2, device2; // translate TO this PCI v/d If you have a single ROM which could support three devices, you would have two sets of data: 0x1234, 0x0001, 0x1234, 0x0002 0x1234, 0x0001, 0x1234, 0x0003 This data would let the ROM for vendor 0x1234, device 0x0001 support devices 0x0002 and 0x0003. NOTE: there is no data for device 0x0001, since it would be handled without translation. The code would work something like this: sprintf(name, "pci%04x,%04x.rom", pci->vendor, pci->device); rom = cbfs_findfile(name); // load the file if (!rom) { // ROM not found... try translation ven = pci->vendor; dev = pci->device; if (translate_findFirst(&ven, &dev)) { do { sprintf(name, "pci%04x,%04x.rom", ven, dev); rom = cbfs_findfile(name); // load the file while ((rom == null) && translate_findNext(&ven, &dev)); } } I'm not tied to the findFirst/findNext mechanism nor to the specific format of the data. What I would like to see is some mechanism in both coreboot and SeaBIOS that would allow a given ROM to be used for multiple devices. In coreboot this would affect the map_oprom_vendev() function. In SeaBIOS this would affect both lookup_hardcode() and map_pcirom(). Since this problem exists in both codebases, is it reasonable to come up with a solution that will work in both codebases? Thoughts? -- Steve G.

3 2

Re: [SeaBIOS] [coreboot] One ROM for multiple devices
by Peter Stuge 13 Jun '12

13 Jun '12

Steve Goodrich wrote: > I would like to see is some mechanism in both coreboot and SeaBIOS > that would allow a given ROM to be used for multiple devices. .. > Since this problem exists in both codebases, is it reasonable to > come up with a solution that will work in both codebases? I think this should happen in CBFS. The proposal is basically a special case symlink. It would be nice to have generic symlinks instead. Another special case solution yet still CBFS-centered could be to search for wildcard option ROMs at runtime. (V and D below are hexits, while x is a literal x.) 1. pciVVVV,DDDD.rom 2. pciVVVV,DDDx.rom 3. pciVVVV,DDxx.rom 4. pciVVVV,Dxxx.rom 5. pciVVVV,xxxx.rom 6. pciVVVx,xxxx.rom 7. pciVVxx,xxxx.rom 8. pciVxxx,xxxx.rom 9. pcixxxx,xxxx.rom 6 through 9 may be debatable, but I'm not neccessarily against them! //Peter

1 0

Re: [SeaBIOS] [coreboot] One ROM for multiple devices
by Kevin O'Connor 13 Jun '12

13 Jun '12

On Tue, Jun 12, 2012 at 05:06:11PM -0600, Steve Goodrich wrote: > Please be aware that this is cross-posted to both the SeaBIOS and coreboot > mailing lists. I know this is generally frowned upon, but I believe the > subject is valid for discussion in both forums. > > > I have a coreboot/SeaBIOS image containing an option ROM that works for > multiple graphics devices (seven or eight of them). These graphics devices > come from the same vendor but each device has its own (unique) PCI Device > ID. If I'm going to load the driver from SeaBIOS, I need to have a copy of > the option ROM file, each with the name of the target PCI device (e.g. > "pci1234,5678.rom"). Having seven or eight copies in the BIOS image file is > a waste of space. For the SeaBIOS case, is there any reason you can't simply place the rom in a cbfs file "vgaroms/myrom.rom"? -Kevin

1 0

Re: [SeaBIOS] [coreboot] AMD Persimmon VGA Option ROM
by Wolfgang Kamp - datakamp 12 Jun '12

12 Jun '12

Hi, now I have debugged the seabios pci probing. The things happen in pci.c. The pci_next function probes all possible Bus:Device:Function combinations in the right manner. The behavior is that the bdf 00:01:0 returns 0xffff as vendor id. So the device is really not present at this time. But coreboot earlier has enumerated these device correctly. How could it be that the graphics unit of the AMD G-series APU T40E is hidden from the pci bus? The device is only present to seabios when coreboot executes the VGA ROM bios. Wolfgang -----Ursprüngliche Nachricht----- Von: coreboot-bounces(a)coreboot.org [mailto:coreboot-bounces@coreboot.org] Im Auftrag von Kevin O'Connor Gesendet: Dienstag, 12. Juni 2012 03:35 An: Stefan Reinauer Cc: coreboot(a)coreboot.org Betreff: Re: [coreboot] VGA Option ROM On Sat, Jun 09, 2012 at 02:21:50PM -0700, Stefan Reinauer wrote: > On 6/9/12 6:43 AM, Kevin O'Connor wrote: > >On Fri, Jun 08, 2012 at 08:15:30AM -0700, ron minnich wrote: > >>I wonder if we need another option :-( to configure the rom but not run it? > >Shouldn't coreboot do that when CONFIG_VGA_BRIDGE_SETUP is set, but > >CONFIG_VGA_ROM_RUN is not? > > > >-Kevin > > > CONFIG_VGA_BRIDGE_SETUP routes VGA legacy IO through the (PCI) > bridge with the VGA card attached. It does not influence option rom > handling. Right. Wolfgang is reporting that his VGA card isn't mapped at all if he doesn't select CONFIG_VGA_ROM_RUN (it doesn't show up as a PCI device at all). It should get mapped even if CONFIG_VGA_ROM_RUN isn't set. -Kevin -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [SeaBIOS] freedos images
by Kevin O'Connor 12 Jun '12

12 Jun '12

On Mon, Jun 11, 2012 at 02:59:30PM -0700, ron minnich wrote: > I'm trying to find a freedos usb image I can boot on seabios. > > I am trying these: http://derek.chezmarcotte.ca/?p=188 but I am > finding the usb keyboard performance is really terrible, for some > reason. Anyone have pointers to something that works really well? If I recall correctly, what I did was create a 20Meg harddisk image with qemu-img, then install freedos onto the harddrive image, and then dd the image to the USB stick. -Kevin

1 0

freedos images
by ron minnich 11 Jun '12

11 Jun '12

I'm trying to find a freedos usb image I can boot on seabios. I am trying these: http://derek.chezmarcotte.ca/?p=188 but I am finding the usb keyboard performance is really terrible, for some reason. Anyone have pointers to something that works really well? thanks ron

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS June 2012