• Registered: 2013-11-30
  • Posts: 36

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: http://forum.chumby.com/viewtopic.php?id=10100

  • Registered: 2013-11-30
  • Posts: 36

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.

  • Registered: 2013-11-30
  • Posts: 36

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:

https://forum.chumby.com/viewtopic.php?pid=38820#p38820

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...

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

I recently got an Infocast 8 and can confirm that everything I've done so far with the audio also works on the Infocast. The only difference I've observed so far is that the Infocast has a rev A0 CPU and the Chumby 8 has a B0 CPU. So I will need to be careful going forward to ensure I don't depend on any fixes specific to the B0 silicon. So far so good! It's also clear to me that the Infocast definitely had a different early bootloader boot process than the Chumby, because it prints extra garbage on the serial line at startup before the early bootloader loads. It's probably related to the errata fixed in B0 where the boot ROM isn't capable of booting over 4-bit SD cards. I think someone mentioned that issue early on in this thread years ago.

I also played with the etnaviv 2D acceleration driver a little bit at the end of last week. I can get it to load and recognize the GC300 2D accelerator in the PXA168, but the driver crashes and doesn't work. So that would require further digging to get working. It's also unclear to me how you would even make use of the 2D accelerator. I saw one way of possibly getting it working with X11, but I don't know if X11 would make sense to run in such a resource constrained situation like this. I think my time would be better spent on getting it buttoned up as some kind of alternate firmware playground for people to mess with and customize to their heart's content.

  • From: WiscoDisco
  • Registered: 2011-03-23
  • Posts: 113

Re: Newer kernel for silvermoon

Excellent work!

Owner of three C1's, Infocast 3.5, Sony Dash C10, and Infocast 8. A tinkerer at heart and IT director by trade.
  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

Hey, thanks! Latest update is I don't have anything recently pushed to GitHub, but I've been hard at work (in my spare time) getting the graphics working "correctly" in Linux. Yes, I decided to go there. The DRI/DRM graphics system in Linux is super intimidating but I'm starting to slowly figure things out enough to get it working.

