Cybook Gen3 and Cybook Opus

The Cybook Gen3 was the 3th generation of eBook reader made by Bookeen and the first one using an e-ink screen The Cybook Opus was based on the Gen3 but in a reduced form factor. The Cybook Opus2 was a slight update on the hardware level but was mostly identital to the original Opus, it was publicly known with the same name as the original, but the major difference was the device available in different colours.

Summary

The Cybook Gen3 was the 1st device I worked on while I was working for Bookeen. I was not the first person working on that device and had to deal with what my predecessor left me with.

The Gen3 is probably the generation that had the most different variants, invisible to the consumer, but enough changes to need major changes in the linux kernel.

It was sourced from an OEM with some personalisation, which is why you could at the time find other device that had really similar form factor, but running really different applications.

Photos

The Cybook Gen3:

The Cybook Opus:

The Cybook Opus 2:

Technical informations

There has been 3 main version of the Cybook Gen3

• The original version using a Samsung s3c2410 at 200 Mhz and the Apollo e-ink display controller
• An updated version using a Samsung s3c2440 at 400 Mhz using the same e-ink display controller as the original version
• A second updated version sold as the “Gold Edition” using the same Samsung SoC, but a more modern e-ink controller made by Epson the S1D13521B

The Cybook Opus was based on the second revision of the Gen3, so also using a s3c2440 and the Apollo e-ink display driver.

The original model was already out of sale when I join the company and took over a bit after the Gen3 model was on the market.

A lot of my work on that generation went into cleaning the code I received which was a mixture of the OEM and my predecesor. A lot of bugs had to be fixed.

Two major bug come to mind writing this documents:

When updating to the second model, the OEM decided to use NAND Flash for storage (the original used an internal USB based solution for user mass storage) but the NAND flash was used as is with a FAT partition without any flash transation layer (FTL).

Problem, FAT use the same area to store file informations and it’s own book keeping, which lead to extended wear on the Flash sector and in some cases the sector becoming bad making the file system unable to keep important informations. Because device was already in client hands, a solution of reserving a certains number of sector with a translation table was made to remap bad sector into the reserved area.

That solution was far from optimal and using a proper FTL would have been much better, but would have needed to completely reformat the storage on the device leading to a risk of bricking the device in the process which was not acceptable.

This would have been discovered before the original release, a proper FTL approch would have been used.

The second problem I encountered was a really easy to fix one, but took a long time to understand and find what the problem was. We suddenly started to receive complain from consumer where there device was crashing at random time with no clear explanation on how to reproduce. When it bacame clear something was going on, it took me a comple of months to find that in some extremely rare cases, when the device was going out of sleep mode, a bit or two in memor was flipping which in most cases ended in un-used memory, but in some rare occasion was either in the memory used by the loaded book, or worse somewhere in the application code or the kernel code and would lead to a crash.

I had to make an app that was allocating as much memory as possible, setting all to a known value, setting the device into sleep mode with a wakeup timer, then after waking up checking the large memory block if it was all at the known defined value, and indeed in some rare occasion as it could take hours with sleep/wakeup cycles of a couple of dozen seconds before encountering a bit flip, and worse some devices seems to be completely immune to the problem and ran the stress test for days without crashing.

After a long time poking various configuration register and checking electric signal to the RAM I found out that one signal going to the RAM was marginally out of specs in timing when the device was waking up and some chip were somewhat sensitive to that and were triggering a bit to flip.

And all of that were triggered by a configuration bit in the s3c2440 memory controller that were supposed (and was actually) lowering the consuption of the SoC in sleep mode.

As eBook reader spend most of their time sleeping, reducing the consuption was crucial and every bit of micro-amp saved could lead to huge increase of reading time, but in that case we sadly had to slighly reduce the device read time to not get random crash.

Projects used

A few project were used with this device:

• Linux used as the OS running on the device
• Various linux kernel module to support specific hardware on the device including a display driver