kobo-clara: new device (Kobo Clara HD)

Hi,

this adds support for the Kobo Clara HD ereader. It includes both the vendor kernel and the mainline kernel with Andreas Kemnade’s patches (many drivers have already been upstreamed). The latter works very well and even supports running the X server with no modifications. The framebuffer device can be used directly with both kernels. I added the vendor kernel because most free ereader programs (like koreader, plato and inkbox) are developed for that kernel’s (slightly different) framebuffer API.

I used the downstream u-boot fork. It is new enough (2016) to support loading the kernel, DTB and initramfs from an ext2 partition. It does need a "hardware config" structure in the SD card block 1024 to function properly. I included this directly in the firmware-kobo-clara package as it is only 110 bytes with documented values. U-boot environment is read from block 1536. I replaced the original environment with the one that simply loads the actual boot script (different for each kernel) from the boot partition.

Hardware config is also passed by u-boot to the vendor kernel. So is the frontlight value table, similarly installed by firmware-kobo-clara. Both files must be preceded on the SD card by a header containing a magic number and length. I generate the header with a shell function that I had some fun writing but might be overkill (we could just include the generated header). The mainline kernel doesn’t need either blob.

The main remaining issue is distributing waveform data, needed by the eink display panel driver. I didn’t find any online source, and I think it might actually be tuned specifically for each panel (or perhaps each batch of panels). Like most Kobo devices, the ereader comes with waveform data written at block 14336 of the SD card, again preceded by the length header. U-boot can load this and pass it to the kernel if found; this is only supported by the vendor kernel. Both kernels will also try to load the waveform from /lib/firmware/imx/epdc, so it would probably be better to place it there.

I was thinking it might be possible to extract the waveform from the SD card on first boot and store it in /lib/firmware. I am not sure how to best go about this within the pmOS framework. Doing it in initramfs seems like a good option, but I don’t think a hook will work since those get run before the root partition is mounted. Alternatively it might be possible to do it during installation by hooking into the pmbootstrap install command somehow.

To actually install this you have to open the device (not very difficult) and replace (the contents of) the SD card. Running pmbootstrap install --sdcard works OK, and will leave the waveform blob intact. There are some references to fastboot in the u-boot code but I have not investigated that option yet. I also haven’t looked into the WiFi driver, but apparently it is supported as an out-of-tree module for the mainline kernel.

Please let me know if there are other issues to address before this can be merged. Thanks!