Kernel status

Introduction

The first firmware release was based on a heavily patched linux-2.6.27-omap1 kernel. linux-omap used to be OMAP community kernel fork, nowadays its code was either merged to mainline or dropped. Further OMAP development continues on mainline kernels, linux-omap tree is mainly used to queue developed code to mainline.

Current firmware releases are based on 3.x kernel series.

Status

Driver support in 3.x series is more or less complete, however not all parts are merged to mainline kernel due to various reasons.

merged code (already in mainline as of 3.4)

• board support (enables UART, I2C, SPI, RTC, MMC{1,2,3}, NAND, OTG, EHCI, gpio-keys, leds-gpio, keypad, touchscreen, regulators)
• sound: ALSA ASoC machine driver
• bq27500 fuel gauge
• LCD panel driver
• wl1251 WiFi driver glue (portions only in 2.6.37)
• charging (partial only, 2.6.37)
• wl1251 complete powerdown/suspend using runtime_pm (2.6.38).
• backlight driver (3.4)

this doesn't list various bugfix patches to get above working :)

not merged

now in openpandora.org GIT (mainline merge status in brackets)

• nubs (aka vsense, needs rework for mainline)
• keypad fn handling (not allowed in mainline)
• PWM LEDs (needs rework)
• Overclocking support
• some charging bits (too many hacks)
• various random hacks that benefit pandora but may harm other devices, hence mainline incompatible

openpandora.org git structure

Support for various kernels is available in pandora-XX branches or tags, XX corresponds to last part of kernel version number. 2.6.27 is an exception, it's in pandora-27-omap1 branch.

Branches based on pre-release -rc kernels will be often rebased. This means you can't do 'git pull' on them, use 'git fetch; git reset --hard origin/pandora-XX' instead. Warning: this will destroy all your changes (even if they are commited), backup them first!

See also:

• Firmware governance

Configuring newer kernels

When compiling mainline kernel, use

make omap2plus_defconfig

for openpandora.org kernels you can use omap3_pandora_defconfig

make omap3_pandora_defconfig

after either of those are run, you can tune the configuration for your needs:

make menuconfig

Now you should be able to build a working kernel. More info available at Kernel build instructions.

Running

Easiest way is to place your new uImage to root of SD (FAT or ext2, ext2 may need a bootloader update) along with a file named 'autoboot.txt', which contains u-boot commands such as:

fatload mmc 0 0x80300000 uImage; bootm 0x80300000

Kernel bootargs can be changed by adding 'setenv' line before fatload:

setenv bootargs debug root=...

serial port

In an unlikely event that you can get serial output from EXT port, be aware that serial device has changed several times (due to the driver and port configuration changes in the kernel):

• openpandora.org 2.6.27: ttyS0
• mainline upto 2.6.36: ttyS2
• mainline/openpandora.org 2.6.37 and up: ttyO2

This is relevant for console= bootarg.

Contributing

Help is always welcome, usually in form of testing or writing patches. In most cases it's best to file a bug report or feature request in the bug tracker so that things don't get lost.

Submitting patches

It's best to send formal GIT-generated patch so that you get proper credit for your work and to make applying the patch easier. You can also add 'Signed-off-by' line ('-s' on 'git commit' will do it for you), which has the same meaning as for mainline Linux.

So basic workflow would be:

<make changes>
git config --global user.name "My Name"
git config --global user.email "myname@domain.com"
git add <changed files>
git commit
git format-patch -o /somewhere/ -1

Then create a new feature request in bugtracker and attach the generated file(s), or send them to the mailing list, or post them on the forums, whatever is more convenient to you.