Topic: Debian 9.6 and 4.20 Kernel on Chumby One

I had a little python project I made for a raspi and screen to show me my current dhcp leases - too many IoT devices to remember all the ip's, too lazy to set up a local DNS server. After I made it I wanted to use my pi screen for something else, and thought putting it on my long neglected chumby would be good.

Well - that turned out to be a bit more work than I anticipated. But I've got wifi, the LCD screen, and the touchscreen working and I thought I'd throw up a how to and some patches - hopefully someone that's more experienced can give it more love and time than I can afford right now.

Please keep in mind these are unpolished dirty hacks. Do not attempt. Standard disclaimers etc etc.

Prerequisites

At minimum, you'll need a serial console to do the configuration post SD card install. I'm sure there are some posts to reference setting up. 3.3v FTDI at 115200. You'll also need some way to write to the SD card - and an upgrade from the stock 1-2gb sdcard would be wise as well. I'm using an 8gb card that's a little too small for my rpi project now.

I originally used my ubuntu desktop to compile - but found it was pretty bad at getting the proper libraries set up. I ended up running a debian minimum machine under a virtualbox VM on my desktop. ARM cross compiling has come a ways since the old tutorials were made. Specifically I used /eewiki/display/linuxonarm/iMX233-OLinuXino as a rough guide. I skipped using the linaro environment, instead relying on straight debian to do what I needed.

apt-get install gcc-arm-linux-gnueabi build-essential bison flex libssl-dev libncurses-dev

Problem 1: Bootloader

Boot process is well described at title=Falconwing_boot#Boot_processode

1. The boot rom examines the OCOTP fuses and determines it needs to boot from MBR
2. The first 2048 bytes of the SD card are examined, and the boot image is located
3. sdram_prep, clocks, power, and chumby_stub are all loaded from a Bootstream image into OCRAM
4. sdram_pre, clocks, and power are all executed to set up registers and DRAM
5. chumby_stub is executed
6. chumby_stub loads chumby_boot from disk into DRAM
7. chumby_stub jumps to chumby_boot
8. chumby_boot checks for someone touching the screen
9. chumby_boot sets up the LCD and draws a boot logo.
10. chumby_boot waits 3 sec for the user to press a key to enter shell
11. chumby_boot draws the appropriate "now booting" logo
12. chumby_boot loads the Linux kernel from disk into DRAM
13. chumby_boot sets up the Linux tags
14. chumby_boot jumps to the Linux kernel

The problem in trying to get a newer kernel is two fold - one, the reserved space for a kernel is 4mb in size. Secondly - the initial setup data is encrypted by a key that's burned into the imx233 processor - so it can't be easily manipulated. The solution is to take step 14 - which is outside the encrypted boot area - and run das u-boot in its place. From here we can basically chain load uboot - and use u-boot to set up all the cmdline variables and devicetree data needed for a new kernel.

But it's not quite as easy as running "config_util --cmd=putblock --dev=/dev/mmcblk0p1 --block=krnA < u-boot.bin" - it's pretty close. U-boot expects to be run close to bare metal assembly - and would normally run steps 2-4 as part of the SPL - Secondary Program Loader - before u-boot runs. The SPL also gathers some basic information about the system to pass onto uboot - like ram size and address range. We'll need to modify u-boot to hard code those values as a dirty hack.

First step - snag u-boot.
u-boot/u-boot/archive/v2018.11.zip

Then create a new board config - these are copied off of other imx23-based boards. I began to make a more pi-like system where uEnv and cmdline could be stored in a fat32 partition on the SD card. U-Boot can also read it's config off a SD card block which I copied off another config, but didn't do the math to make sure it's outside the stock bootloaders range - so beware using it. In the defconfig file you set CONFIG_SYS_TEXT_BASE=0x40008000 - this is the entry point for the kernel.

The second major change is to edit arch/arm/cpu/arm926ejs/mxs/mxs.c - this is where the SPL normally sets the memory size. Since chumbys have 64MB, we hardcode it here and disable the hang(); when it returns a 0 mem size - which it will.

 if (data->mem_dram_size == 0) {
                printf("MXS:\n"
                        "Error, the RAM size passed up from SPL is 0!\n");
        //      hang();
        }
        data->mem_dram_size = 0x04000000;
        gd->ram_size = data->mem_dram_size;
        return 0;

