Add the Raspberry Pi firmware driver

[notro]

The firmware driver will land in v4.2, but this PR backports it to 4.0 and makes it work with the legacy mailbox API (bcm2708-vcio). The driver provides a new API that replaces the bcm_mailbox_property() function. It does not support the other mailbox channels used by vchiq and bcm2708_fb.

These drivers use the mailbox property channel:

• bcm2835-thermal
  I have rewritten the driver and will send it upstream when the firmware driver lands in linux-next (probably after the 4.2 merge window).
• bcm2835-cpufreq
  This needs to be turned it into a device driver so deferred probing works, since the firmware driver is loaded later in the boot process. I haven't got the necessary knowledge to send it upstream and face technical questions.
• rpi-ft5406
  This one is easy to fix, but I don't have any hardware to test with. I can make a PR, but someone else has to test it.

Tested on Pi1 and Pi2 with and without Device Tree + ARCH_BCM2835.

$ dmesg | grep firmware
[    2.296791] raspberrypi-firmware soc:firmware: Attached to firmware from 2015-06-10 20:42

[notro]

I have looked closer at the cpufreq driver and it isn't as complicated as I first thought, so I can try and get it upstream.
Are the thermal and cpufreq device accessible from the ARM side?
The reason I ask is for driver naming. If it can be accessed from ARM and docs will be available in the future, we keep the driver names.
If access has to go through the firmware, I wonder if we should change the names: raspberrypi_thermal and raspberrypi_cpufreq

[popcornmix]

Setting clocks will always have to go through the gpu (there are a lot of complicated dependencies between common plls and divisors that the gpu is master so it wouldn't be safe for the arm to mess with them without interaction with gpu), so cpufreq will have to use the mailbox.

The temperature sensor may be accessible from arm, but again there may be locking issues (the gpu also accesses it).

[notro]

It will take a few weeks to get the drivers accepted into mainline (Stephen Warren going on vacation) and I understand we will switch to 4.0 soon, so maybe we should defer this PR to rpi-4.1.y? What do you think?

[popcornmix]

Sure. We do have an early 4.1 port in this repo. Currently not hugely tested - please give it a try.
There has been squashing. The aim is to get the drivers added in their current DT supporting form, and to make 2708 and 2709 appear at the start of the patchset, and have changes applied in sync.
Let me know if you'd prefer any changes to how they are squashed, or any changes regarding attribution.

[notro]

Eric Anholt has made a clock driver that inlcudes the arm clock: [PATCH v3 1/7] dt/bindings: Add binding for the Raspberry Pi clock provider
I'll wait for that before I upstream the cpufreq driver.

or any changes regarding attribution.

Most of the work I have done is transitional and will probably be gone whithin a year when we're using ARCH_BCM2835 and more mainline drivers (I'm optimistic), but I'm honoured to see that you have added me in the Main bcm2708/bcm2709 linux port commit message.

[popcornmix]

The patches are certainly appreciated. It now looks like moving to ARCH_BCM2835 is not too far away. We would be a lot further away without your help.

[popcornmix]

BTW, I'm hoping to bump rpi-update kernel to 4.0 soon (maybe this weekend), with apt-get and raspbian images to follow. So 3.18 updates will stop. 4.1 will be the new experimental tree, so any patches moving us towards upstream can happen there.

I'll leave 4.0 tree unsquashed, so the history is available, and as it will be the new stable tree, I will merge upstream updates rather than rebase them. 4.1 may be rebased.

[notro]

I have updated the status page: https://github.com/raspberrypi/linux/wiki/Upstreaming
If something needs changing, please update the page or let me know and I'll do it or we'll discuss it.

[notro]

@popcornmix I'm trying to understand the mailbox interface and in particular reading.
The various drivers/channels does mailbox transactions differently.

This is my understanding about the returned register value when reading, based on the wiki:

• The channel is in the lower 4 bits. With multiple asynchronuos mailbox requests to different channels, this is how we know which request we get back.
• The upper 28 bits has the actual value.

Actual value is:

• MBOX_CHAN_POWER: the previously written value
• MBOX_CHAN_FB: zero if everything is ok.
• MBOX_CHAN_VCHIQ: ??
• MBOX_CHAN_PROPERTY: the previously written value

What kind of error is it if the returned value is wrong?

bcm2708-vcio: What purpose does the reading serve here? Wait for completion? The returned is value is not checked.

extern int bcm_mailbox_property(void *data, int size)
{
...
    wmb();
    s = bcm_mailbox_write(MBOX_CHAN_PROPERTY, (uint32_t)mem_bus);
    if (s == 0)
      s = bcm_mailbox_read(MBOX_CHAN_PROPERTY, &success);
    if (s == 0) {
      /* copy the response */
      rmb();

bcm2708_fb checks for zero:

static int bcm2708_fb_set_par(struct fb_info *info)
{
...
    /* ensure last write to fbinfo is visible to GPU */
    wmb();

    /* inform vc about new framebuffer */
    bcm_mailbox_write(MBOX_CHAN_FB, fb->dma);

    /* TODO: replace fb driver with vchiq version */
    /* wait for response */
    bcm_mailbox_read(MBOX_CHAN_FB, &val);

    /* ensure GPU writes are visible to us */
    rmb();

        if (val == 0) {
...

vchiq has no reading

int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
{
...
    /* Send the base address of the slots to VideoCore */

    dsb(); /* Ensure all writes have completed */

    err = bcm_mailbox_write(MBOX_CHAN_VCHIQ, (unsigned int)slot_phys);
    if (err) {
        dev_err(dev, "mailbox write failed\n");
        return err;
    }

bcm2708-power checks the returned value:

int bcm_power_request(BCM_POWER_HANDLE_T handle, uint32_t request)
{
...
    /* Send a request to VideoCore */
    bcm_mailbox_write(MBOX_CHAN_POWER, global_request << 4);
    /* Wait for a response during power-up */
    if (global_request & ~g_state.global_request) {
        rc = bcm_mailbox_read(MBOX_CHAN_POWER, &actual);
        actual >>= 4;
...
    if (rc == 0) {
        if (actual != global_request) {
            printk(KERN_ERR

[notro]

Is it as simple as this: The written value should match the read value, unless MBOX_CHAN_FB which should be zero?
Any other value is an error and the data in the buffer can't be trusted.

What happens if I send a bogus address to the mailbox? Or are all addresses valid?

[popcornmix]

There isn't a general protocol for what the mailbox return value is. Each channel returns something useful. Looking at firmware code:

MBOX_CHAN_POWER: A bit set for each power supply that has been enabled
MBOX_CHAN_FB: zero if everything is ok. Non zero for error.
MBOX_CHAN_VCHIQ: No return value
MBOX_CHAN_PROPERTY: the previously written value

To be honest, the channels other than PROPERTY are really legacy. The PROPERTY interface can handle the POWER and FB commands, and it wouldn't be hard to add the VCHIQ message to the PROPERTY interface.

[notro]

Would it be possible to add MBOX_CHAN_FB to the property interface as well?

I now have vchiq and bcm2708_fb working through the firmware driver: https://gist.github.com/notro/d747deac1e916764a1e6

Next to do is the power driver and then I will see if I can switch to bcm2835-mailbox. I'm beginning to suspect that this is possible.

[popcornmix]

The methods are slightly different, but I belive all that is possible through the FB interface is possible through property interface. There are a lot of framebuffer set/test/get calls in property mailbox interface.

[notro]

I have the bcm2708_fb driver working with property tags: https://gist.github.com/notro/6cdadc27fe39aed0b45e
However I had to offset the base address for it to work:

        fbinfo.base |= 0x40000000;

Can you check the firmware to see if the two methods/channels return the same address?

Do you know how I can test setcolreg and the ioctl?

I have also added a function to the firmware driver that turns on USB power.
So the last piece is the VCHIQ channel. Can you add that as a property?

[popcornmix]

Chuckie Egg is my test program for palletised modes:
https://www.raspberrypi.org/forums/viewtopic.php?f=35&t=9583

(just building a firmware with VCHIQ support on property channel)

[popcornmix]

setterm -blank force / setterm -blank poke (in real keyboard not uart/ssh) should test the blank ioctl. For VSYNC look here: #679

[popcornmix]

Can you try: https://dl.dropboxusercontent.com/u/3669512/temp/firmware_vchiqmbox.zip

VCHIQ Init
Tag: 0x00048010
Request:
Length: 4
Value:
u32: channelbase
Response:
Length: 4
Value:
u32: 0 is success

[popcornmix]

I think there is a bug on the firmware that makes:

fbinfo.base |= 0x40000000;

necessary. Just building an updated version that should make this unnecessary.

[popcornmix]

Updated last firmware to include fix for fbinfo.base:
https://dl.dropboxusercontent.com/u/3669512/temp/firmware_vchiqmbox2.zip

[notro]

The framebuffer address is correct now, but I can't get vchiq to work with the property channel.
Booting hangs in vc_sm, but disabling that gets me to userspace.

vchiq_platform_init(): Send address:

printk("%s: slot_phys=%pad\n", __func__, &slot_phys);
    channelbase = slot_phys;
printk("%s: channelbase=0x%x\n", __func__, channelbase);
    err = rpi_firmware_property(fw, RPI_FIRMWARE_VCHIQ_INIT,
                    &channelbase, sizeof(channelbase));
printk("%s: channelbase=0x%x\n", __func__, channelbase);

vcgencmd hangs:

$ vcgencmd measure_temp
^C

$ dmesg
[    1.795231] vchiq: vchiq_init_state: slot_zero = 0xdbc80000, is_master = 0
[    1.805028] vchiq_platform_init: slot_phys=0x5bc80000
[    1.811954] vchiq_platform_init: channelbase=0x5bc80000
[    1.818844] rpi_firmware_transaction: data=0x5b800000
[    1.826414] rpi_firmware_transaction: message=0x5b800000
[    1.833465] vchiq_platform_init: channelbase=0x0

$ sudo vcdbg log msg
...
003618.413: vchiq_core: vchiq_init_state: slot_zero = 0x5bc80000, is_master = 1

[popcornmix]

Do you have a complete patch?
I tried:

struct rpi_firmware *fw = rpi_firmware_get(NULL);
BUG_ON(!fw);
#define RPI_FIRMWARE_VCHIQ_INIT 0x00048010
printk("%s: slot_phys=%pad\n", __func__, &slot_phys);
    u32 channelbase = slot_phys;
printk("%s: channelbase=0x%x\n", __func__, channelbase);
    err = rpi_firmware_property(fw, RPI_FIRMWARE_VCHIQ_INIT,
                    &channelbase, sizeof(channelbase));
printk("%s: channelbase=0x%x\n", __func__, channelbase);

    //err = bcm_mailbox_write(MBOX_CHAN_VCHIQ, (unsigned int)slot_phys);

but fw is NULL.

[notro]

This is the firmware driver: https://gist.github.com/notro/dfcef441d6b527423bbd
These are the rest of the changes: https://gist.github.com/notro/25f289e8382bc444e9e6

Applied on rpi-4.1.y

[notro]

VCHIQ is working now, thanks.

I have been able to use bcm2835-mailbox, the firmware driver and then put the legacy mailbox API (bcm_mailbox_*) on top of that.
bcm2708-vcio is turned into a module that just provides the legacy API and /dev/vcio.
A little tweak to the mailbox subsystem makes it work without DT also.
The firmware driver also turns on USB power, so bcm2708-power can be removed.
This is the patch I use on top of the firmware driver and bcm2835-mailbox: https://gist.github.com/notro/26954782c8e43ad9d5d5

The legacy API can be removed (except for /dev/vcio) when all drivers have been converted.

What do you think about this approach?

[popcornmix]

Sounds okay to me. I assume hello_fft (and similar mailbox apps) still works?
Is there a better way of creating /dev/vcio?

[notro]

I assume hello_fft (and similar mailbox apps) still works?

pi@raspberrypi:/opt/vc/src/hello_pi/hello_fft$ sudo ./hello_fft.bin 12
rel_rms_err = 7.8e-07, usecs = 260, k = 0

Is there a better way of creating /dev/vcio?

At first I moved the legacy API to the firmware driver, but then I remembered the /dev/vcio stuff so I just kept it in the bcm2708-vcio module, since it is 200+ lines.
But perhaps we could make a new module, since it's not a mailbox driver anymore: drivers/char/broadcom/vcio.c. When all drivers have been converted only the /dev/vcio stuff will remain, so this might be a good choice.

The mailbox driver will land in 4.2, but the firmware driver is yet to have entered any tree I can find.
It's acked and Lee has propably sent it: http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-June/001865.html
The other patches in the series has been applied for 4.2: http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-June/001863.html

How do you feel about me making a PR before it is verified entering a for-mainline tree?

[popcornmix]

How do you feel about me making a PR before it is verified entering a for-mainline tree?

I'm okay with that on rpi-4.1.y. This tree is for testing future changes. It it changes before it reaches mainline then we'll have to keep track of that.
The stable (rpi-4.0.y) would need a bit more more caution.

[notro]

Why does it take so long (0.5s) to turn on USB power?

[    0.692073] raspberrypi_firmware_set_power(domain=3, on=1)
[    0.697610] rpi_firmware_transaction(chan=8, data=0x5b800000)
[    1.204122] raspberrypi_firmware_set_power: ret=0

It's the same with the bcm2708-power driver:

[    0.766703] bcm_power: Broadcom power driver
[    0.770999] bcm_power_open() -> 0
[    0.774332] bcm_power_request(0, 8)
[    1.278510] bcm_mailbox_read -> 00000080, 0
[    1.282718] bcm_power_request -> 0

The documentation indicates that bit 1 should make a difference, but setting it doesn't change how long it takes.

State:
Bit 0: 0=off, 1=on
Bit 1: 0=do not wait, 1=wait

Response indicates new state, with/without waiting for the power to become stable.

Half a second is a big part of the kernel boot time before userspace takes over.

[popcornmix]

Good question. I stepped through the firmware code and sure enough it takes 500ms.
I prodded a few people and found @P33M has an uncommitted patch:

drivers/usb: Reduce busy-wait to sensible timeout
DWC OTG databook states that after a host/device mode force bit is set,
a 25ms delay must elapse before any further register read/writes.
Previously the busy-wait loop was 500ms.

That will be in next firmware update.

[notro]

Does this mean that the documentation is wrong about the wait bit?

[popcornmix]

The wait bit is only a hint. We do the power switch from the mailbox thread.
For a simple register write + delay for power to become stable we can skip the delay when the bit is unset.
The USB needs additional register accesses after the delay, so making use of the wait but is not straightforward without launching another thread.

[notro]

While testing my PR I've discovered that hello_fft.bin does not work on Pi2 without Device Tree.
I've tested with the stock kernel as well:

$ uname -a
Linux raspberrypi 4.0.6-v7+ #798 SMP PREEMPT Tue Jun 23 18:06:01 BST 2015 armv7l GNU/Linux

$ sudo /opt/vc/src/hello_pi/hello_fft/hello_fft.bin 12
^C

I have some instrumentation in my new code, and I can see that only 3 of the 6 messages are sent:

[   93.020799] rpi_firmware_transaction(chan=8, data=0xfa810000)
[   93.020942] rpi_firmware_transaction(chan=8, data=0xfa810000)
[   93.021788] rpi_firmware_transaction(chan=8, data=0xfa810000)

Don't know if this matters though.

[popcornmix]

Faster USB power on and VCHIQ init through mailbox should be in latest rpi-update firmware.

[notro]

Chuckie Egg is my test program for palletised modes:
https://www.raspberrypi.org/forums/viewtopic.php?f=35&t=9583

The binary download links are dead.

This one gives a blank screen and I can't quit:

sudo apt-get install libsdl1.2-dev
wget http://www.marklomas.net/ch-egg/downloads/ch-egg-port-sdl-source_v1_1.zip
unzip ch-egg-port-sdl-source_v1_1.zip
cd ch-egg-port-sdl-source_v1.1/

# Compile libbbcb.a
cd ch-egg/bbcb
gcc -Os -I/usr/include/SDL -c sound.c mode2font.c r6502main.c
ar cr libbbcb.a sound.o r6502main.o mode2font.o

# Compile and link ch-egg.elf
cd ..
gcc -Os -I/usr/include/SDL -I../ execute.c library.c main.c -Lbbcb -lbbcb -lSDL -lm

./a.out

I also tried this, but it also gives me a blank screen. Can quit with 'q'.

git clone https://github.com/pbrook/Chuckie-Egg
cd Chuckie-Egg/
./configure
make chuckie
./chuckie

Do you have a binary or how do you build it?

[popcornmix]

The blank screen is caused by an SDL bug (it assumes framebuffer base address won't change when changing framebuffer resolution/depth). Install the deb package from here:
https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=99822#p707673

I used this version (http://marklomas.net/ch-egg/native/native.htm). The build script needed "-lm" and a tweak to the path of the bbcb library, but it otherwise works okay.

Ping @XECDesign - can we get this into raspbian as a default? Lots of packages are broken due to this currently.

[XECDesign]

Sure, will get that sorted tomorrow.

[popcornmix]

@XECDesign thanks.

[notro]

@popcornmix Thanks, it's working now.

However when I use the property channel I get wrong colours.
Please have a look at the patch and see if there's anything obviously wrong with my palette handling: https://gist.github.com/notro/7c5ef4d22eaa2c60dd2c

[notro]

I realised that I can get the palette as well (patch).

This is what I get:

[   52.448474] bcm2708_fb_setcolreg: set palette: regno=15
[   52.448516] 0000 000a 0015 001f 0120 012a 0135 013f 0240 024a 0255 025f 0360 036a 0375 037f
[   52.448998]
[   52.448998] bcm2708_fb_setcolreg: get palette:
[   52.449042] 0000 0008 0010 0018 0020 0028 0030 0038 0040 0048 0050 0058 0060 0068 0070 0078
[   52.449070] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449094] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449116] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449138] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449161] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449182] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449207] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449230] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449253] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449275] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449298] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449322] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449345] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449367] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
[   52.449390] 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

