The hab_rvt_failsafe() callback according to the HABv4 documentation:
"This function provides a safe path when image authentication has failed
and all possible boot paths have been exhausted. It is intended for use by
post-ROM boot stage components, via the ROM Vector Table."
Once invoked the par
On Mon, Dec 04, 2017 at 12:37:00PM +0900, Masahiro Yamada wrote:
> Freescale (NXP) boards have lots of defconfig files per board.
> I used "imply PANIC_HANG" for them.
>
> Signed-off-by: Masahiro Yamada
> Reviewed-by: York Sun
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Descript
Understanding if the HAB is enabled is something that we want to
interrogate and report on outside of the HAB layer. First step to that is
renaming the relevant function to match the previously introduced external
naming convention imx_hab_function()
The name imx_hab_is_hab_enabled() is a tautolog
This patch enables printout of the IVT entry, dcd and csf data fields.
Signed-off-by: Bryan O'Donoghue
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Albert Aribaud
Cc: Sven Ebenfeld
Cc: George McCollister
Cc: Breno Matheus Lima
---
arch/arm/mach-imx/hab.c | 2 ++
1 file changed, 2
On Tue, Dec 26, 2017 at 11:36:39AM -0700, Simon Glass wrote:
> Hi,
>
> Just three patches here. The test-coverage stuff has been pushed to
> u-boot-dm/next and I'll run that through again when the merge window
> opens.
>
>
> The following changes since commit 48a346061d1f0a7eff566f6a7cc7eeeba7e
It will be helpful to boot commands to know if the HAB is enabled. Export
imx_hab_is_enabled() now to facilitate further work with this data-point in
a secure-boot context.
Signed-off-by: Bryan O'Donoghue
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Albert Aribaud
Cc: Sven Ebenfeld
C
This patch implements the basic callback hooks for
hab_rvt_check_failsafe for BootROM code using the older BootROM address
layout - in my test case the i.MX7. Code based on new BootROM callbacks
will just do nothing and there's definitely a TODO to implement that extra
functionality on the alternat
Tidy up the HAB namespace a bit by prefixing external functions with
imx_hab. All external facing functions past this point will be prefixed in
the same way to make the fact we are doing IMX HAB activities clear from
reading the code. authenticate_image() could mean anything
imx_hab_authenticate_im
Tidy up the HAB namespace a bit by prefixing external functions with
imx_hab. All external facing functions past this point will be prefixed in
the same way to make the fact we are doing IMX HAB activities clear from
reading the code. authenticate_image() could mean anything
imx_hab_authenticate_im
The current flow of authenticate_image() will print the HAB event log even
if we reject an element of the IVT header before ever calling into the ROM.
This can be confusing.
This patch changes the flow of the code so that the HAB event log is only
printed out if we have called into the ROM and rec
It will be helpful to boot commands to know if the HAB is enabled. Export
imx_hab_is_enabled() now to facilitate further work with this data-point in
a secure-boot context.
Signed-off-by: Bryan O'Donoghue
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Albert Aribaud
Cc: Sven Ebenfeld
C
The hab_rvt_failsafe() callback according to the HABv4 documentation:
"This function provides a safe path when image authentication has failed
and all possible boot paths have been exhausted. It is intended for use by
post-ROM boot stage components, via the ROM Vector Table."
Once invoked the par
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
hab_failsafe when called puts the part into BootROM recovery mode.
This will allow u-boot scripts to script the dropping down into recovery
mode.
=> hab_failsafe
Shows the i.MX7 appear as "hiddev0,hidraw5: USB HID v1.10 Device [Freescale
SemiConductor Inc SP Blank ULT1] " in a Linux dmesg thus a
On Fri, Dec 29, 2017 at 11:51:43AM +0100, Stefano Babic wrote:
> Hi Tom,
>
> please pull from u-boot-imx, thanks! Series with patch causing warning:
>
> Hannu Lounento (5):
> net: e1000: add support for writing to EEPROM
>
> is dropped from PR until issues will be fixed. This caused a reb
hab_failsafe when called puts the part into BootROM recovery mode.
This will allow u-boot scripts to script the dropping down into recovery
mode.
=> hab_failsafe
Shows the i.MX7 appear as "hiddev0,hidraw5: USB HID v1.10 Device [Freescale
SemiConductor Inc SP Blank ULT1] " in a Linux dmesg thus a
The various i.MX BootROMs containing the High Assurance Boot (HAB) block
rely on a data structure called the Image Vector Table (IVT) to describe to
the BootROM where to locate various data-structures used by HAB during
authentication.
This patch adds a definition of the IVT header for use in late
Understanding if the HAB is enabled is something that we want to
interrogate and report on outside of the HAB layer. First step to that is
renaming the relevant function to match the previously introduced external
naming convention imx_hab_function()
The name imx_hab_is_hab_enabled() is a tautolog
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 t
CSF_PAD_SIZE should be defined in hab.h, move it to that location now.
Signed-off-by: Bryan O'Donoghue
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Albert Aribaud
Cc: Sven Ebenfeld
Cc: George McCollister
Cc: Breno Matheus Lima
---
arch/arm/include/asm/mach-imx/hab.h | 1 +
arch/ar
This patch implements the basic callback hooks for
hab_rvt_check_failsafe for BootROM code using the older BootROM address
layout - in my test case the i.MX7. Code based on new BootROM callbacks
will just do nothing and there's definitely a TODO to implement that extra
functionality on the alternat
The IVT is a self-describing structure which contains a self field. The
self field is the absolute physical base address the IVT ought to be at in
memory. Use the IVT self field to validate the calculated ivt_addr bugging
out if the two values differ.
Signed-off-by: Bryan O'Donoghue
Cc: Stefano B
u-boot command "hab_auth_img" tells a user that it takes
- addr - image hex address
- offset - hex offset of IVT in the image
but in fact the callback hab_auth_img makes to authenticate_image treats
the second 'offset' parameter as an image length.
Furthermore existing code requires the IVT head
Previous patches added IVT header verification steps. We shouldn't call
hab_rvt_entry() until we have done the basic header verification steps.
This patch changes the time we make the hab_rvt_entry() call so that it
only takes place if we are happy with the IVT header sanity checks.
Signed-off-by
There is no need to export these functions and data structures externally.
Make them all static now.
Signed-off-by: Bryan O'Donoghue
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Albert Aribaud
Cc: Sven Ebenfeld
Cc: George McCollister
Cc: Breno Matheus Lima
---
arch/arm/mach-imx/ha
Add a hab_rvt_check_target() step to authenticate_image() as a sanity
check for the target memory region authenticate_image() will run over,
prior to making the BootROM authentication callback itself.
This check is recommended by the HAB documentation so it makes sense to
adhere to the guidance an
The size of the IVT header should be defined in hab.h move it there now.
Signed-off-by: Bryan O'Donoghue
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Albert Aribaud
Cc: Sven Ebenfeld
Cc: George McCollister
Cc: Breno Matheus Lima
---
arch/arm/include/asm/mach-imx/hab.h | 2 ++
arch
Both usages of authenticate_image treat the result code as a simple binary.
The command line usage of authenticate_image directly returns the result
code of authenticate_image as a success/failure code.
Right now when calling hab_auth_img and test the result code in a shell a
passing hab_auth_img
The current flow of authenticate_image() will print the HAB event log even
if we reject an element of the IVT header before ever calling into the ROM.
This can be confusing.
This patch changes the flow of the code so that the HAB event log is only
printed out if we have called into the ROM and rec
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
Cc: Stefano B
This patch implements the basic callback hooks for hab_rvt_check_target()
for BootROM code using the older BootROM address layout - in my test case
the i.MX7. Code based on new BootROM callbacks will just have HAB_SUCCESS
as a result code. Adding support for the new BootROM callbacks is a TODO.
Si
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 hard-coded fixed CSF offset currently in
place.
Signed-off-by: Bryan O'Donoghue
Cc: Stefano Babic
Cc: Fabio Estev
The hab_rvt_check_target() callback according to the HABv4 documentation:
"This function reports whether or not a given target region is allowed for
either peripheral configuration or image loading in memory. It is intended
for use by post-ROM boot stage components, via the ROM Vector Table, in
authenticate_image returns 1 for success and 0 for failure. That result
code is mapped directly to the result code for the command line function
hab_auth_img - which means when hab_auth_img succeeds it is returning
CMD_RET_FAILURE (1) instead of CMD_RET_SUCCESS (0).
This patch fixes this behaviour
There is no need to export these functions and data structures externally.
Make them all static now.
Signed-off-by: Bryan O'Donoghue
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Albert Aribaud
Cc: Sven Ebenfeld
Cc: George McCollister
Cc: Breno Matheus Lima
---
arch/arm/mach-imx/ha
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
Cc: Stefano Babic
Cc: Fabio Estevam
Cc
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 to a
On Fri, Dec 29, 2017 at 10:04 AM, Andreas Färber wrote:
> Hi,
>
> Am 29.12.2017 um 16:52 schrieb Paul Kocialkowski:
>> Le vendredi 29 décembre 2017 à 08:16 -0600, Adam Ford a écrit :
>>> This converts the following to Kconfig:
>>>CONFIG_USB_MUSB_OMAP2PLUS
>>>CONFIG_USB_MUSB_AM35X
>>>CO
> On 29 Dec 2017, at 16:32, Adam Ford wrote:
>
> This converts the following to Kconfig:
> CONFIG_TWL4030_USB
> CONFIG_OMAP_USB_PHY
> CONFIG_ROCKCHIP_USB2_PHY
Please split this into three distinct commits, converting each of these
PHY changes in a separate patch. This will make life much
Hi,
Am 29.12.2017 um 16:52 schrieb Paul Kocialkowski:
> Le vendredi 29 décembre 2017 à 08:16 -0600, Adam Ford a écrit :
>> This converts the following to Kconfig:
>>CONFIG_USB_MUSB_OMAP2PLUS
>>CONFIG_USB_MUSB_AM35X
>>CONFIG_USB_MUSB_DSPS
>>CONFIG_USB_MUSB_PIO_ONLY
>
> Thanks for m
On 29/12/17 16:42, Breno Matheus Lima wrote:
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
On 29/12/17 16:36, Breno Matheus Lima wrote:
Secure boot enabled
HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found!
=>
In this situation the "hab_rvt_authenticate_image()" is not executed,
It's a bit confusing to receive a "No HAB Events Found!" message after
running hab_auth_img
Add HS200 timing setting and the MMC tuning callback.
Signed-off-by: Masahiro Yamada
---
drivers/mmc/sdhci-cadence.c | 87 -
1 file changed, 78 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
index
This series can be cleanly applied to u-boot-mmc/next.
I really hope the HS200 support will be pulled in the next MW.
Masahiro Yamada (8):
dm: add dev_read_u32()
mmc: do not overwrite cfg->f_max if "max-frequency" if missing
mmc: let mmc_of_parse() fail for insane bus-width value
mmc: s
This line overwrites host_cap that has been set by drivers and/or
helpers like mmc_of_parse(). Accumulate capabilities flags.
Signed-off-by: Masahiro Yamada
---
drivers/mmc/sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
ind
This driver is a counterpart from the one in Linux. Follow the
clean-up I did in Linux.
Signed-off-by: Masahiro Yamada
---
drivers/mmc/sdhci-cadence.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cade
dev_read_u32_default() always returns something even when the property
is missing. So, it is impossible to do nothing in the case. One
solution is to use ofnode_read_u32() instead, but adding dev_read_u32()
will be helpful.
BTW, Linux has an equvalent function, device_property_read_u32();
it is
This is needed to parse more capabilities such as mmc-hs200-1_8v.
Signed-off-by: Masahiro Yamada
---
drivers/mmc/sdhci-cadence.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
index 712b18c..921095b 100644
--- a/drivers/mmc/sdhc
You must fix your DT if it specifies insane bus-width, for example,
bus-width = <3>;
debug() is not displayed in usual configuration, so people will not
even notice weirdness. Use dev_err() instead, then let it fail.
Signed-off-by: Masahiro Yamada
---
drivers/mmc/mmc-uclass.c | 6 ++
1
During the tuning, drivers repeat data transfer, changing timing
parameters in the controller hardware. So, the tuning commands
(CMD19 for SD, CMD21 for eMMC) fail, and this is not a problem
at all.
Showing "Error detected..." in normal operation just make users
upset. This should not be shown.
mmc_of_parse() in U-Boot is a pussy helper; it sets cfg->f_max to
52MHz even if DT does not provide "max-frequency" at all. This can
overwrite cfg->f_max that may have been set to a reasonable default.
As the DT binding says, "max-frequency" is an optional property.
Do nothing if DT does not spec
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 no
This commit updates the configuration files needed to support OF_CONTROL
on the OMAP3 BeagleBoard(s).
---
board/ti/beagle/beagle.c | 11
configs/omap3_beagle_defconfig | 5 ++
include/configs/omap3_beagle.h | 145 +++--
3 files changed, 69 insertio
This commit adds OMAP3 BeagleBoard devicetree files from
Linux v4.15-rc5. This includes standard OMAP34XX board revisions as
well as the 'xM' which is OMAP36XX.
Signed-off-by: Derald D. Woods
---
arch/arm/dts/Makefile | 5 +
arch/arm/dts/omap3-beagle-u-boot.dtsi |
This series adds OF_CONTROL support for BeagleBoard and BeagleBoard-xM.
Devicetree files are taken from Linux v4.15-rc5.
Note that this is a follow-up to this previous patch series:
https://lists.denx.de/pipermail/u-boot/2017-December/314672.html
Tested using GCC 7.2.0 [--with-float=hard --with
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.
Hi Bryan,
2017-12-28 16:49 GMT-02:00 Bryan O'Donoghue :
> 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
Hi,
Le vendredi 29 décembre 2017 à 09:32 -0600, Adam Ford a écrit :
> This converts the following to Kconfig:
>CONFIG_TWL4030_USB
>CONFIG_OMAP_USB_PHY
>CONFIG_ROCKCHIP_USB2_PHY
Thanks for the effort!
See one comment below. Otherwise, looks good to me.
> Signed-off-by: Adam Ford
> -
Hi,
Le vendredi 29 décembre 2017 à 08:16 -0600, Adam Ford a écrit :
> This converts the following to Kconfig:
>CONFIG_USB_MUSB_OMAP2PLUS
>CONFIG_USB_MUSB_AM35X
>CONFIG_USB_MUSB_DSPS
>CONFIG_USB_MUSB_PIO_ONLY
Thanks for making the change! See more comments below for two minor
chang
This converts the following to Kconfig:
CONFIG_TWL4030_USB
CONFIG_OMAP_USB_PHY
CONFIG_ROCKCHIP_USB2_PHY
Signed-off-by: Adam Ford
---
configs/am43xx_evm_defconfig | 1 +
configs/am43xx_evm_ethboot_defconfig | 1 +
configs/am43xx_evm_qspiboot_defconfig | 1 +
conf
This converts the following to Kconfig:
CONFIG_USB_MUSB_OMAP2PLUS
CONFIG_USB_MUSB_AM35X
CONFIG_USB_MUSB_DSPS
CONFIG_USB_MUSB_PIO_ONLY
Signed-off-by: Adam Ford
---
Changes to V2: Add AM35X and DSPS.
Make CONFIG_USB_MUSB_PIO_ONLY enabled when
USB_MUSB_PIC32, USB_MUSB_O
This converts the following to Kconfig:
CONFIG_USB_MUSB_HCD
CONFIG_USB_MUSB_UDC
CONFIG_USB_DAVINCI
CONFIG_USB_OMAP3
CONFIG_USB_DA8XX
CONFIG_USB_AM35X
Signed-off-by: Adam Ford
---
configs/am3517_crane_defconfig| 2 ++
configs/cm_t35_defconfig | 2 ++
configs/duove
Linux bindings have been introduced in the code (removing the U-Boot
specific ones) without documentation update. Compatible string has
changed, as well as the four GPIO properties. Reflect this by updating
the soft-spi.txt documentation.
Fixes: 102412c415 ("dm: spi: soft_spi: switch to use linux
Armada pinctrl drivers shall not be compiled without the entire pinctrl
framework and thus lack a "depends on" condition, otherwise the driver
will simply not be probed.
Signed-off-by: Miquel Raynal
---
drivers/pinctrl/mvebu/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Hi Jagan,
> -Original Message-
> From: Prabhakar Kushwaha [mailto:prabhakar.kushw...@nxp.com]
> Sent: Thursday, December 21, 2017 5:43 PM
> To: u-boot@lists.denx.de
> Cc: jagannadh.t...@gmail.com; Poonam Aggrwal
> ; Suresh Gupta ;
> marek.va...@gmail.com; cyrille.pitc...@wedev4u.fr; Prabh
Hi Jagan:
2017-12-28 14:12 GMT+08:00 Jagan Teki :
> Some of the SPI device drivers at drivers/spi not a real
> spi controllers, Unlike normal/generic SPI controllers they
> operates only with SPI-NOR flash devices. these were technically
> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
Missed that mail :(
it's old board, I have no source code for that customized version of bootloader.
I have commands
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
NAND device: Man
On Wed, Dec 27, 2017 at 10:12 PM, Paul Kocialkowski wrote:
> Hi,
>
> Le mercredi 27 décembre 2017 à 20:09 -0600, Adam Ford a écrit :
>> This converts the following to Kconfig:
>>CONFIG_USB_MUSB_OMAP2PLUS
>>CONFIG_USB_MUSB_PIO_ONLY
>
> Thanks for the continued effort on omap platforms!
>
>
Hi Tom,
please pull from u-boot-imx, thanks! Series with patch causing warning:
Hannu Lounento (5):
net: e1000: add support for writing to EEPROM
is dropped from PR until issues will be fixed. This caused a rebasing of
my tree.
The following changes since commit 48a346061d1f0a7eff566f6a7
Hi Martyn,
On 08/11/2017 16:59, Martyn Welch wrote:
> This series improves the support on the bx50v3 devices (b540v3, b650v3 and
> b850v3) and utilising features recently added as part of the PPD
> implementation.
>
> NOTE: This series requires the PPD series:
> https://lists.denx.de/piperma
70 matches
Mail list logo
