Howto recompile opensource firmware for KOBO reader

[eschwartz]

Or much more simply -- verify the update integrity. e.g. Kindles use a signed update package, and if the update_*.bin has a webpage for content, it won't be signed...

AIUI, Kobo updates are just gzipped tarballs -- so at least check for a gzip header (and check for .tgz corruption) before assuming it is a valid update and rebooting.


That would catch firewalls as well as a few other problems.

Error: Corrupted update files.

[davidfor]

Sorry, but all this is weird.

Firstly, firewalls block what they are told to block. "A wireless firewall is not supposed to stop text" is rubbish. Yes, a firewall in an internet cafe/hotspot will probably allow web pages and images, and block executables and maybe zip files, but they could just as easily block all pages with the name of their competitor in the text somewhere.

The firmware download and upgrade works as:

- Contact a page to see if there is an update.
- If there is an update, download it using link in the above response.
- When complete, unpack the zip file into the ".kobo" directory.
- Prompt the user to install.
- Reboot and do the install during start up.

If you say no to the install, it will happen the next time you restart, or connect and disconnect from the PC. And if you connect to the PC you can remove the files and NOTHING will happen. And I've done that a lot with no consequences. And I've had the download fail as well with no issues. As far as I can tell, if the update available check fails, it continues with the sync. If the download fails, it stops and you get an error message displayed.

The upgrade during the setup might be different. But, it should only be missing the prompt. If it can't download the update, it should just continue. As it happens, I hit this recently. When I got my Glo HD, I set it up with no problems. After a day or so, I decided to do a factory reset to test something. This time, it didn't do the upgrade. I know it tried as I saw some messages, but continued with the setup without the restart and install. When I checked, it was running 3.14.0 rather than the expected 3.15.0. Later, I did a sync and the upgrade happened with no problems.

I have also had failures doing the download when setting up. In all cases, it displayed an error and I had to hit a cancel or back button. This took me back to the previous step. At that point, I had the choice of trying again, or backing out further and using the PC connection.

[eschwartz]

Personally, I wouldn't know as I don't have a Kobo. I would assume that the developers made sure to do error checking, but fastrobot's posts imply that is not happening.

I personally have no way of knowing if Kobo was sloppy or fastrobot is wrong.

[fastrobot]

Originally Posted by george.talusan

Lot of noise here about nothing.

If the build instructions are followed from the Kobo-Reader repository using the individual git repos, you should be able to build up your own chroot. The main reason for the big split is because github doesn't allow binaries greater than 100MB and it's easier to just track upstream repositories if we use git as intended.

In other words, just clone and compile.

UPDATE: Also if there's anything missing, then file an issue on github instead of complaining here.

OK. I posted another request for where these "build instructions" are, exactly --- as I can't clone and compile without knowing the command used to compile....and I don't see any documentation that's obvious, or even findable by grep. So I'm stumped. Its pretty difficult to recompile the source to be compatible with the Kobo, and build plugin applications without knowing how the QT library is compiled on the Kobo. Thanks.

I opened a request on github:
https://github.com/kobolabs/Kobo-Reader/issues/54

I don't see build instructions for QT anywhere 4.8.0, that shows how QT4.8.0 needs to be configured to rebuild the libraries fully compatible with the Kobo Glo and Aura HD. Are they in the archive?

I found a script for qt-4.6.2, in the build instructions, which has the following switches:
./configure $CPPFLAGS $LIBS -release -no-accessibility -system-libmng -no-nis -no-cups -no-xshape -no-xrandr -no-xkb -no-xinerama -no-xcursor -no-sm -system-libpng -system-libjpeg -qt-gif -qt-zlib -embedded arm -xplatform qws/linux-arm-g++ -no-qt3support -exceptions -opensource -no-pch -qt-freetype -qt-gfx-qvfb -confirm-license -dbus -ldbus-1 -nomake examples -nomake docs -nomake translations -nomake examples -nomake docs -nomake demos -scripttools -xmlpatterns -no-opengl -depths all -qt-gfx-transformed -qt-gfx-linuxfb -no-mouse-pc -no-mouse-linuxtp -no-mouse-linuxinput -no-mouse-tslib -no-mouse-qvfb -no-mouse-qnx -no-armfpa -no-neon -openssl -lrt -I${DEVICEROOT}/include/dbus-1.0 -I${DEVICEROOT}/lib/dbus-1.0/include $QT_EXTRA_ARGS -prefix-install

But these switches aren't all available in 4.8.0 or 5.xx
What switches ought I use to build the libraries that are on the Kobo Glo, and AuraHD ?

[fastrobot]

Originally Posted by davidfor

Sorry, but all this is weird.

Firstly, firewalls block what they are told to block. "A wireless firewall is not supposed to stop text" is rubbish. Yes, a firewall in an internet cafe/hotspot will probably allow web pages and images, and block executables and maybe zip files, but they could just as easily block all pages with the name of their competitor in the text somewhere.

