geekhack Projects > Making Stuff Together!
Hacking HHKB Professional Classic
Duncaen:
I think I'm typing this from the first HHKB Professional Classic running qmk. There is still a lot of work to do, but the basics are working.
The current code:
https://github.com/Duncaen/qmk_firmware/tree/hhkb_classic
I'm currently flashing the firmware by shorting BOOT0 to get into the DFU bootloader, which is a bit cumbersome.
I don't think there is a way to make it boot into the dfu bootloader without doing that so I might need to come up with a better solution.
Maybe some flash mode while qmk is running similar to the original firmware, maybe also using the dual bank mechanism.
I'm still trying to find out what the best values to use are for the activation point of the switches is and if it would be better with per key values which I think the original firmware does, the gist from hasu has some info about calibration data in EEPROM.
hasu:
Great job!
Let us know if you have any your new find or correction on my note.
Duncaen:
Here are the most interesting addresses in the eeprom:
--- Code: ---0x08080000 u8[128] keymap_hhk_layer_0
0x08080080 u8[128] keymap_hhk_layer_1
0x08080100 u8[128] keymap_mac_layer_0
0x08080180 u8[128] keymap_mac_layer_1
0x08080200 u8[128] keymap_win_layer_0
0x08080280 u8[128] keymap_win_layer_1
0x08080300 u16 keymap_eeprom # 0xAAAA to load keymap from eeprom, otherwise default keymaps from flash are used.
0x08080310 u8[64] keyboard_info
0x08080350 u16 keyboard_info_eeprom # 0xAAAA to load info from keyboard otherwise data from flash is used.
0x08080360 bool boot_bank2
0x08080370 u16 bank2_crc16
# crc16(-ccitt?) polynomial=0x1021 initial_value=0xFFFF reverse_input=True reverse_output=True final_xor_value=0x0000
0x08081100 u16[128] actuation_points_0
0x08081200 u16[128] actuation_points_1
# If the first value in actuation_points_1 is zero all calibration is disabled.
# My eeprom only the first value is 1 everything else is 0, actuation_points_0 contains the actual data.
# When sensing a key, the firmware adds both values for a key; actuation_points_0[key]+from actuation_points_0[key]
0x08081330 u8[4] firmware_version_0 # boot
0x08081338 u8[4] firmware_version_1 # bank2
--- End code ---
I've been using this dapboot branch https://github.com/Duncaen/dapboot/tree/hhkb as second stage dfu bootloader which works well to flash changes without having to open the keyboard. My qmk branch has a `keyboards/hhkb/classic/dapboot` keyboard with the right ldscript and the right configuration to make lshift+rshift+esc reset into dapboot.
I did waste quite some time with trying to get qmk boot on the "second bank" flashing with the original firmware on bank1, but I was unable to actually get it working because the bank 1 firmware changes the clocks which for some reason makes chibios unable to initialize and without a debugger I'm not really able to see what is actually going wrong.
The firmware files basically just have a 2 crc16 at the beginning of the file, the first one is checked by the keymap tool and include the trailing 0xFF and the "compatible model" things that are easy to follow thanks to the decompiled keymap tool.
The second crc16 is just for the firmware binary and is what the keyboard checks after finishing the firmware update and then is written to the eeprom, this checksum is being checked each boot and it will not switch to bank2 if it doesn't match.
There also seems to be some hidden key combination in the original firmware, not sure if this is documented somewhere and/or actually works, holding `fn+rshift+v` should after some time send the firmware version and then some bytes from ram I don't really know what they are.
yamamech:
--- Quote from: Duncaen on Sun, 15 January 2023, 15:31:47 ---I'm currently flashing the firmware by shorting BOOT0 to get into the DFU bootloader, which is a bit cumbersome.
--- End quote ---
I'm currently trying to flash your firmware to my PD-KB401, but I can't figure out how to get the board into recovery mode as there doesn't seem to be any labels for a BOOT0 pin to get it into recovery mode. Is it by any chance that I'd be right in assuming it's labelled PSW2 on the board with the USB C port on it?
EDIT:
I looked up the pinout and saw that BOOT0 is on pin 60, if this is the right pin for the bootloader, what pin should I short it with / what should I use on the other end to short it?
Duncaen:
--- Quote from: yamamech on Fri, 17 February 2023, 12:10:51 ---
--- Quote from: Duncaen on Sun, 15 January 2023, 15:31:47 ---I'm currently flashing the firmware by shorting BOOT0 to get into the DFU bootloader, which is a bit cumbersome.
--- End quote ---
I'm currently trying to flash your firmware to my PD-KB401, but I can't figure out how to get the board into recovery mode as there doesn't seem to be any labels for a BOOT0 pin to get it into recovery mode. Is it by any chance that I'd be right in assuming it's labelled PSW2 on the board with the USB C port on it?
EDIT:
I looked up the pinout and saw that BOOT0 is on pin 60, if this is the right pin for the bootloader, what pin should I short it with / what should I use on the other end to short it?
--- End quote ---
R6 and R85 as seen on this picture from hasu https://i.imgur.com/oTwQLPg.jpeg. I just used a jumper wire without soldering, I plugged the usb cable half in, positioned the jumper wire so that they press against the right side of R6 and R85 with one hand and then plugged in usb with the other hand, this takes some tries to get right the first time, if the keyboard boots into the dfu bootloader the led will be orange.
Edit: Make sure you make backups of the flash and eeprom with dfu, I would also be interested in looking at you eeprom to compare the actuation points.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version