Aside from that, there's some setting up of the iomux pins and a disabling of the watchdog.

https://github.com/openhoon/chumbyhacks … umby.patch

Extract v2018.11.zip and the github patch an apply it by cd'ing into the directory and patch < uboot-2018.11-chumby.patch - that should create the new config files. From there

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- mx23_chumby_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-

That will produce uboot.bin. Copy that (either through SSH or a usb memstick) and run

config_util --cmd=putblock --dev=/dev/mmcblk0p1 --block=krnA < u-boot.bin  

on the chumby.

Reboot - and now you should see a u-boot prompt available through serial.

Now though u-boot you can load up a kernel image and boot it - if you're running this off the madox rom you can run

setenv bootargs console=ttyAM0,115200 root=/dev/mmcblk0p2 rw rootwait chumbyrev=08 ssp1=mmc sysrq_always_enabled logo.brand=chumby
ext2load mmc 0:2 0x42000000 /boot/zImage
bootz 0x42000000 - 

Next up is setting up the the SD card - just make sure you leave the first partition alone. Remove it from the chumby, slap it into your machine, and fdisk to delete the other partitions and create a small 16mb fat32 partition, and then the rest for the root fs. Snag a rootfs from /rootfs/eewiki/minfs/ - anything listed as armel will work - basically we're following the same steps from /eewiki/display/linuxonarm/iMX233-OLinuXino - set up etc/fstab, /etc/wpa/wpa_supplicant.conf, and etc/interfaces .

2nd Problem: Kernel and Device Tree

It's not that hard to compile a new kernel - a make CROSS_COMPILE=arm-linux-gnueabi- mxs_defconfig will give you a pretty basic kernel. Key to making things work is a new devicetree - this provides system information similar to the bios for the kernel. I was able to get the system booted with the olinuxino devicetree, but had a heck of a time making the graphics work. Eventually I had to bust out the schematics to map the gpio pins - I think it's mostly accurate.

The framebuffer console has changed a bit in newer kernels, with a new mxsfb driver that works on the DRM subsystem - which now needs an additional devicetree node for the LCD panel. The LCD panel in the chumby is a nanovision nma35qv65 320x240 screen - I found the datasheet at /download/5466_9662_1.pdf - which has a typo - the HX8328-A device doesn't exist - but the pdf/HX8238-D.pdf does. Still couldn't get it to work - until I manually inserted the initialization sequence from the chumby-boot code into the driver initialization. Looking at the registers the MXSFB sets -

mxsfb ctrl1: 00070000
chumby ini  010f0701
mxsfb ctrl: 00080320
chumby ini: 000b0821

These values don't appear to have any external flags to pass so the mxsfb_crtc.c file had to be modified directly. Most of the register value differences appear to be related to IRQ over and underflows.

https://github.com/openhoon/chumbyhacks … acks.patch includes the mxsfb changes, along with a new devicetree, and a chumby.config that I'm currently using. A couple of notes - the USB wifi card is rt73usb, DRM requires some CMA DMA ram (I just gave it 2mb). Once the patch is applied - run

make CROSS_COMPILE=arm-linux-gnueabi- mxs_defconfig 
cp chumby.config .config
make CROSS_COMPILE=arm-linux-gnueabi- menuconfig 
make -j8 CROSS_COMPILE=arm-linux-gnueabi- 

That'll pop the kernel out in arch/arm/boot - cp that to your /boot directory on the flash cart, cp arch/arm/dts/imx23-chumby.dtb to /boot/dtbs/ . Uboot is currently set up to run

setenv bootargs console=ttyAMA0,115200 root=/dev/mmcblk0p3 rootfstype=ext4 rw rootwait ssp1=mmc ram=64M net.ifnames=0

I'm not sure if ssp1=mmc is still used by the 4.20 kernel.

With only 64mb of ram, even an apt-get update will run out of memory. While it's generally not advisable to run a swapfile on an SD card because of wear levelling and other general SD card limitations - wants must.

fallocate -l 512M /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo 'vm.swappiness=10' >> /etc/sysctl.conf
echo '/swapfile swap swap defaults 0 0' >> /etc/fstab

Hopefully I've written these instructions out clear enough - and maybe someone can use them and make it better. I haven't attempted to get the sound working and I don't think the backlight is 100% tuned correctly. I might throw up a dd'able image up somewhere once it's more polished. On the surface the alterations I made aren't much - but they actually took 3 weeks of poking around during the holiday break, learning about device trees and poking around in source files.

