Kernel & Driver Customisation

Once Linux kernel board bringup is completed, it's time to customise the kernel to meet your exacting requirements.  From optimising the kernel configuration to minimise memory footprint, to full custom device drivers and subsystem integration, PetaLogix Kernel and Driver Customisation services deliver an embedded Linux platform tailored to your needs.

Here is a sample of the kernel and driver related tasks we perform for our clients on a daily basis:

Devices drivers for custom IP cores

The right device driver architecture is often far from obvious.  Whether for custom hardware of your own design, or being delivered through our Custom IP Design and Integration services, PetaLogix have extensive experience developing device driver solutions for a wide variety of unique IP cores.  Once the specification is agreed, we deliver not only the driver, but also userspace libraries and sample applications to get your applications team productive.  "Simulator" device drivers implementing the driver interface can really parallelise development, allowing the application design team to start work while the target IP cores and drivers are in development.

Sourcing and porting device drivers for external devices

There are thousands of device drivers in the Linux kernel and in external repositories.  How can you be sure of success if you are building these devices into your product?  PetaLogix are Linux kernel experts, we can quickly source and evaluate drivers for devices you may be considering in your product, and provide expert advice on alternatives.  Once you've chosen a device, we'll make sure it's compatible with your kernel version, builds seamlessly and performs to specification.  Of course, if you need help interfacing these devices to your system, our Custom IP Design and Integration services will help you achieve it.

Performance analysis and optimisation

Achieving peak performance from Embedded Linux takes skill.  Petalogix's deep understanding of FPGA-based embedded design lets us optimise and tune your system across both hardware and software domains.  Choose from a wide range of industry-standard benchmark suites to gain an in-depth understanding of your system performance, and use our application performance analysis to identify opportunities for migration to custom hardware IP.

Some of the more interesting custom driver architectures we've developed include

• a driver subsystem for a custom image processing pipeline, where compressed image data recovered from network packets were pushed through a custom image decompression and processing pipeline
• drivers for intelligent peripherals that filter multi-gigabit per second data streams and extract events of interest, which are then passed to a device driver as an event stream
• interfaces to dynamic self-reconfiguration capabilities of Xilinx FPGAs, allowing the processor to reconfigure itself on the fly.
  

Not all systems require exotic solutions - and some of the more standard devices and subsystems we've worked with include

• USB host and device controllers
• PCI and PCI Express subsystem drivers
• 802.11 Wireless Chipsets (WiFi)
  
• Ethernet drivers
  
• Graphical framebuffers
• Embedded buses such as I2C, SPI

Device drivers for custom hardware

For newcomers to Embedded Linux on programmable FPGAs, particularly those with experience in legacy RTOS kernels that lack formal driver and kernel/application separation models, it can be tempting to want to control their custom hardware devices directly from user space (application code).  It's easy to understand the appeal - it can appear easier (at first) to do so, and sometimes what begins as a quick prototype to verfiy device functionality morphs into a large, unreliable and unmaintainable codebase.

There are several advantages to embracing the Linux device driver model, even for highly customised hardware devices:

• Interrupt Handling - there are no reliable ways to handle device interrupts purely from userspace (although see the comments about the UIO framework below)
• Portability - quick hacks for direct hardware access that may work on one Linux kernel architecture, may not be portable to other CPU or system architectures, or even among variants of the same CPU architecture
• Maintainability - keeping a clean separation between driver and application code helps developers - particularly those new to a project - to navigate the code base, and keep hardware-access related code distinct from the application code that calls it

• Access control - managing devices in userspace makes it very difficult to control concurrent access to the device by more than one process - a problem trivially solved by a device driver

There is a middle ground - the UserSpace IO (UIO) framework allows drivers to be implemented almost entirely in userspace, with just a very small in-kernel driver that performs essential interrupt request and acknowledgement functions, and basic device initialisation.

PetaLogix has used the UIO framework successfully for a number of custom drivers, typically writing userspace libraries to handle low level device details.  Careful design is still required to ensure that the pitfalls listed above can be avoided.