Bookeen Saga ereader. Not sure where to start. #6043

rstar000 · 2020-04-12T12:50:57Z

Frenzie · 2020-04-12T13:49:48Z

Just a bit of a quick linkdump. The ioctls are basically already implemented by KOReader unless they're doing something way out there. See koreader/koreader-base#1023 and #5828 for the most recent example of a port. (Also keep in mind that just to get things proof of concept working you don't need all the intricacies.) Pinging @NiLuJe

https://github.com/koreader/koreader-base/blob/fd8e6cfadea27f14188e5f12f2c342a828b0a9c2/ffi/framebuffer_mxcfb.lua
https://github.com/koreader/koreader-base/blob/fd8e6cfadea27f14188e5f12f2c342a828b0a9c2/ffi-cdecl/mxcfb_kobo_decl.c
https://github.com/koreader/koreader-base/blob/fd8e6cfadea27f14188e5f12f2c342a828b0a9c2/ffi/mxcfb_kobo_h.lua

rstar000 · 2020-04-12T13:57:21Z

Thanks! I have seen the wiki page on porting koreader: http://koreader.rocks/doc/topics/Porting.md.html. It seems like the touchscreen and buttons should be handled though the /dev/cyio device, however that seems straight forward. The e-ink stuff, not so much :)

NiLuJe · 2020-04-12T15:32:17Z

Unfortunately, AFAIK, the Allwiner SoCs use a completely different driver, so, no, the ioctl stuff is definitely not taken care of ;).

Frenzie · 2020-04-12T15:36:12Z

Huh, weird, just sounds like more effort for everyone. Or is that in some strange way the point?

rstar000 · 2020-04-12T15:38:19Z

Take a look at the repo i linked. It doesn't seem that different. The ioctl calls to /dev/disp handle screen updates and the actual drawing done to the framebuffer.

rstar000 · 2020-04-12T15:46:57Z

Hey! I found the header with all of the ioctl codes! https://github.com/BOOKEEN/kernel-linux-3.0/blob/0aeda9a8538f2e2dcdfee92b5740a6bcc33c3662/include/linux/drv_display_sun4i.h

NiLuJe · 2020-04-12T17:01:58Z

@Frenzie: Not the same video/image block (i.e., what passes as a "graphics card" in these things). AW's "display engine" (or whatever it's actually called) here, instead of my good friend the PxP on Freescale HW ;).
As another example, I seem to recall the Sipix drivers being much closer in spirit to the Freescale API, FWIW.

@rstar000: That's a good start. That's a few less magic numbers in the way, which is good. The layout of the structure's reference to pass to that is still confusing, but at least your first example seems to know what to do with most of it.
Some of those waveform mode constants look funky as hell, it'll probably take a trip to the code to figure out why they're so convoluted.

My usual approach is to patch strace to decode those ioctls and see what happens in the stock software (c.f., the strace section in my build script and the matching Kobo mxcfb patch (which is possibly slightly less convoluted to grok that the Kindle ones)).

The other approach is an interposer via an LD_PRELOAD hack (c.f., Kobo's really old one, and libremarkable's for current i.MX6-ish boards).

