Re: [U-Boot] [PATCH 1/3] mx6sx: udoo_neo: Define the default serial console

[Breno Matheus Lima]

Hi Peter,

2017-02-14 11:10 GMT-02:00  Peter Robinson <pbrobin...@gmail.com>:
> From: Peter Robinson <pbrobin...@gmail.com>
> Date: Tue, Feb 14, 2017 at 11:10 AM
> Subject: [U-Boot] [PATCH 1/3] mx6sx: udoo_neo: Define the default serial 
> console
> To: Breno Lima <breno.l...@nxp.com>, Francesco Montefoschi
> <francesco.montefos...@udoo.org>, Stefano Babic <sba...@denx.de>,
> u-boot@lists.denx.de
>
>
> Standard boot processes including distro boot generally expect the
> default console to be defined.
>
> Signed-off-by: Peter Robinson <pbrobin...@gmail.com>

For the entire series:

Tested-by: Breno Lima <breno.l...@nxp.com>

Thanks
Best Regards,
-- 
Breno Matheus Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx6sx: Add initial support for UDOO Neo Board

[Breno Matheus Lima]

Hi Andreas,

Thanks for letting me know, I'm going to send a patch to fix it.

2017-01-09 17:30 GMT-02:00 Andreas Färber <afaer...@suse.de>:
>
> Hi,
>
> Am 25.11.2016 um 19:56 schrieb Breno Lima:
> > diff --git a/include/configs/udoo_neo.h b/include/configs/udoo_neo.h
> > new file mode 100644
> > index 000..81e0481
> > --- /dev/null
> > +++ b/include/configs/udoo_neo.h
> [...]
> > +#define CONFIG_EXTRA_ENV_SETTINGS \
> > + "console=ttymxc0,115200\0" \
> > + "fdt_high=0x\0" \
> > + "initrd_high=0x\0" \
> > + "fdt_file=undefined\0" \
> > + "fdt_addr=0x8300\0" \
>
> This needs to be fdt_addr_r.
>
> => boot
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> load - load binary file from a filesystem
>
> Usage:
> load  [<dev[:part]> [ [ [bytes [pos]
> - Load binary file 'filename' from partition 'part' on device
>type 'interface' instance 'dev' to address 'addr' in memory.
>   'bytes' gives the size to load in bytes.
>   If 'bytes' is 0 or omitted, the file is read until the end.
>   'pos' gives the file byte position to start reading from.
>   If 'pos' is 0 or omitted, the file is read from the start.
> BOOTP broadcast 1
> ...
>
> > + "ip_dyn=yes\0" \
> > + "mmcdev=0\0" \
> > + "mmcrootfstype=ext4\0" \
> > + "mmcautodetect=no\0" \
> > + "findfdt="\
> > + "if test $board_name = BASIC; then " \
> > + "setenv fdt_file imx6sx-udoo-neo-basic.dtb; fi; "
\
> > + "if test $board_name = BASICKS; then " \
> > + "setenv fdt_file imx6sx-udoo-neo-basic.dtb; fi; "
\
> > + "if test $board_name = FULL; then " \
> > + "setenv fdt_file imx6sx-udoo-neo-full.dtb; fi; " \
> > + "if test $board_name = EXTENDED; then " \
> > + "setenv fdt_file imx6sx-udoo-neo-extended.dtb;
fi; " \
> > + "if test $fdt_file = UNDEFINED; then " \
> > + "echo WARNING: Could not determine dtb to use;
fi; \0" \
>
> Nit: Trailing semicolon and space could be dropped.
>
> > + "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
> > + "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
> > + "ramdisk_addr_r=0x8300\0" \
> > + "ramdiskaddr=0x83000000\0" \
>
> Why have a duplicate $ramdiskaddr for a new board?
>
> Regards,
> Andreas
>
> > + "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
> > + BOOTENV
> > +
> > +#define BOOT_TARGET_DEVICES(func) \
> > + func(MMC, mmc, 0)
> > +
> > +#define CONFIG_BOOTCOMMAND \
> > + "run findfdt; " \
> > + "run distro_bootcmd"
> > +
> > +#include 
> [...]
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)


Regards,
--
Breno Matheus Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] mx6slevk: imximage.cfg: Handle the CONFIG_SECURE_BOOT case

[Breno Matheus Lima]

Hi Stefano,

Just a gentle ping on this series.

Thanks,
Breno Lima

2017-11-27 23:34 GMT-02:00 Peng Fan <peng@nxp.com>:
>
>
>> -Original Message-
>> From: Breno Lima [mailto:brenomath...@gmail.com]
>> Sent: Tuesday, November 28, 2017 7:03 AM
>> To: Fabio Estevam <fabio.este...@nxp.com>; sba...@denx.de
>> Cc: Peng Fan <peng....@nxp.com>; u-boot@lists.denx.de; Breno Matheus
>> Lima <breno.l...@nxp.com>
>> Subject: [PATCH 1/5] mx6slevk: imximage.cfg: Handle the
>> CONFIG_SECURE_BOOT case
>>
>> From: Breno Lima <breno.l...@nxp.com>
>>
>> Secure boot is not enabled in mx6slevk imximage.cfg, add support for it.
>>
>> Signed-off-by: Breno Lima <breno.l...@nxp.com>
>> ---
>>  board/freescale/mx6slevk/imximage.cfg | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/board/freescale/mx6slevk/imximage.cfg
>> b/board/freescale/mx6slevk/imximage.cfg
>> index 024de9c..9722eb5 100644
>> --- a/board/freescale/mx6slevk/imximage.cfg
>> +++ b/board/freescale/mx6slevk/imximage.cfg
>> @@ -8,6 +8,8 @@
>>   *
>>   * The syntax is taken as close as possible with the kwbimage
>>   */
>> +#define __ASSEMBLY__
>> +#include 
>>
>>  /* image version */
>>
>> @@ -21,6 +23,13 @@ IMAGE_VERSION 2
>>  BOOT_FROMsd
>>
>>  /*
>> + * Secure boot support
>> + */
>> +#ifdef CONFIG_SECURE_BOOT
>> +CSF CONFIG_CSF_SIZE
>> +#endif
>> +
>> +/*
>
> Acked-by: Peng Fan <peng@nxp.com>
>
>
>>   * Device Configuration Data (DCD)
>>   *
>>   * Each entry must have the format:
>> --
>> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 12/23] arm: imx: hab: Print CSF based on IVT descriptor

[Breno Matheus Lima]

Hi Bryan,

2017-12-28 16:49 GMT-02:00 Bryan O'Donoghue :
> The IVT gives the absolute address of the CSF. There is no requirement for
> the CSF to be located adjacent to the IVT so lets use the address provided
> in the IVT header instead of the fixed CSF offset currently in place.
>
> Its worth noting if you use u-boot mkimage and the i.MX CST tool as
> described in the NXP documentation you will get an image like
>
> IVT | BINARY | CSF not IVT | CSF | BINARY as the code currently assumes.

Your patch looks fine, just a comment here.

The hab_rvt_authenticate_image() is usually executed for extending the
root of trust beyond the initial boot image (zImage, u-boot-ivt.img),
in my understanding the layout described on the NXP documentation " |
IVT | BINARY | CSF | " just applies for the initial boot images.

For additional boot images the expected layout is currently documented
in "arch/arm/mach-imx/hab.c" | BINARY |  IVT  |  CSF |

Maybe this sentence can be reformulated for better understanding.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 04/23] arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail

[Breno Matheus Lima]

Hi Bryan,

2017-12-28 16:49 GMT-02:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
> The current code disjoins an entire block of code on hab_entry pass/fail
> resulting in a large chunk of authenticate_image being offset to the right.
>
> Fix this by checking hab_entry() pass/failure and exiting the function
> directly if in an error state.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
> Cc: Stefano Babic <sba...@denx.de>
> Cc: Fabio Estevam <fabio.este...@nxp.com>
> Cc: Peng Fan <peng@nxp.com>
> Cc: Albert Aribaud <albert.u.b...@aribaud.net>
> Cc: Sven Ebenfeld <sven.ebenf...@gmail.com>
> Cc: George McCollister <george.mccollis...@gmail.com>
> Cc: Breno Matheus Lima <brenomath...@gmail.com>
> ---
>  arch/arm/mach-imx/hab.c | 118 
> 
>  1 file changed, 60 insertions(+), 58 deletions(-)
>
> diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
> index 6f86c02..f878b7b 100644
> --- a/arch/arm/mach-imx/hab.c
> +++ b/arch/arm/mach-imx/hab.c
> @@ -438,75 +438,77 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
> image_size)
>
> hab_caam_clock_enable(1);
>
> -   if (hab_rvt_entry() == HAB_SUCCESS) {
> -   /* If not already aligned, Align to ALIGN_SIZE */
> -   ivt_offset = (image_size + ALIGN_SIZE - 1) &
> -   ~(ALIGN_SIZE - 1);
> +   if (hab_rvt_entry() != HAB_SUCCESS) {
> +   puts("hab entry function fail\n");
> +   goto hab_caam_clock_disable;
> +   }
>
> -   start = ddr_start;
> -   bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
> +   /* If not already aligned, Align to ALIGN_SIZE */
> +   ivt_offset = (image_size + ALIGN_SIZE - 1) &
> +   ~(ALIGN_SIZE - 1);
> +
> +   start = ddr_start;
> +   bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
>  #ifdef DEBUG
> -   printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n",
> -  ivt_offset, ddr_start + ivt_offset);
> -   puts("Dumping IVT\n");
> -   print_buffer(ddr_start + ivt_offset,
> -(void *)(ddr_start + ivt_offset),
> -4, 0x8, 0);
> -
> -   puts("Dumping CSF Header\n");
> -   print_buffer(ddr_start + ivt_offset + IVT_SIZE,
> -(void *)(ddr_start + ivt_offset + IVT_SIZE),
> -4, 0x10, 0);
> +   printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n",
> +  ivt_offset, ddr_start + ivt_offset);
> +   puts("Dumping IVT\n");
> +   print_buffer(ddr_start + ivt_offset,
> +(void *)(ddr_start + ivt_offset),
> +4, 0x8, 0);
> +
> +   puts("Dumping CSF Header\n");
> +   print_buffer(ddr_start + ivt_offset + IVT_SIZE,
> +(void *)(ddr_start + ivt_offset + IVT_SIZE),
> +4, 0x10, 0);
>
>  #if  !defined(CONFIG_SPL_BUILD)
> -   get_hab_status();
> +   get_hab_status();
>  #endif
>
> -   puts("\nCalling authenticate_image in ROM\n");
> -   printf("\tivt_offset = 0x%x\n", ivt_offset);
> -   printf("\tstart = 0x%08lx\n", start);
> -   printf("\tbytes = 0x%x\n", bytes);
> +   puts("\nCalling authenticate_image in ROM\n");
> +   printf("\tivt_offset = 0x%x\n", ivt_offset);
> +   printf("\tstart = 0x%08lx\n", start);
> +   printf("\tbytes = 0x%x\n", bytes);
>  #endif
> -   /*
> -* If the MMU is enabled, we have to notify the ROM
> -* code, or it won't flush the caches when needed.
> -* This is done, by setting the "pu_irom_mmu_enabled"
> -* word to 1. You can find its address by looking in
> -* the ROM map. This is critical for
> -* authenticate_image(). If MMU is enabled, without
> -* setting this bit, authentication will fail and may
> -* crash.
> -*/
> -   /* Check MMU enabled */
> -   if (is_soc_type(MXC_SOC_MX6) && get_cr() & CR_M) {
> -   if (is_mx6dq()) {
> -   /*
> -* This won't work on Rev 1.0.0 of
> -* i.MX6Q/D, since their ROM doesn't
> - 

Re: [U-Boot] [PATCH v2 07/23] arm: imx: hab: Fix authenticate_image input parameters

[Breno Matheus Lima]

Hi Bryan,

2017-12-28 16:49 GMT-02:00 Bryan O'Donoghue :
> u-boot command "hab_auth_img" tells a user that it takes
>
> - addr - image hex length

I think the correct is:
- addr - image hex address

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 00/24] Fix and extend i.MX HAB layer

[Breno Matheus Lima]

Hi Bryan,

2018-01-08 15:36 GMT-02:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
> v5:
> - Drop dcache disable across HAB call.
>   We can't replicate this error on the current codebase and the available
>   images. We'll have to wait for the error to crop up again before pushing
>   that patch any further.
>
> v4:
> - No change mixed extra patches @ v3 unnoticed with previous
>   git-send
>
> v3:
> - Only call into ROM if headers are verified. - Bryan
>
> - Print HAB event log if and only if a call was made to HAB
>   and a meaningful status code has been obtained. - Breno
>
> v2:
> - Fix compilation warnings and errors in SPL highlighted by
>   Breno Matheus Lima
>
> - Add CC: Breno Matheus Lima <brenomath...@gmail.com> to all patches
>
> v1:
> This patchset updates the i.MX HAB layer in u-boot to fix a list of
> identified issues and then to add and extend existing functionality.
>
> The first block of patches 0001-0006 deal with fixing existing code,
>
> - Fixes indentation
> - Fixes the treatment of input parameters to hab_auth_image.
>
> The second block of patches 0007-0013 are about tidying up the HAB code
>
> - Remove reliance on hard-coding to specific offsets
> - IVT header drives locating CSF
> - Continue to support existing boards
>
> Patches 0014 onwards extend out the HAB functionality.
>
> - hab_rvt_check_target is a recommended check in the NXP documents to
>   perform prior to hab_rvt_authenticate_image
> - hab_rvt_failsafe is a useful function to set the board into BootROM
>   USB recovery mode.
>
>
> Bryan O'Donoghue (24):
>   arm: imx: hab: Make authenticate_image return int
>   arm: imx: hab: Fix authenticate_image result code
>   arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail
>   arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail
>   arm: imx: hab: Move IVT_SIZE to hab.h
>   arm: imx: hab: Move CSF_PAD_SIZE to hab.h
>   arm: imx: hab: Fix authenticate_image input parameters
>   arm: imx: hab: Add IVT header definitions
>   arm: imx: hab: Add IVT header verification
>   arm: imx: hab: Verify IVT self matches calculated address
>   arm: imx: hab: Only call ROM once headers are verified
>   arm: imx: hab: Print CSF based on IVT descriptor
>   arm: imx: hab: Print additional IVT elements during debug
>   arm: imx: hab: Define rvt_check_target()
>   arm: imx: hab: Implement hab_rvt_check_target
>   arm: imx: hab: Add a hab_rvt_check_target to image auth
>   arm: imx: hab: Print HAB event log only after calling ROM
>   arm: imx: hab: Make internal functions and data static
>   arm: imx: hab: Prefix authenticate_image with imx_hab
>   arm: imx: hab: Rename is_hab_enabled imx_hab_is_enabled
>   arm: imx: hab: Make imx_hab_is_enabled global
>   arm: imx: hab: Define rvt_failsafe()
>   arm: imx: hab: Implement hab_rvt_failsafe
>   arm: imx: hab: Add hab_failsafe console command

For the entire series:

Tested-by: Breno Lima <breno.l...@nxp.com>

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] i2c: imx: bus arbitration fix when reading block data

[Breno Matheus Lima]

Hi Jim,

2018-01-16 10:47 GMT-02:00 Heiko Schocher :
> Hello Fabio,
>
> Am 16.01.2018 um 12:50 schrieb Fabio Estevam:
>>
>> Hi Heiko,
>>
>> On Tue, Jan 16, 2018 at 3:29 AM, Heiko Schocher  wrote:
>>
>>> And some Tested-by would be helpful ...
>>>
>>> @Stefano, @Fabio: Any chance to test this change? Thanks!
>>
>>
>> Breno on Cc will do a quick test on this one.

I tested your patch on a mx6sabresd board and U-Boot is hanging in
power_init_board():

U-Boot SPL 2018.01-39204-g3244ca3 (Jan 16 2018 - 12:13:25)
Trying to boot from MMC1


U-Boot 2018.01-39204-g3244ca3 (Jan 16 2018 - 12:13:25 -0200)

CPU:   Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz)
CPU:   Automotive temperature grade (-40C to 125C) at 25C
Reset cause: POR
Board: MX6-SabreSD
I2C:   ready
DRAM:  1 GiB


With DEBUG mode enabled I'm getting the following output:

U-Boot 2018.01-39204-g3244ca3-dirty (Jan 16 2018 - 12:24:34 -0200)

CPU:   Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz)
CPU:   Automotive temperature grade (-40C to 125C) at 36C
Reset cause: POR
Board: MX6-SabreSD
I2C:   ready
DRAM:  1 GiB
pmic_alloc: new pmic struct: 0x4f56e1e8
pmic_get: pmic PFUZE100 -> 0x4f56e1e8
i2c_write_data: chip=0x8, len=0x0
write_data:

I also tested on a mx7dsabresd and on this board your patch is working
fine. If you need more details please let me know.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] U-boot can verify an HW signature?

[Breno Matheus Lima]

Hi Saveiro,

2018-01-19 16:45 GMT-02:00 Saverio Mori <saverio.m...@gmail.com>:
> Hi Breno Lima,
> For the moment we have not secure boot, we use "plain" u-boot running on
> a module board equipped with an "open" i.MX6UL processor, and we are
> newbies in the field of secure boot. We wish that our firmware works
> only on approved hardware, and not on common one. From what we have
> read, secured boot allow that only approved FW works on prepared HW; our
> problem is just the reciprocal, i.e. allow running of our FW only on
> approved boards. In other words, a secured FW can works on a unsecured
> board (while a secured board requires a secured FW), we wish to block
> this situation.
> All The Best,

You can have more details about secure boot in doc/README.mxc_hab file.

The application note AN4581 can be also helpful:
https://www.nxp.com/docs/en/application-note/AN4581.pdf

The secure boot is intended to prepare your device to just run
authenticated SW,  once your SRK Hash and SEC_CONFIG fuse are
programmed you can only execute authenticated bootloader on this
device.

If you want that your SW can be only executed on  approved hardware
you can refer to encrypted boot, which is supported on i.MX6UL.

You can find more details in doc/README.mxc_hab file and also in NXP
community. Currently there is no application note provided by NXP
about encrypted boot:
https://community.nxp.com/docs/DOC-330622

Note that dek_blob command can be only executed in closed devices, so
you need to run an authenticated U-Boot to prepare an encrypted boot
image.

Let us know if you have any questions during the process.

Thanks,
Breno Lima

>
> Saverio M.
>
> Il 19/01/2018 18:54, Breno Matheus Lima ha scritto:
>> Hi Saverio,
>>
>> 2018-01-19 11:12 GMT-02:00 Saverio Mori <saverio.m...@gmail.com>:
>>> Hi to the community. I have found a lot of material on secure booting and 
>>> how to sign u-boot an uimage in order to that only trusted sw is load. This 
>>> is good for my but i have also the opposite problem, that is i have to be 
>>> sure that my sw is load on an hardware signed in some way. It is possible, 
>>> and how, implement this feature in u-boot, at least running on iMX6 boards? 
>>> Thanks!!!
>> Can you please share more details about this verification you want to
>> achieve? Are you currently running a signed U-Boot in a closed device
>> (eFuse SEC_CONFIG = 1)?
>>
>> Thanks,
>> Breno Lima
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] U-boot can verify an HW signature?

[Breno Matheus Lima]

Hi Saverio,

2018-01-19 11:12 GMT-02:00 Saverio Mori :
> Hi to the community. I have found a lot of material on secure booting and how 
> to sign u-boot an uimage in order to that only trusted sw is load. This is 
> good for my but i have also the opposite problem, that is i have to be sure 
> that my sw is load on an hardware signed in some way. It is possible, and 
> how, implement this feature in u-boot, at least running on iMX6 boards? 
> Thanks!!!

Can you please share more details about this verification you want to
achieve? Are you currently running a signed U-Boot in a closed device
(eFuse SEC_CONFIG = 1)?

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] doc: mxc_hab: Improve the config option list

[Breno Matheus Lima]

Hi Fabio,

2018-01-21 15:57 GMT-02:00 Fabio Estevam :
> From: Fabio Estevam 
>
> The original text is from the time that the config options were not
> converted to Kconfig.
>
> After the conversion to Kconfig only CONFIG_SECURE_BOOT and
> CONFIG_CMD_DEKBLOB need to be selected by the user.
>
> The other config options are automatically selected by the Kconfig
> logic.
>
> Signed-off-by: Fabio Estevam 

Reviewed-by: Breno Lima 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 21/25] arm: imx: hab: Make authenticate_image() return zero on open boards

[Breno Matheus Lima]

Hi Bryan,

2018-01-12 10:40 GMT-02:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
> The BootROM will not successfully process a HAB image passed by u-boot
> unless the board has been set into locked mode. Some of the existing usages
> of authenticate_image() expect and rely on unlocked boards doing the
> following
>
> 1. Not calling into the BootROM authenticate_image() callback
> 2. Returning a pass status for authenticate_image() calls anyway
>
> A previous patch removed the necessity to call into imx_hab_is_enabled()
> twice. This patch ensures the reliance on authenticate_image() returning
> zero is maintained.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
> Suggested-by: Breno Matheus Lima <brenomath...@gmail.com>
> Cc: Stefano Babic <sba...@denx.de>
> Cc: Fabio Estevam <fabio.este...@nxp.com>
> Cc: Peng Fan <peng@nxp.com>
> Cc: Albert Aribaud <albert.u.b...@aribaud.net>
> Cc: Sven Ebenfeld <sven.ebenf...@gmail.com>
> Cc: George McCollister <george.mccollis...@gmail.com>

Thanks for adding this patch on the series, I tested on an open
mx6ulevk board and it's working fine.

Tested-by: Breno Lima <breno.l...@nxp.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: fix CAAM base for i.MX6UL

[Breno Matheus Lima]

Hi Anatolij,

2018-01-11 12:54 GMT-02:00 Fabio Estevam :
> Hi Anatolij,
>
> Thanks for the fix.
>
> On Thu, Jan 11, 2018 at 12:14 PM, Anatolij Gustschin  wrote:
>> HW accelerated "hash sha256 ..." command doesn't work on i.MX6UL, we get
>> "CAAM was not setup properly or it is faulty" error message.
>>
>> This is due to wrong CAAM base 0x0210, on i.MX6UL the CAAM base
>> address is 0x0214. Fix it.
>>
>> Note: with this patch applied the "hash sha256" commant still has some
>> issues on i.MX6UL ("Invalid KEY Command" or other errors). With data
>> cache off the "hash sha256" command works as expected.
>
> Breno, could you please take a look at this issue when possible ?

I managed to reproduce this issue on a mx6sabreauto, with data cache
off the "hash sha256" command works as expected.

I will take a look on this issue and let you know any progress.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 03/24] arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail

[Breno Matheus Lima]

Hi Bryan,

2018-01-08 15:36 GMT-02:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
> There is no need to call is_enabled() twice in authenticate_image - it does
> nothing but add an additional layer of indentation.
>
> We can check for is_enabled() at the start of the function and return the
> result code directly.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
> Cc: Stefano Babic <sba...@denx.de>
> Cc: Fabio Estevam <fabio.este...@nxp.com>
> Cc: Peng Fan <peng@nxp.com>
> Cc: Albert Aribaud <albert.u.b...@aribaud.net>
> Cc: Sven Ebenfeld <sven.ebenf...@gmail.com>
> Cc: George McCollister <george.mccollis...@gmail.com>
> Cc: Breno Matheus Lima <brenomath...@gmail.com>
> ---
>  arch/arm/mach-imx/hab.c | 138 
> 
>  1 file changed, 69 insertions(+), 69 deletions(-)
>
> diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
> index 9fe6d43..6f86c02 100644
> --- a/arch/arm/mach-imx/hab.c
> +++ b/arch/arm/mach-imx/hab.c
> @@ -428,91 +428,91 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
> image_size)
> hab_rvt_entry = hab_rvt_entry_p;
> hab_rvt_exit = hab_rvt_exit_p;
>
> -   if (is_hab_enabled()) {
> -   printf("\nAuthenticate image from DDR location 0x%x...\n",
> -  ddr_start);
> +   if (!is_hab_enabled()) {
> +   puts("hab fuse not enabled\n");
> +   return result;
> +   }

Just another comment in your series, I was working on an open i.MX6UL
EVK and noticed that we may have problem with SPL boards in open mode:

U-Boot SPL 2018.01-rc3-39088-g59b5c4e (Jan 11 2018 - 16:32:52)
Trying to boot from MMC1
hab fuse not enabled
spl: ERROR:  image authentication unsuccessful
### ERROR ### Please RESET the board ###

The imx_hab_authenticate_image() is returning an authentication
failure in this case and we cannot boot u-boot-ivt.img. In this way is
not possible to run hab_status before closing the device.

I think the following fix this issue:

--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -492,7 +492,7 @@ int imx_hab_authenticate_image(uint32_t ddr_start,
uint32_t image_size,

if (!imx_hab_is_enabled()) {
puts("hab fuse not enabled\n");
-   return result;
+   goto hab_exit;
}

printf("\nAuthenticate image from DDR location 0x%x...\n",
@@ -594,7 +594,8 @@ hab_exit_failure_print_status:
 hab_caam_clock_disable:
hab_caam_clock_enable(0);

-   if (load_addr != 0)
+hab_exit:
+   if (load_addr != 0 || (!imx_hab_is_enabled()))
result = 0;

Can you please check if is possible to add this on your series? If is
too late I can submit a patch.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 00/25] Fix and extend i.MX HAB layer

[Breno Matheus Lima]

Hi Jagan,

2018-02-08 10:43 GMT-02:00 Jagan Teki <ja...@amarulasolutions.com>:
> On Fri, Jan 12, 2018 at 6:09 PM, Bryan O'Donoghue
> <bryan.odonog...@linaro.org> wrote:
>> v6:
>> - Added patch 21/25 return zero on open (unlocked) board when
>>   calling authenticate_image() - Breno
>>
>> - Added Tested-by: Breno Matheus Lima <brenomath...@gmail.com>
>>   as indicated for remainder 24/25 patches
>>
>> - Added Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>
>>   as indicated for remainder 24/25 patches
>>
>> v5:
>> - Drop dcache disable across HAB call.
>>   We can't replicate this error on the current codebase and the available
>>   images. We'll have to wait for the error to crop up again before pushing
>>   that patch any further.
>>
>> v4:
>> - No change mixed extra patches @ v3 unnoticed with previous
>>   git-send
>>
>> v3:
>> - Only call into ROM if headers are verified. - Bryan
>>
>> - Print HAB event log if and only if a call was made to HAB
>>   and a meaningful status code has been obtained. - Breno
>>
>> v2:
>> - Fix compilation warnings and errors in SPL highlighted by
>>   Breno Matheus Lima
>>
>> - Add CC: Breno Matheus Lima <brenomath...@gmail.com> to all patches
>>
>> v1:
>> This patchset updates the i.MX HAB layer in u-boot to fix a list of
>> identified issues and then to add and extend existing functionality.
>>
>> The first block of patches 0001-0006 deal with fixing existing code,
>>
>> - Fixes indentation
>> - Fixes the treatment of input parameters to hab_auth_image.
>>
>> The second block of patches 0007-0013 are about tidying up the HAB code
>>
>> - Remove reliance on hard-coding to specific offsets
>> - IVT header drives locating CSF
>> - Continue to support existing boards
>>
>> Patches 0014 onwards extend out the HAB functionality.
>>
>> - hab_rvt_check_target is a recommended check in the NXP documents to
>>   perform prior to hab_rvt_authenticate_image
>> - hab_rvt_failsafe is a useful function to set the board into BootROM
>>   USB recovery mode.
>>
>>
>>
>> Bryan O'Donoghue (25):
>>   arm: imx: hab: Make authenticate_image return int
>>   arm: imx: hab: Fix authenticate_image result code
>>   arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail
>>   arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail
>>   arm: imx: hab: Move IVT_SIZE to hab.h
>>   arm: imx: hab: Move CSF_PAD_SIZE to hab.h
>>   arm: imx: hab: Fix authenticate_image input parameters
>>   arm: imx: hab: Add IVT header definitions
>>   arm: imx: hab: Add IVT header verification
>>   arm: imx: hab: Verify IVT self matches calculated address
>>   arm: imx: hab: Only call ROM once headers are verified
>>   arm: imx: hab: Print CSF based on IVT descriptor
>>   arm: imx: hab: Print additional IVT elements during debug
>>   arm: imx: hab: Define rvt_check_target()
>>   arm: imx: hab: Implement hab_rvt_check_target
>>   arm: imx: hab: Add a hab_rvt_check_target to image auth
>>   arm: imx: hab: Print HAB event log only after calling ROM
>>   arm: imx: hab: Make internal functions and data static
>>   arm: imx: hab: Prefix authenticate_image with imx_hab
>>   arm: imx: hab: Rename is_hab_enabled imx_hab_is_enabled
>>   arm: imx: hab: Make authenticate_image() return zero on open boards
>>   arm: imx: hab: Make imx_hab_is_enabled global
>>   arm: imx: hab: Define rvt_failsafe()
>>   arm: imx: hab: Implement hab_rvt_failsafe
>>   arm: imx: hab: Add hab_failsafe console command
>>
>>  arch/arm/include/asm/mach-imx/hab.h |  46 +++-
>>  arch/arm/mach-imx/hab.c | 461 
>> +---
>>  arch/arm/mach-imx/spl.c |  38 ++-
>>  3 files changed, 354 insertions(+), 191 deletions(-)
>
> I tried Secure boot before[1] with SPL and U-Boot proper and work well.
>
> I'm observing authentication issue while loading U-Boot proper, U-Boot
> proper now have features like SPL DM and SPL FIT etc
>
> U-Boot SPL 2018.03-rc1-00182-gb81f7c9 (Feb 08 2018 - 17:19:03 +0530)
> Trying to boot from MMC1
> Expected Linux image is not found. Trying to start U-boot
>
> Authenticate image from DDR location 0x1780...
> bad magic magic=0xb8 length=0x841b version=0x17
> bad length magic=0xb8 length=0x841b version=0x17
> bad version magic=0xb8 length=0x841b version=0x17
> spl: ERROR:  image authentication unsuccessful
> ### ERROR ### Please RESET the board ###
>
> Please let me know where I missed, I'm authenticating SPL and
> u-boot-dtb.img now.

Can you please check if the generated u-boot-dtb.img contains a IVT
table appended in the end of the image?

The mx6slevk_spl_defconfig target also generates SPL + u-boot-dtb.img
but I have to use the u-boot-ivt.img binary instead. In my case
u-boot-dtb.img does not includes a IVT table.

Best Regards,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3] imx: spl: Partially revert "spl: eMMC/SD: Provide one __weak spl_boot_mode() function"

[Breno Matheus Lima]

2018-02-15 12:41 GMT-02:00 Fabio Estevam :
> Commit d695d6627803 ("spl: eMMC/SD: Provide one __weak spl_boot_mode()
> function") breaks the boot on several i.MX6 boards,
> such as cuboxi and wandboard:
>
> U-Boot SPL 2018.03-rc1-00212-g48914fc119 (Feb 10 2018 - 11:04:33 +1300)
> Trying to boot from MMC1
> Failed to mount ext2 filesystem...
> spl_load_image_ext: ext4fs mount err - 0
>
> Partially revert it so that we can boot U-Boot again on these
> i.MX6 platforms.
>
> Reported-by: Jonathan Gray 
> Signed-off-by: Fabio Estevam 

Tested-by: Breno Lima 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/23] Fix and extend i.MX HAB layer

[Breno Matheus Lima]

Hi Bryan,

2017-12-27 10:25 GMT-02:00 Bryan O'Donoghue :
> This patchset updates the i.MX HAB layer in u-boot to fix a list of
> identified issues and then to add and extend existing functionality.
>
> The first block of patches 0001-0006 deal with fixing existing code,
>
> - Fixes indentation
> - Fixes the treatment of input parameters to hab_auth_image.
>
> The second block of patches 0007-0013 are about tidying up the HAB code
>
> - Remove reliance on hard-coding to specific offsets
> - IVT header drives locating CSF
> - Continue to support existing boards
>
> Patches 0014 onwards extend out the HAB functionality.
>
> - hab_rvt_check_target is a recommended check in the NXP documents to
>   perform prior to hab_rvt_authenticate_image
> - hab_rvt_failsafe is a useful function to set the board into BootROM
>   USB recovery mode.
>
> Bryan O'Donoghue (23):
>   arm: imx: hab: Make authenticate_image return int
>   arm: imx: hab: Fix authenticate_image result code
>   arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail
>   arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail
>   arm: imx: hab: Fix authenticate_image input parameters

After applying "[PATCH 05/23] arm: imx: hab: Fix authenticate_image
input parameters" I'm getting the following error when building
mx6sabreauto:

arch/arm/mach-imx/spl.c: In function 'jump_to_image_no_args':
arch/arm/mach-imx/spl.c:200:14: error: 'IVT_SIZE' undeclared (first
use in this function)
 offset + IVT_SIZE + CSF_PAD_SIZE, offset)) {
  ^
arch/arm/mach-imx/spl.c:200:14: note: each undeclared identifier is
reported only once for each function it appears in
arch/arm/mach-imx/spl.c:200:25: error: 'CSF_PAD_SIZE' undeclared
(first use in this function)
 offset + IVT_SIZE + CSF_PAD_SIZE, offset)) {
 ^
arch/arm/mach-imx/spl.c:206:1: warning: 'noreturn' function does return
 }
 ^
scripts/Makefile.build:280: recipe for target
'spl/arch/arm/mach-imx/spl.o' failed
make[2]: *** [spl/arch/arm/mach-imx/spl.o] Error 1
make[2]: *** Waiting for unfinished jobs

>   arm: imx: hab: Fix authenticate image lockup on MX7
>   arm: imx: hab: Move IVT_SIZE to hab.h
>   arm: imx: hab: Move CSF_PAD_SIZE to hab.h

I believe patches "[PATCH 07/23] arm: imx: hab: Move IVT_SIZE to
hab.h" and "[PATCH 08/23] arm: imx: hab: Move CSF_PAD_SIZE to hab.h"
have to be applied before the [PATCH 05/23] to avoid this build error.
Can you please check if it's possible to move these patches?

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] mx6ull: Handle the CONFIG_MX6ULL cases correctly

[Breno Matheus Lima]

Hi Fabio,

2018-01-01 22:16 GMT-02:00 Fabio Estevam :
> From: Fabio Estevam 
>
> Since commit 051ba9e082f7 ("Kconfig: mx6ull: Deselect MX6UL from
> CONFIG_MX6ULL") CONFIG_MX6ULL does not select CONFIG_MX6UL anymore, so
> take this into consideration in all the checks for CONFIG_MX6UL.
>
> Reported-by: Stefan Agner 
> Signed-off-by: Fabio Estevam 
> Reviewed-by: Stefan Agner 

Tested-by: Breno Lima 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 08/25] arm: imx: hab: Fix authenticate image lockup on MX7

[Breno Matheus Lima]

Hi Bryan,

2018-01-02 14:43 GMT-02:00 Bryan O'Donoghue :
> The i.MX6 has some pretty explicit code associated with informing the IROM
> about flushing caches during authenticate_image().
>
> Looking at various pieces of documentation its pretty clear the i.MX6 IROM
> registers are not documented and absent similar documentation on the i.MX7
> the next-best fix is to disabled the dcache while making an
> authenticate_image() callback.
>
> This patch therefore disables dcache temporarily while doing an IROM
> authenticate_image() callback, thus resolving a lockup encountered in a
> complex set of authenticate-image calls observed.
>

I'm trying to reproduce the same issue on an i.MX7D board but I'm not
being able so far, Is it possible to share more details on how to
reproduce this issue? Looking the thread at the NXP community seems
that this can be reproduced in a specific situation, I would like to
test in a similar environment as yours.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 00/25] Fix and extend i.MX HAB layer

[Breno Matheus Lima]

Hi Bryan,

2017-12-29 23:08 GMT-02:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
> v3:
> - Only call into ROM if headers are verified. - Bryan
>
> - Print HAB event log if and only if a call was made to HAB
>   and a meaningful status code has been obtained. - Breno
>
> v2:
> - Fix compilation warnings and errors in SPL highlighted by
>   Breno Matheus Lima
>
> - Add CC: Breno Matheus Lima <brenomath...@gmail.com> to all patches
>
> v1:
> This patchset updates the i.MX HAB layer in u-boot to fix a list of
> identified issues and then to add and extend existing functionality.
>
> The first block of patches 0001-0006 deal with fixing existing code,
>
> - Fixes indentation
> - Fixes the treatment of input parameters to hab_auth_image.
>
> The second block of patches 0007-0013 are about tidying up the HAB code
>
> - Remove reliance on hard-coding to specific offsets
> - IVT header drives locating CSF
> - Continue to support existing boards
>
> Patches 0014 onwards extend out the HAB functionality.
>
> - hab_rvt_check_target is a recommended check in the NXP documents to
>   perform prior to hab_rvt_authenticate_image
> - hab_rvt_failsafe is a useful function to set the board into BootROM
>   USB recovery mode.
>
> Bryan O'Donoghue (25):
>   arm: imx: hab: Make authenticate_image return int
>   arm: imx: hab: Fix authenticate_image result code
>   arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail
>   arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail
>   arm: imx: hab: Move IVT_SIZE to hab.h
>   arm: imx: hab: Move CSF_PAD_SIZE to hab.h
>   arm: imx: hab: Fix authenticate_image input parameters
>   arm: imx: hab: Fix authenticate image lockup on MX7
>   arm: imx: hab: Add IVT header definitions
>   arm: imx: hab: Add IVT header verification
>   arm: imx: hab: Verify IVT self matches calculated address
>   arm: imx: hab: Only call ROM once headers are verified
>   arm: imx: hab: Print CSF based on IVT descriptor
>   arm: imx: hab: Print additional IVT elements during debug
>   arm: imx: hab: Define rvt_check_target()
>   arm: imx: hab: Implement hab_rvt_check_target
>   arm: imx: hab: Add a hab_rvt_check_target to image auth
>   arm: imx: hab: Print HAB event log only after calling ROM
>   arm: imx: hab: Make internal functions and data static
>   arm: imx: hab: Prefix authenticate_image with imx_hab
>   arm: imx: hab: Rename is_hab_enabled imx_hab_is_enabled
>   arm: imx: hab: Make imx_hab_is_enabled global
>   arm: imx: hab: Define rvt_failsafe()
>   arm: imx: hab: Implement hab_rvt_failsafe
>   arm: imx: hab: Add hab_failsafe console command

I'm trying to test your patchset but I'm having some problems with the
series numbering, looking in U-Boot list the patches from 18 to 25 are
duplicated:

https://lists.denx.de/pipermail/u-boot/2017-December/thread.html

[U-Boot] [PATCH v3 16/25] arm: imx: hab: Implement
hab_rvt_check_target   Bryan O'Donoghue
[U-Boot] [PATCH v3 17/25] arm: imx: hab: Add a hab_rvt_check_target to
image auth   Bryan O'Donoghue
[U-Boot] [PATCH v3 18/25] arm: imx: hab: Make internal functions and
data static   Bryan O'Donoghue
[U-Boot] [PATCH v3 18/25] arm: imx: hab: Print HAB event log only
after calling ROM   Bryan O'Donoghue
[U-Boot] [PATCH v3 19/25] arm: imx: hab: Make internal functions and
data static   Bryan O'Donoghue
[U-Boot] [PATCH v3 19/25] arm: imx: hab: Prefix authenticate_image
with imx_hab   Bryan O'Donoghue
[U-Boot] [PATCH v3 20/25] arm: imx: hab: Prefix authenticate_image
with imx_hab   Bryan O'Donoghue
[U-Boot] [PATCH v3 20/25] arm: imx: hab: Rename is_hab_enabled
imx_hab_is_enabled   Bryan O'Donoghue
[U-Boot] [PATCH v3 21/25] arm: imx: hab: Make imx_hab_is_enabled
global   Bryan O'Donoghue
[U-Boot] [PATCH v3 21/25] arm: imx: hab: Rename is_hab_enabled
imx_hab_is_enabled   Bryan O'Donoghue
[U-Boot] [PATCH v3 22/25] arm: imx: hab: Define rvt_failsafe()   Bryan
O'Donoghue
[U-Boot] [PATCH v3 22/25] arm: imx: hab: Make imx_hab_is_enabled
global   Bryan O'Donoghue
[U-Boot] [PATCH v3 23/25] arm: imx: hab: Define rvt_failsafe()   Bryan
O'Donoghue
[U-Boot] [PATCH v3 23/25] arm: imx: hab: Implement hab_rvt_failsafe
Bryan O'Donoghue
[U-Boot] [PATCH v3 24/25] arm: imx: hab: Add hab_failsafe console
command   Bryan O'Donoghue
[U-Boot] [PATCH v3 24/25] arm: imx: hab: Implement hab_rvt_failsafe
Bryan O'Donoghue
[U-Boot] [PATCH v3 25/25] arm: imx: hab: Add hab_failsafe console
command   Bryan O'Donoghue
[U-Boot] [PATCH v3 25/25] arm: imx: hab: Print HAB event log only
after calling ROM   Bryan O'Donoghue

Can you please resend this patchset so I can test the latest changes?

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] crypto/fsl: fix BLOB encapsulation and decapsulation

[Breno Matheus Lima]

Hi Clemens,

2017-12-20 20:08 GMT-02:00 Clemens Gruber :
> The blob_encap and blob_decap functions were not flushing the dcache
> before passing data to CAAM/DMA and not invalidating the dcache when
> getting data back.
> Therefore, blob encapsulation and decapsulation failed with errors like
> the following due to data cache incoherency:
> "4006: DECO: desc idx 0: Invalid KEY command"
>
> To ensure coherency, we allocate aligned memory to store the data passed
> to/from CAAM and flush/invalidate the memory regions.
> Blobs can now be encapsulated and decapsulated with the blob cmd as well
> as from board code by calling blob_encap and blob_decap directly.
>
> Tested on an i.MX6Q board.

I tested your patch on a closed i.MX6QSabreAuto and the functions
blob_encap() and blob_decap() are working fine.
In my environment I had to add a small modification in function
do_blob() in cmd/blob.c file to get the cmd blob working:

+   hab_caam_clock_enable(1);
+   sec_init();

I will investigate this and provide a fix.

>
> Signed-off-by: Clemens Gruber 
Tested-by: Breno Lima 

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 10/23] arm: imx: hab: Add IVT header verification

[Breno Matheus Lima]

Hi Bryan,

2017-12-27 10:25 GMT-02:00 Bryan O'Donoghue :
> The IVT header contains a magic number, fixed length and one of two version
> identifiers. Validate these settings before doing anything with a putative
> IVT binary.
>
> Signed-off-by: Bryan O'Donoghue 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> Cc: Peng Fan 
> Cc: Albert Aribaud 
> Cc: Sven Ebenfeld 
> Cc: George McCollister 
> ---
>  arch/arm/mach-imx/hab.c | 34 ++
>  1 file changed, 34 insertions(+)
>
> diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
> index 76267a7..5591cb5 100644
> --- a/arch/arm/mach-imx/hab.c
> +++ b/arch/arm/mach-imx/hab.c
> @@ -229,6 +229,31 @@ uint8_t hab_engines[16] = {
> -1
>  };
>
> +static int ivt_header_error(const char *err_str, struct ivt_header *ivt_hdr)
> +{
> +   printf("%s magic=0x%x length=0x%02x version=0x%x\n", err_str,
> +  ivt_hdr->magic, ivt_hdr->length, ivt_hdr->version);
> +
> +   return 1;
> +}
> +
> +static int verify_ivt_header(struct ivt_header *ivt_hdr)
> +{
> +   int result = 0;
> +
> +   if (ivt_hdr->magic != IVT_HEADER_MAGIC)
> +   result = ivt_header_error("bad magic", ivt_hdr);
> +
> +   if (be16_to_cpu(ivt_hdr->length) != IVT_TOTAL_LENGTH)
> +   result = ivt_header_error("bad length", ivt_hdr);
> +
> +   if (ivt_hdr->version != IVT_HEADER_V1 &&
> +   ivt_hdr->version != IVT_HEADER_V2)
> +   result = ivt_header_error("bad version", ivt_hdr);
> +
> +   return result;
> +}
> +

I'm trying to build mx6sabreauto which uses the SPL framework and I'm
getting the following build error:

arch/arm/mach-imx/hab.c: In function 'imx_hab_authenticate_image':
arch/arm/mach-imx/hab.c:514:6: warning: implicit declaration of
function 'verify_ivt_header' [-Wimplicit-function-declaration]
  if (verify_ivt_header(ivt_hdr))
  ^
arch/arm/mach-imx/hab.c: At top level:
arch/arm/mach-imx/hab.c:73:13: warning: 'hab_rvt_failsafe_new' defined
but not used [-Wunused-function]
 static void hab_rvt_failsafe_new(void)
 ^
  LD  lib/built-in.o
  LD  spl/arch/arm/mach-imx/built-in.o
  CC  spl/lib/display_options.o
  LD  spl/common/spl/built-in.o
  LD  drivers/video/built-in.o
  LD  drivers/built-in.o
  LD  spl/lib/built-in.o
  LD  u-boot
  LD  spl/u-boot-spl
arch/arm/mach-imx/built-in.o: In function `imx_hab_authenticate_image':
/home/breno/NXP/bootloader/mainline/u-boot-imx/arch/arm/mach-imx/hab.c:514:
undefined reference to `verify_ivt_header'
scripts/Makefile.spl:358: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 1
Makefile:1394: recipe for target 'spl/u-boot-spl' failed
make: *** [spl/u-boot-spl] Error 2
make: *** Waiting for unfinished jobs

Moving the functions ivt_header_error and verify_ivt_header outside of
the "#if !defined(CONFIG_SPL_BUILD)" branch solves this issue in my
side. Can you please check if it's possible to move these functions?

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] U-boot can verify an HW signature?

[Breno Matheus Lima]

Hi Saverio,

2018-01-24 5:35 GMT-02:00 Saverio Mori <saverio.m...@gmail.com>:
> Hi Breno Lima,
> Thank you very much, indeed this is the answer that i need. Perhaps
> could you give me some more details on realizing encrypted boot using
> the yocto project platform?

Currently is not possible to sign or encrypt a U-Boot image using
Yocto project, the CST (Code Signing Tool) is only available at NXP
portal. You can build U-Boot using Yocto with the following
configurations enabled and sign/encrypt this image with CST.

CONFIG_SECURE_BOOT=y
CONFIG_CMD_DEKBLOB=y

This patch from Fabio Estevam can be also helpful:
https://lists.denx.de/pipermail/u-boot/2018-January/317847.html

Thanks,
Breno Lima

> All The Best,
>
> Saverio
>
> Il 20/01/2018 16:00, Breno Matheus Lima ha scritto:
>> Hi Saveiro,
>>
>> 2018-01-19 16:45 GMT-02:00 Saverio Mori <saverio.m...@gmail.com>:
>>> Hi Breno Lima,
>>> For the moment we have not secure boot, we use "plain" u-boot running on
>>> a module board equipped with an "open" i.MX6UL processor, and we are
>>> newbies in the field of secure boot. We wish that our firmware works
>>> only on approved hardware, and not on common one. From what we have
>>> read, secured boot allow that only approved FW works on prepared HW; our
>>> problem is just the reciprocal, i.e. allow running of our FW only on
>>> approved boards. In other words, a secured FW can works on a unsecured
>>> board (while a secured board requires a secured FW), we wish to block
>>> this situation.
>>> All The Best,
>> You can have more details about secure boot in doc/README.mxc_hab file.
>>
>> The application note AN4581 can be also helpful:
>> https://www.nxp.com/docs/en/application-note/AN4581.pdf
>>
>> The secure boot is intended to prepare your device to just run
>> authenticated SW,  once your SRK Hash and SEC_CONFIG fuse are
>> programmed you can only execute authenticated bootloader on this
>> device.
>>
>> If you want that your SW can be only executed on  approved hardware
>> you can refer to encrypted boot, which is supported on i.MX6UL.
>>
>> You can find more details in doc/README.mxc_hab file and also in NXP
>> community. Currently there is no application note provided by NXP
>> about encrypted boot:
>> https://community.nxp.com/docs/DOC-330622
>>
>> Note that dek_blob command can be only executed in closed devices, so
>> you need to run an authenticated U-Boot to prepare an encrypted boot
>> image.
>>
>> Let us know if you have any questions during the process.
>>
>> Thanks,
>> Breno Lima
>>
>>> Saverio M.
>>>
>>> Il 19/01/2018 18:54, Breno Matheus Lima ha scritto:
>>>> Hi Saverio,
>>>>
>>>> 2018-01-19 11:12 GMT-02:00 Saverio Mori <saverio.m...@gmail.com>:
>>>>> Hi to the community. I have found a lot of material on secure booting and 
>>>>> how to sign u-boot an uimage in order to that only trusted sw is load. 
>>>>> This is good for my but i have also the opposite problem, that is i have 
>>>>> to be sure that my sw is load on an hardware signed in some way. It is 
>>>>> possible, and how, implement this feature in u-boot, at least running on 
>>>>> iMX6 boards? Thanks!!!
>>>> Can you please share more details about this verification you want to
>>>> achieve? Are you currently running a signed U-Boot in a closed device
>>>> (eFuse SEC_CONFIG = 1)?
>>>>
>>>> Thanks,
>>>> Breno Lima
>>>
>>>
>
>



-- 
Breno Matheus Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] imx: hab: Convert DCD non-NULL error to warning

[Breno Matheus Lima]

Hi All,

2018-03-12 13:07 GMT-03:00 Tom Rini <tr...@konsulko.com>:
> On Sun, Mar 11, 2018 at 03:36:16PM +0100, Stefano Babic wrote:
>> Hi Everybody,
>>
>> I have applied 1-2 as Fabio suggested. I have a couple of comments for
>> this, too:
>>
>> On 10/03/2018 02:10, Breno Matheus Lima wrote:
>> > Hi Bryan,
>> >
>> > 2018-03-09 10:07 GMT-03:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
>> >> commit 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
>> >> to calling HAB authenticate function.") makes the DCD field being NULL a
>> >> dependency.
>> >>
>> >> This change though will break loading and executing of existing pre-signed
>> >> binaries on a u-boot update i.e. if this change is deployed on a board you
>> >> will be forced to redo all images on that board to NULL out the DCD.
>> >>
>> >> There is no prior guidance from NXP that the DCD must be NULL similarly
>> >> public guidance on usage of the HAB doesn't call out this NULL dependency
>> >> (see boundary devices link).
>> >>
>> >> Since later SoCs will reject a non-NULL DCD there's no reason to make a
>> >> NULL DCD a requirement, however if there is an actual dependency for later
>> >> SoCs the appropriate fix would be to do SoC version checking.
>> >>
>> >> Earlier SoCs are capable (and happy) to authenticate images with non-NULL
>> >> DCDs, we should not be forcing this change on downstream users -
>> >> particularly if it means those users now must rewrite their build systems
>> >> and/or redeploy signed images in the field.
>> >>
>> >> Fixes: 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
>> >> to calling HAB authenticate function.")
>> >
>> > We understand the concern being raised however would prefer to leave
>> > this as an error, and selected users relying on images with DCD
>> > pointers can modify the code accordingly. This does not just apply to
>> > new SoC’s but also applies to existing SoC’s.
>>
>> Anyway, this is not so easy to identify. What we current know is that
>> older SOCs have no problem if the pointer is not set to Null. I agree
>> with Brian that if some constraint is coming, it should be defined with
>> a version checking as we currently do for a lot of things (is_soc() to
>> be clear).
>>
>> I am quite lost because I do not know which SOCs are affected and which
>> not. What does it hide under "later SOCSs" ? Or better which new version
>> of HAB ? I know HAB was updated due to other issues - are the
>> corresponding SOC involved ?
>>
>> If a not-null DCD pointer affects just future SOCs, we should fix it
>> when these SOCs will be available. This means both new SOSs (imx8x) as
>> new version of supported SOCs (mx5 / mx6 / mx7).
>>
>> > Users performing such an
>> > update should definitely test the image prior to making an OTA
>> > available.
>>
>> I think this is another topic and not what Brian is trying to address. I
>> hope as you that *any* update is tested before deploying. But this is
>> unrelated.
>>
>> > It has never been intended for DCD to be used in any post
>> > boot image and we realize the lack of documentation is a hindsight by
>> > us, and we are currently addressing that with updated guidance.
>> >
>>
>> ok, thanks for this, very appreciated.
>>
>> Anyway, I am facing what we should do with this patch for 2018.03. As I
>> said, I am not forcing anyone and I have just picked up 1/3 and 2/3. But
>> IMHO, if there are not good reason to say that not raising an error
>> breaks a lot of supplied device, this should flow into 2018.03, too. And
>> then we get enough time to better explore this issue.
>
> And I need an answer to this final part, before I can release v2018.03.
> Thanks all!
>

The purpose of hab_rvt_authenticate_image() API function is to
authenticate additional boot images in a post-ROM stage, initial boot
images are supposed to be authenticate only once by the initial ROM
code. The HAB implementation in older devices will process and run DCD
if we provide a DCD pointer. DCD commands are supposed to be executed
only once in an early boot stage, re-executing it could lead to an
incorrect authentication boot flow. If we convert DCD non-NULL error
to warning may also break supported devices, not only the new ones.

We understand Bryan's point based in CST documentation but
unfortunately our do

Re: [U-Boot] [PATCH 4/4] imx: hab: Provide hab_auth_img_or_fail command

[Breno Matheus Lima]

Hi Bryan,

2018-03-09 14:35 GMT-03:00 Bryan O'Donoghue :
> This patch adds hab_auth_img_or_fail() a command line function that
> encapsulates a common usage of authenticate and failover, namely if
> authenticate image fails, then drop to BootROM USB recovery mode.
>
> For secure-boot systems, this type of locked down behavior is important to
> ensure no unsigned images can be run.
>
> It's possible to script this logic but, when done over and over again the
> environment starts get very complex and repetitive, reducing that script
> repetition down to a command line function makes sense.
>
> Signed-off-by: Bryan O'Donoghue 
> Cc: Utkarsh Gupta 
> Cc: Breno Lima 
> Cc: Fabio Estevam 
> ---
>  arch/arm/mach-imx/hab.c | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
> index 0c18b2e..61ccdeb 100644
> --- a/arch/arm/mach-imx/hab.c
> +++ b/arch/arm/mach-imx/hab.c
> @@ -366,6 +366,22 @@ static int do_hab_get_ivt_addr(cmd_tbl_t *cmdtp, int 
> flag, int argc,
> return CMD_RET_SUCCESS;
>  }
>
> +static int do_authenticate_image_or_failover(cmd_tbl_t *cmdtp, int flag,
> +int argc, char * const argv[])
> +{
> +   if (!imx_hab_is_enabled())
> +   goto done;

It would be nice to return CMD_RET_USAGE on this case, or maybe print
something like "Secure boot disabled". If I run in a non HAB enabled
board I get the following output:

=> hab_auth_img_or_fail   
=>

We may also need to add the following here:

if (argc < 4)
   return CMD_RET_USAGE;

If I run this command without any parameter the code is wrongly
executed, and the system goes to USB recovery mode.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] imx: hab: Encase majority of header in __ASSEMBLY__ declaration

[Breno Matheus Lima]

Hi Bryan,

2018-03-09 14:35 GMT-03:00 Bryan O'Donoghue :
> Subsequent patches will want to include hab.h but in doing so include it on
> an assembly compile path causing a range of compile errors. Fix the errors
> pre-emptively by encasing the majority of the declarations in hab.h inside
> an ifdef __ASSEMBLY__ block.
>
> Signed-off-by: Bryan O'Donoghue 
> Cc: Utkarsh Gupta 
> Cc: Breno Lima 
> Cc: Fabio Estevam 

Tested-by: 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] imx: hab: Specify IVT padding size

[Breno Matheus Lima]

Hi Bryan,

2018-03-09 14:35 GMT-03:00 Bryan O'Donoghue :
> This patch adds IVT_PAD_SIZE at 0xC00. The IVT header is padded to this
> size. Defining the size explicitly makes it possible to use the define to
> locate the start/end of an IVT header without using magic numbers in code.
>

As far as I know the 0xC00 pad size is only mandatory in U-Boot/SPL
images, for instance in some U-Boot images the first 0xC00 should
include IVT + Boot data + DCD table + padding to 0xC00.
Are you using the IVT_PAD_SIZE in your current code? Or this macro
will be used in a next series?

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] imx: hab: Add routine to set HAB IVT address

[Breno Matheus Lima]

Hi Bryan,

2018-03-09 14:35 GMT-03:00 Bryan O'Donoghue :
> This patch takes a given address applies a plus or minus offset to locate
> the putative address of an IVT given a non-IVT link location.
>
> It then sets hab_ivt_address to allow for further logic/scripting based on
> the calculated address.
>
> This routine is useful when scripting hab_auth_img calls from boot.scr.
> Subsequent patches will illustrate its utility in a board-port.
>
> Signed-off-by: Bryan O'Donoghue 
> Cc: Utkarsh Gupta 
> Cc: Breno Lima 
> Cc: Fabio Estevam 

Tested-by: 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] imx: hab: Convert DCD non-NULL error to warning

[Breno Matheus Lima]

Hi Bryan,

2018-03-09 10:07 GMT-03:00 Bryan O'Donoghue :
> commit 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
> to calling HAB authenticate function.") makes the DCD field being NULL a
> dependency.
>
> This change though will break loading and executing of existing pre-signed
> binaries on a u-boot update i.e. if this change is deployed on a board you
> will be forced to redo all images on that board to NULL out the DCD.
>
> There is no prior guidance from NXP that the DCD must be NULL similarly
> public guidance on usage of the HAB doesn't call out this NULL dependency
> (see boundary devices link).
>
> Since later SoCs will reject a non-NULL DCD there's no reason to make a
> NULL DCD a requirement, however if there is an actual dependency for later
> SoCs the appropriate fix would be to do SoC version checking.
>
> Earlier SoCs are capable (and happy) to authenticate images with non-NULL
> DCDs, we should not be forcing this change on downstream users -
> particularly if it means those users now must rewrite their build systems
> and/or redeploy signed images in the field.
>
> Fixes: 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
> to calling HAB authenticate function.")

We understand the concern being raised however would prefer to leave
this as an error, and selected users relying on images with DCD
pointers can modify the code accordingly. This does not just apply to
new SoC’s but also applies to existing SoC’s. Users performing such an
update should definitely test the image prior to making an OTA
available. It has never been intended for DCD to be used in any post
boot image and we realize the lack of documentation is a hindsight by
us, and we are currently addressing that with updated guidance.

Best regards,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] imximage: Check the IVT offset in the correct location

[Breno Matheus Lima]

Hi Fabio,

2018-03-08 17:40 GMT-03:00 Fabio Estevam :
> From: Fabio Estevam 
>
> Sometimes imximage throws the following error:
>
>   CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp
>   CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp
>   MKIMAGE u-boot-dtb.imx
> Error: No BOOT_FROM tag in board/freescale/vf610twr/imximage.cfg.cfgtmp
> arch/arm/mach-imx/Makefile:100: recipe for target 'u-boot-dtb.imx' failed
>
> This problem happens because imximage_ivt_offset is being checked
> at un unsafe point, and in some cases it can be checked prior to
> its assignment.
>
> Fix this issue by only checking imximage_ivt_offset after its
> assignment has really occurred.
>
> Introduce a check_ivt_offset() function to help on this task.
>
> Reported-by: Breno Lima 
> Reported-by: Thomas Petazzoni 
> Signed-off-by: Fabio Estevam 

Tested-by: Breno Lima 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 16/17] warp7: defconfig: Enable CMD_SETEXPR

[Breno Matheus Lima]

Hi Bryan,

2018-04-02 19:42 GMT-03:00 Bryan O'Donoghue :
> setexpr allows us to do arithmetic for env variables - something that is
> both useful and required when doing HAB authentication without hard-coding
> HAB load addresses.
>
> Enable setexpr in the secure defconfig - it's not required for the unsecure
> version.

I believe we can reword this sentence since the warp7_secure_defconfig
were removed :)

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 07/17] warp7: Specify CONFIG_OPTEE_LOAD_ADDR

[Breno Matheus Lima]

Hi Bryan,

2018-04-02 19:42 GMT-03:00 Bryan O'Donoghue :
> In order to sign images with the IMX code-signing-tool (CST) we need to
> know the load address of a given image. The best way to derive this load
> address is to make it into a define - so that u-boot.cfg contains the
> address - which we can then parse when generating the IMX CST headers.
>
> This patch makes the OPTEE_LOAD_ADDR available via u-boot.cfg for further
> parsing by external tools.
>
> Signed-off-by: Bryan O'Donoghue 
> Reviewed-by: Ryan Harkin 
> ---
>  configs/warp7_defconfig | 1 +
>  include/configs/warp7.h | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
> index 3dbcd69..c647cd0 100644
> --- a/configs/warp7_defconfig
> +++ b/configs/warp7_defconfig
> @@ -45,3 +45,4 @@ CONFIG_USB_ETH_CDC=y
>  CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
>  CONFIG_OF_LIBFDT=y
>  CONFIG_OPTEE=y
> +CONFIG_OPTEE_LOAD_ADDR=0x8400


I'm seeing the following in my U-Boot environment variables, seems
that CONFIG_OPTEE_LOAD_ADDR it's not being correctly defined:
...
mmcpart=1
optee_addr=CONFIG_OPTEE_LOAD_ADDR
rootpart=2
...

Moving CONFIG_OPTEE_LOAD_ADDR to Kconfig address this issue, can you
please check if the same is happening in your side?

--- a/board/warp7/Kconfig
+++ b/board/warp7/Kconfig
@@ -20,4 +20,10 @@ config SYS_FDT_ADDR
 help
   The address the FDT file should be loaded to.

+config OPTEE_LOAD_ADDR
+hex "OPTEE load address"
+default 0x8400
+help
+  The address the OPTEE binary should be loaded to.
+
 endif

--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1469,6 +1469,7 @@ CONFIG_OMAP_EHCI_PHY2_RESET_GPIO
 CONFIG_OMAP_EHCI_PHY3_RESET_GPIO
 CONFIG_OMAP_USB2PHY2_HOST
 CONFIG_OMAP_USB3PHY1_HOST
+CONFIG_OPTEE_LOAD_ADDR
 CONFIG_ORIGEN

U-Boot environment variables after applying the patch above:
...
mmcpart=1
optee_addr=0x8400
rootpart=2
...

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 06/17] warp7: Print out the OPTEE DRAM region

[Breno Matheus Lima]

Hi Bryan,

2018-04-02 19:42 GMT-03:00 Bryan O'Donoghue :
> Right now a region of 0x30 bytes is allocated at the end of DRAM for
> the purposes of loading an OPTEE firmware inside of it. This patch adds the
> printout of the relevant address ranges.
>
> Signed-off-by: Bryan O'Donoghue 

Just a quick question here, It was your intention to do not add
CONFIG_OPTEE_TZDRAM_SIZE=0x30 in your series? So users can setup
according their requirements?

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 09/17] warp7: defconfig: Enable CONFIG_BOOTM_TEE

[Breno Matheus Lima]

Hi Bryan,

2018-04-02 19:42 GMT-03:00 Bryan O'Donoghue :
> This patch enables CONFIG_BOOTM_TEE. Once enabled its possible to
> chain-load Linux through OPTEE.
>
> Loading kernel to 0x8080
> => run loadimage
>
> Load FDT to 0x8300
> => run loadfdt
>
> Load OPTEE to 0x8400
> => fatload mmc 0:5 0x8400 /lib/firmware/uTee.optee
>
> Then chain-load to the kernel via OPTEE
>
> => bootm 0x8400 - 0x8300
>
>Image Name:
>Image Type:   ARM Trusted Execution Environment Kernel Image (uncompressed)
>Data Size:249844 Bytes = 244 KiB
>Load Address: 9de4
>Entry Point:  9e00
>Verifying Checksum ... OK
>Loading Kernel Image ... OK


I'm seeing the following cache misaligned operation warning in my
environment, did I miss something on my OPTEE build?

=> bootm 0x8400 - 0x8300
## Booting kernel from Legacy Image at 8400 ...
   Image Name:
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:274844 Bytes = 268.4 KiB
   Load Address: 9de4
   Entry Point:  9e00
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8300
   Booting using the fdt blob at 0x8300
   Loading Kernel Image ... OK
CACHE: Misaligned operation at range [9de4, 9e0431a4]
   Using Device Tree in place at 8300, end 830095b6

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] bootm: Align cache flush begin address

[Breno Matheus Lima]

Hi Bryan,

2018-04-15 7:48 GMT-03:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
> commit b4d956f6bc0f ("bootm: Align cache flush end address correctly")
> aligns the end address of the cache flush operation to a cache-line size to
> ensure lower-layers in the code accept the range provided and flush.
>
> A similar action should be taken for the begin address of a cache flush
> operation. The load address may not be aligned to a cache-line boundary, so
> ensure the passed address is aligned.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
> Reported-by: Breno Matheus Lima <brenomath...@gmail.com>
> Suggested-by: Tom Rini <tr...@konsulko.com>
> Cc: Simon Glass <s...@chromium.org>

Thanks for the fix, I'm not seeing the issue anymore.

Tested-by: Breno Lima <breno.l...@nxp.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 00/17] warp7: Enable automated OPTEE/HAB boot flow

[Breno Matheus Lima]

Hi Bryan,

2018-04-13 12:31 GMT-03:00 Bryan O'Donoghue :
> https://git.linaro.org/landing-teams/working/mbl/u-boot.git/log/?h=linaro-mbl%2bbod
>
> v3:
> - Reword commit message of patch #16 - Breno
>
> - This patchset now relies on five in-flight patch-sets the first four of
>   which should be applied first
>
> 1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial
>Already has a Reviewed-by from Fabio
>
> 2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth
>Has a Reviewed-by: from Breno
>
> 3. [PATCH v3 0/2] WaRP7 unify secure and non-secure defconfigs
>
> 4. Pierre-Jean's generic load patches
>
>[U-Boot] [PATCH v3 1/2] warp7: include/configs: use generic fs commands
>in CONFIG_EXTRA_ENV_SETTINGS
>
>[U-Boot] [PATCH v3 2/2] warp7: configs: enable CONFIG_CMD_FS_GENERIC
>
> 5. [PATCH] bootm: Align cache flush begin address
>This last patch can be applied in any order
>
> v2:
> - Ensure warp7_defconfig boots existing yocto with this change plus the
>   automated HAB layer being added here following on from "[PATCH v3 0/2]
>   WaRP7 unify secure and non-secure defconfigs"
>
> - Fix reference to partition #1 versus partition #2 in select uuidpart
>   patch
>
> - Rebase on top of Pierre-Jean Texier generic load patches
>
> - Drop my patch which did the same thing as Pierre-Jean's patch via
>   ${loadcmd}
>
> - Update example boot.scr from v1 to reflect use of generic 'load' command
>
> - This patchset now relies on four in-flight patch-sets which all have the
>   relevant Reviewed-by tags from the board Maintainer Fabio.
>
> 1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial
>Already has a Reviewed-by from Fabio
>
> 2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth
>Has a Reviewed-by: from Breno
>
> 3. [PATCH v3 0/2] WaRP7 unify secure and non-secure defconfigs
>
> 4. Pierre-Jean's generic load patches
>
>[U-Boot] [PATCH v3 1/2] warp7: include/configs: use generic fs commands
>in CONFIG_EXTRA_ENV_SETTINGS
>
>[U-Boot] [PATCH v3 2/2] warp7: configs: enable CONFIG_CMD_FS_GENERIC
>
> v1:
> This series enables an automated HAB verified secure boot which chain-loads
> via OPTEE see `git show 5cf3251..c225e7c` for details.
>
> This set depends on three in-flight patchsets
>
> 1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial
>Already has a Reviewed-by from Fabio
>
> 2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth
>Has a Reviewed-by: from Breno
>
> 3. [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree
>
> I'm trying not to make this cover email too long. So - once this set is
> applied it is possible to boot from the BootROM using HAB to verify
>
> - u-boot
> - boot.scr
> - Kernel
> - DTB
>
> Chainload via OPTEE and boot up to Linux. If there is a HAB failure at any
> stage of the process we force-drop down to the USB HID failover mode, from
> which we can send up a recovery image to unblock.
>
> I've run the WaRP7 default u-boot and this new version on NXP's reference
> yocto image and verified that that yocto image boots with both versions of
> the WaRP7 -> warp7_defconfig and warp7_secure_defconfig.
>
> http://freescale.github.io/#download -> BoardsWaRPboard community - WaRP -
> Wearable Reference PlatformFSL Community BSP 2.3fsl-image-multimediawayland
>
> In addition the modifications targeting warp7_secure_defconfig mean it is
> possible to chain-load via OPTEE using scripted HAB to verify images prior
> to exiting the u-boot domain.
>
> Here is an example of the scripting we are doing which shows further reuse
> of shell functions introduced in previous patches.
>
>  Example secure-boot boot.scr.imx-signed 
>
> # This section is responsbile for loading a signed Linux kernel
> setenv image_signed zImage.imx-signed
> if test ${hab_enabled} -eq 1; then
> setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}
> load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} ${image_signed}
> run warp7_auth_or_fail
> else
> run loadimage;
> fi
>
> # This section is responsbile for loading a signed FDT image
> setenv fdt_file_signed imx7s-warp.dtb.imx-signed
> if test ${hab_enabled} -eq 1; then
> setexpr hab_ivt_addr ${fdt_addr} - ${ivt_offset}
> load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr}
> ${fdt_file_signed}
> run warp7_auth_or_fail
> else
> run loadfdt;
> fi
>
> # Boot from rootfs1 by default
> setenv mmcpart 3
>
> # But if the rootfs2 file exists in partition 2, boot from rootfs2
> ext4size mmc 0:2 rootfs2 && setenv mmcpart 5
>
> # This section is responsbile for loading a signed OPTEE image
> setenv optee_file /lib/firmware/uTee.optee
> setenv optee_file_signed /lib/firmware/uTee.optee.imx-signed
> setenv loadoptee "load mmc ${mmcdev}:${mmcpart} ${optee_addr}
> ${optee_file}"
> if test ${hab_enabled} -eq 1; then
> setexpr hab_ivt_addr ${optee_addr} 

Re: [U-Boot] [PATCH v2 3/3] imx: hab: Provide hab_auth_img_or_fail command

[Breno Matheus Lima]

Hi All,

2018-03-27 19:44 GMT-03:00 Breno Matheus Lima <brenomath...@gmail.com>:
> Hi Bryan,
>
> 2018-03-26 11:11 GMT-03:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
>> This patch adds hab_auth_img_or_fail() a command line function that
>> encapsulates a common usage of authenticate and failover, namely if
>> authenticate image fails, then drop to BootROM USB recovery mode.
>>
>> For secure-boot systems, this type of locked down behavior is important to
>> ensure no unsigned images can be run.
>>
>> It's possible to script this logic but, when done over and over again the
>> environment starts get very complex and repetitive, reducing that script
>> repetition down to a command line function makes sense.
>>
>> Signed-off-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
>> Cc: Utkarsh Gupta <utkarsh.gu...@nxp.com>
>> Cc: Breno Lima <breno.l...@nxp.com>
>> Cc: Fabio Estevam <fabio.este...@nxp.com>
>
> Tested-by: Breno Lima <breno.l...@nxp.com>
>
> Thanks,
> Breno

Sorry, I have comment on the wrong series, my intention was to comment
on V3 series. I will resend the tested-by

Thanks,
Breno Matheus Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] imximage: Encase majority of header in __ASSEMBLY__ declaration

[Breno Matheus Lima]

Hi All,

-Original Message-
From: Bryan O'Donoghue [mailto:bryan.odonog...@linaro.org] 
Sent: segunda-feira, 26 de março de 2018 11:37
To: u-boot@lists.denx.de; Fabio Estevam <fabio.este...@nxp.com>
Cc: rui.si...@linaro.org; sba...@denx.de; Bryan O'Donoghue 
<bryan.odonog...@linaro.org>; Utkarsh Gupta <utkarsh.gu...@nxp.com>; Breno 
Matheus Lima <breno.l...@nxp.com>
Subject: [PATCH v3 1/2] imximage: Encase majority of header in __ASSEMBLY__ 
declaration

Subsequent patches will want to include imageimage.h but in doing so include it 
on an assembly compile path causing a range of compile errors.
Fix the errors pre-emptively by encasing the majority of the declarations in 
imximage.h inside an ifdef __ASSEMBLY__ block.

Signed-off-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
Cc: Utkarsh Gupta <utkarsh.gu...@nxp.com>
Cc: Breno Lima <breno.l...@nxp.com>
Cc: Fabio Estevam <fabio.este...@nxp.com>

Tested-by: Breno Lima <breno.l...@nxp.com>

Thanks,
Breno

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/2] imx: hab: Provide hab_auth_img_or_fail command

[Breno Matheus Lima]

Hi All,

-Original Message-
From: Bryan O'Donoghue [mailto:bryan.odonog...@linaro.org] 
Sent: segunda-feira, 26 de março de 2018 11:37
To: u-boot@lists.denx.de; Fabio Estevam <fabio.este...@nxp.com>
Cc: rui.si...@linaro.org; sba...@denx.de; Bryan O'Donoghue 
<bryan.odonog...@linaro.org>; Utkarsh Gupta <utkarsh.gu...@nxp.com>; Breno 
Matheus Lima <breno.l...@nxp.com>
Subject: [PATCH v3 2/2] imx: hab: Provide hab_auth_img_or_fail command

This patch adds hab_auth_img_or_fail() a command line function that 
encapsulates a common usage of authenticate and failover, namely if 
authenticate image fails, then drop to BootROM USB recovery mode.

For secure-boot systems, this type of locked down behavior is important to 
ensure no unsigned images can be run.

It's possible to script this logic but, when done over and over again the 
environment starts get very complex and repetitive, reducing that script 
repetition down to a command line function makes sense.

Signed-off-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
Cc: Utkarsh Gupta <utkarsh.gu...@nxp.com>
Cc: Breno Lima <breno.l...@nxp.com>
Cc: Fabio Estevam <fabio.este...@nxp.com>

Tested-by: Breno Lima <breno.l...@nxp.com>

Thanks,
Breno
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] imx: hab: Provide hab_auth_img_or_fail command

[Breno Matheus Lima]

Hi Bryan,

2018-03-26 11:11 GMT-03:00 Bryan O'Donoghue :
> This patch adds hab_auth_img_or_fail() a command line function that
> encapsulates a common usage of authenticate and failover, namely if
> authenticate image fails, then drop to BootROM USB recovery mode.
>
> For secure-boot systems, this type of locked down behavior is important to
> ensure no unsigned images can be run.
>
> It's possible to script this logic but, when done over and over again the
> environment starts get very complex and repetitive, reducing that script
> repetition down to a command line function makes sense.
>
> Signed-off-by: Bryan O'Donoghue 
> Cc: Utkarsh Gupta 
> Cc: Breno Lima 
> Cc: Fabio Estevam 

Tested-by: Breno Lima 

Thanks,
Breno
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Makefile: always preserve output for images that can contain HAB Blocks

[Breno Matheus Lima]

Hi Rasmus,

2018-03-02 10:36 GMT-03:00 Rasmus Villemoes :
> The current makefile logic disables creation of the
> SPL.log/u-boot-ivt.img.log etc. files when V=1 is given on the command
> line, the rationale presumably being that the user wants and gets the
> information on the console.
>
> However, from general principles, I don't think a higher V= level
> should affect which build artifacts get generated (and certainly
> shouldn't produce fewer). Concretely, it's also a problem that when
> doing a V=1 build in a terminal, the relevant HAB blocks lines easily
> drown in all the other V=1 output. And build systems such as Yocto by
> default pass V=1, so in that case the information gets hidden away in
> the do_compile log file, making it nigh impossible to create a recipe
> for creating signed U-boot images.
>
> So change the logic so that for V=0, the mkimage output is redirected
> to MKIMAGEOUTPUT (which is also the current behaviour), while for any
> other value of V, we _additionally_ write the information to make's
> stdout, whatever that might be.
>
> Signed-off-by: Rasmus Villemoes 

Tested-by: Breno Lima 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] Makefile: always preserve output for images that can contain HAB Blocks

[Breno Matheus Lima]

Hi All,

2018-03-23 8:08 GMT-03:00 Rasmus Villemoes :
> The current makefile logic disables creation of the
> SPL.log/u-boot-ivt.img.log etc. files when V=1 is given on the command
> line, the rationale presumably being that the user wants and gets the
> information on the console.
>
> However, from general principles, I don't think a higher V= level
> should affect which build artifacts get generated (and certainly
> shouldn't produce fewer). Concretely, it's also a problem that when
> doing a V=1 build in a terminal, the relevant HAB blocks lines easily
> drown in all the other V=1 output.
>
> Moreover, build systems such as Yocto by default pass V=1, so in that
> case the information gets hidden away in the do_compile log file, making
> it nigh impossible to create a recipe for creating signed U-boot images
> - I don't want to disable V=1, because having verbose output in the log
> file is valuable when things go wrong, but OTOH trying to go digging in
> the do_compile log file (and getting exactly the right lines) is not
> pleasant to even think about.
>
> So change the logic so that for V=0, the mkimage output is redirected
> to MKIMAGEOUTPUT (which is also the current behaviour), while for any
> other value of V, we _additionally_ write the information to make's
> stdout, whatever that might be.
>
> Signed-off-by: Rasmus Villemoes 

Tested-by: Breno Lima 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] tools/imximage: use 0x prefix in HAB Blocks line

[Breno Matheus Lima]

Hi Rasmus,

2018-03-23 9:40 GMT-03:00 Fabio Estevam :
> On Fri, Mar 23, 2018 at 8:08 AM, Rasmus Villemoes
>  wrote:
>> The u-boot-ivt.img.log file contains 0x prefixes in the HAB Blocks line,
>> while the SPL.log does not. For consistency, and to make it easier to
>> extract and put into a .csf file for use with NXP's code signing tool,
>> add 0x prefixes here.
>>
>> Signed-off-by: Rasmus Villemoes 
>
> Reviewed-by: Fabio Estevam 

Tested-by: Breno Lima 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Makefile: always preserve output for images that can contain HAB Blocks

[Breno Matheus Lima]

Hi All,

My bad, I have commented in the wrong patch, my intention was to
comment in [PATCH 1/2] Makefile: always preserve output for images
that can contain HAB Blocks.

Thanks,
Breno Lima

2018-03-24 19:06 GMT-03:00 Breno Matheus Lima <brenomath...@gmail.com>:
> Hi Rasmus,
>
> 2018-03-02 10:36 GMT-03:00 Rasmus Villemoes <rasmus.villem...@prevas.dk>:
>> The current makefile logic disables creation of the
>> SPL.log/u-boot-ivt.img.log etc. files when V=1 is given on the command
>> line, the rationale presumably being that the user wants and gets the
>> information on the console.
>>
>> However, from general principles, I don't think a higher V= level
>> should affect which build artifacts get generated (and certainly
>> shouldn't produce fewer). Concretely, it's also a problem that when
>> doing a V=1 build in a terminal, the relevant HAB blocks lines easily
>> drown in all the other V=1 output. And build systems such as Yocto by
>> default pass V=1, so in that case the information gets hidden away in
>> the do_compile log file, making it nigh impossible to create a recipe
>> for creating signed U-boot images.
>>
>> So change the logic so that for V=0, the mkimage output is redirected
>> to MKIMAGEOUTPUT (which is also the current behaviour), while for any
>> other value of V, we _additionally_ write the information to make's
>> stdout, whatever that might be.
>>
>> Signed-off-by: Rasmus Villemoes <rasmus.villem...@prevas.dk>
>
> Tested-by: Breno Lima <breno.l...@nxp.com>
>
> Thanks,
> Breno Lima



-- 
Breno Matheus Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] warp7: defconfig: Fix CAAM on boot with tip-of-tree

[Breno Matheus Lima]

Hi Bryan,

2018-03-31 17:04 GMT-03:00 Bryan O'Donoghue :
> Booting the following image with tip-of-tree we get a CAAM DECO error (and
> subsequent crash due to a kernel bug in 4.1).
>
> http://freescale.github.io/#download -> BoardsWaRPboard community - WaRP -
> Wearable Reference PlatformFSL Community BSP 2.3fsl-image-multimediawayland
>
> Image: fsl-image-multimedia-imx7s-warp-20180323-90.rootfs.sdcard
>
> Error:
> caam 3090.caam: Entropy delay = 3200
> caam 3090.caam: failed to acquire DECO 0
> 
> caam 3090.caam: failed to acquire DECO 0
> caam 3090.caam: Entropy delay = 12400
> caam 3090.caam: failed to acquire DECO 0
> caam 3090.caam: failed to instantiate RNG
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at
> /home/jenkins/workspace/fsl-community-bsp-pyro_xwayland_2/build/tmp/work-shared/imx7s-warp/kernel-source/mm/vmalloc.c:1465
> caam_remove+0x6)
> Trying to vfree() nonexistent vm area (88047000)
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.1.36-4.1-1.0.x-imx-warp7+ga543d1b #1
> Hardware name: Freescale i.MX7 Dual (Device Tree)
> [<80015d54>] (unwind_backtrace) from [<80012688>] (show_stack+0x10/0x14)
> [<80012688>] (show_stack) from [<8076e810>] (dump_stack+0x78/0x8c)
> [<8076e810>] (dump_stack) from [<800346a0>]
> (warn_slowpath_common+0x80/0xb0)
> [<800346a0>] (warn_slowpath_common) from [<80034700>]
> (warn_slowpath_fmt+0x30/0x40)
> [<80034700>] (warn_slowpath_fmt) from [<8054c278>] (caam_remove+0x6c/0x3f4)
> [<8054c278>] (caam_remove) from [<8054ce74>] (caam_probe+0x874/0xfa8)
> [<8054ce74>] (caam_probe) from [<80382a7c>] (platform_drv_probe+0x48/0xa4)
> [<80382a7c>] (platform_drv_probe) from [<80381328>]
> (driver_probe_device+0x174/0x2a8)
> [<80381328>] (driver_probe_device) from [<8038152c>]
> (__driver_attach+0x8c/0x90)
> [<8038152c>] (__driver_attach) from [<8037f9d4>]
> (bus_for_each_dev+0x68/0x9c)
> [<8037f9d4>] (bus_for_each_dev) from [<80380a68>]
> (bus_add_driver+0xf4/0x1e8)
> [<80380a68>] (bus_add_driver) from [<80381b38>] (driver_register+0x78/0xf4)
> [<80381b38>] (driver_register) from [<80009738>]
> (do_one_initcall+0x8c/0x1d0)
> [<80009738>] (do_one_initcall) from [<80a66dac>]
> (kernel_init_freeable+0x140/0x1d0)
> [<80a66dac>] (kernel_init_freeable) from [<8076aa38>]
> (kernel_init+0x8/0xe8)
> [<8076aa38>] (kernel_init) from [<8000f468>] (ret_from_fork+0x14/0x2c)
> ---[ end trace d5f941204ed8cb28 ]---
> caam: probe of 3090.caam failed with error -11
> Unable to handle kernel NULL pointer dereference at virtual address
> 0004
> pgd = 80004000
> [0004] *pgd=
> Internal error: Oops: 805 [#1] PREEMPT SMP ARM
> 
> [<8055cdf8>] (caam_sm_startup) from [<80aa83c8>] (caam_sm_init+0x50/0x58)
> [<80aa83c8>] (caam_sm_init) from [<80009738>] (do_one_initcall+0x8c/0x1d0)
> [<80009738>] (do_one_initcall) from [<80a66dac>]
> (kernel_init_freeable+0x140/0x1d0)
> [<80a66dac>] (kernel_init_freeable) from [<8076aa38>]
> (kernel_init+0x8/0xe8)
> [<8076aa38>] (kernel_init) from [<8000f468>] (ret_from_fork+0x14/0x2c)
> Code: e59d300c e2832010 e5843008 e5834068 (e58a2004)
> ---[ end trace d5f941204ed8cb29 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
>
> Fix: Enable the CAAM correctly by setting CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
> in the upstream defconfig.
>
> Signed-off-by: Bryan O'Donoghue 
> Cc: Fabio Estevam 
> Cc: Breno Lima 
> Reviewed-by: Fabio Estevam 

Tested-by: Breno Lima 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] imx: hab: Specify IVT padding size

[Breno Matheus Lima]

Hi Bryan,

2018-03-17 8:06 GMT-03:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
>
>
> On 15/03/18 16:54, Breno Matheus Lima wrote:
>>
>> Hi Bryan,
>>
>> 2018-03-09 14:35 GMT-03:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
>>>
>>> This patch adds IVT_PAD_SIZE at 0xC00. The IVT header is padded to this
>>> size. Defining the size explicitly makes it possible to use the define to
>>> locate the start/end of an IVT header without using magic numbers in
>>> code.
>>>
>>
>> As far as I know the 0xC00 pad size is only mandatory in U-Boot/SPL
>> images, for instance in some U-Boot images the first 0xC00 should
>> include IVT + Boot data + DCD table + padding to 0xC00.
>> Are you using the IVT_PAD_SIZE in your current code? Or this macro
>> will be used in a next series?
>>
>> Thanks,
>> Breno Lima
>>
>
> All of my images - kernel, u-boot, optee, boot.scr are signed in the same
> first-stage format with this padding present - for simplicity.
>
> Maybe this better named "BOOTROM_IVT_PAD_SIZE" since only the bootrom
> requires it.

As far as I know the IVT has a fixed size of 0x20, and the set of IVT
+ Boot Data + DCD cannot exceed 0xC00.

This value is calculated by the following operation in function
imximage_generate() at tools/imximage.c:
alloc_len = imximage_init_loadsize - imximage_ivt_offset;

Maybe we can rename to something like UBOOT_IMX_HDR_SIZE? We also have
to ensure this definition is being used by U-Boot code.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] doc: imx: fix typo in imximage.txt

[Breno Matheus Lima]

Hi Michael,

Em sex, 2 de nov de 2018 às 19:12, Michael Heimpold  escreveu:
>
> Signed-off-by: Michael Heimpold 

Reviewed-by: Breno Lima 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] doc: imx: fix typos in mxsimage.txt

[Breno Matheus Lima]

Hi Michael,

Em sex, 2 de nov de 2018 às 19:12, Michael Heimpold  escreveu:
>
> This fixes two small typos in mxsimage.txt.
>
> Signed-off-by: Michael Heimpold 

Reviewed-by: Breno Lima 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 7/7] doc: imx: Improve i.MX documentation naming

[Breno Matheus Lima]

There is no need to have README in all i.MX documents name.
Remove README from i.MX docs name and add .txt file extension.

Signed-off-by: Breno Lima 
Reviewed-by: Ye Li 
---
 doc/imx/common/{README.imx25 => imx25.txt}| 0
 doc/imx/common/{README.imx27 => imx27.txt}| 0
 doc/imx/common/{README.imx5 => imx5.txt}  | 0
 doc/imx/common/{README.imx6 => imx6.txt}  | 0
 doc/imx/common/{README.mxs => mxs.txt}| 0
 doc/imx/misc/{README.sdp => sdp.txt}  | 0
 doc/imx/mkimage/{README.imximage => imximage.txt} | 0
 doc/imx/mkimage/{README.mxsimage => mxsimage.txt} | 0
 8 files changed, 0 insertions(+), 0 deletions(-)
 rename doc/imx/common/{README.imx25 => imx25.txt} (100%)
 rename doc/imx/common/{README.imx27 => imx27.txt} (100%)
 rename doc/imx/common/{README.imx5 => imx5.txt} (100%)
 rename doc/imx/common/{README.imx6 => imx6.txt} (100%)
 rename doc/imx/common/{README.mxs => mxs.txt} (100%)
 rename doc/imx/misc/{README.sdp => sdp.txt} (100%)
 rename doc/imx/mkimage/{README.imximage => imximage.txt} (100%)
 rename doc/imx/mkimage/{README.mxsimage => mxsimage.txt} (100%)

diff --git a/doc/imx/common/README.imx25 b/doc/imx/common/imx25.txt
similarity index 100%
rename from doc/imx/common/README.imx25
rename to doc/imx/common/imx25.txt
diff --git a/doc/imx/common/README.imx27 b/doc/imx/common/imx27.txt
similarity index 100%
rename from doc/imx/common/README.imx27
rename to doc/imx/common/imx27.txt
diff --git a/doc/imx/common/README.imx5 b/doc/imx/common/imx5.txt
similarity index 100%
rename from doc/imx/common/README.imx5
rename to doc/imx/common/imx5.txt
diff --git a/doc/imx/common/README.imx6 b/doc/imx/common/imx6.txt
similarity index 100%
rename from doc/imx/common/README.imx6
rename to doc/imx/common/imx6.txt
diff --git a/doc/imx/common/README.mxs b/doc/imx/common/mxs.txt
similarity index 100%
rename from doc/imx/common/README.mxs
rename to doc/imx/common/mxs.txt
diff --git a/doc/imx/misc/README.sdp b/doc/imx/misc/sdp.txt
similarity index 100%
rename from doc/imx/misc/README.sdp
rename to doc/imx/misc/sdp.txt
diff --git a/doc/imx/mkimage/README.imximage b/doc/imx/mkimage/imximage.txt
similarity index 100%
rename from doc/imx/mkimage/README.imximage
rename to doc/imx/mkimage/imximage.txt
diff --git a/doc/imx/mkimage/README.mxsimage b/doc/imx/mkimage/mxsimage.txt
similarity index 100%
rename from doc/imx/mkimage/README.mxsimage
rename to doc/imx/mkimage/mxsimage.txt
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/7] Restructure the i.MX U-Boot documentation

[Breno Matheus Lima]

This patch set is restructuring and cleaning up the current i.MX documentation
included in the U-Boot doc directory.

The current i.MX documentation is in the root directory so we cannot easily
check which one is i.MX related:
http://git.denx.de/?p=u-boot/u-boot-imx.git;a=tree;f=doc;

This series is restructuring the documentation only relevant for i.MX devices
in a new imx directory:

doc
└── imx
├── common
│   ├── imx25.txt
│   ├── imx27.txt
│   ├── imx5.txt
│   ├── imx6.txt
│   └── mxs.txt
├── hab
│   └── habv4
│├── encrypted_boot.txt
│└── secure_boot.txt
├── misc
│   └── sdp.txt
└── mkimage
 ├── imximage.txt
 └── mxsimage.txt

Subsequent patches will include more content in HAB documentation.

Breno Lima (7):
  doc: imx: reorganize i.MX documentation
  doc: imx: Move SPD related info to the appropriate doc
  doc: imx: mkimage: reorganize i.MX mkimage documentation
  doc: imx: Reorganize i.MX SoC common documentation
  doc: imx: hab: Reorganize High Assurance Boot documentation
  doc: imx: misc: Reorganize miscellaneous documentation
  doc: imx: Improve i.MX documentation naming

 doc/{README.imx25 => imx/common/imx25.txt}|  0
 doc/{README.imx27 => imx/common/imx27.txt}|  0
 doc/{README.imx5 => imx/common/imx5.txt}  |  0
 doc/{README.imx6 => imx/common/imx6.txt}  | 25 ---
 doc/{README.mxs => imx/common/mxs.txt}|  0
 doc/imx/hab/habv4/encrypted_boot.txt  | 43 ++
 .../hab/habv4/secure_boot.txt}| 44 ---
 doc/{README.sdp => imx/misc/sdp.txt}  | 22 +-
 .../mkimage/imximage.txt} |  0
 .../mkimage/mxsimage.txt} |  0
 10 files changed, 63 insertions(+), 71 deletions(-)
 rename doc/{README.imx25 => imx/common/imx25.txt} (100%)
 rename doc/{README.imx27 => imx/common/imx27.txt} (100%)
 rename doc/{README.imx5 => imx/common/imx5.txt} (100%)
 rename doc/{README.imx6 => imx/common/imx6.txt} (73%)
 rename doc/{README.mxs => imx/common/mxs.txt} (100%)
 create mode 100644 doc/imx/hab/habv4/encrypted_boot.txt
 rename doc/{README.mxc_hab => imx/hab/habv4/secure_boot.txt} (68%)
 rename doc/{README.sdp => imx/misc/sdp.txt} (82%)
 rename doc/{README.imximage => imx/mkimage/imximage.txt} (100%)
 rename doc/{README.mxsimage => imx/mkimage/mxsimage.txt} (100%)

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/7] doc: imx: Reorganize i.MX SoC common documentation

[Breno Matheus Lima]

The following documents describe device details according to the
i.MX family:

- README.imx25
- README.imx27
- README.imx5
- README.imx6
- README.mxs

Move all device common related document to doc/imx/common for a better
directory structure.

Signed-off-by: Breno Lima 
---
 doc/imx/{ => common}/README.imx25 | 0
 doc/imx/{ => common}/README.imx27 | 0
 doc/imx/{ => common}/README.imx5  | 0
 doc/imx/{ => common}/README.imx6  | 0
 doc/imx/{ => common}/README.mxs   | 0
 5 files changed, 0 insertions(+), 0 deletions(-)
 rename doc/imx/{ => common}/README.imx25 (100%)
 rename doc/imx/{ => common}/README.imx27 (100%)
 rename doc/imx/{ => common}/README.imx5 (100%)
 rename doc/imx/{ => common}/README.imx6 (100%)
 rename doc/imx/{ => common}/README.mxs (100%)

diff --git a/doc/imx/README.imx25 b/doc/imx/common/README.imx25
similarity index 100%
rename from doc/imx/README.imx25
rename to doc/imx/common/README.imx25
diff --git a/doc/imx/README.imx27 b/doc/imx/common/README.imx27
similarity index 100%
rename from doc/imx/README.imx27
rename to doc/imx/common/README.imx27
diff --git a/doc/imx/README.imx5 b/doc/imx/common/README.imx5
similarity index 100%
rename from doc/imx/README.imx5
rename to doc/imx/common/README.imx5
diff --git a/doc/imx/README.imx6 b/doc/imx/common/README.imx6
similarity index 100%
rename from doc/imx/README.imx6
rename to doc/imx/common/README.imx6
diff --git a/doc/imx/README.mxs b/doc/imx/common/README.mxs
similarity index 100%
rename from doc/imx/README.mxs
rename to doc/imx/common/README.mxs
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/7] doc: imx: reorganize i.MX documentation

[Breno Matheus Lima]

Currently the U-Boot doc/ directory contains the following files
that are only relevant for i.MX devices:

- doc/README.imx25
- doc/README.imx27
- doc/README.imx5
- doc/README.imx6
- doc/README.imximage
- doc/README.mxc_hab
- doc/README.mxs
- doc/README.mxsimage
- doc/README.sdp

Move all content to a common i.MX folder for a better documentation
structure.

Signed-off-by: Breno Lima 
---
 doc/{ => imx}/README.imx25| 0
 doc/{ => imx}/README.imx27| 0
 doc/{ => imx}/README.imx5 | 0
 doc/{ => imx}/README.imx6 | 0
 doc/{ => imx}/README.imximage | 0
 doc/{ => imx}/README.mxc_hab  | 0
 doc/{ => imx}/README.mxs  | 0
 doc/{ => imx}/README.mxsimage | 0
 doc/{ => imx}/README.sdp  | 0
 9 files changed, 0 insertions(+), 0 deletions(-)
 rename doc/{ => imx}/README.imx25 (100%)
 rename doc/{ => imx}/README.imx27 (100%)
 rename doc/{ => imx}/README.imx5 (100%)
 rename doc/{ => imx}/README.imx6 (100%)
 rename doc/{ => imx}/README.imximage (100%)
 rename doc/{ => imx}/README.mxc_hab (100%)
 rename doc/{ => imx}/README.mxs (100%)
 rename doc/{ => imx}/README.mxsimage (100%)
 rename doc/{ => imx}/README.sdp (100%)

diff --git a/doc/README.imx25 b/doc/imx/README.imx25
similarity index 100%
rename from doc/README.imx25
rename to doc/imx/README.imx25
diff --git a/doc/README.imx27 b/doc/imx/README.imx27
similarity index 100%
rename from doc/README.imx27
rename to doc/imx/README.imx27
diff --git a/doc/README.imx5 b/doc/imx/README.imx5
similarity index 100%
rename from doc/README.imx5
rename to doc/imx/README.imx5
diff --git a/doc/README.imx6 b/doc/imx/README.imx6
similarity index 100%
rename from doc/README.imx6
rename to doc/imx/README.imx6
diff --git a/doc/README.imximage b/doc/imx/README.imximage
similarity index 100%
rename from doc/README.imximage
rename to doc/imx/README.imximage
diff --git a/doc/README.mxc_hab b/doc/imx/README.mxc_hab
similarity index 100%
rename from doc/README.mxc_hab
rename to doc/imx/README.mxc_hab
diff --git a/doc/README.mxs b/doc/imx/README.mxs
similarity index 100%
rename from doc/README.mxs
rename to doc/imx/README.mxs
diff --git a/doc/README.mxsimage b/doc/imx/README.mxsimage
similarity index 100%
rename from doc/README.mxsimage
rename to doc/imx/README.mxsimage
diff --git a/doc/README.sdp b/doc/imx/README.sdp
similarity index 100%
rename from doc/README.sdp
rename to doc/imx/README.sdp
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/7] doc: imx: mkimage: reorganize i.MX mkimage documentation

[Breno Matheus Lima]

The following documents describe the image type used by the mkimage
tool to generate U-Boot images for i.MX devices.

- README.imximage
- README.mxsimage

Move all mkimage related document to doc/imx/mkimage for a better
directory structure.

Signed-off-by: Breno Lima 
---
 doc/imx/{ => mkimage}/README.imximage | 0
 doc/imx/{ => mkimage}/README.mxsimage | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename doc/imx/{ => mkimage}/README.imximage (100%)
 rename doc/imx/{ => mkimage}/README.mxsimage (100%)

diff --git a/doc/imx/README.imximage b/doc/imx/mkimage/README.imximage
similarity index 100%
rename from doc/imx/README.imximage
rename to doc/imx/mkimage/README.imximage
diff --git a/doc/imx/README.mxsimage b/doc/imx/mkimage/README.mxsimage
similarity index 100%
rename from doc/imx/README.mxsimage
rename to doc/imx/mkimage/README.mxsimage
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 5/7] doc: imx: hab: Reorganize High Assurance Boot documentation

[Breno Matheus Lima]

The current High Assurance Boot document README.mxc_hab
include details for the following features in a single file:

- HAB Secure Boot
- HAB Encrypted Boot

Split HAB documentation in a specific directory for a cleaner
documentation structure, subsequent patches will include more
content in HAB documentation.

Signed-off-by: Breno Lima 
---
 doc/imx/hab/habv4/encrypted_boot.txt  | 43 ++
 .../habv4/secure_boot.txt}| 44 ---
 2 files changed, 43 insertions(+), 44 deletions(-)
 create mode 100644 doc/imx/hab/habv4/encrypted_boot.txt
 rename doc/imx/{README.mxc_hab => hab/habv4/secure_boot.txt} (68%)

diff --git a/doc/imx/hab/habv4/encrypted_boot.txt 
b/doc/imx/hab/habv4/encrypted_boot.txt
new file mode 100644
index 00..c59d204d38
--- /dev/null
+++ b/doc/imx/hab/habv4/encrypted_boot.txt
@@ -0,0 +1,43 @@
+1. Setup U-Boot Image for Encrypted Boot
+
+An authenticated U-Boot image is used as starting point for
+Encrypted Boot. The image is encrypted by i.MX Code Signing
+Tool (CST). The CST replaces only the image data of
+u-boot-dtb.imx with the encrypted data. The Initial Vector Table,
+DCD, and Boot data, remains in plaintext.
+
+The image data is encrypted with a Encryption Key (DEK).
+Therefore, this key is needed to decrypt the data during the
+booting process. The DEK is protected by wrapping it in a Blob,
+which needs to be appended to the U-Boot image and specified in
+the CSF file.
+
+The DEK blob is generated by an authenticated U-Boot image with
+the dek_blob cmd enabled. The image used for DEK blob generation
+needs to have the following configurations enabled in Kconfig:
+
+CONFIG_SECURE_BOOT=y
+CONFIG_CMD_DEKBLOB=y
+
+Note: The encrypted boot feature is only supported by HABv4 or
+greater.
+
+The dek_blob command then can be used to generate the DEK blob of
+a DEK previously loaded in memory. The command is used as follows:
+
+dek_blob   
+example: dek_blob 0x1080 0x10801000 192
+
+The resulting DEK blob then is used to construct the encrypted
+U-Boot image. Note that the blob needs to be transferred back
+to the host.Then the following commands are used to construct
+the final image.
+
+cat u-boot-dtb.imx csf-u-boot.bin > u-boot-signed.imx
+objcopy -I binary -O binary --pad-to  --gap-fill=0x00 \
+u-boot-signed.imx u-boot-signed-pad.bin
+cat u-boot-signed-pad.imx DEK_blob.bin > u-boot-encrypted.imx
+
+NOTE: u-boot-signed.bin needs to be padded to the value
+equivalent to the address in which the DEK blob is specified
+in the CSF.
diff --git a/doc/imx/README.mxc_hab b/doc/imx/hab/habv4/secure_boot.txt
similarity index 68%
rename from doc/imx/README.mxc_hab
rename to doc/imx/hab/habv4/secure_boot.txt
index a40ebf3e84..ae68dc8040 100644
--- a/doc/imx/README.mxc_hab
+++ b/doc/imx/hab/habv4/secure_boot.txt
@@ -98,47 +98,3 @@ cat u-boot-ivt.img csf-u-boot.bin > u-boot-signed.img
 
 These two signed binaries can be used on an i.MX in closed
 configuration when the according SRK Table Hash has been flashed.
-
-4. Setup U-Boot Image for Encrypted Boot
-
-An authenticated U-Boot image is used as starting point for
-Encrypted Boot. The image is encrypted by i.MX Code Signing
-Tool (CST). The CST replaces only the image data of
-u-boot-dtb.imx with the encrypted data. The Initial Vector Table,
-DCD, and Boot data, remains in plaintext.
-
-The image data is encrypted with a Encryption Key (DEK).
-Therefore, this key is needed to decrypt the data during the
-booting process. The DEK is protected by wrapping it in a Blob,
-which needs to be appended to the U-Boot image and specified in
-the CSF file.
-
-The DEK blob is generated by an authenticated U-Boot image with
-the dek_blob cmd enabled. The image used for DEK blob generation
-needs to have the following configurations enabled in Kconfig:
-
-CONFIG_SECURE_BOOT=y
-CONFIG_CMD_DEKBLOB=y
-
-Note: The encrypted boot feature is only supported by HABv4 or
-greater.
-
-The dek_blob command then can be used to generate the DEK blob of
-a DEK previously loaded in memory. The command is used as follows:
-
-dek_blob   
-example: dek_blob 0x1080 0x10801000 192
-
-The resulting DEK blob then is used to construct the encrypted
-U-Boot image. Note that the blob needs to be transferred back
-to the host.Then the following commands are used to construct
-the final image.
-
-cat u-boot-dtb.imx csf-u-boot.bin > u-boot-signed.imx
-objcopy -I binary -O binary --pad-to  --gap-fill=0x00 \
-u-boot-signed.imx u-boot-signed-pad.bin
-cat u-boot-signed-pad.imx DEK_blob.bin > u-boot-encrypted.imx
-
-NOTE: u-boot-signed.bin needs to be padded to the value
-equivalent to the address in which the DEK blob is specified
-in the CSF.
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/7] doc: imx: Move SPD related info to the appropriate doc

[Breno Matheus Lima]

Currently the Serial Download Protocol tools and procedure are
documented in two places:

- doc/imx/README.sdp
- doc/imx/README.imx6

It is better to consolidate all SDP related information into
README.sdp file, so move the content from README.imx6 to
README.sdp.

Signed-off-by: Breno Lima 
---
 doc/imx/README.imx6 | 25 -
 doc/imx/README.sdp  | 22 --
 2 files changed, 20 insertions(+), 27 deletions(-)

diff --git a/doc/imx/README.imx6 b/doc/imx/README.imx6
index b0644f8491..eab88353f6 100644
--- a/doc/imx/README.imx6
+++ b/doc/imx/README.imx6
@@ -88,28 +88,3 @@ Reading bank 4:
 
 Word 0x0002: 9f027772 0004
 
-2. Using imx_usb_loader for first install with SPL
---
-
-imx_usb_loader is a very nice tool by Boundary Devices that
-allow to install U-Boot without a JTAG debugger, using
-the USB boot mode as described in the manual. It is
-a replacement for Freescale's MFGTOOLS.
-
-The sources can be found here:
-
-   https://github.com/boundarydevices/imx_usb_loader.git
-
-Booting in USB mode, the i.MX6 announces itself to the Linux Host as:
-
-Bus 001 Device 111: ID 15a2:0061 Freescale Semiconductor, Inc.
-
-imx_usb_loader is able to download a single file (u-boot.imx)
-to the board. For boards without SPL support, it is enough to
-issue the command:
-
-   sudo ../imx_usb_loader/imx_usb -v u-boot.imx
-
-In order to load SPL and u-boot.img via imx_usb_loader tool,
-please refer to doc/README.sdp.
-
diff --git a/doc/imx/README.sdp b/doc/imx/README.sdp
index 178ea688a7..6ea6e41395 100644
--- a/doc/imx/README.sdp
+++ b/doc/imx/README.sdp
@@ -16,14 +16,19 @@ protocols allow to access a USB device without OS specific 
drivers. The
 U-Boot implementation has primarly been tested using the open source
 imx_loader utility (https://github.com/boundarydevices/imx_usb_loader).
 
+imx_usb_loader is a very nice tool by Boundary Devices that allow to
+install U-Boot without a JTAG debugger, using the USB boot mode as
+described in the manual. It is a replacement for Freescale's
+MFGTOOLS.
+
 The host side utilities are typically capable to interpret the i.MX
 specific image header (see doc/README.imximage). There are extensions
 for imx_loader's imx_usb utility which allow to interpret the U-Boot
 specific legacy image format (see mkimage(1)). Also the U-Boot side
 support beside the i.MX specific header the U-Boot legacy header.
 
-Usage
--
+1. Using imx_usb_loader for first install with SPL
+--
 
 This implementation can be started in U-Boot using the sdp command
 (CONFIG_CMD_USB_SDP) or in SPL if Serial Downloader boot mode has been
@@ -98,3 +103,16 @@ With that SPL and U-Boot can be downloaded with a single 
invocation
 of imx_usb without arguments:
 
   # imx_usb
+
+2. Using imx_usb_loader non-SPL images
+---
+
+Booting in USB mode, the i.MX6 announces itself to the Linux Host as:
+
+Bus 001 Device 111: ID 15a2:0061 Freescale Semiconductor, Inc.
+
+imx_usb_loader is able to download a single file (u-boot.imx)
+to the board. For boards without SPL support, it is enough to
+issue the command:
+
+   sudo ../imx_usb_loader/imx_usb -v u-boot.imx
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 6/7] doc: imx: misc: Reorganize miscellaneous documentation

[Breno Matheus Lima]

The Serial Download Protocol feature is availible in various
i.MX SoCs.

Move README.sdp document to imx/misc directory.

Signed-off-by: Breno Lima 
---
 doc/imx/{ => misc}/README.sdp | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename doc/imx/{ => misc}/README.sdp (100%)

diff --git a/doc/imx/README.sdp b/doc/imx/misc/README.sdp
similarity index 100%
rename from doc/imx/README.sdp
rename to doc/imx/misc/README.sdp
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Problems to boot i.MX8QXP EVK board

[Breno Matheus Lima]

Hi Peng,

I'm not being able to boot U-Boot v2019.01 on my i.MX8QXP B0 MEK board
by following README file (board/freescale/imx8qxp_mek/README).

After reverting commit f7e475db4011("tools: imx8image: set dcd_skip to
true") everything seems to be working fine.

Do you happen to know if the procedure in README file should be enough
for v2019.01?

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Problems to boot i.MX8QXP EVK board

[Breno Matheus Lima]

Hi Peng,

Em qua, 16 de jan de 2019 às 23:33, Peng Fan  escreveu:
>
> Hi Breno,
>
> > -Original Message-
> > From: Breno Matheus Lima [mailto:brenomath...@gmail.com]
> > Sent: 2019年1月17日 9:04
> > To: Peng Fan ; Breno Matheus Lima
> > 
> > Cc: Fabio Estevam ; Fabio Estevam
> > ; U-Boot-Denx 
> > Subject: Problems to boot i.MX8QXP EVK board
> >
> > Hi Peng,
> >
> > I'm not being able to boot U-Boot v2019.01 on my i.MX8QXP B0 MEK board
> > by following README file (board/freescale/imx8qxp_mek/README).
> >
> > After reverting commit f7e475db4011("tools: imx8image: set dcd_skip to
> > true") everything seems to be working fine.
>
> Are you using A0 or B0 chip? A0 chip is no being supported anymore.
>

I'm using i.MX8QXP B0:

U-Boot 2019.01-1-gc94b5e99a6 (Jan 16 2019 - 22:52:33 -0200)

CPU:   NXP i.MX8QXP RevB A35 at 147228 MHz

Model: Freescale i.MX8QXP MEK
Board: iMX8QXP MEK
Build: SCFW 3301c1a9
Boot:  SD1
DRAM:  3 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial@5a06
Out:   serial@5a06
Err:   serial@5a06
Net:   eth-1: ethernet@5b04
Hit any key to stop autoboot:  0
=>

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Problems to boot i.MX8QXP EVK board

[Breno Matheus Lima]

Hi Peng,
Em qua, 16 de jan de 2019 às 23:48, Peng Fan  escreveu:
>
>
>
> > -Original Message-
> > From: Breno Matheus Lima [mailto:brenomath...@gmail.com]
> > Sent: 2019年1月17日 9:42
> > To: Peng Fan 
> > Cc: Breno Matheus Lima ; Fabio Estevam
> > ; Fabio Estevam ;
> > U-Boot-Denx 
> > Subject: Re: Problems to boot i.MX8QXP EVK board
> >
> > Hi Peng,
> >
> > Em qua, 16 de jan de 2019 às 23:33, Peng Fan 
> > escreveu:
> > >
> > > Hi Breno,
> > >
> > > > -Original Message-----
> > > > From: Breno Matheus Lima [mailto:brenomath...@gmail.com]
> > > > Sent: 2019年1月17日 9:04
> > > > To: Peng Fan ; Breno Matheus Lima
> > > > 
> > > > Cc: Fabio Estevam ; Fabio Estevam
> > > > ; U-Boot-Denx 
> > > > Subject: Problems to boot i.MX8QXP EVK board
> > > >
> > > > Hi Peng,
> > > >
> > > > I'm not being able to boot U-Boot v2019.01 on my i.MX8QXP B0 MEK
> > > > board by following README file
> > (board/freescale/imx8qxp_mek/README).
> > > >
> > > > After reverting commit f7e475db4011("tools: imx8image: set dcd_skip
> > > > to
> > > > true") everything seems to be working fine.
> > >
> > > Are you using A0 or B0 chip? A0 chip is no being supported anymore.
> > >
> >
> > I'm using i.MX8QXP B0:
>
> Could you give a try using 4.14.78 GA release scfw/seco/atf + upstream uboot?
>
> There might be some change in scfw.

Hi Peng,

I'm using the following versions:

- U-Boot upstream v2019.01
- ATF from NXP codeaurora (rel_imx_4.14.78_1.0.0_ga)
- SCFW binary from imx-sc-firmware-1.1 package
- SECO FW from firmware-imx-8.0 package

The same issue still happening, I can only boot my board after
reverting commit f7e475db4011("tools: imx8image: set dcd_skip to
true").

As you can see in log below, SCFW top is 65afe5f6:

U-Boot 2019.01-1-g2df3ad4767 (Jan 17 2019 - 08:15:39 -0200)

CPU:   NXP i.MX8QXP RevB A35 at 147228 MHz

Model: Freescale i.MX8QXP MEK
Board: iMX8QXP MEK
Build: SCFW 65afe5f6
Boot:  SD1
DRAM:  3 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial@5a06
Out:   serial@5a06
Err:   serial@5a06
Net:   eth-1: ethernet@5b04
Hit any key to stop autoboot:  0
=>

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "tools: imx8image: set dcd_skip to true"

[Breno Matheus Lima]

Hi Fabio,

Em sex, 18 de jan de 2019 às 11:00, Fabio Estevam  escreveu:
>
> This reverts commit f7e475db4011d18b4ae974154eb022c3af6a4d16.
>
> This commit breaks the boot on imx8qxp evk and it should only
> be re-applied after imx8qxp evk is converted to SPL.
>
> Revert it for now, so that imx8qxp evk can be functional.
>
> Reported-by: Breno Lima 
> Signed-off-by: Fabio Estevam 

Tested-by: Breno Lima 

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/6] doc: imx: habv4: Add HABv4 introduction

[Breno Matheus Lima]

The HABv4 is supported in i.MX50, i.MX53, i.MX6, i.MX7,
series and i.MX 8M, i.MX8MM devices.

Add an introductory document containing the following topics:

- HABv4 Introduction
- HABv4 Secure Boot
- HABv4 Encrypted Boot
- HAB PKI tree generation
- HAB Fast Authentication PKI tree generation
- SRK Table and SRK Hash generation

Reviewed-by: Ye Li 
Reviewed-by: Utkarsh Gupta 
Signed-off-by: Breno Lima 
---
 doc/imx/habv4/introduction_habv4.txt | 262 +++
 1 file changed, 262 insertions(+)
 create mode 100644 doc/imx/habv4/introduction_habv4.txt

diff --git a/doc/imx/habv4/introduction_habv4.txt 
b/doc/imx/habv4/introduction_habv4.txt
new file mode 100644
index 00..25711bbe95
--- /dev/null
+++ b/doc/imx/habv4/introduction_habv4.txt
@@ -0,0 +1,262 @@
+  +===+
+  + i.MX Secure and Encrypted Boot using HABv4+
+  +===+
+
+1. Introduction
+
+
+The i.MX family of applications processors provides the High Assurance Boot
+(HAB) feature in the on-chip ROM. The ROM is responsible for loading the
+initial program image (U-Boot) from the boot media and HAB enables the ROM
+to authenticate and/or decrypt the program image by using cryptography
+operations.
+
+This feature is supported in i.MX 50, i.MX 53, i.MX 6, i.MX 7 series and
+ i.MX 8M, i.MX 8MM devices.
+
+Step-by-step guides are available under doc/imx/habv4/guides/ directory,
+users familiar with HAB and CST PKI tree generation should refer to these
+documents instead.
+
+1.1 The HABv4 Secure Boot Architecture
+---
+
+The HABv4 secure boot feature uses digital signatures to prevent unauthorized
+software execution during the device boot sequence. In case a malware takes
+control of the boot sequence, sensitive data, services and network can be
+impacted.
+
+The HAB authentication is based on public key cryptography using the RSA
+algorithm in which image data is signed offline using a series of private
+keys. The resulting signed image data is then verified on the i.MX processor
+using the corresponding public keys. The public keys are included in the CSF
+binary and the SRK Hash is programmed in the SoC fuses for establishing the
+root of trust.
+
+The diagram below illustrate the secure boot process overview:
+
+  Host PC + CST i.MX + HAB
+  +--+ +--+
+ ---> |  U-Boot  | | Compare  |
+ |+--+ +--+
+ |  | ^^
+ |  v Reference  /  \  Generated
+ |+--+  Hash/\   Hash
+ ||   Hash   |  Private/  \
+ |+--+Key /\
+ |  |  |+--+  +--+
+ |  v  ||  Verify  |  |   Hash   |
+ |+--+ |+--+  +--+
+ ||   Sign   |  <---  SRK^^
+ |+--+HASH\  /
+ |  |  |  CSF  \/   U-Boot
+ |  v  v\  /
+ |+--++--++--+
+ ||  U-Boot  ||  ||  U-Boot  |
+ ---> | +| -> |   i.MX   | -> | +|
+  |CSF   ||  ||CSF   |
+  +--++--++--+
+
+The U-Boot image to be programmed into the boot media needs to be properly
+constructed i.e. it must contain a proper Command Sequence File (CSF).
+
+The CSF is a binary data structure interpreted by the HAB to guide
+authentication process, this is generated by the Code Signing Tool[1].
+The CSF structure contains the commands, SRK table, signatures and
+certificates.
+
+Details about the Secure Boot and Code Signing Tool (CST) can be found in
+the application note AN4581[2] and in the secure boot guides.
+
+1.2 The HABv4 Encrypted Boot Architecture
+--
+
+The HAB Encrypted Boot feature available in CAAM supported devices adds an
+extra security operation to the bootloading sequence. It uses cryptographic
+techniques (AES-CCM) to obscure the U-Boot data, so it cannot be seen or used
+by unauthorized users. This mechanism protects the U-Boot code residing on
+flash or external memory and also ensures that the final image is unique
+per device.
+
+The process can be divided into two protection mechanisms. The first mechanism
+is the bootloader code encryption which provides data confidentiality and the
+second mechanism is 

[U-Boot] [PATCH 3/6] doc: imx: habv4: Add Secure Boot guide for i.MX6 and i.MX7 non-SPL targets

[Breno Matheus Lima]

Add HABv4 documentation for non-SPL targets covering the
following topics:

- How to sign an securely boot an u-boot-dtb.imx image.
- How to extend the root of trust for additional boot images.
- Add 3 CSF examples.
- Add IVT generation script example.

Reviewed-by: Ye Li 
Reviewed-by: Utkarsh Gupta 
Signed-off-by: Breno Lima 
---
 .../csf_additional_images.txt |  34 ++
 .../habv4/csf_examples/mx6_mx7/csf_uboot.txt  |  32 ++
 .../mx6_mx7/csf_uboot_fast_authentication.txt |  23 +
 doc/imx/habv4/guides/mx6_mx7_secure_boot.txt  | 402 ++
 doc/imx/habv4/script_examples/genIVT.pl   |  12 +
 5 files changed, 503 insertions(+)
 create mode 100644 
doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt
 create mode 100644 doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt
 create mode 100644 
doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt
 create mode 100644 doc/imx/habv4/guides/mx6_mx7_secure_boot.txt
 create mode 100644 doc/imx/habv4/script_examples/genIVT.pl

diff --git 
a/doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt 
b/doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt
new file mode 100644
index 00..bbe489714b
--- /dev/null
+++ b/doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt
@@ -0,0 +1,34 @@
+[Header]
+Version = 4.2
+Hash Algorithm = sha256
+Engine Configuration = 0
+Certificate Format = X509
+Signature Format = CMS
+Engine = CAAM
+
+[Install SRK]
+# Index of the key location in the SRK table to be installed
+File = "../crts/SRK_1_2_3_4_table.bin"
+Source index = 0
+
+[Install CSFK]
+# Key used to authenticate the CSF data
+File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate CSF]
+
+[Install Key]
+# Key slot index used to authenticate the key to be installed
+Verification index = 0
+# Target key slot in HAB key store where key will be installed
+Target Index = 2
+# Key to install
+File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate Data]
+# Key slot index used to authenticate the image data
+Verification index = 2
+# Authenticate Start Address, Offset, Length and file
+Blocks = 0x8080 0x 0x80EEA020 "zImage", \
+0x8380 0x 0x8380B927 "imx7d-sdb.dtb", \
+0x8400 0x 0x840425B8 "uTee-7dsdb"
diff --git a/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt 
b/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt
new file mode 100644
index 00..39986243e4
--- /dev/null
+++ b/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt
@@ -0,0 +1,32 @@
+[Header]
+Version = 4.2
+Hash Algorithm = sha256
+Engine Configuration = 0
+Certificate Format = X509
+Signature Format = CMS
+Engine = CAAM
+
+[Install SRK]
+# Index of the key location in the SRK table to be installed
+File = "../crts/SRK_1_2_3_4_table.bin"
+Source index = 0
+
+[Install CSFK]
+# Key used to authenticate the CSF data
+File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate CSF]
+
+[Install Key]
+# Key slot index used to authenticate the key to be installed
+Verification index = 0
+# Target key slot in HAB key store where key will be installed
+Target Index = 2
+# Key to install
+File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate Data]
+# Key slot index used to authenticate the image data
+Verification index = 2
+# Authenticate Start Address, Offset, Length and file
+Blocks =  0x877ff400 0x 0x0009ec00 "u-boot-dtb.imx"
diff --git 
a/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt 
b/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt
new file mode 100644
index 00..cdb34bcf74
--- /dev/null
+++ b/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt
@@ -0,0 +1,23 @@
+[Header]
+Version = 4.2
+Hash Algorithm = sha256
+Engine Configuration = 0
+Certificate Format = X509
+Signature Format = CMS
+Engine = CAAM
+
+[Install SRK]
+# Index of the key location in the SRK table to be installed
+File = "../crts/SRK_1_2_3_4_table.bin"
+Source index = 0
+
+[Install NOCAK]
+File = "../crts/SRK1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate CSF]
+
+[Authenticate Data]
+# Key slot index 0 used to authenticate the image data
+Verification index = 0
+# Authenticate Start Address, Offset, Length and file
+Blocks =  0x877ff400 0x 0x0009ec00 "u-boot-dtb.imx"
diff --git a/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt 
b/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt
new file mode 100644
index 00..98e18beecd
--- /dev/null
+++ b/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt
@@ -0,0 +1,402 @@
+ +===+
+ +   i.MX6, i.MX7 U-Boot Secure 

[U-Boot] [PATCH 4/6] doc: imx: habv4: Add Secure Boot guide for i.MX6 and i.MX7 SPL targets

[Breno Matheus Lima]

The current U-Boot implementation includes SPL targets for
some NXP development boards:

- mx6sabreauto_defconfig
- mx6sabresd_defconfig
- mx6ul_14x14_evk_defconfig
- mx6ul_9x9_evk_defconfig

Add additional steps needed to completly secure the
bootloader image.

Signed-off-by: Breno Lima 
---
 .../habv4/guides/mx6_mx7_spl_secure_boot.txt  | 181 ++
 1 file changed, 181 insertions(+)
 create mode 100644 doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt

diff --git a/doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt 
b/doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt
new file mode 100644
index 00..0d7931aac0
--- /dev/null
+++ b/doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt
@@ -0,0 +1,181 @@
+  +===+
+  +  i.MX6, i.MX7 U-Boot HABv4 Secure Boot guide for SPL targets  +
+  +===+
+
+1. HABv4 secure boot process
+-
+
+This document is an addendum of mx6_mx7_secure_boot.txt guide describing a
+step-by-step procedure on how to sign and securely boot an U-Boot image for
+SPL targets.
+
+Details about HAB can be found in the application note AN4581[1] and in the
+introduction_habv4.txt document.
+
+1.1 Building a SPL target supporting secure boot
+-
+
+The U-Boot provides Second Program Loader (SPL) support which generates two
+final images, SPL and U-Boot proper. The HABv4 can be used to authenticate
+both binaries.
+
+Out of reset the ROM code authenticates the SPL which is responsible for
+initializing essential features such as DDR, UART, PMIC and clock
+enablement. Once the DDR is available, the SPL code loads the U-Boot proper
+image to its specific execution address and call the HAB APIs to extend the
+root of trust.
+
+The U-Boot provides support to secure boot configuration and also provide
+access to the HAB APIs exposed by the ROM vector table, the support is
+enabled by selecting the CONFIG_SECURE_BOOT option.
+
+When built with this configuration the U-Boot correctly pads the final SPL
+image by aligning to the next 0xC00 address, so the CSF signature data
+generated by CST can be concatenated to the image.
+
+The U-Boot also append an Image Vector Table (IVT) in the final U-Boot proper
+binary (u-boot-ivt.img) so it can be used by HAB API in a post ROM stage.
+
+The diagram below illustrate a signed SPL image layout:
+
+--- +-+ <-- *start
+^   |  Image Vector Table |
+|   +-+ <-- *boot_data
+|   |  Boot Data  |
+|   +-+
+ Signed |   |   Padding   |
+  Data  |   +-+ <-- *entry
+|   | |
+|   |SPL  |
+|   | |
+|   +-+
+v   |   Padding   |
+--- +-+ <-- *csf
+| |
+| Command Sequence File (CSF) |
+| |
++-+
+|  Padding (optional) |
++-+
+
+The diagram below illustrate a signed u-boot-ivt.img image layout:
+
+--- +-+ <-- *load_address
+^   | |
+|   | |
+|   | u-boot.img  |
+ Signed |   | |
+  Data  |   | |
+|   +-+
+|   |Padding Next Boundary|
+|   +-+ <-- *ivt
+v   | Image Vector Table  |
+--- +-+ <-- *csf
+| |
+| Command Sequence File (CSF) |
+| |
++-+
+| Padding (optional)  |
++-+
+
+1.2 Enabling the secure boot support
+-
+
+The first step is to generate an U-Boot image supporting the HAB features
+mentioned above, this can be achieved by adding CONFIG_SECURE_BOOT to the
+build configuration:
+
+- Defconfig:
+
+  CONFIG_SECURE_BOOT=y
+
+- Kconfig:
+
+  ARM architecture -> Support i.MX HAB features
+
+1.3 Creating the CSF description file
+--
+

[U-Boot] [PATCH 0/6] doc: imx: habv4: Improve iMX6 and iMX7 secure boot documentation

[Breno Matheus Lima]

Hi All,

This series is improving the current HABv4 U-Boot documentation
for iMX6 and iMX7 families devices.

The patch set is adding a complete step-by-step procedure on how to
securely boot an U-Boot image using HABv4:

 habv4
 ├── csf_examples
 │   ├── additional_images
 │   │   └── csf_additional_images.txt
 │   └── mx6_mx7
 │   ├── csf_uboot_fast_authentication.txt
 │   └── csf_uboot.txt
 ├── guides
 │   ├── encrypted_boot.txt
 │   ├── mx6_mx7_secure_boot.txt
 │   └── mx6_mx7_spl_secure_boot.txt
 ├── introduction_habv4.txt
 └── script_examples
 └── genIVT.pl

Patches 0001, 0005 and 0006 are cleaning up the HABv4 documentation
direcotry structure.

Patches 0002, 0003 and 0004 are adding new content under HABv4 directory.

Depending on the web browser the plain text diagrams are not correctly
displayed, the documentation can be also seen in the following links:

0002 - HABv4 introduction:
https://pastebin.com/SLU52WwP

0003 - Secure Boot guide for i.MX6 and i.MX7 non-SPL targets:
https://pastebin.com/87zVfFpJ

0004 - Secure Boot guide for i.MX6 and i.MX7 SPL targets:
https://pastebin.com/DPm42ihr

Subsequent patches will include more content for encrypted boot
and also cover i.MX8M family.

Breno Lima (6):
  doc: imx: habv4: Remove extra hab directory for a cleaner
documentation structure
  doc: imx: habv4: Add HABv4 introduction
  doc: imx: habv4: Add Secure Boot guide for i.MX6 and i.MX7 non-SPL
targets
  doc: imx: habv4: Add Secure Boot guide for i.MX6 and i.MX7 SPL targets
  doc: imx: habv4: Move encrypted boot guide
  doc: imx: habv4: Remove secure_boot.txt guide

 doc/imx/hab/habv4/secure_boot.txt | 100 -
 .../csf_additional_images.txt |  34 ++
 .../habv4/csf_examples/mx6_mx7/csf_uboot.txt  |  32 ++
 .../mx6_mx7/csf_uboot_fast_authentication.txt |  23 +
 .../habv4 => habv4/guides}/encrypted_boot.txt |   0
 doc/imx/habv4/guides/mx6_mx7_secure_boot.txt  | 402 ++
 .../habv4/guides/mx6_mx7_spl_secure_boot.txt  | 181 
 doc/imx/habv4/introduction_habv4.txt  | 262 
 doc/imx/habv4/script_examples/genIVT.pl   |  12 +
 9 files changed, 946 insertions(+), 100 deletions(-)
 delete mode 100644 doc/imx/hab/habv4/secure_boot.txt
 create mode 100644 
doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt
 create mode 100644 doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt
 create mode 100644 
doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt
 rename doc/imx/{hab/habv4 => habv4/guides}/encrypted_boot.txt (100%)
 create mode 100644 doc/imx/habv4/guides/mx6_mx7_secure_boot.txt
 create mode 100644 doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt
 create mode 100644 doc/imx/habv4/introduction_habv4.txt
 create mode 100644 doc/imx/habv4/script_examples/genIVT.pl

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/6] doc: imx: habv4: Remove extra hab directory for a cleaner documentation structure

[Breno Matheus Lima]

There is no need to have an extra hab directory under doc/imx/.

Habv4 and AHAB documentation can be added directly in doc/imx/ for a
cleaner documentation structure.

Signed-off-by: Breno Lima 
---
 doc/imx/{hab => }/habv4/encrypted_boot.txt | 0
 doc/imx/{hab => }/habv4/secure_boot.txt| 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename doc/imx/{hab => }/habv4/encrypted_boot.txt (100%)
 rename doc/imx/{hab => }/habv4/secure_boot.txt (100%)

diff --git a/doc/imx/hab/habv4/encrypted_boot.txt 
b/doc/imx/habv4/encrypted_boot.txt
similarity index 100%
rename from doc/imx/hab/habv4/encrypted_boot.txt
rename to doc/imx/habv4/encrypted_boot.txt
diff --git a/doc/imx/hab/habv4/secure_boot.txt b/doc/imx/habv4/secure_boot.txt
similarity index 100%
rename from doc/imx/hab/habv4/secure_boot.txt
rename to doc/imx/habv4/secure_boot.txt
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 6/6] doc: imx: habv4: Remove secure_boot.txt guide

[Breno Matheus Lima]

The secure_boot.txt guide was replaced by mx6_mx7_secure_boot.txt and
mx6_mx7_spl_secure_boot.txt documents.

Both documents covers all steps needed for SPL and non-SPL tagets,
so remove secure_boot.txt file to avoid duplicated content.

Signed-off-by: Breno Lima 
---
 doc/imx/habv4/secure_boot.txt | 100 --
 1 file changed, 100 deletions(-)
 delete mode 100644 doc/imx/habv4/secure_boot.txt

diff --git a/doc/imx/habv4/secure_boot.txt b/doc/imx/habv4/secure_boot.txt
deleted file mode 100644
index ae68dc8040..00
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 5/6] doc: imx: habv4: Move encrypted boot guide

[Breno Matheus Lima]

All guides are currently located at doc/imx/habv4/guides/ directory.

Move encrypted_boot.txt document to guides directory.

Signed-off-by: Breno Lima 
---
 doc/imx/habv4/{ => guides}/encrypted_boot.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename doc/imx/habv4/{ => guides}/encrypted_boot.txt (100%)

diff --git a/doc/imx/habv4/encrypted_boot.txt 
b/doc/imx/habv4/guides/encrypted_boot.txt
similarity index 100%
rename from doc/imx/habv4/encrypted_boot.txt
rename to doc/imx/habv4/guides/encrypted_boot.txt
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] imx: hab: Convert non-NULL IVT DCD pointer warning to an error

[Breno Matheus Lima]

The following NXP application notes and manual recommend to ensure the
IVT DCD pointer is Null prior to calling HAB API authenticate_image()
function:

- AN12263: HABv4 RVT Guidelines and Recommendations
- AN4581: Secure Boot on i.MX50, i.MX53, i.MX 6 and i.MX7 Series using
  HABv4
- CST docs: High Assurance Boot Version 4 Application Programming
  Interface Reference Manual

Commit ca89df7dd46f ("imx: hab: Convert DCD non-NULL error to warning")
converted DCD non-NULL error to warning due to the lack of documentation
at the time of first patch submission. We have warned U-Boot users since
v2018.03, and it makes sense now to follow the NXP recommendation to
ensure the IVT DCD pointer is Null.

DCD commands should only be present in the initial boot image loaded by
the SoC ROM. Starting in HAB v4.3.7 the HAB code  will generate an error
if a DCD pointer is present in an image being authenticated by calling the
HAB RVT API. Older versions of HAB will process and run DCD if it is
present, and this could lead to an incorrect authentication boot flow.

Signed-off-by: Breno Lima 
---
 arch/arm/mach-imx/hab.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index b88acd13da..e07076c726 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -560,8 +560,10 @@ int imx_hab_authenticate_image(uint32_t ddr_start, 
uint32_t image_size,
}
 
/* Verify if IVT DCD pointer is NULL */
-   if (ivt->dcd)
-   puts("Warning: DCD pointer should be NULL\n");
+   if (ivt->dcd) {
+   puts("Error: DCD pointer must be NULL\n");
+   goto hab_authentication_exit;
+   }
 
start = ddr_start;
bytes = image_size;
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: hab: extend hab_auth_img to calculate ivt_offset

[Breno Matheus Lima]

Hi Parthiban,

Em ter, 6 de nov de 2018 às 14:42, Parthiban Nallathambi  
escreveu:
>
> Current implementation of hab_auth_img command needs ivt_offset to
> authenticate the image. But ivt header is placed at the end of image
> date after padding.
>
> This leaves the usage of hab_auth_img command to fixed size or static
> offset for ivt header. New function "get_image_ivt_offset" is introduced
> to find the ivt offset during runtime. The case conditional check in this
> function is same as boot_get_kernel in common/bootm.c
>
> With this variable length image e.g. FIT image with any random size can
> have IVT at the end and ivt_offset option can be left optional
>
> Can be used as "hab_auth_img $loadaddr $filesize" from u-boot script
>
> Signed-off-by: Parthiban Nallathambi 
> ---
>  arch/arm/mach-imx/hab.c | 29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
> index b88acd13da..060d0866b3 100644
> --- a/arch/arm/mach-imx/hab.c
> +++ b/arch/arm/mach-imx/hab.c
> @@ -6,6 +6,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -302,18 +304,41 @@ static int do_hab_status(cmd_tbl_t *cmdtp, int flag, 
> int argc,
> return 0;
>  }
>
> +static ulong get_image_ivt_offset(ulong img_addr, ulong length)
> +{

I'm seeing that function get_image_ivt_offset() requires a length but
we are not using it, there is any reason for that?

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] imx: hab: extend hab_auth_img to calculate ivt_offset

[Breno Matheus Lima]

Hi Parthiban,

Em qua, 21 de nov de 2018 às 18:47, Parthiban Nallathambi  
escreveu:
>
> Hi Breno,
>
> On 11/21/18 7:42 PM, Breno Matheus Lima wrote:
> > Hi Parthiban,
> >
> > Em qua, 21 de nov de 2018 às 15:52, Parthiban Nallathambi  
> > escreveu:
> >>
> >> Hi Breno,
> >>
> >> On 11/21/18 5:45 PM, Breno Matheus Lima wrote:
> >>> Hi Parthiban,
> >>>
> >>> Em qua, 21 de nov de 2018 às 11:50, Parthiban Nallathambi  
> >>> escreveu:
> >>>>
> >>>> Current implementation of hab_auth_img command needs ivt_offset to
> >>>> authenticate the image. But ivt header is placed at the end of image
> >>>> date after padding.
> >>>>
> >>>> This leaves the usage of hab_auth_img command to fixed size or static
> >>>> offset for ivt header. New function "get_image_ivt_offset" is introduced
> >>>> to find the ivt offset during runtime. The case conditional check in this
> >>>> function is same as boot_get_kernel in common/bootm.c
> >>>>
> >>>> With this variable length image e.g. FIT image with any random size can
> >>>> have IVT at the end and ivt_offset option can be left optional
> >>>>
> >>>> Can be used as "hab_auth_img $loadaddr $filesize" from u-boot script
> >>>>
> >>>> Signed-off-by: Parthiban Nallathambi 
> >>>> ---
> >>>>
> >>>> Notes:
> >>>>  Changelog in v2:
> >>>>  - Finding IVT offset doesn't need length. Removed the
> >>>>  length argument from get_image_ivt_offset
> >>>>
> >>>>   arch/arm/mach-imx/hab.c | 29 +++--
> >>>>   1 file changed, 27 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
> >>>> index b88acd13da..dbfd692fa3 100644
> >>>> --- a/arch/arm/mach-imx/hab.c
> >>>> +++ b/arch/arm/mach-imx/hab.c
> >>>> @@ -6,6 +6,8 @@
> >>>>   #include 
> >>>>   #include 
> >>>>   #include 
> >>>> +#include 
> >>>> +#include 
> >>>>   #include 
> >>>>   #include 
> >>>>   #include 
> >>>> @@ -302,18 +304,41 @@ static int do_hab_status(cmd_tbl_t *cmdtp, int 
> >>>> flag, int argc,
> >>>>  return 0;
> >>>>   }
> >>>>
> >>>> +static ulong get_image_ivt_offset(ulong img_addr)
> >>>> +{
> >>>> +   const void *buf;
> >>>> +
> >>>> +   buf = map_sysmem(img_addr, 0);
> >>>> +   switch (genimg_get_format(buf)) {
> >>>> +#if defined(CONFIG_IMAGE_FORMAT_LEGACY)
> >>>> +   case IMAGE_FORMAT_LEGACY:
> >>>> +   return (image_get_image_size((image_header_t *)img_addr)
> >>>> +   + 0x1000 - 1)  & ~(0x1000 - 1);
> >>>> +#endif
> >>>> +#if IMAGE_ENABLE_FIT
> >>>> +   case IMAGE_FORMAT_FIT:
> >>>> +   return (fit_get_size(buf) + 0x1000 - 1)  & ~(0x1000 - 1);
> >>>> +#endif
> >>>> +   default:
> >>>> +   return 0;
> >>>> +   }
> >>>> +}
> >>>
> >>>
> >>> Do you have more details about the image header I should use here?
> >>
> >> Is the image signed using CST or similar tool? Is so, the signature data
> >> (HAB data: CSF, Certs and signature) pads at the end of the kernel
> >> image.
> >
> > Yes, my Kernel image contains an IVT and is signed with CST. The image
> > layout looks like link below:
> > https://pastebin.com/5qEt7ETa
> >
> >>
> >>>
> >>> I'm trying to get the IVT offset for my Kernel image based on NXP
> >>> 4.9.11_2.0.0_GA Linux release loaded at 0x8080:
> >>>
> >>> => fatload mmc 0:1 0x8080 zImage
> >>> => hab_auth_img 0x8080 
> >>
> >> Length for hab_auth_img is still mandatory. Length hear means the file
> >> size or total length of the image, this is required for the HAB API to
> >> authenticate (HAB_RVT_AUTHENTICATE_IMAGE).
> >
> > Oh ok, I understood the scenario right now.
> >
> >>From my first 

Re: [U-Boot] [PATCH v2] imx: hab: extend hab_auth_img to calculate ivt_offset

[Breno Matheus Lima]

Hi Parthiban,

Em qua, 21 de nov de 2018 às 15:52, Parthiban Nallathambi  
escreveu:
>
> Hi Breno,
>
> On 11/21/18 5:45 PM, Breno Matheus Lima wrote:
> > Hi Parthiban,
> >
> > Em qua, 21 de nov de 2018 às 11:50, Parthiban Nallathambi  
> > escreveu:
> >>
> >> Current implementation of hab_auth_img command needs ivt_offset to
> >> authenticate the image. But ivt header is placed at the end of image
> >> date after padding.
> >>
> >> This leaves the usage of hab_auth_img command to fixed size or static
> >> offset for ivt header. New function "get_image_ivt_offset" is introduced
> >> to find the ivt offset during runtime. The case conditional check in this
> >> function is same as boot_get_kernel in common/bootm.c
> >>
> >> With this variable length image e.g. FIT image with any random size can
> >> have IVT at the end and ivt_offset option can be left optional
> >>
> >> Can be used as "hab_auth_img $loadaddr $filesize" from u-boot script
> >>
> >> Signed-off-by: Parthiban Nallathambi 
> >> ---
> >>
> >> Notes:
> >>  Changelog in v2:
> >>  - Finding IVT offset doesn't need length. Removed the
> >>  length argument from get_image_ivt_offset
> >>
> >>   arch/arm/mach-imx/hab.c | 29 +++--
> >>   1 file changed, 27 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
> >> index b88acd13da..dbfd692fa3 100644
> >> --- a/arch/arm/mach-imx/hab.c
> >> +++ b/arch/arm/mach-imx/hab.c
> >> @@ -6,6 +6,8 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -302,18 +304,41 @@ static int do_hab_status(cmd_tbl_t *cmdtp, int flag, 
> >> int argc,
> >>  return 0;
> >>   }
> >>
> >> +static ulong get_image_ivt_offset(ulong img_addr)
> >> +{
> >> +   const void *buf;
> >> +
> >> +   buf = map_sysmem(img_addr, 0);
> >> +   switch (genimg_get_format(buf)) {
> >> +#if defined(CONFIG_IMAGE_FORMAT_LEGACY)
> >> +   case IMAGE_FORMAT_LEGACY:
> >> +   return (image_get_image_size((image_header_t *)img_addr)
> >> +   + 0x1000 - 1)  & ~(0x1000 - 1);
> >> +#endif
> >> +#if IMAGE_ENABLE_FIT
> >> +   case IMAGE_FORMAT_FIT:
> >> +   return (fit_get_size(buf) + 0x1000 - 1)  & ~(0x1000 - 1);
> >> +#endif
> >> +   default:
> >> +   return 0;
> >> +   }
> >> +}
> >
> >
> > Do you have more details about the image header I should use here?
>
> Is the image signed using CST or similar tool? Is so, the signature data
> (HAB data: CSF, Certs and signature) pads at the end of the kernel
> image.

Yes, my Kernel image contains an IVT and is signed with CST. The image
layout looks like link below:
https://pastebin.com/5qEt7ETa

>
> >
> > I'm trying to get the IVT offset for my Kernel image based on NXP
> > 4.9.11_2.0.0_GA Linux release loaded at 0x8080:
> >
> > => fatload mmc 0:1 0x8080 zImage
> > => hab_auth_img 0x8080 
>
> Length for hab_auth_img is still mandatory. Length hear means the file
> size or total length of the image, this is required for the HAB API to
> authenticate (HAB_RVT_AUTHENTICATE_IMAGE).

Oh ok, I understood the scenario right now.

From my first overview I thought we would add IVT_SIZE + CSF_PAD_SIZE
in ivt_offset to calculate the image length, similar approach we have
in spl.c:
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-imx/spl.c;h=a20b30d154d788e4ebd4e22e9a6568a4f24c057e;hb=HEAD#l226

In this case only load addr would be necessary.

>
> >
> > The zImage size in Header looks correct (0x00726690), but
> > get_image_ivt_offset() is returning 0x0
>
> Looks like IVT offset is not found in the image.
>
> >
> > $ hexdump zImage | head
> > 000  e1a0  e1a0  e1a0  e1a0
> > *
> > 020 0003 ea00 2818 016f   6690 0072
> > 030 0201 0403 9000 e10f 04f8 eb00 7001 e1a0
> > 040 8002 e1a0 2000 e10f 0003 e312 0001 1a00
> >
> > Seems that genimg_get_format() is returning 0x0.
>
> Image is not signed?

No, my zImage is signed.

>
> >
> > Any ideias if I'm missing something?
> >
> >> +
> >&

Re: [U-Boot] [PATCH v2] imx: hab: extend hab_auth_img to calculate ivt_offset

[Breno Matheus Lima]

Hi Parthiban,

Em qua, 21 de nov de 2018 às 11:50, Parthiban Nallathambi  
escreveu:
>
> Current implementation of hab_auth_img command needs ivt_offset to
> authenticate the image. But ivt header is placed at the end of image
> date after padding.
>
> This leaves the usage of hab_auth_img command to fixed size or static
> offset for ivt header. New function "get_image_ivt_offset" is introduced
> to find the ivt offset during runtime. The case conditional check in this
> function is same as boot_get_kernel in common/bootm.c
>
> With this variable length image e.g. FIT image with any random size can
> have IVT at the end and ivt_offset option can be left optional
>
> Can be used as "hab_auth_img $loadaddr $filesize" from u-boot script
>
> Signed-off-by: Parthiban Nallathambi 
> ---
>
> Notes:
> Changelog in v2:
> - Finding IVT offset doesn't need length. Removed the
> length argument from get_image_ivt_offset
>
>  arch/arm/mach-imx/hab.c | 29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
> index b88acd13da..dbfd692fa3 100644
> --- a/arch/arm/mach-imx/hab.c
> +++ b/arch/arm/mach-imx/hab.c
> @@ -6,6 +6,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -302,18 +304,41 @@ static int do_hab_status(cmd_tbl_t *cmdtp, int flag, 
> int argc,
> return 0;
>  }
>
> +static ulong get_image_ivt_offset(ulong img_addr)
> +{
> +   const void *buf;
> +
> +   buf = map_sysmem(img_addr, 0);
> +   switch (genimg_get_format(buf)) {
> +#if defined(CONFIG_IMAGE_FORMAT_LEGACY)
> +   case IMAGE_FORMAT_LEGACY:
> +   return (image_get_image_size((image_header_t *)img_addr)
> +   + 0x1000 - 1)  & ~(0x1000 - 1);
> +#endif
> +#if IMAGE_ENABLE_FIT
> +   case IMAGE_FORMAT_FIT:
> +   return (fit_get_size(buf) + 0x1000 - 1)  & ~(0x1000 - 1);
> +#endif
> +   default:
> +   return 0;
> +   }
> +}


Do you have more details about the image header I should use here?

I'm trying to get the IVT offset for my Kernel image based on NXP
4.9.11_2.0.0_GA Linux release loaded at 0x8080:

=> fatload mmc 0:1 0x8080 zImage
=> hab_auth_img 0x8080 

The zImage size in Header looks correct (0x00726690), but
get_image_ivt_offset() is returning 0x0

$ hexdump zImage | head
000  e1a0  e1a0  e1a0  e1a0
*
020 0003 ea00 2818 016f   6690 0072
030 0201 0403 9000 e10f 04f8 eb00 7001 e1a0
040 8002 e1a0 2000 e10f 0003 e312 0001 1a00

Seems that genimg_get_format() is returning 0x0.

Any ideias if I'm missing something?

> +
>  static int do_authenticate_image(cmd_tbl_t *cmdtp, int flag, int argc,
>  char * const argv[])
>  {
> ulong   addr, length, ivt_offset;
> int rcode = 0;
>
> -   if (argc < 4)
> +   if (argc < 3)

I think we can also change here to argc < 2, the function
get_image_ivt_offset() only requires the img addr now.

> return CMD_RET_USAGE;
>
> addr = simple_strtoul(argv[1], NULL, 16);
> length = simple_strtoul(argv[2], NULL, 16);
> -   ivt_offset = simple_strtoul(argv[3], NULL, 16);
> +   if (argc == 3)

argc ==2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent

[Breno Matheus Lima]

Commit 22191ac35344 ("drivers/crypto/fsl: assign job-rings to
 non-TrustZone") breaks HABv4 encrypted boot support in the
following i.MX devices:

- i.MX6UL
- i.MX7S
- i.MX7D
- i.MX7ULP

For preparing a HABv4 encrypted boot image it's necessary to
encapsulate the generated DEK in a blob. In devices listed
above the blob generation function takes into consideration
the Job Ring TrustZone ownership configuration (JROWN_NS)
and can be only decapsulated by the same configuration.

The ROM code expects DEK blobs encapsulated by the Secure World
environments which commonly have JROWN_NS = 0.

As U-Boot is running in Secure World we must have JROWN_NS = 0
so the blobs generated by dek_blob tool can be decapsulated
by the ROM code.

Linux Kernel is booting by default in TrustZone Secure World in
most of targets. Make job-rings assignment to non-Secure dependent
of CONFIG_OPTEE and CONFIG_ARMV7_BOOT_SEC_DEFAULT to avoid a Kernel
crash when booting Linux in non-Secure World.

OP-TEE users can still use dek_blob command as job ring assignment
is also dependent of CONFIG_CMD_DEKBLOB configuration.

Signed-off-by: Breno Lima 
---
 drivers/crypto/fsl/jr.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index cc8d3b02a5..23d5a64da0 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -635,11 +635,15 @@ int sec_init_idx(uint8_t sec_idx)
 #endif
 #endif
 
-   /* Set ownership of job rings to non-TrustZone mode by default */
-   for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) {
-   jrown_ns = sec_in32(>jrliodnr[i].ms);
-   jrown_ns |= JROWN_NS | JRMID_NS;
-   sec_out32(>jrliodnr[i].ms, jrown_ns);
+   if ((IS_ENABLED(CONFIG_OPTEE) ||
+!IS_ENABLED(CONFIG_ARMV7_BOOT_SEC_DEFAULT)) &&
+!IS_ENABLED(CONFIG_CMD_DEKBLOB)) {
+   /* Set ownership of job rings to  non-TrustZone mode. */
+   for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) {
+   jrown_ns = sec_in32(>jrliodnr[i].ms);
+   jrown_ns |= JROWN_NS | JRMID_NS;
+   sec_out32(>jrliodnr[i].ms, jrown_ns);
+   }
}
 
ret = jr_init(sec_idx);
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent

[Breno Matheus Lima]

Hi Bryan,

Em dom, 7 de abr de 2019 às 05:05, Bryan O'Donoghue
 escreveu:
>
>
>
> On 06/04/2019 22:41, Breno Matheus Lima wrote:
> > Hi Bryan,
> >
> > Em sáb, 6 de abr de 2019 às 12:21, Bryan O'Donoghue
> >  escreveu:
> >>
> >>
> >>
> >> On 05/04/2019 17:16, Breno Matheus Lima wrote:
> >> Basically you've described and additional dependency the BootROM has, so
> >> lets just "switch context" prior to calling into the BootROM and restore
> >> to a default non-secure job-ring assignment after.
> >
> > Yes, this can work for OP-TEE users decrypting additional boot images
> > at U-Boot level, however all users won't be able to
> > authenticate/decrypt the initial boot image at BootROM level.
>
> I don't understand that comment, perhaps you can give an example.
>

You can take a look in application note AN12056:
https://www.nxp.com/docs/en/application-note/AN12056.pdf

Section 2.2 provides more details on the encrypted boot sequence, as
you can see in Figure 1 the U-Boot image is decrypted at bootROM level
after a system reset. Section 4 explains how to encrypt and sign an
U-Boot image.

As I mentioned in commit log, the ROM code expects DEK blobs
encapsulated by the Secure World environments which commonly have
JROWN_NS = 0.

> > Out of
> > reset CAAM job rings are assigned to TrustZone secure world and
> > BootROM code is expecting blobs generated by the same environment.
> >
> > What about moving the job rings assignment to OP-TEE level? Something
> > similar as we currently have in imx-optee-os project?
>
> TBH, I see that as something that should be done _anyway_ not instead
> i.e. after u-boot, if you want to do 'stuff' with the CAAM you are either
>
> 1. Running in non-secure Linux, in which case you need the job-rings
> assigned to non-secure mode or
>
> 2. You are running inside of a TEE, in which case you absolutely need
> to have at least one job-ring
>
> ... and for the second case the right thing to do is to arbitrate
> ownership of job-rings via a DTB
>
> > https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/drivers/caam/hal/imx_6_7/hal_jr.c?h=imx_4.14.78_1.0.0_ga#n31
> >
> > U-Boot is running in TrustZone secure world in most of targets, in my
> > opinion it makes sense to have at least 1 job ring assigned to
> > TrustZone secure world.
>
> But if u-boot is running in secure-world
>
> save_jr_context();
> setup_some_new_jr_context();
> hab_authenticate_something();
> restore_jr_context();

This can only work if we do similar operation in CMD_DEKBLOB:

save_jr_context();
setup_some_new_jr_context();
blob_dek()
restore_jr_context();

Both operations blob_dek() and hab_authenticate_image() at U-Boot
level must have the Job Ring assigned for TrustZone secure world. The
first authentication/decryption at bootROM level is expecting a DEK
blobs generated by TrustZone secure world.

>
> As a "quick fix", that's the way I'd do it. Just pivoting on
> CONFIG_OPTEE is pretty easy to break i.e. you can have CONFIG_OPTEE
> defined in your u-boot config but not actually be executing a TEE, in
> which case by the time you boot Linux your JR assignment is wrong..

Can you please provide more details on how this can break users that
has CONFIG_OPTEE defined and are not executing a TEE? From my
understanding Linux Kernel will be running in TZ secure world and JRs
assigned to TZ non-secure world, CAAM driver can still be used on this
condition (Similar as we currently have for mx7dsabresd target).

In order to have a quick fix available, what about delaying the Job
Ring assignment in U-Boot?

Perhaps we can provide an U-Boot command to set the Job Ring
ownership, users can add this command in their boot script just before
booting Kernel and/or OP-TEE.

>
> The correct and flexible fix is passing a DTB descriptor that u-boot,
> OPTEE and Kernel can put data into so that there's a canonical
> description of which execution environment owns what.
>

Yes, I agree. We need a more flexible fix here.

Best regards,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH RESEND 6/6] doc: imx: habv4: Remove secure_boot.txt guide

[Breno Matheus Lima]

The secure_boot.txt guide was replaced by mx6_mx7_secure_boot.txt and
mx6_mx7_spl_secure_boot.txt documents.

Both documents covers all steps needed for SPL and non-SPL tagets,
so remove secure_boot.txt file to avoid duplicated content.

Signed-off-by: Breno Lima 
---
 doc/imx/habv4/secure_boot.txt | 100 --
 1 file changed, 100 deletions(-)
 delete mode 100644 doc/imx/habv4/secure_boot.txt

diff --git a/doc/imx/habv4/secure_boot.txt b/doc/imx/habv4/secure_boot.txt
deleted file mode 100644
index ae68dc8040..00
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] doc: imx: habv4: Remove secure_boot.txt guide

[Breno Matheus Lima]

Hi Stefano,

Em sex, 15 de fev de 2019 às 09:57, Stefano Babic  escreveu:
>
> On 23/01/19 20:30, Breno Matheus Lima wrote:
> > The secure_boot.txt guide was replaced by mx6_mx7_secure_boot.txt and
> > mx6_mx7_spl_secure_boot.txt documents.
> >
> > Both documents covers all steps needed for SPL and non-SPL tagets,
> > so remove secure_boot.txt file to avoid duplicated content.
> >
> > Signed-off-by: Breno Lima 
> > ---
> >  doc/imx/habv4/secure_boot.txt | 100 --
> >  1 file changed, 100 deletions(-)
> >  delete mode 100644 doc/imx/habv4/secure_boot.txt
> >
> > diff --git a/doc/imx/habv4/secure_boot.txt b/doc/imx/habv4/secure_boot.txt
> > deleted file mode 100644
> > index ae68dc8040..00
> >
>
> I have applied to my working branch, but I cannot find this on
> patchwork. The rest of the series is present, this not, weird..

Thanks for looking this series.

Interesting, I'm also not being able to find it in patchwork.

Anyway, I have just sent again :)

