Source code to the firmware

[dragetd]

Is the source to the firmware available somewhere?

A programmable controller that sees my keyboard input before my OS does is something that would be nice to have the source of.

[jackhumbert]

I don't this is something that's going to be provided by the manufacturer, but I've made some progress in figuring out where the keymap is stored in the files we have available, and it's currently possible to do some simple substituting: https://github.com/jackhumbert/pinebook-pro-keyboard-updater/tree/master/firmware

[dragetd]

Is there some info on the architecture? Maybe we could at least have some decompiled assembly - might be enough for a simple review.

[jackhumbert]

I've written out most of the functions in c pseudocode from the generated assembly on my fork (firmware/src/main.c). The datasheet is in there as well.

[dragetd]

I see your progress and it is really awesome what you have managed so far!

I still would like the firmware and update to be in separate repositories tho.

[akirakyle]

I've been continuing the reverse engineering effort that @jackhumbert started in my fork here. It's very early in the process and there is still much to learn, and an integral part of that is understanding the firmware update mechanism before making any radical firmware changes so we can avoid hard bricking the controller. As part of that, I'm rewriting the updater in python. Given that the firmware and update utility are so intrinsically linked I don't think it makes sense for them to be in separate repos.

[ayufan]

I think it is better to invest time into rewriting it into fwupd.

…

On Sun, 19 Apr 2020 at 20:56, Akira Kyle ***@***.***> wrote: I've been continuing the reverse engineering effort that @jackhumbert <https://github.com/jackhumbert> started in my fork here <https://github.com/akirakyle/pinebook-pro-keyboard-updater/tree/master/firmware/disassembly>. It's very early in the process and there is still much to learn, and an integral part of that is understanding the firmware update mechanism before making any radical firmware changes so we can avoid hard bricking the controller. As part of that, I'm rewriting the updater in python. Given that the firmware and update utility are so intrinsically linked I don't think it makes sense for them to be in separate repos. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASOSQLYKSQBEDFHZVRYJ2TRNNCN3ANCNFSM4JOOXA4A> .

[akirakyle]

While integrating into fwupd may be an eventual goal, for now the hope is simply to find a way to flash the keyboard micro-controller in a safe way and that requires completely understanding the firmware flashing mechanism. Rewriting the updater tool in python is my way of understanding the host side of the flashing protocol which is not the complicated part. Understanding the 8051 chip's proprietary self programming mechanism by reverse engineering the hex code is difficult part here. It may even turn out that there really is no way to guarantee that flashing anything other than simple firmware overlays not significantly touching program logic won't potentially hard brick the microcontroller which would only be recoverable with a proprietary jtag programmer.

[hughsie]

I don't this is something that's going to be provided by the manufacturer

Has anyone asked them? Coming from the LVFS maintainer the request might get a bit more attention :)