(The strace approach is slightly more work upfront, but much less unwiedly in practice once you're done).

NiLuJe · 2020-04-12T17:16:00Z

Okay, struct layout tracks:

┌─(niluje@illyria:pts/6)─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(/var/tmp/niluje/bookeen)─┐
└─(0.29:29%:19:07:%)── rg Disp_eink_update                                                                                                                                                                                                                                                                                                             ──(Sun, Apr 12)─┘
drivers/video/sun5i/lcd/dev_lcd.c
84://    Disp_eink_update(0, 0);

drivers/video/sun5i/disp/dev_disp.c
1864:           ret = Disp_eink_update(ubuffer[0], ubuffer[1], ubuffer[2], coordinate);

drivers/video/sun5i/disp/de_bsp/bsp_display.h
321:extern __s32 Disp_eink_update(__u32 sel, __u32 fb_id, __u32 mode, __u32 coordinate[]);

drivers/video/sun5i/disp/de_bsp/de/disp_eink.h
194:__s32 Disp_eink_update(__u32 sel, __u32 fb_id, __u32 mode, __u32 coordinate[]);

drivers/video/sun5i/disp/de_bsp/de/disp_eink.c
1781:                                   Disp_eink_update(0,0, EINK_GC16_MODE, coordinate);
1783:                                   Disp_eink_update(0,0, EINK_SHORT_GC16_LOCAL_MODE, coordinate);
2544:__s32 Disp_eink_update(__u32 sel, __u32 fb_id, __u32 mode, __u32 coordinate[])

mode is actually a bitmask [think mxcfb's update, mode & flags all mixed together] (c.f., Disp_eink_update), I suspect the "LOCAL" (EDIT: and/or "RECTANGLE") stuff more or less matches freescale's PARTIAL stuff (i.e., regional, non-flashing updates).

No idea what sel & fb_id are supposed to be used for (well, fb_id more or less speaks for itself ;D), leaving 'em both at 0 seems cool (in fact, quite a few Disp_eink functions seem to take a sel argument and then never do anything with it, so, eh.).

Not quite sure what's up with the split A2 (IN/OUT), I suspect they're used for some sort of automagic A2->!A2 chaining, which we probably don't care about.

The GET_UPDATE_STATUS ioctl is NOT a 1:1 match for the mxcfb wait_for_completion stuff: while the mxcfb EPDC will block for you, in-kernel, this just returns 1 if there's currently an update being processed, and 0 otherwise (it's basically a getter for an internal global flag in the driver).
(In our context, I'm hoping you can/should pretty much forget about it, unless it turns out the hardware does stupid things if you queue multiple updates before completion of previous ones, in which case you'll have to handle the blocking in userland).

NiLuJe · 2020-04-13T02:56:42Z

Another, more generic, useful thing to know would be the glibc version being used, and whether it's hardfloat or not.

As well as the output of /proc/cpuinfo (because cortex A8 or A9 cores can ship in many weird configurations, and I'm only familiar with the Freescale (now NXP) ones) ;).

rstar000 · 2020-04-13T05:07:10Z

I'll try to find these things out.
And here's cpuinfo:

Processor	: ARMv7 Processor rev 2 (v7l)
BogoMIPS	: 1001.88
Features	: swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x3
CPU part	: 0xc08
CPU revision	: 2

Hardware	: sun5i
Revision	: a13b
Serial		: 0a4050cd383630305030355416254254

rstar000 · 2020-04-13T05:08:47Z

I still haven't set up a proper cross-compile environment. Is there a docker image for this?
Another problem i see is that in KOreader, the framebuffer (/dev/fb0) handles screen refresh. In my case the fb and display are separate devices for some reason and i'll need some hacky way to add a second descriptor in framebuffer_mxcfb. Still learning how KOreader code works, though.

NiLuJe · 2020-04-13T05:39:57Z

That was the idea behind my latest questions ;p. (You can just run the libc library to find out the version, it's executable). It's likely going to be fairly close to the Kobo TC in practice...

…

On Mon, Apr 13, 2020, 07:09 rstar000 ***@***.***> wrote: I still haven't set up a proper cross-compile environment. Is there a docker image for this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6043 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3KZQMJKLZC24DAPSTUFDRMKM6XANCNFSM4MGM3FBA> .

NiLuJe · 2020-04-13T05:42:20Z

And the filename of the dynamic loader will tell you if it's soft or hard float. (as would poking at any stock binary with readelf).

…

On Mon, Apr 13, 2020, 07:39 NiLuJe ***@***.***> wrote: That was the idea behind my latest questions ;p. (You can just run the libc library to find out the version, it's executable). It's likely going to be fairly close to the Kobo TC in practice... On Mon, Apr 13, 2020, 07:09 rstar000 ***@***.***> wrote: > I still haven't set up a proper cross-compile environment. Is there a > docker image for this? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#6043 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAA3KZQMJKLZC24DAPSTUFDRMKM6XANCNFSM4MGM3FBA> > . >

rstar000 · 2020-04-13T05:43:45Z

Here it is! Looks super old...

GNU C Library (Sourcery G++ Lite 2010.09-50) stable release version 2.11.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.5.1.
Compiled on a Linux >>2.6.24-26-server<< system on 2010-11-07.
Available extensions:
	crypt add-on version 2.1 by Michael Glad and others
	GNU Libidn by Simon Josefsson
	Native POSIX Threads Library by Ulrich Drepper et al
	Support for some architectures added on, not maintained in glibc core.
	BIND-8.2.3-T5B
For bug reporting instructions, please see:
<https://support.codesourcery.com/GNUToolchain/>.

NiLuJe · 2020-04-13T05:45:10Z

On mobile right now, but I *think* I went over most of this in more details in the reMarkable PR mentioned above (and/or the matching PR in FBInk) ;).

…

On Mon, Apr 13, 2020, 07:42 NiLuJe ***@***.***> wrote: And the filename of the dynamic loader will tell you if it's soft or hard float. (as would poking at any stock binary with readelf). On Mon, Apr 13, 2020, 07:39 NiLuJe ***@***.***> wrote: > That was the idea behind my latest questions ;p. > > (You can just run the libc library to find out the version, it's > executable). > > It's likely going to be fairly close to the Kobo TC in practice... > > On Mon, Apr 13, 2020, 07:09 rstar000 ***@***.***> wrote: > >> I still haven't set up a proper cross-compile environment. Is there a >> docker image for this? >> >> — >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> <#6043 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AAA3KZQMJKLZC24DAPSTUFDRMKM6XANCNFSM4MGM3FBA> >> . >> >

NiLuJe · 2020-04-13T05:51:04Z

Ah, yeah, that might be mildly unfun to deal with...

The Kindle (legacy) TC will generate stuff that will probably work, but you'll ultimately want a real matching ct-ng config...

EDIT: Actually, not used to it yet, but the pocketbook config will also work (bonus points: it's armv7 unlike the legacy Kindle one).

rstar000 · 2020-04-13T09:15:05Z

By the way, what's the best way to implement input? AFAIK, everything (touch, buttons, magnetic lid, accelerometer) is handled through /dev/cyio.

NiLuJe · 2020-04-13T16:17:24Z

You might want to take inspiration from PB, which is also doing something non-standard, IIRC ;).

pazos · 2020-04-13T16:59:22Z

Output

So /dev/disp is used instead of /dev/fb0 as a framebuffer-like device or /dev/fb* still exists and the other is used to trigger the refresh of the buffer?.

Input

/dev/cyio is used in the sample to obtain touch coordinates. Does /dev/input/event* exists on the device?.

NiLuJe · 2020-04-13T17:06:13Z

@pazos: The framebuffer is still where we blit, we just need to send the eInk refresh ioctls to disp instead of fb0 like on Freescale ;).

rstar000 · 2020-04-13T17:47:22Z

@pazos Yes, /dev/input/event exists and there are actually separate event devices for touchscreen, buttons and accelerometer.

I also tried an experiment with writing data directly into /dev/fb0 and then updating the screen with /dev/disp and it all works. I've made an initial version of the output module and now trying to build it (trying with pocketbook toolchain). It turned out quite different from the rest and currently i haven't found any way to properly wait for screen to update.

rstar000 · 2020-04-13T19:01:15Z

I'm having a bit of trouble: how do i make sure SDL libs are built? Koreader starts up, but crashes immediately because it can't find SDL. I used the pocketbook toolchain, btw.

Frenzie · 2020-04-13T19:05:35Z

@rstar000 SDL shouldn't be used on a platform where you're dealing with the framebuffer and input directly. SDL works as an ersatz framebuffer on desktop platforms and technically similar ones like Ubuntu Phone and Sailfish. (It could fulfill the same job on Android but there we deal more directly with an Android surface.)

But shouldn't you be seeing a "could not find hardware abstraction" error instead, until you adjust this function?

koreader/frontend/device.lua

Lines 4 to 51 in 67627ce

    
           local function probeDevice() 
        
               if util.isSDL() then 
        
                   return require("device/sdl/device") 
        
               end 
        
               if isAndroid then 
        
                   return require("device/android/device") 
        
               end 
        
               local kindle_sn = io.open("/proc/usid", "r") 
        
               if kindle_sn then 
        
                   kindle_sn:close() 
        
                   return require("device/kindle/device") 
        
               end 
        
               local kg_test_stat = lfs.attributes("/bin/kobo_config.sh") 
        
               if kg_test_stat then 
        
                   return require("device/kobo/device") 
        
               end 
        
               local pbook_test_stat = lfs.attributes("/ebrmain") 
        
               if pbook_test_stat then 
        
                   return require("device/pocketbook/device") 
        
               end 
        
               local remarkable_test_stat = lfs.attributes("/usr/bin/xochitl") 
        
               if remarkable_test_stat then 
        
                   return require("device/remarkable/device") 
        
               end 
        
               local sony_prstux_test_stat = lfs.attributes("/etc/PRSTUX") 
        
               if sony_prstux_test_stat then 
        
                   return require("device/sony-prstux/device") 
        
               end 
        
               local cervantes_test_stat = lfs.attributes("/usr/bin/ntxinfo") 
        
               if cervantes_test_stat then 
        
                   return require("device/cervantes/device") 
        
               end 
        
               -- add new ports here: 
        
               -- 
        
               -- if --[[ implement a proper test instead --]] false then 
        
               --     return require("device/newport/device") 
        
               -- end 
        
               error("Could not find hardware abstraction for this platform. If you are trying to run the emulator, please ensure SDL is installed.") 
        
           end

rstar000 · 2020-04-13T19:07:25Z

Hmm, I'm seeing this:

/mnt/fat/system/bin/koreader_bin # ./luajit reader.lua 
---------------------------------------------
                launching...
  _  _____  ____                _
 | |/ / _ \|  _ \ ___  __ _  __| | ___ _ __
 | ' / | | | |_) / _ \/ _` |/ _` |/ _ \ '__|
 | . \ |_| |  _ <  __/ (_| | (_| |  __/ |
 |_|\_\___/|_| \_\___|\__,_|\__,_|\___|_|

 It's a scroll... It's a codex... It's KOReader!

 [*] Current time: 04/13/20-18:58:24
 [*] Version: v2020.03.2-29-g2ae796e_2020-04-11

ffi.load: SDL2
ffi.load (warning): libSDL2.so: cannot open shared object file: No such file or directory
ffi.load: libSDL2-2.0.so
ffi.load (warning): libSDL2-2.0.so: cannot open shared object file: No such file or directory
ffi.load: libSDL2-2.0.so.0
ffi.load (warning): libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
SDL2 not loaded:        ./setupkoenv.lua:27: Not able to load dynamic library: libSDL2-2.0.so.0
./luajit: frontend/device.lua:50: Could not find hardware abstraction for this platform. If you are trying to run the emulator, please ensure SDL is installed.
stack traceback:
        [C]: in function 'error'
        frontend/device.lua:50: in function 'probeDevice'
        frontend/device.lua:53: in main chunk
        [C]: in function 'require'
        reader.lua:119: in main chunk
        [C]: at 0x00013f31

Frenzie · 2020-04-13T19:07:45Z

Right, so the error I mentioned. The SDL thing is meaningless in your case. ;-)

rstar000 · 2020-04-13T19:08:09Z

Am I launching it wrong? Or is there something wrong with the build?

rstar000 · 2020-04-13T19:08:53Z

Ohhh, i see. I haven't actually added my stuff to device.lua. Just a sec...

rstar000 · 2020-04-13T21:31:55Z

Ok that's it for today. I got it to not crash at any input/output related things. Now it just crashes in some lua code :D

./luajit: frontend/gettext.lua:380: attempt to index field 'context' (a nil value)
stack traceback:
        frontend/gettext.lua:380: in function 'C_'
        frontend/ui/data/css_tweaks.lua:24: in main chunk
        [C]: in function 'require'
        frontend/apps/reader/modules/readerstyletweak.lua:5: in main chunk
        [C]: in function 'require'
        frontend/apps/reader/readerui.lua:48: in main chunk
        [C]: in function 'require'
        ./reader.lua:269: in main chunk
        [C]: at 0x00013f31

rstar000 · 2020-04-13T21:50:14Z

I got it! Just had to export LANG variable. Still need to deal with input though.

rstar000 · 2020-04-14T06:06:02Z

So, it's almost all working. The buttons work. The touchscreen somewhat works, however it always registers a "pan-hold" gesture. Not sure how to fix it, probably an event hook is needed. Any ideas?

rstar000 · 2020-07-26T13:56:22Z

I tried editing /etc/init.d/ebrmain.sh script to make it start koreader on boot, but for some reason it doesn't work (though it works if this script is called directly). Any ideas why this might not work on boot?

lenaing · 2020-07-26T14:02:02Z

Is S99ebrmain.sh still linked to ebrmain.sh ?
The RC Init script launch all S* scripts in alphabetical order.
Can you show your modifications to the script please ? :)

rstar000 · 2020-07-26T14:06:11Z

Yes, for me it is.
Here's the modified start func:

start()
{
	if [ ! -x /mnt/app/ebrmain ]; then
		mount -o remount,rw /
		chmod +x /mnt/app/ebrmain
		mount -o remount,ro /
	fi

	if [ ! -x /mnt/app/boordr ]; then
		mount -o remount,rw /
		chmod +x /mnt/app/boordr
		mount -o remount,ro /
	fi

	if [ ! -e /mnt/app/ebrmain ]; then
		exit 1
	fi

	/mnt/app/ebrmain &
	sleep 10s

	if [ -f /mnt/fat/system/bin/koreader.autorun ]; then
		export LANG=en
		/mnt/fat/system/bin/koreader_bin/koreader.sh &
	fi

}

NiLuJe · 2020-07-26T16:23:15Z

You probably don't want to run ebrmain at all?

(warning: here be dragons, don't try this without a way to interrupt/recover the boot process).

lenaing · 2020-07-26T21:03:05Z

I don't know what is in your koreader.sh file but I suspect that you need to cd into the correct directory before running this script. Maybe it start but crash because of wrong relative paths?

I added this file and it "works for me" :) : /etc/init.d/S99koreader.sh

#!/bin/sh

sleep 10
cd /mnt/fat/koreader/                    
export LANG=en       
./luajit reader.lua &

exit 0

Obviously I double checked to be sure to have a "working" touchscreen beforehand, because otherwise I can't exit koreader and get back to boordr :)

Edit:
Well it launches automatically when I'm connected with USB.
When disconnected, I have to touch either the menu button or the screen to display the koreader UI.
Also, UI menu touch detection seems painfully slow when I'm not on USB

roshavagarga · 2020-07-26T21:12:35Z

@lenaing How would one go about reading one of the files? I'm curious what S12script_manage.sh has, since I have it and you don't seem to, unless @rstar000 has already viewed it and it's not important.

If this script works, I'd be up for testing it, should there be an updated file available like last time. If anything else needs to be run for more info on my device, feel free to ping me.

lenaing · 2020-07-26T22:16:38Z

@roshavagarga , You can view content of files with the cat or the less command passing their name as argument. (ie: cat my_file.ext or cat /path/to/my/file.ext or relative to your directory cat ../path/to/my/file.ext.

You may want to attach the result as a file to one of your comment.

roshavagarga · 2020-07-27T06:55:53Z

Contents seem short enough to share as pure code @lenaing
This is the S12script_manage.sh

#Commented. It needs to check the exact name of the device.
exit 0


mount /dev/priv /priv

if [[ -e /store/serial_file.ok ]] && [[ ! -e /store/script_file.ok ]]; then

        . /system/device_info.sh
        . /etc/init.d/functions.sh

        echo "mounting" > /dev/ttyS0

        mount /dev/boot

        if [ "$TYPE" == "1S" ] || [ "$TYPE" == "1F" ]; then
                echo "F1/F2┬áboard detected." > /dev/ttyS0
                if [[ -e /opt/fex/script_F2.bin ]]; then
                        cp /opt/fex/script_F2.bin /boot/script.bin
                fi
        elif [ "$TYPE" == "2S" ] || [ "$TYPE" == "2F" ]; then
                echo "F3/F4┬áboard detected." > /dev/ttyS0
                if [[ -e /opt/fex/script_F4.bin ]]; then
                        cp /opt/fex/script_F4.bin /boot/script.bin
                fi
        else
                echo "Do nothing (yet)."
        fi

        touch /store/script_file.ok

        sync
        umount /boot
        exit 0
fi
exit 0

I checked my ebrmain file and it has this code at the end, which is missing from rstar000's modified ebrmain. Not sure if that's important or not, might be specific to my device.

stop()

        killall -9 ebrmain boordr
}

restart ()

        stop
        start
}


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

