04-20-2021, 03:18 PM
(This post was last modified: 04-20-2021, 03:30 PM by dsimic.)
As @ slyecho noted above, it would be advisable to try flashing the reverse-engineered version of the keyboard firmware. Even if you end up with using 50% of the available writes (four out of eight), it would be worth a try, IMHO.
Edit: I would strongly suggest that you try using " showkey -s" and " showkey -k" on a virtual console to capture the scan codes and keycodes, respectively, for the troublesome Fn keys. Then, we can compare those codes with the ones recorded for the same keys on my PineBook Pro.
I'd already done the showkey thing, and dumpkeys, and something else similar. Anyway this is all Fn-NumLk.
Code: kb mode was UNICODE
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]
press any key (program terminates 10s after last keypress)...
0x9c
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
0x46
0xc6
04-21-2021, 12:15 AM
(This post was last modified: 04-21-2021, 12:43 AM by dsimic.
Edit Reason: Clarified a bit
)
Below are the scan codes returned by " showkey -s" on my PineBook Pro, for pressing and releasing Fn+NumLock a total of three times (more precisely, for keeping Fn pressed, and pressing and releasing NumLock three times, but I also tested the "full-fat" version of pressing Fn, pressing NumLock, releasing NumLock and releasing Fn, and as expected there was no difference in the scan codes):
Code: 0x9c
0x45 0xc5
0x45 0xc5
0x45 0xc5
Somehow, the press scan codes (0x45 vs. 0x46) and release scan codes (0xc5 vs. 0xc6) for Fn+NumLock seem to be off by one on your keyboard. However, the release scan code (0x9c) for Enter seems to be correct.
Another wacky thing is that Fn Priint Screen and Pause have the same scan code. The F7 one for turning off the touchpad really turns off the touchpad, and Fn-F8 insert really works. This is holding down the Fn and going through F1 through Power. Esc/Z tries to suspend but it's not set up.
Code: kb mode was UNICODE
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]
press any key (program terminates 10s after last keypress)...
0x9c
0x7d 0x19
0x19 0x99 0xfd
0x71
0x71 0xf1
0x72
0xf2
0x73
0xf3
0x6e
0xee
0x45
0xc5
0x46
0xc6
0x77
0xf7
0x45
0xc5
0x74
0xf4
But again the only reason I noticed this was that 3 times my num lock got turned on and pressing Fn-NumLk didn't turn it off, it's on 2 other keys instead.
Reported earlier, the "unshifted" F keys are correct. It's only when they are "shifted" with Fn that they are wrong.
This is why I suggest it has to be the firmware. Unless there's another level of abstraction between the microcontroller in question and the physical switches, there can be nothing wrong with the keyboard, or the "unshifted" keys would be wrong.
04-21-2021, 02:07 AM
(This post was last modified: 04-21-2021, 02:53 AM by ab1jx.
Edit Reason: dis51
)
Anybody run this hex code through a disassembler?
http://plit.de/asem-51/dis51.html
Well ok, it disassembles to 95 k bytes, too much to post here. Try it. Just a sample:
Code: L0358:
MOV A, #82h
ADD A, 37h
MOV R0, A
MOV A, @R0
MOV R7, A
CLR C
SUBB A, #90h
JC L0359
LJMP L0360
L0359:
MOV B, #2h
MOV A, R7
MUL AB
ADD A, #15h
MOV DPL, A
MOV A, B
ADDC A, #8h
MOV DPH, A
CLR A
MOVC A, @A+DPTR
MOV 65h, A
MOV B, #2h
MOV A, R7
MUL AB
ADD A, #16h
MOV DPL, A
MOV A, B
ADDC A, #8h
MOV DPH, A
CLR A
MOVC A, @A+DPTR
MOV 64h, A
MOV A, 65h
JNZ L0361
LJMP L0360
L0361:
LCALL L0362
MOV A, 65h
CJNE A, #4h, L0363
JNB 0Ah, L0364
SETB 26h
SJMP L0363
L0364:
CLR 26h
L0363:
JB 0Ah, L0365
LJMP L0366
L0365:
MOV A, 65h
CJNE A, #2h, L0419
MOV A, 64h
CJNE A, #8h, L0420
MOV R0, #15h
MOV @R0, #1h
L0420:
LJMP L0368
L0419:
MOV A, 65h
CJNE A, #1h, L0421
LJMP L0422
L0421:
MOV A, 65h
CJNE A, #3h, L0423
LJMP L0424
L0423:
MOV A, 65h
CJNE A, #5h, L0425
LJMP L0426
L0425:
MOV A, 65h
XRL A, #6h
JNZ L0427
JNB 26h, L0428
LCALL L0394
MOV DPH, A
CLR A
MOVC A, @A+DPTR
MOV R5, A
CJNE A, #0FEh, L0429
JNB 24h, L0430
CLR 24h
RET
L0430:
SETB 24h
RET
L0429:
LJMP L0431
L0428:
LCALL L0396
LJMP L0431
L0427:
MOV A, 65h
XRL A, #7h
JZ L0432
LJMP L0433
L0432:
JNB 26h, L0447
LCALL L0398
MOV DPH, A
CLR A
MOVC A, @A+DPTR
MOV R5, A
LJMP L0431
L0447:
MOV R0, #15h
MOV A, @R0
JNZ L0448
LJMP L0449
L0448:
LCALL L0399
CJNE A, #43h, L0450
MOV R7, #1h
SJMP L0451
L0450:
MOV R7, #0h
L0451:
MOV A, R7
JZ L0452
CLR A
MOV R0, #14h
MOV @R0, A
MOV R0, #17h
MOV A, @R0
MOV R7, A
JNB ACC.0, L0453
LCALL L0454
ANL A, #0FEh
MOV @R0, A
MOV 12h, #4h
SJMP L0455
L0453:
LCALL L0467
ORL A, #1h
MOV @R0, A
MOV 12h, #6h
L0455:
SETB 0C0h
SETB 0C1h
LCALL L0456
LCALL L0138
L0452:
LCALL L0399
CJNE A, #44h, L0457
MOV R7, #1h
SJMP L0458
L0457:
MOV R7, #0h
L0458:
MOV A, R7
JZ L0459
MOV R0, #14h
MOV @R0, #1h
MOV R0, #17h
MOV A, @R0
MOV R7, A
JNB ACC.1, L0460
LCALL L0454
ANL A, #0FDh
MOV @R0, A
MOV 12h, #4h
SJMP L0461
L0460:
LCALL L0467
ORL A, #2h
MOV @R0, A
MOV 12h, #6h
L0461:
SETB 0C0h
SETB 0C1h
LCALL L0456
LCALL L0138
L0459:
LCALL L0399
CJNE A, #45h, L0462
MOV R7, #1h
SJMP L0463
L0462:
MOV R7, #0h
L0463:
MOV A, R7
JNZ L0464
LJMP L0360
L0464:
MOV R0, #14h
MOV @R0, #2h
MOV R0, #17h
MOV A, @R0
MOV R7, A
JNB ACC.2, L0465
LCALL L0454
ANL A, #0FBh
MOV @R0, A
MOV 12h, #4h
SJMP L0466
L0465:
LCALL L0467
ORL A, #4h
MOV @R0, A
MOV 12h, #6h
L0466:
SETB 0C0h
SETB 0C1h
LCALL L0136
MOV R5, #1h
MOV R7, #0A0h
LCALL L0137
MOV R5, #1h
CLR A
MOV R7, A
LCALL L0137
MOV R0, #17h
MOV A, @R0
MOV R7, A
MOV R5, #1h
LCALL L0137
LJMP L0138
L0449:
LCALL L0399
MOV R5, A
LJMP L0431
L0433:
MOV A, 65h
XRL A, #0Ah
JNZ L0434
JNB 26h, L0435
LCALL L0402
MOV DPH, A
CLR A
MOVC A, @A+DPTR
MOV R5, A
LJMP L0431
L0435:
MOV A, 64h
ADD A, ACC
JNB 1Ah, L0436
LCALL L0437
SJMP L0438
L0436:
ADD A, #57h
MOV DPL, A
CLR A
ADDC A, #9h
L0438:
MOV DPH, A
CLR A
MOVC A, @A+DPTR
MOV R5, A
LJMP L0431
L0434:
MOV A, 65h
XRL A, #9h
JNZ L0439
JNB 26h, L0440
MOV C, 0Ah
LJMP L0441
L0440:
SJMP L0422
L0439:
MOV A, 65h
XRL A, #0Ch
JZ L0442
LJMP L0360
L0442:
JNB 26h, L0443
L0444:
MOV A, 0E4h
JNB ACC.3, L0444
MOV A, 0E4h
ANL A, #3h
JNZ L0444
LCALL L0406
LCALL L0143
L0445:
MOV A, 0E4h
JNB ACC.3, L0445
MOV A, 0E4h
ANL A, #3h
JNZ L0445
LCALL L0404
LJMP L0446
L0443:
SJMP L0422
L0366:
MOV A, 65h
CJNE A, #2h, L0367
MOV A, 64h
CJNE A, #8h, L0368
CLR A
MOV R0, #15h
MOV @R0, A
L0368:
LCALL L0369
LJMP L0370
L0367:
MOV A, 65h
CJNE A, #1h, L0372
L0422:
LCALL L0369
LJMP L0373
L0372:
MOV A, 65h
CJNE A, #3h, L0383
L0424:
LCALL L0369
LJMP L0384
L0383:
MOV A, 65h
CJNE A, #5h, L0388
L0426:
LCALL L0369
LJMP L0389
L0388:
MOV A, 65h
XRL A, #6h
JNZ L0393
LCALL L0394
LCALL L0395
LCALL L0374
LCALL L0396
L0431:
MOV C, 0Ah
CLR A
RLC A
MOV R7, A
LJMP L0373
L0393:
MOV A, 65h
XRL A, #7h
JNZ L0397
LCALL L0398
LCALL L0395
LCALL L0374
LCALL L0399
LCALL L0400
SJMP L0373
L0397:
MOV A, 65h
XRL A, #0Ah
JNZ L0401
LCALL L0402
LCALL L0395
LCALL L0374
MOV A, 64h
ADD A, ACC
ADD A, #57h
MOV DPL, A
CLR A
ADDC A, #9h
LCALL L0395
SJMP L0373
L0401:
MOV A, 65h
CJNE A, #9h, L0403
LCALL L0369
LCALL L0374
MOV C, 0Ah
CLR A
L0441:
RLC A
MOV R7, A
MOV R5, #66h
L0373:
LJMP L0374
L0403:
MOV A, 65h
XRL A, #0Ch
JNZ L0360
MOV C, 0Ah
RLC A
MOV R7, A
MOV R5, 64h
LCALL L0374
LCALL L0404
LCALL L0143
L0405:
MOV A, 0E4h
JNB ACC.3, L0405
MOV A, 0E4h
ANL A, #3h
JNZ L0405
LCALL L0406
L0446:
LCALL L0143
L0360:
RET
L0456:
LCALL L0136
MOV R5, #1h
MOV R7, #0A0h
LCALL L0137
MOV R5, #1h
CLR A
MOV R7, A
LCALL L0137
MOV R0, #17h
MOV A, @R0
MOV R7, A
MOV R5, #1h
LCALL L0137
RET
L0406:
MOV C, 0Ah
CLR A
RLC A
MOV R7, A
MOV R5, #8h
LCALL L0370
RET
L0404:
MOV C, 0Ah
CLR A
RLC A
MOV R7, A
MOV R5, #13h
LCALL L0374
RET
8051 instruction set summary http://ww1.microchip.com/downloads/en/De...oc0509.pdf
It would take a lot of time to go through that much assembly code, with questionable end results because no datasheet is available for the keyboard controller.
I'll look into the source code of the firmware update utility and see if it's possible to implement an option to read the current firmware and save it to a file. That would allow a much better insight into the "untouched" and troublesome keyboards.
Possibly, about half of it is just DB statements defining constants though. If you do a grep -v DB there's 47K left.
The sh61f63 datasheet says "instruction set compatible with standard 8051".
It might be possible. I don't have an untouched one to look at. I was trying to see if it was possible that it only works with 16 k chips and not 14 k. But there's a #define MAX_BINLEN (14*1024) in there. Looked like it read back and checked the touchpad code more than the keyboard code though.
That's a ton of code for a keyboard and touchpad!
I'm wondering, if this is on the main board, how is it proprietary to the keyboard and touchpad? I wish I had time; it shouldn't be terribly difficult to reverse engineer the whole works and write new firmware from scratch. But then, I'd rather not get my head into 8051...
04-21-2021, 05:34 AM
(This post was last modified: 04-21-2021, 07:44 AM by ab1jx.
Edit Reason: wip, mutiple usb busses
)
The pbp has how many usb busses and hubs? And only 2 for the user. Try lsusb -v. Somebody said earlier in this thread that it's on the mainboard right next to something. From dsimic: "According to page 20 of the PineBook Pro schematic, the SH68F83Q IC is located on the main board. The schematic puts it behind the J6 connector (#7 in the picture), which receives the keyboard's ribbon cable."
Sounds like a job for hexcmp. Windows only I think but it might work under WINE. https://duckduckgo.com/?q=hexcmp&t=fpas&...&ia=images
I think disassembling both and feeding them into diff would be better, that way the differences are in assembly, not hex. Diff is used to make source code patch files.
|