Best regards,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Problems to build i.MX8MQ EVK board

[Breno Matheus Lima]

Hi Stefano,

Em qui, 31 de jan de 2019 às 11:21, Stefano Babic  escreveu:
>
> Hi Breno,
>
> On 31/01/19 14:16, Breno Matheus Lima wrote:
> > Hi Peng,
> >
> > I'm trying to build imx8mq_evk_defconfig target by following the
> > README file under board/freescale/imx8mq_evk/.
> >
> > I'm seeing the following error with latest U-Boot:
> >
> > ./tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected operator
>
> I think this is due to the "==" operator that is not accepted by your
> shell, if you are not using bash. There is a patch but I asked to do in
> a different way.
>
> http://patchwork.ozlabs.org/patch/1019908/

Yes this is the problem, after applying this patch I'm not seeing the
issue anymore :-)

Thanks for pointing this patch!

Best regards,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Problems to build i.MX8MQ EVK board

[Breno Matheus Lima]

Hi Peng,

I'm trying to build imx8mq_evk_defconfig target by following the
README file under board/freescale/imx8mq_evk/.

I'm seeing the following error with latest U-Boot:

./tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected operator
./tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected operator
./tools/imx8m_image.sh: 15: [: spl/u-boot-spl-ddr.bin: unexpected operator
./tools/imx8m_image.sh: 15: [: spl/u-boot-spl-ddr.bin: unexpected operator
WARNING './spl/u-boot-spl-ddr.bin' not found, resulting binary is not-functional

Seems that imx8m_image.sh script is not generating the u-boot-spl-ddr.bin file.

Do you happen to know if I'm missing something else?

I have the following firmwares in place:

- bl31.bin
- signed_hdmi_imx8m.bin
- lpddr4_pmu_train_1d_dmem.bin
- lpddr4_pmu_train_1d_imem.bin
- lpddr4_pmu_train_2d_dmem.bin
- lpddr4_pmu_train_2d_imem.bin

Thanks,
Breno Lima

-- 
Breno Matheus Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent

[Breno Matheus Lima]

Hi Bryan,

Seems that my last email didn't get in U-Boot mailing list, I'm sending again.

Em sáb, 6 de abr de 2019 às 12:21, Bryan O'Donoghue
 escreveu:
>
>
>
> On 05/04/2019 17:16, Breno Matheus Lima wrote:
> > + if ((IS_ENABLED(CONFIG_OPTEE) ||
> > +  !IS_ENABLED(CONFIG_ARMV7_BOOT_SEC_DEFAULT)) &&
> > +  !IS_ENABLED(CONFIG_CMD_DEKBLOB)) {
>
> So.
>
> How does this patch work if you want to do HABv4 encrypted
> authentication of an OP-TEE image prior to booting it ?

Thanks for your comments and for pointing this out, I agree that this
can be an issue for OP-TEE users that may want to decrypt additional
boot images at U-Boot level.

The main issue is that all users are currently impacted in first
authentication/decryption executed at BootROM level:

BootROM -> HABv4 -> U-Boot

We may need to come up with a solution suitable for all use cases

>
> i.e.
>
> You'll switch the job-ring ownership over to non-trusted world, call HAB
> and the BootROM will fail to authenticate.
>
> How about we improve the hab driver in u-boot ?
>
> 1. I notice somebody has already added a save_gd()/restore_gd() pair
> 2. How about a save_jr()/restore_jr() pair and
> 3. a bootrom_jr_setup() ?
>
> In pseudocode then
>
> do_hab_auth()
> {
> save_jr();  // save current job-ring context
> bootrom_jr_setup(); // set job-ring to bootrom mode
> hab_rvt_authenticate();
> restore_jr();   // restore previous job-ring context
> }
>
> That gets us out of the nasty business of
>
> 1. Constraining the use case of CONFIG_OPTEE=y &&
> authenticate(encrypted-dek-blob);
>
> 2. Pushing changes into upstream OP-TEE for job-ring assignment
>
> IMV - we should save and restore the job ring context so that all of
> this stuff will "just work"
>
> That should work for
>
> BootROM -> u-boot -> HABv4 auth(encryptedblob) -> Linux
>
> and
>
> BootROM -> u-boot -> run optee -> HABv4 auth(encrypted blob) -> Linux
>
> Basically you've described and additional dependency the BootROM has, so
> lets just "switch context" prior to calling into the BootROM and restore
> to a default non-secure job-ring assignment after.

Yes, this can work for OP-TEE users decrypting additional boot images
at U-Boot level, however all users won't be able to
authenticate/decrypt the initial boot image at BootROM level. Out of
reset CAAM job rings are assigned to TrustZone secure world and
BootROM code is expecting blobs generated by the same environment.

What about moving the job rings assignment to OP-TEE level? Something
similar as we currently have in imx-optee-os project?

https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/drivers/caam/hal/imx_6_7/hal_jr.c?h=imx_4.14.78_1.0.0_ga#n31

U-Boot is running in TrustZone secure world in most of targets, in my
opinion it makes sense to have at least 1 job ring assigned to
TrustZone secure world.

Best regards,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent

[Breno Matheus Lima]

Hi Bryan,

Em sáb, 6 de abr de 2019 às 12:21, Bryan O'Donoghue
 escreveu:
>
>
>
> On 05/04/2019 17:16, Breno Matheus Lima wrote:
> > + if ((IS_ENABLED(CONFIG_OPTEE) ||
> > +  !IS_ENABLED(CONFIG_ARMV7_BOOT_SEC_DEFAULT)) &&
> > +  !IS_ENABLED(CONFIG_CMD_DEKBLOB)) {
>
> So.
>
> How does this patch work if you want to do HABv4 encrypted
> authentication of an OP-TEE image prior to booting it ?

Thanks for your comments and for pointing this out, I agree that this
can be an issue for OP-TEE users that may want to decrypt additional
boot images at U-Boot level.

The main issue is that all users are currently impacted in first
authentication/decryption executed at BootROM level:

BootROM -> HABv4 -> U-Boot

We may need to come up with a solution suitable for all use cases.

>
> i.e.
>
> You'll switch the job-ring ownership over to non-trusted world, call HAB
> and the BootROM will fail to authenticate.
>
> How about we improve the hab driver in u-boot ?
>
> 1. I notice somebody has already added a save_gd()/restore_gd() pair
> 2. How about a save_jr()/restore_jr() pair and
> 3. a bootrom_jr_setup() ?
>
> In pseudocode then
>
> do_hab_auth()
> {
> save_jr();  // save current job-ring context
> bootrom_jr_setup(); // set job-ring to bootrom mode
> hab_rvt_authenticate();
> restore_jr();   // restore previous job-ring context
> }
>
> That gets us out of the nasty business of
>
> 1. Constraining the use case of CONFIG_OPTEE=y &&
> authenticate(encrypted-dek-blob);
>
> 2. Pushing changes into upstream OP-TEE for job-ring assignment
>
> IMV - we should save and restore the job ring context so that all of
> this stuff will "just work"
>
> That should work for
>
> BootROM -> u-boot -> HABv4 auth(encryptedblob) -> Linux
>
> and
>
> BootROM -> u-boot -> run optee -> HABv4 auth(encrypted blob) -> Linux
>
> Basically you've described and additional dependency the BootROM has, so
> lets just "switch context" prior to calling into the BootROM and restore
> to a default non-secure job-ring assignment after.

Yes, this can work for OP-TEE users decrypting additional boot images
at U-Boot level, however all users won't be able to
authenticate/decrypt the initial boot image at BootROM level. Out of
reset CAAM job rings are assigned to TrustZone secure world and
BootROM code is expecting blobs generated by the same environment.

What about moving the job rings assignment to OP-TEE level? Something
similar as we currently have in imx-optee-os project?

https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/drivers/caam/hal/imx_6_7/hal_jr.c?h=imx_4.14.78_1.0.0_ga#n31

U-Boot is running in TrustZone secure world in most of targets, in my
opinion it makes sense to have at least 1 job ring assigned to
TrustZone secure world.

Best regards,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] doc: Remove duplicated documentation directory

[Breno Matheus Lima]

Commit ad7061ed742e ("doc: Move device tree bindings documentation to
 doc/device-tree-bindings") moved all device tree binding documentation
to doc/device-tree-bindings directory.

The current U-Boot project still have two documentation directories:

- doc/
- Documentation/

Move all documentation and sphinx files to doc directory so all content
can be in a common place.

Signed-off-by: Breno Lima 
---
 MAINTAINERS|  2 +-
 Makefile   |  6 +++---
 {Documentation => doc}/Makefile| 10 +-
 {Documentation => doc}/conf.py |  0
 .../device-tree-bindings}/arm/l2c2x0.txt   |  0
 .../device-tree-bindings}/axi/gdsys,ihs_axi.txt|  0
 .../board/gdsys,board_gazerbeam.txt|  0
 .../device-tree-bindings/clock}/fsl,mpc83xx-clk.txt|  0
 .../device-tree-bindings}/cpu/fsl,mpc83xx.txt  |  0
 .../misc}/misc/fsl,mpc83xx-serdes.txt  |  0
 .../misc}/misc/gdsys,io-endpoint.txt   |  0
 .../misc}/misc/gdsys,iocon_fpga.txt|  0
 .../misc}/misc/gdsys,iocpu_fpga.txt|  0
 .../device-tree-bindings/misc}/misc/gdsys,soc.txt  |  0
 .../ram/fsl,mpc83xx-mem-controller.txt |  0
 .../reserved-memory/reserved-memory.txt|  0
 .../device-tree-bindings}/timer/fsl,mpc83xx-timer.txt  |  0
 {Documentation => doc}/efi.rst |  0
 {Documentation => doc}/index.rst   |  0
 {Documentation => doc}/linker_lists.rst|  0
 {Documentation => doc}/media/Makefile  |  4 ++--
 .../media/linker_lists.h.rst.exceptions|  0
 {Documentation => doc}/serial.rst  |  0
 .../sphinx-static/theme_overrides.css  |  0
 {Documentation => doc}/sphinx/cdomain.py   |  0
 {Documentation => doc}/sphinx/kernel_include.py|  0
 {Documentation => doc}/sphinx/kerneldoc.py |  0
 {Documentation => doc}/sphinx/kfigure.py   |  0
 {Documentation => doc}/sphinx/load_config.py   |  0
 {Documentation => doc}/sphinx/parse-headers.pl |  2 +-
 {Documentation => doc}/sphinx/requirements.txt |  0
 {Documentation => doc}/sphinx/rstFlatTable.py  |  2 +-
 32 files changed, 13 insertions(+), 13 deletions(-)
 rename {Documentation => doc}/Makefile (91%)
 rename {Documentation => doc}/conf.py (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings}/arm/l2c2x0.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings}/axi/gdsys,ihs_axi.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings}/board/gdsys,board_gazerbeam.txt (100%)
 rename {Documentation/devicetree/bindings/clk => 
doc/device-tree-bindings/clock}/fsl,mpc83xx-clk.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings}/cpu/fsl,mpc83xx.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings/misc}/misc/fsl,mpc83xx-serdes.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings/misc}/misc/gdsys,io-endpoint.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings/misc}/misc/gdsys,iocon_fpga.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings/misc}/misc/gdsys,iocpu_fpga.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings/misc}/misc/gdsys,soc.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings}/ram/fsl,mpc83xx-mem-controller.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings}/reserved-memory/reserved-memory.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings}/timer/fsl,mpc83xx-timer.txt (100%)
 rename {Documentation => doc}/efi.rst (100%)
 rename {Documentation => doc}/index.rst (100%)
 rename {Documentation => doc}/linker_lists.rst (100%)
 rename {Documentation => doc}/media/Makefile (89%)
 rename {Documentation => doc}/media/linker_lists.h.rst.exceptions (100%)
 rename {Documentation => doc}/serial.rst (100%)
 rename {Documentation => doc}/sphinx-static/theme_overrides.css (100%)
 rename {Documentation => doc}/sphinx/cdomain.py (100%)
 rename {Documentation => doc}/sphinx/kernel_include.py (100%)
 rename {Documentation => doc}/sphinx/kerneldoc.py (100%)
 rename {Documentation => doc}/sphinx/kfigure.py (100%)
 rename {Documentation => doc}/sphinx/load_config.py (100%)
 rename {Documentation => doc}/sphinx/parse-headers.pl (99%)
 rename {Documentation => doc}/sphinx/requirements.txt (100%)
 rename {Documentation => doc}/sphinx/rstFlatTable.py (99%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 33fd4652a4..78872169cd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -474,7 +474,7 @@ S:  Maintained
 T: git 

[U-Boot] [PATCH] Revert "drivers/crypto/fsl: assign job-rings to non-TrustZone"

[Breno Matheus Lima]

Commit 22191ac35344 ("drivers/crypto/fsl: assign job-rings to
 non-TrustZone") breaks HABv4 encrypted boot support in the
following i.MX devices:

- i.MX6UL
- i.MX7S
- i.MX7D
- i.MX7ULP

For preparing a HABv4 encrypted boot image it's necessary to
encapsulate the generated DEK in a blob. In devices listed
above the blob generation function takes into consideration
the Job Ring TrustZone ownership configuration (JROWN_NS)
and can be only decapsulated by the same configuration.

The ROM code expects DEK blobs encapsulated by the Secure World
environments which commonly have JROWN_NS = 0.

As U-Boot is running in Secure World we must have JROWN_NS = 0
so the blobs generated by dek_blob tool can be decapsulated
by the ROM code.

Job-rings assignment is now handled in OP-TEE OS, this commit can
be safely reverted.
https://github.com/OP-TEE/optee_os/pull/2986

This reverts commit 22191ac353445ad8fafc5a78aefcd94e78963041.

Signed-off-by: Breno Lima 
---
 drivers/crypto/fsl/jr.c | 9 -
 drivers/crypto/fsl/jr.h | 2 --
 2 files changed, 11 deletions(-)

diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index cc8d3b02a5..3121762364 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -578,8 +578,6 @@ int sec_init_idx(uint8_t sec_idx)
 {
ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
uint32_t mcr = sec_in32(>mcfgr);
-   uint32_t jrown_ns;
-   int i;
int ret = 0;
 
 #ifdef CONFIG_FSL_CORENET
@@ -635,13 +633,6 @@ int sec_init_idx(uint8_t sec_idx)
 #endif
 #endif
 
-   /* Set ownership of job rings to non-TrustZone mode by default */
-   for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) {
-   jrown_ns = sec_in32(>jrliodnr[i].ms);
-   jrown_ns |= JROWN_NS | JRMID_NS;
-   sec_out32(>jrliodnr[i].ms, jrown_ns);
-   }
-
ret = jr_init(sec_idx);
if (ret < 0) {
printf("SEC initialization failed\n");
diff --git a/drivers/crypto/fsl/jr.h b/drivers/crypto/fsl/jr.h
index f6fbb44383..ffd3a19273 100644
--- a/drivers/crypto/fsl/jr.h
+++ b/drivers/crypto/fsl/jr.h
@@ -33,8 +33,6 @@
 #define JRNSLIODN_MASK 0x0fff
 #define JRSLIODN_SHIFT 0
 #define JRSLIODN_MASK  0x0fff
-#define JROWN_NS   0x0008
-#define JRMID_NS   0x0001
 
 #define JQ_DEQ_ERR -1
 #define JQ_DEQ_TO_ERR  -2
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP

[Breno Matheus Lima]

Hi Sjoerd,

Em seg, 17 de jun de 2019 às 11:26, Sjoerd Simons
 escreveu:
>
> On Tue, 2019-06-04 at 18:56 -0300, Fabio Estevam wrote:
> > On Tue, Jun 4, 2019 at 5:41 PM Sjoerd Simons
> >  wrote:
>
> > We have been using imx_usb_loader for a long time. After DM / fit
> > comvesion the IVT piece is not added into the final .img.
> >
> > From the main Makefile:
> >
> > ifdef CONFIG_SPL_LOAD_FIT
> > MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O
> > u-boot \
> > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
> > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
> > $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST)))
> > else
> > MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \
> > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
> > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
> > MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O
> > u-boot \
> > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
> > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
> > u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log
> > CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-
> > boot.imx.log
> > endif
> >
> > we  can see that the ivt is not added for the CONFIG_SPL_LOAD_FIT
> > case.
> >
> > I tried to change this logic, but so far was not able to make it
> > work.
>
> So when looking through how secure boot can work from the SPL i can
> accross e246bfcfe. Which explains the u-boot SPL expect a signed fit
> image with roughly the following layout:
>
> --
> | | | |   |   | ||
> | FIT | FIT | FIT |   | U-BOOT| ATF | U-BOOT |
> | FDT | IVT | CSF |   | nodtb.bin | |   DTB  |
> | | | |   |   | ||
> --
>
> The code aligns the IVT at 0x1000 and the standard CSF size is
> 0x2000. So one has to set CONFIG_FIT_EXTERNAL_OFFSET=0x3000 (assuming the FIT 
> FDT <= 0x1000 bytes) to make CONFIG_SECURE_BOOT work in this setup (even if 
> HAB is off and the image isn't signed). Otherwise the SPL won't pick up the 
> correct location for all the external data.
>
> Seems a bit ugly that the start offset of the external data can't be
> introspected from the fdt blob, but oh well.
>
> The way this seems to work for i.mx8 is that the SECOND_LOADER command
> sticks in a IVT header into the fit image. I assume some other tooling
> can then stick the CSF data in the appropriate place (anyone have a
> pointer?).
>

Thanks for looking at this issue.

We are using similar structure in NXP U-Boot for i.MX8M devices, you
can use dd tool as explained in document below:
https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/guides/mx8m_mx8mm_secure_boot.txt?h=imx_v2018.03_4.14.98_2.0.0_ga#n301

> Now i guess the first question becomes whether the i.mx6 should follow
> the same layout. And if so how to integrate it properly (teach mkimage
> about handling firmware_ivt for fit images?).
>

IMHO we should follow the same layout as in i.MX8M, as far as I know
in NXP BSP this is handled by imx-mkimage tool:
https://source.codeaurora.org/external/imx/imx-mkimage/?h=imx_4.14.98_2.0.0_ga

Perhaps we can try similar with mkimage tool included in upstream U-Boot?

> Relatedly i was looking for a good description of using HAB for loading
> the OS in FIT images, but failed to find a good document. pointers
> welcome.
>

For HAB API usage you can take a look in HABv4 RVT Guidelines and
Recommendations application note:
https://www.nxp.com/docs/en/application-note/AN12263.pdf

The U-Boot docs in NXP BSP U-Boot also provides an overview:
https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4?h=imx_v2018.03_4.14.98_2.0.0_ga

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] mx6sxsabresd: imximage.cfg: Handle the CONFIG_SECURE_BOOT case

