Oyolinux

Project Oyolinux
Status	In progress
Contact	User:smeding
Last Update	2013-02-17

Since i (User:TheOnlyJoey) purchased a shitload of OYO e-readers, here is a wiki page to dump all the information.

• http://www.fwma.de/pmwiki/pmwiki.php?n=Main.OYO <-- everything linux and shizzle
• http://en.wikipedia.org/wiki/4FFF_N618 <-- hardware information
• http://openinkpot.org/wiki/Device/Qisda-eBook <-- some source shizzlewizzle.
• oyo-hack wiki on gitorious
• OYO hacking page at TechInc

smeding's efforts

smeding has been working on a from-scratch Linux system for the Oyo and has made considerable progress. The notes listed here have resulted in a working system, but could do with some more elaboration.

SD card

A normal Linux FS pretty much relies on symlinks, but the boot loader can only boot from vfat which does not support these.

The solution: partition the SD card to have one small (10MB or so) partition with the kernel (and the empty initramfs the bootloader looks for), and a large ext3 partition that the kernel can mount as root.

Hardware hacking

I soldered to the hardware serial port that's internally available, which helps with kernel debugging (the usb-serial is a kernel module so won't work if the kernel doesn't boot). Pictures available at http://ownyo.de. It's *very* fiddly, a better solution would be to find the appropriate FFC for the debug connector, as well as a matching connector, and make a little breakout board.

Kernel

• Run this to retrieve and set up the kernel repo:

$ git clone git://gitorious.org/oyo-hack/kernel.git kernel
$ cd kernel
$ git checkout topic/board/sg060
$ tg remote --populate origin

• Then, to configure:

$ make ARCH=arm sg060_defconfig
$ make ARCH=arm menuconfig

• You'll want to change the kernel parameters (the default is some weird config used by Heiko Stübner for his development work). I use the following: root=/dev/mmcblk0p2 console=ttySAC0,115200 ro init=/sbin/init rootwait

• Add in VFAT and the locales it needs directly (instead of as modules), as well as ext2 support, so we don't have to muck about with an initramfs or something

Root fs

• Download buildroot
• Apply this patch: http://patchwork.ozlabs.org/patch/219054/ so you can select an existing kernel source dir
• Type 'make menuconfig' in the buildroot dir. Set up the basics -- make it compile for an ARM system, and 'generic' works. I chose to let buildroot compile me a cross compiler, for convenience. Make it produce a tarball as the filesystem image or something.
• Enable the buildroot bits you want on your root fs.
• Enable the kernel build, and use the existing kernel repo you downloaded and initialized as a custom local source dir. (I don't think using the git repo directly would work because of the topgit stuff.) Set the config to point at the kernel config file you made earlier. Tell it to build a zImage.
• Compile everything by typing 'make'. This may take a while.
• Prepare the partitions in the following manner:
  • Make and format two partitions on your SD card -- one 20MB vfat partition and one larger ext2 partition.
  • Copy the kernel ($BUILDROOTDIR/outputimages/zImage) to $VFATPARTITION/qdutil/uzImage
  • Create an empty u-boot image with u-boot's mkimage. I don't think it matters too much what's in there, but I was operating under the impression it wanted an initramfs so I built an empty cpio.gz archive and put that inside. Copy it to the SD card as $VFATPARTITION/qdutil/urootfs.img
  • Extract the root FS image to the ext2 partition.

If you now hold the left/right buttons while powering it up, you should be able to see it boot correctly via the (hardware, see above) serial port. The screen won't do much yet -- I'm working on that :)

Screen

If you compiled the screen support as a module, you have to load it with modprobe es600-epd. You then get a regular old /dev/fb0 that you can tinker with. smeding has code to draw a clock using cairo.

Of interest are two sysfs options: /sys/devices/platform/auo_k1900fb/update_mode and /sys/devices/platform/auo_k1900fb/content_type. These control some low-level aspects of the refresh. It seems like content_type doesn't really do all that much, but update_mode is a number that's written directly to the controller. It can vary from 0-5:

• 0: Flash the screen with a negative image. Prevents ghosting, but visually jarring.
• 1: Makes areas transitioning black->white white, /then/ makes areas transitioning white->black black. Probably the best mode for small changes, but produces some ghosting.
• 2: Flashes the screen a lot. Get kernel messages about controller hanging, but that may be because I'm updating quickly (once per second).
• 3: Flashes screen negative, then correct, then negative again. Probably causes even less ghosting.
• 4: Seems to whiten screen progressively.
• 5: Updates somewhat like mode 1, but causes the unchanged parts of the screen to turn grayish with weird artifacts.