search

odudex / krux

Open-source, airgapped hardware signer for Bitcoin
https://selfcustody.github.io/krux/
Other
10 stars 2 forks source link

On `pip install kflash` as an alternative to flashing w/ krux #24

Closed jdlcdl closed 1 year ago

jdlcdl commented 1 year ago

Just to leave record of a brick-ish experience I had yesterday, (which I believe @tadeubas had as well):

Existing docs, to be changed soon, imply to use pip3 install kflash and then to flash a device w/ kboot.kfpkg.

But if we instead use kflash to install firmware.bin, then it will install the firmware at 0x0 instead of 0x80000. The device will work only until an air-gapped upgrade is performed, which will corrupt SPI Flash around 0x4000 because it expects Kboot's main config to be there. The result is that the device will not reboot, it won't even power down properly. User must disconnect energy to the board or wait until battery discharges, then flash again using kboot.kfpkg which will flash Kboot stages 0 and 1, main and backup configs, and firmware where Kboot and krux expect them to be.

As a better alternative, I like to use the same ktool.py which the krux script uses and which is available in a locally cloned repo. It has a well documented --help argument. Consider getting to know this tool; it's a savior when my amigo seems bricked.

Note: for the below commands, they assume you're in a local krux repo like ~/krux and you've already done a ./krux build maixpy_device_name so that ./build/firmware.bin and ./build/kboot.kfpkg exist. If this is the case, your environment is either already setup, or you prefix python commands w/ poetry run python; however you do it, do it below as well.

All commands below assume that $BOARD is set:

export BOARD=dan    # for maixpy_dock
export BOARD=goE    # for other boards

If you want a flash dump into /tmp/k210.flash_dump, (for a brick, or new install, or just for analyzing SPI Flash):

./firmware/Kboot/build/ktool.py -B $BOARD -R -a 0x0 -L 0x1000000 /tmp/k210.flash_dump

note: default baud rate is slow, this will take ~30m; faster baud rates are problematic in my experience.

To erase the entire 16MB of SPI Flash, efficiently setting all bytes to 0xff, for a clean slate:

./firmware/Kboot/build/ktool.py -B $BOARD -b 1500000 -E

To install everything (Kboot stages 0 and 1, main and backup config, and firmware into slot1):

./firmware/Kboot/build/ktool.py -B $BOARD -b 1500000 ./build/kboot.kfpkg

To install ONLY firmware.bin into slot1, without touching the main config which might be pointing to slot2:

./firmware/Kboot/build/ktool.py -B $BOARD -b 1500000 -a 0x80000 ./build/firmware.bin

or into slot2:

./firmware/Kboot/build/ktool.py -B $BOARD -b 1500000 -a 0x280000 ./build/firmware.bin

To boot a new firmware w/o modifying SPI Flash (given settings are not changed, else SPIFFS will be touched), so that you can temporarily test a new firmware on your device (until reset or power-off):

./firmware/Kboot/build/ktool.py -B $BOARD -b 1500000 -s ./build/firmware.bin
odudex commented 1 year ago

Kflash references on docs (Installing->From Source->Flash the firmware onto the device) will be removed to avoid secondary issues. Change already on PR: https://github.com/selfcustody/krux/pull/239

tadeubas commented 1 year ago

Thx @jdlcdl for the info! It is nice to know that it is possible to flash on the right memory address using the .bin instead of the .kfpkg.