roshavagarga · 2020-08-19T06:27:02Z

@rstar000 @lenaing Mind merging the work done so far into the main branch?

roshavagarga · 2020-08-24T17:13:10Z

I managed to get a zip from Bookeen's support with the source code, which is under 300 megabytes zipped and 1.2 gigabytes when unzipped. I have no idea how useful this would be, but it seems to actually hold build instructions and firmware, drivers, etc for a ton of parts that aren't used in my device.

I can upload it somewhere or give a link. I've attached a directory tree.
directories.txt

Edit: These sunxi open source boot scripts might be useful?

NiLuJe · 2020-08-24T17:34:30Z

That's a Linux source tree (so, just the kernel). I don't recall if we actually had it before, so, yeah, I'll take it ;).

roshavagarga · 2020-09-02T14:17:24Z

@rstar000 @lenaing Managed to get a tiny bit newer u-boot, a newer firmware bin and recovery firmware. All can be sent to anyone interested, just ping me. Bookeen support said the only way to execute native code was the adb_debug file method we used so far.

Instructions on reflashing device with recovery img file:

Reflashing the device using PhoenixTools:
• Start PhoenixUSBPro (https://androidmtk.com/download-phoenix-usb-pro-all-versions)
• Select the firmware for the device (.img file)
• Click on Reboot
• Click on Start
• Turn off the e-reader
• Hold menu button, plug the USB then press multiple times the power button (while still holding menu)
until PhoenixUSBPro starts flashing
• Wait until the end of the flashing process
• When device displays "Please provide production files", plug to a computer and copy to the root of the factory
disk three files: "mac" "sn" and "vcom" (no extension!) with the info (vcom format is X.XX for instance 2.15 and
can be found on the screen connector)
• Follow the factory tests (press home/press on touch panel) then e-reader should work again

Edit: Effectively, this means that as long as both of you contact their support through https://service.bookeen.com/, you can also get your devices' files.

roshavagarga · 2020-09-02T17:31:45Z

Leaving this Google Drive link here for those that want access to the files. All of these are meant for a Bookeen Cybook Muse Frontlight 2. Feel free to alternatively upload these to a new repository and post that here.

CybUpdate.bin - Update file for firmware version 2674.
u-boot_fusion_CYBME2F-BK_20200824.zip - u-boot, almost identical to the one in Bookeen's github.
linux_fusion_CYBME2F-BK_20200824.zip - kernel source, slightly different from the one in Bookeen's github.
sun5i_CYBME2F-BK-2630-7-11-18-bundle.img.zip - recovery file to firmware version 2630.

MartinAngelov · 2020-09-20T13:51:19Z

@rstar000 @lenaing Managed to get a tiny bit newer u-boot, a newer firmware bin and recovery firmware. All can be sent to anyone interested, just ping me. Bookeen support said the only way to execute native code was the adb_debug file method we used so far.

Instructions on reflashing device with recovery img file:
Reflashing the device using PhoenixTools:
• Start PhoenixUSBPro (https://androidmtk.com/download-phoenix-usb-pro-all-versions)
• Select the firmware for the device (.img file)
• Click on Reboot
• Click on Start
• Turn off the e-reader
• Hold menu button, plug the USB then press multiple times the power button (while still holding menu)
until PhoenixUSBPro starts flashing
• Wait until the end of the flashing process
• When device displays "Please provide production files", plug to a computer and copy to the root of the factory
disk three files: "mac" "sn" and "vcom" (no extension!) with the info (vcom format is X.XX for instance 2.15 and
can be found on the screen connector)
• Follow the factory tests (press home/press on touch panel) then e-reader should work again
Edit: Effectively, this means that as long as both of you contact their support through https://service.bookeen.com/, you can also get your devices' files.

Is the procedure for the same recovery img you've provided?

I do not have my vcom ia it posible to recover the info?

roshavagarga · 2020-09-24T10:01:05Z

@MartinAngelov received an answer via email.
@rstar000 and @lenaing - can you confirm that one of you can make a PR within a few weeks with just the current koreader and koreader-base changes both of you proposed, so that it's merged into mainline, in case somebody else with more time pops up and wants to continue the work? :)

lenaing · 2020-11-06T08:39:40Z

Hi,
Sorry, had no time to work on this recently.
I made my PR against @rstar000 branch here : rstar000#2
@rstar000 : You may merge my work to yours (or not, as you wish :)) and create a PR to the main koreader project so that others could continue working on it as requested by @roshavagarga ?
Kind regards,

roshavagarga · 2020-11-06T10:32:48Z

@lenaing No worries!
If @rstar000 doesn't have the time or answer within a few weeks, since I already pinged him a few times, I think this should be merged as-is in the hopes that somebody will continue the work at some future point.

Godzil · 2020-11-10T18:01:30Z

Output

So /dev/disp is used instead of /dev/fb0 as a framebuffer-like device or /dev/fb* still exists and the other is used to trigger the refresh of the buffer?.

Input

/dev/cyio is used in the sample to obtain touch coordinates. Does /dev/input/event* exists on the device?.

I'm really sorry for cyio. That thing was NEVER meant to stay, it was a quick and dirty jobs for transition (because some people could not figure how to move from the old hacked kernel module they made used in prior devices to normal input event. This was really never meant to stay, and should have been used only during dev on a s3c2416 product that was released but... didn't went well.

So I'm terribly sorry for that thing, I tried to make it as good as possible, as bug free as possible, but they asked so many changes and it went into so many things that is was a nightmare to maintain. I think they are still using the same unchanged version from what I've done years ago.
Oh and it need to use fusd, an open source project for user space driver that I took over and maintain on github as it was dead and non working on "modern" kernel back in the day. (I never like how FUSE did for user space driver and it was not working well back in the day anyway)

roshavagarga · 2020-11-10T18:23:54Z

@Godzil I take it you're one of the devs that worked on the original firmware?
I'm adding the link to fusd here, for anyone that might need it - https://github.com/Godzil/fusd

Any insight you might have into the original firmware and how things can be accessed would be greatly appreciated - currently not a lot of devs have the devices or the time to continue the porting work, but I'm sure that anything you can add on top of everything that's been said in this thread will be useful once someone has the time and/or device to continue work on this :)

