Kobo v5 support#12401
Conversation
No, I'll ultimately be creating a new TC for it, which means a new target, so said new target can simply use the new packaging method without affecting anything else. |
Feel free to steal the branching from my nickel-v5 branch and just change the args in the "new" branch ;). |
|
Regarding dropbear: v5 firmware includes an updated libcrypt. Copying
|
|
Option 4 is the new TC, which should mean we'll build against the new libxcrypt automagically ;). (I'm planning on working on this next week, FWIW). |
I'm curious as to why, exactly, as I don't think I noticed anything different in the FW on that front. Can you post the syslog ( |
|
Ah, usbMS detects the wrong platform. I also wrote a small tool for myself to disable charging above 85% to prolongue battery life. Unfortunately, usbms uses the charging flag of the charger to detect a USB connection :-( Do you have the sources for the usbMS tool? I didn't find them in the repo but it says your toolchain built it :D |
Yep, the NTX "Am I plugged in?" ioctl will horribly implode the kernel on MTK, so beggars can't be choosers ;p.
It relies on Which reminds me, most of the fuckery in the startup script about that sort of stuff can just rely on
Yup, it's hosted under the koreader org: https://github.com/koreader/KoboUSBMS |
|
Note that the syslog snippet is clipped, so I'm not entirely sure the device detection went all that well in C-land either ;). |
Oh, yeah, no, it isn't, because we attempt to pull it from udevd, which no longer has it set. At a quick glance, only nickel & dbus will have it set. So, yeah, probably just source EDIT: Except for |
And it's a fallback because we actually expect it to be set via the launcher, because kfmon and/or nickel were guaranteed to have it given how they were launched (via rcS) on v4 ;). (Same for |
|
Ah, the missing syslog follows, but there is no more useful information. I really need to be doing something else right now, thanks for all your work, I'll follow up here in the next days :) |
Actually, doing that in KFMon sort of makes more sense, so, NiLuJe/kfmon@29180ab should have taken care of it ;). |
|
Can confirm USBMS working with that change. We might still want a workaround inside usbms? I notice that we have three more processes we might want to kill: memorylogger dumps mem stats to usb storage in regular intervals, I guess QtWebEngine is the underlying engine for the new nickel? |
Sounds good to me! On a related note, I guess it probably makes more sense to actually call (Plus dealing with the boot anim being Keep in mind that having Nickel hot-restart sanely has been sort of a dark art in the past, so I'm not even sure it'll actually work ;). |
Nah, it was pretty much built under the assumption the env would be sane, I didn't want to have to maintain the same brittle stuff in a gajillion different places ;). |
|
Okay, restart of nickel is straight forward -> Working :) |
|
I am still using this as a daily driver and it works flawlessly. Once, I had a battery drain of 60% in 2 days of non-usage, but it was in my bag and maybe some sensor stuff was happening... |
|
I'm hoping to get to it sometime in the next two weeks, but, yeah, definitely don't hold out on my account, building with the old TC works perfectly fine if you forget SSH (which you should, the plugin is unmaintained and the dropbear version is horrendously old) ;). |
|
The TC is alive (and extremely untested). ;p. I'll be building the full set during the night to double check that I didn't break anything when fixing other things along the way, and run some actual tests on a full KOReader build tomorrow. c.f., https://github.com/NiLuJe/koxtoolchain (where the GH action might actually yield some binaries if I didn't break anything). |
kobov4 exists solely because there's a dedicated TC for it, but we don't distribute binaries for it (it doesn't differ enough from kobo, and experience has taught us that this kind of split was not a great idea (e.g., kindle5 vs. kindlepw2)). kobov5 targets a massively updated userland, and requires further changes, including to the delivery mechanism, so it very much warrants a dedicated package (re: koreader#12401)
kobov4 exists solely because there's a dedicated TC for it, but we don't distribute binaries for it (it doesn't differ enough from kobo, and experience has taught us that this kind of split was not a great idea (e.g., kindle5 vs. kindlepw2)). kobov5 targets a massively updated userland, and requires further changes, including to the delivery mechanism, so it very much warrants a dedicated package (re: koreader#12401)
kobov4 exists solely because there's a dedicated TC for it, but we don't distribute binaries for it (it doesn't differ enough from kobo, and experience has taught us that this kind of split was not a great idea (e.g., kindle5 vs. kindlepw2)). kobov5 targets a massively updated userland, and requires further changes, including to the delivery mechanism, so it very much warrants a dedicated package (re: koreader#12401)
kobov4 exists solely because there's a dedicated TC for it, but we don't distribute binaries for it (it doesn't differ enough from kobo, and experience has taught us that this kind of split was not a great idea (e.g., kindle5 vs. kindlepw2)). kobov5 targets a massively updated userland, and requires further changes, including to the delivery mechanism, so it very much warrants a dedicated package (re: #12401)
|
Okay, we need to find a way to rerun the init code from |
|
@Frenzie @vzsze |
The @PeeK1e build system seems to work here. I used it yesterday evening and double checked again today. |
|
Also can someone point me on how to include this in CI build? looks like CI builds the kobo target-- it should build kobov4 and also kobov5. |
|
The CI does not build all targets. The nightly builder on gitlab (https://gitlab.com/koreader/nightly-builds) does. |
@Jogai If you were looking for the artifacts on GitLab, it seems I have forgotten to add a "no-expiry" on those. The old builds are gone but I triggered a new build and it's available on my gitlab artifact storage again. The current patches also seem to work on my Tolino and exiting Koreader no longer crashes the UI :) |
| # A SIGTERM does not break anything, it'll just prevent automatic lease renewal until the time | ||
| # KOReader actually sets the if up itself (i.e., it'll do)... | ||
| killall -q -TERM nickel hindenburg sickel fickel strickel fontickel adobehost foxitpdf iink dhcpcd-dbus dhcpcd bluealsa bluetoothd fmon nanoclock.lua | ||
| killall -q -TERM nickel hindenburg sickel fickel strickel fontickel adobehost foxitpdf iink dhcpcd-dbus dhcpcd bluealsa bluetoothd fmon nanoclock.lua memorylogger QtWebEngineProcess |
There was a problem hiding this comment.
What's the relevance of this memorylogger process? The name sounds fairly innocuous.
There was a problem hiding this comment.
We restart that when we exit (via rc.local). it is a process that monitors system and esp. nickel memory usage and logs it to the /mnt/onboard storage.
|
I would wait until we get the USBMS patches (koreader/KoboUSBMS#7) in, so mass storage handling is done properly. Then, we would need another commit in koreader-base referencing that one and another one (here?) referencing the updated base. Alternatively, if that is supposed to be different MRs, this one doesn't need to wait. The nightly build process to me looks like I cannot really support getting it for kobov4+kobov5 as it needs an additional docker image with the right toolchain? That should all work - tell me if there is something I can do. |
|
I think there were some unresolved comments by @NiLuJe but let me stick a target on it to apply some pressure. ;-) |
|
Our kokobo docker image includes both kobo and kobov5 toolchains. I think kobov4 is for legacy kobo platforms? |
I think (didn't check) kobo is what is currently used and is only for v4 targets but has been renamed to v4 for clarity. I guess we can get rid of kobo and have v4 + v5? Alternatively, leave kobo and just add v5. |
Actually, the
So the kobo toolchain supports older legacy platforms. |
|
Hm, so we might want 3 kobo builds? afaik @NiLuJe might have a better understanding about the topic and can give some insight :-) |
|
I think all platforms supported by |
|
IIRC, we don't use kobov4 for KOReader, as we want to keep supporting old FW versions (for our good old kobo/"v4" packages). (It was created for stuff that will only ever care about supporting 4.6+ or whatever the glibc cutoff was ;p). Likewise, we could use the kobo TC to build for v5, but since we have access to both and we need a different package anyway, it's trivial to "silently" upgrade to kobov5 for those, as they wouldn't run on v4 anyway (I'm assuming swapping a Tolino to "kobo mode" wipes the userstore, so we don't care about supporting that use-case. I don't even know if that keeps the tolino or the kobo glibc, so this point may be moot anyway). |
|
TL;DR: Yeah, basically what @benoit-pierre just said ;p. |
The "modern" tolinos have exactly the same firmware for tolino and kobo, i expect no changes in glibc versions, all strings are runtime hw check results... I remember as written above that v5 needs the upgraded libcrypto at least for dropbear that only comes with the new toolchain, so I don't think we can build with older toolchains. There is still some review comments from you that are partly quite old - can you please comment on the relevant or close the irrelevant ones? I have some motivation to finally get this merged :D |
|
Right, I'd forgotten about the libcrypto thing ;). |
koreader/koreader-base#2243 should have taken care of the libcrypto issue, no? |
Sorry, brainfart… That's for pocketbook, but we can do the same on Kobo. |
|
I added the dropbear static linking fix also for the kobo target, recompiled everything with the kobo toolchain (prebuild 2025-05, because i cannot compile it on archlinux, there is more to fix for GCC15 than in the kobov5 toolchain), wiped my koreader installation on the ereader and put this one. It works as well. Feels a bit "sad" to not use the more modern CPU target arch, but i didn't do performance analysis. How to proceed? |
|
We have the toolchain and everything, so I don't really see any downside in using the kobov5 TC here, I just wanted to note for DIYers that you could technically use the "older" TC ;). |
|
It's working with firmware version 5.15.253009. I had to reinstall Kfmon, like after every firmware update. |
kobov4 exists solely because there's a dedicated TC for it, but we don't distribute binaries for it (it doesn't differ enough from kobo, and experience has taught us that this kind of split was not a great idea (e.g., kindle5 vs. kindlepw2)). kobov5 targets a massively updated userland, and requires further changes, including to the delivery mechanism, so it very much warrants a dedicated package (re: koreader#12401)
|
On 5.15.253009 (938d08ad9c, 4/27/26), USBMS doesn't work. Its screen shows "please disable your custom usb gadget manually". Looking at And sure, there's a gadget set up in sysfs. Please let me know if you need more info. |
|
@NerdyProjects Was this ready to merge? I'm not sure if I quite understand the todo list in the OP with things scratched out. ;-) |
This adds basic support for the recent v5 line of Kobo firmwares.
It is not production ready and I also did not yet include a generator for update.tar.
Should the kobo target just output two files?
Also see #12047 and NiLuJe/kfmon#11
ToDo
-son older readersgenerate update.tarupdate toolchain with new target for kobo_v5nickel.sh(currently: reader reboots)nickel.shagain :-)fix sshd (libcrypt.so.1 missing; might be fixed with new toolchain)maybe todos
fix USBMS (currently: needs right environment set which works via updated kfmon)This change is