[   52.449444] bcm2708_fb_setcolreg: set palette: regno=255
[   52.449471] 0000 000a 0015 001f 0120 012a 0135 013f 0240 024a 0255 025f 0360 036a 0375 037f
[   52.449496] 0480 048a 0495 049f 05a0 05aa 05b5 05bf 06c0 06ca 06d5 06df 07e0 07ea 07f5 07ff
[   52.449521] 2000 200a 2015 201f 2120 212a 2135 213f 2240 224a 2255 225f 2360 236a 2375 237f
[   52.449546] 2480 248a 2495 249f 25a0 25aa 25b5 25bf 26c0 26ca 26d5 26df 27e0 27ea 27f5 27ff
[   52.449573] 4800 480a 4815 481f 4920 492a 4935 493f 4a40 4a4a 4a55 4a5f 4b60 4b6a 4b75 4b7f
[   52.449599] 4c80 4c8a 4c95 4c9f 4da0 4daa 4db5 4dbf 4ec0 4eca 4ed5 4edf 4fe0 4fea 4ff5 4fff
[   52.449625] 6800 680a 6815 681f 6920 692a 6935 693f 6a40 6a4a 6a55 6a5f 6b60 6b6a 6b75 6b7f
[   52.449650] 6c80 6c8a 6c95 6c9f 6da0 6daa 6db5 6dbf 6ec0 6eca 6ed5 6edf 6fe0 6fea 6ff5 6fff
[   52.449673] 9000 900a 9015 901f 9120 912a 9135 913f 9240 924a 9255 925f 9360 936a 9375 937f
[   52.449700] 9480 948a 9495 949f 95a0 95aa 95b5 95bf 96c0 96ca 96d5 96df 97e0 97ea 97f5 97ff
[   52.449725] b000 b00a b015 b01f b120 b12a b135 b13f b240 b24a b255 b25f b360 b36a b375 b37f
[   52.449749] b480 b48a b495 b49f b5a0 b5aa b5b5 b5bf b6c0 b6ca b6d5 b6df b7e0 b7ea b7f5 b7ff
[   52.449775] d800 d80a d815 d81f d920 d92a d935 d93f da40 da4a da55 da5f db60 db6a db75 db7f
[   52.449799] dc80 dc8a dc95 dc9f dda0 ddaa ddb5 ddbf dec0 deca ded5 dedf dfe0 dfea dff5 dfff
[   52.449826] f800 f80a f815 f81f f920 f92a f935 f93f fa40 fa4a fa55 fa5f fb60 fb6a fb75 fb7f
[   52.449851] fc80 fc8a fc95 fc9f fda0 fdaa fdb5 fdbf fec0 feca fed5 fedf ffe0 ffea fff5 ffff
[   52.450271]
[   52.450271] bcm2708_fb_setcolreg: get palette:
[   52.450322] 0000 0008 0010 0018 0020 0028 0030 0038 0040 0048 0050 0058 0060 0068 0070 0078
[   52.450349] 0080 0088 0090 0098 00a0 00a8 00b0 00b8 00c0 00c8 00d0 00d8 00e0 00e8 00f0 00f8
[   52.450375] 0200 0208 0210 0218 0220 0228 0230 0238 0240 0248 0250 0258 0260 0268 0270 0278
[   52.450398] 0280 0288 0290 0298 02a0 02a8 02b0 02b8 02c0 02c8 02d0 02d8 02e0 02e8 02f0 02f8
[   52.450422] 0400 0408 0410 0418 0420 0428 0430 0438 0440 0448 0450 0458 0460 0468 0470 0478
[   52.450448] 0480 0488 0490 0498 04a0 04a8 04b0 04b8 04c0 04c8 04d0 04d8 04e0 04e8 04f0 04f8
[   52.450472] 0600 0608 0610 0618 0620 0628 0630 0638 0640 0648 0650 0658 0660 0668 0670 0678
[   52.450495] 0680 0688 0690 0698 06a0 06a8 06b0 06b8 06c0 06c8 06d0 06d8 06e0 06e8 06f0 06f8
[   52.450519] 0900 0908 0910 0918 0920 0928 0930 0938 0940 0948 0950 0958 0960 0968 0970 0978
[   52.450543] 0980 0988 0990 0998 09a0 09a8 09b0 09b8 09c0 09c8 09d0 09d8 09e0 09e8 09f0 09f8
[   52.450568] 0b00 0b08 0b10 0b18 0b20 0b28 0b30 0b38 0b40 0b48 0b50 0b58 0b60 0b68 0b70 0b78
[   52.450591] 0b80 0b88 0b90 0b98 0ba0 0ba8 0bb0 0bb8 0bc0 0bc8 0bd0 0bd8 0be0 0be8 0bf0 0bf8
[   52.450616] 0d00 0d08 0d10 0d18 0d20 0d28 0d30 0d38 0d40 0d48 0d50 0d58 0d60 0d68 0d70 0d78
[   52.450640] 0d80 0d88 0d90 0d98 0da0 0da8 0db0 0db8 0dc0 0dc8 0dd0 0dd8 0de0 0de8 0df0 0df8
[   52.450663] 0f00 0f08 0f10 0f18 0f20 0f28 0f30 0f38 0f40 0f48 0f50 0f58 0f60 0f68 0f70 0f78
[   52.450688] 0f80 0f88 0f90 0f98 0fa0 0fa8 0fb0 0fb8 0fc0 0fc8 0fd0 0fd8 0fe0 0fe8 0ff0 0ff8

[popcornmix]

You are submitting 32bpp palette numbers as 16bpp. This should fix it:
https://gist.github.com/popcornmix/e019aaac1b4292ce770c

There was also a bug in reading the palette which I've got a fix for.
(If you ask to read half the size I suspect that will work).

[notro]

Thanks, that's better.
This means that I have successfully converted all drivers to the firmware api.
I can't test the touch driver, but it returns zero indicating no touchpanel detected.