OpenBSD Journal

Developer blog: dlg: bio(4) on something other than amd64 and i386

Contributed by dlg on from the dept.

One of the really annoying things about hardware raid controllers is that the management tools supplied by the vendor are binary only, and they're generally only for specific set operating systems and architectures. Unfortunately that can limit you (the actual customer) from using your shiny new card in whatever box you want to use.

Lucky for you, OpenBSD is full of idealists who believe that if the card fits in the slot, it should work in that slot. Most vendors only provide binary only tools for i386 or amd64 machines, and generally only on a handful of operating systems. This obviously implies that your shiny card isn't necessarily going to work everywhere.

Having the tools only for certain operating systems isn't such a huge problem, since the linux and freebsd emulation layers in OpenBSD mean that we just have to emulate some ioctls as well and some of those tools should Just Work(tm). However, there would need to be effort in each particular raid driver to support the ioctls specific to each vendors management tool. But as we've said before, we believe that this approach is damaging in the long run, so we haven't (and wont) put the effort into making that work. Ideally we would be able to support a single management tool with the same set of ioctls in each driver.

If the driver supporting a controller is written well enough, then there isn't any real reason why the hardware wont work in something "strange" like a macppc or sparc64 box. Or any box really, as long as you can plug it in. However, making an i386 or x86_64 binary run on another architecture such as macppc or sparc64 is much harder to do, and again, it's something we shouldn't have to deal with. If we have source code we can simply compile (and perhaps fix) the code for the new architecture.

So we have two issues here: one, we want a single management tool for all RAID controllers, and two, we want this same tool to work on all our supported architectures. Of course, OpenBSD has an answer to both of these, and it's called bio(4), and bioctl(8). However, until yesterday, only the first of these issues was proven in real life to be addressed by bioctl.

If you have a look at the bio(4) manpage you'll see a list of 4 controllers which are managable using bioctl(4). So obviously OpenBSD has successfully shown that a single tool can be used to manage several RAID controllers, much like ifconfig(8) is used to manage the dozens of network interfaces available in OpenBSD. Unfortunately noone has really tried to get those controllers working on something other than i386 or amd64.

Yesterday though, I enabled bio(4) on macppc, and tested arc(4) on it. Here's the dmesg:

[ using 362056 bytes of bsd ELF symbol table ]
console out [ATY,Rage128Ps]console in [keyboard] USB found
: memaddr 94000000 size 4000000, : consaddr 94008000, : ioaddr 90020000, size 20000: memtag 8000, iotag 8000: width 640 linebytes 768 height 480 depth 8
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org

OpenBSD 4.0-current (GENERIC) #5: Wed Feb 7 09:08:27 EST 2007
    loki@tmp.home.animata.net:/usr/src/sys/arch/macppc/compile/GENERIC
real mem = 1073741824 (1048576K)
avail mem = 976834560 (953940K)
using 1254 buffers containing 53686272 bytes (52428K) of memory
mainbus0 (root): model PowerMac3,1
cpu0 at mainbus0: 7400 (Revision 0x208): 400 MHz: 1MB backside cache
memc0 at mainbus0: uni-n
ki2c0 at memc0 offset 0xf8001000
iic0 at ki2c0
mpcpcibr0 at mainbus0 pci: uni-north, Revision 0xff
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 "Apple Uni-N AGP" rev 0x00
vgafb0 at pci0 dev 16 function 0 "ATI Rage Fury" rev 0x00, mmio
wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
mpcpcibr1 at mainbus0 pci: uni-north, Revision 0xff
pci1 at mpcpcibr1 bus 0
pchb1 at pci1 dev 11 function 0 "Apple Uni-N" rev 0x00
ppb0 at pci1 dev 13 function 0 "DEC 21154 PCI-PCI" rev 0x05
pci2 at ppb0 bus 1
ppb1 at pci2 dev 3 function 0 "Intel IOP331 PCIX-PCIX" rev 0x0a
pci3 at ppb1 bus 2
arc0 at pci3 dev 14 function 0 "Areca ARC-1110" rev 0x00: irq 53
arc0: 4 SATA Ports, 128MB SDRAM, FW Version: V1.41 2006-5-24
scsibus0 at arc0: 16 targets
sd0 at scsibus0 targ 0 lun 0: <Areca, ARC-1110-VOL#00, R001> SCSI3 0/direct fixed
sd0: 305245MB, 54265 cyl, 24 head, 480 sec, 512 bytes/sec, 625141760 sec total
macobio0 at pci2 dev 7 function 0 "Apple Keylargo" rev 0x02
openpic0 at macobio0 offset 0x40000: version 0x4614
macgpio0 at macobio0 offset 0x50
macgpio1 at macgpio0 irq 47
"programmer-switch" at macgpio0 not configured
"escc-legacy" at macobio0 offset 0x12000 not configured
zsc0 at macobio0 offset 0x13000: irq 22,50
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
awacs0 at macobio0 offset 0x14000: irq 24,9,10 headphones
audio0 at awacs0
"timer" at macobio0 offset 0x15000 not configured
adb0 at macobio0 offset 0x16000 irq 25: via-pmu, 0 targets
apm0 at adb0: battery flags 0x9, 0% charged
ki2c1 at macobio0 offset 0x18000
iic1 at ki2c1
wdc0 at macobio0 offset 0x1f000 irq 19: DMA
wd0 at wdc0 channel 0 drive 0: <WDC WD102AA>
wd0: 16-sector PIO, LBA, 9787MB, 20044080 sectors
wd1 at wdc0 channel 0 drive 1: <Maxtor 51024U2>
wd1: 16-sector PIO, LBA, 9770MB, 20010816 sectors
wd0(wdc0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4
wd1(wdc0:0:1): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4
wdc1 at macobio0 offset 0x20000 irq 20: DMA
atapiscsi0 at wdc1 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <MATSHITA, DVD-ROM SR-8585, 1A28> SCSI0 5/cdrom removable
cd0(wdc1:0:0): using BIOS timings, DMA mode 2
wdc2 at macobio0 offset 0x21000 irq 21: DMA
ohci0 at pci2 dev 8 function 0 "Apple USB" rev 0x00: irq 27, version 1.0
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Apple OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ohci1 at pci2 dev 9 function 0 "Apple USB" rev 0x00: irq 28, version 1.0
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: Apple OHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
"TI TSB12LV23 FireWire" rev 0x00 at pci2 dev 10 function 0 not configured
mpcpcibr2 at mainbus0 pci: uni-north, Revision 0x16
pci4 at mpcpcibr2 bus 0
pchb2 at pci4 dev 11 function 0 "Apple Uni-N Eth" rev 0x00
gem0 at pci4 dev 15 function 0 "Apple Uni-N GMAC" rev 0x01: irq 41, address 00:30:65:57:bb:fc
bmtphy0 at gem0 phy 0: BCM5201 10/100 PHY, rev. 2
uhub2 at uhub1 port 1
uhub2: Mitsumi Electric Hub in Apple USB Keyboard, rev 1.10/2.11, addr 2
uhub2: 3 ports with 2 removable, bus powered
ural0 at uhub0 port 1
ural0: Cisco-Linksys Wireless-G USB Network Adapter, rev 2.00/0.04, addr 2
ural0: MAC/BBP RT2571 (rev 0x03), RF RT2526, address 00:0f:66:e7:c2:57
uhidev0 at uhub2 port 1 configuration 1 interface 0
uhidev0: Mitsumi Electric Apple USB Keyboard, rev 1.00/1.03, addr 3, iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
bootpath: '/pci@f2000000/@d/mac-io@7/ata-4@1f000/disk@0/bsd'
boot device: wd0.
root on wd0a
rootdev=0x0 rrootdev=0xb00 rawdev=0xb02

And here's bioctl working on something other than an i386 or amd64:

# bioctl arc0
Volume  Status               Size Device  
 arc0 0 Online       320072581120 sd0     RAID1
      0 Online       320072933376 0:0.0   noencl <ST3320620AS 3.AAD>
      1 Online       320072933376 0:1.0   noencl <ST3320620AS 3.AAD>
# sysctl hw.sensors.arc0
hw.sensors.arc0.drive0=online (sd0), OK

(Comments are closed)


Comments
  1. By Raymond (194.157.7.200) on

    Would there be anyone here that has information on how to get email alerts from a XFX Revo64 (NetCell based) HW SATA2 RAID-4 card in anything else than Windows? http://www.xfxforce.com/web/product/listConfigurationDetails.jspa?series=Revo64&productConfigurationId=1089

    I've tried to find information on support for this full hw card both for Linux and OpenBSD to no avail. =(

    Comments
    1. By Anonymous Coward (24.37.236.100) on

      > Would there be anyone here that has information on how to get email alerts from a XFX Revo64 (NetCell based) HW SATA2 RAID-4 card in anything else than Windows? http://www.xfxforce.com/web/product/listConfigurationDetails.jspa?series=Revo64&productConfigurationId=1089
      >
      > I've tried to find information on support for this full hw card both for Linux and OpenBSD to no avail. =(
      >
      >
      Maybe donating one?

      Comments
      1. By Raymond (193.185.199.3) on

        > > Would there be anyone here that has information on how to get email alerts from a XFX Revo64 (NetCell based) HW SATA2 RAID-4 card in anything else than Windows? http://www.xfxforce.com/web/product/listConfigurationDetails.jspa?series=Revo64&productConfigurationId=1089
        > >
        > > I've tried to find information on support for this full hw card both for Linux and OpenBSD to no avail. =(
        > >
        > >
        > Maybe donating one?

        If I had two I could think of it, but don't have it =(

  2. By Anonymous Coward (63.144.178.254) on

    how about the raid card's bios, where one creates and alters the raid sets?

    Comments
    1. By Otto Moerbeek (otto) on http://www.drijf.net

      > how about the raid card's bios, where one creates and alters the raid sets?

      bios is quite platform specific, it won't work on macppc, for example.

    2. By Paul 'WEiRD' de Weerd (216.239.55.7) weerd@weirdnet.nl on http://www.weirdnet.nl/openbsd/

      > how about the raid card's bios, where one creates and alters the raid sets?

      Yeah, this is the one thing that still bothers me. The BIOS on these RAID controllers is often i386-only (meaning that they would work on amd64 in i386 mode (such as during boot where you'd access the BIOS)).

      I assume it's technically possible to configure a RAID set from the OS (I've seen tools for Adaptec RAID controllers under Windows, surely other vendors provide similar tooling). Is this something the OpenBSD developers are interested in supporting somewhere in the future ?

      Comments
      1. By Anonymous Coward (87.79.237.121) on

        > > how about the raid card's bios, where one creates and alters the raid sets?
        >
        > Yeah, this is the one thing that still bothers me. The BIOS on these RAID controllers is often i386-only (meaning that they would work on amd64 in i386 mode (such as during boot where you'd access the BIOS)).

        As far as I heard, OpenBSD developers are currently trying to
        make the VESA BIOS in the VM86 emulation work, in order to have
        a VESA framebuffer and be able to run X11 with wsfb driver,
        instead of vesa or gfx card specific driver.

        This could be extended to the RAID controller BIOSes, in a
        first stage making them work under VM86 mode on the i386
        platform (probably not amd64 though), in a second step
        using something like Xen, VirtualBox, etc. to provide
        i386 real mode emulation for other platforms, where the
        necessary parts of qemu shouldn't be part of the kernel tho.

        Comments
        1. By Marco Peereboom (143.166.255.41) on

          Jordan and I looked at that before to make ami work on sparc64 but it is quite a bit more tricky than just that. We might look at it again in the future though.

        2. By Gordon Willem Klok (gwk) on

          > > > how about the raid card's bios, where one creates and alters the raid sets?
          > >
          > > Yeah, this is the one thing that still bothers me. The BIOS on these RAID controllers is often i386-only (meaning that they would work on amd64 in i386 mode (such as during boot where you'd access the BIOS)).
          >
          > As far as I heard, OpenBSD developers are currently trying to
          > make the VESA BIOS in the VM86 emulation work, in order to have
          > a VESA framebuffer and be able to run X11 with wsfb driver,
          > instead of vesa or gfx card specific driver.
          >
          > This could be extended to the RAID controller BIOSes, in a
          > first stage making them work under VM86 mode on the i386
          > platform (probably not amd64 though), in a second step
          > using something like Xen, VirtualBox, etc. to provide
          > i386 real mode emulation for other platforms, where the
          > necessary parts of qemu shouldn't be part of the kernel tho.

          Yes vesabios is being worked on, but this is really specific to i386, in order to use the vesa bios calls were using a specific feature of intel processors from the 386 on words called virtual 8086 mode which basically just provides a way to execute the 16bit 8086 code of the bios designed to run in real mode inside a protected mode task. AFAIK this feature is pretty specific to i386 (its not even present in amd64 processors running in long mode)

          So it wont help with other architectures, you could emulate an 8086 on other architectures (I understand this is how its done in X land) but thats a lot of work for not much benefit since this causes issues with really only 1)raid/scsi controllers (many of whom include f-code or have sparc/mac versions of there cards or 2) video cards that usually have mac versions with fcode (at least ATI did, and I guess some nvidia that shipped in apple machines)

    3. By Marco Peereboom (143.166.255.41) on

      > how about the raid card's bios, where one creates and alters the raid sets?

      I have been toying with creating raid volumes with bioctl. I have had some success with that however it needs more work. To be continued...

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]