Skip to content
GitLab
  1. Mar 14, 2018
  3. Mar 13, 2018
    • Tom Rini's avatar
      Prepare v2018.03 · f95ab1fb
      Tom Rini authored 
      

Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      f95ab1fb
    • Bryan O'Donoghue's avatar
      imx: hab: Convert DCD non-NULL error to warning · ca89df7d
      Bryan O'Donoghue authored 
      commit 8c4037a0 ("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: 8c4037a0

 ("imx: hab: Ensure the IVT DCD pointer is Null prior
to calling HAB authenticate function.")

Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Utkarsh Gupta <utkarsh.gupta@nxp.com>
Cc: Breno Lima <breno.lima@nxp.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Link: https://boundarydevices.com/high-assurance-boot-hab-dummies


Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      ca89df7d
  5. Mar 11, 2018
  7. Mar 10, 2018
  9. Mar 09, 2018
    • Tuomas Tynkkynen's avatar
      ARM: Drop unreferenced CONFIG_* defines named after boards · b996b7d4
      Tuomas Tynkkynen authored 
      

The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_AT91SAM9263EK
CONFIG_AT91SAM9RLEK
CONFIG_BARIX_IPAM390
CONFIG_BOARD_H2200
CONFIG_EP9301
CONFIG_KZM_A9_GT
CONFIG_PICOSAM
CONFIG_PLATINUM_PICON
CONFIG_PLATINUM_TITANIUM
CONFIG_PM9261
CONFIG_PM9263
CONFIG_PM9G45
CONFIG_SIEMENS_DRACO
CONFIG_SIEMENS_PXM2
CONFIG_SIEMENS_RUT
CONFIG_SMDKC100
CONFIG_SMDKV310
CONFIG_STM32F4DISCOVERY

Most of them are config symbols named after the respective boards which
seems to have been a standard practice at some point.

Signed-off-by: default avatarTuomas Tynkkynen <tuomas@tuxera.com>
      b996b7d4
    • Tuomas Tynkkynen's avatar
      ARM: Drop unreferenced CONFIG_* defines named after SoCs · 17796171
      Tuomas Tynkkynen authored 
      

The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_ARM926EJS
CONFIG_CPUAT91
CONFIG_EXYNOS5800
CONFIG_SYS_CORTEX_R4

Most of them are config symbols named after the respective SoCs which
seems to have been a standard practice at some point.

Signed-off-by: default avatarTuomas Tynkkynen <tuomas@tuxera.com>
      17796171
    • Tuomas Tynkkynen's avatar
      MIPS: Drop unreferenced CONFIG_* defines · c604f47a
      Tuomas Tynkkynen authored 
      

The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_DBAU1X00
CONFIG_PB1X00

Most of them are config symbols named after the respective boards which
seems to have been a standard practice at some point.

Signed-off-by: default avatarTuomas Tynkkynen <tuomas@tuxera.com>
      c604f47a
    • Mario Six's avatar
      treewide: Fix gdsys mail addresses · d38826a3
      Mario Six authored 
      

The @gdsys.cc addresses are supposed to be used for mailing lists.
Switch all occurrences of @gdsys.de mail addresses to their @gdsys.cc
equivalent.

Also, Dirk's address was wrong in one place; fix that as well.

Signed-off-by: default avatarMario Six <six@gdsys.cc>
      d38826a3
    • Tuomas Tynkkynen's avatar
      ARM: qemu-arm: Increase CONFIG_SYS_CBSIZE · b771f0b1
      Tuomas Tynkkynen authored 
      

CONFIG_SYS_CBSIZE determines the maximum length of the kernel command
line, and the default value of 256 is too small for booting some Linux
images in the wild.

Signed-off-by: default avatarTuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
      b771f0b1
    • Yasushi SHOJI's avatar
      imx: syscounter: make sure asm is volatile · 314d9f7e
      Yasushi SHOJI authored 
      Without the volatile attribute, compilers are entitled to optimize out
the same asm().  In the case of __udelay() in syscounter.c, it calls
`get_ticks()` twice, one for the starting time and the second in the
loop to check the current time.  When compilers inline `get_ticks()`
they see the same `mrrc` instructions and optimize out the second one.
This leads to infinite loop since we don't get updated value from the
system counter.

Here is a portion of the disassembly of __udelay:

  88:	428b      	cmp	r3, r1
  8a:	f8ce 20a4 	str.w	r2, [lr, #164]	; 0xa4
  8e:	bf08      	it	eq
  90:	4282      	cmpeq	r2, r0
  92:	f8ce 30a0 	str.w	r3, [lr, #160]	; 0xa0
  96:	d3f7      	bcc.n	88 <__udelay+0x88>
  98:	e8bd 8cf0 	ldmia.w	sp!, {r4, r5, r6, r7, sl, fp, pc}

Note that final jump / loop at 96 to 88, we don't have any `mrrc`.

With a volatile attribute, the above changes to this:

  8a:	ec53 2f0e 	mrrc	15, 0, r2, r3, cr14
  8e:	42ab      	cmp	r3, r5
  90:	f8c1 20a4 	str.w	r2, [r1, #164]	; 0xa4
  94:	bf08      	it	eq
  96:	42a2      	cmpeq	r2, r4
  98:	f8c1 30a0 	str.w	r3, [r1, #160]	; 0xa0
  9c:	d3f5      	bcc.n	8a <__udelay+0x8a>
  9e:	e8bd 8cf0 	ldmia.w	sp!, {r4, r5, r6, r7, sl, fp, pc}
  a2:	bf00      	nop

I'm advised[1] to put volatile on all asm(), so this commit also adds it
to the asm() in timer_init().

[1]: https://lists.denx.de/pipermail/u-boot/2018-March/322062.html



Signed-off-by: default avatarYasushi SHOJI <yasushi.shoji@gmail.com>
Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      314d9f7e
    • Fabio Estevam's avatar
      imximage: Remove failure when no IVT offset is found · b5b0e4e3
      Fabio Estevam authored 
      

Sometimes imximage throws the following error:

  CFGS    board/freescale/vf610twr/imximage.cfg.cfgtmp
  CFGS    board/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

Later on, when running mkimage for the u-boot.imx it will succeed in
finding the IVT offset.

Looks like some race condition happening during parallel build when
processing mkimage for u-boot-dtb.imx and u-boot.imx.

A proper fix still needs to be implemented, but as a workaround let's
remove the error when the IVT offset is not found.

It is useful to have such message, especially during bring-up phase,
but the build error that it causes is severe, so better avoid the
build error for now.

The error checking can be re-implemented later when we have a proper
fix.

Reported-by: default avatarBreno Lima <breno.lima@nxp.com>
Reported-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      b5b0e4e3
  11. Mar 06, 2018
  13. Mar 05, 2018