Re: [U-Boot] i.MX HAB: U-Boot loading from SPI NOR flash

2019-02-19 Thread Fernando AE 
Hello all,

I figured out by myself, just posting here in case someone else need the info...

What happens is that the DCD block in the U-Boot image header contains
a minimal setup info to start the external DRAM. After initializing
the DRAM, the ROM code will copy the whole U-Boot image to the
external DRAM. Then, the ROM code will compute the U-Boot image
signature and compare to the attached one coming with the U-Boot image
itself.

The tricky part is determining the DRAM address where the signature
computation should begin. To do so, we need to modify the very
automated building in NXP U-Boot to dump info of the following step:

MKIMAGE u-boot-dtb.imx

Adding SHELL='sh -x' to the make command we see:

+ ./tools/mkimage -n board/hms/mx6ul_ewon4/imximage.cfg.cfgtmp -T
imximage -e 0x8780 -d u-boot-dtb.bin u-boot-dtb.imx

The output of this command, manually run, gives:

Image Type:   Freescale IMX Boot Image
Image Ver:2 (i.MX53/6/7 compatible)
Mode: DCD
Data Size:475136 Bytes = 464.00 KiB = 0.45 MiB
Load Address: 877ff420
Entry Point:  8780
HAB Blocks:   877ff400  0006fc00
DCD Blocks:   0091 002c 01f0

Here, from HAB Blocks, we can infer that the signature computation
starts at 0x877ff400 (in the i.MX6UL DRAM space) and covers a size of
0x6fc00 bytes, which corresponds to the size of u-boot-dtb.imx.
Setting up these values to the code signing tool configuration works.

Hope it helps someone one day,
Fernando

On Fri, Feb 8, 2019 at 10:46 AM Fernando AE  wrote:
>
> Hello all,
>
> I'm trying to make the High Assurance Boot (HAB) work in an iMX6UL-based 
> board.
>
> Here is the context of my experiment:
>
> 0) Reference documentation:
> [1] Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using
> HABv4, Document Number: AN4581, Rev. 2 , 05/2018
> [2] i.MX 6UltraLite Applications Processor Reference Manual, Document
> Number: IMX6ULRM
> Rev. 1, 04/2016
>
> 1) i.MX6UL-based board
> 2) Fuses set to boot from "Serial ROM though SPI", in reality there is
> a NOR flash there
> 3) Compiled/tried NXP U-Boot 2017.03 and 2018.03 with CONFIG_SECURE_BOOT=y
> 4) Both versions boot properly, I can use themselves to reflash and
> iterate a new U-Boot in NOR Flash
>
> As far I've understood, the ROM code loads the first 4KB in SRAM to
> first check the U-Boot header values, [2] 8.5.4.2 ECSPI Boot.
>
> If the header is ok, the whole U-Boot image in copied from NOR SPI to
> "application destination".
>
> **First question**:
>
> I assume that some code in the first 4KB have to be executed in order
> to turn on the external DRAM, otherwise the ROM code could not copy
> data to the "application destination".
>
> With this assumption, I cannot understand how the HAB can check the
> signature of the whole U-Boot image before running any code inside it.
>
> **Second question**:
>
> Basically what I need to know is what address should I tell HAB to
> start checking the signature. In the application note [1], the address
> is set to the DRAM (external bus).
>
> Thanks for your help,
> Fernando
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] i.MX HAB: U-Boot loading from SPI NOR flash

2019-02-08 Thread Fernando AE 
Hello all,

I'm trying to make the High Assurance Boot (HAB) work in an iMX6UL-based board.

Here is the context of my experiment:

0) Reference documentation:
[1] Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using
HABv4, Document Number: AN4581, Rev. 2 , 05/2018
[2] i.MX 6UltraLite Applications Processor Reference Manual, Document
Number: IMX6ULRM
Rev. 1, 04/2016

1) i.MX6UL-based board
2) Fuses set to boot from "Serial ROM though SPI", in reality there is
a NOR flash there
3) Compiled/tried NXP U-Boot 2017.03 and 2018.03 with CONFIG_SECURE_BOOT=y
4) Both versions boot properly, I can use themselves to reflash and
iterate a new U-Boot in NOR Flash

As far I've understood, the ROM code loads the first 4KB in SRAM to
first check the U-Boot header values, [2] 8.5.4.2 ECSPI Boot.

If the header is ok, the whole U-Boot image in copied from NOR SPI to
"application destination".

**First question**:

I assume that some code in the first 4KB have to be executed in order
to turn on the external DRAM, otherwise the ROM code could not copy
data to the "application destination".

With this assumption, I cannot understand how the HAB can check the
signature of the whole U-Boot image before running any code inside it.

**Second question**:

Basically what I need to know is what address should I tell HAB to
start checking the signature. In the application note [1], the address
is set to the DRAM (external bus).

Thanks for your help,
Fernando
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Unaligned memory accesses exception

2018-08-22 Thread Fernando AE 
Hello all,

I'm bringing up U-Boot for an iMX6UL board, and I've encountered
unaligned memory accesses exceptions while I was trying to test the
ETH commands (e.g., 'ping').

After investigation, I found out that the iMX6UL processor traps
unaligned memory accesses by default. As a workaround, I disabled
theses checks, hoping for negligible performance loss.

I'm wondering if it is a bad idea to disable unaligned memory accesses
during the U-Boot execution, regarding performance issues or other
drawbacks at the kernel level.

Thanks for your suggestions.
Best regards,
Fernando A. E.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Clarification ECC bytes

2018-07-18 Thread Fernando AE 
Thanks for your reply.

Following your suggestion, should I ask Scott Wood? In some mailing
lists we are advised not to directly send emails, if not invited.

Regards,
Fernando

On Wed, Jul 18, 2018 at 4:03 PM, Wolfgang Denk  wrote:
> Dear Fernando,
>
> In message 
>  you 
> wrote:
>>
>> I'm rebasing our internal code over v2017.11 and I found an unexpected
>> change in drivers/mtd/nand/nand_base.c:
>
> In such cases it is always a good idea to run "git blame" to find
> out where the code is coming from...
>
>> /* See nand_bch_init() for details. */
>> ecc->bytes = 0;
>> ecc->priv = nand_bch_init(mtd);
>> -
>>
>> This means that ecc->bytes = 0 is overwritting the board driver
>> supplied value. Actually, back in v2014.03, that specific line
>> (ecc->bytes = 0) did not exit. I also checked today in v2018.07 and
>> master, and this potential bug is still there.
>
> git blame says this comes from
>
> commit ceee07b65875bb01bef55cba06940ef7afc1afba
> Author: Scott Wood 
> Date:   Mon May 30 13:57:58 2016 -0500
>
> mtd: nand: Sync with Linux v4.6
>
> Updates the NAND code to match Linux v4.6.  The previous sync was from
> Linux v4.1 in commit d3963721d93fafa.
>
> Note that none of the individual NAND drivers tracked Linux closely
> enough to be synced themselves, other than manually applying a few
> cross-tree changes.
>
> Signed-off-by: Scott Wood 
> Tested-by: Heiko Schocher 
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> That's their goal, remember, a goal that's really contrary to that of
> the programmer or administrator. We just want to get our  jobs  done.
> $Bill  just  wants  to  become  $$Bill. These aren't even marginallly
> congruent.
>  -- Tom Christiansen in <6jhtqk$qls$1...@csnews.cs.colorado.edu>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Clarification ECC bytes

2018-07-18 Thread Fernando AE 
Hello all,

I'm rebasing our internal code over v2017.11 and I found an unexpected
change in drivers/mtd/nand/nand_base.c:

In the function nand_scan_tail:
-
(...)
case NAND_ECC_SOFT_BCH:
(...)
/*
 * Board driver should supply ecc.size and ecc.strength values
 * to select how many bits are correctable. Otherwise, default
 * to 4 bits for large page devices.
 */
if (!ecc->size && (mtd->oobsize >= 64)) {
ecc->size = 512;
ecc->strength = 4;
}

/* See nand_bch_init() for details. */
ecc->bytes = 0;
ecc->priv = nand_bch_init(mtd);
-

This means that ecc->bytes = 0 is overwritting the board driver
supplied value. Actually, back in v2014.03, that specific line
(ecc->bytes = 0) did not exit. I also checked today in v2018.07 and
master, and this potential bug is still there.

Could someone kindly help me here? Removing this line is safe? Or I'm
missing something?

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

[U-Boot] Question: Frescale imx board repositories

2018-07-17 Thread Fernando AE 
Hello all,

I'd like to know what's the difference between the Frescale imx board
repositories from:

1) https://source.codeaurora.org/external/imx/uboot-imx
2) https://github.com/Freescale/u-boot-fslc

It seems that #2 is rebased more often and is referenced by yocto. I
was wordering if the differece could be in stability or board support.

Thanks for your help,
Fernando
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot