I was browsing the support for ExpressCard in Linux. I couldn't find any explicit support for it at all, not matter where I looked. I found usb support and pci express support, as well as hot plug versions of the latter. This puzzled me a bit, since I'd read that Linux supported ExpressCard cards. Maybe no special software support is required at all...
So, I thought I'd get a couple of ExpressCards and take them for a test spin. It turns out that FreeBSD versions back to 4.x that can boot on modern machines with ExpressCard slots will support one important class of cards (assuming the drivers are in the version of FreeBSD that you try).
The ExpressCard standard specifies two types of cards, from an electrical point of view (not to be confused with the two width form-factors offered: 34mm and 54mm). The first kind is card that contains a USB 2.0 device in it. In this configuration, the host bridge connects it up to power and a standard usb hub. The second kind of card is a single channel PCI Express card, used for applications where greater bandwidth is required between the CPU and the hardware on the card.
The USB versions just work. I plugged in a Delkin Devices eFilm ExpressCard that I was recently able to purchase due to the generosity of a someone who sent me money to buy toys with. This device supports SD, SDHC, MMC, MS, MSpro and xD cards. Since I also wanted to enhance the SD/MMC stack to support SDHC cards, I thought this would be a good choice (since the price was right) for me to test things out on.
The PCIe versions will need PCIe hot-plug support added to pcib (or a subclass). I've had trouble finding cards that are PCIe for sure, so if you know of one, please let me know. I'm guessing that the eSATA cards are a good choice for that, but confirmation would be great.
So the good news is: FreeBSD has supported at least some of the ExpressCard cards since before the ExpressCard standard was published.
20070305
20070303
Followup Atmel AT91 family work
After receiving an evaluation board from Atmel with an AT91SAM9260 onboard, I've started updating the Atmel support for FreeBSD in the p4 repository.
This chip is basically the same as the AT91RM9200, but with a few twists. First, it uses a ARM926EJS core rather than a ARM910T core. This means that it has an arm9e core in it (half way between an arm9 and an arm10 core). Fortunately, the NetBSD support for these CPUs was easy to port, and has been nearly a drop in (I'm sure I botched something it went so smoothly).
Next, there are three classes of devices on the AT91SAM926x parts that need addressing. The first class of parts are those that have FreeBSD drivers that utilize the AT91RM9200 errata to produce proper function. Many of these bugs in silicon have been fixed, so the kernel needs to cope in some manner. The MCI device is the most prominent here, as it needed to have byte swapping done in and outbound to be interoperable with other systems. There were structural changes that severely affected performance that will need to be ifdef'd for the old part. There are a number of other minor tweaks that may be necessary.
Next, we have those devices that were present in the RM9200, but have been augmented for the SAM9 series. These include enhanced support for SDIO cards in the MCI device, as well as a number of minor additions to the TWI, SPI and USART devices (or so my first reading would suggest... some are so minor that they could just be clearer documentation).
Finally, we have those devices that aren't present at all on the RM9200, but are in the SAM9 devices. There's an LCD controller and a cool image processing whatsit that fall into this category. The EMAC from the RM9200 has been removed, replaced by a newer 10/100 part that has more buffers for transmit, so the bottlenecks seen on the RM9200's network performance can be corrected. This will take a little time, but since the SD card boot should just work, or nearly should, the pressure to have this falls from 'critical' down to 'necessary for basic support.'
The eval board I received also has some neat audio hardware attached to the SSC bus (think McASP-like bus, if you are familiar with TI's DSPs). Back of the envelope calculations suggest that I could use this device as my 'audio server'. It is small enough to slip into the rack of audio/video gear I have upstairs and fast enough to play skipless audio. This is a ways off, but time will tell.
The devices are located at different addresses than the RM9200. Initially, I'll augment the hint structure we have to cope. It should be nearly complete as it is. Eventually, however, it might be nice to have 'super kernels' that can run on any member of the Atmel family of processors that FreeBSD supports. To do that, hints will need to have some way of selecting which subset to use.
The boot loader that I carefully optimized for the RM9200 is likely too big for the SAM9. There's 16kB of SRAM on the RM9200, 12kB of which is useful for the first stage of a loader. The SAM9 has only 4kB, but a much augmented boot ROM code that may be able to help. The bootspi boot loader is about 9k with all the bells and whistles, and could be chopped to about 5k w/o much effort. I'm unsure if I should do anything here, or just have the redboot that's on the board load the kernel (or a special boot2 that runs in SDRAM rather than SRAM).
I'm sure I'm missing some other issues that will come up during the port. But so far it has been an uneventful few hours. Time, alas, conspires against me. I find I have only a few hours here or there to work on it. Although I've been working on it for weeks, I have only put 3 hours of actual grunt time into the port...
This chip is basically the same as the AT91RM9200, but with a few twists. First, it uses a ARM926EJS core rather than a ARM910T core. This means that it has an arm9e core in it (half way between an arm9 and an arm10 core). Fortunately, the NetBSD support for these CPUs was easy to port, and has been nearly a drop in (I'm sure I botched something it went so smoothly).
Next, there are three classes of devices on the AT91SAM926x parts that need addressing. The first class of parts are those that have FreeBSD drivers that utilize the AT91RM9200 errata to produce proper function. Many of these bugs in silicon have been fixed, so the kernel needs to cope in some manner. The MCI device is the most prominent here, as it needed to have byte swapping done in and outbound to be interoperable with other systems. There were structural changes that severely affected performance that will need to be ifdef'd for the old part. There are a number of other minor tweaks that may be necessary.
Next, we have those devices that were present in the RM9200, but have been augmented for the SAM9 series. These include enhanced support for SDIO cards in the MCI device, as well as a number of minor additions to the TWI, SPI and USART devices (or so my first reading would suggest... some are so minor that they could just be clearer documentation).
Finally, we have those devices that aren't present at all on the RM9200, but are in the SAM9 devices. There's an LCD controller and a cool image processing whatsit that fall into this category. The EMAC from the RM9200 has been removed, replaced by a newer 10/100 part that has more buffers for transmit, so the bottlenecks seen on the RM9200's network performance can be corrected. This will take a little time, but since the SD card boot should just work, or nearly should, the pressure to have this falls from 'critical' down to 'necessary for basic support.'
The eval board I received also has some neat audio hardware attached to the SSC bus (think McASP-like bus, if you are familiar with TI's DSPs). Back of the envelope calculations suggest that I could use this device as my 'audio server'. It is small enough to slip into the rack of audio/video gear I have upstairs and fast enough to play skipless audio. This is a ways off, but time will tell.
The devices are located at different addresses than the RM9200. Initially, I'll augment the hint structure we have to cope. It should be nearly complete as it is. Eventually, however, it might be nice to have 'super kernels' that can run on any member of the Atmel family of processors that FreeBSD supports. To do that, hints will need to have some way of selecting which subset to use.
The boot loader that I carefully optimized for the RM9200 is likely too big for the SAM9. There's 16kB of SRAM on the RM9200, 12kB of which is useful for the first stage of a loader. The SAM9 has only 4kB, but a much augmented boot ROM code that may be able to help. The bootspi boot loader is about 9k with all the bells and whistles, and could be chopped to about 5k w/o much effort. I'm unsure if I should do anything here, or just have the redboot that's on the board load the kernel (or a special boot2 that runs in SDRAM rather than SRAM).
I'm sure I'm missing some other issues that will come up during the port. But so far it has been an uneventful few hours. Time, alas, conspires against me. I find I have only a few hours here or there to work on it. Although I've been working on it for weeks, I have only put 3 hours of actual grunt time into the port...
Subscribe to:
Posts (Atom)