edit: Apparently I can't directly link URL's so I partially remove them - but they should be largely pointing at github.

2 (edited by infocastme 2019-01-12 09:41:34)

Re: Debian 9.6 and 4.20 Kernel on Chumby One

Thanks for a great write up!

gooflophaze wrote:

Apparently I can't directly link URL's

here is how you do links;

[url]http://forum.chumby.com/[/url] produces

http://forum.chumby.com/

3 (edited by gooflophaze 2019-01-12 10:38:37)

Re: Debian 9.6 and 4.20 Kernel on Chumby One

I don't know if it's because I'm a new user or overzealous anti-spam, but I literally can not mention various address-like keywords (acronyms of hypertext transport, world wide web, .commercial site, etc) or else I receive the following when I try to post.

Warning! The following errors must be corrected before your message can be posted:
Too more links in message. Allowed 0 links. Reduce number of links and post it again.

Re: Debian 9.6 and 4.20 Kernel on Chumby One

It's an anti-spam measure - you have to have a certain number of posts before you can include links, or things that look like links.

It's actually quite astonishing how many attempts there are per-day to create new accounts and post a single spam post on this forum.  For the last few months, we've been barraged by attempted spammers from Spain. Some get through the registration process, but give up when they're unable to post with links.

Re: Debian 9.6 and 4.20 Kernel on Chumby One

Ah yes, I did not catch the fact that he is a new user. :-)

Re: Debian 9.6 and 4.20 Kernel on Chumby One

gooflophaze wrote:

I don't know if it's because I'm a new user or overzealous anti-spam,

It's not overzealous at all.   If anything, it's *under*zealous for new people, based on how many spammers there are out there.

gooflophaze wrote:

but I literally can not mention various address-like keywords (acronyms of hypertext transport, world wide web, .commercial site, etc) or else I receive the following when I try to post.

Warning! The following errors must be corrected before your message can be posted:
Too more links in message. Allowed 0 links. Reduce number of links and post it again.

I edited your post so your links are clickable.

Thanks for posting!

Cleaning up any loose bits and bytes.

Re: Debian 9.6 and 4.20 Kernel on Chumby One

Thanks for the edit - I put the rest of the urls in the readme on github. I haven't had time to delve back into it (other projects take priority) but the good news is..

root@arm:~# uname -a
Linux arm 4.20.0 #1 Wed Jan 9 04:23:00 EST 2019 armv5tejl GNU/Linux
root@arm:~# uptime
 06:47:41 up 45 days, 13:31,  2 users,  load average: 0.56, 0.16, 0.05

4.20.0 appears to be pretty stable (though I need to fix the ntp client..)

8 (edited by Doktor Jones 2021-01-15 16:58:25)

Re: Debian 9.6 and 4.20 Kernel on Chumby One

Thanks for all your work on this!
I've built on this and added (partial) chumby support to buildroot 2020.11.1

What's working:

  • Building a rootfs.tar with 5.9 series kernel.

  • WIFI, LCD and backlight all work well.

What's not working:

  • Sound, touchscreen, top button and rotary encoder. I haven't investigated if these work at all. I assume not.

  • Sometimes the LCD image is shifted. This occurs on about 5% of reboots. Something is still not quite right in the LCD initialization.

  • Building uboot. Something I would like to implement but so far built using your manual instructions.

~ # uname -a
Linux chumby 5.9.14-ARCH #1 Fri Jan 15 09:54:06 MST 2021 armv5tejl GNU/Linux
~ # uptime
 14:22:48 up  3:54,  load average: 0.13, 0.11, 0.08

Build instructions:

make chumby_defconfig
make menuconfig # select what you want here, python3, pip, iwd, wireless-regdb, openssh, etc...
make
# extract rootfs.tar to mmcblk0p3
tar xpf output/images/rootfs.tar -C <mmcblk0p3 mount point>

Then boot it up with a serial terminal connected so that the network and any other configuration can be performed.

I setup zram swap space to avoid writes to the sd card. Put this in /etc/init.d/S35zramswap and make sure it's executable:

#!/bin/sh
#
# zramswap    sets up/removes a zram swap
#

umask 077

