ProjectKernelPorting
From The Neuros Technology Wiki
Contents |
[edit] Idea and Motivation
This project started while trying to use the video decoder device (i.e tvp5150 ADC) for a custom application, looking on the current kernel source, implementation and user application interface i decide to rewrite it, then i realized that the same arguments applied to several other places on the kernel. So i end coding my own kernel implementation for the DM320 platform and specially for the Neuros OSD device.
This project has two main goals:
- Develop open source drivers where possible.
- Rewrite current drivers that don't follow Linux APIs.
[edit] Development
The current Linux Kernel version is 2.6.19.7, there are plans to use the last but that would require several changes.
[edit] Devices
| Device | Status |
|---|---|
| Ethernet | Working |
| Uart | Working |
| I2C | Working |
| OSD | Working |
| VOUT | Not Working |
[edit] DM9000a Network Device
The driver for the network device is the one that is already included on the vanilla kernel source (i.e dm9000).
[edit] UART ports
[edit] OSD
The OSD device uses the linux Framebuffer API, the current implementation supports all four planes, two video planes (yuv 4:2:2) and two graphics/bitmap planes (16,8,4,2,1 bpp). You can use the standard Linux Framebuffer ioctls to set up things like the depth or the size of each plane and a sysfs interface to move each plane around the screen, enable or disable a specific plane, set blending between a bitmap window and video window, and all kind of cool stuff the DM320 can do.
[edit] Test Cases
Under my personal subversion space, there is a directory called test, currently i only have several demos and test cases for the framebuffer device(s). The network device is tested by mounting the rootfs through NFS, i don't know how to benchmark or compare this driver against the official network driver.
[edit] Porting for 2.6.20 and beyond
The main issue on this version is that if the PHYS_ADDR is not a 2MB boundary the kernel won't compile. This is the case of the Neuros OSD. The start of the DRAM is set with the same value as the end of the FLASH starting from 0x00100000 (1MB). The FLASH size is 16 MB (0x01000000) So the start of the DRAM is at 0x01100000 which is not in a 2MB boundary. How we can solve this? one option is losing 1MB of DRAM (very drastic indeed), but at least it works, no for the kernel parameters of course, as they are placed on address 0x01100100. Another option would be to change the bootloader code and set the FLASH to be of 17 MB, so the DRAM start address will be on a 2MB boundary.
[edit] Source
[edit] Testing the Kernel
In order to compile this kernel you need an arm toolchain (under the neuros-bsp on the official source tree you'll find one), a rootfs for testing and of course the kernel source code. The first thing to do is to obtain the kernel and test sources, to do so run this command
svn co https://svn.neurostechnology.com/hackers/turran/ ./
then compile your own kernel (note that you need the mkimage command to make an uImage)
cd kernel make ARCH=arm CROSS_COMPILE=arm-linux- uImage make ARCH=arm CROSS_COMPILE=arm-linux- modules
At this point, you have the kernel compiled with an image suitable for UBoot and the modules, dont worry, about the kernel configuration for now, its part of the source tree. Then install the modules on the rootfs you are going to use
make ARCH=arm CROSS_COMPILE=arm-linux- MOD_INSTALL_PATH=#YOUR ROOTFS# modules_install
Now, you are up to test the new kernel. You must download the image from UBoot and boot it using the rootfs as the Neuros OSD rootfs (through NFS). To download the image from the Neuros OSD use a tftp server on your PC, run the server on the kernel/arch/arm/boot/ directory, like:
sudo in.tftpd -L -s kernel/arch/arm/boot
and then on the UBoot prompt run this command:
Neuros Devboard > tftp 0x1800000 uImage
If everything is ok, the new kernel image is on memory, we only need to setup the nfs directory on which our rootfs is and boot. To boot run:
bootm
