CI20 upstream

This page contains details about the latest kernel branch running on the CI20.

It will be periodically updated to keep up to speed with the latest.

The current branch tracking mainline 3.18.3

https://github.com/MIPS/CI20_linux

Overview
The CI20 uses the Ingenic JZ4780 SoC.

Ingenic provided a 3.0.8 kernel with reasonably functioning support for most peripherals on the JZ4780.

Kernel.org development moves very quickly.

IMGTEC has reworked many drivers and forward ported others.

kernel.org already has support for JZ4740. However, JZ4740 has not been updated to use device-tree. JZ4780 and JZ4740 do share many features and peripherals. Hence, the best practice would be to augment the jz4740 drivers to work with the JZ4780.

3.16 branch was created to run the CI20 on a more recent kernel with that in mind. There was some work done on consolidation to use the existing jz4740 drivers. But the core SoC parts were still disjoint.

After collaboration with the kernel community working on jz4740, jz4770, jz4780. 3.18 was rewritten with heavy emphasis on consolidation of the core SoC driver.

Core patches are in-flight.

There is still lots of work to be done. Please do contribute to kernel development. We are very welcoming and friendly on #ci20 chatroom and the mailing list

Core
In-flight patch series for jz4780 core support in kernel can be seen here http://www.spinics.net/lists/mips/msg55258.html

Ethernet MAC Address
Due to the manufacturing process for the CI20, the ethernet's MAC address isn't burned into its EEPROM - it is instead burnt into EEPROM on the other side of the board. The move to 3.18 means the MAC address has to be set at boot time (otherwise a random MAC will be chosen).

This can be done using U-BOOT - add the following to your bootargs:

dm9000.mac_addr=${ethaddr}

NOTE: Setting this bootarg for a kernel before 3.18 will cause a kernel panic.

WiFi firmware
The ci20_defconfig for 3.18 loads the firmware inside the kernel uImage. It should ideally not do that and load the firmware from user-space the way 3.0.8 does it.

WiFi on the CI20 is by a brcm4330 chip that requires closed source firmware. These files cannot be shipped as part of the kernel repository.

The required files can be found here or copied and renamed from the Debian NAND image

ci20:/lib/firmware/iw8103/fw_bcm4330b2.bin -> CI20_linux/firmware/brcm/brcmfmac4330-sdio.bin

ci20:/lib/firmware/iw8103/nv_4330b2.txt -> CI20_linux/firmware/brcm/brcmfmac4330-sdio.txt

Please note, the files have to be correctly named and in the correct directory for kernel compilation and for them to work.

NAND
If you are using the default debian rootfs on NAND and just update the kernel.

The NAND drivers between 3.0.8 and 3.16 are different. And detect different partition structures.

3.16 detects rootfs to be on mtd3.

While 3.0.8 detects rootfs to be on mtd1

So change the bootargs in uboot

setenv bootargs "console=ttyS4,115200 mem=256M@0x0 ubi.mtd=3 root=ubi0:root rootfstype=ubifs rw clock_ignore_unused" ^

Note: You might want to add another file in /boot instead of changing vmlinux.img

setenv bootcmd "mtdparts default; ubi part system; ubifsmount ubi:boot; ubifsload 0x88000000 uImage.3.18; bootm 0x88000000" ^

This way you can check your ci20 boots without messing the nand during a kernel upgrade.

Once checked

saveenv

will save the environment

Bluetooth

 * /etc/init.d/iw8103 is the startup script for the BT/Wifi firmware in the default rootfs.

If using 3.16/3.18, the script can cause the boot to hang unless the BT device is responding. Please move the script out of /etc/init.d or make sure the kernel is correct.

This is an issue with broadcoms patchram utility. It keeps trying. (Perhaps its some arguments passed to the script?)

Add "root=/dev/mmcblk0p1 rootwait" to bootargs in uboot if you wish to boot a rootfs from mmc.

SGX
GPU drivers rely on userland binaries and kernel module sources.

The work is on-going at IMG. Until the drivers are updated, using the GPU (openGL etc) will not be possible.

For normal usage, Xorg and framebuffer drivers do work.

The default xorg.conf is configured to load the powervr module. move that somewhere else/keep a copy. And use this xorg.conf

Note: Rename to xorg.conf. Don't leave it named xorg.conf.fbdev.

Place in /etc/X11/xorg.conf