Well, yes, I suppose that's technically correct. But that doesn't make what I said weird.
The last time I checked, FredMeyers is not a competitor to Kobo -- it's a grocery store.
And it would be pretty stupid to offer a wireless hotspot for customers of the DELI -- so that they can "Browse" the web while eating lunch, if you're going to block HTML text files.
Nobody can browse the web without at least plain text files being permitted.
So -- even though they 'could' block kobo, specifically, I seroiusly doubt that's what I am encountering.

The firmware download and upgrade works as:

- Contact a page to see if there is an update.
- If there is an update, download it using link in the above response.
- When complete, unpack the zip file into the ".kobo" directory.
- Prompt the user to install.
- Reboot and do the install during start up.

If you say no to the install, it will happen the next time you restart, or connect and disconnect from the PC.

I don't have a PC. Kobo's desktop software doesn't run on Linux, so I don't plug the cable in. I can only do a wireless setup, or none at all.

And if you connect to the PC you can remove the files and NOTHING will happen. And I've done that a lot with no consequences. And I've had the download fail as well with no issues. As far as I can tell, if the update available check fails, it continues with the sync. If the download fails, it stops and you get an error message displayed.

I agree; for that's basically what happened after I had been using the Kobo for a while and the firmware went out of date. 75% through the "sync", I would get a message saying "Network error". I could cancel it, I could restart the kobo -- but nothing would allow it to complete a 'sync' while a firewall was present and the firmware not updated.

If the firmware was updated, though -- I was able to download books even with the firewall present and compete a sync. My conclusion -- the firmware being out of date affects the sync process and can prevent updating of a kobo reader, and re-downloading of books from the Kobo store.

The upgrade during the setup might be different. But, it should only be missing the prompt. If it can't download the update, it should just continue. As it happens, I hit this recently. When I got my Glo HD, I set it up with no problems.

Excuse me? You got your glo to set up without upgrading the firmware ?
Using only wireless setup ??? I'd like to see a video of that, show me the firmware update fail after a factory reset -- and you still be able to log into the store and download all your DRM protected books (not just the free ones). I'd like to know the revision number of the Glo, for I'll find and buy that one. I've tried EVERYTHING to make that happen, and it didn't work. I started out with a Kobo Touch, then upgraded to a Glo and Aura, and my experience is that they will allow you to cancel and go back a step during initial setup -- but I've never seen it allow you to actually log in and use the reader with the Kobo store, download and read books, until after the initial updates succeeded. It automatically restarts, or else you have to go back a step -- in either event, it either reboots and tries to update again, or you can't make any progress because you never complete the final step.

Are you using a trick, by deleting the update files or something, to make it let you log in?

After a day or so, I decided to do a factory reset to test something. This time, it didn't do the upgrade. I know it tried as I saw some messages, but continued with the setup without the restart and install. When I checked, it was running 3.14.0 rather than the expected 3.15.0. Later, I did a sync and the upgrade happened with no problems.

I have also had failures doing the download when setting up. In all cases, it displayed an error and I had to hit a cancel or back button. This took me back to the previous step. At that point, I had the choice of trying again, or backing out further and using the PC connection.

Again, there's no PC to connect to. You're cheating if you use the PC.

[davidfor]

Originally Posted by fastrobot

Well, yes, I suppose that's technically correct. But that doesn't make what I said weird.
The last time I checked, FredMeyers is not a competitor to Kobo -- it's a grocery store.
And it would be pretty stupid to offer a wireless hotspot for customers of the DELI -- so that they can "Browse" the web while eating lunch, if you're going to block HTML text files.
Nobody can browse the web without at least plain text files being permitted.
So -- even though they 'could' block kobo, specifically, I seroiusly doubt that's what I am encountering.

Yes, I was nitpicking. But, your statement was something like "a firewall lets text through". It was just such a bad statement that I couldn't leave it alone. What I did forget to say is that I'd be surprised if these places are blocking zip files and not blocking epubs. It is much more likely that they blocked everything and then let a few things through. Or, more likely, the device/firewall was configured that way when they bought it.

Personally, I suspect the problem is size. The free hotspots I have used limit the length of time or total downloads of a session. The one I can remember had 50MB a day. That's to small for any of the Kobo firmware versions.

I don't have a PC. Kobo's desktop software doesn't run on Linux, so I don't plug the cable in. I can only do a wireless setup, or none at all.

I agree; for that's basically what happened after I had been using the Kobo for a while and the firmware went out of date. 75% through the "sync", I would get a message saying "Network error". I could cancel it, I could restart the kobo -- but nothing would allow it to complete a 'sync' while a firewall was present and the firmware not updated.

If the firmware was updated, though -- I was able to download books even with the firewall present and compete a sync. My conclusion -- the firmware being out of date affects the sync process and can prevent updating of a kobo reader, and re-downloading of books from the Kobo store.

