Kobo Glo HD support

[anarcat]

Hi!

Amazing project, thanks so much for doing this.

I've got a rooted (got SSH and all) Kobo Glo HD device here that I'd be curious to see run more free software. If there's anything I can do to help development, please do let me know... i would need to open up the thing to change the SD card for tests, but I was thinking of doing that anyways to get Wikipedia in there... ;)

[lgeek]

Hi. It would be useful to know whether it uses a soldered eMMC or removable uSD for internal storage. You could also check the layout of the internal storage to see if it matches the one used by the i.MX507-based devices and described in the README.

After that, you could try to build and run the kernel source provided by kobo. Same for u-boot. UART access would greatly help with this. Check whether the kernel package includes any proprietary drivers (WiFi is the usual suspect) and replace them with open sources ones from linux-backports. Check whether it includes or depends on additional firmware blobs which could be removed.

Check whether my implementation of kobo_hwconfig works on it. After that, you would be able to give the okreader rootfs a try.

[anarcat]

On 2017-03-30 07:16:00, Cosmin Gorgovan wrote: Hi. It would be useful to know whether it uses a soldered eMMC or removable uSD for internal storage.

I believe the internal storage is removable, but you need to open the case first, according to this at least: http://goodereader.com/blog/electronic-readers/the-kobo-glo-hd-has-an-sd-card https://www.mobileread.com/forums/showthread.php?t=261362 I haven't tried this myself yet, I'm worried about cracking the case. :)

You could also check the layout of the internal storage to see if it matches the one used by the i.MX507-based devices and described in the README.

Hmm... well, I've got a shell on the thing, so I'm happy to check this further... How can i inspect this? fdisk? parted? This can act as a high-latency shell if you want. Just send me the commands you want. I also know how to compile and deploy arm binaries from debian, FWIW. :)

After that, you could try to build and run the [kernel source provided by kobo](https://github.com/kobolabs/Kobo-Reader/blob/master/hw/imx6sl-glohd/kernel.tar.bz2). UART access would greatly help with this. Check whether it includes any proprietary drivers (WiFi is the usual suspect) and replace them with open sources ones from linux-backports. Check whether it includes or depends on additional firmware blobs which could be removed. Check whether my implementation of kobo_hwconfig works on it. After that, you would be able to give the okreader rootfs a try.

Cool, I'll look into this when I pry the case open. :) It's nice to have a roadmap!

[lgeek]

You could also check the layout of the internal storage to see if it matches the one used by the i.MX507-based devices and described in the README.
Hmm... well, I've got a shell on the thing, so I'm happy to check this further... How can i inspect this? fdisk? parted?

I'd suggest dd-ing the first 20MB or so (dd if=/dev/mmcblk0 of=/mnt/onboard/dump bs=1M count=20) and then copying the file to a computer for analysis. You can use fdisk or parted to see the offset of the first partition. To find the kernel image and maybe some other files (u-boot?), try binwalk. The HWCONFIG block uses the string HW CONFIG as a header signature IIRC.

[lgeek]

@anarcat I've ended up ordering a Glo HD since I'm pretty keen on getting okreader running on the i.MX6-based devices (and checking out the newer eink screens). Don't expect instant bring-up; I'll keep this thread updated.

[anarcat]

Awesome! Let me know when you want me to run some tests then. :)

[nicolas161]

Thank you very much for your work, @lgeek.

I also have a Kobo Glo HD, so if you need to test your work on another device you can tell me. I don't have any technical knowledge, though, but I can try to help.

[jellelicht]

Is there anything I could do to help with this? I have a Kobo Glo HD around as well

[almostalive]

Any update @lgeek on getting a Kobo Glo HD?

[lgeek]

@almostalive There's experimental support in the glohd_bringup branch, which works for me. It's missing u-boot and I need to do some cleanup, but I didn't have time recently.

[jellelicht]

@lgeek: either way, thanks for the work you already did. Could you give maybe give some high level steps on how to start playing with the glohd_bringup branch like you are doing right now? Don't be afraid to RTFM me, I am willing to learn 😉

[almostalive]

@lgeek that is awesome. I will try it out soon! Couple of questions though. For u-boot did you use the one that is on the uSD or did you build it from the source located here https://github.com/kobolabs/Kobo-Reader/blob/master/hw/imx6sl-glohd/uboot.tar.bz2 ? If you built it yourself, did you need to change any of the source code to have it boot up with okreader? Also what config did you use for make? I'm thinking its mx6sl_ntx_lpddr2_config but I'm not sure. I think that is all the questions I have for u-boot.

Also does your koreader repo have any changes not found the offical koreader repo? Asking since I'll be building it from source might aswell try out the latest commits sometime.

The last real questions is, you mention formating the system partition, is there anything on the 3rd partition that needs to stay or could it be reformatted as well and possibly changed to a different fs like ext4?

I'm guessing a Raspberry Pi 2 running debian should be fine for building this albiet slow.

[lgeek]

@jellelicht I've also updated the README in that branch, it should get you started.

@almostalive I haven't replaced the u-boot image. My koreader fork doesn't have any additional commits, but I also haven't tested the upstream head in this environment. Make sure you use the okreader build script to package koreader, because it replaces some Nickel-specific scripts with okreader versions.

No data from the third (data) partition is needed, but keeping it vfat allows you to continue mounting the device on Windows in case you care about that. Also, because of the hacky way in which that partition is writable both by the device and the host computer, a journaled FS might have a higher likelyhood of getting in an inconsistent state. Don't forget to update the fstab, by the way.

The only potential issue with building on RPi2 is that it might not have enough memory. A while ago, 1 GB used to be enough, but lately I've only built okreader on systems with 4GB+ RAM. Try disabling parallel make (the -j flag) in build.sh if you run into related issues.

[almostalive]

Thanks for the info. The u-boot image was my biggest concern before starting the build and since I don't have to worry about it, I'm going to give this a try sometime this weekend.

For koreader I figured I would of course build everything right from your scripts and repos first just so I know everything works. Then eventually replace the koreader submodule path with upstream to play with, while still using your scripts.

I don't have a Windows pc so I don't care about that. Just wanted to make sure nothing important was there.

I'll give it a couple tries on rpi2 and if that fails, I'll see if I can setup a cross compile enviroment on my main pc running Arch and modify the scripts as needed. If neither of those works then qemu.

Thank you for this and I'll let you know how it goes.

[almostalive]

built and installed. sorry it took so long to reply. pure jessie or stretch both failed on the raspbery 2 but ubuntu 16.04 server worked fine. I'm drunk so I can't remember the exact errors.

On building, you use [email protected] for submodules. I had to change that to 'https://github.com' to pull them because i would get ssh errors. i used --depth 1 when updating the submodules which made the imx6-linux folder not properly work. getting pass those two things where easy.

After installing okreader on my glo hd, I notice it was faster but had two problems. Trying to connect via wifi says "Failed to initialize network control client: Failed to connect to wpa_supplicant control socket: /var/run/wpa_supplicant/eth0" from koreader. And plugging in vai usb shows nothing on my linux machines. I can chrage but I can't acess the sd card from usb.

[anarcat]

i'm probably really too late for this, but:

[root@(none) ~]# lsmod
dhd 242221 0 - Live 0x7f004000
sdio_wifi_pwr 486 0 - Live 0x7f000000
lowmem 905 0 - Live 0x7f04f000 (P)

i haven't tried the binary analysis yet, that seems a bit beyond my skillset for now. i did crack the case open to change the SD card to a larger one so that Wikipedia works better though, so I'm likely to try this again soon.

thanks!

[lgeek]

@almostalive Both problems could be caused by a failure to load the kernel modules, either because they're not available in /lib/modules or because of a version mismatch with the kernel image. To start with, could you check that the modules built in linux-okreader-modules-imx6 and that the package is installed on your rootfs?

@anarcat Yeah, we've made a bit of progress since then :)

[almostalive]

@lgeek the problem was sort of a mismatch with the kernel version. The folder was /lib/modules/3.0.35 so I decided to dd the first 15M to see what binwalk would say about the kernel - image name: "Linux-3.0.35+". so changed it to /lib/modules/3.0.35+ and gave it a try. It all worked!!!

[anarcat]

Yeah, we've made a bit of progress since then :)

So is there anything else you'd need from me here? i got an image I could work on here... from what @almostalive is saying here, it looks like "it all worked" - does that mean we can boot okreader here now?

After being frustrated by Nickel (Kobo's native interface) for a full day, I'm eager to ditch that stupid OS in favor of something more open that i could run wallabako on...

[lgeek]

@anarcat I've been using the version from the glohd_bringup branch on my Glo HD since May last year. I've not tried using wallabako.

[anarcat]

@lgeek so it works! that's nice to hear... i'll probably give it a try then!

i wasn't expecting anyone to use wallabako with okreader just yet: i still need to figure out how it all fits together... this probably belongs more in koreader/koreader#2621, so don't worry about that just yet. :)

unless you think wallabako should be somehow integrated more directly into okreader instead of being a koreader plugin?

[Frenzie]

@anarcat

I have tried reverse-engineering the Kobo database format, and it's a
real mess. The content table, for example, has about 90 columns,
most of which are basically useless. There are multiple rows per book,
one per book but also one per chapter per book (instead of having,
say, a separate chapters) table.

Fun. :-)

[jellelicht]

What does one need to do exactly with the partitions on the SD card after building okreader? The README is quite clear on most other steps, but this section about partitions 1 and 3 mostly left me confused 😕