Edit: There are links to firmwares and recovery packages + kernel code in the posts above, should you be interested in checking out things. If there are any personal projects you have or useful code that you want to submit - please, feel free to do so.

Godzil · 2020-11-10T22:19:26Z

I've worked on the firmware (not the main app, just from bootloader to the linux filesystem and some of the tools used on these machines, some invisible for the main user) from most of the S3C2440 devices to the last 6" OMAP based device. I never worked on any AllWinner based device or the latest using a Freescale/NXP chip if I'm correct. (yeah I worked there for a while, but it seems the people who replaced me never stayed long.)

Thanks for sharing these files, but I'm not sure I could be of a lot of help on these platforms. I can provide some help on the system I worked with though if needed.

roshavagarga · 2020-12-08T12:27:54Z

Hi,
Sorry, had no time to work on this recently.
I made my PR against @rstar000 branch here : rstar000#2
@rstar000 : You may merge my work to yours (or not, as you wish :)) and create a PR to the main koreader project so that others could continue working on it as requested by @roshavagarga ?
Kind regards,

It seems he's too busy. If you have the time, could you create the PR with your work and his?

rstar000 · 2020-12-08T18:16:11Z

Hi everyone! Sorry for the late response. I've had some crunches at work for the last few months, so couldn't really make an update or merge these branches. I'll try to find some time hopefully this week.

