Re: Newer kernel for silvermoon

This is sort of reviving a dead thread (but what's not these days sad ), but I've been following the work you all have done and it's amazing!  I've recently picked my chumby up again with hopes of reviving it in, to me, a more usable form.  I so far have compiled the kernel and gotten Archlinux running pretty well, except there's no physical screen activity (only ttyS0) (kind of a problem for usability) and there's no wifi. I understand there was stuff with the wifi driver, but I'm not sure I quite understand how it works nor do I "see" it in linux.  I'm not sure where to even look for a new adaptor past ifconfig -a.  I'd look into the schematics, but I can't seem to find them online (404).  Are those still somewhere?

Additionally, I don't know how to modify u-boot.  The only things I can find online for it are OE.  Okay, but I can't actually build any of that stuff because it's too old.  I did manage to find a half-baked version I had made with a u-boot.bin.  This is all great, but really all I want to do is change the bootcmd environment variable, no?  Also, ext2load/fs fails to correctly read an ext3 partiton that was not part of the original image (just says it's empty), so I'm just using the second chumby partition to hold the kernel, and then I direct it to a new, third partition with Arch. I'm not very versed in bootloaders and the documentation for this case is pretty sparse.

I guess I'm just here asking if anyone knows where to go from here and to say that Chumbies aren't dead yet.  Sure I may not be using the service, but I'd really like to get the hardware working.

Re: Newer kernel for silvermoon

presumably, you've been through: … for_chumby

Cleaning up any loose bits and bytes.

28 (edited by mark005 2016-06-28 08:53:00)

Re: Newer kernel for silvermoon

Yes, I've got a 3.13-rc3 kernel up and running.  I'd like to find a way to boot straight into the kernel without having to interrupt u-boot.  It looks like it tries to load krnA or krnB depending on whether it's a recovery boot or not, both are offset in the kernel image somewhere?  Just subbing in vmlinuz doesn't boot.  I have to interrupt the bootup and run

ext2load mmc 0:2 ${default_load_addr} /boot/zImage 
bootz ${default_load_addr}

where zImage is the kernel image I compiled (works with vmlinuz as well, but it seems to have to be compressed, i.e. not vmlinux).  I have deleted every file off the old second partition except the boot directory and then for by bootargs I have (among other things)

 root=/dev/mmcblk0p3 init=/bin/init 

.  I don't particularly want to go poking around in the first partition with a hex editor if I don't have to, but I've got backups.  Also, what's so special about the stock second partition that makes it readable by u-boot, but not a new ext3 partition?

29 (edited by mark005 2016-05-23 09:03:33)

Re: Newer kernel for silvermoon

Progress update:  I installed X and it works out of the box (except the touch screen.  I didn't have time to test it before, but I'm still trying to figure that out).

Re: Newer kernel for silvermoon

Well I've gotten it to a state where I think any more work is more than it's worth.  For documentation purposes, I did the following.  I edited the bootloader with a hex editor and it seems to have worked, but now when I drop to a u-boot command line, most of the commands, when passed arguments, say that the command is undefined.  Since it boots automatically with no problems, though, I'm done messing with it (It's the same length, too.  I don't know what happened).  As for the kernel, I wasn't able to forward port any more, despite trying.  Shutdown/reboot don't work (I get an error from serial/pxa.c saying that it would send the command and get a response of 00 and after several tries it errors out and halts).  Sound: it seems to load the kernel module, wm8961, but I can't seem to be able to get the driver to talk to de device, but this may be my own lack of how the ASoC system works.  This is the closest thing on the internet I could find, but I can't seem to figure it out.  I just bought a USB sound adaptor, and that works just fine.  I tried changing wm8961 to wm8960 and wm8962 in the source code, but they don't seem to be drop in replacements (both of those seem to have much better support in the kernel).  As for networking, I couldn't get the libertas_sdio card inside to work, so I just use a wifi dongle (be careful if you get one, the 3.13 kernel does not support the mt7601u chipset out of the box (though there are drivers online to compile yourself) and many more.  Do research before buying).  I also tried a bit to get the touchscreen working but soon realized what a rabbit hole that was and stopped before it had eaten a solid week of my time.  Additionally, I tried, but failed at, getting the pwm backlight to work.  Other than that it seems to be working.  I did encounter swapped red/blue (which no one else on the internet seems to have?), but I solved it by changing the .panel_rbswap variable to 1 in the pxa168fb_mach_info chumby8_lcd_info struct.  I don't know who's interested in any of this in this thread (you all seem so much more knowledgeable than I), but I hate it when there's a thread on the internet with no conclusion or closure.