start() {
    sysctl -w vm.swappiness=100
    modprobe zram
    echo zstd > /sys/block/zram0/comp_algorithm
    echo 20M > /sys/block/zram0/disksize
    mkswap /dev/zram0
    swapon /dev/zram0
}
stop() {
    swapoff /dev/zram0
    echo 1 > /sys/block/zram0/reset
}

case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  *)
    echo "Usage: $0 {start|stop}"
    exit 1
esac

exit $?

I've been running with some small python scripts that use pycario to display text on the screen for a basic clock that shows the date and time as well as the outside temperature and 24 hour high and low temps. It receives temperature information via mqtt.
python3 pip seems to work well for pure python packages.

on github prw/buildroot branch is 2020.11.x.

[Link edited in by Doktor Jones]

Re: Debian 9.6 and 4.20 Kernel on Chumby One

Great work!

I added (also partial) u-boot support to timberline5s buildroot
github.com/dasdgw/buildroot

But there is no output on the LCD.
Besides from that, linux seams to run without further issues.

On the terminal I can see u-boot complaining:

Video: MXSFB: 'videomode' variable not set!

And in the linux boot log:

pwm-backlight backlight: supply power not found, using dummy regulator
mxsfb 80030000.lcdif: Failed to create outputs

Any ideas what I messed up or forgot?

Re: Debian 9.6 and 4.20 Kernel on Chumby One

I have those same messages in dmesg but the LCD eventually works:

$ dmesg | grep 'pwm-backlight\|mxsfb'
[    2.160000] pwm-backlight backlight: supply power not found, using dummy regulator
[    2.170000] mxsfb 80030000.lcdif: Failed to create outputs
[    2.700000] pwm-backlight backlight: supply power not found, using dummy regulator
[    2.720000] mxsfb 80030000.lcdif: Failed to create outputs
[    3.120000] pwm-backlight backlight: supply power not found, using dummy regulator
[    3.160000] mxsfb 80030000.lcdif: Failed to create outputs
[    6.470000] pwm-backlight backlight: supply power not found, using dummy regulator
[    6.590000] mxsfb 80030000.lcdif: Failed to create outputs
[    6.660000] pwm-backlight backlight: supply power not found, using dummy regulator
[    6.820000] [drm] Initialized mxsfb-drm 1.0.0 20160824 for 80030000.lcdif on minor 0
[    7.120000] mxsfb 80030000.lcdif: [drm] fb0: mxsfb-drmdrmfb frame buffer device

In my u-boot build I added "vt.global_cursor_default=0" to the kernel parameters to prevent the virtual console cursor from blinking. I don't remember disabling anything related to this in the kernel config, but it's possible I did. I checked the config and didn't see anything obvious.

For a quick test of the LCD you can write some junk to it

dd if=/dev/urandom of=/dev/fb0