roshavagarga · 2020-12-09T14:39:53Z

@rstar000 No worries, whenever you have the time. I'll note I've left a link to my Google drive with newer sources from my device, as obtained from Bookeen itself - check my post from the 2nd of September, you can ask for the same from their support for your specific device too :)

roshavagarga · 2021-07-18T06:31:38Z

@rstar000 If you can find some time to at least merge the branches, I'd be personally thankful, as it's obvious you're busy with IRL things :)

roshavagarga · 2021-12-05T10:57:29Z

Last call, since we're nearing the 2-year mark since this was originally posted. @rstar000 and @lenaing - if you can get this merged even in its current state I'd be thankful, otherwise I think this should be closed as it's dead in the water and nobody else has a device to actually try and fully implement Koreader on bookeen readers.

lenaing · 2021-12-05T11:34:13Z

Sorry, almost lost track of where I was on this work. I can't make sure when i'll get time to work on this again. Feel free to close the PR. I'll comment on this if I find time again.

rstar000 · 2021-12-05T11:38:10Z

Unfortunately, I don't have the time to continue working on this. In the end, I decided to buy a tablet to read papers, as it handles PDFs much better. Sorry :(

roshavagarga mentioned this issue Aug 20, 2020

Unable to launch KOReader on PocketBook Basic 611 #6505

