The road towards using regular linux on ebook readers
Kemnade, Andreas
Most Kobo/Tolino readers offer a well marked console port and often a second UART. If they are not water resistant, they offer an internal µSD card slot containing the whole operating system and bootloader so that sounds like an invitation to do something interesting with them besides just reading books. Especially in prolonged outdoor activities, the display and their low power consumption have their merits. Hardware is quite similar, so you also have chances to get a replacement next corner. Several devicetrees and also some drivers made their way into mainline linux now, on others upstreaming work is in progress. Support is starting to find its way into mobile linux distributions like postmarketOS and graphics start to work with standard APIs. In this talk I talk about my experiences, especially the current state of support in mainline linux, what is missing and what are the challenges. I will also talk about requirements for the graphics userspace and shortly present my favorite use case: displaying maps.
 Hello everybody, welcome. My name is Andreas Kimnate and I will talk about the two words using regular Linux on ebook readers, especially with Kobo and Tolino readers. First I will tell you a bit about me, the motivation behind all that and about the devices. Then I will go from down to up system, from bootloader to kernel and then the user space and share changes. I will also show my favorite use case maps and how the display feels like. Then some videos. So if I am not taking something, I am often doing some outdoor stuff. In summer vacation I usually do long bicycle trips, often in sparsely populated areas in northern Europe. So I am a bit on my own there. Of course I have some Linux mobile device with me. I had an PDA in former times and also the Moku. So the motivation behind all my work is to solve my outdoor problems. So it can only be done in my spare time. The ebook readers I am involved with are the Kobo Clara HDs, my first one. And also I talked to someone, persuaded him to buy the Stein 3 because we both thought they are equal but that was not the case. They are not so equal. So I helped them with porting it and I found a used GTO2, a used Shine 2. And I imported it also there. And for comparison I get my hands on some defective H2O and for some very condensing atmospheres I bought Vision 5 for example like the showing star maps. So what do I want basically? A bit of computer in the middle of nowhere. So I prefer to have little power consumption instead of sick batteries and it should be the data I'd readable. And having it with me should not prevent me from relaxing too much. It's a powerful enough to look at for example the coronavirus site all the time. That's a bit more relaxing. And also a bigger display. It's helpful if you do some planning and not just going from simply going from A to B. So some nemic planning and you can and also like I'd actually be able to have some information stored with me. And of course doing some text work is always nice to be able to do that. And contrary to the other devices I had before, here I can find something similar kind of next corner and so I feel that my work experience is not lost if I shoot another device. So it's basically master one device, master next one easily. So about the devices, there's a Tolino Alliance consisting of mainly German bookstores to compete with Amazon kindle more easily. The brand Tolino belongs to Gutenkobo, so you find similar devices. They use most than ordinary file formats, so also the original software is of quite some use. So you have often several pairs of almost identical devices. There's just a different pin compatible SOC. So it's the IMX6 Solide Tolino devices and the IMX6 SLL and Kovu devices. And it almost identical was Pitfall for me, so I mentioned that with the Shine 3. And the vendor software on the Tolino, it's Android based system on a 3.0 based kernel. But there's also some quite new boot things on Kovu. You have something a bit newer. But this all asked to be replaced by something newer, so you can use ordinary stuff on it. More newer stuff. So how can they easily be hacked? What can you do with them? The non-waterproof device have internal microSD slots, contains a world operating system and a bootloader. So can be replaced by something big and you can have backups. The waterproof device usually have EMMC. It's a bit more tricky. You can break it. The space is a bit mislimited. Probably not. You put some Wikipedia on it. We all have some serial console, easily accessible and also some fast boot. At least the Kovu bootloader allows to use USB mass storage. And there's some I'm in specific recovery over USB. If no bootloader is found, like no microSD in or in the EMMC devices, the device is zeroed where it does not look like a bootloader. And you can enter this mode also by writing some magic values into some registers and then reset. There was once an 8 gigabyte card in here. I've changed it, replaced it. And also the console is clearly marked. And interestingly, next set there's another UART. So you can attach your favorite peripheral to it if you want. So how do I debug these things? I remove the back cover and buy some sleep cover for it and put a hole in there. So I have some debug cover and I'm accessing this band with some poro pins. Here also with some Lutus adapter so I can access it wireless. Yep, so no wires attached there. Was something looking ugly. So now let's talk about UBoot, the bootloader. The vendor UBoot has some special behavior. The bootM and bootZ commands are modified. They load blocks from hidden partitions and also append things to the kernel arguments, also the keyword required sometimes. And if no kernel is loaded yet using a special command, they tend to override things. So if you are just loading the kernel from the desk, you have to take care of it to some tricks. And for some reason deep sleep on mainline kernels with to combination with Tolino vendor UBoot it doesn't work reliably for whatever reason. There's a fork of the... So I decided to replace it by something new. So downside is that booting the vendor systems is a bit more tricky because you need to load this hidden partitions and pass the addresses to the kernel command line. I did not manage to boot the Tolino vendor kernel visit yet. Well, but contrary, buttons and LED is easily accessible for boot options. Like booting the dual booting the original systems or doing some recovery things. And they're just more easily configurable. Big pen we tested using that USB recovery boot. So you can test a run before writing it to flash. So you can avoid breaking your devices. So now let's talk about the kernel. What's already in there. The device is for the devices I'm involved with. And the Pimic for battery realtime block, it's upstreamed for touchscreen. The touchscreen for the Shine 2 HD is upstream already for a longer time. And the Wi-Fi, some devices have a Broadcom based Wi-Fi with drivers upstream. So what's missing, there are patches for the touchscreen already on the mailing list. That's a review and it covers a lot of devices. As of the devices mentioned here, it's also the remarkable tool. So the Pine node and then there is the real tech chip that's only in out of 3 driver. So it's only in out of 3 driver, seems to be no upstream work active. The biggest construction site is the display. It's not mainlined at all. But I have a DIM variant of the driver in preparation. I think I will send out an IFC patch series soon. To use the display you also need a driver for some EPD Pimics. And the most recent code for this is online my shithub repository. So you can check out and test. I have documented some quirks like how to convince fastboot to take that kernel and also the individual status for several devices. So now out the display. What's the most interesting part? The third clue is we need a list of non-overlapping damaged rectangles. Pass them through. So it's first for the convert them to gray. And several EboGridas have rotated displays. We need to rotate it here. Also on the IMAX 6SL, the PHP does faith form processing. It's not well documented. But the things go to the display controller and then to the display. My DRM driver does not use the display yet because the implementation mainline is too limited. It's too limited. And the EPDC needs some waveform blob to operate. So what are the challenges here? You need to get these rectangles. So I get the API and provide something which is already used for other devices like command mode, DSI displays. So the user space is prepared for it. Then the vendor kernel uses frame buffer devices and special IOControls which need special programs to handle. So if you use ordinary programs, you will just need to track damage events of XORG either by patching the frame buffer driver or by running a special program on top of XORG and catch the damage faster or you have other mechanisms to recognize change memory areas. But that usually results in full horizontal stripes to be refreshed. And especially that's ugly if two small rectangles damage which distance. Stabilize rebrand forms, the display gets drienson. I have quite strange code in my driver. make things work. That's all a bit disgusting. These are stored in didn't partitions and I'm copying to the firmware directory and it's loaded. So now let's talk about distributions. There's post marketOS which supports the codeclarer hd and the shine tool. So you clone your SD card, install post marketOS on it. The first boot the waveform is copied from the hdn partition and then there is also a layer on top of open embedded for the codeclarer hd. There's a LittoxOS. There are some special Ipopia software distributions. They are using the Endocals and so using this special IOControl things. So now to my favorite use case, Maps navigation. I'm using some special USB cable to attach power source and shivers receiver. Power source is my bicycle hub dynamo. We can also use the secondary UART. I had the former software already in place so I used that. About Maps, the standard OpenStreetMap style is hardly readable. Some topographic maps from Swedish and German state agencies seem to work surprisingly well. There's also Navit. So this is Navit with OSM data and routing in sunlight. Quite readable. There's the OSM standard and I improve them a little bit by exchanging street borders. The grey with black. But there's still a lot of work to do here. And then Control is a map from the Swedish state agency. It's easily readable and under a nice license. Similar experience with not so free maps from Germany. So now let's look at some videos. How the display looks like. So I'm routing the system here. This is the Shine 2. This is my DIM driver. Now it's starting. You see the cursor. You can move it. Okay. Now this is post market with XFCE4. I'm unlocking my screen. Yes. You see some shadows from a display. Now I have my terminal. Now it's time for your questions. That's it. We are live. Andreas, thank you very much for the talk. So we can get started with the questions. We have quite a few. Starting from the first one. Which of the ebook readers did you find most pleasant to hack on and why? I mostly prefer the ebook readers first in microSD card because I can easily back up the whole system and cannot damage too much things. So I can. So less chances to break them. My favorite is still the Kuroklara HD. And also there's a once with some, this is second Siri port. Also nice for hacking. You can attach something to it. Just more possibilities and also getting a big microSD card. You have seen in my pictures I have some 128 there. That's also helpful to keep also the original system there for it while booting something. Thank you. Are you aware of any work for main lining Linux on the Amazon Kindle devices? I'm not aware of anything there. I personally don't. I've not looked too much into that because that was too much fields to look to even support. Okay. So next one was a maps. Maps for navigation. Well, it works. Well depends on the style. So you have quite a quite different experience. So standard OSM style. It's hardly usable, but never itself. It works. And I've successfully used it. Next one. Which of see. So I lost your video stream for a while. I don't know if other people are seeing you. So I'll move on. Another question related to the previous one. Which of the book readers do you find most pleasant to use and why? For all this auto stuff and stuff I would prefer the more waterproof ones. But that's clearly contradicts this. This ability so I would just for just with just about reading ebooks I would prefer the waterproof ones and so you don't need to be that careful with this water and that things out. I'm out. Thank you. Then moving on. Do you think that OEM will become more friendly towards the first projects in the future? Well, the ebook readers at least you can ask for sources and say respond. But it does not feel too much about contribution. So when I reported Kernel errors or something, it somehow got fixed after some year and there was no response. But what I think if there is more stuff in my main line, especially the EPC driver, maybe, but on the other hand, it's often I think they are a bit competitive with the issues there. So they don't like to they may they must start to adapt their software that they have hard-coded past to better into the better battery capacity, which includes the ship name and then patch the kernel so that regardless of what ship it's really is, just renamed in the kernel. So somehow I have my doubts there. Thank you. And the next question, since Kobo and Torino share almost identical hardware, but the former on Linux and the latter Android, is there any chance of further more interoperability and cross development? If it's about the different SOTs, then even the other the reboot of the other device doesn't find the MMC, so it already stops there. If the devices are similar, then devices are similar and have the same SOT, then there are some reports that the Kobo firmware boots on Torino firmware and vice versa, with some limited functionality, had a very fully working people have tried that. But if it's all this about the different SOTs, then there's a problem that probably either since they then they are different kernel versions, then the user space would have to be adapted. And so it's not probably not so easy. And getting the vendor kernel on the other processor to work, that will be a nightmare. Since you all three 3.0 kernel used on the SL devices are different, don't use device tree, and these old kernels do not support the SL processor, so that will be a nightmare. Thank you. We have 30 seconds left for maybe one last question. How big are the EMMCs on these devices? Once I get in touch with it, it was eight gigabytes. But on the newest ones, I've seen something about 32, but eight gigabytes is common. Well, on some older, for a bit.
 Hello everybody, welcome.  My name is Andreas Kimnate and I will talk about the two words using regular Linux on  ebook readers, especially with Kobo and Tolino readers.  First I will tell you a bit about me, the motivation behind all that and about the devices.  Then I will go from down to up system, from bootloader to kernel and then the user space  and share changes.  I will also show my favorite use case maps and how the display feels like.  Then some videos.  So if I am not taking something, I am often doing some outdoor stuff.  In summer vacation I usually do long bicycle trips, often in sparsely populated areas in  northern Europe.  So I am a bit on my own there.  Of course I have some Linux mobile device with me.  I had an PDA in former times and also the Moku.  So the motivation behind all my work is to solve my outdoor problems.  So it can only be done in my spare time.  The ebook readers I am involved with are the Kobo Clara HDs, my first one.  And also I talked to someone, persuaded him to buy the Stein 3 because we both thought  they are equal but that was not the case.  They are not so equal.  So I helped them with porting it and I found a used GTO2, a used Shine 2.  And I imported it also there.  And for comparison I get my hands on some defective H2O and for some very condensing  atmospheres I bought Vision 5 for example like the showing star maps.  So what do I want basically?  A bit of computer in the middle of nowhere.  So I prefer to have little power consumption instead of sick batteries and it should be  the data I'd readable.  And having it with me should not prevent me from relaxing too much.  It's a powerful enough to look at for example the coronavirus site all the time.  That's a bit more relaxing.  And also a bigger display.  It's helpful if you do some planning and not just going from simply going from A to  B.  So some nemic planning and you can and also like I'd actually be able to have some information  stored with me.  And of course doing some text work is always nice to be able to do that.  And contrary to the other devices I had before, here I can find something similar kind of  next corner and so I feel that my work experience is not lost if I shoot another device.  So it's basically master one device, master next one easily.  So about the devices, there's a Tolino Alliance consisting of mainly German bookstores to compete  with Amazon kindle more easily.  The brand Tolino belongs to Gutenkobo, so you find similar devices.  They use most than ordinary file formats, so also the original software is of quite some  use.  So you have often several pairs of almost identical devices.  There's just a different pin compatible SOC.  So it's the IMX6 Solide Tolino devices and the IMX6 SLL and Kovu devices.  And it almost identical was Pitfall for me, so I mentioned that with the Shine 3.  And the vendor software on the Tolino, it's Android based system on a 3.0 based kernel.  But there's also some quite new boot things on Kovu.  You have something a bit newer.  But this all asked to be replaced by something newer, so you can use ordinary stuff on it.  More newer stuff.  So how can they easily be hacked?  What can you do with them?  The non-waterproof device have internal microSD slots, contains a world operating system and  a bootloader.  So can be replaced by something big and you can have backups.  The waterproof device usually have EMMC.  It's a bit more tricky.  You can break it.  The space is a bit mislimited.  Probably not.  You put some Wikipedia on it.  We all have some serial console, easily accessible and also some fast boot.  At least the Kovu bootloader allows to use USB mass storage.  And there's some I'm in specific recovery over USB.  If no bootloader is found, like no microSD in or in the EMMC devices, the device is  zeroed where it does not look like a bootloader.  And you can enter this mode also by writing some magic values into some registers and  then reset.  There was once an 8 gigabyte card in here.  I've changed it, replaced it.  And also the console is clearly marked.  And interestingly, next set there's another UART.  So you can attach your favorite peripheral to it if you want.  So how do I debug these things?  I remove the back cover and buy some sleep cover for it and put a hole in there.  So I have some debug cover and I'm accessing this band with some poro pins.  Here also with some Lutus adapter so I can access it wireless.  Yep, so no wires attached there.  Was something looking ugly.  So now let's talk about UBoot, the bootloader.  The vendor UBoot has some special behavior.  The bootM and bootZ commands are modified.  They load blocks from hidden partitions and also append things to the kernel arguments,  also the keyword required sometimes.  And if no kernel is loaded yet using a special command, they tend to override things.  So if you are just loading the kernel from the desk, you have to take care of it to some  tricks.  And for some reason deep sleep on mainline kernels with to combination with Tolino vendor  UBoot it doesn't work reliably for whatever reason.  There's a fork of the...  So I decided to replace it by something new.  So downside is that booting the vendor systems is a bit more tricky because you need to load  this hidden partitions and pass the addresses to the kernel command line.  I did not manage to boot the Tolino vendor kernel visit yet.  Well, but contrary, buttons and LED is easily accessible for boot options.  Like booting the dual booting the original systems or doing some recovery things.  And they're just more easily configurable.  Big pen we tested using that USB recovery boot.  So you can test a run before writing it to flash.  So you can avoid breaking your devices.  So now let's talk about the kernel.  What's already in there.  The device is for the devices I'm involved with.  And the Pimic for battery realtime block, it's upstreamed for touchscreen.  The touchscreen for the Shine 2 HD is upstream already for a longer time.  And the Wi-Fi, some devices have a Broadcom based Wi-Fi with drivers upstream.  So what's missing, there are patches for the touchscreen already on the mailing list.  That's a review and it covers a lot of devices.  As of the devices mentioned here, it's also the remarkable tool.  So the Pine node and then there is the real tech chip that's only in out of 3 driver.  So it's only in out of 3 driver, seems to be no upstream work active.  The biggest construction site is the display.  It's not mainlined at all.  But I have a DIM variant of the driver in preparation.  I think I will send out an IFC patch series soon.  To use the display you also need a driver for some EPD Pimics.  And the most recent code for this is online my shithub repository.  So you can check out and test.  I have documented some quirks like how to convince fastboot to take that kernel and  also the individual status for several devices.  So now out the display.  What's the most interesting part?  The third clue is we need a list of non-overlapping damaged rectangles.  Pass them through.  So it's first for the convert them to gray.  And several EboGridas have rotated displays.  We need to rotate it here.  Also on the IMAX 6SL, the PHP does faith form processing.  It's not well documented.  But the things go to the display controller and then to the display.  My DRM driver does not use the display yet because the implementation mainline is too  limited.  It's too limited.  And the EPDC needs some waveform blob to operate.  So what are the challenges here?  You need to get these rectangles.  So I get the API and provide something which is already used for other devices like command  mode, DSI displays.  So the user space is prepared for it.  Then the vendor kernel uses frame buffer devices and special IOControls which need special  programs to handle.  So if you use ordinary programs, you will just need to track damage events of XORG either  by patching the frame buffer driver or by running a special program on top of XORG and  catch the damage faster or you have other mechanisms to recognize change memory areas.  But that usually results in full horizontal stripes to be refreshed.  And especially that's ugly if two small rectangles damage which distance.  Stabilize rebrand forms, the display gets drienson.  I have quite strange code in my driver.  make things work. That's all a bit disgusting. These are stored in  didn't partitions and I'm copying to the firmware directory and it's loaded.  So now let's talk about distributions. There's post marketOS which supports the  codeclarer hd and the shine tool. So you clone your SD card, install post marketOS on it.  The first boot the waveform is copied from the hdn partition and then there is also a layer on top  of open embedded for the codeclarer hd. There's a LittoxOS. There are some special  Ipopia software distributions. They are using the Endocals and so using this special IOControl things.  So now to my favorite use case, Maps navigation. I'm using some special USB cable to attach  power source and shivers receiver. Power source is my bicycle hub dynamo. We can also use the  secondary UART. I had the former software already in place so I used that. About Maps, the standard  OpenStreetMap style is hardly readable. Some topographic maps from Swedish and German  state agencies seem to work surprisingly well. There's also Navit. So this is Navit with  OSM data and routing in sunlight. Quite readable. There's the OSM standard and I improve them  a little bit by exchanging street borders. The grey with black. But there's still a lot  of work to do here. And then Control is a map from the Swedish state agency. It's easily  readable and under a nice license. Similar experience with not so free maps from Germany.  So now let's look at some videos. How the display looks like. So I'm routing the system  here. This is the Shine 2. This is my DIM driver. Now it's starting. You see the cursor.  You can move it. Okay. Now this is post market with XFCE4. I'm unlocking my screen.  Yes. You see some shadows from a display. Now I have my terminal. Now it's time for your  questions. That's it.  We are live. Andreas, thank you very much for the talk. So we can get started with the  questions. We have quite a few. Starting from the first one. Which of the ebook readers  did you find most pleasant to hack on and why? I mostly prefer the ebook readers first  in microSD card because I can easily back up the whole system and cannot damage too much  things. So I can. So less chances to break them. My favorite is still the Kuroklara HD.  And also there's a once with some, this is second Siri port. Also nice for hacking. You  can attach something to it. Just more possibilities and also getting a big microSD card. You have  seen in my pictures I have some 128 there. That's also helpful to keep also the original  system there for it while booting something. Thank you. Are you aware of any work for main  lining Linux on the Amazon Kindle devices? I'm not aware of anything there. I personally  don't. I've not looked too much into that because that was too much fields to look to  even support. Okay. So next one was a maps.  Maps for navigation. Well, it works. Well depends on the style. So you have quite a quite different  experience. So standard OSM style. It's hardly usable, but never itself. It works. And I've  successfully used it. Next one. Which of see. So I lost your video stream for a while. I  don't know if other people are seeing you. So I'll move on. Another question related to  the previous one. Which of the book readers do you find most pleasant to use and why?  For all this auto stuff and stuff I would prefer the more waterproof ones. But that's  clearly contradicts this. This ability so I would just for just with just about reading  ebooks I would prefer the waterproof ones and so you don't need to be that careful with  this water and that things out. I'm out. Thank you. Then moving on. Do you think that OEM  will become more friendly towards the first projects in the future? Well, the ebook readers  at least you can ask for sources and say respond. But it does not feel too much about contribution.  So when I reported Kernel errors or something, it somehow got fixed after some year and there  was no response. But what I think if there is more stuff in my main line, especially the  EPC driver, maybe, but on the other hand, it's often I think they are a bit competitive  with the issues there. So they don't like to they may they must start to adapt their software  that they have hard-coded past to better into the better battery capacity, which includes  the ship name and then patch the kernel so that regardless of what ship it's really is,  just renamed in the kernel. So somehow I have my doubts there. Thank you. And the next question,  since Kobo and Torino share almost identical hardware, but the former on Linux and the  latter Android, is there any chance of further more interoperability and cross development?  If it's about the different SOTs, then even the other the reboot of the other device doesn't  find the MMC, so it already stops there. If the devices are similar, then devices are  similar and have the same SOT, then there are some reports that the Kobo firmware boots  on Torino firmware and vice versa, with some limited functionality, had a very fully working  people have tried that. But if it's all this about the different SOTs, then there's a problem  that probably either since they then they are different kernel versions, then the user  space would have to be adapted. And so it's not probably not so easy. And getting the  vendor kernel on the other processor to work, that will be a nightmare. Since you all three  3.0 kernel used on the SL devices are different, don't use device tree, and these old kernels  do not support the SL processor, so that will be a nightmare.  Thank you. We have 30 seconds left for maybe one last question. How big are the EMMCs on  these devices?  Once I get in touch with it, it was eight gigabytes. But on the newest ones, I've seen something  about 32, but eight gigabytes is common. Well, on some older, for a bit.
