Closed KevinOConnor closed 3 months ago
Would this also work to reflect the settings chosen in make menuconfig
dialog as a troubleshooting means if a firmware file has been built with the correct settings?
This PR just adds an "app" and "license" field to the dictionary. It is possible to add other fields, though typically that is done through the DECL_CONSTANT()
system.
The "constants" info is reported during startup. It looks like:
MCU 'mcu' config: BUS_PINS_i2c1=PB6,PB7 BUS_PINS_i2c2=PB10,PB11 BUS_PINS_i2c1a=PB8,PB9 BUS_PINS_spi3=PB4,PB5,PB3 INITIAL_PINS=!PA14 STEPPER_BOTH_EDGE=1 ADC_MAX=4095 PWM_MAX=255 CLOCK_FREQ=72000000 BUS_PINS_spi1=PA6,PA7,PA5 RESERVE_PINS_USB=PA11,PA12 MCU=stm32f103xe STATS_SUMSQ_BASE=256 BUS_PINS_spi1a=PB4,PB5,PB3 BUS_PINS_spi2=PB14,PB15,PB13
It's typically possible to work back to the major kconfig settings from the existing "mcu constants" report. Although it is technically possible to record the entire Kconfig .config
file in the data dictionary, it's not really practical because it would notably increase the flash usage of the mcu (as Kconfig produces tons of "secondary settings" and I don't know of a way to extract just the "primary settings").
-Kevin
Ah, a pity. Would have been useful to quickly get the "primary settings". Thanks for considering.
For identification purposes it can be useful to extract a flash image and scan its contents. The binwalk tool (eg, https://manpages.org/binwalk ) can already rapidly locate and extract the Klipper data dictionary from a flash image. However, the data dictionary doesn't actually state that the image is Klipper. This PR changes the build scripts to put the "Klipper" name and its license (GNU GPLv3) in the image so that that information is rapidly available.
-Kevin