Re: Newer kernel for silvermoon

Cool! No I haven't looked into the 3.5" models. It's a completely different processor, so everything would be different about the bootloader setup. I actually have a couple of Chumby Ones and want to mess with those at some point in the future, but probably not until I'm finished with the Chumby 8. My ultimate stretch goal for the future would be mainline kernel support for both the Chumby 8 and Chumby One, but I don't know how realistic that is.

I did notice this post making progress on the Chumby One with newer kernels:

Re: Newer kernel for silvermoon

Big update for today, I got audio working! Well, playback anyway. Recording is something I'll tackle another day, if ever. Does the Chumby 8 even have a mic? It's definitely wired up to a header in the schematic.

To make a long story short, the mainline kernel mostly has everything you need to get the Chumby audio working. Mostly. It's just that a few old patches from 2010 adding support for the PXA168 never got merged, but luckily they're still available for historical reference and they were very helpful. It has been an interesting learning experience figuring out I2S (and similar formats). Basically, the PXA2xx/3xx have the same SSP controller as the PXA168, so there's already mainline support for audio that requires a little bit of tweaking. Unfortunately it also seems to have some bugs. But it's unclear to me if they are truly bugs, or just differences in behavior or expected configuration between the PXA168 versus the PXA2xx/3xx. I had to do some hacks so I'm less confident about the audio fixes getting mainlined. I guess it depends on how much time I want to invest in cleaning it up and working with the kernel devs to figure out why things didn't just work "out of the box" for me.

Anyway, I figured out the magic combination of settings and patches that work for what we need for the Chumby 8. I have pushed new builds of u-boot, linux, and buildroot. My latest buildroot should have audio support.

I wouldn't say I'm done with audio support quite yet, but it's looking pretty good. Things still to do:

  • Confirm that I'm configuring the WM8961 correctly. There are likely some config differences from what Chumby did. It seems to work at least...

  • Confirm that I'm hooking the WM8961's controls up to the PXA168's controls properly, if that's even a thing...basically just confirm I'm doing it right

  • Get headphone jack working. Currently I haven't hooked up the headphone jack presence detection input, or even tested the headphone jack for that matter. Theoretically this should be easy because I'm using simple-audio-card which has the built-in ability to deal with headphone detect pins.

  • Do minimal work to attempt to get audio recording working, assuming there is actually a mic

To use the speaker, run something like this from the command line (assuming you have a file blah.wav stored on the root of your rootfs on the SD card:

amixer set Speaker 117
aplay /blah.wav

The volume levels are kind of weird -- your usable range is basically somewhere around 90 to 127. If you go much lower than 90 you can't really hear anything at all. 127 is the highest allowed. It seems louder than the stock Chumby kernel's maximum. I'm not sure if they intentionally limited the volume or what. So be careful about going higher than 119, I believe that was the stock kernel's max.

Re: Newer kernel for silvermoon

Today's audio update:

There is indeed a mic on the Chumby 8. In fact, there was a helpful post on this forum explaining how to test it on the stock kernel:

So I tested it, and it works after I got the MICBIAS working in the device tree, which basically entailed hooking up the WM8961 to the PXA168 "properly" as I was talking about in my second bullet point above. It revealed a few bugs where I was doing the I2S slightly wrong and the channels were kind of swapped from what they should be, so I did some hacky fixes for that. I'm still not super proud of these fixes, but the pxa2xx ssp audio driver is tough to work on because it supports so many other machines that I don't want to break if possible. The SSP controller is really a pain to mess with, I hope I'm done with it for now.

There was also a problem where if you stopped recording or playing, it would halt any existing playback or recording, respectively. That's fixed now too.

All the other stuff I listed in the previous message is also handled. I'm configuring the WM8961 just fine. The original kernel defaulted to a higher speaker AC gain, and did a slight power saving thing with the DSP enable that the mainline kernel driver doesn't bother with. Other than that, it's pretty much all the same. The headphone jack detection works great, that was basically a one line change in the device tree.

As always, the latest changes are pushed to my linux and buildroot repos.

To detect if the headphone is plugged in, I'm not sure how ALSA stuff does it, but it shows up as /dev/input/event1 now. For testing purposes, evtest is capable of monitoring the status and notifying when it changes. "amixer events" also shows an event occurs when headphones are plugged in or removed.

To set up for playing sound through the headphones:

amixer set Headphone 70%
amixer set Speaker 0%

Or you can play out both simultaneously if you'd like, by setting Speaker to something other than 0%.

To record 5 seconds of audio (initial setup shamelessly copied from the link above):

amixer set Capture 85%
amixer set "Capture PGA" 100%
amixer set "Capture PGA" on
amixer set "Capture Boost" 100%
arecord -c 1 -r 44100 -d 5 -f S16_LE -t wav > /tmp/test.wav

You can also record in stereo by using the command at the link above instead, but there's no point in doing so because the second channel is empty. The right channel input for the mic is wired to nothing on the board.

I began noticing today that ever since I got audio working, the touchscreen has been super unresponsive and printing error messages. It appears that ever since I got DMA working, it's using DMA even for the simple 2-byte transfers that the touchscreen driver does. That's silly, so I increased the DMA threshold in the PXA SPI driver to something a bit more reasonable (8 bytes) so we won't waste a bunch of time setting up DMA just for 2 bytes to be transferred.

Oh yeah, and there's an issue that causes a bunch of DMA-related errors to be printed at startup: "-ENXIO: IRQ index 1 not found", "IRQ index 2 not found", etc. all the way through to index 31. This is a nonissue and everything is working correctly with the DMA controller. It has to do with the way the DMA controller figures out its interrupts when setting up. I'll try to figure out a workaround for the errors sometime soon.

Anyway, I'm not really sure what's next. Clean up the buildroot so it builds a fully bootable SD card without needing manual environment setup? Honestly, with working audio, WiFi, minimal framebuffer, and touchscreen, that opens up a lot of possible development opportunities for people who want to play around! Maybe a cool stretch goal would be an "actual" video driver. Supposedly there's a 2D graphics accelerator on this chip compatible with the etnaviv driver. I'm curious how hard that would be to get working...