Excuse me? You got your glo to set up without upgrading the firmware ?
Using only wireless setup ??? I'd like to see a video of that, show me the firmware update fail after a factory reset -- and you still be able to log into the store and download all your DRM protected books (not just the free ones). I'd like to know the revision number of the Glo, for I'll find and buy that one. I've tried EVERYTHING to make that happen, and it didn't work. I started out with a Kobo Touch, then upgraded to a Glo and Aura, and my experience is that they will allow you to cancel and go back a step during initial setup -- but I've never seen it allow you to actually log in and use the reader with the Kobo store, download and read books, until after the initial updates succeeded. It automatically restarts, or else you have to go back a step -- in either event, it either reboots and tries to update again, or you can't make any progress because you never complete the final step.

Are you using a trick, by deleting the update files or something, to make it let you log in?

Yes, I got to do a setup over WiFi after a factory reset without the firmware being updated. How or why, I don't know. I was surprised when it happened. I was able to login and it downloaded the usual five books and all the details of the others during the setup. I was then able to use the device to read and do a couple of checks with no problems. But, when I did a sync, it downloaded and installed the firmware that it missed during the setup.

Again, there's no PC to connect to. You're cheating if you use the PC.

Where did I say I used a PC? I said I had the option to back out to the step where I could choose that option. Whether I did on one occasion or not, was dependent on exactly what I was doing at the time.

Of course, if I wanted to cheat, I would use the PC. I'd connect to the PC and copy the latest firmware files onto the device. When I disconnected, it would do the update. Once it finished, it should be prompting to do the setup. Doing that over the WiFi should work as when the firmware version check was done, it would find that it was already at the latest and not have to download anything. And of course, none of that needs the Kobo desktop software.

[eschwartz]

As I understand it, Kobo offers download links to firmware updates -- which can be manually sideloaded without Kobo Desktop.

[davidfor]

Originally Posted by eschwartz

As I understand it, Kobo offers download links to firmware updates -- which can be manually sideloaded without Kobo Desktop.

Strictly, they don't. But, they haven't hidden the links to them very well and we easily find it when an update is released. And someone at Kobo likes to have fun with the links. In the past they have shown they were hockey fans, but the latest includes "hello_MR" in the path.

[eschwartz]

Originally Posted by davidfor

Strictly, they don't. But, they haven't hidden the links to them very well and we easily find it when an update is released.

Almost as good.

And someone at Kobo likes to have fun with the links. In the past they have shown they were hockey fans, but the latest includes "hello_MR" in the path.

[fastrobot]

George,

This is what I use.

configure -opensource -confirm-license -prefix /usr/local/Qt-5.2.1-arm -platform macx-clang -xplatform linux-armv7-kobo-g++ -no-xcb -qt-harfbuzz -skip connectivity -skip doc -skip docgallery -skip feedback -skip location -skip pim -skip qa -skip quick1 -skip quickcontrols -skip serialport -skip translations -system-libpng -system-libjpeg -system-freetype -system-zlib -lz -I/chroot/usr/include -I/chroot/usr/include/freetype2 -I/chroot/include -no-compile-examples -I/chroot/include/dbus-1.0 -I/chroot/lib/dbus-1.0/include -dbus -no-qml-debug

...

Closed #54.

Thank you for build instructions to QT-5.2.1. I would have eventually asked for those when I actually tried to compile that part of the code, rather than asking for what I'm actually doing now: eg: QT4.8.0. But thanks, I'll keep the 5.2.1 for when I get that far.

And as another note, I'm still finding minor busybox bugs: eg: the KOBO busybox program 'test -w /mnt/sd' returns true when examining a mount point that was remounted as read only. On all linux systems, the superuser permission bits can be RW even on a read only file system; but the 'test' command generally correctly tests for read only filesystem -- but the Kobo busybox version does not.

[PeterT]

Just wondering if you have tried the busybox version of test on any other platform?

[fastrobot]

Originally Posted by PeterT

Just wondering if you have tried the busybox version of test on any other platform?

Only on the SonyReader, which I bricked not too long ago. So I can't retest it now ; but I didn't notice the problem on that platform at the time.

I haven't tried the newest release of busybox to see if they have changed test to accurately reflect read only permissions on a mount-point. but I'm not surprised that busybox test on the Kobo returns true when the mount point is mounted read-only; because the linux kernel *is* reporting that the superuser has write permissions even though the device is mounted read only. I was more surprised that the normal gnu filesystem 'test' program can correctly determine that a device is read only, even when the permission bits on the mount point directory don't reflect reality.

I'm going to have to dig through the kernel source, and busybox, and the normal gnu filesystem utils to figure out why there is different behavior between the normal gnu utilities and busybox, and especially why the linux kernel doesn't change the permission bits to reflect that the mount point was mounted read only.