I have been using the simpledrm driver which is just a "dumb" framebuffer that doesn't really make use of the capabilities of the chip. Luckily, the armada-drm driver in the mainline kernel is pretty much compatible with the PXA168's LCD controller. It just needs a few minor tweaks (along with some patches from the maintainer that haven't been upstreamed yet) and it works. I've also been able to get the GC300 2D graphics accelerator working with the etnaviv kernel driver. That was quite a process to figure out because there were a few tweaks needed to be made to the driver for compatibility with older stuff. This does require using X11 (with the xf86-video-armada driver for X11). It's still pretty experimental and not as useful as you might think, but it's still cool to be able to get everything working.

Previously, attempts to play video looked terrible with the dumb framebuffer. Everything was slow. With the armada-drm driver (the etnaviv 2D accelerator doesn't seem to matter) I was able to play a smaller 640x360 MPEG-4 video file using mpv and it plays nice and smoothly. You can even scale it to full-screen with no performance impact. One downside is that the first time I play a video it appears as a blue screen, but subsequent attempts work. Not sure what's up with that. Another problem is once you go to higher resolutions it doesn't work so well. So it's not perfect, but hey, at least there is some video capability instead of just a slow framebuffer. Looks like Marvell had a custom gstreamer plugin to support decoding up to 720p30 H.264 in the PXA168, so there's probably some kind of hardware decoding help available. That might be interesting to look into, if it's possible to get working with a modern kernel. I probably won't look into it, to be honest. Maybe someone else can bash their head against the wall for a while and figure out PXA168 gstreamer!

Lastly, I've been suspicious for a while that the CPU usage % of "top" was inaccurate on the PXA168. Whenever I ran top, it would always say that top was using 80% to 100% of the CPU, and the idle was usually 0% or something low like 10%. It turns out I was correct. There's some kind of long-time bug in the kernel with the PXA168 and "CONFIG_NO_HZ_IDLE" that causes inaccurate idle time reporting. It's not counting all the idle ticks it's supposed to. This was even an issue back with the 3.13 kernel I was playing with originally too. I changed to CONFIG_HZ_PERIODIC and now the CPU usage calculation is actually correct. It would be nice to figure out how to get it working properly with NO_HZ_IDLE, but I'm not sure how difficult it'll be to track down.

I'll try to push all this stuff to GitHub eventually. Unfortunately adding X11 into the mix means some weird stuff happens at startup with the framebuffer now and X11 is a tad bit slow to load. But it's probably worth it to add much better graphics capabilities.

  • Registered: 2022-09-06
  • Posts: 5

Re: Newer kernel for silvermoon

dougg3 wrote:

I recently got an Infocast 8 and can confirm that everything I've done so far with the audio also works on the Infocast. The only difference I've observed so far is that the Infocast has a rev A0 CPU and the Chumby 8 has a B0 CPU. So I will need to be careful going forward to ensure I don't depend on any fixes specific to the B0 silicon. So far so good! It's also clear to me that the Infocast definitely had a different early bootloader boot process than the Chumby, because it prints extra garbage on the serial line at startup before the early bootloader loads. It's probably related to the errata fixed in B0 where the boot ROM isn't capable of booting over 4-bit SD cards. I think someone mentioned that issue early on in this thread years ago.

Nice work!

I'm getting my Chumby & Infocasts out of deep hibernation. Attempting to get this going on my Infocast8, but its hitting a wall. Complaining about not finding " /boot/uboot.env" & " unable to read from /mmc 0:2."

I followed your steps for setting up the environment, but it fails to set up successfully.

Any ideas as how to proceed?

Thanks!

  • Registered: 2022-07-10
  • Posts: 9

Re: Newer kernel for silvermoon

i got similar problem early, I solved it by exchange a new SD card. I have I8. Good luck!

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

Glad to see more people trying this out! Welcome to the club sol.soul! smile Like Infocast008 said, that sounds like a problem with the SD card -- assuming you are following the instructions I listed in this post:

https://forum.chumby.com/viewtopic.php?pid=58764#p58764

...and have used "dd" to copy the resulting sdcard.img to the SD card. I haven't had any problems using the stock 2 GB card that came with the Infocast 8 that I bought, for what it's worth. (I backed up the SD card contents first just to be safe...)

Couple other tidbits since my last post. I figured out a better way to fix the "top" issue and submitted a kernel patch upstream to fix it. Also fixed the flooding of DMA error messages at startup and submitted that patch upstream. Additionally...I figured out why we get the weird characters printed at startup on the Infocast. It's because the SPI flash chip used for initial boot (not present on the Chumby 8) is wired to the same RX/TX pins used by the console UART. So the raw SPI flash chip communication gets sent out the TX pin to the console.

I want to figure out a way to back up those SPI flash chip contents just to be safe. It'll be a little tricky because some of the SPI pins are shared with the console UART. Not a priority by any means, just would be nice to have in case someone's boot SPI flash chip gets corrupted somehow.

60 Reply by sol.soul (edited by sol.soul 2022-09-07 15:13:41)

  • Registered: 2022-09-06
  • Posts: 5

Re: Newer kernel for silvermoon

Hi all,

Switched to another SD & making progress. Now I'm attempting to get Chumby8TSCsal, but getting error after "buildroot/output/host/bin/qmake make -j $(nproc)". Stating unknown option -j. I'll keep playing around & guess I have more reading to do.

[edited a bit later...]

Got Chumby8TSCal to complete. Now to figure out the easiest way to get it on the Infocast.

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

Yeah...the qmake and make are 2 separate commands (and the qmake command ends in "..")

You could either remove the SD card and copy it over (gets tedious very quickly) or copy it over WiFi if you connect to your WiFi network with nmcli, I think I talked about that in a previous post in the thread somewhere. Then you can SSH things to the Infocast assuming you remount the rootfs as read-only beforehand. Unless you generate permanent host keys, the host keys will change on every boot which will cause annoying SSH errors. Can't remember exactly how I generated the keys to be honest.

  • Registered: 2022-09-06
  • Posts: 5

Re: Newer kernel for silvermoon

Yeah I was able to connect via ssh , but got some errors and was disconnected right away. I was also not able to mount & browse the sd card as usual.

I'll give it another go tonight.

63 Reply by dougg3 (edited by dougg3 2022-09-18 17:16:21)

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

Huge update for this weekend. I have finally gotten everything into a position where I can publish all of the changes for getting the 2D GPU working! Plus, u-boot now has a default environment so it will boot up immediately without any fiddling inside of u-boot.

You will definitely want to do a full clean and rebuild of buildroot because of everything I've changed. It now uses X11 under the hood. I wasn't thrilled about bringing in X11 as a dependency, but it's the only way that currently exists to make use of the 2D GPU. I've also changed Chumby8TSCal to work correctly with this new setup. It's now generating a config file for X11's xf86-input-libinput plugin, which means the touch calibration will be loaded automatically at every boot.

It's all the same basic principle for building buildroot. If you have an old checkout, do this:

make clean; git pull

If you don't have a checkout yet, git clone it instead. Then, either way, here are the build commands:

make chumby8_defconfig
make

Then use dd to copy the resulting sdcard.img to an SD card. Friendly reminder that you need the UART header soldered on with a USB serial adapter in order to get console access to actually be able to do anything, this is all just experimental dev stuff.

Summary of changes:

  • u-boot has a default environment now, so it'll fully boot without fiddling in u-boot. If you get an error about "File not found /boot/uboot.env" that is completely normal now. It checks for the file in case you've made a custom environment and saved it with the saveenv command.

  • I changed the boot splash screen to the default chumby boot splash image. The colorful screen was there to help me make sure I had the LCD controller configured correctly, but now I can go back to a normal chumby splash.

  • Now uses X11 with the native Linux driver for the PXA168's LCD controller and has the 2D GPU enabled

  • Now has mpv installed so you can play (smaller) videos. Example command: mpv --fs myvideo.avi

  • I'm now running the LCD at exactly 60 Hz. Previously it was a lower refresh rate that matched the stock Chumby kernel.

  • Fix for incorrect CPU usage reported with top

  • Fix for a bunch of DMA errors printed at startup

  • Due to the change to X11, the screen does go black at startup until you run a program that displays something.

I may need to get a window manager running in order to make the display do something when X runs...not sure yet. But as soon as you run a Qt program or mpv or whatever, something will show up on the screen. It would be nice if I could change the X default to be a white instead of black screen when it loads...Edit: I got it to do a white screen now by adding the -wr option to Xorg. Unfortunately it does flash black for a brief moment still. I'm not sure if that's avoidable at all.

The last thing I wanted to mention is my GC300 2D GPU fixes are on their way to being in the mainline kernel. Kudos to the etnaviv maintainers/community for reviewing and accepting my patches! I haven't had much of a response on any of my other patches for PXA168 stuff. It might be kind of tricky to get all of this stuff into the mainline kernel but I'm going to try to get as much of it as possible.

  • Registered: 2022-09-06
  • Posts: 5

Re: Newer kernel for silvermoon

dougg3 wrote:

Huge update for this weekend. I have finally gotten everything into a position where I can publish all of the changes for getting the 2D GPU working! Plus, u-boot now has a default environment so it will boot up immediately without any fiddling inside of u-boot.

make clean; git pull

If you don't have a checkout yet, git clone it instead. Then, either way, here are the build commands:

make chumby8_defconfig
make

I tried to build your latest, but it failed to output an sd image. It states that python built successfully, but halts to this:

Failed to build these modules:
fcntl                                                       

make[2]: *** [Makefile:639: sharedmods] Error 1
make[1]: *** [package/pkg-generic.mk:292: /home/buildroot/output/build/host-python3-3.10.2/.stamp_built] Error 2
make: *** [Makefile:84: _all] Error 2

No issues with previous builds on this system. I'll try again later when I have a bit more time.

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

Weird! What Linux distro and version are you using? I've tested on Ubuntu 20.04 and 18.04 and can't reproduce...it's likely some kind of buildroot strangeness.

  • Registered: 2022-09-06
  • Posts: 5

Re: Newer kernel for silvermoon

dougg3 wrote:

Weird! What Linux distro and version are you using? I've tested on Ubuntu 20.04 and 18.04 and can't reproduce...it's likely some kind of buildroot strangeness.


I'm using Mint 21 "Vanessa.' I think I have 18.04 system somewhere so I'll give it a shot on that one soon.

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

Interesting! I just set up a Mint 21 VM and tested building from scratch. I can't reproduce the error you ran into. I had to install git and build-essential in order to get everything going, and then I had to install libssl-dev about 3/4 of the way through in order to get past an error with u-boot I think. But other than that, no problems at all. Strange...

BTW, I just pushed another commit that changes the Linux fetch process to grab a tarball from GitHub instead of cloning my entire linux repository. I realized that was taking forever (and downloading a lot of data) and the tarball should be a lot faster.

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

I'm going to briefly go to a slightly different topic unrelated to Linux/buildroot/etc. Tonight I wrote a quick utility to dump the contents of the SPI NOR flash boot chip (U105) on the Infocast 8 (not present on the Chumby 8 because the B0 stepping fixes the SD bootability issue). I figured it would be good to have a dump of this chip's contents just in case I screw something up in the future, because the Infocast depends on it for booting.

I bit-banged the SPI commands in userspace to make it simple, rather than dinking around with the kernel. This requires temporarily changing a few pin functions because the UART and SPI boot flash share some of the same pins.

The schematic says the part number is: EN25P05 (64 kilobyte flash) but when I read the ID it actually identified as EN25F10 which is 128 KB flash. I was too lazy to look at the actual marking on the chip. Anyway, I dumped the entire chip and the contents end at around 50 KB into the chip (the rest is filled with 0xFF).

The file content is actually almost identical to the obm.bin that my buildroot sticks onto the start of the SD card for SD booting, with a few minor changes I will document here:

The bytes at 0x28 through 0x2b are "0a 4e 41 4e" (NAN\x0A) instead of "08 43 4d 4d" (MMC\x08). This is a little confusing because the reference manual that explains the boot ROM doesn't list "NAN'0A" as an option. However, I did notice that it lists "SPI'0A" as an option, and the "first byte" number is unique for each option. I suspect the boot ROM only looks at that first byte (0x0a for SPI, 0x08 for MMC3, etc.) and the other 3 are just unused display values to make it easy to read in a hex editor or something. Technically it's supposed to be SPI\x0A instead of NAN\x0A, but I guess it doesn't actually matter.

The byte at 0x7D is 0x20 instead of 0x18. This indicates that the offset of image 2 in the OBM file is 0x2000 instead of 0x1800.

Finally all of the contents of obm.bin starting at 0x1000 (which is image 2) actually start at 0x2000 instead. In other words, at 0x1000, an additional 0x1000 bytes of 0x00 get inserted first. This matches the offset change above. It's kind of hard to explain the 0x800 difference, but it's because obm.bin starts at 0x800 on the physical SD card, so the offset 0x1800 really only represents an offset of 0x1000 in the file. SPI flash boot doesn't have this pecularity so 0x2000 is actually 0x2000.

One final thing that is barely worth mentioning -- the final 0x200 bytes of obm.bin are all 0x00, but they are 0xFF in the SPI flash chip. And then the SPI flash chip continues with 0xFFs for the rest of the chip contents. I believe these contents don't matter at all.

Anyway I have no idea if this info will ever be useful to anybody out there in the future, but it should provide enough info to re-create the Infocast 8's SPI flash contents if something goes bad.

  • Registered: 2022-07-10
  • Posts: 9

Re: Newer kernel for silvermoon

Dougg3, thanks, this info helps a lot. I always curious about the obm.bin. Where did you get it from?
Also, I couldn't find the schematic you refer to (for C8 or I8). Do you mind upload the schematic file and reference manual(link file missing)? Thanks.

70 Reply by dougg3 (edited by dougg3 2022-09-24 22:30:06)

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

Hey Infocast008,

You can find obm.bin at the very beginning of partition 1 of the stock SD card. My buildroot downloads it from GitHub here and inserts it into the SD card image:

https://github.com/sutajiokousagi/meta- … silvermoon

From what I can tell this is some kind of proprietary Marvell thing that was customized a bit by Chumby. I never was able to find the source for it. aspenix-1.0 at the Chumby source page looks very similar, but definitely not the same thing. For what it's worth, I don't think obm.bin on the SD card is even necessary on the Infocast 8. I'm reasonably sure that the SPI flash chip is doing what obm.bin would do. But the Chumby 8 definitely needs it.

The schematic is here:
http://files.chumby.com/hdwedocs/silver … ref_v3.pdf

The reference manuals for the PXA168 are linked in the Linux documentation. These have been super helpful. They are no longer available on Marvell's site, but the Linux docs now point to archive.org instead. See the PXA168 section:

Edit: I pushed some auto time sync stuff today. The Chumby 8 doesn't really have an "RTC" per se, so I disabled the PXA168 RTC driver. The CR2032 battery actually goes to the STM32 cryptoprocessor. The cryptoprocessor provides a "seconds since boot" counter that can be effectively used as an RTC to keep time while the system is powered off. I copied the approach the stock firmware followed to read the cryptoprocessor's counter and turn it into a usable date/time. My firmware now bundles the Chumby "cpi" utility for interacting with the coprocessor. It also has ntpd enabled so that it'll automatically sync the time if it has an internet connection.

I think I'm about at the point where there's nothing left to do for the C8/I8, other than fix little bugs as they pop up, keep it rebased on top of new kernel versions as they come out, and start making some cool apps to run on the custom firmware! I leave that to everyone's individual preferences to figure out what they want to do with this. I don't have any plans on making a "standardized" Chumby firmware -- but the building blocks are now there for anybody who wants to play with it.

If someone gets the urge, it might be possible to adapt the IPP libraries in gst_pxa168-1.0.tgz (on the Chumby source page I linked) to accelerate video and audio decoding in gstreamer or something like that. The PXA168 doesn't have any hardware video/audio decoders, but it does have a WMMX2 SIMD coprocessor. My understanding is the IPP libraries use the coprocessor to help speed up decoding. They're Marvell proprietary libraries (no source available) and I have no idea how tricky it would be to use them with modern stuff. But the libraries and headers are definitely in that tgz file.

Oh, one other thing -- a while ago I was worried that the new libertas-sdio WiFi driver was way too slow. It turns out it's now faster than the Marvell WiFi driver bundled with the original firmware. I think it was slower while I had debugging stuff turned on. As long as I have power save disabled, which I do in my firmware, the libertas driver is faster than the stock Chumby driver. With power save enabled, it seems to be roughly the same (so power save is probably enabled on the Marvell driver too).

Every once in a blue moon, when I boot up, the WiFi doesn't work. There's some kind of SDIO communication corruption while it's detecting the SDIO card or something. An error pops up in dmesg about it. It only happens every 50 boots or so...no idea what the problem is. It happens so infrequently that I can't even try to fix it because it's really hard to reproduce. If you ever see it happen, just reboot and it'll be fine on the next boot. Maybe someday I can get to the bottom of it.

  • Registered: 2022-07-10
  • Posts: 9

Re: Newer kernel for silvermoon

Thanks for sharing! It helps a lot, I can go into some details with this schematic and manuals.
I successfully build the new buildroot(posted at 2022-09-18 18:51:53 ) and writing to SD card. It boots to new splash screen but I got some errors, it rebooting every few seconds.
I am using Ubuntu 22.04.1 LTS.
Here are the debug info from serial port cable. Any idea? Thanks.

Total times UART was inited: 0x00000001

Total wait loops iterated: 0x000022B3

Hello world, I'm the most incredibly annoying boot process you'll ever meet!

key waiting

done with key wait

key waiting2

flash boot attempt

loading OS loader

chumby!

disableIRQ

setupxfer

levelling up...



U-Boot 2021.10 (Sep 25 2022 - 01:59:05 -0400)
Chumby 8

SoC:   Armada 88AP168-A0
DRAM:  128 MiB
MMC:   mv_sdh: 0
Loading Environment from EXT4... ** File not found /boot/uboot.env **

** Unable to read "/boot/uboot.env" from mmc0:2 **
In:    serial@d4017000
Out:   serial@d4017000
Err:   serial@d4017000
Hit any key to stop autoboot:  1  0
1440054 bytes read in 264 ms (5.2 MiB/s)
3923704 bytes read in 700 ms (5.3 MiB/s)
11026 bytes read in 16 ms (672.9 KiB/s)
## Booting kernel from Legacy Image at 01000000 ...
   Image Name:   Linux-5.18.9
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3923640 Bytes = 3.7 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02000000
   Booting using the fdt blob at 0x2000000
   Loading Kernel Image
   Loading Device Tree to 07996000, end 0799bb11 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.18.9 (fred@fred-MS-7641) (arm-linux-gcc.br_real (Buildroot toolchains.bootlin.com-2021.11-1) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #1 PREEMPT Sun Sep 25 02:18:58 EDT 2022
[    0.000000] CPU: Marvell 88SV331x [56158400] revision 0 (ARMv5TE), cr=0005397f
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] OF: fdt: Machine model: Chumby Industries Chumby 8
[    0.000000] printk: debug: ignoring loglevel setting.
[    0.000000] Memory policy: Data cache writeback
[    0.000000] cma: Reserved 8 MiB at 0x07000000
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000005ffffff]
[    0.000000]   node   0: [mem 0x0000000006000000-0x0000000006ffffff]
[    0.000000]   node   0: [mem 0x0000000007000000-0x0000000007ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 32512
[    0.000000] Kernel command line: console=ttyS0,115200 ro ignore_loglevel rootwait root=/dev/mmcblk0p2
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 94672K/131072K available (7168K kernel code, 211K rwdata, 1344K rodata, 1024K init, 120K bss, 28208K reserved, 8192K cma-reserved)
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000]     Trampoline variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] Not found marvell,tauros2-cache, disable it
[    0.000000] Tauros2: Disabling L2 prefetch.
[    0.000000] Tauros2: Disabling burst8 line fill.
[    0.000000] Tauros2: Enabling L2 cache.
[    0.000000] Tauros2: L2 cache support initialised in ARMv5 mode.
[    0.000005] sched_clock: 32 bits at 3250kHz, resolution 307ns, wraps every 660764198758ns
[    0.000067] clocksource: clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 588080137591 ns
[    0.000690] Console: colour dummy device 80x30
[    0.000753] Calibrating delay loop... 795.44 BogoMIPS (lpj=3977216)
[    0.040264] pid_max: default: 32768 minimum: 301
[    0.040621] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.040664] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.041396] CPU: Testing write buffer coherency: ok
[    0.043717] cblist_init_generic: Setting adjustable number of callback queues.
[    0.043754] cblist_init_generic: Setting shift to 0 and lim to 1.
[    0.044100] Setting up static identity map for 0x100000 - 0x100058
[    0.044445] rcu: Hierarchical SRCU implementation.
[    0.045301] devtmpfs: initialized
[    0.050905] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.050960] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.051889] pinctrl core: initialized pinctrl subsystem
[    0.054126] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.056112] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.059826] thermal_sys: Registered thermal governor 'step_wise'
[    0.070518] platform panel: Fixing up cyclic dependency with d420b000.lcd-controller
[    0.084936] SCSI subsystem initialized
[    0.085319] usbcore: registered new interface driver usbfs
[    0.085425] usbcore: registered new interface driver hub
[    0.085517] usbcore: registered new device driver usb
[    0.086339] i2c i2c-0:  PXA I2C adapter
[    0.087043] i2c i2c-1:  PXA I2C adapter
[    0.087263] pps_core: LinuxPPS API ver. 1 registered
[    0.087289] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.087339] PTP clock support registered
[    0.088509] clocksource: Switched to clocksource clocksource
[    0.104677] NET: Registered PF_INET protocol family
[    0.105112] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.106198] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[    0.106261] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.106293] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.106334] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.106371] TCP: Hash tables configured (established 1024 bind 1024)
[    0.106500] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.106548] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.106823] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.107795] RPC: Registered named UNIX socket transport module.
[    0.107830] RPC: Registered udp transport module.
[    0.107847] RPC: Registered tcp transport module.
[    0.107863] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.108664] Initialise system trusted keyrings
[    0.109577] workingset: timestamp_bits=30 max_order=15 bucket_order=0
[    0.111311] NFS: Registering the id_resolver key type
[    0.111436] Key type id_resolver registered
[    0.111459] Key type id_legacy registered
[    0.111708] Key type asymmetric registered
[    0.111735] Asymmetric key parser 'x509' registered
[    0.111893] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    0.111923] io scheduler mq-deadline registered
[    0.111944] io scheduler kyber registered
[    0.112763] pxa-usb-phy d4206000.usb-phy: Marvell PXA USB PHY
[    0.113586] pinctrl-single d401e000.pinctrl: 128 pins, size 512
[    0.121355] gpio-94 (sdhci2_cmd): hogged as output/high
[    0.129584] pxa-dma d4000000.dma-controller: initialized 32 channels on 100 requestors
[    0.130249] d4017000.serial: ttyS0 at MMIO 0xd4017000 (irq = 43, base_baud = 921600) is a UART1
[    0.688323] printk: console [ttyS0] enabled
[    0.693123] d4026000.serial: ttyS2 at MMIO 0xd4026000 (irq = 45, base_baud = 921600) is a UART3
[    0.707009] at24 0-0050: supply vcc not found, using dummy regulator
[    0.715412] at24 0-0050: 1024 byte 24c08 EEPROM, writable, 1 bytes/write
[    0.723743] usbcore: registered new interface driver asix
[    0.729366] usbcore: registered new interface driver ax88179_178a
[    0.735532] usbcore: registered new interface driver cdc_ether
[    0.741489] usbcore: registered new interface driver net1080
[    0.747215] usbcore: registered new interface driver cdc_subset
[    0.753257] usbcore: registered new interface driver zaurus
[    0.759043] usbcore: registered new interface driver cdc_ncm
[    0.764719] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.771607] phy phy-d4206000.usb-phy.0: initializing Marvell PXA USB PHY
[    0.779518] mv-ehci d4209000.usb: EHCI Host Controller
[    0.784709] mv-ehci d4209000.usb: new USB bus registered, assigned bus number 1
[    0.792594] mv-ehci d4209000.usb: irq 67, io mem 0xd4209000
[    0.818596] mv-ehci d4209000.usb: USB 2.0 started, EHCI 1.00
[    0.825451] hub 1-0:1.0: USB hub found
[    0.829377] hub 1-0:1.0: 1 port detected
[    0.834001] mv-ehci d4209000.usb: successful find EHCI device with regs 0x(ptrval) irq 67 working in Host mode
[    0.844704] usbcore: registered new interface driver uas
[    0.850288] usbcore: registered new interface driver usb-storage
[    0.857539] sa1100-rtc d4010000.rtc: registered as rtc0
[    0.863018] sa1100-rtc d4010000.rtc: setting system clock to 1970-01-01T00:00:00 UTC (0)
[    0.871339] i2c_dev: i2c /dev entries driver
[    0.876318] chumby8-poweroff d4026000.reset: Chumby 8 reboot driver registered
[    0.884053] sdhci: Secure Digital Host Controller Interface driver
[    0.890296] sdhci: Copyright(c) Pierre Ossman
[    0.895242] mmc1 bounce up to 128 segments into one, max segment size 65536 bytes
[    0.903227] sdhci-pltfm: SDHCI platform and OF driver helper
[    0.909455] mmc0 bounce up to 128 segments into one, max segment size 65536 bytes
[    0.918099] usbcore: registered new interface driver usbhid
[    0.925554] usbhid: USB HID core driver
[    0.929809] NET: Registered PF_PACKET protocol family
[    0.935027] Key type dns_resolver registered
[    0.939511] XScale iWMMXt coprocessor detected.
[    0.944150] Loading compiled-in X.509 certificates
[    0.958611] mmc0: SDHCI controller on d427e000.sdhci [d427e000.sdhci] using DMA
[    0.966086] mmc1: SDHCI controller on d4281000.sdhci [d4281000.sdhci] using DMA
[    0.980248] armada-drm armada-drm: bound d420b000.lcd-controller (ops 0xc082c400)
[    0.989239] [drm] Initialized armada-drm 1.0.0 20120730 for armada-drm on minor 0
[    0.997676] Waiting for root device /dev/mmcblk0p2...
[    1.020284] mmc1: new SDIO card at address 0001
[    1.031849] mmc0: new high speed SD card at address 0001
[    1.038160] mmcblk0: mmc0:0001 00000 1.89 GiB
[    1.045506]  mmcblk0: p1 p2
[    1.060138] EXT4-fs (mmcblk0p2): bad geometry: block count 409600 exceeds size of device (204800 blocks)
[    1.070478] EXT2-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (240)
[    1.083820] List of all partitions:
[    1.087340] b300         1982464 mmcblk0
[    1.087360]  driver: mmcblk
[    1.094316]   b301            9216 mmcblk0p1 00000000-01
[    1.094339]
[    1.101244]   b302          204800 mmcblk0p2 00000000-02
[    1.101265]
[    1.108102] No filesystem could mount root, tried:
[    1.108115]  ext3
[    1.113124]  ext4
[    1.115065]  ext2
[    1.116991]  cramfs
[    1.118991] usb 1-1: new high-speed USB device number 2 using mv-ehci
[    1.127598]  msdos
[    1.127612]
[    1.131327] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)
[    1.139779] CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.9 #1
[    1.145541] Hardware name: Marvell PXA168 (Device Tree Support)
[    1.151462] Backtrace:
[    1.153927]  dump_backtrace from show_stack+0x18/0x1c
[    1.159044]  r7:c08b803c r6:c0b06af8 r5:00000000 r4:c08c6628
[    1.164712]  show_stack from dump_stack+0x28/0x30
[    1.169451]  dump_stack from panic+0x10c/0x304
[    1.173926]  r5:00000000 r4:c0b36880
[    1.177516]  panic from mount_block_root+0x20c/0x248
[    1.182523]  r3:00000000 r2:00000000 r1:c8809e94 r0:c08b803c
[    1.188194]  r7:c0f3001c
[    1.190735]  mount_block_root from mount_root+0x1fc/0x248
[    1.196172]  r10:c0b35028 r9:c094e3cc r8:c0a27834 r7:0b300002 r6:00000008 r5:c0a27864
[    1.204019]  r4:00000002
[    1.206560]  mount_root from prepare_namespace+0x134/0x18c
[    1.212083]  r10:c0b35000 r9:c094e3cc r8:c0a27834 r7:c0a27854 r6:00000008 r5:c0a27864
[    1.219931]  r4:c0b35028
[    1.222472]  prepare_namespace from kernel_init_freeable+0x1bc/0x1f8
[    1.228857]  r5:c0c14320 r4:c0b04ef0
[    1.232446]  kernel_init_freeable from kernel_init+0x18/0x134
[    1.238237]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c06fb5d8
[    1.246076]  r4:00000000
[    1.248618]  kernel_init from ret_from_fork+0x14/0x2c
[    1.253697] Exception stack(0xc8809fb0 to 0xc8809ff8)
[    1.258770] 9fa0:                                     00000000 00000000 00000000 00000000
[    1.266967] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.275162] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    1.281790]  r5:c06fb5d8 r4:00000000
[    1.285390] Rebooting in 5 seconds..

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

Hmm...everything looks normal up to the point of these messages:

[    1.060138] EXT4-fs (mmcblk0p2): bad geometry: block count 409600 exceeds size of device (204800 blocks)
[    1.070478] EXT2-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (240)

These don't show up on a normal boot when everything's working correctly. It appears that it's trying to mount as ext4 and failing because of "bad geometry", and then it tries falling back to ext2 instead, but that fails because it's really an ext4 partition. So the real error is the "bad geometry" error. This seems like a filesystem corruption issue. I know you've run into issues with this previously too -- how are you writing sdcard.img to the card? A couple of pointers that I would recommend:

  • To anyone who reads this: be very careful with the commands below; if you type the wrong "sdx" device, you could corrupt your hard drive. On my machine, my main boot SSD is sda and the SD card is sdb. If you have multiple hard drives, the card might be sdc or sdd or even higher. You should be able to use "dmesg" after plugging in the SD card to see its device name.

  • Ubuntu is going to auto-mount any existing partitions on the card when you plug the card into your computer. Make sure you unmount them first before re-flashing the card because it could get confused. The eject button in Ubuntu will probably fully eject the card which you don't want to do, so use umount instead, e.g.: umount /dev/sdx2 (where sdx is the SD card's device name)

  • After all partitions are unmounted, use dd to flash the card: sudo dd if=sdcard.img of=/dev/sdx

  • After dd completes, type "sync" to make sure everything has been written to the card. I'm paranoid and run "sync" a few times.

  • Then I cleanly eject by typing sudo eject /dev/sdx