Also make sure the backlight is on (1 lowest brightness, 7 highest, 0 doesn't do anything):

echo 7 > /sys/bus/platform/drivers/pwm-backlight/backlight/backlight/backlight/brightness

I occasionally see the LCD image shifted after a reboot so the initialization still isn't correct.

Re: Debian 9.6 and 4.20 Kernel on Chumby One

Thank you for looking into this.
In my dmesg output there is no line with 'mxs-drm'.

I also don't have a framebuffer device at /dev/fb0.
Is this device generated when mxs-fb successully initialized?

Backlight is also not available.

I noticed a small difference in your and mine output.
Your chumby is reported as chumbyrev=08 while mine says chumbyrev=06.
Does anyone know what's the difference between the the several chumbyrev versions?

Re: Debian 9.6 and 4.20 Kernel on Chumby One

I looked at the old chumby kernel source and that kernel parameter is used in a few places.

Revisions >6 have the y axis flipped on the touchscreen
Revision 7 has a difference with setting the backlight brightness, audio volume limits, battery temperature sensing
Revision 9 has tv out rather than the LCD. This might be the 'hacker' board?

Grepping through an image of the original sd card gives me this. Leads me to believe I do indeed have revision 8.

$ strings factory.img | grep chumbyrev       
linux 0x40008000 "console=ttyAM0,115200 init=/linuxrc root=/dev/mmcblk0p2 rootfstype=ext3 ro rootwait chumbyrev=** ssp1=mmc sysrq_always_enabled logo.brand=BBBBBBBBBBBB"
linux 0x40008000 "console=ttyAM0,115200 init=/linuxrc root=/dev/mmcblk0p2 rootfstype=ext3 ro rootwait chumbyrev=** ssp1=mmc sysrq_always_enabled partition=recovery logo.brand=BBBBBBBBBBBB"
linux 0x40008000 "console=ttyAM0,115200 init=/linuxrc root=/dev/mmcblk0p3 rootfstype=ext3 ro rootwait chumbyrev=** ssp1=mmc sysrq_always_enabled logo.brand=BBBBBBBBBBBB"
linux 0x40008000 "console=ttyAM0,115200 init=/linuxrc root=/dev/mmcblk0p3 rootfstype=ext3 ro rootwait chumbyrev=** ssp1=mmc sysrq_always_enabled partition=recovery logo.brand=BBBBBBBBBBBB"
console=ttyAM0,115200 init=/linuxrc root=/dev/mmcblk0p2 rootfstype=ext3 ro rootwait chumbyrev=08 ssp1=mmc sysrq_always_enabled logo.brand=chumby
console=ttyAM0,115200 init=/linuxrc root=/dev/mmcblk0p3 rootfstype=ext3 ro rootwait chumbyrev=08 ssp1=mmc sysrq_always_enabled logo.brand=chumby

Do you have BR2_PACKAGE_KMOD selected in your buildroot .config? I probably didn't put a very complete chumby defconfig together.

Output of lsmod

$ lsmod
Module                  Size  Used by    Not tainted
iptable_nat            16384  0 
nf_nat                 40960  1 iptable_nat
nf_conntrack          122880  1 nf_nat
nf_defrag_ipv6         16384  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
libcrc32c              16384  2 nf_nat,nf_conntrack
iptable_mangle         16384  0 
bpfilter               16384  0 
zram                   24576  1 
rt2800usb              24576  0 
rt2800lib             110592  1 rt2800usb
rt2x00usb              24576  1 rt2800usb
rt2x00lib              57344  3 rt2800usb,rt2800lib,rt2x00usb
mac80211              438272  3 rt2800lib,rt2x00usb,rt2x00lib
cfg80211              315392  2 rt2x00lib,mac80211
rfkill                 28672  3 cfg80211
pwm_mxs                16384  1 
nvmem_mxs_ocotp        16384  0 

Re: Debian 9.6 and 4.20 Kernel on Chumby One

Didn't thought about searching the old kernel sources, great idea!

BR2_PACKAGE_KMOD was not in my .config. So I added it.
Compiling right now.

I somehow bricked my current install. I'll set it up again tomorrow.
But I think when I ran lsmod, no modules where shown.
Is the kmod package responsible for loading modules?

I'll post results tomorrow.

Again, thanks for your time and advice.

Re: Debian 9.6 and 4.20 Kernel on Chumby One

After adding BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV=y
from the olimex config the fb gets set up.
But the colors are wrong.
I added fb-test-app to the buildroot config and executed fb-test

# fb-test
fb-test 1.1.0 (rosetta)
fb res 320x240 virtual 320x240, line_len 1280, bpp 32
# 

with

fb-test -g

I should get a green output. But it's yellow.
Blue is blue but red is also a blue shade.

Shouldn't the bpp be 18?

So I'm getting closer, but still not there.

Re: Debian 9.6 and 4.20 Kernel on Chumby One

I believe the display is 5-6-5 (16 bpp).

Re: Debian 9.6 and 4.20 Kernel on Chumby One

I'm glad you figured that config option out. Good to put that one in the defconfig. The pixel format is indeed 5-6-5!

Here's an imagemagick command I was using to show the date and time on the screen.

convert -size 320x240 xc:black \
        -font "DejaVu-Sans" \
        -pointsize 32 \
        -fill grey \
        -annotate +5+45 "$(date '+%a %b %d\n%H:%M:%S')" \
        -type truecolor \
        -flip -strip \
        -define bmp:subtype=RGB565 bmp2:test.bmp

Then copied to the chumby and wrote it to the framebuffer

dd if=test.bmp of=/dev/fb0 obs=160k ibs=26 skip=1

imagemagick adds some junk header information in the first 26 bytes of the output, hence the dd command to skip over it.

I was going to show a clock on the screen this way, but imagemagick couldn't render an image once per second when running on the chumby.
It's an easy way to test the screen at least.