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 chumby.com service, but I'd really like to get the hardware working.

Re: Newer kernel for silvermoon

presumably, you've been through:
http://wiki.chumby.com/index.php?title= … 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

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?

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

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!

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!

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