Raspberry Pi 3.2.21 kernel

Posted on by

You know the drill! A few days ago, Linux 3.2.21 was released. As usual I’ve updated my Raspberry Pi kernel. This one has a few additional changes on top of just the 3.2.20 to 3.2.21 update:

  • Imported some further patches from the official Raspberry Pi kernel, including some patches to the ALSA audio driver.

Please see my kernel project page for download links and instructions.

14 thoughts on “Raspberry Pi 3.2.21 kernel”

  1. By installing your newest kernel I get the errors:

    Selecting previously deselected package linux-image-3.2.21-rpi1+.
    (Reading database … 58998 files and directories currently installed.)
    Unpacking linux-image-3.2.21-rpi1+ (from linux-image-3.2.21-rpi1+_1_armel.deb) …
    Examining /etc/kernel/preinst.d/
    Done.
    Setting up linux-image-3.2.21-rpi1+ (1) …

    Hmm. There is a symbolic link /lib/modules/3.2.21-rpi1+/build
    However, I can not read it: No such file or directory
    Therefore, I am deleting /lib/modules/3.2.21-rpi1+/build

    Hmm. The package shipped with a symbolic link /lib/modules/3.2.21-rpi1+/source
    However, I can not read the target: No such file or directory
    Therefore, I am deleting /lib/modules/3.2.21-rpi1+/source

    Running depmod.
    Examining /etc/kernel/postinst.d.
    run-parts: executing /etc/kernel/postinst.d/pm-utils 3.2.21-rpi1+ /boot/vmlinuz-3.2.21-rpi1+

    And then it doesn’t boot. With the latest default kernel it boots fine.

    • No problem with any of the messages you posted there. They’re fully expected as you don’t have the kernel source or build directory on your system.

  2. It appears (based on my work on kernel packaging for raspbian) that the latest firmware can no-longer boot compressed kernels.

    • Uhm, no that can’t be right. I’ve been booting compressed kernels since I pointed out the fix for the problem. What firmware revision do you think it stopped in? I only just booted one with firmware I grabbed yesterday.

  3. sorry false alarm, the cause of my boot failure was actually SD card corruption.

  4. Hi Chris,
    I am trying your driver to drive a MI0283QT2 lcd.
    Bascially it works as long as the sdi payload ( size of tx_buf of the spi_ioc_transfer struct ) is not bigger that 4096 bytes.
    Is this a limitation of your driver ?
    I do not know if it may help but, 4096 is the page size on my system.
    Cheers,

    • That’s a very interesting thought. There should not be a page-size limit to the buffer size that I can think of off the top of my head but I shall have to investigate this I think.

  5. I found out where the problem was, it is not related to your code, but to spidev.
    For the record, spidev limit the size of data passed from the userlevel to 4096. But you can override this value with the kernel parameter bufsiz.

  6. Hi Chris,

    Thanks for the new kernel. It looks fine with one problem. Yes, the omxplyer crash is still there. For what it’s worth it appears to last slightly longer on the .21 kernel than the .20 from what I can see it’s the same fault.

    So, there seem to be two ways to investigate. Either I can send you the omxplayer binary so you can investigate or I can get one of those fancy leads and send you the output from the UART.

    What works best for you?

    • I have Chris’s source compiled with my config from 3.1.9 and omxplayer works fine (didn’t even seem to need recompilation). If it helps, I can provide my config for comparison.

  7. Hi Chris,

    Thanks for the great work on SPI and I2C! also thanks for the precompiled kernel! it saved me time!

    if I understand right I should be able to write to /dev/spidev0.0 to write bytes to the spi (with default parameters) with cs0 pulled low.

    trying (as root)
    echo 'a' > /dev/spidev0.0
    doesn’t seem to do anything. Checking on my scope I have the CS0 and CS1 pins being pulled high as soon as the kernel finds bcm2708_spi. but writing to spidev0.0 doesn’t cause any change on CS0 or SCLK. any idea whats up or what to troubleshoot next?

    [ 0.000000] Linux version 3.2.21-rpi1+ (bootc@tarquin) (gcc version 4.6.4 20120402 (prerelease) (crosstool-NG 1.15.2) ) #9 Sat Jun 23 11:07:26 BST 2012

  8. disregard the above. it was trigger bug in my chinese scope’s firmware.

    • As this has just made it into the official kernel, this is something I am working to include in my kernel now.

Comments are closed.