diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.falcon | 7 | ||||
| -rw-r--r-- | doc/device-tree-bindings/i2c/i2c-stm32.txt | 30 | ||||
| -rw-r--r-- | doc/uImage.FIT/signature.txt | 10 | ||||
| -rw-r--r-- | doc/uImage.FIT/verified-boot.txt | 2 |
4 files changed, 42 insertions, 7 deletions
diff --git a/doc/README.falcon b/doc/README.falcon index e9f8a7583c..9a7f0bc235 100644 --- a/doc/README.falcon +++ b/doc/README.falcon @@ -118,7 +118,12 @@ after each run of 'spl export'. Unfortunately the position of temporary storage can not be predicted nor provided at commandline, it depends highly on your system setup and your provided data (ATAGS or FDT). However at the end of an succesful 'spl export' run it will print the -RAM address of temporary storage. +RAM address of temporary storage. The RAM address of FDT will also be +set in the environment variable 'fdtargsaddr', the new length of the +prepared FDT will be set in the environment variable 'fdtargslen'. +These environment variables can be used in scripts for writing updated +FDT to persistent storage. + Now the user have to save the generated BLOB from that printed address to the pre-defined address in persistent storage (CONFIG_CMD_SPL_NAND_OFS in case of NAND). diff --git a/doc/device-tree-bindings/i2c/i2c-stm32.txt b/doc/device-tree-bindings/i2c/i2c-stm32.txt new file mode 100644 index 0000000000..df03743ace --- /dev/null +++ b/doc/device-tree-bindings/i2c/i2c-stm32.txt @@ -0,0 +1,30 @@ +* I2C controller embedded in STMicroelectronis STM32 platforms + +Required properties : +- compatible : Must be "st,stm32f7-i2c" +- reg : Offset and length of the register set for the device +- resets: Must contain the phandle to the reset controller +- clocks: Must contain the input clock of the I2C instance +- A pinctrl state named "default" must be defined to set pins in mode of + operation for I2C transfer +- #address-cells = <1>; +- #size-cells = <0>; + +Optional properties : +- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified, + the default 100 kHz frequency will be used. As only Normal, Fast and Fast+ + modes are implemented, possible values are 100000, 400000 and 1000000. + +Example : + + i2c1: i2c@40005400 { + compatible = "st,stm32f7-i2c"; + reg = <0x40005400 0x400>; + resets = <&rcc 181>; + clocks = <&clk_pclk1>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c1>; + clock-frequency = <400000>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index 7cdb7bf324..a57cdab339 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -81,7 +81,7 @@ $ openssl rsa -in keys/dev.key -pubout Device Tree Bindings -------------------- The following properties are required in the FIT's signature node(s) to -allow thes signer to operate. These should be added to the .its file. +allow the signer to operate. These should be added to the .its file. Signature nodes sit at the same level as hash nodes and are called signature@1, signature@2, etc. @@ -150,7 +150,7 @@ all available signing keys until one matches. - required: If present this indicates that the key must be verified for the image / configuration to be considered valid. Only required keys are normally verified by the FIT image booting algorithm. Valid values are -"image" to force verification of all images, and "conf" to force verfication +"image" to force verification of all images, and "conf" to force verification of the selected configuration (which then relies on hashes in the images to verify those). @@ -242,7 +242,7 @@ configuration 3 with kernel 1 and fdt 2: With signed images, nothing protects against this. Whether it gains an advantage for the attacker is debatable, but it is not secure. -To solved this problem, we support signed configurations. In this case it +To solve this problem, we support signed configurations. In this case it is the configurations that are signed, not the image. Each image has its own hash, and we include the hash in the configuration signature. @@ -327,7 +327,7 @@ Enabling FIT Verification In addition to the options to enable FIT itself, the following CONFIGs must be enabled: -CONFIG_FIT_SIGNATURE - enable signing and verfication in FITs +CONFIG_FIT_SIGNATURE - enable signing and verification in FITs CONFIG_RSA - enable RSA algorithm for signing WARNING: When relying on signed FIT images with required signature check @@ -336,7 +336,7 @@ CONFIG_IMAGE_FORMAT_LEGACY Testing ------- -An easy way to test signing and verfication is to use the test script +An easy way to test signing and verification is to use the test script provided in test/vboot/vboot_test.sh. This uses sandbox (a special version of U-Boot which runs under Linux) to show the operation of a 'bootm' command loading and verifying images. diff --git a/doc/uImage.FIT/verified-boot.txt b/doc/uImage.FIT/verified-boot.txt index e639e7ae71..41c9fa9e09 100644 --- a/doc/uImage.FIT/verified-boot.txt +++ b/doc/uImage.FIT/verified-boot.txt @@ -93,7 +93,7 @@ include hashes to verify images, so it is relatively straightforward to add signatures as well. The public key can be stored in U-Boot's CONFIG_OF_CONTROL device tree in -a standard place. Then when a FIT it loaded it can be verified using that +a standard place. Then when a FIT is loaded it can be verified using that public key. Multiple keys and multiple signatures are supported. See signature.txt for more information. |