Re: Newer kernel for silvermoon

Thank you for the followup.

Cleaning up any loose bits and bytes.

Re: Newer kernel for silvermoon

Thanks for the follow-up!

mark005 wrote:

I hate it when there's a thread on the internet with no conclusion or closure.

Here! Here!  Even if there are people here more knowledgeable than you, (Duane, that's you), you've actually done the work and even managed to come back and share what you've done.  That helps those of us that may do something similar in the future.

Linux Guy - Occasional Chumby Hacker

Re: Newer kernel for silvermoon

mark005 wrote:

I did encounter swapped red/blue (which no one else on the internet seems to have?), but I solved it by changing the .panel_rbswap variable to 1 in the pxa168fb_mach_info chumby8_lcd_info struct.

Here's a reference to that for you from just over 6 years ago smile . I had ran into that on some of the earlier projects that were built. I also had quite a bit of fun trying to get the original toolchain to build a properly booting kernel for the Insight8, but that was many years ago at this point shortly after its release.

It's great to hear that you've made as much progress as you have! It's still a really great hardware platform to work with and since I've come across mine I believe I am going to whip up a modular remote for the RaspPI. And no matter what, someone that is out there somewhere will come across your post and find it interesting or very useful. It may just take a while.

34 (edited by dougg3 2022-05-07 12:30:41)

Re: Newer kernel for silvermoon

It's been over 8 years since my original post here about trying to get the Chumby 8 running with a newer kernel. I still haven't given up on this; it's just taken a while to find time. I'm not sure if people are still using their silvermoon devices these days -- it has aged quite a bit and 128 MB of RAM isn't much, but I had a hankering to continue on with this recently, mainly as a personal "board bringup" challenge.

My latest progress over the last week doesn't directly involve the kernel at all. I actually decided to get the Chumby 8 working with a modern u-boot version first, for a number of reasons: it's more likely that a modern Linux kernel will be able to boot successfully if we have a modern bootloader available to boot it, I wanted everything to be based on a device tree, and I also wanted to be able to generate a full SD image from scratch using as few binary blobs as possible. Also as a personal preference, I wanted to integrate it with buildroot because that's the environment I'm most comfortable in.

Sadly, support for the PXA168 was recently removed from u-boot due to not meeting a deadline for updating the aspenite board file, so I had to base it on version 2021.10 which is the last version that supported it. I have actually succeeded at this! It involved a lot of SD card swapping, frustration, and a lot of experimentation, but I have a basic Chumby 8 u-boot build working. It has UART, SD card, and LCD support. It also talks to the coprocessor to allow the reboot and poweroff commands to behave properly. My changes are here on GitHub:

This is still a work in progress -- the biggest thing left to do is figure out how to get a chunk of code from the old u-boot working -- it reconfigures the PLLs and changes the DDR RAM settings. It seems to work okay without it, but I'm sure the original engineers did it for a reason, and I want to match that configuration. It's complicated and hacky because it loads a function into SRAM, jumps into it, and reconfigures the DDR RAM that u-boot is running from, so integrating it with the new u-boot may take some work. I also have no idea if it works on other silvermoon-type devices. I'm specifically targeting the Chumby 8, because that's what I have to test with.

I haven't actually tested trying to boot any kind of a kernel with this yet, but it should work if someone sets all the proper environment variables. It definitely won't work with a stock chumby kernel because I've changed the machine ID to match the number that was added to the machine ID registry for silvermoon, which doesn't match what was actually used in the old silvermoon kernel. But you could change this pretty easily for testing.

But how do you test/use this new u-boot? Turns out I also created a branch of buildroot that automatically creates a bootable SD card image from scratch, that includes u-boot. It also builds a small root filesystem, but doesn't yet have a kernel so it can't boot into it.

This was also a little tricky. I had to figure out how to get the binary bootloader blob (obm.bin). I also had to look at it a bit deeper and figure out where/how it loads u-boot, so I could figure out how to arrange the generated SD card image. But I got it working, and it boots up to a u-boot prompt. I'm pretty happy with it because the only binary blob it depends on is that obm.bin file, and buildroot automatically downloads it for you. Everything else is automatically downloaded and built from scratch by buildroot. Here's how to test it:

git clone -b chumby
cd buildroot
make chumby8_defconfig

You should eventually end up with a successful build. The final binary is a file called sdcard.img in the "output/images" subdirectory. You can dd this image to an SD card and boot a Chumby 8 with it. It won't be useful unless you've soldered on the UART header and have a USB to TTL serial adapter. Anyway, if you've got that all set up like me, you'll end up with a Chumby boot prompt:

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

U-Boot 2021.10 (May 06 2022 - 19:03:09 -0700)
Chumby 8

SoC:   Armada 88AP168-B0
DRAM:  128 MiB
MMC:   mv_sdh: 0
Loading Environment from nowhere... OK
In:    serial@d4017000
Out:   serial@d4017000
Err:   serial@d4017000

You can test the LCD and SD card by running the following command in u-boot to load a BMP image from the generated ext4 filesystem and display it on the screen:

ext4load mmc 0:2 0x1000000 /boot/testsplash.bmp ; bmp display 0x1000000

That's all I have for now! After I figure out the PLL/DDR reconfiguration stuff, I think I can start focusing on trying to get a modern kernel booting. I can't make any promises about how soon I'll be able to look at it though! As others have pointed out above, it's a long and complicated process to get every peripheral working. A lot of the stuff doesn't have mainline support, and a lot of it is super custom chumby stuff so it's more complicated than just "create a dts file". But maybe we can slowly inch toward it...

Edit 5/7/2022: I got the PLL and DDR configuration figured out and working, and the changes have been pushed to the repos above. I'm feeling pretty good about the condition of this new u-boot!

Re: Newer kernel for silvermoon

That is truly amazing work! I wish I had time to play but life if getting in the way of my free time for now.

Re: Newer kernel for silvermoon

Hey, thanks! I know the feeling -- this week I was a lot busier so I didn't make as much progress! But I did get kernel 5.15 booting into a barebones buildroot-generated rootfs with support for USB and the SD card. I suspect the LCD will be fairly easy to get working too. I'm not ready to share my work yet, but I will as soon as I have things in a cleaner state. My ultimate plan is to improve the PXA168 mainline kernel support, as long as the maintainers are willing to review/accept the patches. It seems like this particular processor never got great mainline support. Now that the ARM kernel uses the device tree system, it seems like it'll be easier to work on and slowly bring it up -- one module at a time. That would also help future-proof everything to continue to stay supported as the kernel changes with new versions.

Re: Newer kernel for silvermoon

I finally got around to cleaning up the kernel fixes and pushing them to GitHub. I haven't gotten the LCD working yet, but I've been dinking around with other kernel stuff:

  • Kernel boots (fixed timer issue in mainline kernel's device tree)

  • Internal SD card works

  • USB works

  • Internal WiFi works -- this was a big pain. The PXA168 has some issues with its SDHC controller, and the internal WiFi module is an SDIO module. I ran into a nasty problem with missing SDIO card interrupts, which curiously the original 2.6.28 kernel doesn't have. Chumby's original kernel used the Marvell vendor driver, whereas newer kernels use the libertas driver that was basically a cleaner port of that code to the mainline kernel. I can't get it to operate as fast as the original vendor driver, but at least it works reliably for me now!

  • reboot and poweroff commands work - I made a custom reset/poweroff driver the "correct way" that sends the commands to the coprocessor when the kernel wants to reboot or shut down.

Here is my kernel branch, based on 5.15.33. I plan on attempting to upstream most of this to the mainline kernel, with the exception of at least the libertas patch, which is super hacky. Unless someone with inside knowledge of Marvell's erratas, in particular SDIO card interrupts on the PXA168, can help me, I likely can't fix it the "correct" way. If anyone has access to any of that information, I'd love to hear from you! … 33-chumby8

The dts file for the Chumby is in my buildroot branch and I still need to continue cleaning up what I have before I push the latest changes for that. But it's basically just adding the USB, SDHC, and chumby reset peripherals.

38 (edited by dougg3 2022-07-05 16:21:43)

Re: Newer kernel for silvermoon

I'm still making progress. I started submitting some of my clock fixes to the upstream kernel. Haven't had much of a response yet on that. In the meantime, I was able to fix the WiFi SDIO issue the "correct" way by looking at Marvell's PXA168 errata sheet, which I found an link to in the kernel docs. Just had to work around the SDIO card interrupt issue by following the process that the errata told me to. It's kind of ugly, but it does the trick. The libertas driver is still slower than the stock Marvell driver that Chumby bundled, but I don't think I can do much about that.

Other than that, since last time:

  • The display works. It's nothing fancy, I'm just reusing the framebuffer that u-boot has already set up, using the simpledrm driver. In order to get this working properly, I had to move to a newer kernel so now I'm on 5.18.9. I'm not sure what changed between 5.15 and 5.18 that made it start working, but it works, so yay! I can run Qt apps and they display on the screen.

  • The touchscreen works. I got the SSP (SPI) controller working with the PXA168. Just needed small tweaks to the mainline pxa2xx SSP driver. Then I created a new touchscreen driver that's a bit of a frankenstein hybrid of the Chumby kernel's silvermoon-tsb driver and the ads7846 driver in modern kernels. That was a bit of a fun exercise, figuring out what the old chumby driver was doing and trying to adapt it to the modern SPI framework. The Chumby driver was doing some special stuff with the SSP controller to add delay between the chip select going low and the data being sent out. I found a cleaner but less efficient way of dealing with it using new capabilities of the modern SPI subsystem. Anyway, the touchscreen works, but the calibration is off. tslib should be able to handle that for me -- ts_calibrate only works with framebuffer drivers, but I'm using DRM instead of FB, so I need to figure out an alternate calibration method. No biggie.

I've pushed my changes here: … .9-chumby8

I still need to get a few minor fixes to u-boot and buildroot pushed up to my earlier linked branches.

Edit: I got the PWM backlighting working today, which was another interesting process. The mainline PWM driver had a couple of subtle problems, and the clock/reset control for the PWM on the PXA168 is really screwy. I was able to figure out a crazy workaround for that by doing a few register writes in u-boot. I pushed my latest Linux and u-boot changes. Still working on getting buildroot in a state where I can push it.

Re: Newer kernel for silvermoon

Thanks for sharing! I have Infocast 8. I compiled the new Buildroot and ended up with a successful build and writing to SD card. I connected a USB to serial adapter to UART header, and my serial terminal received texts successfully similar to your results. But my problem is my Infocast8's LCD didn't show anything(LCD kept dark all the time) after executed the "ext4load mmc 0:2 0x1000000 /boot/testsplash.bmp" command. I think it may be because difference between C8 and I8, any idea what's going on or where i can look into? Thanks a lot.

Re: Newer kernel for silvermoon

Hey, thanks for testing! Did you do the second part of the command after the ;?

bmp display 0x1000000

The first ext4load command will load the image into RAM, and then the second command should enable the display and put it on the screen. To be honest, I don't have an Infocast 8 available for testing, so it's also possible that something I've done doesn't work properly on it...

Re: Newer kernel for silvermoon

Thanks, it is working now. Sorry, i missed the second part of the command.

For the new Chumby kernel(both v5.15.33 & v5.18.9), I also compile and build successfully. I know you are still working
on the u-boot/buildroot + new kernel.  Is that possible copy new kernel to the SD card manually? Thanks.

Re: Newer kernel for silvermoon

Awesome! I think you can put it in /boot/uImage, but a lot of my newest fixes are in the .dts file which I haven't pushed to GitHub lately. I'll try to get it pushed in a few days if I can find some time.

Re: Newer kernel for silvermoon

Okay, I pushed my latest changes to buildroot so you can get all of my improvements by simply making sure buildroot is up to date and building it. Here are instructions assuming you already had it checked out and built earlier:

git pull
make chumby8_defconfig
make clean

Tested on a Chumby 8. This will give working WiFi, PWM backlight (should dim as soon as the kernel loads), touchscreen, DRM display device, reboot/poweroff. The display device doesn't do anything automatically in my buildroot -- it just preserves the u-boot splash screen until you do something with the display. You can run a Qt app as long as you build it with the qmake provided by buildroot and run it with the environment variable QT_QPA_FB_DRM=1. I decided to not use tslib, and instead I calibrate the /dev/event0 device directly. Not as fancy as tslib but it seems to work okay. I made a touchscreen calibration program to make it easy to calibrate:

I don't have a default environment set up for u-boot yet, so when u-boot comes up it will complain about no environment. You can run the following commands in u-boot to set up and save an environment so it will boot from the SD card automatically with the correct parameters.

setenv bootargs 'console=ttyS0,115200 ro ignore_loglevel rootwait'
setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p2'
setenv bootcmd_mmc 'run bootargs_mmc ; run showsplash ; run getkernel ; run getfdt ; bootm 0x1000000 - 0x2000000'
setenv bootdelay 1
setenv getfdt 'ext4load mmc 0:2 0x2000000 /boot/pxa168-chumby8.dtb'
setenv getkernel 'ext4load mmc 0:2 0x1000000 /boot/uImage'
setenv showsplash 'ext4load mmc 0:2 0x1000000 /boot/testsplash.bmp ; bmp display 0x1000000'
setenv bootcmd 'run bootcmd_mmc'

You may need to do these commands a few lines at a time if you copy/paste. I've had problems pasting long strings into u-boot in the past. After doing those commands, type


to reboot after saving, and it should automatically boot into Linux.

To connect to a WiFi network, you have to temporarily mount the filesystem read/write and then connect. In the command below, the WiFi network name is "mynetwork":

mount -oremount,rw /
nmcli --ask dev wifi connect mynetwork
mount -oremount,ro /

After the nmcli command, it should say something like "Device 'wlan0' successfully activated with blahblahblah". It will save this network and autoconnect at startup.

There is an SSH server, so you can connect with "ssh root@192.168.x.x". Right now it's just wide open with no password, so don't use this setup in anything that needs security. It's just convenient for development for now. It does mention at startup about how it has to regenerate a new host key at every startup, which is kind of a pain, but it works for now. You'll just have to clear the host key on your computer any time you reboot the Chumby. That's something I can clean up and fix later.

Again, this is all untested on anything but the Chumby 8, but it would be awesome if it worked on the Infocast too. No guarantees, I don't know what differences there might be.

I think my next goal is to get the audio working. It seems doable, but there's going to be a pretty big learning curve. It appears that in 2010, Marvell tried to submit PXA168 audio stuff to mainline but somehow it didn't end up making it. It'll likely take a while to figure out how to modernize it all and get it working. Luckily we have the original 2.6.28 kernel source as a working reference.

Re: Newer kernel for silvermoon

Thanks. I tested the new buildroot and got problems with the 'saveenv' parameter.
Please see errors below:
1. error after first boot:
<Loading Environment from EXT4... ** File not found /boot/uboot.env ** >
<** Unable to read "/boot/uboot.env" from mmc0:2 ** >

2. follows instructions to setup the 'setenv' variables. Some errors after sending 'saveenv' parameter:
=> saveenv
Saving Environment to EXT4... File System is consistent
** fs_devread read error - block
** fs_devread read error - block
Error in getting the block group descriptor table
fs_devread read outside partition 255068866
** fs_devread read error - block
** fs_devread read error - block
error in File System init

3. If keeps sending 'saveenv' parameter, different errors show:
** Unable to write "/boot/uboot.env" from mmc0:2 **
Failed (1)
Saving Environment to EXT4... ** No partition table - mmc 0 **
Failed (1)

4. If bypass the 'saveenv' parameter and run variable commands directly at prompt:
=> bootm 0x1000000 - 0x2000000
## Booting kernel from Legacy Image at 01000000 ...
   Image Name:   Linux-5.18.9
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4954184 Bytes = 4.7 MiB
Starting kernel ...
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.18.9 (root@DESKTOP-N8J5DIS) (arm-linux-gcc.br_real (Buildroot 10.3.0, GNU ld (GNU Binutils) 2.36.1) #1 PREEMPT Thu Jul 14 12:49:37 PDT 2022
[  111.988235]  r5:c0807e60 r4:00000000
[  111.994899] ---[ end Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. ]---

It stops at kernal panic at time [  111.994899] .

any idea what is the problem? Thanks.

Re: Newer kernel for silvermoon

Interesting…in my mind, that is pointing to SD card corruption. Both the saveenv error and missing init. The saveenv command definitely shouldn’t be failing like that. Have you tried dd’ing the sdcard.img file to the SD card again, or trying a different SD card?

Re: Newer kernel for silvermoon

Thanks! It is working now after switching to new SD card.
For QT, which version do you recommend?  I am beginner (Linux), any easy way(or instructions) to compile the QT from source?,  Thanks.

Re: Newer kernel for silvermoon

That is excellent news! I hope I haven't introduced some kind of SD compatibility bug. Anyway, my buildroot already compiles Qt 5.15.x from source. I'm not sure exactly what version it is, whatever buildroot is currently using. You should have a qmake binary in buildroot/output/host/bin/qmake. This is the qmake you can use to build Qt programs to run on it. Depending on what you want to do, you might need to enable other Qt options in the buildroot config. But it's definitely enough to build and run my touchscreen cal program for example.

Re: Newer kernel for silvermoon

Thanks a lot.
I try to run kmscube/qt5charts or other QT5 examples for further testing the new kernel. I enable the qt5(with examples) using 'make menuconfig'. I recompile and build successfully . The sdcard.img has new date(although uImage doesn't change) after finish. I couldn't find the execute files to run kmscube/qt5charts, Am I doing something wrong?

Re: Newer kernel for silvermoon

Somehow I didn't get notified about your latest response, sorry! I am not sure if kmscube would even run on this. The graphics I have working are very barebones, it's definitely not using any acceleration. I'm not familiar with exactly how the Qt5 examples get installed, but they should be there somewhere if you enabled them and ran "make". I usually just make my own little simple program and run it directly. You could try building and running my touchscreen calibration program to test Qt. Just copy the generated Chumby8TSCal program onto the root of the SD card after you compile it using the instructions.

Re: Newer kernel for silvermoon

Thanks for your help. I can run Chumby8TSCal successfully. I only have few problems with QT5 example after enable the QT5 but i think I can solve it by install QT at PC directly to learn QT first.

Does this new buildroot(kernel/uboot) work for Chumby One/Insignia 3.5? Does obm.bin work for Chumby one? Thanks.