Closed

NiLuJe mentioned this issue Sep 27, 2020

Pocketbook: Make distinction between NTX and Allwinner boards koreader/koreader-base#1202

Closed

pazos added the new target label Oct 11, 2020

Bookeen Saga ereader. Not sure where to start. #6043

Bookeen Saga ereader. Not sure where to start. #6043

Comments

rstar000 commented Apr 12, 2020 • edited

Issue

Progress:

Frenzie commented Apr 12, 2020

rstar000 commented Apr 12, 2020 • edited

NiLuJe commented Apr 12, 2020

Frenzie commented Apr 12, 2020

rstar000 commented Apr 12, 2020

rstar000 commented Apr 12, 2020

NiLuJe commented Apr 12, 2020 • edited

NiLuJe commented Apr 12, 2020 • edited

NiLuJe commented Apr 13, 2020 • edited

rstar000 commented Apr 13, 2020

rstar000 commented Apr 13, 2020 • edited

NiLuJe commented Apr 13, 2020 via email

NiLuJe commented Apr 13, 2020 via email

rstar000 commented Apr 13, 2020 • edited

NiLuJe commented Apr 13, 2020 via email

NiLuJe commented Apr 13, 2020 • edited

rstar000 commented Apr 13, 2020

NiLuJe commented Apr 13, 2020 • edited