Here is what my boot output at the same point looks like with my stock Infocast 8 card:

[    0.998814] mmc0: new SD card at address f259
[    1.004480] mmcblk0: mmc0:f259 SU02G 1.84 GiB 
[    1.010351] mmc1: new SDIO card at address 0001
[    1.019874]  mmcblk0: p1 p2
[    1.058483] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Quota mode: disabled.
[    1.067439] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.

Unless there's a physical problem with the SD card, I'd be willing to bet that following the steps above will get everything up and running again...hope this helps!

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

I actually forgot one more thing I wanted to take care of: the card detect pins for the built-in SD/XD/MS/CF card reader. I just pushed a new buildroot update that handles them.

When you boot without any cards plugged into the card reader ports, a dummy "/dev/sda" device shows up. This is kind of weird. The original Chumby kernel added some icky hacks in the usb-storage driver to monitor the card detect pins and disable the card reader so it wouldn't pop up an empty sda device.

It took some brainstorming, but I figured out a slightly cleaner approach. u-boot's default Linux command line now adds a quirk to tell the usb-storage driver to ignore the card reader (by looking at its USB product and vendor IDs). Then, a userspace daemon that I wrote automatically loads at startup. It monitors the card detect pins and updates the USB connected/disconnected state automatically. Seems to work great!

