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

setid
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?

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.

Thanks for the follow-up!

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.

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:

https://github.com/dougg3/u-boot/tree/chumby8

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.

https://github.com/dougg3/buildroot/tree/chumby

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 https://github.com/dougg3/buildroot.git -b chumby
cd buildroot
make chumby8_defconfig
make

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
chumby!
disableIRQ
setupxfer
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!

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.

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 archive.org 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: https://github.com/dougg3/silvermoon-li … .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.

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

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.

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 toolchains.bootlin.com-2021.11-1) 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.

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.

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?