[Breno Matheus Lima]

Secure boot is not enabled in mx6sxsabresd imximage.cfg, add support
for it.

Signed-off-by: Breno Lima 
---
 board/freescale/mx6sxsabresd/imximage.cfg | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/freescale/mx6sxsabresd/imximage.cfg 
b/board/freescale/mx6sxsabresd/imximage.cfg
index 3e94f6ab66..0354bb36e2 100644
--- a/board/freescale/mx6sxsabresd/imximage.cfg
+++ b/board/freescale/mx6sxsabresd/imximage.cfg
@@ -17,6 +17,13 @@ IMAGE_VERSION 2
 
 BOOT_FROM  sd
 
+/*
+ * Secure boot support
+ */
+#ifdef CONFIG_SECURE_BOOT
+CSF CONFIG_CSF_SIZE
+#endif
+
 /*
  * Device Configuration Data (DCD)
  *
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] crypto/fsl: Use __sec_set_jr_context_normal

[Breno Matheus Lima]

Hi Bryan,

Em ter, 30 de abr de 2019 às 05:13, Bryan O'Donoghue
 escreveu:
>
>
>
> On 30/04/2019 02:28, Bryan O'Donoghue wrote:
> >
> >
> > On 25/04/2019 04:24, Breno Matheus Lima wrote:
> >> I couldn't get encrypted boot working in my first attempt, doing the
> >> exact same procedure with commit 22191ac35344 ("drivers/crypto/fsl:
> >> assign job-rings to non-TrustZone") reverted works fine.
> >
> > Hi Breno,
> >
> > I noticed another patch from you re: dek blob, does that address this
> > issue for you are is this still a live thing ?

No, the patch I have recently submitted does not address the JR
TrustZone issue we are currently seeing with DEK blob decapsulation at
ROM level. I was not following AN12056 when I tried so I couldn't see
this other issue at first moment.

> >
> > If you are running in secure-world, and the BootROM dek blob stuff
> > validates job-ring ownership it _should_ be possible to flip the
> > ownership bits to what the BootROM expects and then back again.
> >
> > If its not working, presumably its because we aren't flipping ownership
> > at the right time.
>
> It occurred to me after I went to bed.
>
> The right thing to do is leave the BootROM settings up until we hand-off
> and then set the required post-boot settings.
>
> Something I reckon can be ~easily done in some sort of architectural
> handover preparation function.
>
> I'll spin that patchset.

Thanks for preparing a second version for this patchset, I see that
you have also replied to my other e-mail in "[PATCH 1/4] crypto/fsl:
Introduce API to save/restore job-ring context".

Your new proposal looks fine to me, I can test again.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] mx6sl: hab: Fix pu_irom_mmu_enabled address

[Breno Matheus Lima]

According to hab.c code we have to notify the ROM code if the MMU is
enabled or not. This is achieved by setting the "pu_irom_mmu_enabled"
to 0x1.

The current address in hab.c code is wrong for i.MX6SL, according to ROM
map file the correct address is 0x00901c60.

As we are writing in the wrong address the ROM code is not flushing the
caches when needed, and the following HAB event is observed in certain
scenarios:

- HAB Event 1 -
event data:
0xdb 0x00 0x14 0x41 0x33 0x18 0xc0 0x00
0xca 0x00 0x0c 0x00 0x01 0xc5 0x00 0x00
0x00 0x00 0x07 0xe4

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_SIGNATURE (0x18)
CTX = HAB_CTX_COMMAND (0xC0)
ENG = HAB_ENG_ANY (0x00)

Update MX6SL_PU_IROM_MMU_EN_VAR to address this issue.

Reported-by: Frank Zhang 
Signed-off-by: Breno Lima 
Reviewed-by: Ye Li 
---
 arch/arm/mach-imx/hab.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index d42a15e877..24d16299e8 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -17,7 +17,7 @@
 #define ALIGN_SIZE 0x1000
 #define MX6DQ_PU_IROM_MMU_EN_VAR   0x009024a8
 #define MX6DLS_PU_IROM_MMU_EN_VAR  0x00901dd0
-#define MX6SL_PU_IROM_MMU_EN_VAR   0x00900a18
+#define MX6SL_PU_IROM_MMU_EN_VAR   0x00901c60
 #define IS_HAB_ENABLED_BIT \
(is_soc_type(MXC_SOC_MX7ULP) ? 0x8000 : \
 (is_soc_type(MXC_SOC_MX7) ? 0x200 : 0x2))
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] crypto/fsl: Use __sec_set_jr_context_normal

[Breno Matheus Lima]

Hi Bryan,

Em ter, 23 de abr de 2019 às 07:20, Bryan O'Donoghue
 escreveu:
>
> Use __sec_set_jr_context_normal() to set job-ring ownership rather than the
> current in-line array walk.
>
> Signed-off-by: Bryan O'Donoghue 
> ---
>  drivers/crypto/fsl/jr.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index 7b13aa4a61..65982b8369 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -616,7 +616,6 @@ int sec_init_idx(uint8_t sec_idx)
>  {
> ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
> uint32_t mcr = sec_in32(>mcfgr);
> -   uint32_t jrown_ns;
> int i;

We may also need to remove this variable otherwise we get build warning below:

drivers/crypto/fsl/jr.c: In function 'sec_init_idx':
drivers/crypto/fsl/jr.c:625:6: warning: unused variable 'i' [-Wunused-variable]
  int i;
  ^

Thanks for submitting this patch set.

I couldn't get encrypted boot working in my first attempt, doing the
exact same procedure with commit 22191ac35344 ("drivers/crypto/fsl:
assign job-rings to non-TrustZone") reverted works fine.

I will take a better look in your patch set and let you know if I find
something.

Best Regards,
Breno Matheus Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] crypto/fsl: Introduce API to save/restore job-ring context

[Breno Matheus Lima]

Hi Bryan,

Em ter, 23 de abr de 2019 às 07:20, Bryan O'Donoghue
 escreveu:
>
> We need to handle the case where DEK blobs are passed to the BootROM. In
> this case, unlike in HAB authentication the BootROM checks job-ring
> ownership set to secure world.
>
> One possible solution is to set the job-ring ownership to the expected
> state for DEK blobs and then restore to whatever the run-time wants.
>
> For the case where Linux runs in normal-world we would want to set the
> job-ring ownership to normal-world.
>
> The first step in the ownership context switch dance is making an API to do
> it.
>
> This patch introduces:
>
> void __weak sec_set_jr_context_secure(void);
> void __weak sec_set_jr_context_normal(void);
>
> This can be over-ridden for a given architecture, as will be necessary for
> the MPC85xxx
>
> Signed-off-by: Bryan O'Donoghue 
> ---
>  drivers/crypto/fsl/jr.c | 38 ++
>  include/fsl_sec.h   |  3 +++
>  2 files changed, 41 insertions(+)
>
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index cc8d3b02a5..7b13aa4a61 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -574,6 +574,44 @@ static int rng_init(uint8_t sec_idx)
> return ret;
>  }
>  #endif
> +
> +static void __sec_set_jr_context_secure(uint8_t sec_idx)
> +{
> +   ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
> +   uint32_t jrown_ns;
> +   int i;
> +
> +   for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) {
> +   jrown_ns = sec_in32(>jrliodnr[i].ms);
> +   jrown_ns &= ~(JROWN_NS | JRMID_NS);

We have the following definition at drivers/crypto/fsl/jr.h:

#define JRMID_NS 0x0001

Seems that we are setting JROWN_MID field which is not TrustZone
related, from i.MX7D Security Reference Manual:

Job Ring Owner's MID. This field defines the MID of the bus master
that is permitted to read or write the registers that are specific to
a particular Job Ring. These registers include the job ring
configuration registers, the interrupt registers, the CAAM Secure
Memory Access Permissions and Secure Memory Access Group registers and
the ring buffer registers.

Could you please double check?

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] imx: hab: Increase CSF_SIZE for i.MX6 and i.MX7 devices

[Breno Matheus Lima]

In certain i.MX devices the encrypted boot image is failing to boot.

According to AN12056 "Encrypted Boot on HABv4 and CAAM Enabled Devices"
it's necessary to pad CSF to 0x2000 and append DEK blob.

In this case the total image size in boot data structure must cover the
entire binary otherwise the dek_blob won't be copied to memory and image
won't be decrypted.

Increase CSF_SIZE to 0x4000 to avoid such issue when booting encrypted
boot images.

Signed-off-by: Breno Lima 
---
 include/configs/mx6_common.h | 2 +-
 include/configs/mx7_common.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h
index 6b20c6db58..2b8ce9d71d 100644
--- a/include/configs/mx6_common.h
+++ b/include/configs/mx6_common.h
@@ -59,7 +59,7 @@
 
 /* Secure boot (HAB) support */
 #ifdef CONFIG_SECURE_BOOT
