FreeBSD has tier-1 support for the AMD64 platform. Unfortunately, the mobile scene is a bit different. The available options are nice, powerful machines, and sohuld be a perfect environment for FreeBSD.
Note that some of this information may be out of date. Please email me with any updates.
Last update: 04 May 2008
Author: Coleman Kane
As an upgrade from the Gateway notebook below, I recently got an HP Compaq 6715b. After reviewing a large amount of available laptops, I came across it as a good potential for FreeBSD compatibility. The system configuration is:
I recently purchased a Gateway 7422GX laptop from Best Buy. Since Gateway recently purchased eMachines, they also released a eMachines laptop which is identical, save the markings. I believe the M6811 is the same as the 7422GX. They even have the same case. The important system characteristics are as follows:
This laptop was actually quite easy to set up with FreeBSD. It has a nice feel, and I would recommend it to anybody looking for an Athlon64 laptop to run FreeBSD on.
Click here to read my experience.
My professor, John Franco also purchased (much earlier) a Compaq R3000. This system was exceptionally mean and is still an ongoing saga of attempting to thwart the manufacturer's design. The specs are here:
Click here to read my experience.
FreeBSD 7.0-RELEASE won't currently work out-of-the-box on this laptop (and probably other, similar ones). This is due to a PCI resource overlap that is programmed into the BIOS by the manufacturer. You'll have to use my patched kernel in order to get FreeBSD on this system. I haven't had the write-combining stability issues of previous notebooks with this one, it seems pretty solid. Once you get the system installed (and modify loader.conf appropriately), you will have four key components that will not work unless you take special measures:
Have have made install CD images for RELENG_7 that include the patch. You'll have to analyze your dmesg, then break into loader (option 6 on the boot menu) to set the hw.pci.hp6715b_membase_for_hda_audio kernel variable.
The images are available here:
I didn't do a DOCS or PORTS build, so you'll only really need disc1 for the install.
To get the on-board graphics working, you must download the experimental radeonhd driver from The freedesktop.org repository. You will notice that there is an x11-drivers/xf86-video-radeonhd in ports, but it is not current enough to support the card in this notebook. First, you should build/install all of x11/xorg. Then you should download, build, and install the latest radeonhd driver (make sure you also have devel/git installed):
root# cd ~ root# git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd .... git does its thing .... root# cd xf86-video-radeonhd root# ./configure .... driver is configured for your X.org .... root# make && make install
You will then want to make sure that you set the driver to radeonhd in your /etc/X11/xorg.conf file before you start your X server. I have tried the avivo and the ati drivers that are also available, and neither of them work. Only the radeonhd driver seems to work with this card.
I also had trouble getting X to properly display on my panel, resulting in a large amount of snow and distortion. I fiddled around with numerous settings, and eventually came this xorg.conf that works well for me. You may want to download it and use it as a starting point.
Note that I can only get X.org to work at the natural resolution of the display panel, which is either 1280×800 or 1680×1050 depending upon the purchase option you chose. None of the other modes will be accepted by X.
I chose the draft-n wifi adapter choice, as a newer piece of hardware that will hopefully have widespread 802.11n support when the standard is ratified. This card, like most other Broadcom wireless adapters, has no open source support in FreeBSD yet. To combat this, we can use the ndis wrapper to create a driver that interfaces with the Windows NDIS .sys driver available for Windows NT4, 2000, XP, and Vista. I went through numerous drivers until I found one from Dell's website that didn't case the kernel to panic. The files are here: bcm4328-driver.tar.gz (includes bcmwl5-utf8.inf and bcmwl564.sys). To create this driver, perform the following steps:
bash# tar xjf bcm4328-driver.tar.gz bash# cd bcm4328-driver bash# ndisgen bcmwl5-utf8.inf bcmwl564.sys ... follow on-screen instructions, which pretty much consisted of hitting ENTER repeatedly ... bash# cp bcmwl564_sys.ko /boot/modules
Next, you should add the following line to /boot/loader.conf:
bcmwl564_sys_load="YES"
To test if it is working, you can run kldload /boot/modules/bcmwl564_sys.ko to load the driver right now and use the ndis0 interface.
The driver should now load when you boot your system, and the interface will automatically be detected.
One caveat that I have with this driver is I cannot view a list of nearby access points. I receive a number of bssid_list failed! messages during operation. However, if the access point(s) are already configured in /etc/wpa_supplicant.conf, then I can reliably use them. The scan command for ifconfig ndis0 fails to work properly, however I was able to use the scan_results command and the scan command within the wpa_cli utility with some success to get local access points, with the latest driver I got from Dell.
The above problem (bssid_list failed) is now solved in 8.0-CURRENT: src/sys/dev/if_ndis/if_ndis.c rev 1.129. All BSSID scan functions of the card work. You just have to deal with the occasional pollution of the system log with seemingly harmless fpudna in kernel mode errors.
FIXED: However, the hack is for experts only (or people who are willing to put up with my high-latency responsiveness)
This is being discussed in a related PR here: kerm/111767
Basically, the problem is that a portion of this device's memory range is stolen by the SATA controller at initialization of atapci0. In order to work around this, though, you need to be able to tell BIOS to remap these two devices to non-conflicting memory ranges. Unfortunately, the BIOS is rather limited in what it allows you to tweak. In order to solve this problem (and also free up the SATA controller for operation, further discussed below), I had to write a hack that consists of providing a loader.conf tunable that will be filled with the 32-bit base address to re-map the audio controller's I/O memory at.
The patch (to 8.0-CURRENT) is here: pci.c-hp6715b.diff
--- sys/dev/pci/pci.c.orig 2007-12-08 23:57:21.000000000 -0500 +++ sys/dev/pci/pci.c 2007-12-09 22:34:05.000000000 -0500 @@ -2235,6 +2235,9 @@ & PCIM_CMD_MEMEN) != 0; } +static unsigned int hp6715b_membase_for_hd_audio = 0; +TUNABLE_INT("hw.pci.hp6715b_membase_for_hd_audio", &hp6715b_membase_for_hd_audio); + /* * Add a resource based on a pci map register. Return 1 if the map * register is a 32bit map register or 2 if it is a 64bit register. @@ -2267,6 +2270,12 @@ ln2size = pci_mapsize(testval); ln2range = pci_maprange(testval); base = pci_mapbase(map); + if((pci_get_devid(dev) == 0x43831002) && (hp6715b_membase_for_hd_audio != 0)) { + device_printf(dev, "Applying PCI membase fixup for HDA Audio on an HP 6715b notebook to: %08x\n", + hp6715b_membase_for_hd_audio); + base = (pci_addr_t)hp6715b_membase_for_hd_audio; + pci_write_config(dev, 0x10, base | 4, 4); + } barlen = ln2range == 64 ? 2 : 1; /*
Once applied, you will now have to find a new base address to map the HDA controller at. This will be specified in /boot/loader.conf as the tunable hw.pci.hp6715b_membase_for_hd_audio, such as (in my case):
hw.pci.hp6715b_membase_for_hd_audio="0xd0614000"
If you are looking for available memory ranges, the devinfo tool can be very helpful. If you run devinfo -uv, you will get a listing of the resource allocations set up for your system. In my case, the memory ranges looked roughly like so:
I/O memory addresses:
0x0-0x9fbff (ram0)
0x9fc00-0x9ffff (root0)
0xa0000-0xbffff (vga0)
0xc0000-0xcd3ff (root0)
0xcd400-0xcffff (acpi0)
0xd0000-0xd0fff (orm0)
0xd1000-0xd29ff (root0)
0xd2a00-0xd2fff (acpi0)
0xd3000-0xdffff (root0)
0xe0000-0xfffff (acpi0)
0x100000-0x77faffff (ram0)
0x77fb0000-0xbfffffff (root0)
0xc0000000-0xc7ffffff (vgapci0)
0xc8000000-0xc80fffff (ndis0)
0xc8100000-0xc8103fff (ndis0)
0xc8104000-0xcfffffff (root0)
0xd0000000-0xd000ffff (bge0)
0xd0010000-0xd00fffff (root0)
0xd0100000-0xd0100fff (cbb0)
0xd0101000-0xd01017ff ----
0xd0101800-0xd03fffff (root0)
0xd0400000-0xd040ffff (vgapci0)
0xd0410000-0xd04fffff (root0)
0xd0500000-0xd05fffff (vgapci0)
0xd0600000-0xd0600fff (root0)
0xd0601000-0xd0601fff (ohci0)
0xd0602000-0xd0602fff (ohci1)
0xd0603000-0xd0603fff (ohci2)
0xd0604000-0xd0604fff (ohci3)
0xd0605000-0xd0605fff (ohci4)
0xd0606000-0xd06060ff (ehci0)
0xd0606100-0xd0608fff (root0)
0xd0609000-0xd06093ff (atapci0)
0xd0609400-0xfebfffff (root0)
0xfec00000-0xfec0001f (apic0)
0xfec00020-0xfedfffff (root0)
0xfee00000-0xfee003ff (apic0)
The ranges marked as root0 are considered ”available for allocation”, so I picked the address 0xd0614000 as the new base for my HDA sound card (moving it from the present base @ 0xd0608000). Not just any address will work, your address must be aligned on a boundary that matches the size of the memory range for I/O. In this case, I couldn't map this to address 0xd0616000. This is because the memory range is 16kB-wide (0×4000), forcing the memory I/O base to only accept addresses that satisfy: ”base mod 0×4000 == 0”. This basically means that any addresses matching the following patterns should be fine (where NNNN is any number):
When you have selected a memory base, you can test out that it is a valid choice using the pciconf tool. Find the device using pciconf -l | grep 0×43831002:
pcm0@pci0:0:20:2: class=0x040300 card=0x30c2103c chip=0x43831002 rev=0x00 hdr=0x00
The value pci0:0:20:2 is the system-unique selector for my HDA controller. I can now use that selector to read/write PCI configuration variables with pciconf. I would like to try setting this value to 0xd0614004 and seeing what happens (the 4 in the lower byte identifies this as a memory I/O, rather than a port I/O address):
root# pciconf -w pci0:0:20:2 0x10 0xd0614004
Then, check what the PCI controller did to mangle the value:
root# pciconf -w pci0:0:20:2 0x10 d0614004
If the result value above is identical to what you put in, then you should be set (and you can use it in the loader.conf tunable above). Otherwise, the PCI controller would have set this to an adjusted value. If this occurred, verify that the adjusted value (and the following range) don't overlap with any other memory ranges, and then use the adjusted value in your loader.conf. You won't be able to simply do this at run-time with pciconf, because when you attempt to kldload snd_hda, the PCI bus will be rescanned. When this occurs, the attached device(s) will be reset to the resource values that were detected at boot time.
UPDATE: The following patches are already in HEAD and RELENG_7. You should only need these if you are still using the old 7.0-RELEASE sources from the original installation. Otherwise, you probably just want the patch in the previous section.
This controller will work with FreeBSD using the Generic ATA controller driver. This will register as either ”Generic IDE controller” or ”ATI ATA controller”. The IXP600 is supposed to have an AHCI-compliant SATA controller in it, however there have been some problems getting it working on this laptop.
This behavior went unnoticed to me until Andy Kosela pointed out that the hard drive would only work in UDMA33 mode. Upon further inspection, I discovered that the ata-chipset.c did not have the proper PCI IDs for the IXP600 serial ATA controller. After adding them, and putting the appropriate bits to enable AHCI, I experienced numerous issues reading and writing the MMIO register space for AHCI operations. It turns out that on both of our laptops, the mem resources for The OnBoard ATI SB600 HDA Audio Controller and this Serial ATA controller overlap, as below from my dmesg output:
atapci0: <ATI IXP600 SATA300 controller> port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 ... pcm0: <ATI SB600 High Definition Audio Controller> mem 0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0
You'll notice that the serial ATA controller grabbed memory right smack in the middle of the audio controller's memory space. Since the SATA controller got attached first, the audio controller cannot set up its memory space (and fails to attach). The fixes above, to get the Audio Controller working have solved this.
The SATA controller does work with the out-of-the box AHCI code in the kernel. You simply need to:
The following patches will do the trick:
--- sys/dev/ata/ata-pci.h.orig 2007-12-09 14:29:56.000000000 -0500 +++ sys/dev/ata/ata-pci.h 2007-12-08 23:58:29.000000000 -0500 @@ -104,6 +104,7 @@ #define ATA_ATI_IXP400_S1 0x43791002 #define ATA_ATI_IXP400_S2 0x437a1002 #define ATA_ATI_IXP600 0x438c1002 +#define ATA_ATI_IXP600_S1 0x43801002 #define ATA_ATI_IXP700 0x439c1002 #define ATA_CENATEK_ID 0x16ca
File: ata-pci.h-hp6715b.diff
--- sys/dev/ata/ata-chipset.c.orig 2007-12-09 14:29:22.000000000 -0500 +++ sys/dev/ata/ata-chipset.c 2007-12-09 14:05:08.000000000 -0500 @@ -1346,6 +1346,7 @@ { ATA_ATI_IXP400_S1, 0x00, SIIMEMIO, 0, ATA_SA150, "IXP400" }, { ATA_ATI_IXP400_S2, 0x00, SIIMEMIO, 0, ATA_SA150, "IXP400" }, { ATA_ATI_IXP600, 0x00, 0, 0, ATA_UDMA6, "IXP600" }, + { ATA_ATI_IXP600_S1, 0x00, 0, AHCI, ATA_SA300, "IXP600" }, { ATA_ATI_IXP700, 0x00, 0, 0, ATA_UDMA6, "IXP700" }, { 0, 0, 0, 0, 0, 0}}; @@ -1370,6 +1371,15 @@ if (ata_setup_interrupt(dev)) return ENXIO; + if (ctlr->chip->cfg2 & AHCI) { + ctlr->r_rid2 = PCIR_BAR(5); + ctlr->r_type2 = SYS_RES_MEMORY; + if ((ctlr->r_res2 = bus_alloc_resource_any(dev, ctlr->r_type2, + &ctlr->r_rid2, + RF_ACTIVE))) + return ata_ahci_chipinit(dev); + } + /* IXP600 & IXP700 only have 1 PATA channel */ if ((ctlr->chip->chipid == ATA_ATI_IXP600) || (ctlr->chip->chipid == ATA_ATI_IXP700))
File: ata-chipset.c-hp6715b.diff
These patches will enable the controller to be identified and operate as an AHCI-compliant SATA300 (SATA-II) controller, with one port. Note that some of the drives shipped with this notebook only support SATA150. If so, your drive will register that it is SATA150, this is not a bug. If you are absolutely sure that your hard drive is supposed to support SATA300, then send the dmesg and the model name/number over to me and we can discuss it.
This laptop installation was rather succesful the first time. I read the AMD64 laptop horror stories on the mailing lists and decided to bring along a copy of FreeBSD 5.3-RELEASE to test-boot in the systems. I found this one at CompUSA and (for less money) at Best Buy.
The first thing to note is that this laptop has a Broadcom BCM4306 wireless card. In order to use it under anything besides Windows, you will need the NDIS wrapper which basically runs the windows (NDIS) driver under Linux or FreeBSD. Personally, I think these cards are crap, in addition to the Centrino's Intel PRO Wireless cards. If you bought it for the Wi-Fi card, you're out of luck. Go get a good Atheros or Prism based NIC. I recommend the SMC EliteConnect SMC2536W-AG that supports 802.11a/b/g as well as WPA and WME. They are pretty inexpensive and have a 150mW amplifier on them which gives excellent range and reliability. This will use the ath(4) driver. You'll need the ath_hal(4) module as well.
The PRISM-based cards as well as the Agere/Orinoco/Lucent cards should work as well. These two types will work under 5.3-RELEASE with the wi(4) driver.
However, if you really want the Broadcom wifi NIC to work under FreeBSD, you don't want to use the drivers available from Gateway's website. I spent a fair amount of time scouring the web searching for a good, working Win64 driver. Eventually I found one, and I have packaged its .sys and .inf (converted to UTF-8) files into an archive here: bcm4306-driver.tar.bz2. You will need to use ndisgen(8) to build the driver for your particular FreeBSD version. If you have a recent version of FreeBSD, this is as easy as:
tar xjf bcm4306-driver.tar.bz2 cd bcm4306-driver ndisgen netbc564-utf8.inf BCMWL564.SYS ... follow the prompts (just hit ENTER a bunch) ...
You'll end up with a file named BCMWL564_SYS.ko. You'll want to install this into /boot/modules and configure it to be loaded in loader.conf.
NOTE: This may not necessarily apply to your particular hardware. It seems that some hard disk drives support the Write-Combining feature, while others don't, and even others silently don't support it. The latter case is where you'll need to make this adjustment. If you are one of the unlucky few, then you'll know it rather quickly when a seemingly good hard drive starts having all kinds of read/write errors.
I don't know about anybody else, but upon getting FreeBSD installed on this laptop, it began to exhibit stability issues wrt the hard drive controller. I had to turn of write caching for the ata(4) controller with:
sysctl hw.ata.wc=0
Just place that in your /boot/loader.conf and it should be alright. This is a pretty common thing for me across the board with various ATA controllers. If it is corrupting your drive, try turning this off. If not, good for you. WC is a feature that is supported by some drives to improve performance.
This is not really a problem. Some directions tell you to disable ACPI by default on the Athlon64 platforms. You can safely enable it on these models. You can even remove the atpic device from the kernel build.
The latest FreeBSD kernels support the Power Management features of these CPUs now.
This Radeon card works very well with one exception. It does not support DRI in xorg, however (none of the 9500 and up are supported). Apparently the Radeon 9550 is like a slower clocked 9600. The previous versions of this laptop had the 9600 apparently. Frankly, I didn't mind since I don't typically use the GL fatures of the card. I'll gladly take the performance hit for some extra battery life.
ATI does provide a linux amd64 driver. Perhaps with a little prodding here. We can get them to compile a FreeBSD one. Remember, NVidia provides freebsd drivers.
This laptop also has a card reader built into it. Apparently this has support for four different card formats. I was able to test it with a couple CF (CompactFlash) cards and some Sony MemoryStick cards. This is probably one of the most handy surprise features of the laptop. It is just wired to the internal USB.
The DVD-RW drive works very well for burning CD-R's. I can burn at 24X without making any coasters. Haven't tested the DVD+/-RW (yes, both) capability yet.
Has a VIA Rhine onboard ethernet controller. Simple, generic, seems to work quite well. I don't use it anymore since I got the ath(4) card working. The ath(4) changes have since been moved into -CURRENT.
There is a whole series of Compaq and HP laptops which are nearly identical minus the external casing. I would recommend not touching any of them with a 20-foot pole. These laptops are bad news and are going to be hell to get working. You'll have to maintain a number of patches to RELENG_5 or -CURRENT. My professor has one, and can't return it, so we've been working on getting it running under FreeBSD 5-STABLE.
The first problem that happens with this laptop is that the system will freeze on boot. Most users won't be able to boot the install CD in order to use it.
The kicker is this: the fix is in -STABLE, however you want to get FreeBSD on the laptop first, so that you may download the latest RELENG_5 stable branch. Never fear, Kelly Black is here! Kelly has built a mininst CD from the stable tree which will boot these laptops far enough to get FreeBSD installed on them. You can get that here:
Just burn this image to a CD and boot it. When you get to the loader, be sure that you boot with ACPI disabled. Either select that number from the boot menu, or go to the loader console and type:
set hint.acpi.0.disabled="1"
Now you may boot the laptop and run the install tool. Install the base system from the CD image so that the updated files are installed on your system. Reboot, then install cvsup-without-gui. You should have a /usr/share/examples/cvsup/stable-supfile. If you do not, you can grab that one. Read the instructions therein and upgrade your sources to the latest RELENG_5 branch.
Do not yet rebuild at this point.
I had quite some difficulty getting this system to be stable enough to build world on. I had to turn of write caching and rate the hard drive down to ATA33:
hw.ata.wc=0 needs to be in /boot/loader.conf.
atacontrol mode 0 UDMA33 BIOSPIO
needs to be run to turn down the drive speed. This increased stability significantly, and was the only way I could use the laptop.
Another big problem is that the CardBus controller is unreliable and the PCI devices are as well (might be related to above problem). There seems to be some bugginess to the built in timers (ACPI timers). In addition, for some reason certain pci devices do not seem to be initialized by the ACPI BIOS. There are three patches that must be applied:
device atpic.#if 0 portions that the email refers to.