> u-boot will work, but you will get into trouble if you demand users to drop to u-boot > to make changes. On my device I use barebox, which is a bit easier *) to use than U-Boot. Still I don't expect my users to the bootloader. Instead my hardware has a 256 byte i2c EEPROM where I store information. And the user can run a user-space command to change settings there, e.g. uccomm verbose_boot yes uccomm power_config ignition ... and so on. I could do some of them via bootloader environment files, but not all. And this is the other obvious way of doing "communication" from Linux user-space to bootloader: setting the environment. The bootloader could mount the partition and try to source some file, to get the info needed. *) in barebox, you have actual shell-like script that look sane, not variables that call variables, e.g. you can do things like this: if [ $oem_id = 255 ]; then splash -x 550 -y 500 -b 0xffffff /env/logo.png fb0.enable=1 pwm_02080000.period_ns=200000 pwm_02080000.duty_ns=160000 pwm_02080000.enable=1 fi gpio_set_value 191 1 There are also commands available to directly modify the device tree. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