-#define CONFIG_CSF_SIZE0x2000
+#define CONFIG_CSF_SIZE0x4000
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_SPL_DRIVERS_MISC_SUPPORT
 #endif
diff --git a/include/configs/mx7_common.h b/include/configs/mx7_common.h
index cc7e87269e..f3167c51d4 100644
--- a/include/configs/mx7_common.h
+++ b/include/configs/mx7_common.h
@@ -48,7 +48,7 @@
 
 /* Secure boot (HAB) support */
 #ifdef CONFIG_SECURE_BOOT
-#define CONFIG_CSF_SIZE0x2000
+#define CONFIG_CSF_SIZE0x4000
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_SPL_DRIVERS_MISC_SUPPORT
 #endif
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Wandboard boot failure when HAB support is enabled

[Breno Matheus Lima]

Hi Jon,

Em qua, 28 de ago de 2019 às 09:49, Jon Szymaniak
 escreveu:
>
> Hello all,
>
> I'd like to get U-Boot >= 2019.07 booting on a Wandboard Quad with HAB
> support enabled, but appear to be running into either some regressions
> (or matters of PEBKAC).  For the scope of this discussion, I'm only
> concerned with booting an "insecure" HAB-enabled U-Boot image (ideally
> FIT), on a device that has not yet been fused (i.e., with the U-Boot
> commands need to fuse and verify successful image authentication prior
> to enforcing ROM-based authentication of the SPL).
>
> As of commit df516569, I am able to use the default Wandboard
> configuration, enable HAB support (CONFIG_SECURE_BOOT=y) via
> menufconfig, build and then successfully boot the resulting SPL +
> u-boot-ivt.img combination on a Wandboard Quad (B1).
>
> However, as of commit 5b85858 (and onwards), I am no longer able to
> boot the second stage U-Boot image when HAB support is enabled (the
> SPL still works, however).  Disabling HAB support (the default
> configuration state) still works, of course.
>
> Issue #1: u-boot-ivt.img load address changed from 0x1780 to 0x
>
> It appears that the generation of u-boot-ivt.img "breaks" in df516569
> because the associated MKIMAGEFLAGS_u-boot-ivt.img definition, present
> in an else clause of the top-level Makefile, is no longer used, now
> that the default configuration enables SPL FIT support. As a result,
> the generated image contains a load address of 0x0, which results in a
> boot loop.
>
> I've tried to work around this with the following change, which leads
> me to Issue #2.  I'm unclear on whether a multi-DTB IVT image should
> be instead be produced to address this, or whether "legacy" boot
> images should continue to work.
>
> diff --git a/Makefile b/Makefile
> index f3857ab6a9..07fa36b4c1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1243,12 +1243,13 @@ else
>  MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \
>  -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
>  -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
> +endif
> +
>  MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O u-boot \
>  -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
>  -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
>  u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log
>  CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log
> -endif
>
>  MKIMAGEFLAGS_u-boot-dtb.img = $(MKIMAGEFLAGS_u-boot.img)
>
>
> Issue #2: u-boot-ivt.img stuck in lib/hang.c's hang()
>
> Once executing u-boot-ivt.img from 0x1780, I'm seeing the
> following call path occurring:
>
> board_init_f() -> initcall_run_list @ fdtdec_setup() errors out -->
> hang() -> bootstage_error(BOOTSTAGE_ID_NEED_RESET)
>
> I'm still trying to determine specifically where in fdtdec_setup() the
> failure is, but before I dig too much deeper, I was hoping to get some
> feedback on whether this is simply a matter of needing to produce a
> modified image that isn't currently being built.
>
> Again, I'm not entirely clear what the expectation is here -- should I
> simply not be attempting to boot the u-boot-ivt.img? Should this still
> work despite not being a FIT image?  Do we need to generate a
> FIT-based IVT image for this configuration?

Thanks for reporting the issue.

We have a related discussion in thread below, this issue is happening
with all i.MX targets supporting FIT image:
https://lists.denx.de/pipermail/u-boot/2019-June/373287.html

HABv4 authenticate image API requires an IVT to work, so in my opinion
we need to generate an IVT header for the FIT image. We are using
similar structure in NXP U-Boot for i.MX8M devices:
https://lists.denx.de/pipermail/u-boot/2019-June/373287.html

HABv4 should be able to authenticate FIT image in memory in case we
provide a valid IVT, we can specif multiple blocks and offsets as in
CSF example below:
https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/csf_examples/mx8m_mx8mm/csf_fit.txt?h=imx_v2018.03_4.14.98_2.0.0_ga

I don't see a reason to use the "legacy" boot images as HAB should be
able to authenticate the FIT image layout, we may need to understand
how to adapt the current image layout.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] habv4: tools: Avoid hardcoded CSF size for SPL targets

[Breno Matheus Lima]

Hi Peng,

Em qua, 11 de set de 2019 às 22:07, Peng Fan  escreveu:
>
> Hi Breno,
>
> > Subject: [PATCH 2/4] habv4: tools: Avoid hardcoded CSF size for SPL targets
>
> I saw this patch in imx/master, not in Tom's tree. But this patch breaks
> build for other archs, such as arc and etc.
>

