* [U-Boot] [PATCH v3 2/5] sunxi: arm64: Increase CONFIG_SYS_BOOTM_LEN to 32MB
2017-12-13 6:03 [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature Jagan Teki
@ 2017-12-13 6:03 ` Jagan Teki
2017-12-13 15:34 ` Maxime Ripard
2017-12-13 6:03 ` [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64 Jagan Teki
` (3 subsequent siblings)
4 siblings, 1 reply; 29+ messages in thread
From: Jagan Teki @ 2017-12-13 6:03 UTC (permalink / raw)
To: u-boot
From: Jagan Teki <jagannadh.teki@gmail.com>
The default value of CONFIG_SYS_BOOTM_LEN, 0x800000, causes error
when uncompressing Image.gz out of FIT image.
Uncompressing Kernel Image ... Error: inflate() returned -5
Image too large: increase CONFIG_SYS_BOOTM_LEN
and loading Image out of FIT image.
Loading Kernel Image ... Image too large: increase CONFIG_SYS_BOOTM_LEN
Must RESET board to recover
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v3:
- none
Changes for v2:
- Add in separate patch with proper commit message
include/configs/sunxi-common.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 786155f..ee1cb39 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -34,6 +34,7 @@
#ifdef CONFIG_ARM64
#define CONFIG_BUILD_TARGET "u-boot.itb"
+#define CONFIG_SYS_BOOTM_LEN (32 << 20)
#endif
/* Serial & console */
--
2.7.4
^ permalink raw reply related [flat|nested] 29+ messages in thread* [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64
2017-12-13 6:03 [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature Jagan Teki
2017-12-13 6:03 ` [U-Boot] [PATCH v3 2/5] sunxi: arm64: Increase CONFIG_SYS_BOOTM_LEN to 32MB Jagan Teki
@ 2017-12-13 6:03 ` Jagan Teki
2017-12-13 15:38 ` Maxime Ripard
2017-12-13 15:59 ` Quentin Schulz
2017-12-13 6:03 ` [U-Boot] [PATCH v3 4/5] docs: README.sunxi: Move sunxi64 documentation Jagan Teki
` (2 subsequent siblings)
4 siblings, 2 replies; 29+ messages in thread
From: Jagan Teki @ 2017-12-13 6:03 UTC (permalink / raw)
To: u-boot
Add verified-boot documentation for sunxi a64 platform.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v3:
- Create separate document file
Changes for v2:
- New patch
doc/README.sunxi | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 193 insertions(+)
create mode 100644 doc/README.sunxi
diff --git a/doc/README.sunxi b/doc/README.sunxi
new file mode 100644
index 0000000..ef4f735
--- /dev/null
+++ b/doc/README.sunxi
@@ -0,0 +1,193 @@
+#
+# Copyright (C) 2017 Amarula Solutions
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+U-Boot on SunXi
+==============
+
+Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
+
+ 1. Verified Boot
+
+1. Verified Boot
+================
+
+U-Boot supports an image verification method called "Verified Boot".
+This is a brief tutorial to utilize this feature for the Sunxi A64 platform.
+You will find details documents in the doc/uImage.FIT directory.
+
+Here, we take Orangepi Win board for example, but it should work for any
+other boards including 32 bit SoCs.
+
+1. Generate RSA key to sign
+
+ $ mkdir keys
+ $ openssl genpkey -algorithm RSA -out keys/dev.key \
+ -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
+ $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
+
+Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
+but need to match to the "key-name-hint" property described below.
+
+2. FIT Input
+
+---------------------------------------->8----------------------------------------
+/dts-v1/;
+/ {
+ description = "FIT image with single Linux kernel, FDT blob";
+ #address-cells = <1>;
+
+ images {
+ kernel at 0 {
+ description = "ARM64 Linux kernel";
+ data = /incbin/("/path/to/linux/dir/arch/arm64/boot/Image.gz");
+ type = "kernel";
+ arch = "arm64";
+ os = "linux";
+ compression = "gzip";
+ load = <0x50080000>;
+ entry = <0x50080000>;
+ hash at 1 {
+ algo = "sha256";
+ };
+ };
+
+ fdt at 0 {
+ description = "Orangepi Win/Win+ Devicetree blob";
+ data = /incbin/("/path/to/linux/dir/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dtb");
+ type = "flat_dt";
+ arch = "arm64";
+ compression = "none";
+ hash at 1 {
+ algo = "sha256";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf at 0";
+
+ conf at 0 {
+ description = "Boot Linux kernel, FDT blob";
+ kernel = "kernel at 0";
+ fdt = "fdt at 0";
+ signature at 0 {
+ algo = "sha256,rsa2048";
+ key-name-hint = "dev";
+ sign-images = "kernel", "fdt";
+ };
+ };
+ };
+};
+---------------------------------------->8----------------------------------------
+
+You need to change the two '/incbin/' lines, depending on the location of
+your kernel image and devicetree blob. The "load" and "entry" properties also
+need to be adjusted if you want to change the physical placement of the kernel.
+
+The "key-name-hint" must specify the key name you have created in the step 1.
+
+The FIT file name is arbitrary. Let's say you saved it into "fit.its".
+
+3. Compile U-Boot with FIT and signature enabled
+
+To use the Verified Boot, you need to enable the following two options:
+ CONFIG_FIT
+ CONFIG_FIT_SIGNATURE
+
+ $ make orangepi_win_defconfig
+ $ make CROSS_COMPILE=aarch64-linux-gnu-
+
+4. FIT Output
+
+After building U-Boot, you will see tools/mkimage. With this tool, you can
+create an image tree blob as follows:
+
+ $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage
+
+The -k option must specify the key directory you have created in step 1.
+
+A file "fitImage" will be created. This includes kernel, DTB,
+hash data for each of the three, and signature data.
+
+The public key needed for the run-time verification is stored in "dts/dt.dtb".
+
+5. Compile Verified U-Boot
+
+Since the "dt.dtb" has been updated in step 4, you need to re-compile the
+U-Boot.
+
+ $ make CROSS_COMPILE=aarch64-linux-gnu-
+
+The re-compiled "u-boot.bin" is appended with DTB that contains the public key.
+
+6. Flash the image
+
+Flash the "fitImage" to a storage device (SD, NAND, eMMC, or whatever) on your
+board.
+
+7. Boot verified kernel
+
+Load the fitImage to memory and run the following from the U-Boot command line.
+
+ > bootm <addr>
+
+Here, <addr> is the base address of the fitImage.
+
+If it is successful, you will see messages like follows:
+
+---------------------------------------->8----------------------------------------
+=> setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p1 rootwait
+=> ext4load mmc 0:1 $kernel_addr_r /boot/fitImage
+16321738 bytes read in 1049 ms (14.8 MiB/s)
+=> bootm $kernel_addr_r
+## Loading kernel from FIT Image at 40080000 ...
+ Using 'conf at 0' configuration
+ Verifying Hash Integrity ... OK
+ Trying 'kernel at 0' kernel subimage
+ Description: ARM64 Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x400800e4
+ Data Size: 6884659 Bytes = 6.6 MiB
+ Architecture: AArch64
+ OS: Linux
+ Load Address: 0x50080000
+ Entry Point: 0x50080000
+ Hash algo: sha256
+ Hash value: 6808fe51ea3c15f31c4510d2701d4707b56d20213c9da05bce79fb53bf108f1a
+ Verifying Hash Integrity ... sha256+ OK
+## Loading fdt from FIT Image at 40080000 ...
+ Using 'conf at 0' configuration
+ Trying 'fdt at 0' fdt subimage
+ Description: Orangepi Win/Win+ Devicetree blob
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Start: 0x40710f24
+ Data Size: 9032 Bytes = 8.8 KiB
+ Architecture: AArch64
+ Hash algo: sha256
+ Hash value: ca3d874cd10466633ff133cc0156828d48c8efb96987fa45f885761d22a25dc1
+ Verifying Hash Integrity ... sha256+ OK
+ Booting using the fdt blob at 0x40710f24
+ Uncompressing Kernel Image ... OK
+ Loading Device Tree to 0000000049ffa000, end 0000000049fff347 ... OK
+
+Starting kernel ...
+---------------------------------------->8----------------------------------------
+
+Please pay attention to the lines that start with "Verifying Hash Integrity".
+
+"Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check
+passed.
+
+"Verifying Hash Integrity ... sha256+ OK" (2 times) means the hash check passed
+for kernel and DTB.
+
+If they are not displayed, the Verified Boot is not working.
+
+--
+Jagan Teki <jagan@amarulasolutions.com>
+13 Dec 2017
--
2.7.4
^ permalink raw reply related [flat|nested] 29+ messages in thread* [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64
2017-12-13 6:03 ` [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64 Jagan Teki
@ 2017-12-13 15:38 ` Maxime Ripard
2017-12-13 16:11 ` Jagan Teki
2017-12-13 15:59 ` Quentin Schulz
1 sibling, 1 reply; 29+ messages in thread
From: Maxime Ripard @ 2017-12-13 15:38 UTC (permalink / raw)
To: u-boot
Hi,
On Wed, Dec 13, 2017 at 11:33:04AM +0530, Jagan Teki wrote:
> Add verified-boot documentation for sunxi a64 platform.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v3:
> - Create separate document file
> Changes for v2:
> - New patch
>
> doc/README.sunxi | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 193 insertions(+)
> create mode 100644 doc/README.sunxi
>
> diff --git a/doc/README.sunxi b/doc/README.sunxi
> new file mode 100644
> index 0000000..ef4f735
> --- /dev/null
> +++ b/doc/README.sunxi
> @@ -0,0 +1,193 @@
> +#
> +# Copyright (C) 2017 Amarula Solutions
> +#
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +U-Boot on SunXi
> +==============
> +
> +Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
> +
> + 1. Verified Boot
> +
> +1. Verified Boot
> +================
> +
> +U-Boot supports an image verification method called "Verified Boot".
> +This is a brief tutorial to utilize this feature for the Sunxi A64 platform.
> +You will find details documents in the doc/uImage.FIT directory.
> +
> +Here, we take Orangepi Win board for example, but it should work for any
> +other boards including 32 bit SoCs.
> +
> +1. Generate RSA key to sign
> +
> + $ mkdir keys
> + $ openssl genpkey -algorithm RSA -out keys/dev.key \
> + -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
> + $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
> +
> +Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
> +but need to match to the "key-name-hint" property described below.
I really think that the very first thing you must talk about in that
documentation is that it will not protect the SPL itself and that this
is not a secure setup.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171213/229e16f8/attachment.sig>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64
2017-12-13 15:38 ` Maxime Ripard
@ 2017-12-13 16:11 ` Jagan Teki
2017-12-14 9:07 ` Maxime Ripard
0 siblings, 1 reply; 29+ messages in thread
From: Jagan Teki @ 2017-12-13 16:11 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 9:08 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Wed, Dec 13, 2017 at 11:33:04AM +0530, Jagan Teki wrote:
>> Add verified-boot documentation for sunxi a64 platform.
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>> ---
>> Changes for v3:
>> - Create separate document file
>> Changes for v2:
>> - New patch
>>
>> doc/README.sunxi | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 193 insertions(+)
>> create mode 100644 doc/README.sunxi
>>
>> diff --git a/doc/README.sunxi b/doc/README.sunxi
>> new file mode 100644
>> index 0000000..ef4f735
>> --- /dev/null
>> +++ b/doc/README.sunxi
>> @@ -0,0 +1,193 @@
>> +#
>> +# Copyright (C) 2017 Amarula Solutions
>> +#
>> +# SPDX-License-Identifier: GPL-2.0+
>> +#
>> +
>> +U-Boot on SunXi
>> +==============
>> +
>> +Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
>> +
>> + 1. Verified Boot
>> +
>> +1. Verified Boot
>> +================
>> +
>> +U-Boot supports an image verification method called "Verified Boot".
>> +This is a brief tutorial to utilize this feature for the Sunxi A64 platform.
>> +You will find details documents in the doc/uImage.FIT directory.
>> +
>> +Here, we take Orangepi Win board for example, but it should work for any
>> +other boards including 32 bit SoCs.
>> +
>> +1. Generate RSA key to sign
>> +
>> + $ mkdir keys
>> + $ openssl genpkey -algorithm RSA -out keys/dev.key \
>> + -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
>> + $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
>> +
>> +Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
>> +but need to match to the "key-name-hint" property described below.
>
> I really think that the very first thing you must talk about in that
> documentation is that it will not protect the SPL itself and that this
> is not a secure setup.
Based on my experience with U-boot, verified-boot here doesn't relate
to protect SPL or U-Boot. it's generally for kernel and followed
stages. I don't think we can think here too-much. some reference
doc/README.uniphier
You're true if we protect boot stages, then it becomes secure
boot(from BROM) like HABv4 in i.MX6, but verified boot in U-Boot is
different.
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64
2017-12-13 16:11 ` Jagan Teki
@ 2017-12-14 9:07 ` Maxime Ripard
0 siblings, 0 replies; 29+ messages in thread
From: Maxime Ripard @ 2017-12-14 9:07 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 09:41:35PM +0530, Jagan Teki wrote:
> On Wed, Dec 13, 2017 at 9:08 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Wed, Dec 13, 2017 at 11:33:04AM +0530, Jagan Teki wrote:
> >> Add verified-boot documentation for sunxi a64 platform.
> >>
> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >> ---
> >> Changes for v3:
> >> - Create separate document file
> >> Changes for v2:
> >> - New patch
> >>
> >> doc/README.sunxi | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 193 insertions(+)
> >> create mode 100644 doc/README.sunxi
> >>
> >> diff --git a/doc/README.sunxi b/doc/README.sunxi
> >> new file mode 100644
> >> index 0000000..ef4f735
> >> --- /dev/null
> >> +++ b/doc/README.sunxi
> >> @@ -0,0 +1,193 @@
> >> +#
> >> +# Copyright (C) 2017 Amarula Solutions
> >> +#
> >> +# SPDX-License-Identifier: GPL-2.0+
> >> +#
> >> +
> >> +U-Boot on SunXi
> >> +==============
> >> +
> >> +Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
> >> +
> >> + 1. Verified Boot
> >> +
> >> +1. Verified Boot
> >> +================
> >> +
> >> +U-Boot supports an image verification method called "Verified Boot".
> >> +This is a brief tutorial to utilize this feature for the Sunxi A64 platform.
> >> +You will find details documents in the doc/uImage.FIT directory.
> >> +
> >> +Here, we take Orangepi Win board for example, but it should work for any
> >> +other boards including 32 bit SoCs.
> >> +
> >> +1. Generate RSA key to sign
> >> +
> >> + $ mkdir keys
> >> + $ openssl genpkey -algorithm RSA -out keys/dev.key \
> >> + -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
> >> + $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
> >> +
> >> +Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
> >> +but need to match to the "key-name-hint" property described below.
> >
> > I really think that the very first thing you must talk about in that
> > documentation is that it will not protect the SPL itself and that this
> > is not a secure setup.
>
> Based on my experience with U-boot, verified-boot here doesn't relate
> to protect SPL or U-Boot. it's generally for kernel and followed
> stages. I don't think we can think here too-much. some reference
> doc/README.uniphier
Except that when you read verified boot, it also comes with the
assumption that you're actually protected against something.
In this particular case, you're protected against exactly
nothing. Anyone could come up, replace the bootloader to remove the
signature check, and you're doomed. It's trivial to do, and you're not
mentionning it anywhere.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171214/6e4e269c/attachment.sig>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64
2017-12-13 6:03 ` [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64 Jagan Teki
2017-12-13 15:38 ` Maxime Ripard
@ 2017-12-13 15:59 ` Quentin Schulz
2017-12-13 16:16 ` Jagan Teki
1 sibling, 1 reply; 29+ messages in thread
From: Quentin Schulz @ 2017-12-13 15:59 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On 13/12/2017 07:03, Jagan Teki wrote:
> Add verified-boot documentation for sunxi a64 platform.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v3:
> - Create separate document file
> Changes for v2:
> - New patch
>
> doc/README.sunxi | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 193 insertions(+)
> create mode 100644 doc/README.sunxi
>
> diff --git a/doc/README.sunxi b/doc/README.sunxi
> new file mode 100644
> index 0000000..ef4f735
> --- /dev/null
> +++ b/doc/README.sunxi
> @@ -0,0 +1,193 @@
> +#
> +# Copyright (C) 2017 Amarula Solutions
> +#
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +U-Boot on SunXi
> +==============
> +
> +Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
> +
> + 1. Verified Boot
> +
> +1. Verified Boot
> +================
> +
> +U-Boot supports an image verification method called "Verified Boot".
> +This is a brief tutorial to utilize this feature for the Sunxi A64 platform.
> +You will find details documents in the doc/uImage.FIT directory.
> +
> +Here, we take Orangepi Win board for example, but it should work for any
> +other boards including 32 bit SoCs.
> +
> +1. Generate RSA key to sign
> +
> + $ mkdir keys
> + $ openssl genpkey -algorithm RSA -out keys/dev.key \
> + -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
> + $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
> +
> +Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
> +but need to match to the "key-name-hint" property described below.
> +
> +2. FIT Input
> +
> +---------------------------------------->8----------------------------------------
> +/dts-v1/;
> +/ {
> + description = "FIT image with single Linux kernel, FDT blob";
> + #address-cells = <1>;
> +
> + images {
> + kernel at 0 {
> + description = "ARM64 Linux kernel";
> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/Image.gz");
> + type = "kernel";
> + arch = "arm64";
> + os = "linux";
> + compression = "gzip";
> + load = <0x50080000>;
> + entry = <0x50080000>;
> + hash at 1 {
> + algo = "sha256";
> + };
> + };
> +
> + fdt at 0 {
> + description = "Orangepi Win/Win+ Devicetree blob";
> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dtb");
> + type = "flat_dt";
> + arch = "arm64";
> + compression = "none";
> + hash at 1 {
> + algo = "sha256";
> + };
> + };
> + };
> +
> + configurations {
> + default = "conf at 0";
> +
> + conf at 0 {
> + description = "Boot Linux kernel, FDT blob";
> + kernel = "kernel at 0";
> + fdt = "fdt at 0";
> + signature at 0 {
> + algo = "sha256,rsa2048";
> + key-name-hint = "dev";
> + sign-images = "kernel", "fdt";
> + };
> + };
> + };
> +};
> +---------------------------------------->8----------------------------------------
> +
> +You need to change the two '/incbin/' lines, depending on the location of
> +your kernel image and devicetree blob. The "load" and "entry" properties also
> +need to be adjusted if you want to change the physical placement of the kernel.
> +
> +The "key-name-hint" must specify the key name you have created in the step 1.
> +
> +The FIT file name is arbitrary. Let's say you saved it into "fit.its".
> +
> +3. Compile U-Boot with FIT and signature enabled
> +
> +To use the Verified Boot, you need to enable the following two options:
> + CONFIG_FIT
> + CONFIG_FIT_SIGNATURE
> +
> + $ make orangepi_win_defconfig
> + $ make CROSS_COMPILE=aarch64-linux-gnu-
> +
> +4. FIT Output
> +
> +After building U-Boot, you will see tools/mkimage. With this tool, you can
> +create an image tree blob as follows:
> +
> + $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage
> +
> +The -k option must specify the key directory you have created in step 1.
> +
> +A file "fitImage" will be created. This includes kernel, DTB,
> +hash data for each of the three, and signature data.
> +
> +The public key needed for the run-time verification is stored in "dts/dt.dtb".
> +
> +5. Compile Verified U-Boot
> +
> +Since the "dt.dtb" has been updated in step 4, you need to re-compile the
> +U-Boot.
> +
> + $ make CROSS_COMPILE=aarch64-linux-gnu-
> +
> +The re-compiled "u-boot.bin" is appended with DTB that contains the public key.
> +
> +6. Flash the image
> +
> +Flash the "fitImage" to a storage device (SD, NAND, eMMC, or whatever) on your
> +board.
> +
> +7. Boot verified kernel
> +
> +Load the fitImage to memory and run the following from the U-Boot command line.
> +
> + > bootm <addr>
> +
> +Here, <addr> is the base address of the fitImage.
> +
> +If it is successful, you will see messages like follows:
> +
> +---------------------------------------->8----------------------------------------
> +=> setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p1 rootwait
> +=> ext4load mmc 0:1 $kernel_addr_r /boot/fitImage
> +16321738 bytes read in 1049 ms (14.8 MiB/s)
> +=> bootm $kernel_addr_r
> +## Loading kernel from FIT Image at 40080000 ...
> + Using 'conf at 0' configuration
> + Verifying Hash Integrity ... OK
> + Trying 'kernel at 0' kernel subimage
> + Description: ARM64 Linux kernel
> + Type: Kernel Image
> + Compression: gzip compressed
> + Data Start: 0x400800e4
> + Data Size: 6884659 Bytes = 6.6 MiB
> + Architecture: AArch64
> + OS: Linux
> + Load Address: 0x50080000
> + Entry Point: 0x50080000
> + Hash algo: sha256
> + Hash value: 6808fe51ea3c15f31c4510d2701d4707b56d20213c9da05bce79fb53bf108f1a
> + Verifying Hash Integrity ... sha256+ OK
> +## Loading fdt from FIT Image at 40080000 ...
> + Using 'conf at 0' configuration
> + Trying 'fdt at 0' fdt subimage
> + Description: Orangepi Win/Win+ Devicetree blob
> + Type: Flat Device Tree
> + Compression: uncompressed
> + Data Start: 0x40710f24
> + Data Size: 9032 Bytes = 8.8 KiB
> + Architecture: AArch64
> + Hash algo: sha256
> + Hash value: ca3d874cd10466633ff133cc0156828d48c8efb96987fa45f885761d22a25dc1
> + Verifying Hash Integrity ... sha256+ OK
> + Booting using the fdt blob at 0x40710f24
> + Uncompressing Kernel Image ... OK
> + Loading Device Tree to 0000000049ffa000, end 0000000049fff347 ... OK
> +
> +Starting kernel ...
> +---------------------------------------->8----------------------------------------
> +
> +Please pay attention to the lines that start with "Verifying Hash Integrity".
> +
> +"Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check
> +passed.
> +
> +"Verifying Hash Integrity ... sha256+ OK" (2 times) means the hash check passed
> +for kernel and DTB.
> +
> +If they are not displayed, the Verified Boot is not working.
> +
> +--
> +Jagan Teki <jagan@amarulasolutions.com>
> +13 Dec 2017
>
What's specific to sunxi boards in this README?
We already have an extensive documentation in doc/uImage.FIT/. Could a
few parts of your README make it to this documentation instead if it
isn't already there?
Thanks,
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64
2017-12-13 15:59 ` Quentin Schulz
@ 2017-12-13 16:16 ` Jagan Teki
2017-12-13 16:25 ` Andre Przywara
0 siblings, 1 reply; 29+ messages in thread
From: Jagan Teki @ 2017-12-13 16:16 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 9:29 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> Hi Jagan,
>
> On 13/12/2017 07:03, Jagan Teki wrote:
>> Add verified-boot documentation for sunxi a64 platform.
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>> ---
>> Changes for v3:
>> - Create separate document file
>> Changes for v2:
>> - New patch
>>
>> doc/README.sunxi | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 193 insertions(+)
>> create mode 100644 doc/README.sunxi
>>
>> diff --git a/doc/README.sunxi b/doc/README.sunxi
>> new file mode 100644
>> index 0000000..ef4f735
>> --- /dev/null
>> +++ b/doc/README.sunxi
>> @@ -0,0 +1,193 @@
>> +#
>> +# Copyright (C) 2017 Amarula Solutions
>> +#
>> +# SPDX-License-Identifier: GPL-2.0+
>> +#
>> +
>> +U-Boot on SunXi
>> +==============
>> +
>> +Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
>> +
>> + 1. Verified Boot
>> +
>> +1. Verified Boot
>> +================
>> +
>> +U-Boot supports an image verification method called "Verified Boot".
>> +This is a brief tutorial to utilize this feature for the Sunxi A64 platform.
>> +You will find details documents in the doc/uImage.FIT directory.
>> +
>> +Here, we take Orangepi Win board for example, but it should work for any
>> +other boards including 32 bit SoCs.
>> +
>> +1. Generate RSA key to sign
>> +
>> + $ mkdir keys
>> + $ openssl genpkey -algorithm RSA -out keys/dev.key \
>> + -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
>> + $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
>> +
>> +Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
>> +but need to match to the "key-name-hint" property described below.
>> +
>> +2. FIT Input
>> +
>> +---------------------------------------->8----------------------------------------
>> +/dts-v1/;
>> +/ {
>> + description = "FIT image with single Linux kernel, FDT blob";
>> + #address-cells = <1>;
>> +
>> + images {
>> + kernel at 0 {
>> + description = "ARM64 Linux kernel";
>> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/Image.gz");
>> + type = "kernel";
>> + arch = "arm64";
>> + os = "linux";
>> + compression = "gzip";
>> + load = <0x50080000>;
>> + entry = <0x50080000>;
>> + hash at 1 {
>> + algo = "sha256";
>> + };
>> + };
>> +
>> + fdt at 0 {
>> + description = "Orangepi Win/Win+ Devicetree blob";
>> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dtb");
>> + type = "flat_dt";
>> + arch = "arm64";
>> + compression = "none";
>> + hash at 1 {
>> + algo = "sha256";
>> + };
>> + };
>> + };
>> +
>> + configurations {
>> + default = "conf at 0";
>> +
>> + conf at 0 {
>> + description = "Boot Linux kernel, FDT blob";
>> + kernel = "kernel at 0";
>> + fdt = "fdt at 0";
>> + signature at 0 {
>> + algo = "sha256,rsa2048";
>> + key-name-hint = "dev";
>> + sign-images = "kernel", "fdt";
>> + };
>> + };
>> + };
>> +};
>> +---------------------------------------->8----------------------------------------
>> +
>> +You need to change the two '/incbin/' lines, depending on the location of
>> +your kernel image and devicetree blob. The "load" and "entry" properties also
>> +need to be adjusted if you want to change the physical placement of the kernel.
>> +
>> +The "key-name-hint" must specify the key name you have created in the step 1.
>> +
>> +The FIT file name is arbitrary. Let's say you saved it into "fit.its".
>> +
>> +3. Compile U-Boot with FIT and signature enabled
>> +
>> +To use the Verified Boot, you need to enable the following two options:
>> + CONFIG_FIT
>> + CONFIG_FIT_SIGNATURE
>> +
>> + $ make orangepi_win_defconfig
>> + $ make CROSS_COMPILE=aarch64-linux-gnu-
>> +
>> +4. FIT Output
>> +
>> +After building U-Boot, you will see tools/mkimage. With this tool, you can
>> +create an image tree blob as follows:
>> +
>> + $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage
>> +
>> +The -k option must specify the key directory you have created in step 1.
>> +
>> +A file "fitImage" will be created. This includes kernel, DTB,
>> +hash data for each of the three, and signature data.
>> +
>> +The public key needed for the run-time verification is stored in "dts/dt.dtb".
>> +
>> +5. Compile Verified U-Boot
>> +
>> +Since the "dt.dtb" has been updated in step 4, you need to re-compile the
>> +U-Boot.
>> +
>> + $ make CROSS_COMPILE=aarch64-linux-gnu-
>> +
>> +The re-compiled "u-boot.bin" is appended with DTB that contains the public key.
>> +
>> +6. Flash the image
>> +
>> +Flash the "fitImage" to a storage device (SD, NAND, eMMC, or whatever) on your
>> +board.
>> +
>> +7. Boot verified kernel
>> +
>> +Load the fitImage to memory and run the following from the U-Boot command line.
>> +
>> + > bootm <addr>
>> +
>> +Here, <addr> is the base address of the fitImage.
>> +
>> +If it is successful, you will see messages like follows:
>> +
>> +---------------------------------------->8----------------------------------------
>> +=> setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p1 rootwait
>> +=> ext4load mmc 0:1 $kernel_addr_r /boot/fitImage
>> +16321738 bytes read in 1049 ms (14.8 MiB/s)
>> +=> bootm $kernel_addr_r
>> +## Loading kernel from FIT Image at 40080000 ...
>> + Using 'conf at 0' configuration
>> + Verifying Hash Integrity ... OK
>> + Trying 'kernel at 0' kernel subimage
>> + Description: ARM64 Linux kernel
>> + Type: Kernel Image
>> + Compression: gzip compressed
>> + Data Start: 0x400800e4
>> + Data Size: 6884659 Bytes = 6.6 MiB
>> + Architecture: AArch64
>> + OS: Linux
>> + Load Address: 0x50080000
>> + Entry Point: 0x50080000
>> + Hash algo: sha256
>> + Hash value: 6808fe51ea3c15f31c4510d2701d4707b56d20213c9da05bce79fb53bf108f1a
>> + Verifying Hash Integrity ... sha256+ OK
>> +## Loading fdt from FIT Image at 40080000 ...
>> + Using 'conf at 0' configuration
>> + Trying 'fdt at 0' fdt subimage
>> + Description: Orangepi Win/Win+ Devicetree blob
>> + Type: Flat Device Tree
>> + Compression: uncompressed
>> + Data Start: 0x40710f24
>> + Data Size: 9032 Bytes = 8.8 KiB
>> + Architecture: AArch64
>> + Hash algo: sha256
>> + Hash value: ca3d874cd10466633ff133cc0156828d48c8efb96987fa45f885761d22a25dc1
>> + Verifying Hash Integrity ... sha256+ OK
>> + Booting using the fdt blob at 0x40710f24
>> + Uncompressing Kernel Image ... OK
>> + Loading Device Tree to 0000000049ffa000, end 0000000049fff347 ... OK
>> +
>> +Starting kernel ...
>> +---------------------------------------->8----------------------------------------
>> +
>> +Please pay attention to the lines that start with "Verifying Hash Integrity".
>> +
>> +"Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check
>> +passed.
>> +
>> +"Verifying Hash Integrity ... sha256+ OK" (2 times) means the hash check passed
>> +for kernel and DTB.
>> +
>> +If they are not displayed, the Verified Boot is not working.
>> +
>> +--
>> +Jagan Teki <jagan@amarulasolutions.com>
>> +13 Dec 2017
>>
>
> What's specific to sunxi boards in this README?
it not board specific, it's generic sunxi platform README.
>
> We already have an extensive documentation in doc/uImage.FIT/. Could a
> few parts of your README make it to this documentation instead if it
> isn't already there?
Since we've plenty of sunxi boards, showing readme with specific
feature in single board with all details does make more sense rather
than pointing out existing docs. It would be very beneficial for new
user to try with detailed info.
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64
2017-12-13 16:16 ` Jagan Teki
@ 2017-12-13 16:25 ` Andre Przywara
2017-12-13 16:35 ` Jagan Teki
0 siblings, 1 reply; 29+ messages in thread
From: Andre Przywara @ 2017-12-13 16:25 UTC (permalink / raw)
To: u-boot
Hi,
On 13/12/17 16:16, Jagan Teki wrote:
> On Wed, Dec 13, 2017 at 9:29 PM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
>> Hi Jagan,
>>
>> On 13/12/2017 07:03, Jagan Teki wrote:
>>> Add verified-boot documentation for sunxi a64 platform.
>>>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>> Changes for v3:
>>> - Create separate document file
>>> Changes for v2:
>>> - New patch
>>>
>>> doc/README.sunxi | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 193 insertions(+)
>>> create mode 100644 doc/README.sunxi
>>>
>>> diff --git a/doc/README.sunxi b/doc/README.sunxi
>>> new file mode 100644
>>> index 0000000..ef4f735
>>> --- /dev/null
>>> +++ b/doc/README.sunxi
>>> @@ -0,0 +1,193 @@
>>> +#
>>> +# Copyright (C) 2017 Amarula Solutions
>>> +#
>>> +# SPDX-License-Identifier: GPL-2.0+
>>> +#
>>> +
>>> +U-Boot on SunXi
>>> +==============
>>> +
>>> +Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
>>> +
>>> + 1. Verified Boot
>>> +
>>> +1. Verified Boot
>>> +================
>>> +
>>> +U-Boot supports an image verification method called "Verified Boot".
>>> +This is a brief tutorial to utilize this feature for the Sunxi A64 platform.
>>> +You will find details documents in the doc/uImage.FIT directory.
>>> +
>>> +Here, we take Orangepi Win board for example, but it should work for any
>>> +other boards including 32 bit SoCs.
>>> +
>>> +1. Generate RSA key to sign
>>> +
>>> + $ mkdir keys
>>> + $ openssl genpkey -algorithm RSA -out keys/dev.key \
>>> + -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
>>> + $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
>>> +
>>> +Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
>>> +but need to match to the "key-name-hint" property described below.
>>> +
>>> +2. FIT Input
>>> +
>>> +---------------------------------------->8----------------------------------------
>>> +/dts-v1/;
>>> +/ {
>>> + description = "FIT image with single Linux kernel, FDT blob";
>>> + #address-cells = <1>;
>>> +
>>> + images {
>>> + kernel at 0 {
>>> + description = "ARM64 Linux kernel";
>>> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/Image.gz");
>>> + type = "kernel";
>>> + arch = "arm64";
>>> + os = "linux";
>>> + compression = "gzip";
>>> + load = <0x50080000>;
>>> + entry = <0x50080000>;
>>> + hash at 1 {
>>> + algo = "sha256";
>>> + };
>>> + };
>>> +
>>> + fdt at 0 {
>>> + description = "Orangepi Win/Win+ Devicetree blob";
>>> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dtb");
>>> + type = "flat_dt";
>>> + arch = "arm64";
>>> + compression = "none";
>>> + hash at 1 {
>>> + algo = "sha256";
>>> + };
>>> + };
>>> + };
>>> +
>>> + configurations {
>>> + default = "conf at 0";
>>> +
>>> + conf at 0 {
>>> + description = "Boot Linux kernel, FDT blob";
>>> + kernel = "kernel at 0";
>>> + fdt = "fdt at 0";
>>> + signature at 0 {
>>> + algo = "sha256,rsa2048";
>>> + key-name-hint = "dev";
>>> + sign-images = "kernel", "fdt";
>>> + };
>>> + };
>>> + };
>>> +};
>>> +---------------------------------------->8----------------------------------------
>>> +
>>> +You need to change the two '/incbin/' lines, depending on the location of
>>> +your kernel image and devicetree blob. The "load" and "entry" properties also
>>> +need to be adjusted if you want to change the physical placement of the kernel.
>>> +
>>> +The "key-name-hint" must specify the key name you have created in the step 1.
>>> +
>>> +The FIT file name is arbitrary. Let's say you saved it into "fit.its".
>>> +
>>> +3. Compile U-Boot with FIT and signature enabled
>>> +
>>> +To use the Verified Boot, you need to enable the following two options:
>>> + CONFIG_FIT
>>> + CONFIG_FIT_SIGNATURE
>>> +
>>> + $ make orangepi_win_defconfig
>>> + $ make CROSS_COMPILE=aarch64-linux-gnu-
>>> +
>>> +4. FIT Output
>>> +
>>> +After building U-Boot, you will see tools/mkimage. With this tool, you can
>>> +create an image tree blob as follows:
>>> +
>>> + $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage
>>> +
>>> +The -k option must specify the key directory you have created in step 1.
>>> +
>>> +A file "fitImage" will be created. This includes kernel, DTB,
>>> +hash data for each of the three, and signature data.
>>> +
>>> +The public key needed for the run-time verification is stored in "dts/dt.dtb".
>>> +
>>> +5. Compile Verified U-Boot
>>> +
>>> +Since the "dt.dtb" has been updated in step 4, you need to re-compile the
>>> +U-Boot.
>>> +
>>> + $ make CROSS_COMPILE=aarch64-linux-gnu-
>>> +
>>> +The re-compiled "u-boot.bin" is appended with DTB that contains the public key.
>>> +
>>> +6. Flash the image
>>> +
>>> +Flash the "fitImage" to a storage device (SD, NAND, eMMC, or whatever) on your
>>> +board.
>>> +
>>> +7. Boot verified kernel
>>> +
>>> +Load the fitImage to memory and run the following from the U-Boot command line.
>>> +
>>> + > bootm <addr>
>>> +
>>> +Here, <addr> is the base address of the fitImage.
>>> +
>>> +If it is successful, you will see messages like follows:
>>> +
>>> +---------------------------------------->8----------------------------------------
>>> +=> setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p1 rootwait
>>> +=> ext4load mmc 0:1 $kernel_addr_r /boot/fitImage
>>> +16321738 bytes read in 1049 ms (14.8 MiB/s)
>>> +=> bootm $kernel_addr_r
>>> +## Loading kernel from FIT Image at 40080000 ...
>>> + Using 'conf at 0' configuration
>>> + Verifying Hash Integrity ... OK
>>> + Trying 'kernel at 0' kernel subimage
>>> + Description: ARM64 Linux kernel
>>> + Type: Kernel Image
>>> + Compression: gzip compressed
>>> + Data Start: 0x400800e4
>>> + Data Size: 6884659 Bytes = 6.6 MiB
>>> + Architecture: AArch64
>>> + OS: Linux
>>> + Load Address: 0x50080000
>>> + Entry Point: 0x50080000
>>> + Hash algo: sha256
>>> + Hash value: 6808fe51ea3c15f31c4510d2701d4707b56d20213c9da05bce79fb53bf108f1a
>>> + Verifying Hash Integrity ... sha256+ OK
>>> +## Loading fdt from FIT Image at 40080000 ...
>>> + Using 'conf at 0' configuration
>>> + Trying 'fdt at 0' fdt subimage
>>> + Description: Orangepi Win/Win+ Devicetree blob
>>> + Type: Flat Device Tree
>>> + Compression: uncompressed
>>> + Data Start: 0x40710f24
>>> + Data Size: 9032 Bytes = 8.8 KiB
>>> + Architecture: AArch64
>>> + Hash algo: sha256
>>> + Hash value: ca3d874cd10466633ff133cc0156828d48c8efb96987fa45f885761d22a25dc1
>>> + Verifying Hash Integrity ... sha256+ OK
>>> + Booting using the fdt blob at 0x40710f24
>>> + Uncompressing Kernel Image ... OK
>>> + Loading Device Tree to 0000000049ffa000, end 0000000049fff347 ... OK
>>> +
>>> +Starting kernel ...
>>> +---------------------------------------->8----------------------------------------
>>> +
>>> +Please pay attention to the lines that start with "Verifying Hash Integrity".
>>> +
>>> +"Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check
>>> +passed.
>>> +
>>> +"Verifying Hash Integrity ... sha256+ OK" (2 times) means the hash check passed
>>> +for kernel and DTB.
>>> +
>>> +If they are not displayed, the Verified Boot is not working.
>>> +
>>> +--
>>> +Jagan Teki <jagan@amarulasolutions.com>
>>> +13 Dec 2017
>>>
>>
>> What's specific to sunxi boards in this README?
>
> it not board specific, it's generic sunxi platform README.
I guess Quentin's point was that those instructions are generic to every
U-Boot platform. There is nothing sunxi specific in there.
docs/uImage.FIT is definitely the place for this doc to go.
>> We already have an extensive documentation in doc/uImage.FIT/. Could a
>> few parts of your README make it to this documentation instead if it
>> isn't already there?
>
> Since we've plenty of sunxi boards, showing readme with specific
> feature in single board with all details does make more sense rather
> than pointing out existing docs. It would be very beneficial for new
> user to try with detailed info.
I don't really get what you are after.
Please check doc/uImage.FIT/verified-boot.txt and see if you can extend
this file. As you pointed out yourself this is verified boot, a U-Boot
feature, which is totally architecture, platform and board agnostic.
Cheers,
Andre
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64
2017-12-13 16:25 ` Andre Przywara
@ 2017-12-13 16:35 ` Jagan Teki
2017-12-13 16:47 ` Andre Przywara
0 siblings, 1 reply; 29+ messages in thread
From: Jagan Teki @ 2017-12-13 16:35 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 9:55 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 13/12/17 16:16, Jagan Teki wrote:
>> On Wed, Dec 13, 2017 at 9:29 PM, Quentin Schulz
>> <quentin.schulz@free-electrons.com> wrote:
>>> Hi Jagan,
>>>
>>> On 13/12/2017 07:03, Jagan Teki wrote:
>>>> Add verified-boot documentation for sunxi a64 platform.
>>>>
>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>> ---
>>>> Changes for v3:
>>>> - Create separate document file
>>>> Changes for v2:
>>>> - New patch
>>>>
>>>> doc/README.sunxi | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 193 insertions(+)
>>>> create mode 100644 doc/README.sunxi
>>>>
>>>> diff --git a/doc/README.sunxi b/doc/README.sunxi
>>>> new file mode 100644
>>>> index 0000000..ef4f735
>>>> --- /dev/null
>>>> +++ b/doc/README.sunxi
>>>> @@ -0,0 +1,193 @@
>>>> +#
>>>> +# Copyright (C) 2017 Amarula Solutions
>>>> +#
>>>> +# SPDX-License-Identifier: GPL-2.0+
>>>> +#
>>>> +
>>>> +U-Boot on SunXi
>>>> +==============
>>>> +
>>>> +Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
>>>> +
>>>> + 1. Verified Boot
>>>> +
>>>> +1. Verified Boot
>>>> +================
>>>> +
>>>> +U-Boot supports an image verification method called "Verified Boot".
>>>> +This is a brief tutorial to utilize this feature for the Sunxi A64 platform.
>>>> +You will find details documents in the doc/uImage.FIT directory.
>>>> +
>>>> +Here, we take Orangepi Win board for example, but it should work for any
>>>> +other boards including 32 bit SoCs.
>>>> +
>>>> +1. Generate RSA key to sign
>>>> +
>>>> + $ mkdir keys
>>>> + $ openssl genpkey -algorithm RSA -out keys/dev.key \
>>>> + -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
>>>> + $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
>>>> +
>>>> +Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
>>>> +but need to match to the "key-name-hint" property described below.
>>>> +
>>>> +2. FIT Input
>>>> +
>>>> +---------------------------------------->8----------------------------------------
>>>> +/dts-v1/;
>>>> +/ {
>>>> + description = "FIT image with single Linux kernel, FDT blob";
>>>> + #address-cells = <1>;
>>>> +
>>>> + images {
>>>> + kernel at 0 {
>>>> + description = "ARM64 Linux kernel";
>>>> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/Image.gz");
>>>> + type = "kernel";
>>>> + arch = "arm64";
>>>> + os = "linux";
>>>> + compression = "gzip";
>>>> + load = <0x50080000>;
>>>> + entry = <0x50080000>;
>>>> + hash at 1 {
>>>> + algo = "sha256";
>>>> + };
>>>> + };
>>>> +
>>>> + fdt at 0 {
>>>> + description = "Orangepi Win/Win+ Devicetree blob";
>>>> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dtb");
>>>> + type = "flat_dt";
>>>> + arch = "arm64";
>>>> + compression = "none";
>>>> + hash at 1 {
>>>> + algo = "sha256";
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>> + configurations {
>>>> + default = "conf at 0";
>>>> +
>>>> + conf at 0 {
>>>> + description = "Boot Linux kernel, FDT blob";
>>>> + kernel = "kernel at 0";
>>>> + fdt = "fdt at 0";
>>>> + signature at 0 {
>>>> + algo = "sha256,rsa2048";
>>>> + key-name-hint = "dev";
>>>> + sign-images = "kernel", "fdt";
>>>> + };
>>>> + };
>>>> + };
>>>> +};
>>>> +---------------------------------------->8----------------------------------------
>>>> +
>>>> +You need to change the two '/incbin/' lines, depending on the location of
>>>> +your kernel image and devicetree blob. The "load" and "entry" properties also
>>>> +need to be adjusted if you want to change the physical placement of the kernel.
>>>> +
>>>> +The "key-name-hint" must specify the key name you have created in the step 1.
>>>> +
>>>> +The FIT file name is arbitrary. Let's say you saved it into "fit.its".
>>>> +
>>>> +3. Compile U-Boot with FIT and signature enabled
>>>> +
>>>> +To use the Verified Boot, you need to enable the following two options:
>>>> + CONFIG_FIT
>>>> + CONFIG_FIT_SIGNATURE
>>>> +
>>>> + $ make orangepi_win_defconfig
>>>> + $ make CROSS_COMPILE=aarch64-linux-gnu-
>>>> +
>>>> +4. FIT Output
>>>> +
>>>> +After building U-Boot, you will see tools/mkimage. With this tool, you can
>>>> +create an image tree blob as follows:
>>>> +
>>>> + $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage
>>>> +
>>>> +The -k option must specify the key directory you have created in step 1.
>>>> +
>>>> +A file "fitImage" will be created. This includes kernel, DTB,
>>>> +hash data for each of the three, and signature data.
>>>> +
>>>> +The public key needed for the run-time verification is stored in "dts/dt.dtb".
>>>> +
>>>> +5. Compile Verified U-Boot
>>>> +
>>>> +Since the "dt.dtb" has been updated in step 4, you need to re-compile the
>>>> +U-Boot.
>>>> +
>>>> + $ make CROSS_COMPILE=aarch64-linux-gnu-
>>>> +
>>>> +The re-compiled "u-boot.bin" is appended with DTB that contains the public key.
>>>> +
>>>> +6. Flash the image
>>>> +
>>>> +Flash the "fitImage" to a storage device (SD, NAND, eMMC, or whatever) on your
>>>> +board.
>>>> +
>>>> +7. Boot verified kernel
>>>> +
>>>> +Load the fitImage to memory and run the following from the U-Boot command line.
>>>> +
>>>> + > bootm <addr>
>>>> +
>>>> +Here, <addr> is the base address of the fitImage.
>>>> +
>>>> +If it is successful, you will see messages like follows:
>>>> +
>>>> +---------------------------------------->8----------------------------------------
>>>> +=> setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p1 rootwait
>>>> +=> ext4load mmc 0:1 $kernel_addr_r /boot/fitImage
>>>> +16321738 bytes read in 1049 ms (14.8 MiB/s)
>>>> +=> bootm $kernel_addr_r
>>>> +## Loading kernel from FIT Image at 40080000 ...
>>>> + Using 'conf at 0' configuration
>>>> + Verifying Hash Integrity ... OK
>>>> + Trying 'kernel at 0' kernel subimage
>>>> + Description: ARM64 Linux kernel
>>>> + Type: Kernel Image
>>>> + Compression: gzip compressed
>>>> + Data Start: 0x400800e4
>>>> + Data Size: 6884659 Bytes = 6.6 MiB
>>>> + Architecture: AArch64
>>>> + OS: Linux
>>>> + Load Address: 0x50080000
>>>> + Entry Point: 0x50080000
>>>> + Hash algo: sha256
>>>> + Hash value: 6808fe51ea3c15f31c4510d2701d4707b56d20213c9da05bce79fb53bf108f1a
>>>> + Verifying Hash Integrity ... sha256+ OK
>>>> +## Loading fdt from FIT Image at 40080000 ...
>>>> + Using 'conf at 0' configuration
>>>> + Trying 'fdt at 0' fdt subimage
>>>> + Description: Orangepi Win/Win+ Devicetree blob
>>>> + Type: Flat Device Tree
>>>> + Compression: uncompressed
>>>> + Data Start: 0x40710f24
>>>> + Data Size: 9032 Bytes = 8.8 KiB
>>>> + Architecture: AArch64
>>>> + Hash algo: sha256
>>>> + Hash value: ca3d874cd10466633ff133cc0156828d48c8efb96987fa45f885761d22a25dc1
>>>> + Verifying Hash Integrity ... sha256+ OK
>>>> + Booting using the fdt blob at 0x40710f24
>>>> + Uncompressing Kernel Image ... OK
>>>> + Loading Device Tree to 0000000049ffa000, end 0000000049fff347 ... OK
>>>> +
>>>> +Starting kernel ...
>>>> +---------------------------------------->8----------------------------------------
>>>> +
>>>> +Please pay attention to the lines that start with "Verifying Hash Integrity".
>>>> +
>>>> +"Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check
>>>> +passed.
>>>> +
>>>> +"Verifying Hash Integrity ... sha256+ OK" (2 times) means the hash check passed
>>>> +for kernel and DTB.
>>>> +
>>>> +If they are not displayed, the Verified Boot is not working.
>>>> +
>>>> +--
>>>> +Jagan Teki <jagan@amarulasolutions.com>
>>>> +13 Dec 2017
>>>>
>>>
>>> What's specific to sunxi boards in this README?
>>
>> it not board specific, it's generic sunxi platform README.
>
> I guess Quentin's point was that those instructions are generic to every
> U-Boot platform. There is nothing sunxi specific in there.
> docs/uImage.FIT is definitely the place for this doc to go.
Yeah, I understand instructions are generic for all platforms but what
I'm trying to show how these generic things are applying or verified
on sunxi like what other platforms does. (like README.unipher)
wouldn't be beneficial to show these details on sunxi?
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64
2017-12-13 16:35 ` Jagan Teki
@ 2017-12-13 16:47 ` Andre Przywara
2017-12-14 1:28 ` Tom Rini
0 siblings, 1 reply; 29+ messages in thread
From: Andre Przywara @ 2017-12-13 16:47 UTC (permalink / raw)
To: u-boot
Hi,
On 13/12/17 16:35, Jagan Teki wrote:
> On Wed, Dec 13, 2017 at 9:55 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>> Hi,
>>
>> On 13/12/17 16:16, Jagan Teki wrote:
>>> On Wed, Dec 13, 2017 at 9:29 PM, Quentin Schulz
>>> <quentin.schulz@free-electrons.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On 13/12/2017 07:03, Jagan Teki wrote:
>>>>> Add verified-boot documentation for sunxi a64 platform.
>>>>>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>> Changes for v3:
>>>>> - Create separate document file
>>>>> Changes for v2:
>>>>> - New patch
>>>>>
>>>>> doc/README.sunxi | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 193 insertions(+)
>>>>> create mode 100644 doc/README.sunxi
>>>>>
>>>>> diff --git a/doc/README.sunxi b/doc/README.sunxi
>>>>> new file mode 100644
>>>>> index 0000000..ef4f735
>>>>> --- /dev/null
>>>>> +++ b/doc/README.sunxi
>>>>> @@ -0,0 +1,193 @@
>>>>> +#
>>>>> +# Copyright (C) 2017 Amarula Solutions
>>>>> +#
>>>>> +# SPDX-License-Identifier: GPL-2.0+
>>>>> +#
>>>>> +
>>>>> +U-Boot on SunXi
>>>>> +==============
>>>>> +
>>>>> +Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
>>>>> +
>>>>> + 1. Verified Boot
>>>>> +
>>>>> +1. Verified Boot
>>>>> +================
>>>>> +
>>>>> +U-Boot supports an image verification method called "Verified Boot".
>>>>> +This is a brief tutorial to utilize this feature for the Sunxi A64 platform.
>>>>> +You will find details documents in the doc/uImage.FIT directory.
>>>>> +
>>>>> +Here, we take Orangepi Win board for example, but it should work for any
>>>>> +other boards including 32 bit SoCs.
>>>>> +
>>>>> +1. Generate RSA key to sign
>>>>> +
>>>>> + $ mkdir keys
>>>>> + $ openssl genpkey -algorithm RSA -out keys/dev.key \
>>>>> + -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
>>>>> + $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
>>>>> +
>>>>> +Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
>>>>> +but need to match to the "key-name-hint" property described below.
>>>>> +
>>>>> +2. FIT Input
>>>>> +
>>>>> +---------------------------------------->8----------------------------------------
>>>>> +/dts-v1/;
>>>>> +/ {
>>>>> + description = "FIT image with single Linux kernel, FDT blob";
>>>>> + #address-cells = <1>;
>>>>> +
>>>>> + images {
>>>>> + kernel at 0 {
>>>>> + description = "ARM64 Linux kernel";
>>>>> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/Image.gz");
>>>>> + type = "kernel";
>>>>> + arch = "arm64";
>>>>> + os = "linux";
>>>>> + compression = "gzip";
>>>>> + load = <0x50080000>;
>>>>> + entry = <0x50080000>;
>>>>> + hash at 1 {
>>>>> + algo = "sha256";
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + fdt at 0 {
>>>>> + description = "Orangepi Win/Win+ Devicetree blob";
>>>>> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dtb");
>>>>> + type = "flat_dt";
>>>>> + arch = "arm64";
>>>>> + compression = "none";
>>>>> + hash at 1 {
>>>>> + algo = "sha256";
>>>>> + };
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + configurations {
>>>>> + default = "conf at 0";
>>>>> +
>>>>> + conf at 0 {
>>>>> + description = "Boot Linux kernel, FDT blob";
>>>>> + kernel = "kernel at 0";
>>>>> + fdt = "fdt at 0";
>>>>> + signature at 0 {
>>>>> + algo = "sha256,rsa2048";
>>>>> + key-name-hint = "dev";
>>>>> + sign-images = "kernel", "fdt";
>>>>> + };
>>>>> + };
>>>>> + };
>>>>> +};
>>>>> +---------------------------------------->8----------------------------------------
>>>>> +
>>>>> +You need to change the two '/incbin/' lines, depending on the location of
>>>>> +your kernel image and devicetree blob. The "load" and "entry" properties also
>>>>> +need to be adjusted if you want to change the physical placement of the kernel.
>>>>> +
>>>>> +The "key-name-hint" must specify the key name you have created in the step 1.
>>>>> +
>>>>> +The FIT file name is arbitrary. Let's say you saved it into "fit.its".
>>>>> +
>>>>> +3. Compile U-Boot with FIT and signature enabled
>>>>> +
>>>>> +To use the Verified Boot, you need to enable the following two options:
>>>>> + CONFIG_FIT
>>>>> + CONFIG_FIT_SIGNATURE
>>>>> +
>>>>> + $ make orangepi_win_defconfig
>>>>> + $ make CROSS_COMPILE=aarch64-linux-gnu-
>>>>> +
>>>>> +4. FIT Output
>>>>> +
>>>>> +After building U-Boot, you will see tools/mkimage. With this tool, you can
>>>>> +create an image tree blob as follows:
>>>>> +
>>>>> + $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage
>>>>> +
>>>>> +The -k option must specify the key directory you have created in step 1.
>>>>> +
>>>>> +A file "fitImage" will be created. This includes kernel, DTB,
>>>>> +hash data for each of the three, and signature data.
>>>>> +
>>>>> +The public key needed for the run-time verification is stored in "dts/dt.dtb".
>>>>> +
>>>>> +5. Compile Verified U-Boot
>>>>> +
>>>>> +Since the "dt.dtb" has been updated in step 4, you need to re-compile the
>>>>> +U-Boot.
>>>>> +
>>>>> + $ make CROSS_COMPILE=aarch64-linux-gnu-
>>>>> +
>>>>> +The re-compiled "u-boot.bin" is appended with DTB that contains the public key.
>>>>> +
>>>>> +6. Flash the image
>>>>> +
>>>>> +Flash the "fitImage" to a storage device (SD, NAND, eMMC, or whatever) on your
>>>>> +board.
>>>>> +
>>>>> +7. Boot verified kernel
>>>>> +
>>>>> +Load the fitImage to memory and run the following from the U-Boot command line.
>>>>> +
>>>>> + > bootm <addr>
>>>>> +
>>>>> +Here, <addr> is the base address of the fitImage.
>>>>> +
>>>>> +If it is successful, you will see messages like follows:
>>>>> +
>>>>> +---------------------------------------->8----------------------------------------
>>>>> +=> setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p1 rootwait
>>>>> +=> ext4load mmc 0:1 $kernel_addr_r /boot/fitImage
>>>>> +16321738 bytes read in 1049 ms (14.8 MiB/s)
>>>>> +=> bootm $kernel_addr_r
>>>>> +## Loading kernel from FIT Image at 40080000 ...
>>>>> + Using 'conf at 0' configuration
>>>>> + Verifying Hash Integrity ... OK
>>>>> + Trying 'kernel at 0' kernel subimage
>>>>> + Description: ARM64 Linux kernel
>>>>> + Type: Kernel Image
>>>>> + Compression: gzip compressed
>>>>> + Data Start: 0x400800e4
>>>>> + Data Size: 6884659 Bytes = 6.6 MiB
>>>>> + Architecture: AArch64
>>>>> + OS: Linux
>>>>> + Load Address: 0x50080000
>>>>> + Entry Point: 0x50080000
>>>>> + Hash algo: sha256
>>>>> + Hash value: 6808fe51ea3c15f31c4510d2701d4707b56d20213c9da05bce79fb53bf108f1a
>>>>> + Verifying Hash Integrity ... sha256+ OK
>>>>> +## Loading fdt from FIT Image at 40080000 ...
>>>>> + Using 'conf at 0' configuration
>>>>> + Trying 'fdt at 0' fdt subimage
>>>>> + Description: Orangepi Win/Win+ Devicetree blob
>>>>> + Type: Flat Device Tree
>>>>> + Compression: uncompressed
>>>>> + Data Start: 0x40710f24
>>>>> + Data Size: 9032 Bytes = 8.8 KiB
>>>>> + Architecture: AArch64
>>>>> + Hash algo: sha256
>>>>> + Hash value: ca3d874cd10466633ff133cc0156828d48c8efb96987fa45f885761d22a25dc1
>>>>> + Verifying Hash Integrity ... sha256+ OK
>>>>> + Booting using the fdt blob at 0x40710f24
>>>>> + Uncompressing Kernel Image ... OK
>>>>> + Loading Device Tree to 0000000049ffa000, end 0000000049fff347 ... OK
>>>>> +
>>>>> +Starting kernel ...
>>>>> +---------------------------------------->8----------------------------------------
>>>>> +
>>>>> +Please pay attention to the lines that start with "Verifying Hash Integrity".
>>>>> +
>>>>> +"Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check
>>>>> +passed.
>>>>> +
>>>>> +"Verifying Hash Integrity ... sha256+ OK" (2 times) means the hash check passed
>>>>> +for kernel and DTB.
>>>>> +
>>>>> +If they are not displayed, the Verified Boot is not working.
>>>>> +
>>>>> +--
>>>>> +Jagan Teki <jagan@amarulasolutions.com>
>>>>> +13 Dec 2017
>>>>>
>>>>
>>>> What's specific to sunxi boards in this README?
>>>
>>> it not board specific, it's generic sunxi platform README.
>>
>> I guess Quentin's point was that those instructions are generic to every
>> U-Boot platform. There is nothing sunxi specific in there.
>> docs/uImage.FIT is definitely the place for this doc to go.
>
> Yeah, I understand instructions are generic for all platforms but what
> I'm trying to show how these generic things are applying or verified
> on sunxi like what other platforms does. (like README.unipher)
> wouldn't be beneficial to show these details on sunxi?
A single line like: "Verified boot like described in
doc/uImage.FIT/verified works on sunxi boards." would be sufficient for
that.
So looking closer I see that you copied and modified that part from
README.uniphier - where I consider this misplaced as well. I would
recommend to instead move that verified boot part out of that file, and
add it to doc/uImage.FIT/verified-boot.txt under an example section.
Then you can point from both the sunxi and uniphier documentation to
that generic documentation.
Duplicating the documentation definitely does not make sense to me.
If you want to spoon-feed beginners with step-by-step instructions, feel
free to add a page to the linux-sunxi wiki with all those details.
Cheers,
Andre.
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64
2017-12-13 16:47 ` Andre Przywara
@ 2017-12-14 1:28 ` Tom Rini
0 siblings, 0 replies; 29+ messages in thread
From: Tom Rini @ 2017-12-14 1:28 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 04:47:29PM +0000, Andre Przywara wrote:
> Hi,
>
> On 13/12/17 16:35, Jagan Teki wrote:
> > On Wed, Dec 13, 2017 at 9:55 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> >> Hi,
> >>
> >> On 13/12/17 16:16, Jagan Teki wrote:
> >>> On Wed, Dec 13, 2017 at 9:29 PM, Quentin Schulz
> >>> <quentin.schulz@free-electrons.com> wrote:
> >>>> Hi Jagan,
> >>>>
> >>>> On 13/12/2017 07:03, Jagan Teki wrote:
> >>>>> Add verified-boot documentation for sunxi a64 platform.
> >>>>>
> >>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>> ---
> >>>>> Changes for v3:
> >>>>> - Create separate document file
> >>>>> Changes for v2:
> >>>>> - New patch
> >>>>>
> >>>>> doc/README.sunxi | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>> 1 file changed, 193 insertions(+)
> >>>>> create mode 100644 doc/README.sunxi
> >>>>>
> >>>>> diff --git a/doc/README.sunxi b/doc/README.sunxi
> >>>>> new file mode 100644
> >>>>> index 0000000..ef4f735
> >>>>> --- /dev/null
> >>>>> +++ b/doc/README.sunxi
> >>>>> @@ -0,0 +1,193 @@
> >>>>> +#
> >>>>> +# Copyright (C) 2017 Amarula Solutions
> >>>>> +#
> >>>>> +# SPDX-License-Identifier: GPL-2.0+
> >>>>> +#
> >>>>> +
> >>>>> +U-Boot on SunXi
> >>>>> +==============
> >>>>> +
> >>>>> +Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
> >>>>> +
> >>>>> + 1. Verified Boot
> >>>>> +
> >>>>> +1. Verified Boot
> >>>>> +================
> >>>>> +
> >>>>> +U-Boot supports an image verification method called "Verified Boot".
> >>>>> +This is a brief tutorial to utilize this feature for the Sunxi A64 platform.
> >>>>> +You will find details documents in the doc/uImage.FIT directory.
> >>>>> +
> >>>>> +Here, we take Orangepi Win board for example, but it should work for any
> >>>>> +other boards including 32 bit SoCs.
> >>>>> +
> >>>>> +1. Generate RSA key to sign
> >>>>> +
> >>>>> + $ mkdir keys
> >>>>> + $ openssl genpkey -algorithm RSA -out keys/dev.key \
> >>>>> + -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
> >>>>> + $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
> >>>>> +
> >>>>> +Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
> >>>>> +but need to match to the "key-name-hint" property described below.
> >>>>> +
> >>>>> +2. FIT Input
> >>>>> +
> >>>>> +---------------------------------------->8----------------------------------------
> >>>>> +/dts-v1/;
> >>>>> +/ {
> >>>>> + description = "FIT image with single Linux kernel, FDT blob";
> >>>>> + #address-cells = <1>;
> >>>>> +
> >>>>> + images {
> >>>>> + kernel at 0 {
> >>>>> + description = "ARM64 Linux kernel";
> >>>>> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/Image.gz");
> >>>>> + type = "kernel";
> >>>>> + arch = "arm64";
> >>>>> + os = "linux";
> >>>>> + compression = "gzip";
> >>>>> + load = <0x50080000>;
> >>>>> + entry = <0x50080000>;
> >>>>> + hash at 1 {
> >>>>> + algo = "sha256";
> >>>>> + };
> >>>>> + };
> >>>>> +
> >>>>> + fdt at 0 {
> >>>>> + description = "Orangepi Win/Win+ Devicetree blob";
> >>>>> + data = /incbin/("/path/to/linux/dir/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dtb");
> >>>>> + type = "flat_dt";
> >>>>> + arch = "arm64";
> >>>>> + compression = "none";
> >>>>> + hash at 1 {
> >>>>> + algo = "sha256";
> >>>>> + };
> >>>>> + };
> >>>>> + };
> >>>>> +
> >>>>> + configurations {
> >>>>> + default = "conf at 0";
> >>>>> +
> >>>>> + conf at 0 {
> >>>>> + description = "Boot Linux kernel, FDT blob";
> >>>>> + kernel = "kernel at 0";
> >>>>> + fdt = "fdt at 0";
> >>>>> + signature at 0 {
> >>>>> + algo = "sha256,rsa2048";
> >>>>> + key-name-hint = "dev";
> >>>>> + sign-images = "kernel", "fdt";
> >>>>> + };
> >>>>> + };
> >>>>> + };
> >>>>> +};
> >>>>> +---------------------------------------->8----------------------------------------
> >>>>> +
> >>>>> +You need to change the two '/incbin/' lines, depending on the location of
> >>>>> +your kernel image and devicetree blob. The "load" and "entry" properties also
> >>>>> +need to be adjusted if you want to change the physical placement of the kernel.
> >>>>> +
> >>>>> +The "key-name-hint" must specify the key name you have created in the step 1.
> >>>>> +
> >>>>> +The FIT file name is arbitrary. Let's say you saved it into "fit.its".
> >>>>> +
> >>>>> +3. Compile U-Boot with FIT and signature enabled
> >>>>> +
> >>>>> +To use the Verified Boot, you need to enable the following two options:
> >>>>> + CONFIG_FIT
> >>>>> + CONFIG_FIT_SIGNATURE
> >>>>> +
> >>>>> + $ make orangepi_win_defconfig
> >>>>> + $ make CROSS_COMPILE=aarch64-linux-gnu-
> >>>>> +
> >>>>> +4. FIT Output
> >>>>> +
> >>>>> +After building U-Boot, you will see tools/mkimage. With this tool, you can
> >>>>> +create an image tree blob as follows:
> >>>>> +
> >>>>> + $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage
> >>>>> +
> >>>>> +The -k option must specify the key directory you have created in step 1.
> >>>>> +
> >>>>> +A file "fitImage" will be created. This includes kernel, DTB,
> >>>>> +hash data for each of the three, and signature data.
> >>>>> +
> >>>>> +The public key needed for the run-time verification is stored in "dts/dt.dtb".
> >>>>> +
> >>>>> +5. Compile Verified U-Boot
> >>>>> +
> >>>>> +Since the "dt.dtb" has been updated in step 4, you need to re-compile the
> >>>>> +U-Boot.
> >>>>> +
> >>>>> + $ make CROSS_COMPILE=aarch64-linux-gnu-
> >>>>> +
> >>>>> +The re-compiled "u-boot.bin" is appended with DTB that contains the public key.
> >>>>> +
> >>>>> +6. Flash the image
> >>>>> +
> >>>>> +Flash the "fitImage" to a storage device (SD, NAND, eMMC, or whatever) on your
> >>>>> +board.
> >>>>> +
> >>>>> +7. Boot verified kernel
> >>>>> +
> >>>>> +Load the fitImage to memory and run the following from the U-Boot command line.
> >>>>> +
> >>>>> + > bootm <addr>
> >>>>> +
> >>>>> +Here, <addr> is the base address of the fitImage.
> >>>>> +
> >>>>> +If it is successful, you will see messages like follows:
> >>>>> +
> >>>>> +---------------------------------------->8----------------------------------------
> >>>>> +=> setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p1 rootwait
> >>>>> +=> ext4load mmc 0:1 $kernel_addr_r /boot/fitImage
> >>>>> +16321738 bytes read in 1049 ms (14.8 MiB/s)
> >>>>> +=> bootm $kernel_addr_r
> >>>>> +## Loading kernel from FIT Image at 40080000 ...
> >>>>> + Using 'conf at 0' configuration
> >>>>> + Verifying Hash Integrity ... OK
> >>>>> + Trying 'kernel at 0' kernel subimage
> >>>>> + Description: ARM64 Linux kernel
> >>>>> + Type: Kernel Image
> >>>>> + Compression: gzip compressed
> >>>>> + Data Start: 0x400800e4
> >>>>> + Data Size: 6884659 Bytes = 6.6 MiB
> >>>>> + Architecture: AArch64
> >>>>> + OS: Linux
> >>>>> + Load Address: 0x50080000
> >>>>> + Entry Point: 0x50080000
> >>>>> + Hash algo: sha256
> >>>>> + Hash value: 6808fe51ea3c15f31c4510d2701d4707b56d20213c9da05bce79fb53bf108f1a
> >>>>> + Verifying Hash Integrity ... sha256+ OK
> >>>>> +## Loading fdt from FIT Image at 40080000 ...
> >>>>> + Using 'conf at 0' configuration
> >>>>> + Trying 'fdt at 0' fdt subimage
> >>>>> + Description: Orangepi Win/Win+ Devicetree blob
> >>>>> + Type: Flat Device Tree
> >>>>> + Compression: uncompressed
> >>>>> + Data Start: 0x40710f24
> >>>>> + Data Size: 9032 Bytes = 8.8 KiB
> >>>>> + Architecture: AArch64
> >>>>> + Hash algo: sha256
> >>>>> + Hash value: ca3d874cd10466633ff133cc0156828d48c8efb96987fa45f885761d22a25dc1
> >>>>> + Verifying Hash Integrity ... sha256+ OK
> >>>>> + Booting using the fdt blob at 0x40710f24
> >>>>> + Uncompressing Kernel Image ... OK
> >>>>> + Loading Device Tree to 0000000049ffa000, end 0000000049fff347 ... OK
> >>>>> +
> >>>>> +Starting kernel ...
> >>>>> +---------------------------------------->8----------------------------------------
> >>>>> +
> >>>>> +Please pay attention to the lines that start with "Verifying Hash Integrity".
> >>>>> +
> >>>>> +"Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check
> >>>>> +passed.
> >>>>> +
> >>>>> +"Verifying Hash Integrity ... sha256+ OK" (2 times) means the hash check passed
> >>>>> +for kernel and DTB.
> >>>>> +
> >>>>> +If they are not displayed, the Verified Boot is not working.
> >>>>> +
> >>>>> +--
> >>>>> +Jagan Teki <jagan@amarulasolutions.com>
> >>>>> +13 Dec 2017
> >>>>>
> >>>>
> >>>> What's specific to sunxi boards in this README?
> >>>
> >>> it not board specific, it's generic sunxi platform README.
> >>
> >> I guess Quentin's point was that those instructions are generic to every
> >> U-Boot platform. There is nothing sunxi specific in there.
> >> docs/uImage.FIT is definitely the place for this doc to go.
> >
> > Yeah, I understand instructions are generic for all platforms but what
> > I'm trying to show how these generic things are applying or verified
> > on sunxi like what other platforms does. (like README.unipher)
> > wouldn't be beneficial to show these details on sunxi?
>
> A single line like: "Verified boot like described in
> doc/uImage.FIT/verified works on sunxi boards." would be sufficient for
> that.
>
> So looking closer I see that you copied and modified that part from
> README.uniphier - where I consider this misplaced as well. I would
> recommend to instead move that verified boot part out of that file, and
> add it to doc/uImage.FIT/verified-boot.txt under an example section.
> Then you can point from both the sunxi and uniphier documentation to
> that generic documentation.
>
> Duplicating the documentation definitely does not make sense to me.
> If you want to spoon-feed beginners with step-by-step instructions, feel
> free to add a page to the linux-sunxi wiki with all those details.
Agreed, thanks Andre!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171213/6cf35ee8/attachment.sig>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 4/5] docs: README.sunxi: Move sunxi64 documentation
2017-12-13 6:03 [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature Jagan Teki
2017-12-13 6:03 ` [U-Boot] [PATCH v3 2/5] sunxi: arm64: Increase CONFIG_SYS_BOOTM_LEN to 32MB Jagan Teki
2017-12-13 6:03 ` [U-Boot] [PATCH v3 3/5] docs: Document verified-boot for sunxi a64 Jagan Teki
@ 2017-12-13 6:03 ` Jagan Teki
2017-12-13 15:38 ` Maxime Ripard
2017-12-13 16:12 ` Andre Przywara
2017-12-13 6:03 ` [U-Boot] [PATCH v3 5/5] docs: README.sunxi: Move nand documentation Jagan Teki
2017-12-13 15:39 ` [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature Maxime Ripard
4 siblings, 2 replies; 29+ messages in thread
From: Jagan Teki @ 2017-12-13 6:03 UTC (permalink / raw)
To: u-boot
Move documentation of README.sunxi64 from board files
into docs/README.sunxi
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v3:
- New patch
board/sunxi/README.sunxi64 | 165 ------------------------------------------
doc/README.sunxi | 173 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 170 insertions(+), 168 deletions(-)
delete mode 100644 board/sunxi/README.sunxi64
diff --git a/board/sunxi/README.sunxi64 b/board/sunxi/README.sunxi64
deleted file mode 100644
index c492f74..0000000
--- a/board/sunxi/README.sunxi64
+++ /dev/null
@@ -1,165 +0,0 @@
-Allwinner 64-bit boards README
-==============================
-
-Newer Allwinner SoCs feature ARMv8 cores (ARM Cortex-A53) with support for
-both the 64-bit AArch64 mode and the ARMv7 compatible 32-bit AArch32 mode.
-Examples are the Allwinner A64 (used for instance on the Pine64 board) or
-the Allwinner H5 SoC (as used on the OrangePi PC 2).
-These SoCs are wired to start in AArch32 mode on reset and execute 32-bit
-code from the Boot ROM (BROM). As this has some implications on U-Boot, this
-file describes how to make full use of the 64-bit capabilities.
-
-Quick Start / Overview
-======================
-- Build the ARM Trusted Firmware binary (see "ARM Trusted Firmware (ATF)" below)
-- Build U-Boot (see "SPL/U-Boot" below)
-- Transfer to an uSD card (see "microSD card" below)
-- Boot and enjoy!
-
-Building the firmware
-=====================
-
-The Allwinner A64/H5 firmware consists of three parts: U-Boot's SPL, an
-ARM Trusted Firmware (ATF) build and the U-Boot proper.
-The SPL will load both ATF and U-Boot proper along with the right device
-tree blob (.dtb) and will pass execution to ATF (in EL3), which in turn will
-drop into the U-Boot proper (in EL2).
-As the ATF binary will become part of the U-Boot image file, you will need
-to build it first.
-
- ARM Trusted Firmware (ATF)
-----------------------------
-Checkout the "allwinner" branch from the github repository [1] and build it:
-$ export CROSS_COMPILE=aarch64-linux-gnu-
-$ make PLAT=sun50iw1p1 DEBUG=1 bl31
-The resulting binary is build/sun50iw1p1/debug/bl31.bin. Either put the
-location of this file into the BL31 environment variable or copy this to
-the root of your U-Boot build directory (or create a symbolic link).
-$ export BL31=/src/arm-trusted-firmware/build/sun50iw1p1/debug/bl31.bin
- (adjust the actual path accordingly)
-
- SPL/U-Boot
-------------
-Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM
-enters the SPL still in AArch32 secure SVC mode, there is some shim code to
-enter AArch64 very early. The rest of the SPL runs in AArch64 EL3.
-U-Boot proper runs in EL2 and can load any AArch64 code (using the "go"
-command), EFI applications (with "bootefi") or arm64 Linux kernel images
-(often named "Image"), using the "booti" command.
-
-$ make clean
-$ export CROSS_COMPILE=aarch64-linux-gnu-
-$ make pine64_plus_defconfig
-$ make
-
-This will build the SPL in spl/sunxi-spl.bin and a FIT image called u-boot.itb,
-which contains the rest of the firmware.
-
-
-Boot process
-============
-The on-die BROM code will try several methods to load and execute the firmware.
-On a typical board like the Pine64 this will result in the following boot order:
-
-1) Reading 32KB from sector 16 (@8K) of the microSD card to SRAM A1. If the
-BROM finds the magic "eGON" header in the first bytes, it will execute that
-code. If not (no SD card at all or invalid magic), it will:
-2) Try to read 32KB from sector 16 (@8K) of memory connected to the MMC2
-controller, typically an on-board eMMC chip. If there is no eMMC or it does
-not contain a valid boot header, it will:
-3) Initialize the SPI0 controller and try to access a NOR flash connected to
-it (using the CS0 pin). If a flash chip is found, the BROM will load the
-first 32KB (from offset 0) into SRAM A1. Now it checks for the magic eGON
-header and checksum and will execute the code upon finding it. If not, it will:
-4) Initialize the USB OTG controller and will wait for a host to connect to
-it, speaking the Allwinner proprietary (but deciphered) "FEL" USB protocol.
-
-
-To boot the Pine64 board, you can use U-Boot and any of the described methods.
-
-FEL boot (USB OTG)
-------------------
-FEL is the name of the Allwinner defined USB boot protocol built in the
-mask ROM of most Allwinner SoCs. It allows to bootstrap a board solely
-by using the USB-OTG interface and a host port on another computer.
-As the FEL mode is controlled by the boot ROM, it expects to be running in
-AArch32. For now the AArch64 SPL cannot properly return into FEL mode, so the
-feature is disabled in the configuration at the moment.
-
-microSD card
-------------
-Transfer the SPL and the U-Boot FIT image directly to an uSD card:
-# dd if=spl/sunxi-spl.bin of=/dev/sdx bs=8k seek=1
-# dd if=u-boot.itb of=/dev/sdx bs=8k seek=5
-# sync
-(replace /dev/sdx with you SD card device file name, which could be
-/dev/mmcblk[x] as well).
-
-Alternatively you can concatenate the SPL and the U-Boot FIT image into a
-single file and transfer that instead:
-$ cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin
-# dd if=u-boot-sunxi-with-spl.bin of=/dev/sdx bs=8k seek=1
-
-You can partition the microSD card, but leave the first MB unallocated (most
-partitioning tools will do this anyway).
-
-NOR flash
----------
-Some boards (like the SoPine, Pinebook or the OrangePi PC2) come with a
-soldered SPI NOR flash chip. On other boards like the Pine64 such a chip
-can be connected to the SPI0/CS0 pins on the PI-2 headers.
-Create the SPL and FIT image like described above for the SD card.
-Now connect either an "A to A" USB cable to the upper USB port on the Pine64
-or get an adaptor and use a regular A-microB cable connected to it. Other
-boards often have a proper micro-B USB socket connected to the USB OTB port.
-Remove a microSD card from the slot and power on the board.
-On your host computer download and build the sunxi-tools package[2], then
-use "sunxi-fel" to access the board:
-$ ./sunxi-fel ver -v -p
-This should give you an output starting with: AWUSBFEX soc=00001689(A64) ...
-Now use the sunxi-fel tool to write to the NOR flash:
-$ ./sunxi-fel spiflash-write 0 spl/sunxi-spl.bin
-$ ./sunxi-fel spiflash-write 32768 u-boot.itb
-Now boot the board without an SD card inserted and you should see the
-U-Boot prompt on the serial console.
-
-(Legacy) boot0 method
----------------------
-boot0 is Allwiner's secondary program loader and it can be used as some kind
-of SPL replacement to get U-Boot up and running from an microSD card.
-For some time using boot0 was the only option to get the Pine64 booted.
-With working DRAM init code in U-Boot's SPL this is no longer necessary,
-but this method is described here for the sake of completeness.
-Please note that this method works only with the boot0 files shipped with
-A64 based boards, the H5 uses an incompatible layout which is not supported
-by this method.
-
-The boot0 binary is a 32 KByte blob and contained in the official Pine64 images
-distributed by Pine64 or Allwinner. It can be easily extracted from a micro
-SD card or an image file:
-# dd if=/dev/sd<x> of=boot0.bin bs=8k skip=1 count=4
-where /dev/sd<x> is the device name of the uSD card or the name of the image
-file. Apparently Allwinner allows re-distribution of this proprietary code
-"as-is".
-This boot0 blob takes care of DRAM initialisation and loads the remaining
-firmware parts, then switches the core into AArch64 mode.
-The original boot0 code looks for U-Boot at a certain place on an uSD card
-(at 19096 KB), also it expects a header with magic bytes and a checksum.
-There is a tool called boot0img[3] which takes a boot0.bin image and a compiled
-U-Boot binary (plus other binaries) and will populate that header accordingly.
-To make space for the magic header, the pine64_plus_defconfig will make sure
-there is sufficient space at the beginning of the U-Boot binary.
-boot0img will also take care of putting the different binaries at the right
-places on the uSD card and works around unused, but mandatory parts by using
-trampoline code. See the output of "boot0img -h" for more information.
-boot0img can also patch boot0 to avoid loading U-Boot from 19MB, instead
-fetching it from just behind the boot0 binary (-B option).
-$ ./boot0img -o firmware.img -B boot0.img -u u-boot-dtb.bin -e -s bl31.bin \
--a 0x44008 -d trampoline64:0x44000
-Then write this image to a microSD card, replacing /dev/sdx with the right
-device file (see above):
-$ dd if=firmware.img of=/dev/sdx bs=8k seek=1
-
-[1] https://github.com/apritzel/arm-trusted-firmware.git
-[2] git://github.com/linux-sunxi/sunxi-tools.git
-[3] https://github.com/apritzel/pine64/
diff --git a/doc/README.sunxi b/doc/README.sunxi
index ef4f735..48f82cb 100644
--- a/doc/README.sunxi
+++ b/doc/README.sunxi
@@ -9,9 +9,170 @@ U-Boot on SunXi
Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
- 1. Verified Boot
-
-1. Verified Boot
+ 1. Allwinner 64-bit boards
+ 2. Verified Boot
+
+1. Allwinner 64-bit boards
+==========================
+
+Newer Allwinner SoCs feature ARMv8 cores (ARM Cortex-A53) with support for
+both the 64-bit AArch64 mode and the ARMv7 compatible 32-bit AArch32 mode.
+Examples are the Allwinner A64 (used for instance on the Pine64 board) or
+the Allwinner H5 SoC (as used on the OrangePi PC 2).
+These SoCs are wired to start in AArch32 mode on reset and execute 32-bit
+code from the Boot ROM (BROM). As this has some implications on U-Boot, this
+file describes how to make full use of the 64-bit capabilities.
+
+Quick Start / Overview
+======================
+- Build the ARM Trusted Firmware binary (see "ARM Trusted Firmware (ATF)" below)
+- Build U-Boot (see "SPL/U-Boot" below)
+- Transfer to an uSD card (see "microSD card" below)
+- Boot and enjoy!
+
+Building the firmware
+=====================
+
+The Allwinner A64/H5 firmware consists of three parts: U-Boot's SPL, an
+ARM Trusted Firmware (ATF) build and the U-Boot proper.
+The SPL will load both ATF and U-Boot proper along with the right device
+tree blob (.dtb) and will pass execution to ATF (in EL3), which in turn will
+drop into the U-Boot proper (in EL2).
+As the ATF binary will become part of the U-Boot image file, you will need
+to build it first.
+
+ ARM Trusted Firmware (ATF)
+----------------------------
+Checkout the "allwinner" branch from the github repository [1] and build it:
+$ export CROSS_COMPILE=aarch64-linux-gnu-
+$ make PLAT=sun50iw1p1 DEBUG=1 bl31
+The resulting binary is build/sun50iw1p1/debug/bl31.bin. Either put the
+location of this file into the BL31 environment variable or copy this to
+the root of your U-Boot build directory (or create a symbolic link).
+$ export BL31=/src/arm-trusted-firmware/build/sun50iw1p1/debug/bl31.bin
+ (adjust the actual path accordingly)
+
+SPL/U-Boot
+----------
+Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM
+enters the SPL still in AArch32 secure SVC mode, there is some shim code to
+enter AArch64 very early. The rest of the SPL runs in AArch64 EL3.
+U-Boot proper runs in EL2 and can load any AArch64 code (using the "go"
+command), EFI applications (with "bootefi") or arm64 Linux kernel images
+(often named "Image"), using the "booti" command.
+
+$ make clean
+$ export CROSS_COMPILE=aarch64-linux-gnu-
+$ make pine64_plus_defconfig
+$ make
+
+This will build the SPL in spl/sunxi-spl.bin and a FIT image called u-boot.itb,
+which contains the rest of the firmware.
+
+Boot process
+============
+The on-die BROM code will try several methods to load and execute the firmware.
+On a typical board like the Pine64 this will result in the following boot order:
+
+1) Reading 32KB from sector 16 (@8K) of the microSD card to SRAM A1. If the
+BROM finds the magic "eGON" header in the first bytes, it will execute that
+code. If not (no SD card at all or invalid magic), it will:
+2) Try to read 32KB from sector 16 (@8K) of memory connected to the MMC2
+controller, typically an on-board eMMC chip. If there is no eMMC or it does
+not contain a valid boot header, it will:
+3) Initialize the SPI0 controller and try to access a NOR flash connected to
+it (using the CS0 pin). If a flash chip is found, the BROM will load the
+first 32KB (from offset 0) into SRAM A1. Now it checks for the magic eGON
+header and checksum and will execute the code upon finding it. If not, it will:
+4) Initialize the USB OTG controller and will wait for a host to connect to
+it, speaking the Allwinner proprietary (but deciphered) "FEL" USB protocol.
+
+To boot the Pine64 board, you can use U-Boot and any of the described methods.
+
+FEL boot (USB OTG)
+------------------
+FEL is the name of the Allwinner defined USB boot protocol built in the
+mask ROM of most Allwinner SoCs. It allows to bootstrap a board solely
+by using the USB-OTG interface and a host port on another computer.
+As the FEL mode is controlled by the boot ROM, it expects to be running in
+AArch32. For now the AArch64 SPL cannot properly return into FEL mode, so the
+feature is disabled in the configuration at the moment.
+
+microSD card
+------------
+Transfer the SPL and the U-Boot FIT image directly to an uSD card:
+# dd if=spl/sunxi-spl.bin of=/dev/sdx bs=8k seek=1
+# dd if=u-boot.itb of=/dev/sdx bs=8k seek=5
+# sync
+(replace /dev/sdx with you SD card device file name, which could be
+/dev/mmcblk[x] as well).
+
+Alternatively you can concatenate the SPL and the U-Boot FIT image into a
+single file and transfer that instead:
+$ cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin
+# dd if=u-boot-sunxi-with-spl.bin of=/dev/sdx bs=8k seek=1
+
+You can partition the microSD card, but leave the first MB unallocated (most
+partitioning tools will do this anyway).
+
+NOR flash
+---------
+Some boards (like the SoPine, Pinebook or the OrangePi PC2) come with a
+soldered SPI NOR flash chip. On other boards like the Pine64 such a chip
+can be connected to the SPI0/CS0 pins on the PI-2 headers.
+Create the SPL and FIT image like described above for the SD card.
+Now connect either an "A to A" USB cable to the upper USB port on the Pine64
+or get an adaptor and use a regular A-microB cable connected to it. Other
+boards often have a proper micro-B USB socket connected to the USB OTB port.
+Remove a microSD card from the slot and power on the board.
+On your host computer download and build the sunxi-tools package[2], then
+use "sunxi-fel" to access the board:
+$ ./sunxi-fel ver -v -p
+This should give you an output starting with: AWUSBFEX soc=00001689(A64) ...
+Now use the sunxi-fel tool to write to the NOR flash:
+$ ./sunxi-fel spiflash-write 0 spl/sunxi-spl.bin
+$ ./sunxi-fel spiflash-write 32768 u-boot.itb
+Now boot the board without an SD card inserted and you should see the
+U-Boot prompt on the serial console.
+
+(Legacy) boot0 method
+---------------------
+boot0 is Allwiner's secondary program loader and it can be used as some kind
+of SPL replacement to get U-Boot up and running from an microSD card.
+For some time using boot0 was the only option to get the Pine64 booted.
+With working DRAM init code in U-Boot's SPL this is no longer necessary,
+but this method is described here for the sake of completeness.
+Please note that this method works only with the boot0 files shipped with
+A64 based boards, the H5 uses an incompatible layout which is not supported
+by this method.
+
+The boot0 binary is a 32 KByte blob and contained in the official Pine64 images
+distributed by Pine64 or Allwinner. It can be easily extracted from a micro
+SD card or an image file:
+# dd if=/dev/sd<x> of=boot0.bin bs=8k skip=1 count=4
+where /dev/sd<x> is the device name of the uSD card or the name of the image
+file. Apparently Allwinner allows re-distribution of this proprietary code
+"as-is".
+This boot0 blob takes care of DRAM initialisation and loads the remaining
+firmware parts, then switches the core into AArch64 mode.
+The original boot0 code looks for U-Boot at a certain place on an uSD card
+(at 19096 KB), also it expects a header with magic bytes and a checksum.
+There is a tool called boot0img[3] which takes a boot0.bin image and a compiled
+U-Boot binary (plus other binaries) and will populate that header accordingly.
+To make space for the magic header, the pine64_plus_defconfig will make sure
+there is sufficient space at the beginning of the U-Boot binary.
+boot0img will also take care of putting the different binaries at the right
+places on the uSD card and works around unused, but mandatory parts by using
+trampoline code. See the output of "boot0img -h" for more information.
+boot0img can also patch boot0 to avoid loading U-Boot from 19MB, instead
+fetching it from just behind the boot0 binary (-B option).
+$ ./boot0img -o firmware.img -B boot0.img -u u-boot-dtb.bin -e -s bl31.bin \
+-a 0x44008 -d trampoline64:0x44000
+Then write this image to a microSD card, replacing /dev/sdx with the right
+device file (see above):
+$ dd if=firmware.img of=/dev/sdx bs=8k seek=1
+
+2. Verified Boot
================
U-Boot supports an image verification method called "Verified Boot".
@@ -188,6 +349,12 @@ for kernel and DTB.
If they are not displayed, the Verified Boot is not working.
+References
+==========
+[1] https://github.com/apritzel/arm-trusted-firmware.git
+[2] git://github.com/linux-sunxi/sunxi-tools.git
+[3] https://github.com/apritzel/pine64/
+
--
Jagan Teki <jagan@amarulasolutions.com>
13 Dec 2017
--
2.7.4
^ permalink raw reply related [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 4/5] docs: README.sunxi: Move sunxi64 documentation
2017-12-13 6:03 ` [U-Boot] [PATCH v3 4/5] docs: README.sunxi: Move sunxi64 documentation Jagan Teki
@ 2017-12-13 15:38 ` Maxime Ripard
2017-12-13 16:21 ` Jagan Teki
2017-12-13 16:12 ` Andre Przywara
1 sibling, 1 reply; 29+ messages in thread
From: Maxime Ripard @ 2017-12-13 15:38 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 11:33:05AM +0530, Jagan Teki wrote:
> Move documentation of README.sunxi64 from board files
> into docs/README.sunxi
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
I'd really prefer to have it split. We can move it in doc/ if you
want, and it definitely makes sense, but maybe we can have a subfolder
instead?
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171213/c8507a76/attachment.sig>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 4/5] docs: README.sunxi: Move sunxi64 documentation
2017-12-13 15:38 ` Maxime Ripard
@ 2017-12-13 16:21 ` Jagan Teki
0 siblings, 0 replies; 29+ messages in thread
From: Jagan Teki @ 2017-12-13 16:21 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 9:08 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Wed, Dec 13, 2017 at 11:33:05AM +0530, Jagan Teki wrote:
>> Move documentation of README.sunxi64 from board files
>> into docs/README.sunxi
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>
> I'd really prefer to have it split. We can move it in doc/ if you
> want, and it definitely makes sense, but maybe we can have a subfolder
> instead?
why we need subfolder? that will eventually increase no.of files with
single platform specific documentation, it become easy in a single
file with index like other platforms did README.rockchip,
README.uniphier
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 4/5] docs: README.sunxi: Move sunxi64 documentation
2017-12-13 6:03 ` [U-Boot] [PATCH v3 4/5] docs: README.sunxi: Move sunxi64 documentation Jagan Teki
2017-12-13 15:38 ` Maxime Ripard
@ 2017-12-13 16:12 ` Andre Przywara
2017-12-14 1:30 ` Tom Rini
1 sibling, 1 reply; 29+ messages in thread
From: Andre Przywara @ 2017-12-13 16:12 UTC (permalink / raw)
To: u-boot
Hi,
On 13/12/17 06:03, Jagan Teki wrote:
> Move documentation of README.sunxi64 from board files
> into docs/README.sunxi
... which is where I originally put it, only that Tom asked to move it
to board/sunxi:
https://lists.denx.de/pipermail/u-boot/2016-July/260025.html
Tom, what's your take on this?
Cheers,
Andre.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 4/5] docs: README.sunxi: Move sunxi64 documentation
2017-12-13 16:12 ` Andre Przywara
@ 2017-12-14 1:30 ` Tom Rini
0 siblings, 0 replies; 29+ messages in thread
From: Tom Rini @ 2017-12-14 1:30 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 04:12:04PM +0000, Andre Przywara wrote:
> Hi,
>
> On 13/12/17 06:03, Jagan Teki wrote:
> > Move documentation of README.sunxi64 from board files
> > into docs/README.sunxi
>
> ... which is where I originally put it, only that Tom asked to move it
> to board/sunxi:
>
> https://lists.denx.de/pipermail/u-boot/2016-July/260025.html
>
> Tom, what's your take on this?
Given that we support all sunxi boards under board/sunxi/ directly
(unlike other platforms which have per-board directories), I still think
it belongs where it is today.
I do not object to someone thinking over the problem of how should
U-Boot document everything that it has documented today, in a more
consistent manner, but I don't think moving this around helps. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171213/02d0bfc9/attachment.sig>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 5/5] docs: README.sunxi: Move nand documentation
2017-12-13 6:03 [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature Jagan Teki
` (2 preceding siblings ...)
2017-12-13 6:03 ` [U-Boot] [PATCH v3 4/5] docs: README.sunxi: Move sunxi64 documentation Jagan Teki
@ 2017-12-13 6:03 ` Jagan Teki
2017-12-13 15:39 ` [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature Maxime Ripard
4 siblings, 0 replies; 29+ messages in thread
From: Jagan Teki @ 2017-12-13 6:03 UTC (permalink / raw)
To: u-boot
Move documentation of README.nand from board files
into docs/README.sunxi
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v3:
- New patch
board/sunxi/README.nand | 54 --------------------------------------------
doc/README.sunxi | 60 +++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 58 insertions(+), 56 deletions(-)
delete mode 100644 board/sunxi/README.nand
diff --git a/board/sunxi/README.nand b/board/sunxi/README.nand
deleted file mode 100644
index a5d4ff0..0000000
--- a/board/sunxi/README.nand
+++ /dev/null
@@ -1,54 +0,0 @@
-Allwinner NAND flashing
-=======================
-
-A lot of Allwinner devices, especially the older ones (pre-H3 era),
-comes with a NAND. NANDs storages are a pretty weak choice when it
-comes to the reliability, and it comes with a number of flaws like
-read and write disturbs, data retention issues, bloks becoming
-unusable, etc.
-
-In order to mitigate that, various strategies have been found to be
-able to recover from those issues like ECC, hardware randomization,
-and of course, redundancy for the critical parts.
-
-This is obviously something that we will take into account when
-creating our images. However, the BROM will use a quite weird pattern
-when accessing the NAND, and will access only at most 4kB per page,
-which means that we also have to split that binary accross several
-pages.
-
-In order to accomodate that, we create a tool that will generate an
-SPL image that is ready to be programmed directly embedding the ECCs,
-randomized, and with the necessary bits needed to reduce the number of
-bitflips. The U-Boot build system, when configured for the NAND will
-also generate the image sunxi-spl-with-ecc.bin that will have been
-generated by that tool.
-
-In order to flash your U-Boot image onto a board, assuming that the
-board is in FEL mode, you'll need the sunxi-tools that you can find at
-this repository: https://github.com/linux-sunxi/sunxi-tools
-
-Then, you'll need to first load an SPL to initialise the RAM:
-sunxi-fel spl spl/sunxi-spl.bin
-
-Load the binaries we'll flash into RAM:
-sunxi-fel write 0x4a000000 u-boot-dtb.bin
-sunxi-fel write 0x43000000 spl/sunxi-spl-with-ecc.bin
-
-And execute U-Boot
-sunxi-fel exe 0x4a000000
-
-On your board, you'll now have all the needed binaries into RAM, so
-you only need to erase the NAND...
-
-nand erase.chip
-
-Then write the SPL and its backup:
-
-nand write.raw.noverify 0x43000000 0 40
-nand write.raw.noverify 0x43000000 0x400000 40
-
-And finally write the U-Boot binary:
-nand write 0x4a000000 0x800000 0xc0000
-
-You can now reboot and enjoy your NAND.
\ No newline at end of file
diff --git a/doc/README.sunxi b/doc/README.sunxi
index 48f82cb..c682606 100644
--- a/doc/README.sunxi
+++ b/doc/README.sunxi
@@ -10,7 +10,8 @@ U-Boot on SunXi
Tutorial describe all details relevant for U-Boot on Allwinner SunXi platform.
1. Allwinner 64-bit boards
- 2. Verified Boot
+ 2. Allwinner NAND flashing
+ 3. Verified Boot
1. Allwinner 64-bit boards
==========================
@@ -172,7 +173,62 @@ Then write this image to a microSD card, replacing /dev/sdx with the right
device file (see above):
$ dd if=firmware.img of=/dev/sdx bs=8k seek=1
-2. Verified Boot
+2. Allwinner NAND flashing
+==========================
+
+A lot of Allwinner devices, especially the older ones (pre-H3 era),
+comes with a NAND. NANDs storages are a pretty weak choice when it
+comes to the reliability, and it comes with a number of flaws like
+read and write disturbs, data retention issues, bloks becoming
+unusable, etc.
+
+In order to mitigate that, various strategies have been found to be
+able to recover from those issues like ECC, hardware randomization,
+and of course, redundancy for the critical parts.
+
+This is obviously something that we will take into account when
+creating our images. However, the BROM will use a quite weird pattern
+when accessing the NAND, and will access only at most 4kB per page,
+which means that we also have to split that binary accross several
+pages.
+
+In order to accomodate that, we create a tool that will generate an
+SPL image that is ready to be programmed directly embedding the ECCs,
+randomized, and with the necessary bits needed to reduce the number of
+bitflips. The U-Boot build system, when configured for the NAND will
+also generate the image sunxi-spl-with-ecc.bin that will have been
+generated by that tool.
+
+In order to flash your U-Boot image onto a board, assuming that the
+board is in FEL mode, you'll need the sunxi-tools that you can find at
+this repository: https://github.com/linux-sunxi/sunxi-tools
+
+Then, you'll need to first load an SPL to initialise the RAM:
+sunxi-fel spl spl/sunxi-spl.bin
+
+Load the binaries we'll flash into RAM:
+sunxi-fel write 0x4a000000 u-boot-dtb.bin
+sunxi-fel write 0x43000000 spl/sunxi-spl-with-ecc.bin
+
+And execute U-Boot
+sunxi-fel exe 0x4a000000
+
+On your board, you'll now have all the needed binaries into RAM, so
+you only need to erase the NAND...
+
+nand erase.chip
+
+Then write the SPL and its backup:
+
+nand write.raw.noverify 0x43000000 0 40
+nand write.raw.noverify 0x43000000 0x400000 40
+
+And finally write the U-Boot binary:
+nand write 0x4a000000 0x800000 0xc0000
+
+You can now reboot and enjoy your NAND.
+
+3. Verified Boot
================
U-Boot supports an image verification method called "Verified Boot".
--
2.7.4
^ permalink raw reply related [flat|nested] 29+ messages in thread* [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature
2017-12-13 6:03 [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature Jagan Teki
` (3 preceding siblings ...)
2017-12-13 6:03 ` [U-Boot] [PATCH v3 5/5] docs: README.sunxi: Move nand documentation Jagan Teki
@ 2017-12-13 15:39 ` Maxime Ripard
2017-12-13 16:08 ` [U-Boot] [linux-sunxi] " Peter Korsgaard
2017-12-14 8:33 ` [U-Boot] " Jagan Teki
4 siblings, 2 replies; 29+ messages in thread
From: Maxime Ripard @ 2017-12-13 15:39 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 11:33:02AM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagannadh.teki@gmail.com>
>
> Enable FIT_SIGNATURE for sunxi a64.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v3:
> - Move imply outside block
> Changes for v2:
> - Use imply instead of select
>
> arch/arm/mach-sunxi/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 1fededd..05e2d47 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -179,6 +179,7 @@ config MACH_SUN50I
> select SUNXI_DRAM_DW_32BIT
> select FIT
> select SPL_LOAD_FIT
> + imply FIT_SIGNATURE
I'm really not sure we should force it by default. How much code size
is it adding?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171213/f82cbb90/attachment.sig>
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [linux-sunxi] Re: [PATCH v3 1/5] sunxi: a64: Enable FIT Signature
2017-12-13 15:39 ` [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature Maxime Ripard
@ 2017-12-13 16:08 ` Peter Korsgaard
2017-12-14 8:16 ` Jagan Teki
2017-12-14 8:33 ` [U-Boot] " Jagan Teki
1 sibling, 1 reply; 29+ messages in thread
From: Peter Korsgaard @ 2017-12-13 16:08 UTC (permalink / raw)
To: u-boot
>>>>> "Maxime" == Maxime Ripard <maxime.ripard@free-electrons.com> writes:
Hi,
>> +++ b/arch/arm/mach-sunxi/Kconfig
>> @@ -179,6 +179,7 @@ config MACH_SUN50I
>> select SUNXI_DRAM_DW_32BIT
>> select FIT
>> select SPL_LOAD_FIT
>> + imply FIT_SIGNATURE
> I'm really not sure we should force it by default. How much code size
> is it adding?
Not only that, enabling FIT_SIGNATURE support disables support for the
legacy images (uImage / boot.scr) for security reasons, so it may very
well break existing setups.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [linux-sunxi] Re: [PATCH v3 1/5] sunxi: a64: Enable FIT Signature
2017-12-13 16:08 ` [U-Boot] [linux-sunxi] " Peter Korsgaard
@ 2017-12-14 8:16 ` Jagan Teki
2017-12-14 8:51 ` Peter Korsgaard
0 siblings, 1 reply; 29+ messages in thread
From: Jagan Teki @ 2017-12-14 8:16 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 9:38 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
>>>>>> "Maxime" == Maxime Ripard <maxime.ripard@free-electrons.com> writes:
>
> Hi,
>
> >> +++ b/arch/arm/mach-sunxi/Kconfig
> >> @@ -179,6 +179,7 @@ config MACH_SUN50I
> >> select SUNXI_DRAM_DW_32BIT
> >> select FIT
> >> select SPL_LOAD_FIT
> >> + imply FIT_SIGNATURE
>
> > I'm really not sure we should force it by default. How much code size
> > is it adding?
>
> Not only that, enabling FIT_SIGNATURE support disables support for the
> legacy images (uImage / boot.scr) for security reasons, so it may very
> well break existing setups.
Sorry, I didn't get why legacy images will disable with fit? It
depends how user can go with it, whether he want legacy or fit both
will work.
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [linux-sunxi] Re: [PATCH v3 1/5] sunxi: a64: Enable FIT Signature
2017-12-14 8:16 ` Jagan Teki
@ 2017-12-14 8:51 ` Peter Korsgaard
0 siblings, 0 replies; 29+ messages in thread
From: Peter Korsgaard @ 2017-12-14 8:51 UTC (permalink / raw)
To: u-boot
>>>>> "Jagan" == Jagan Teki <jagannadh.teki@gmail.com> writes:
> On Wed, Dec 13, 2017 at 9:38 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
>>>>>>> "Maxime" == Maxime Ripard <maxime.ripard@free-electrons.com> writes:
>>
>> Hi,
>>
>> >> +++ b/arch/arm/mach-sunxi/Kconfig
>> >> @@ -179,6 +179,7 @@ config MACH_SUN50I
>> >> select SUNXI_DRAM_DW_32BIT
>> >> select FIT
>> >> select SPL_LOAD_FIT
>> >> + imply FIT_SIGNATURE
>>
>> > I'm really not sure we should force it by default. How much code size
>> > is it adding?
>>
>> Not only that, enabling FIT_SIGNATURE support disables support for the
>> legacy images (uImage / boot.scr) for security reasons, so it may very
>> well break existing setups.
> Sorry, I didn't get why legacy images will disable with fit? It
> depends how user can go with it, whether he want legacy or fit both
> will work.
Not when you enable CONFIG_FIT_SIGNATURE. That option disables support
for the legacy images.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature
2017-12-13 15:39 ` [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature Maxime Ripard
2017-12-13 16:08 ` [U-Boot] [linux-sunxi] " Peter Korsgaard
@ 2017-12-14 8:33 ` Jagan Teki
2017-12-15 13:41 ` Maxime Ripard
1 sibling, 1 reply; 29+ messages in thread
From: Jagan Teki @ 2017-12-14 8:33 UTC (permalink / raw)
To: u-boot
On Wed, Dec 13, 2017 at 9:09 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Wed, Dec 13, 2017 at 11:33:02AM +0530, Jagan Teki wrote:
>> From: Jagan Teki <jagannadh.teki@gmail.com>
>>
>> Enable FIT_SIGNATURE for sunxi a64.
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>> ---
>> Changes for v3:
>> - Move imply outside block
>> Changes for v2:
>> - Use imply instead of select
>>
>> arch/arm/mach-sunxi/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>> index 1fededd..05e2d47 100644
>> --- a/arch/arm/mach-sunxi/Kconfig
>> +++ b/arch/arm/mach-sunxi/Kconfig
>> @@ -179,6 +179,7 @@ config MACH_SUN50I
>> select SUNXI_DRAM_DW_32BIT
>> select FIT
>> select SPL_LOAD_FIT
>> + imply FIT_SIGNATURE
>
> I'm really not sure we should force it by default. How much code size
> is it adding?
Why we need to consider u-boot size? (because it may cross the loader2 size?)
Here is the delta of u-boot elf
before:
text data bss dec hex filename
457378 20248 244160 721786 b037a u-boot
after:
text data bss dec hex filename
461357 20848 244160 726365 b155d u-boot
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature
2017-12-14 8:33 ` [U-Boot] " Jagan Teki
@ 2017-12-15 13:41 ` Maxime Ripard
2017-12-15 14:36 ` Andre Przywara
2017-12-15 15:02 ` Jagan Teki
0 siblings, 2 replies; 29+ messages in thread
From: Maxime Ripard @ 2017-12-15 13:41 UTC (permalink / raw)
To: u-boot
On Thu, Dec 14, 2017 at 02:03:12PM +0530, Jagan Teki wrote:
> On Wed, Dec 13, 2017 at 9:09 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Wed, Dec 13, 2017 at 11:33:02AM +0530, Jagan Teki wrote:
> >> From: Jagan Teki <jagannadh.teki@gmail.com>
> >>
> >> Enable FIT_SIGNATURE for sunxi a64.
> >>
> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >> ---
> >> Changes for v3:
> >> - Move imply outside block
> >> Changes for v2:
> >> - Use imply instead of select
> >>
> >> arch/arm/mach-sunxi/Kconfig | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> >> index 1fededd..05e2d47 100644
> >> --- a/arch/arm/mach-sunxi/Kconfig
> >> +++ b/arch/arm/mach-sunxi/Kconfig
> >> @@ -179,6 +179,7 @@ config MACH_SUN50I
> >> select SUNXI_DRAM_DW_32BIT
> >> select FIT
> >> select SPL_LOAD_FIT
> >> + imply FIT_SIGNATURE
> >
> > I'm really not sure we should force it by default. How much code size
> > is it adding?
>
> Why we need to consider u-boot size? (because it may cross the loader2 size?)
> Here is the delta of u-boot elf
The same reason than anything else on our arm64 builds lately: we have
a u-boot binary too big for the size compared to our environment offset.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171215/04d78c7b/attachment.sig>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature
2017-12-15 13:41 ` Maxime Ripard
@ 2017-12-15 14:36 ` Andre Przywara
2017-12-15 15:05 ` Jagan Teki
2017-12-15 15:02 ` Jagan Teki
1 sibling, 1 reply; 29+ messages in thread
From: Andre Przywara @ 2017-12-15 14:36 UTC (permalink / raw)
To: u-boot
Hi,
On 15/12/17 13:41, Maxime Ripard wrote:
> On Thu, Dec 14, 2017 at 02:03:12PM +0530, Jagan Teki wrote:
>> On Wed, Dec 13, 2017 at 9:09 PM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>>> On Wed, Dec 13, 2017 at 11:33:02AM +0530, Jagan Teki wrote:
>>>> From: Jagan Teki <jagannadh.teki@gmail.com>
>>>>
>>>> Enable FIT_SIGNATURE for sunxi a64.
>>>>
>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>> ---
>>>> Changes for v3:
>>>> - Move imply outside block
>>>> Changes for v2:
>>>> - Use imply instead of select
>>>>
>>>> arch/arm/mach-sunxi/Kconfig | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>>>> index 1fededd..05e2d47 100644
>>>> --- a/arch/arm/mach-sunxi/Kconfig
>>>> +++ b/arch/arm/mach-sunxi/Kconfig
>>>> @@ -179,6 +179,7 @@ config MACH_SUN50I
>>>> select SUNXI_DRAM_DW_32BIT
>>>> select FIT
>>>> select SPL_LOAD_FIT
>>>> + imply FIT_SIGNATURE
>>>
>>> I'm really not sure we should force it by default. How much code size
>>> is it adding?
>>
>> Why we need to consider u-boot size? (because it may cross the loader2 size?)
>> Here is the delta of u-boot elf
>
> The same reason than anything else on our arm64 builds lately: we have
> a u-boot binary too big for the size compared to our environment offset.
I agree, and aside from that I don't see how this is useful:
- We don't *need* this for Allwinner boards.
- It is not usable without some more setup (which that other doc patch
describes).
- As Maxime mentioned, this is not very helpful on it's own, due to it
inherent vulnerability without a protected SPL as well.
- No other boards seems to set FIT_SIGNATURE.
So you can happily add this to your private config file (overlay), where
you create U-Boot binaries and pipe them to some encryption chain
afterwards. But I don't think it belongs into the mainline Kconfig.
Cheers,
Andre.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature
2017-12-15 14:36 ` Andre Przywara
@ 2017-12-15 15:05 ` Jagan Teki
2017-12-15 15:31 ` Andre Przywara
0 siblings, 1 reply; 29+ messages in thread
From: Jagan Teki @ 2017-12-15 15:05 UTC (permalink / raw)
To: u-boot
On Fri, Dec 15, 2017 at 8:06 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 15/12/17 13:41, Maxime Ripard wrote:
>> On Thu, Dec 14, 2017 at 02:03:12PM +0530, Jagan Teki wrote:
>>> On Wed, Dec 13, 2017 at 9:09 PM, Maxime Ripard
>>> <maxime.ripard@free-electrons.com> wrote:
>>>> On Wed, Dec 13, 2017 at 11:33:02AM +0530, Jagan Teki wrote:
>>>>> From: Jagan Teki <jagannadh.teki@gmail.com>
>>>>>
>>>>> Enable FIT_SIGNATURE for sunxi a64.
>>>>>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>> Changes for v3:
>>>>> - Move imply outside block
>>>>> Changes for v2:
>>>>> - Use imply instead of select
>>>>>
>>>>> arch/arm/mach-sunxi/Kconfig | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>>>>> index 1fededd..05e2d47 100644
>>>>> --- a/arch/arm/mach-sunxi/Kconfig
>>>>> +++ b/arch/arm/mach-sunxi/Kconfig
>>>>> @@ -179,6 +179,7 @@ config MACH_SUN50I
>>>>> select SUNXI_DRAM_DW_32BIT
>>>>> select FIT
>>>>> select SPL_LOAD_FIT
>>>>> + imply FIT_SIGNATURE
>>>>
>>>> I'm really not sure we should force it by default. How much code size
>>>> is it adding?
>>>
>>> Why we need to consider u-boot size? (because it may cross the loader2 size?)
>>> Here is the delta of u-boot elf
>>
>> The same reason than anything else on our arm64 builds lately: we have
>> a u-boot binary too big for the size compared to our environment offset.
>
> I agree, and aside from that I don't see how this is useful:
> - We don't *need* this for Allwinner boards.
why? can you elaborate?
> - It is not usable without some more setup (which that other doc patch
> describes).
doc patch is rejected since we have redundant docs on the same topic.
> - As Maxime mentioned, this is not very helpful on it's own, due to it
> inherent vulnerability without a protected SPL as well.
> - No other boards seems to set FIT_SIGNATURE.
I'm mentioning this again, please check the other platforms as well
this is verified-boot not secure-boot, other platforms will do use
same.
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature
2017-12-15 15:05 ` Jagan Teki
@ 2017-12-15 15:31 ` Andre Przywara
0 siblings, 0 replies; 29+ messages in thread
From: Andre Przywara @ 2017-12-15 15:31 UTC (permalink / raw)
To: u-boot
Hi,
On 15/12/17 15:05, Jagan Teki wrote:
> On Fri, Dec 15, 2017 at 8:06 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>> Hi,
>>
>> On 15/12/17 13:41, Maxime Ripard wrote:
>>> On Thu, Dec 14, 2017 at 02:03:12PM +0530, Jagan Teki wrote:
>>>> On Wed, Dec 13, 2017 at 9:09 PM, Maxime Ripard
>>>> <maxime.ripard@free-electrons.com> wrote:
>>>>> On Wed, Dec 13, 2017 at 11:33:02AM +0530, Jagan Teki wrote:
>>>>>> From: Jagan Teki <jagannadh.teki@gmail.com>
>>>>>>
>>>>>> Enable FIT_SIGNATURE for sunxi a64.
>>>>>>
>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>> ---
>>>>>> Changes for v3:
>>>>>> - Move imply outside block
>>>>>> Changes for v2:
>>>>>> - Use imply instead of select
>>>>>>
>>>>>> arch/arm/mach-sunxi/Kconfig | 1 +
>>>>>> 1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>>>>>> index 1fededd..05e2d47 100644
>>>>>> --- a/arch/arm/mach-sunxi/Kconfig
>>>>>> +++ b/arch/arm/mach-sunxi/Kconfig
>>>>>> @@ -179,6 +179,7 @@ config MACH_SUN50I
>>>>>> select SUNXI_DRAM_DW_32BIT
>>>>>> select FIT
>>>>>> select SPL_LOAD_FIT
>>>>>> + imply FIT_SIGNATURE
>>>>>
>>>>> I'm really not sure we should force it by default. How much code size
>>>>> is it adding?
>>>>
>>>> Why we need to consider u-boot size? (because it may cross the loader2 size?)
>>>> Here is the delta of u-boot elf
>>>
>>> The same reason than anything else on our arm64 builds lately: we have
>>> a u-boot binary too big for the size compared to our environment offset.
>>
>> I agree, and aside from that I don't see how this is useful:
>> - We don't *need* this for Allwinner boards.
>
> why? can you elaborate?
I guess *you* have to present why we would need it. Fact is it happily
runs without it, it's just some optional feature. Most users which rely
on the defconfig don't have a need for this. If someone wants to use it,
enabling this is the config is their least problem.
>> - It is not usable without some more setup (which that other doc patch
>> describes).
>
> doc patch is rejected since we have redundant docs on the same topic.
I know ;-)
As mentioned above, for this feature to be useful you have to go through
quite some other steps, so there is no reason for it to be enabled by
default.
>> - As Maxime mentioned, this is not very helpful on it's own, due to it
>> inherent vulnerability without a protected SPL as well.
>> - No other boards seems to set FIT_SIGNATURE.
>
> I'm mentioning this again, please check the other platforms as well
> this is verified-boot not secure-boot, other platforms will do use
> same.
Sure, but none of them sets this unconditionally in their Kconfig. And
given that most users are totally happy with an unsigned firmware for
their Allwinner board ...
You could market it as some upsell of your product ;-)
Cheers,
Andre.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [PATCH v3 1/5] sunxi: a64: Enable FIT Signature
2017-12-15 13:41 ` Maxime Ripard
2017-12-15 14:36 ` Andre Przywara
@ 2017-12-15 15:02 ` Jagan Teki
1 sibling, 0 replies; 29+ messages in thread
From: Jagan Teki @ 2017-12-15 15:02 UTC (permalink / raw)
To: u-boot
On Fri, Dec 15, 2017 at 7:11 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Dec 14, 2017 at 02:03:12PM +0530, Jagan Teki wrote:
>> On Wed, Dec 13, 2017 at 9:09 PM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > On Wed, Dec 13, 2017 at 11:33:02AM +0530, Jagan Teki wrote:
>> >> From: Jagan Teki <jagannadh.teki@gmail.com>
>> >>
>> >> Enable FIT_SIGNATURE for sunxi a64.
>> >>
>> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>> >> ---
>> >> Changes for v3:
>> >> - Move imply outside block
>> >> Changes for v2:
>> >> - Use imply instead of select
>> >>
>> >> arch/arm/mach-sunxi/Kconfig | 1 +
>> >> 1 file changed, 1 insertion(+)
>> >>
>> >> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>> >> index 1fededd..05e2d47 100644
>> >> --- a/arch/arm/mach-sunxi/Kconfig
>> >> +++ b/arch/arm/mach-sunxi/Kconfig
>> >> @@ -179,6 +179,7 @@ config MACH_SUN50I
>> >> select SUNXI_DRAM_DW_32BIT
>> >> select FIT
>> >> select SPL_LOAD_FIT
>> >> + imply FIT_SIGNATURE
>> >
>> > I'm really not sure we should force it by default. How much code size
>> > is it adding?
>>
>> Why we need to consider u-boot size? (because it may cross the loader2 size?)
>> Here is the delta of u-boot elf
>
> The same reason than anything else on our arm64 builds lately: we have
> a u-boot binary too big for the size compared to our environment offset.
Was that the env size is the show-stopper for adding new feature?
since U-Boot proper runs on DRAM env's are those can be update, I'm
not saying based on this FIT in general for new features.
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply [flat|nested] 29+ messages in thread