mobile_kernel_ebook_reader_0_167.png mobile_kernel_ebook_reader_168_779.png mobile_kernel_ebook_reader_780_1643.png mobile_kernel_ebook_reader_1644_5795.png mobile_kernel_ebook_reader_5796_9299.png mobile_kernel_ebook_reader_9300_13379.png mobile_kernel_ebook_reader_13380_15899.png mobile_kernel_ebook_reader_15900_17003.png mobile_kernel_ebook_reader_17004_18251.png mobile_kernel_ebook_reader_18252_20315.png mobile_kernel_ebook_reader_20316_22859.png mobile_kernel_ebook_reader_22860_28259.png mobile_kernel_ebook_reader_28260_29075.png mobile_kernel_ebook_reader_29076_31439.png mobile_kernel_ebook_reader_31440_38567.png mobile_kernel_ebook_reader_38568_39755.png mobile_kernel_ebook_reader_39756_40031.png mobile_kernel_ebook_reader_40032_40499.png mobile_kernel_ebook_reader_40500_41327.png mobile_kernel_ebook_reader_41328_41819.png mobile_kernel_ebook_reader_41820_42479.png mobile_kernel_ebook_reader_42480_42611.png mobile_kernel_ebook_reader_42612_42947.png mobile_kernel_ebook_reader_42948_43871.png mobile_kernel_ebook_reader_43872_44135.png mobile_kernel_ebook_reader_44136_44183.png mobile_kernel_ebook_reader_44184_44375.png mobile_kernel_ebook_reader_44376_44543.png mobile_kernel_ebook_reader_44544_44591.png mobile_kernel_ebook_reader_44592_44891.png mobile_kernel_ebook_reader_44892_46235.png mobile_kernel_ebook_reader_46236_46391.png mobile_kernel_ebook_reader_46392_47327.png mobile_kernel_ebook_reader_47328_47639.png mobile_kernel_ebook_reader_47640_48563.png mobile_kernel_ebook_reader_48564_48803.png mobile_kernel_ebook_reader_48804_48875.png mobile_kernel_ebook_reader_48876_49211.png mobile_kernel_ebook_reader_49212_49319.png mobile_kernel_ebook_reader_49320_50207.png mobile_kernel_ebook_reader_50208_50339.png mobile_kernel_ebook_reader_50340_50399.png mobile_kernel_ebook_reader_50400_50747.png mobile_kernel_ebook_reader_50748_50855.png mobile_kernel_ebook_reader_50856_50975.png mobile_kernel_ebook_reader_50976_51059.png mobile_kernel_ebook_reader_51060_52019.png mobile_kernel_ebook_reader_52020_52583.png mobile_kernel_ebook_reader_52584_53615.png mobile_kernel_ebook_reader_53616_53819.png mobile_kernel_ebook_reader_53820_54095.png mobile_kernel_ebook_reader_54096_56579.png mobile_kernel_ebook_reader_56580_57515.png mobile_kernel_ebook_reader_57516_57827.png mobile_kernel_ebook_reader_57828_58542.png
Hello everybody, welcome. My name is Andreas Kimnate and I will talk about the two words using regular Linux on ebook readers, especially with Kobo and Tolino readers. First I will tell you a bit about me, the motivation behind all that and about the devices. Then I will go from down to up system, from bootloader to kernel and then the user space and share changes. I will also show my favorite use case maps and how the display feels like. Then some videos. So if I am not taking something, I am often doing some outdoor stuff. In summer vacation I usually do long bicycle trips, often in sparsely populated areas in northern Europe. So I am a bit on my own there. Of course I have some Linux mobile device with me. I had an PDA in former times and also the Moku. So the motivation behind all my work is to solve my outdoor problems. So it can only be done in my spare time. The ebook readers I am involved with are the Kobo Clara HDs, my first one. And also I talked to someone, persuaded him to buy the Stein 3 because we both thought they are equal but that was not the case. They are not so equal. So I helped them with porting it and I found a used GTO2, a used Shine 2. And I imported it also there. And for comparison I get my hands on some defective H2O and for some very condensing atmospheres I bought Vision 5 for example like the showing star maps. So what do I want basically? A bit of computer in the middle of nowhere. So I prefer to have little power consumption instead of sick batteries and it should be the data I'd readable. And having it with me should not prevent me from relaxing too much. It's a powerful enough to look at for example the coronavirus site all the time. That's a bit more relaxing. And also a bigger display. It's helpful if you do some planning and not just going from simply going from A to B. So some nemic planning and you can and also like I'd actually be able to have some information stored with me. And of course doing some text work is always nice to be able to do that. And contrary to the other devices I had before, here I can find something similar kind of next corner and so I feel that my work experience is not lost if I shoot another device. So it's basically master one device, master next one easily. So about the devices, there's a Tolino Alliance consisting of mainly German bookstores to compete with Amazon kindle more easily. The brand Tolino belongs to Gutenkobo, so you find similar devices. They use most than ordinary file formats, so also the original software is of quite some use. So you have often several pairs of almost identical devices. There's just a different pin compatible SOC. So it's the IMX6 Solide Tolino devices and the IMX6 SLL and Kovu devices. And it almost identical was Pitfall for me, so I mentioned that with the Shine 3. And the vendor software on the Tolino, it's Android based system on a 3.0 based kernel. But there's also some quite new boot things on Kovu. You have something a bit newer. But this all asked to be replaced by something newer, so you can use ordinary stuff on it. More newer stuff. So how can they easily be hacked? What can you do with them? The non-waterproof device have internal microSD slots, contains a world operating system and a bootloader. So can be replaced by something big and you can have backups. The waterproof device usually have EMMC. It's a bit more tricky. You can break it. The space is a bit mislimited. Probably not. You put some Wikipedia on it. We all have some serial console, easily accessible and also some fast boot. At least the Kovu bootloader allows to use USB mass storage. And there's some I'm in specific recovery over USB. If no bootloader is found, like no microSD in or in the EMMC devices, the device is zeroed where it does not look like a bootloader. And you can enter this mode also by writing some magic values into some registers and then reset. There was once an 8 gigabyte card in here. I've changed it, replaced it. And also the console is clearly marked. And interestingly, next set there's another UART. So you can attach your favorite peripheral to it if you want. So how do I debug these things? I remove the back cover and buy some sleep cover for it and put a hole in there. So I have some debug cover and I'm accessing this band with some poro pins. Here also with some Lutus adapter so I can access it wireless. Yep, so no wires attached there. Was something looking ugly. So now let's talk about UBoot, the bootloader. The vendor UBoot has some special behavior. The bootM and bootZ commands are modified. They load blocks from hidden partitions and also append things to the kernel arguments, also the keyword required sometimes. And if no kernel is loaded yet using a special command, they tend to override things. So if you are just loading the kernel from the desk, you have to take care of it to some tricks. And for some reason deep sleep on mainline kernels with to combination with Tolino vendor UBoot it doesn't work reliably for whatever reason. There's a fork of the... So I decided to replace it by something new. So downside is that booting the vendor systems is a bit more tricky because you need to load this hidden partitions and pass the addresses to the kernel command line. I did not manage to boot the Tolino vendor kernel visit yet. Well, but contrary, buttons and LED is easily accessible for boot options. Like booting the dual booting the original systems or doing some recovery things. And they're just more easily configurable. Big pen we tested using that USB recovery boot. So you can test a run before writing it to flash. So you can avoid breaking your devices. So now let's talk about the kernel. What's already in there. The device is for the devices I'm involved with. And the Pimic for battery realtime block, it's upstreamed for touchscreen. The touchscreen for the Shine 2 HD is upstream already for a longer time. And the Wi-Fi, some devices have a Broadcom based Wi-Fi with drivers upstream. So what's missing, there are patches for the touchscreen already on the mailing list. That's a review and it covers a lot of devices. As of the devices mentioned here, it's also the remarkable tool. So the Pine node and then there is the real tech chip that's only in out of 3 driver. So it's only in out of 3 driver, seems to be no upstream work active. The biggest construction site is the display. It's not mainlined at all. But I have a DIM variant of the driver in preparation. I think I will send out an IFC patch series soon. To use the display you also need a driver for some EPD Pimics. And the most recent code for this is online my shithub repository. So you can check out and test. I have documented some quirks like how to convince fastboot to take that kernel and also the individual status for several devices. So now out the display. What's the most interesting part? The third clue is we need a list of non-overlapping damaged rectangles. Pass them through. So it's first for the convert them to gray. And several EboGridas have rotated displays. We need to rotate it here. Also on the IMAX 6SL, the PHP does faith form processing. It's not well documented. But the things go to the display controller and then to the display. My DRM driver does not use the display yet because the implementation mainline is too limited. It's too limited. And the EPDC needs some waveform blob to operate. So what are the challenges here? You need to get these rectangles. So I get the API and provide something which is already used for other devices like command mode, DSI displays. So the user space is prepared for it. Then the vendor kernel uses frame buffer devices and special IOControls which need special programs to handle. So if you use ordinary programs, you will just need to track damage events of XORG either by patching the frame buffer driver or by running a special program on top of XORG and catch the damage faster or you have other mechanisms to recognize change memory areas. But that usually results in full horizontal stripes to be refreshed. And especially that's ugly if two small rectangles damage which distance. Stabilize rebrand forms, the display gets drienson. I have quite strange code in my driver. make things work. That's all a bit disgusting. These are stored in didn't partitions and I'm copying to the firmware directory and it's loaded. So now let's talk about distributions. There's post marketOS which supports the codeclarer hd and the shine tool. So you clone your SD card, install post marketOS on it. The first boot the waveform is copied from the hdn partition and then there is also a layer on top of open embedded for the codeclarer hd. There's a LittoxOS. There are some special Ipopia software distributions. They are using the Endocals and so using this special IOControl things. So now to my favorite use case, Maps navigation. I'm using some special USB cable to attach power source and shivers receiver. Power source is my bicycle hub dynamo. We can also use the secondary UART. I had the former software already in place so I used that. About Maps, the standard OpenStreetMap style is hardly readable. Some topographic maps from Swedish and German state agencies seem to work surprisingly well. There's also Navit. So this is Navit with OSM data and routing in sunlight. Quite readable. There's the OSM standard and I improve them a little bit by exchanging street borders. The grey with black. But there's still a lot of work to do here. And then Control is a map from the Swedish state agency. It's easily readable and under a nice license. Similar experience with not so free maps from Germany. So now let's look at some videos. How the display looks like. So I'm routing the system here. This is the Shine 2. This is my DIM driver. Now it's starting. You see the cursor. You can move it. Okay. Now this is post market with XFCE4. I'm unlocking my screen. Yes. You see some shadows from a display. Now I have my terminal. Now it's time for your questions. That's it. We are live. Andreas, thank you very much for the talk. So we can get started with the questions. We have quite a few. Starting from the first one. Which of the ebook readers did you find most pleasant to hack on and why? I mostly prefer the ebook readers first in microSD card because I can easily back up the whole system and cannot damage too much things. So I can. So less chances to break them. My favorite is still the Kuroklara HD. And also there's a once with some, this is second Siri port. Also nice for hacking. You can attach something to it. Just more possibilities and also getting a big microSD card. You have seen in my pictures I have some 128 there. That's also helpful to keep also the original system there for it while booting something. Thank you. Are you aware of any work for main lining Linux on the Amazon Kindle devices? I'm not aware of anything there. I personally don't. I've not looked too much into that because that was too much fields to look to even support. Okay. So next one was a maps. Maps for navigation. Well, it works. Well depends on the style. So you have quite a quite different experience. So standard OSM style. It's hardly usable, but never itself. It works. And I've successfully used it. Next one. Which of see. So I lost your video stream for a while. I don't know if other people are seeing you. So I'll move on. Another question related to the previous one. Which of the book readers do you find most pleasant to use and why? For all this auto stuff and stuff I would prefer the more waterproof ones. But that's clearly contradicts this. This ability so I would just for just with just about reading ebooks I would prefer the waterproof ones and so you don't need to be that careful with this water and that things out. I'm out. Thank you. Then moving on. Do you think that OEM will become more friendly towards the first projects in the future? Well, the ebook readers at least you can ask for sources and say respond. But it does not feel too much about contribution. So when I reported Kernel errors or something, it somehow got fixed after some year and there was no response. But what I think if there is more stuff in my main line, especially the EPC driver, maybe, but on the other hand, it's often I think they are a bit competitive with the issues there. So they don't like to they may they must start to adapt their software that they have hard-coded past to better into the better battery capacity, which includes the ship name and then patch the kernel so that regardless of what ship it's really is, just renamed in the kernel. So somehow I have my doubts there. Thank you. And the next question, since Kobo and Torino share almost identical hardware, but the former on Linux and the latter Android, is there any chance of further more interoperability and cross development? If it's about the different SOTs, then even the other the reboot of the other device doesn't find the MMC, so it already stops there. If the devices are similar, then devices are similar and have the same SOT, then there are some reports that the Kobo firmware boots on Torino firmware and vice versa, with some limited functionality, had a very fully working people have tried that. But if it's all this about the different SOTs, then there's a problem that probably either since they then they are different kernel versions, then the user space would have to be adapted. And so it's not probably not so easy. And getting the vendor kernel on the other processor to work, that will be a nightmare. Since you all three 3.0 kernel used on the SL devices are different, don't use device tree, and these old kernels do not support the SL processor, so that will be a nightmare. Thank you. We have 30 seconds left for maybe one last question. How big are the EMMCs on these devices? Once I get in touch with it, it was eight gigabytes. But on the newest ones, I've seen something about 32, but eight gigabytes is common. Well, on some older, for a bit.
Kimnate and I will talk about the two words using favorite use case maps and how the display feels something, I am often doing some outdoor stuff. find something similar kind of next corner and so original software is of quite some use. So you world operating system and a bootloader. So can console, easily accessible and also some fast with drivers upstream. So what's missing, there through. So it's first for the convert them to some waveform blob to operate. So what are the challenges here? You need to get these you clone your SD card, install post marketOS on software distributions. They are using the things. So now to my favorite use case, Maps state agencies seem to work surprisingly well. card because I can easily back up the whole can. So less chances to break them. My favorite once with some, this is second Siri port. Also stuff in my main line, especially the EPC driver, So they don't like to they may they must start to adapt their software that they have hard-coded device tree, and these old kernels do not support