pazos commented Apr 13, 2020

Output

Input

NiLuJe commented Apr 13, 2020

rstar000 commented Apr 13, 2020 • edited

rstar000 commented Apr 13, 2020

Frenzie commented Apr 13, 2020 • edited

rstar000 commented Apr 13, 2020

Frenzie commented Apr 13, 2020 • edited

rstar000 commented Apr 13, 2020

rstar000 commented Apr 13, 2020

rstar000 commented Apr 13, 2020 • edited

rstar000 commented Apr 13, 2020

rstar000 commented Apr 14, 2020 • edited

rstar000 commented Jul 26, 2020 • edited

lenaing commented Jul 26, 2020

rstar000 commented Jul 26, 2020

NiLuJe commented Jul 26, 2020

lenaing commented Jul 26, 2020 • edited

roshavagarga commented Jul 26, 2020

lenaing commented Jul 26, 2020

roshavagarga commented Jul 27, 2020

roshavagarga commented Aug 19, 2020

roshavagarga commented Aug 24, 2020 • edited

NiLuJe commented Aug 24, 2020 • edited

roshavagarga commented Sep 2, 2020 • edited

roshavagarga commented Sep 2, 2020 • edited

MartinAngelov commented Sep 20, 2020

roshavagarga commented Sep 24, 2020

lenaing commented Nov 6, 2020

roshavagarga commented Nov 6, 2020

Godzil commented Nov 10, 2020

Output

Input

roshavagarga commented Nov 10, 2020 • edited

Godzil commented Nov 10, 2020

roshavagarga commented Dec 8, 2020

rstar000 commented Dec 8, 2020

roshavagarga commented Dec 9, 2020

roshavagarga commented Jul 18, 2021

roshavagarga commented Dec 5, 2021

lenaing commented Dec 5, 2021

rstar000 commented Dec 5, 2021

rstar000 commented Apr 12, 2020 •

edited

rstar000 commented Apr 12, 2020 •

edited

NiLuJe commented Apr 12, 2020 •

edited

NiLuJe commented Apr 12, 2020 •

edited

NiLuJe commented Apr 13, 2020 •

edited

rstar000 commented Apr 13, 2020 •

edited

rstar000 commented Apr 13, 2020 •

edited

NiLuJe commented Apr 13, 2020 •

edited

NiLuJe commented Apr 13, 2020 •

edited

rstar000 commented Apr 13, 2020 •

edited

Frenzie commented Apr 13, 2020 •

edited

Frenzie commented Apr 13, 2020 •

edited

rstar000 commented Apr 13, 2020 •

edited

rstar000 commented Apr 14, 2020 •

edited

rstar000 commented Jul 26, 2020 •

edited

lenaing commented Jul 26, 2020 •

edited

roshavagarga commented Aug 24, 2020 •

edited

NiLuJe commented Aug 24, 2020 •

edited

roshavagarga commented Sep 2, 2020 •

edited

roshavagarga commented Sep 2, 2020 •

edited

roshavagarga commented Nov 10, 2020 •

edited