PortADeviceToLinux

Introduction

It's relatively simple to add very basic support for devices (like a tablets or smartphones) in Linux.

This article will give some tips on how to do that, as there are some knowledge specific to Android smartphones and tablets that are worth mentioning.

Keeping the device in a good state

First, you probably don't want to break your device while doing that kind of work, especially if you have only one.

To avoid any issues:

Bootloader issues

Upstream Linux is incompatible with several bootloaders found on smartphones and tablets.

See BootloadersIncompatibleWithLinux and the table in BootloaderInterfaces for list of devices bootloaders that are known to be incompatible with Linux and for workarounds.

If you're unsure you could still do the workarounds to make sure your device is not stuck very early in the boot.

In addition, if you need to pass certain arguments to the kernel, you could hardcode them in the kenrel itself with configuration like CONFIG_CMDLINE and CONFIG_CMDLINE_FORCE to make sure that they are really passed to the kernel, as bootloaders often ignore this or that way to pass the kenrel command line to the kenrel. The BootloaderInterfaces also has some information on that.

Validating that your code runs

There are various ways to get some feedback:

In addition you might also be able to play with the kernel command line arguments and delays to understand what is going on. For instance if the device doesn't find the rootfs, assuming that you can make the device reboot, adding panic=1 rootdelay=60 in one boot and panic=1 rootdelay=120 in the next boot can help you detect why the device is rebooting: if the second boot takes 60 more seconds to reboot, then it probably didn't find its rootfs and rebooted. You could also play with panic values like panic=60 in the first boot and panic=120 in the second boot: if there it waits 60 seconds more in the second boot to reboot, then it's probably due to a kernel panic.

If you have access to the bootloader through UART, you could also try to use its interface (which is documented a bit in BootloaderInterfaces) to dump the memory and retrieve a kernel log (like with dmesg). More information on that method is also available in the Debugging by printing wiki page on elinux.org. It would be best to check if that works fine with a stock kernel first, and then proceed with the upstream kernel. Beware that the offsets can and did change over time.