Thanks for reporting the issue, I will submit a fix.

Best regards,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] habv4: tools: Avoid hardcoded CSF size for SPL targets

[Breno Matheus Lima]

Hi Stefano,

Em seg, 16 de set de 2019 às 05:17, Stefano Babic  escreveu:
>
> Hi Breno,
>
> On 12/09/19 03:07, Peng Fan wrote:
> > Hi Breno,
> >
> >> Subject: [PATCH 2/4] habv4: tools: Avoid hardcoded CSF size for SPL targets
> >
> > I saw this patch in imx/master, not in Tom's tree. But this patch breaks
> > build for other archs, such as arc and etc.
> >
>
> Any news on this ? I dropped it from u-boot-imx due the breakage, but I
> can easy pick it up again if it will be fixed.
>

Sorry the delay. I'm still trying to reproduce the issue, probably
something is missing in my buildman setup.

One workaround would be to enclose the code with CONFIG_SECURE_BOOT,
this code is only used by IH_TYPE_FIRMWARE_IVT which requires HAB to
be enabled. I can send a patch but I would like to confirm before.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken

[Breno Matheus Lima]

age Ver:2 (i.MX53/6/7 compatible)
> Mode: DCD
> Data Size:659456 Bytes = 644.00 KiB = 0.63 MiB
> Load Address: 877ff420
> Entry Point:  8780
> HAB Blocks:   0x877ff400 0x 0x0009cc00
> DCD Blocks:   0x0091 0x002c 0x01b4
>
>
> In [1] F.1. Signing code downloadable with the manufacturing tool from the
> document about Secure Boot, found the NOTE which says:
>
> "Due to an issue with i.MX7D Rev D, the first 4K of OCRAM is not
> available during boot time, on this case users must set the image start
> address greater or equal to 0x911000. For more details please check
> E11166 in Mask Set Errata for Mask 3N09P."
>
> E11166 description in [2]:
> "e11166: OCRAM: The first 4K of OCRAM (0x91 - 0x910fff) is not
> available during
> boot time
>
> Description: The first 4K of OCRAM (0x91 – 0x910fff) is not available
> during boot time which effects plug-ins and custom boot images.Using
> this space may
> cause image corruption during boot time. At time of boot failure, the system 
> may
> enter into serial download mode.
>
> Workaround: Users must set the boot or plugin image start address greater or
> equal to 0x911000 (if the boot image or plug-in is running in OCRAM).
> Alternatively,
> users can use a boot/plugin image load address in the external DDR
> memory instead of
> the internal OCRAM."
>
> Could it be the root cause why I'm facing this issue?
>

When booting from NAND the DCD table is not loaded in OCRAM so that
shouldn't be a problem. The DCD is loaded in OCRAM when booting via
USB OTG using the serial download protocol, you can have more details
in link below:

https://github.com/NXPmicro/mfgtools/wiki/UUU-default-support-protocol-list#habv4-closed-chip-support

> 4. BTW,  is there any publicly available information about analysis of
> BootROM log buffer
> that can be obtained by reading data pointed by Log Buffer Pointer (at
> 0x01E0)
> on iMX7?
>
> [1] https://www.nxp.com/docs/en/application-note/AN4581.pdf
> [2] https://www.nxp.com/docs/en/errata/IMX7DS_3N09P.pdf
>
>
> Looking forward for your replies/comments.
> Thanks!
>
> --
> Best regards - Freundliche Grüsse - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opan...@gmail.com
> skype: igor.opanyuk
> +380 (93) 836 40 67
> http://ua.linkedin.com/in/iopaniuk
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
Breno Matheus Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] imx6: spl: Reduce SPL limit size in case CONFIG_SECURE_BOOT is enabled

[Breno Matheus Lima]

HI Stefano and Jagan,

Em qua, 18 de set de 2019 às 04:59, Stefano Babic  escreveu:
>
> Hi Jagan, Breno,
>
> On 17/09/19 09:13, Jagan Teki wrote:
> > Hi Breno,
> >
> > On Thu, Jul 18, 2019 at 6:06 PM Breno Matheus Lima  
> > wrote:
> >>
> >> In case CONFIG_SECURE_BOOT is enabled we need to limit the SPL size to
> >> avoid a possible HAB failure event:
> >>
> >> - HAB Event 1 -
> >> event data:
> >> 0xdb 0x00 0x14 0x42 0x33 0x22 0x33 0x00
> >> 0x00 0x00 0x00 0x0f 0x00 0x90 0x70 0x00
> >> 0x00 0x01 0x10 0x00
> >> STS = HAB_FAILURE (0x33)
> >> RSN = HAB_INV_ADDRESS (0x22)
> >> CTX = HAB_CTX_TARGET (0x33)
> >> ENG = HAB_ENG_ANY (0x00)
> >>
> >> As explained in Commit 23612534fe0f ("spl: imx6: Provide a SPL_SIZE_LIMIT
> >> default") the i.MX6 SPL size limit is 68KB.
> >>
> >> The ROM code is copying the image size defined in boot data to its
> >> respective load address, in case we exceed the OCRAM free region a
> >> HAB invalid address failure event is generated.
> >>
> >> The maximum CSF size is defined in CONFIG_CSF_SIZE, reduce SPL size
> >> limit based on this configuration.
> >>
> >> Signed-off-by: Breno Lima 
> >> ---
> >>  tools/spl_size_limit.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/tools/spl_size_limit.c b/tools/spl_size_limit.c
> >> index 98ff491867..8902e30129 100644
> >> --- a/tools/spl_size_limit.c
> >> +++ b/tools/spl_size_limit.c
> >> @@ -14,6 +14,9 @@ int main(int argc, char *argv[])
> >>
> >>  #ifdef CONFIG_SPL_SIZE_LIMIT
> >> spl_size_limit = CONFIG_SPL_SIZE_LIMIT;
> >> +#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_CSF_SIZE)
> >> +   spl_size_limit -= CONFIG_CSF_SIZE;
> >> +#endif
> >
> > But, if the target enable HAB on SPL the size would be part of SPL
> > limit, isn't ?
>
> Indeed - it is not clear to me, too, if it is correct, even if CSF is
> added later by the NXP signing tools. The patch reduces significantly
> the available space for SPL, I just wondering why just mamoj is
> affected. Jagan, does it work without this patch applied ?
>

When enabling CONFIG_SECURE_BOOT we increase the image length in boot
data by the size defined in CONFIG_CSF_SIZE. The HAB code will parse
the boot data structure and copy the image length defined (SPL image
plus CSF appended) to its respective load address.

HAB code is checking if the image length defined can fit in OCRAM free
region, and logs the following HAB event in case not:

- HAB Event 1 -
event data:
0xdb 0x00 0x14 0x42 0x33 0x22 0x33 0x00
0x00 0x00 0x00 0x0f 0x00 0x90 0x70 0x00
0x00 0x01 0x10 0x00
STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ADDRESS (0x22)
CTX = HAB_CTX_TARGET (0x33)
ENG = HAB_ENG_ANY (0x00)

HAB closed targets would then fail to boot, so for that reason we
added CONFIG_CSF_SIZE into consideration.

We can reduce the default CONFIG_CSF_SIZE but it depends on the user
specific HAB setup. I did a quick test with RSA 4K keys and couldn't
achieve 0x2000 length.

Do you think we should decrease default CONFIG_CSF_SIZE? Perhaps
0x2000 plus the maximum dek blob size (0x60) would be enough for most
uses cases, users requiring more space can modify their
CONFIG_CSF_SIZE.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/4] Kconfig: Migrate CONFIG_CSF_SIZE to Kconfig