74 Reply by dougg3 (edited by dougg3 2022-10-23 09:23:15)

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

Pushed some new stuff today. buildroot now creates a third partition on the SD card for settings, which is kept mounted read/write at all times (/mnt/settings). The touchscreen calibration, NetworkManager connections, "simulated RTC" date/time, and dropbear SSH keys are all kept on this partition. This should be a lot more convenient than having to remount read/write all the time when changing stuff. I also added Chumby8TSCal as part of the build process so it's always available as a program to run.

I'm pretty happy with where this is now!

P.S. several of my kernel patches from June were approved into the clk-next tree today, so those patches are on their way to being mainlined. This is a great stepping stone because it will enable me to start submitting more of my kernel fixes to mainline.

Edit: I made a few dependency mistakes on my last commits, which caused buildroot to fail to build. I pushed some fixes for this.

  • Registered: 2013-11-30
  • Posts: 36

Re: Newer kernel for silvermoon

I'm still making progress on getting as much of this stuff submitted to the upstream kernel as I can. It's a bit of a weird process because the PXA168 is an old chip and doesn't really have an active maintainer anymore. Luckily most of the changes are for different subsystems, like PWM, MMC/SDHC, SPI, etc. It has definitely been a learning experience!

I just got everything rebased on top of kernel 6.0.9 and pushed a new commit to buildroot to use that by default now.