[Breno Matheus Lima]

Move CONFIG_CSF_SIZE to Kconfig and define default value as 0x4000.

mx8mqevk requires 0x2000 add this configuration in imx8mq_evk_defconfig
file.

Signed-off-by: Breno Lima 
---
 arch/arm/mach-imx/Kconfig | 7 +++
 configs/imx8mq_evk_defconfig  | 1 +
 include/configs/cl-som-imx7.h | 1 -
 include/configs/imx8mq_evk.h  | 4 
 include/configs/mx6_common.h  | 4 
 include/configs/mx6sllevk.h   | 6 --
 include/configs/mx6ullevk.h   | 6 --
 include/configs/mx7_common.h  | 4 
 include/configs/mx7ulp_evk.h  | 6 --
 scripts/config_whitelist.txt  | 1 -
 10 files changed, 8 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index b6fd1595f0..3df96d570b 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -43,6 +43,13 @@ config SECURE_BOOT
  This option enables the support for secure boot (HAB).
  See doc/README.mxc_hab for more details.
 
+config CSF_SIZE
+   hex "Maximum size for Command Sequence File (CSF) binary"
+   default 0x4000
+   help
+ Define the maximum size for Command Sequence File (CSF) binary
+ this information is used to define the image boot data.
+
 config CMD_BMODE
bool "Support the 'bmode' command"
default y
diff --git a/configs/imx8mq_evk_defconfig b/configs/imx8mq_evk_defconfig
index 8417c3ba54..534f4b39f0 100644
--- a/configs/imx8mq_evk_defconfig
+++ b/configs/imx8mq_evk_defconfig
@@ -6,6 +6,7 @@ CONFIG_SYS_TEXT_BASE=0x4020
 CONFIG_TARGET_IMX8MQ_EVK=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL=y
+CONFIG_CSF_SIZE=0x2000
 CONFIG_FIT=y
 CONFIG_FIT_EXTERNAL_OFFSET=0x3000
 CONFIG_SPL_LOAD_FIT=y
diff --git a/include/configs/cl-som-imx7.h b/include/configs/cl-som-imx7.h
index 4c93fc6cbe..73fbceec06 100644
--- a/include/configs/cl-som-imx7.h
+++ b/include/configs/cl-som-imx7.h
@@ -19,7 +19,6 @@
 
 /* Uncomment to enable secure boot support */
 /* #define CONFIG_SECURE_BOOT */
-#define CONFIG_CSF_SIZE0x4000
 
 /* Network */
 #define CONFIG_FEC_MXC
diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h
index 16e4136fa9..8ecdf9eb67 100644
--- a/include/configs/imx8mq_evk.h
+++ b/include/configs/imx8mq_evk.h
@@ -9,10 +9,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_SECURE_BOOT
-#define CONFIG_CSF_SIZE0x2000 /* 8K region */
-#endif
-
 #define CONFIG_SPL_MAX_SIZE(124 * 1024)
 #define CONFIG_SYS_MONITOR_LEN (512 * 1024)
 #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h
index 2b8ce9d71d..25e27da54b 100644
--- a/include/configs/mx6_common.h
+++ b/include/configs/mx6_common.h
@@ -57,12 +57,8 @@
 /* MMC */
 #define CONFIG_FSL_USDHC
 
-/* Secure boot (HAB) support */
-#ifdef CONFIG_SECURE_BOOT
-#define CONFIG_CSF_SIZE0x4000
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_SPL_DRIVERS_MISC_SUPPORT
 #endif
-#endif
 
 #endif
diff --git a/include/configs/mx6sllevk.h b/include/configs/mx6sllevk.h
index fb8f44684b..b96e63198d 100644
--- a/include/configs/mx6sllevk.h
+++ b/include/configs/mx6sllevk.h
@@ -10,12 +10,6 @@
 
 #include "mx6_common.h"
 
-#ifdef CONFIG_SECURE_BOOT
-#ifndef CONFIG_CSF_SIZE
-#define CONFIG_CSF_SIZE 0x4000
-#endif
-#endif
-
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (16 * SZ_1M)
 
diff --git a/include/configs/mx6ullevk.h b/include/configs/mx6ullevk.h
index 1fc5c24dec..7416ccf3ae 100644
--- a/include/configs/mx6ullevk.h
+++ b/include/configs/mx6ullevk.h
@@ -13,12 +13,6 @@
 #include "mx6_common.h"
 #include 
 
-#ifdef CONFIG_SECURE_BOOT
-#ifndef CONFIG_CSF_SIZE
-#define CONFIG_CSF_SIZE 0x4000
-#endif
-#endif
-
 #define PHYS_SDRAM_SIZESZ_512M
 
 /* Size of malloc() pool */
diff --git a/include/configs/mx7_common.h b/include/configs/mx7_common.h
index 4f822ef9a0..01a625b135 100644
--- a/include/configs/mx7_common.h
+++ b/include/configs/mx7_common.h
@@ -46,13 +46,9 @@
 
 #define CONFIG_ARMV7_PSCI_1_0
 
-/* Secure boot (HAB) support */
-#ifdef CONFIG_SECURE_BOOT
-#define CONFIG_CSF_SIZE0x4000
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_SPL_DRIVERS_MISC_SUPPORT
 #endif
-#endif
 
 /*
  * If we have defined the OPTEE ram size and not OPTEE it means that we were
diff --git a/include/configs/mx7ulp_evk.h b/include/configs/mx7ulp_evk.h
index 2af5a4fe3e..c53270d3ad 100644
--- a/include/configs/mx7ulp_evk.h
+++ b/include/configs/mx7ulp_evk.h
@@ -14,12 +14,6 @@
 /*Uncomment it to use secure boot*/
 /*#define CONFIG_SECURE_BOOT*/
 
-#ifdef CONFIG_SECURE_BOOT
-#ifndef CONFIG_CSF_SIZE
-#define CONFIG_CSF_SIZE0x4000
-#endif
-#endif
-
 #define CONFIG_BOARD_POSTCLK_INIT
 #define CONFIG_SYS_BOOTM_LEN   0x100
 
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 2c9cfb450d..9684f1784a 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -276,7 

[U-Boot] [PATCH 0/4] Improve HAB support for SPL targets

[Breno Matheus Lima]

This patch set is improving the HAB support for targets that are using
IH_TYPE_FIRMWARE_IVT image type.

Patch 0001 is migrating CONFIG_CSF_SIZE to Kconfig so value can be
configurable and used by U-Boot tools.

Patch 0002 is fixing secure boot support for targets using
IH_TYPE_FIRMWARE_IVT image type.

Patch 0003 is verifying the SPL size to avoid a possible HAB failure event.

Patch 0004 is cleaning up the code as CONFIG_SECURE_BOOT is now enabled
through Kconfig.

Breno Lima (4):
  Kconfig: Migrate CONFIG_CSF_SIZE to Kconfig
  habv4: tools: Avoid hardcoded CSF size for SPL targets
  imx6: spl: Reduce SPL limit size in case CONFIG_SECURE_BOOT is enabled
  imx: configs: Cleanup CONFIG_SECURE_BOOT comments

 arch/arm/mach-imx/Kconfig | 7 +++
 common/image.c| 8 +---
 configs/imx8mq_evk_defconfig  | 1 +
 include/configs/cl-som-imx7.h | 4 
 include/configs/imx8mq_evk.h  | 4 
 include/configs/mx6_common.h  | 4 
 include/configs/mx6sllevk.h   | 6 --
 include/configs/mx6ullevk.h   | 6 --
 include/configs/mx7_common.h  | 4 
 include/configs/mx7ulp_evk.h  | 9 -
 scripts/config_whitelist.txt  | 1 -
 tools/default_image.c | 5 -
 tools/spl_size_limit.c| 3 +++
 13 files changed, 20 insertions(+), 42 deletions(-)

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/4] habv4: tools: Avoid hardcoded CSF size for SPL targets

[Breno Matheus Lima]

Currently it's not possible to authenticate the U-Boot proper of
mx6ul_14x14_evk_defconfig target:

Authenticate image from DDR location 0x877fffc0...
bad magic magic=0x0 length=0x00 version=0x3
bad length magic=0x0 length=0x00 version=0x3
bad version magic=0x0 length=0x00 version=0x3
spl: ERROR:  image authentication fail

Commit 0633e134784a ("imx: hab: Increase CSF_SIZE for i.MX6 and
i.MX7 devices") has increased CSF_SIZE to avoid a possible issue
when booting encrypted boot images.

Commit d21bd69b6e95 ("tools: mkimage: add firmware-ivt image type
for HAB verification") is hardcoding the CSF and IVT sizes, the
new CSF size is not being considered and u-boot-ivt.img fails to
boot.

Avoid hardcoded CSF and IVT size to fix this issue.

Signed-off-by: Breno Lima 
---
 common/image.c| 8 +---
 tools/default_image.c | 5 -
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/common/image.c b/common/image.c
index 9f9538fac2..fc19dfdd9c 100644
--- a/common/image.c
+++ b/common/image.c
@@ -54,6 +54,8 @@ static const image_header_t *image_get_ramdisk(ulong rd_addr, 
uint8_t arch,
 #endif /* !USE_HOSTCC*/
 
 #include 
+#include 
+#include 
 
 #ifndef CONFIG_SYS_BARGSIZE
 #define CONFIG_SYS_BARGSIZE 512
@@ -369,9 +371,9 @@ void image_print_contents(const void *ptr)
}
} else if (image_check_type(hdr, IH_TYPE_FIRMWARE_IVT)) {
printf("HAB Blocks:   0x%08x   0x   0x%08x\n",
-   image_get_load(hdr) - image_get_header_size(),
-   image_get_size(hdr) + image_get_header_size()
-   - 0x1FE0);
+   image_get_load(hdr) - image_get_header_size(),
+   (int)(image_get_size(hdr) + image_get_header_size()
+   + sizeof(flash_header_v2_t) - CONFIG_CSF_SIZE));
}
 }
 
diff --git a/tools/default_image.c b/tools/default_image.c
index 4b7d1ed4a1..7a26232779 100644
--- a/tools/default_image.c
+++ b/tools/default_image.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 static image_header_t header;
 
@@ -106,7 +108,8 @@ static void image_set_header(void *ptr, struct stat *sbuf, 
int ifd,
 
if (params->type == IH_TYPE_FIRMWARE_IVT)
/* Add size of CSF minus IVT */
-   imagesize = sbuf->st_size - sizeof(image_header_t) + 0x1FE0;
+   imagesize = sbuf->st_size - sizeof(image_header_t)
+   + CONFIG_CSF_SIZE - sizeof(flash_header_v2_t);
else
imagesize = sbuf->st_size - sizeof(image_header_t);
 
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/4] imx6: spl: Reduce SPL limit size in case CONFIG_SECURE_BOOT is enabled

[Breno Matheus Lima]

In case CONFIG_SECURE_BOOT is enabled we need to limit the SPL size to
avoid a possible HAB failure event:

- HAB Event 1 -
event data:
0xdb 0x00 0x14 0x42 0x33 0x22 0x33 0x00
0x00 0x00 0x00 0x0f 0x00 0x90 0x70 0x00
0x00 0x01 0x10 0x00
STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ADDRESS (0x22)
CTX = HAB_CTX_TARGET (0x33)
ENG = HAB_ENG_ANY (0x00)

As explained in Commit 23612534fe0f ("spl: imx6: Provide a SPL_SIZE_LIMIT
default") the i.MX6 SPL size limit is 68KB.

The ROM code is copying the image size defined in boot data to its
respective load address, in case we exceed the OCRAM free region a
HAB invalid address failure event is generated.

The maximum CSF size is defined in CONFIG_CSF_SIZE, reduce SPL size
limit based on this configuration.

Signed-off-by: Breno Lima 
---
 tools/spl_size_limit.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/spl_size_limit.c b/tools/spl_size_limit.c
index 98ff491867..8902e30129 100644
--- a/tools/spl_size_limit.c
+++ b/tools/spl_size_limit.c
@@ -14,6 +14,9 @@ int main(int argc, char *argv[])
 
 #ifdef CONFIG_SPL_SIZE_LIMIT
spl_size_limit = CONFIG_SPL_SIZE_LIMIT;
+#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_CSF_SIZE)
+   spl_size_limit -= CONFIG_CSF_SIZE;
+#endif
 #ifdef CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD
spl_size_limit -= GENERATED_GBL_DATA_SIZE;
 #endif
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/4] imx: configs: Cleanup CONFIG_SECURE_BOOT comments

[Breno Matheus Lima]

Since commit 6e1f4d2652e7 ("arm: imx-common: add SECURE_BOOT option
to Kconfig") the SECURE_BOOT option is selected through Kconfig.

Cleanup comments in code to align with this change.

Signed-off-by: Breno Lima 
---
 include/configs/cl-som-imx7.h | 3 ---
 include/configs/mx7ulp_evk.h  | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/include/configs/cl-som-imx7.h b/include/configs/cl-som-imx7.h
index 73fbceec06..3ca16c5201 100644
--- a/include/configs/cl-som-imx7.h
+++ b/include/configs/cl-som-imx7.h
@@ -17,9 +17,6 @@
 
 #define CONFIG_BOARD_LATE_INIT
 
-/* Uncomment to enable secure boot support */
-/* #define CONFIG_SECURE_BOOT */
-
 /* Network */
 #define CONFIG_FEC_MXC
 #define CONFIG_FEC_XCV_TYPE RGMII
diff --git a/include/configs/mx7ulp_evk.h b/include/configs/mx7ulp_evk.h
index c53270d3ad..437b2758e8 100644
--- a/include/configs/mx7ulp_evk.h
+++ b/include/configs/mx7ulp_evk.h
@@ -11,9 +11,6 @@
 #include 
 #include 
 
-/*Uncomment it to use secure boot*/
-/*#define CONFIG_SECURE_BOOT*/
-
 #define CONFIG_BOARD_POSTCLK_INIT
 #define CONFIG_SYS_BOOTM_LEN   0x100
 
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] mx6ulevk: Add support for SDP boot in SPL target

[Breno Matheus Lima]

Currently it's not possible to boot mx6ulevk board using
imx_usb_loader tool:

U-Boot SPL 2018.03 (Jul 18 2019 - 10:05:17 -0300)
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices

Enable necessary configuration in defconfig file.

Signed-off-by: Breno Lima 
---
 configs/mx6ul_14x14_evk_defconfig | 9 +
 1 file changed, 9 insertions(+)

diff --git a/configs/mx6ul_14x14_evk_defconfig 
b/configs/mx6ul_14x14_evk_defconfig
index 1d777b5fb2..4d12a7cb16 100644
--- a/configs/mx6ul_14x14_evk_defconfig
+++ b/configs/mx6ul_14x14_evk_defconfig
@@ -19,9 +19,13 @@ CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_SPL_TEXT_BASE=0x00908000
 CONFIG_SPL_FS_EXT4=y
 CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_USB_HOST_SUPPORT=y
+CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_USB_SDP_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_SPL=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -67,4 +71,9 @@ CONFIG_FSL_QSPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="FSL"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0525
+CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
+CONFIG_CI_UDC=y
 CONFIG_VIDEO=y
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot