Re: [U-Boot] [PATCH 2/2] image: fit: Show information about OS type in firwmare case too

[Jun Nie]

2018-03-26 22:31 GMT+08:00 Michal Simek :
> SPL ATF implementation requires FIT image with partitions where the one
> is Firmware/ATF and another one Firmware/U-Boot. OS field is used for
> recording that difference that's why make sense to show values there for
> Firmware types.
>
> For example:
>  Image 0 (atf)
>   Description:  ATF bl31.bin
>   Created:  Mon Mar 26 15:58:14 2018
>   Type: Firmware
>   Compression:  uncompressed
>   Data Size:51152 Bytes = 49.95 KiB = 0.05 MiB
>   Architecture: ARM
>   OS:   ARM Trusted Firmware
>   Load Address: 0xfffe
>   Hash algo:md5
>   Hash value:   36a4212bbb698126bf5a248f0f4b5336
>  Image 1 (uboot)
>   Description:  u-boot.bin
>   Created:  Mon Mar 26 15:58:14 2018
>   Type: Firmware
>   Compression:  uncompressed
>   Data Size:761216 Bytes = 743.38 KiB = 0.73 MiB
>   Architecture: ARM
>   OS:   U-Boot
>   Load Address: 0x0800
>   Hash algo:md5
>   Hash value:   f22960fe429be72296dc8dc59a47d566
>
> Signed-off-by: Michal Simek 
> ---
>
Reviewed-by: Jun Nie 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Alex Kiernan]

On Mon, Apr 2, 2018 at 12:13 PM, Felix Brack  wrote:
> Hi Alex,
>
> On 01.04.2018 11:22, Alex Kiernan wrote:
>> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
>>
>> Signed-off-by: Alex Kiernan 
>> Acked-by: Joe Hershberger 
>> ---
>>
>> Changes in v2:
>> - Move DRIVER_TI_CPSW outside of the NETDEVICES guard
>> - Don't mark DRIVER_TI_CPSW default if ARCH_OMAP2PLUS to fix mistranslations
>>   by moveconfig
>>
>
> [..]
>
>> diff --git a/configs/am335x_pdu001_defconfig 
>> b/configs/am335x_pdu001_defconfig
>> index cb75ec0..87ae88c 100644
>> --- a/configs/am335x_pdu001_defconfig
>> +++ b/configs/am335x_pdu001_defconfig
>> @@ -9,13 +9,13 @@ CONFIG_SPL_SERIAL_SUPPORT=y
>>  CONFIG_SPL_LIBDISK_SUPPORT=y
>>  # CONFIG_SPL_NAND_SUPPORT is not set
>>  CONFIG_SPL_WATCHDOG_SUPPORT=y
>> +CONFIG_SPL=y
>>  CONFIG_SPL_FAT_SUPPORT=y
>>  CONFIG_DEFAULT_DEVICE_TREE="am335x-pdu001"
>>  CONFIG_LOCALVERSION="-EETS-1.0.0"
>>  CONFIG_DISTRO_DEFAULTS=y
>>  CONFIG_BOOTDELAY=1
>>  # CONFIG_USE_BOOTCOMMAND is not set
>> -CONFIG_SPL=y
>>  # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
>>  CONFIG_SPL_I2C_SUPPORT=y
>>  CONFIG_SPL_YMODEM_SUPPORT=y
>> @@ -39,6 +39,7 @@ CONFIG_DM_GPIO=y
>>  CONFIG_DM_I2C=y
>>  CONFIG_MMC_OMAP_HS=y
>>  CONFIG_MMC_SDHCI=y
>> +CONFIG_DRIVER_TI_CPSW=y
>
> Applying this patch series generates the following warning while
> creating the default configuration for board PDU001:
>
> warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
> BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS && DRIVER_TI_CPSW &&
> AG7XXX && ALTERA_TSE && BCM_SF2_ETH && DWC_ETH_QOS && ETH_DESIGNWARE &&
> MVNETA && MVPP2 && MACB && PCH_GBE && SUN4I_EMAC && SUN8I_EMAC &&
> SH_ETHER && XILINX_AXIEMAC && XILINX_EMACLITE && ZYNQ_GEM && PIC32_ETH
> && RENESAS_RAVB) selects PHYLIB which has unmet direct dependencies (NET)
>
> This is due to the patch enabling CONFIG_DRIVER_TI_CPSW while leaving
> CONFIG_NET disabled.
> This board does not require/have network support for U-Boot so there is
> no need or benefit activating CONFIG_DRIVER_TI_CPSW here. Leaving the
> file configs/am355x_pdu001_defconfig without any modifications will make
> your patch work properly and result in a clean, warning and error free,
> build for the PDU001 board.
>
>>  CONFIG_PINCTRL=y
>>  CONFIG_PINCTRL_SINGLE=y
>>  CONFIG_DM_PMIC=y
>

Oh bother, thanks for trying it. I think in fixing the opposite
problem from v1 I've missed a depends on NET. Is your board covered by
the Travis tests as I did push v2 and got a green build?

Unfortunately my laptop decided to die overnight and I'm away from the
office for a couple of weeks so I'll have to pick it up when I'm back.

Alex

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

Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[Jagan Teki]

Hi Andre,

On Thu, Mar 29, 2018 at 2:49 PM, Andre Przywara  wrote:
> Hi,
>
> On 29/03/18 09:51, Jagan Teki wrote:
>> Hi Andre,
>>
>> On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara  
>> wrote:
>>> A minor update to the v3 version sent earlier this month.
>>> I reworked patch 09 to drop the direct MMC environment for 32-bit Allwinner
>>> boards as well and keep the current MMC offset.
>>> For now I also dropped the two patches changing (back) the MMC regulator.
>>> I still believe they are good to have and keep them as U-Boot specific
>>> .dtsi files in my tree, possibly posting them later again.
>>>
>>> As the previous version, this combines the EMAC DT support update with
>>> an update of the full Linux kernel DTs for all H3, H5 and A64 boards.
>>>
>>> Patch 01 leaves some hint in the README how to avoid the situation
>>> when overrunning U-Boot's image size on 64-bit boards.
>>> The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
>>> EMAC driver for using the new DT binding used in Linux, also updates
>>> the DTs to the new EMAC DT node already.
>>>
>>> Changes to sync the whole of U-Boot's DT files for the H3, H5 and A64 SoCs
>>> to those from Linux are in the following patches. However this first 
>>> requires
>>> lifting the space limit we currently have due to the raw MMC environment.
>>> Patch 09 disables that for all sunxi boards, to give us finally some
>>> space. Patches 10 and 11 consequently revert the disabling of features we
>>> saw a few weeks ago to migitate the size problem.
>>>
>>> Patches 12-19 then bring in the Linux DTs, split by SoCs, with the .dtsi
>>> files first, then the board files.
>>>
>>> Merging the H3 and H5 device tree files brings in significant changes,
>>> also to the structure of the .dtsi files. However U-Boot's own DT usage
>>> is pretty limited, so it doesn't matter.
>>>
>>> The huge benefit of syncing the DTs is that we can use U-Boot's DT copy
>>> to directly pass it to the kernel, avoiding to actually load a .dtb file
>>> from somewhere. To allows seamless and automatic UEFI booting, so
>>> distribution installer images should just work (TM).
>>>
>>> As a goodie the final patch brings in the actual SoPine + baseboard DT
>>> files, which we were completely missing so far.
>>>
>>> This is based on sunxi/master (2d53018a0ef2).
>>>
>>> Cheers,
>>> Andre.
>>>
>>> Changelog v3 .. v4:
>>> - remove MMC environment for all Allwinner boards (including 32 bit ones)
>>> - keep MMC environment offset to the old values
>>> - drop DT adjustments to use fixed MMC regulator
>>>
>>> Changelog v2 .. v3:
>>> 01: added, was on the list before
>>> 02: drop redundant H5 line
>>> 03-08: unchanged
>>> 09-20: added
>>>
>>> Changelog v1 .. v2:
>>> 01, 02, 03: unchanged
>>> 04, 05, 06, 07: added
>>>
>>> Andre Przywara (19):
>>>   sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted
>>> Firmware
>>>   sunxi: gpio: add missing compatible strings
>>>   net: sun8i-emac: support new pinctrl DT bindings
>>>   net: sun8i-emac: add support for new EMAC DT binding
>>>   arm: dts: sunxi: update A64 to new EMAC binding
>>>   arm: dts: sunxi: update H3 to new EMAC binding
>>>   arm: dts: sunxi: update H5 to new EMAC binding
>>>   net: sun8i-emac: remove support for old binding
>>>   sunxi: disable direct MMC environment
>>>   sunxi: revert disabling of features
>>>   Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT"
>>>   sunxi: DT: A64: update device tree file for Allwinner A64 SoC
>>>   sunxi: DT: A64: update board .dts files from Linux
>>>   sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs
>>>   sunxi: DT: H5: update board .dts files from Linux
>>>   sunxi: DT: H3: update board .dts files from Linux
>>>   sunxi: DT: H3: update libre-cc board .dts file
>>>   sunxi: DT: H2+: update Opi-zero .dts
>>>   sunxi: DT: A64: add proper SoPine baseboard device tree
>>
>> I agree that we have space for now with U-Boot proper since we removed
>> MMC raw, but why we need to Sync all the dts nodes from Linux?
>
> The main reason for me is to allow passing U-Boot's DT to Linux - or any
> other OS, for that matter. This happens already automatically with the
> distro defaults UEFI boot: just put in an UEFI enabled USB pen drive
> (distro installers) and U-Boot will boot from there - without any user
> interaction or special boot script, without the OS providing any DTs.
>
> Conceptually there is only one DT for each board. The fact that U-Boot
> has deviated has no technical reason, it's just not being updated.
>
>> it is costing some space right?
>
> We don't care about this so much anymore. For practical reasons it would
> be good to stay below 984KB (from after the SPL till 1MB, where the
> first partition normally starts). Adding like 10 KB to the image size is
> nothing in there, especially when looking at the benefits - automatic
> boot of any OS.
>
>> becuase
>> - most of the nodes doesn't 

[U-Boot] [PATCH] Makefile: Disable stack-usage check for ARC

[Alexey Brodkin]

With the most recent tools for ARC (arc-2017.09) in case of
"naked" function compiler throws a warning:
-->8-
board/synopsys/hsdk/hsdk.c: In function 'hsdk_core_init_f':
board/synopsys/hsdk/hsdk.c:345:1: warning: stack usage computation not 
supported for this target
 }
 ^
-->8-

That happens because the compiler doesn't handle "naked" functions
as a special case where stack calculation shouldn't be done.

But for now until this is fixed in GCC to get clean buildman output
we're disabling stack-usage check for ARC.

See https://lists.denx.de/pipermail/u-boot/2018-April/324455.html
for more background.

Signed-off-by: Alexey Brodkin 
Cc: Masahiro Yamada 
Cc: Tom Rini 
---
 Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/Makefile b/Makefile
index 5fa14789d99f..c80b902afdce 100644
--- a/Makefile
+++ b/Makefile
@@ -600,9 +600,13 @@ KBUILD_CFLAGS  += -g
 KBUILD_AFLAGS  += -g
 
 # Report stack usage if supported
+# ARC tools based on GCC 7.1 has an issue with stack usage
+# with naked functions, see commit message for more details
+ifndef CONFIG_ARC
 ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-stack-usage.sh $(CC)),y)
KBUILD_CFLAGS += -fstack-usage
 endif
+endif
 
 KBUILD_CFLAGS += $(call cc-option,-Wno-format-nonliteral)
 
-- 
2.14.3

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

Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Jagan Teki]

On Mon, Apr 2, 2018 at 7:13 AM, André Przywara  wrote:
> Hi,
>
> On 01/04/18 14:19, Tom Rini wrote:
>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
>>> On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
 Hi Tom,

 On 7 August 2017 at 09:39, Tom Rini  wrote:
> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>
>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
>> code, with #ifdefs and different code paths. We should try to move over 
>> to
>> this soon so we can drop the old code.
>>>
>>> I hope this will applicable to SPL too?
>>>
>>> If so, we are having SPL size issues with few Allwinner families, if
>>> enable SPL_DM any suggestions?
>>
>> How close, and have you looked at the u-boot-spl.map to see what you can
>> maybe trim?  Or areas to look at reducing in code complexity?
>
> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
> and picked most low hanging fruits already.
> So far we discussed several mitigations, but mostly to cover the
> "natural" SPL code size grow over time:
> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
> padding (for a 2KB architectural alignment). Given that the vectors are
> used only for debugging purposes, we could scrap them entirely or
> construct them on the fly in some other SRAM. So would free about 2.5KB,
> ideally. Lowest hanging fruit so far.
> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
> encoding. This reduces the size significantly, to about 20KB. The
> disadvantage is using a second cross-compiler or even a additional
> cross-compiler for native builds, complicating the build process.
> I maintain a branch for enabling FEL booting here [1], which provides
> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
> There are no technical disadvantages in running the SPL in 32-bit, so
> this is mostly a build issue.

May be this can be a good option and it has verified with board. As
Simon pointed tegra for this matter about building two arch's I think
we can try this out. I made some know change in arm/Makefile but
unable to export armv7 and armv8 compilers so-that build can pick
based on SPL and U-Boot?

--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -24,6 +24,8 @@ arch-$(CONFIG_ARM64)  =-march=armv8-a
 # but otherwise we can use the value in CONFIG_SYS_ARM_ARCH
 ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TEGRA),yy)
 arch-y += -D__LINUX_ARM_ARCH__=4
+else ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_MACH_SUN50I),yy)
+arch-y += -D__LINUX_ARM_ARCH__=7
 else
 arch-y += -D__LINUX_ARM_ARCH__=$(CONFIG_SYS_ARM_ARCH)
 endif

> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
> size and sizeof(long) to be 32-bit and should help, though I haven't
> been able to successfully compile it yet (relocation types problems).
> Despite lacking mainline support for AArch64 ILP32 in Linux and
> glibc(?), GCC supports it for quite a while already. Unknown saving effect.
> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
> the 32KB, so we could leverage this. Siarhei knows more about this.
> 5) Use a TPL. Haven't looked at this in detail yet.

I think it's difficult to implement TPL here because, we should
require same SPL code for TPL like cpu, clock, DRAM and MMC(for boot
mode) butif we have a way to return from BootROM once TPL loaded(like
rockchip does) so-that we can skip MMC code from TPL.

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

Re: [U-Boot] [U-Boot, 18/36] rockchip: rk3188: remove rockchip timer as sys timer

[Artturi Alm]

On Sun, Apr 01, 2018 at 10:21:50PM +0200, Philipp Tomsich wrote:
> > We use ARM arch timer instead.
> > 
> > Signed-off-by: Kever Yang 
> > ---
> > 
> >  include/configs/rk3188_common.h | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> 
> Acked-by: Philipp Tomsich 

fwiw., i don't believe rk3188(Cortex-A9) has the armv7 'arch timer'.
please do test before applying..

-Artturi

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

[U-Boot] Please pull ARC changes for 2018.05

[Alexey Brodkin]

Hi Tom,

The following changes since commit f3b623fa52ce5c67732ea2d789d5e21667e88db3:

  Merge git://git.denx.de/u-boot-marvell (2018-03-30 18:18:22 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-arc.git tags/arc-for-2018.05

for you to fetch changes up to f770b3ee1830a5fbd3b44cd051d9e5468339d651:

  ARC: HSDK: Enable SPI flash support (2018-04-02 12:27:56 +0300)


More ARC changes and fixes for v2018.05

 * Update of ARC tools to the most recent arc-2017.09
 * Fix for compile-time warning for AXS10x
 * Add support of platform-specific commands for HSDK
 * Add support for on-board SPI flash on HSDK
   Note though that for write support another series [1]
   is required. I hope that Jagan will be able to review and
   act on SPI flash improvement series before we get beyond RC1.

   Also note that to get clean build for HSDK we need to disable
   stack-usage check [2] as our current GCC erroneously tries to calculate
   stack-usage on a naked function which leads to warning.

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=35796
[2] https://patchwork.ozlabs.org/patch/894139/


Alexey Brodkin (1):
  ARC: Bump ARC tools used in TravisCI to the most recent release 
arc-2017.09

Eugeniy Paltsev (3):
  ARC: AXS10x: DTS: Remove unused interrupt properties
  ARC: HSDK: Add platform-specific commands
  ARC: HSDK: Enable SPI flash support

 .travis.yml |6 +-
 arch/arc/dts/axs10x_mb.dtsi |5 -
 arch/arc/dts/hsdk.dts   |   56 +++
 board/synopsys/hsdk/MAINTAINERS |4 +-
 board/synopsys/hsdk/Makefile|2 +
 board/synopsys/hsdk/clk-lib.c   |   75 +
 board/synopsys/hsdk/clk-lib.h   |   38 +
 board/synopsys/hsdk/env-lib.c   |  302 ++
 board/synopsys/hsdk/env-lib.h   |   58 +++
 board/synopsys/hsdk/hsdk.c  | 1046
+++--
 configs/hsdk_defconfig  |   13 ++
 include/configs/hsdk.h  |   56 ++-
 12 files changed, 1602 insertions(+), 59 deletions(-)
 create mode 100644 board/synopsys/hsdk/clk-lib.c
 create mode 100644 board/synopsys/hsdk/clk-lib.h
 create mode 100644 board/synopsys/hsdk/env-lib.c
 create mode 100644 board/synopsys/hsdk/env-lib.h

Regards,
Alexey

P.S. It seems like Jagan is not very active so SPI changes we need
(mentioned in [1] above) won't make it through his repo.
Is there a chance to get that series merged in your tree directly?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[André Przywara]

On 02/04/18 08:40, Jagan Teki wrote:

Hi Jagan,

> On Thu, Mar 29, 2018 at 2:49 PM, Andre Przywara  
> wrote:
>> Hi,
>>
>> On 29/03/18 09:51, Jagan Teki wrote:
>>> Hi Andre,
>>>
>>> On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara  
>>> wrote:
 A minor update to the v3 version sent earlier this month.
 I reworked patch 09 to drop the direct MMC environment for 32-bit Allwinner
 boards as well and keep the current MMC offset.
 For now I also dropped the two patches changing (back) the MMC regulator.
 I still believe they are good to have and keep them as U-Boot specific
 .dtsi files in my tree, possibly posting them later again.

 As the previous version, this combines the EMAC DT support update with
 an update of the full Linux kernel DTs for all H3, H5 and A64 boards.

 Patch 01 leaves some hint in the README how to avoid the situation
 when overrunning U-Boot's image size on 64-bit boards.
 The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
 EMAC driver for using the new DT binding used in Linux, also updates
 the DTs to the new EMAC DT node already.

 Changes to sync the whole of U-Boot's DT files for the H3, H5 and A64 SoCs
 to those from Linux are in the following patches. However this first 
 requires
 lifting the space limit we currently have due to the raw MMC environment.
 Patch 09 disables that for all sunxi boards, to give us finally some
 space. Patches 10 and 11 consequently revert the disabling of features we
 saw a few weeks ago to migitate the size problem.

 Patches 12-19 then bring in the Linux DTs, split by SoCs, with the .dtsi
 files first, then the board files.

 Merging the H3 and H5 device tree files brings in significant changes,
 also to the structure of the .dtsi files. However U-Boot's own DT usage
 is pretty limited, so it doesn't matter.

 The huge benefit of syncing the DTs is that we can use U-Boot's DT copy
 to directly pass it to the kernel, avoiding to actually load a .dtb file
 from somewhere. To allows seamless and automatic UEFI booting, so
 distribution installer images should just work (TM).

 As a goodie the final patch brings in the actual SoPine + baseboard DT
 files, which we were completely missing so far.

 This is based on sunxi/master (2d53018a0ef2).

 Cheers,
 Andre.

 Changelog v3 .. v4:
 - remove MMC environment for all Allwinner boards (including 32 bit ones)
 - keep MMC environment offset to the old values
 - drop DT adjustments to use fixed MMC regulator

 Changelog v2 .. v3:
 01: added, was on the list before
 02: drop redundant H5 line
 03-08: unchanged
 09-20: added

 Changelog v1 .. v2:
 01, 02, 03: unchanged
 04, 05, 06, 07: added

 Andre Przywara (19):
   sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted
 Firmware
   sunxi: gpio: add missing compatible strings
   net: sun8i-emac: support new pinctrl DT bindings
   net: sun8i-emac: add support for new EMAC DT binding
   arm: dts: sunxi: update A64 to new EMAC binding
   arm: dts: sunxi: update H3 to new EMAC binding
   arm: dts: sunxi: update H5 to new EMAC binding
   net: sun8i-emac: remove support for old binding
   sunxi: disable direct MMC environment
   sunxi: revert disabling of features
   Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT"
   sunxi: DT: A64: update device tree file for Allwinner A64 SoC
   sunxi: DT: A64: update board .dts files from Linux
   sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs
   sunxi: DT: H5: update board .dts files from Linux
   sunxi: DT: H3: update board .dts files from Linux
   sunxi: DT: H3: update libre-cc board .dts file
   sunxi: DT: H2+: update Opi-zero .dts
   sunxi: DT: A64: add proper SoPine baseboard device tree
>>>
>>> I agree that we have space for now with U-Boot proper since we removed
>>> MMC raw, but why we need to Sync all the dts nodes from Linux?
>>
>> The main reason for me is to allow passing U-Boot's DT to Linux - or any
>> other OS, for that matter. This happens already automatically with the
>> distro defaults UEFI boot: just put in an UEFI enabled USB pen drive
>> (distro installers) and U-Boot will boot from there - without any user
>> interaction or special boot script, without the OS providing any DTs.
>>
>> Conceptually there is only one DT for each board. The fact that U-Boot
>> has deviated has no technical reason, it's just not being updated.
>>
>>> it is costing some space right?
>>
>> We don't care about this so much anymore. For practical reasons it would
>> be good to stay below 984KB (from after the SPL till 1MB, where the
>> first partition normally starts). Adding like 10 KB to the 

Re: [U-Boot] [PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Felix Brack]

Hi Alex,

On 01.04.2018 11:22, Alex Kiernan wrote:
> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
> 
> Signed-off-by: Alex Kiernan 
> Acked-by: Joe Hershberger 
> ---
> 
> Changes in v2:
> - Move DRIVER_TI_CPSW outside of the NETDEVICES guard
> - Don't mark DRIVER_TI_CPSW default if ARCH_OMAP2PLUS to fix mistranslations
>   by moveconfig
> 

[..]

> diff --git a/configs/am335x_pdu001_defconfig b/configs/am335x_pdu001_defconfig
> index cb75ec0..87ae88c 100644
> --- a/configs/am335x_pdu001_defconfig
> +++ b/configs/am335x_pdu001_defconfig
> @@ -9,13 +9,13 @@ CONFIG_SPL_SERIAL_SUPPORT=y
>  CONFIG_SPL_LIBDISK_SUPPORT=y
>  # CONFIG_SPL_NAND_SUPPORT is not set
>  CONFIG_SPL_WATCHDOG_SUPPORT=y
> +CONFIG_SPL=y
>  CONFIG_SPL_FAT_SUPPORT=y
>  CONFIG_DEFAULT_DEVICE_TREE="am335x-pdu001"
>  CONFIG_LOCALVERSION="-EETS-1.0.0"
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_BOOTDELAY=1
>  # CONFIG_USE_BOOTCOMMAND is not set
> -CONFIG_SPL=y
>  # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
>  CONFIG_SPL_I2C_SUPPORT=y
>  CONFIG_SPL_YMODEM_SUPPORT=y
> @@ -39,6 +39,7 @@ CONFIG_DM_GPIO=y
>  CONFIG_DM_I2C=y
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_MMC_SDHCI=y
> +CONFIG_DRIVER_TI_CPSW=y

Applying this patch series generates the following warning while
creating the default configuration for board PDU001:

warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS && DRIVER_TI_CPSW &&
AG7XXX && ALTERA_TSE && BCM_SF2_ETH && DWC_ETH_QOS && ETH_DESIGNWARE &&
MVNETA && MVPP2 && MACB && PCH_GBE && SUN4I_EMAC && SUN8I_EMAC &&
SH_ETHER && XILINX_AXIEMAC && XILINX_EMACLITE && ZYNQ_GEM && PIC32_ETH
&& RENESAS_RAVB) selects PHYLIB which has unmet direct dependencies (NET)

This is due to the patch enabling CONFIG_DRIVER_TI_CPSW while leaving
CONFIG_NET disabled.
This board does not require/have network support for U-Boot so there is
no need or benefit activating CONFIG_DRIVER_TI_CPSW here. Leaving the
file configs/am355x_pdu001_defconfig without any modifications will make
your patch work properly and result in a clean, warning and error free,
build for the PDU001 board.

>  CONFIG_PINCTRL=y
>  CONFIG_PINCTRL_SINGLE=y
>  CONFIG_DM_PMIC=y

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

Re: [U-Boot] [PATCH] vxworks: fixed cpu enable using PSCI on armv8

[Vasyl Vavrychuk]

Hi Bin,

On Sun, Apr 1, 2018 at 4:51 PM, Bin Meng  wrote:
>
> Why I mentioned the 'bootm' command, is that AFAIK the only official
> way of booting a VxWorks 7 ARM kernel is to use 'bootm'. Are you
> saying that 'bootm' command does not work on your Intel Stratix 10
> DevKit board? If that's the case, we have something to fix.
>
> Having said that, having 'bootvx' to support booting a 64-bit VxWorks
> 7 ARM kernel is a nice to have.
Yes, there is the same issue with bootm for ARMv8. It works but only
one CPU core is enabled.

>>>
>>> > +#if defined(CONFIG_ARM64) && defined(CONFIG_ARMV8_PSCI)
>>> > +   armv8_setup_psci();
>>> > +   smp_kick_all_cpus();
>>>
>>> What about ARMv8 32-bit?
>> Do you mean ARMv8 32-bit U-Boot or ARMv8 32-bit VxWorks under ARMv8
>> 64-bit U-Boot?
>>
>
> I meant to say ARMv8 32-bit U-Boot. I am not sure if 32-bit U-Boot can
> load a 64-bit VxWorks kernel..

Is ARMv8 32-bit U-Boot supported?

>
> I was trying to understand the reason of modifying this as I believe 'bootm'
> should work out of the box.
I will submit patch for bootm command in the next email.

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

Re: [U-Boot] [PATCH 1/2] image: fit: Show firmware configuration property if present

[Dr. Philipp Tomsich]

> On 26 Mar 2018, at 16:31, Michal Simek  wrote:
> 
> SPL ATF support requires to have firmware property which should be also
> listed by mkimage -l when images is created.
> 
> The patch is also using this macro in spl_fit to match keyword.
> 
> When image is created:
> Default Configuration: 'config'
> Configuration 0 (config)
>  Description:  ATF with full u-boot
>  Kernel:   unavailable
>  Firmware: atf
>  FDT:  dtb
> 
> Signed-off-by: Michal Simek 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[André Przywara]

On 02/04/18 13:47, Mark Kettenis wrote:

Hi,

>> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= 
>> Date: Mon, 2 Apr 2018 12:51:50 +0100
>>
>> On 02/04/18 12:20, Mark Kettenis wrote:
>>
>> 
>>
 This feature make U-Boot to have full Linux dts inside, Can't we
 implement automatic-boot-of-os distro to grab Linux dtb during
 commands stage like other distro does? Because this make few
 development struggles for U-Boot project like (few of the comments are
 repeated from previous mail, but I'm trying to group them all)
 - Unnecessary to maintain nodes which are not required for bootloader
 and which doesn't have proper dt drivers.
 - It becomes more patches for each-and-every sync.
 - We can compare the sync with Linux dt and simply apply on U-Boot
 which look not good to project growing.
 - Increase size(though it 10KB increase) it becomes unnecessary size
 from U-Boot point-of-view
>>>
>>> This is not just about booting Linux.  And even if it was, it means
>>> that you can only boot on hardware for which a full device tree is
>>> included in your distro.  So a new board that comes with a usable
>>> U-Boot in SPI flash still won't work since the right device tree isn't
>>> there.
>>
>> Ah right, I didn't even mention SPI flash in that thread. Thanks!
>>
>> Out of curiosity: what OS are you thinking about? Collecting trophies
>> here ;-) I tried the FreeBSD-current installer the other day, and it
>> worked pretty well.
> 
> OpenBSD.  ARMv8-wise, our support for Allwinner A64/H5 and Rockchip
> RK3399 is pretty decent these days and Rockchip RK3328 is coming along
> as well.

Ah, great! I didn't know that OpenBSD was that far.
Do you know of anything missing in the DT or UEFI support from mainline
U-Boot? I put firmware images on my Pine64 github repo[1] for A64 and H5
boards, which are based on 2018.03 plus this series, if you want to give
it a try.
Trying to wrap my around INSTALL.arm64, but you might be faster ;-)
Does 6.2 provide enough to work? Or shall I wait till the 15th?

>  And I'm working on Marvell 8040 support.  There is support
> for ARMv7 as well which includes many of the older Allwinner SoCs.
> We don't have the resources to build images for all the different
> boards that are out there though, which probably is the biggest
> stumbling block for getting OpenBSD to run.  Our bootloader is UEFI,

That sounds good!

> so with a recent enough U-Boot in flash the default install.fs image

Is that the FFS filesystem in the OpenBSD partition of miniroot.fs?
Which just contains the bsd.rd kernel + RAM fs?
The 6.2 directory didn't have an explicit install.fs image.

Cheers,
Andre

[1] https://github.com/apritzel/pine64/tree/master/images

> should just work.  It does on Rock64!  Otherwise you have to know the
> magic to write the U-Boot image at the right location into that image
> to make it boot.
> 
> Cheers,
> 
> Mark
> 

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

Re: [U-Boot] [PATCH 1/2] image: fit: Show firmware configuration property if present

[Jun Nie]

2018-03-26 22:31 GMT+08:00 Michal Simek :
> SPL ATF support requires to have firmware property which should be also
> listed by mkimage -l when images is created.
>
> The patch is also using this macro in spl_fit to match keyword.
>
> When image is created:
>  Default Configuration: 'config'
>  Configuration 0 (config)
>   Description:  ATF with full u-boot
>   Kernel:   unavailable
>   Firmware: atf
>   FDT:  dtb
>
> Signed-off-by: Michal Simek 
> ---
>
Reviewed-by: Jun Nie 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] efi_loader: completely initialize network

[Heinrich Schuchardt]

Add missing network initialization code.

Before the patch the network was only usable if a network command like
dhcp or tftp had beed executed.

This was visible when interrupting the console countdown and executing
bootefi selftest for vexpress_ca15_tc2_defconfig.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_net.c | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
index 8c5d5b492c..829d6fa43e 100644
--- a/lib/efi_loader/efi_net.c
+++ b/lib/efi_loader/efi_net.c
@@ -54,14 +54,46 @@ static efi_status_t EFIAPI efi_net_stop(struct 
efi_simple_network *this)
return EFI_EXIT(EFI_SUCCESS);
 }
 
+/*
+ * Initialize network adapter and allocate transmit and receive buffers.
+ *
+ * This function implements the Initialize service of the
+ * EFI_SIMPLE_NETWORK_PROTOCOL. See the Unified Extensible Firmware Interface
+ * (UEFI) specification for details.
+ *
+ * @this:  pointer to the protocol instance
+ * @extra_rx:  extra receive buffer to be allocated
+ * @extra_tx:  extra transmit buffer to be allocated
+ * @return:status code
+ */
 static efi_status_t EFIAPI efi_net_initialize(struct efi_simple_network *this,
  ulong extra_rx, ulong extra_tx)
 {
+   int ret;
+   efi_status_t r = EFI_SUCCESS;
+
EFI_ENTRY("%p, %lx, %lx", this, extra_rx, extra_tx);
 
-   eth_init();
+   if (!this) {
+   r = EFI_INVALID_PARAMETER;
+   goto error;
+   }
 
-   return EFI_EXIT(EFI_SUCCESS);
+   /* Setup packet buffers */
+   net_init();
+   /* Disable hardware and put it into the reset state */
+   eth_halt();
+   /* Set current device according to environment variables */
+   eth_set_current();
+   /* Get hardware ready for send and receive operations */
+   ret = eth_init();
+   if (ret < 0) {
+   eth_halt();
+   r = EFI_DEVICE_ERROR;
+   }
+
+error:
+   return EFI_EXIT(r);
 }
 
 static efi_status_t EFIAPI efi_net_reset(struct efi_simple_network *this,
-- 
2.16.2

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

Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[Mark Kettenis]

> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= 
> Date: Mon, 2 Apr 2018 12:51:50 +0100
> 
> On 02/04/18 12:20, Mark Kettenis wrote:
> 
> 
> 
> >> This feature make U-Boot to have full Linux dts inside, Can't we
> >> implement automatic-boot-of-os distro to grab Linux dtb during
> >> commands stage like other distro does? Because this make few
> >> development struggles for U-Boot project like (few of the comments are
> >> repeated from previous mail, but I'm trying to group them all)
> >> - Unnecessary to maintain nodes which are not required for bootloader
> >> and which doesn't have proper dt drivers.
> >> - It becomes more patches for each-and-every sync.
> >> - We can compare the sync with Linux dt and simply apply on U-Boot
> >> which look not good to project growing.
> >> - Increase size(though it 10KB increase) it becomes unnecessary size
> >> from U-Boot point-of-view
> > 
> > This is not just about booting Linux.  And even if it was, it means
> > that you can only boot on hardware for which a full device tree is
> > included in your distro.  So a new board that comes with a usable
> > U-Boot in SPI flash still won't work since the right device tree isn't
> > there.
> 
> Ah right, I didn't even mention SPI flash in that thread. Thanks!
> 
> Out of curiosity: what OS are you thinking about? Collecting trophies
> here ;-) I tried the FreeBSD-current installer the other day, and it
> worked pretty well.

OpenBSD.  ARMv8-wise, our support for Allwinner A64/H5 and Rockchip
RK3399 is pretty decent these days and Rockchip RK3328 is coming along
as well.  And I'm working on Marvell 8040 support.  There is support
for ARMv7 as well which includes many of the older Allwinner SoCs.

We don't have the resources to build images for all the different
boards that are out there though, which probably is the biggest
stumbling block for getting OpenBSD to run.  Our bootloader is UEFI,
so with a recent enough U-Boot in flash the default install.fs image
should just work.  It does on Rock64!  Otherwise you have to know the
magic to write the U-Boot image at the right location into that image
to make it boot.

Cheers,

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

Re: [U-Boot] [PATCH v3 14/14] log: Add documentation

[Simon Glass]

Hi Lukasz,

On 21 November 2017 at 18:19, Lukasz Majewski  wrote:
> On Mon, 20 Nov 2017 15:33:35 -0700
> Simon Glass  wrote:
>
>> Add documentation for the log system.
>>
>> Signed-off-by: Simon Glass 
>> Reviewed-by: Bin Meng 
>> ---
>>
>> Changes in v3:
>> - Rebase to master
>>
>> Changes in v2:
>> - Drop the special log() functions from the README
>>
>>  doc/README.log | 214
>> + 1 file
>> changed, 214 insertions(+) create mode 100644 doc/README.log

[..]

>> +Code size
>> +-
>> +
>> +Code size impact depends largely on what is enabled. The following
>> numbers are +for snow, which is a Thumb-2 board:
>> +
>> +This series: adds bss +20.0 data +4.0 rodata +4.0 text +44.0
>
> It would be more informative to add units (KiB, B).

OK I will send a patch for that.

>
>> +CONFIG_LOG: bss -52.0 data +92.0 rodata -635.0 text +1048.0
>> +CONFIG_LOG_MAX_LEVEL=7: bss +188.0 data +4.0 rodata +49183.0 text
>> +98124.0 +
>> +The last option turns every debug() statement into a logging call,
>> which +bloats the code hugely. The advantage is that it is then
>> possible to enable +all logging within U-Boot.
>> +

[..]

>
> As I said before - this is a great piece of SW.

Great, thanks!

>
> Reviewed-by: Lukasz Majewski 
>
> Best regards,
>
> Lukasz Majewski

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

[U-Boot] [PATCH] log: Add units to code-size stats in README.log

[Simon Glass]

Without the units these numbers are confusing. Add a comment about the
unit being 'bytes' and mention 'buildman' as the source.

Suggested-by: Lukasz Majewski 
Signed-off-by: Simon Glass 
---

 doc/README.log | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/README.log b/doc/README.log
index dc9e2deec5..2ee1b753bc 100644
--- a/doc/README.log
+++ b/doc/README.log
@@ -162,7 +162,8 @@ Code size
 -
 
 Code size impact depends largely on what is enabled. The following numbers are
-for snow, which is a Thumb-2 board:
+generated by 'buildman -S' for snow, which is a Thumb-2 board (all units in
+bytes):
 
 This series: adds bss +20.0 data +4.0 rodata +4.0 text +44.0
 CONFIG_LOG: bss -52.0 data +92.0 rodata -635.0 text +1048.0
-- 
2.17.0.rc1.321.gba9d0f2565-goog

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

[U-Boot] [RFC PATCH 2/2] zynq: Add support for loading secure images

[Siva Durga Prasad Paladugu]

This patch adds support to load secure images
secure image is an image which is authenticated
or encrypted or both autheticated and encrypted
image in xilinx boot image(BOOT.BIN) format. The
secure image has to be created using xilinx bootgen
tool.

Signed-off-by: Siva Durga Prasad Paladugu 
---
 board/xilinx/zynq/Kconfig|  12 +
 board/xilinx/zynq/Makefile   |   4 +
 board/xilinx/zynq/cmds.c | 602 +++
 include/u-boot/rsa-mod-exp.h |   4 +
 lib/rsa/rsa-mod-exp.c|  51 
 5 files changed, 673 insertions(+)
 create mode 100644 board/xilinx/zynq/cmds.c

diff --git a/board/xilinx/zynq/Kconfig b/board/xilinx/zynq/Kconfig
index f8f8a7f..54d71dc 100644
--- a/board/xilinx/zynq/Kconfig
+++ b/board/xilinx/zynq/Kconfig
@@ -11,4 +11,16 @@ config CMD_ZYNQ_AES
  Decrypts the encrypted image present in source address
  and places the decrypted image at destination address.

+config CMD_ZYNQ
+   bool "Enable ZynqMP specific commands"
+   default y
+   depends on CMD_ZYNQ_AES
+   help
+ Enable Zynq specific commands like "zynq rsa"
+ which is used for zynq secure image verification.
+ The secure image is a xilinx specific BOOT.BIN with
+ either authentication or encryption or both encryption
+ and authentication feature enabled while generating
+ BOOT.BIN using Xilinx bootgen tool.
+
 endif
diff --git a/board/xilinx/zynq/Makefile b/board/xilinx/zynq/Makefile
index 7de0212..07a5bc5 100644
--- a/board/xilinx/zynq/Makefile
+++ b/board/xilinx/zynq/Makefile
@@ -20,6 +20,10 @@ $(warning Put custom ps7_init_gpl.c/h to 
board/xilinx/zynq/custom_hw_platform/))
 endif
 endif

+ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_CMD_ZYNQ) += cmds.o
+endif
+
 obj-$(CONFIG_SPL_BUILD) += $(init-objs)

 # Suppress "warning: function declaration isn't a prototype"
diff --git a/board/xilinx/zynq/cmds.c b/board/xilinx/zynq/cmds.c
new file mode 100644
index 000..9365557
--- /dev/null
+++ b/board/xilinx/zynq/cmds.c
@@ -0,0 +1,602 @@
+/*
+ * Copyright (C) 2018 Xilinx, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define ZYNQ_IMAGE_PHDR_OFFSET 0x09C
+#define ZYNQ_IMAGE_FSBL_LEN_OFFSET 0x040
+
+#define ZYNQ_PART_HDR_CHKSUM_WORD_COUNT0x0F
+#define ZYNQ_PART_HDR_WORD_COUNT   0x10
+
+#define ZYNQ_EFUSE_RSA_ENABLE_MASK 0x400
+
+#define ZYNQ_ATTRIBUTE_PL_IMAGE_MASK   0x20
+#define ZYNQ_ATTRIBUTE_CHECKSUM_TYPE_MASK  0x7000
+#define ZYNQ_ATTRIBUTE_RSA_PRESENT_MASK0x8000
+#define ZYNQ_ATTRIBUTE_RSA_PART_OWNER_MASK 0x3
+
+#define ZYNQ_MAX_PARTITION_NUMBER  0xE
+
+#define ZYNQ_RSA_MODULAR_SIZE  256
+#define ZYNQ_RSA_MODULAR_EXT_SIZE  256
+#define ZYNQ_RSA_EXPO_SIZE 64
+#define ZYNQ_RSA_SPK_SIGNATURE_SIZE256
+#define ZYNQ_RSA_PARTITION_SIGNATURE_SIZE  256
+#define ZYNQ_RSA_SIGNATURE_SIZE0x6C0
+#define ZYNQ_RSA_HEADER_SIZE   4
+#define ZYNQ_RSA_MAGIC_WORD_SIZE   60
+#define ZYNQ_RSA_PART_OWNER_UBOOT  1
+#define ZYNQ_RSA_ALIGN_PPK_START   64
+
+#define WORD_LENGTH_SHIFT  2
+#define ZYNQ_MAXIMUM_IMAGE_WORD_LEN0x4000
+
+#define MD5_CHECKSUM_SIZE  16
+
+static u8 *ppkmodular;
+static u8 *ppkmodularex;
+static u32 ppkexp;
+
+struct partition_hdr {
+   u32 imagewordlen;   /* 0x0 */
+   u32 datawordlen;/* 0x4 */
+   u32 partitionwordlen;   /* 0x8 */
+   u32 loadaddr;   /* 0xC */
+   u32 execaddr;   /* 0x10 */
+   u32 partitionstart; /* 0x14 */
+   u32 partitionattr;  /* 0x18 */
+   u32 sectioncount;   /* 0x1C */
+   u32 checksumoffset; /* 0x20 */
+   u32 pads1[1];
+   u32 acoffset;   /* 0x28 */
+   u32 pads2[4];
+   u32 checksum;   /* 0x3C */
+};
+
+struct zynq_rsa_public_key {
+   uint len;   /* Length of modulus[] in number of u32 */
+   u32 n0inv;  /* -1 / modulus[0] mod 2^32 */
+   u32 *modulus;   /* modulus as little endian array */
+   u32 *rr;/* R^2 as little endian array */
+};
+
+struct partition_hdr part_hdr[ZYNQ_MAX_PARTITION_NUMBER];
+
+struct headerarray {
+   u32 fields[16];
+};
+
+struct zynq_rsa_public_key public_key;
+
+static u32 fsbl_len;
+
+/*
+ * Check whether the given partition is last partition or not
+ */
+static int zynq_islastpartition(struct headerarray *head)
+{
+   int index;
+
+   debug("%s\n", __func__);
+   if (head->fields[ZYNQ_PART_HDR_CHKSUM_WORD_COUNT] != 0x)
+   return -1;
+
+   for (index = 0; index < ZYNQ_PART_HDR_WORD_COUNT - 1; index++) {
+   if (head->fields[index] != 0x0)
+  

[U-Boot] [RFC PATCH 1/2] fpga: xilinx: zynq: Add support to decrypt images

[Siva Durga Prasad Paladugu]

This patch adds support to decrypt an encrypted bitstream
or image. This zynq aes command can either load decrypted
image back to DDR or it can load an encrypted bitsream to
PL directly by decrypting it. The image has to be encrypted
using xilinx bootgen tool and to get only the encrypted
image from tool use -split option while invoking bootgen.

Signed-off-by: Siva Durga Prasad Paladugu 
---
 arch/arm/Kconfig  |   1 +
 board/xilinx/zynq/Kconfig |  14 
 drivers/fpga/zynqpl.c | 158 ++
 include/zynqpl.h  |   5 ++
 4 files changed, 178 insertions(+)
 create mode 100644 board/xilinx/zynq/Kconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 068ea1e..e0cd1d8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1360,6 +1360,7 @@ source "board/toradex/colibri_pxa270/Kconfig"
 source "board/vscom/baltos/Kconfig"
 source "board/woodburn/Kconfig"
 source "board/work-microwave/work_92105/Kconfig"
+source "board/xilinx/zynq/Kconfig"
 source "board/xilinx/zynqmp/Kconfig"
 source "board/zipitz2/Kconfig"

diff --git a/board/xilinx/zynq/Kconfig b/board/xilinx/zynq/Kconfig
new file mode 100644
index 000..f8f8a7f
--- /dev/null
+++ b/board/xilinx/zynq/Kconfig
@@ -0,0 +1,14 @@
+# Copyright (c) 2018, Xilinx, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0
+
+if ARCH_ZYNQ
+
+config CMD_ZYNQ_AES
+   bool "Zynq AES"
+   default y
+   help
+ Decrypts the encrypted image present in source address
+ and places the decrypted image at destination address.
+
+endif
diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
index db9bd12..fcffc2d 100644
--- a/drivers/fpga/zynqpl.c
+++ b/drivers/fpga/zynqpl.c
@@ -18,6 +18,7 @@

 #define DEVCFG_CTRL_PCFG_PROG_B0x4000
 #define DEVCFG_CTRL_PCFG_AES_EFUSE_MASK0x1000
+#define DEVCFG_CTRL_PCAP_RATE_EN_MASK  0x0200
 #define DEVCFG_ISR_FATAL_ERROR_MASK0x00740040
 #define DEVCFG_ISR_ERROR_FLAGS_MASK0x00340840
 #define DEVCFG_ISR_RX_FIFO_OV  0x0004
@@ -498,3 +499,160 @@ struct xilinx_fpga_op zynq_op = {
.loadfs = zynq_loadfs,
 #endif
 };
+
+#ifdef CONFIG_CMD_ZYNQ_AES
+/*
+ * Load the encrypted image from src addr and decrypt the image and
+ * place it back the decrypted image into dstaddr.
+ */
+int zynq_decrypt_load(u32 srcaddr, u32 srclen, u32 dstaddr, u32 dstlen,
+ u8 bstype)
+{
+   u32 isr_status, ts;
+
+   if ((srcaddr < SZ_1M) || (dstaddr < SZ_1M)) {
+   printf("%s: src and dst addr should be > 1M\n",
+  __func__);
+   return FPGA_FAIL;
+   }
+
+   if (zynq_dma_xfer_init(bstype)) {
+   printf("%s: zynq_dma_xfer_init FAIL\n", __func__);
+   return FPGA_FAIL;
+   }
+
+   writel((readl(_base->ctrl) | DEVCFG_CTRL_PCAP_RATE_EN_MASK),
+  _base->ctrl);
+
+   debug("%s: Source = 0x%08X\n", __func__, (u32)srcaddr);
+   debug("%s: Size = %zu\n", __func__, srclen);
+
+   /* flush(clean & invalidate) d-cache range buf */
+   flush_dcache_range((u32)srcaddr, (u32)srcaddr +
+   roundup(srclen << 2, ARCH_DMA_MINALIGN));
+   /*
+* Flush destination address range only if image is not
+* bitstream.
+*/
+   if (bstype == BIT_NONE)
+   flush_dcache_range((u32)dstaddr, (u32)dstaddr +
+   roundup(dstlen << 2, ARCH_DMA_MINALIGN));
+
+   if (zynq_dma_transfer(srcaddr | 1, srclen, dstaddr | 1, dstlen))
+   return FPGA_FAIL;
+
+   if (bstype == BIT_FULL) {
+   isr_status = readl(_base->int_sts);
+   /* Check FPGA configuration completion */
+   ts = get_timer(0);
+   while (!(isr_status & DEVCFG_ISR_PCFG_DONE)) {
+   if (get_timer(ts) > CONFIG_SYS_FPGA_WAIT) {
+   printf("%s: Timeout wait for FPGA to config\n",
+  __func__);
+   return FPGA_FAIL;
+   }
+   isr_status = readl(_base->int_sts);
+   }
+
+   printf("%s: FPGA config done\n", __func__);
+
+   if (bstype != BIT_PARTIAL)
+   zynq_slcr_devcfg_enable();
+   }
+
+   return FPGA_SUCCESS;
+}
+
+static int do_zynq_decrypt_image(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+   char *endp;
+   u32 srcaddr;
+   u32 srclen;
+   u32 dstaddr;
+   u32 dstlen;
+   u8 imgtype = BIT_NONE;
+   int status;
+   u8 i = 1;
+
+   if (argc < 4 && argc > 5)
+   goto usage;
+
+   if (argc == 4) {
+   if (!strcmp("load", argv[i]))
+   imgtype = BIT_FULL;
+   else if (!strcmp("loadp", argv[i]))
+   imgtype = BIT_PARTIAL;
+

Re: [U-Boot] [PATCH] tools: buildman: prevent trying to use the working directory as build dorectory

[Simon Glass]

Hi Lothar,

On 14 July 2017 at 14:57, Lothar Waßmann  wrote:
> Hi,
>
> On Thu, 13 Jul 2017 13:09:58 -0600 Simon Glass wrote:
>> On 5 July 2017 at 01:34, Lothar Waßmann  wrote:
>> > When the U-Boot base directory happens to have the same name as the
>> > branch that buildman is directed to use via the '-b' option and no
>> > output directory is specified with '-o', buildman happily starts
>> > removing the whole U-Boot sources eventually only stopped with the
>> > error message:
>> > OSError: [Errno 20] Not a directory: '..//boards.cfg
>> >
>> > Add a check to the builderthread.Mkdir function to verify that the
>> > path it tries to create does not match the current working
>> > directory.
>> >
>> > Signed-off-by: Lothar Waßmann 
>> > ---
>> >  tools/buildman/builderthread.py | 4 
>> >  1 file changed, 4 insertions(+)
>>
>> That's nasty, thanks for the fix.
>>
>> But this is being done inside each thread so I'm not sure how this
>> will be reported, or whether buildman will stop correctly.
>>
>> Can the check happen before the build even starts, perhaps? E,g, in 
>> builder.py?
>>
> I don't have the time to look deeper into this, perhaps someone more
> involved with the builman scripts can have a look into this.

OK, I've updated this patch. In general my advice is to assume that no
one else has time either :-)

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

Re: [U-Boot] [U-Boot, 18/36] rockchip: rk3188: remove rockchip timer as sys timer

[Dr. Philipp Tomsich]

Arturri,

> On 2 Apr 2018, at 11:38, Artturi Alm  wrote:
> 
> On Sun, Apr 01, 2018 at 10:21:50PM +0200, Philipp Tomsich wrote:
>>> We use ARM arch timer instead.
>>> 
>>> Signed-off-by: Kever Yang 
>>> ---
>>> 
>>> include/configs/rk3188_common.h | 3 ---
>>> 1 file changed, 3 deletions(-)
>>> 
>> 
>> Acked-by: Philipp Tomsich 
> 
> fwiw., i don't believe rk3188(Cortex-A9) has the armv7 'arch timer'.
> please do test before applying..

I won’t be able to test this one (and a number other ones), as I only
have access to RK3399 and RK3368 boards.

Feel free to validate this on your end and comment on this patch.

This patch set is not on my list for the current release cycle, due to
it affecting all boards and the associated test effort needed.  I am
considering either for a ‘next’-branch or for a topic-branch to be
created later in this cycle (e.g. branched off rc2?).

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

Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[Mark Kettenis]

> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de
> X-Spam-Level: 
> X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_BLOCKED,
>   RCVD_IN_MSPIKE_H2,T_DKIM_INVALID autolearn=unavailable 
> autolearn_force=no
>   version=3.4.0
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>  d=amarulasolutions.com; s=google;
>  h=mime-version:in-reply-to:references:from:date:message-id:subject:to
>  :cc; bh=YkmnJ4f8gswV/zdKXGgZZi3cOHA/u5TzVeZb8Z/ynV8=;
>  b=Ka9rvIk1fRVYG7dk1LcAKGpptBUy0Lslma6br3u86kHyhqUWX4jrejwIxeyarUX55j
>  b5Eg/WB42EXQy+YevPQExPVg6lotXw/MIW29Mlpfz0jx/rMaggmlQgBysrcrRIhXuF6G
>  jPwbxSSC+5SdpmqITMoZ/SfNw5yvm+bDtF+Ng=
> X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>  d=1e100.net; s=20161025;
>  h=x-gm-message-state:mime-version:in-reply-to:references:from:date
>  :message-id:subject:to:cc;
>  bh=YkmnJ4f8gswV/zdKXGgZZi3cOHA/u5TzVeZb8Z/ynV8=;
>  b=UPnApuQQyEN/WUPFWWQrdu5FftMAfdDazgVyVN2S2iC0pH/axqntMeuqQuw4jh0vYw
>  nrPiq2C782iEL9G6pQFkQvd6TFfDWwOHEFKI2qDFh+jvevI1PqbczszK848UesC0Ffhu
>  1EyJs8EyNo+1INdrF+VoXydce9YGE3+1y/QQZqIzdP8bVQPGOMO35D+COkScUL5XM3db
>  ReT+WTNMJTWFtXn2bitNbmNJ2T+VljWu8Mrfdynko6X/enwxn5PG60fGT+O1CxaQm5Wi
>  rq6LdlzlkpBvHuKnsh4GXg5C0TEkcCbSmGJUCFe2GyreN1GuIdUx5+VL/Ed28o9XXUuz
>  j5Aw==
> X-Gm-Message-State: ALQs6tCUT9TZd8LpHLCq6AdaTP3iaKD4jfo6CI02WEkLZXWz3Dbn7XLI
>  ErHktqFhgHBKqVEkoeQ5pFJtGVHcKPQAV9qFuRSNMQ==
> X-Google-Smtp-Source: 
> AIpwx48S4/pROvhPMN3NiY9jiXuePYKxMegMCj2pjibZUFA9w1Eq9C1Wvb82pWzc5krxAWkki5uYN2yvs3AQprOF/O0=
> X-Received: by 10.107.200.204 with SMTP id 
> y195mr7833975iof.252.1522654806745; 
>  Mon, 02 Apr 2018 00:40:06 -0700 (PDT)
> From: Jagan Teki 
> Date: Mon, 2 Apr 2018 13:10:06 +0530
> Cc: Maxime Ripard ,
> U-Boot-Denx ,
> linux-sunxi ,
> Jagan Teki 
> X-Former-Content-Transfer-Encoding: base64
> Sender: "U-Boot" 
> X-XS4ALL-DNSBL-Checked: mxdrop304.xs4all.net checked 81.169.180.215 against 
> DNS blacklists
> X-CNFS-Analysis: v=2.3 cv=T56iscCQ c=1 sm=0 tr=0
>  a=ONADgqKa62I6zSSZ3CeWOA==:117 a=ONADgqKa62I6zSSZ3CeWOA==:17
>  a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Kd1tUaAdevIA:10 a=-uNXE31MpBQA:10
>  a=jJxKW8Ag-pUA:10 a=7CQSdrXT:8 a=YfCOm-Dy:8 a=bhBFqEExS3OXt8833KMA:9
>  a=vhG5JYZ5BD7PDyiA:21 a=QEXdDO2ut3YA:10 a=a-qgeE7W1pNrGK8U0ZQC:22
>  a=zQLMK8awuJ6_Hvp-_9Ux:22
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: -0.4 () DKIM_SIGNED, RP_MATCHES_RCVD, T_DKIM_INVALID,
>   T_HEADER_FROM_DIFFERENT_DOMAINS
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kette...@xs4all.nl
> 
> Hi Andre,
> 
> On Thu, Mar 29, 2018 at 2:49 PM, Andre Przywara  
> wrote:
> > Hi,
> >
> > On 29/03/18 09:51, Jagan Teki wrote:
> >> Hi Andre,
> >>
> >> On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara  
> >> wrote:
> >>> A minor update to the v3 version sent earlier this month.
> >>> I reworked patch 09 to drop the direct MMC environment for 32-bit 
> >>> Allwinner
> >>> boards as well and keep the current MMC offset.
> >>> For now I also dropped the two patches changing (back) the MMC regulator.
> >>> I still believe they are good to have and keep them as U-Boot specific
> >>> .dtsi files in my tree, possibly posting them later again.
> >>>
> >>> As the previous version, this combines the EMAC DT support update with
> >>> an update of the full Linux kernel DTs for all H3, H5 and A64 boards.
> >>>
> >>> Patch 01 leaves some hint in the README how to avoid the situation
> >>> when overrunning U-Boot's image size on 64-bit boards.
> >>> The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
> >>> EMAC driver for using the new DT binding used in Linux, also updates
> >>> the DTs to the new EMAC DT node already.
> >>>
> >>> Changes to sync the whole of U-Boot's DT files for the H3, H5 and A64 SoCs
> >>> to those from Linux are in the following patches. However this first 
> >>> requires
> >>> lifting the space limit we currently have due to the raw MMC environment.
> >>> Patch 09 disables that for all sunxi boards, to give us finally some
> >>> space. Patches 10 and 11 consequently revert the disabling of features we
> >>> saw a few weeks ago to migitate the size problem.
> >>>
> >>> Patches 12-19 then bring in the Linux DTs, split by SoCs, with the .dtsi
> >>> files first, then the board files.
> >>>
> >>> Merging the H3 and H5 device tree files brings in significant changes,
> >>> also to the structure of the .dtsi files. However U-Boot's own DT usage
> >>> is pretty limited, so it doesn't matter.
> >>>
> >>> The huge benefit of syncing the DTs is that we can use U-Boot's DT copy
> >>> to directly pass it to the kernel, avoiding to actually load a .dtb file
> >>> from somewhere. To allows seamless and automatic UEFI booting, so
> >>> distribution installer images 

[U-Boot] [PATCH v2] tools: buildman: Don't use the working dir as build dir

[Simon Glass]

From: Lothar Waßmann 

When the U-Boot base directory happens to have the same name as the branch
that buildman is directed to use via the '-b' option and no output
directory is specified with '-o', buildman happily starts removing the
whole U-Boot sources eventually only stopped with the error message:

OSError: [Errno 20] Not a directory: '..//boards.cfg

Add a check to avoid this and also deal with the case where '-o' points
to the source directory, or any subdirectory of it.

Finally, tidy up the confusing logic for removing the old tree when using
-b. This is only done when building a branch.

Signed-off-by: Lothar Waßmann 
Signed-off-by: Simon Glass 
---

Changes in v2:
- Updated to check directories on start-up as per comments on v1 patch
- Added a test
- Expanded check to handle subdirectories

 tools/buildman/builderthread.py |  4 
 tools/buildman/control.py   | 28 +---
 tools/buildman/func_test.py |  9 +
 3 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index 9ac101a5a4..16a3fa452d 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -7,6 +7,7 @@ import errno
 import glob
 import os
 import shutil
+import sys
 import threading
 
 import command
@@ -27,6 +28,9 @@ def Mkdir(dirname, parents = False):
 os.mkdir(dirname)
 except OSError as err:
 if err.errno == errno.EEXIST:
+if os.path.realpath('.') == os.path.realpath(dirname):
+print "Cannot create the current working directory '%s'!" % 
dirname
+sys.exit(1)
 pass
 else:
 raise
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 3cac9f7cf6..5bf128357d 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -81,6 +81,28 @@ def ShowActions(series, why_selected, boards_selected, 
builder, options):
 print ('Total boards to build for each commit: %d\n' %
 len(why_selected['all']))
 
+def CheckOutputDir(output_dir):
+"""Make sure that the output directory is not within the current directory
+
+If we try to use an output directory which is within the current directory
+(which is assumed to hold the U-Boot source) we may end up deleting the
+U-Boot source code. Detect this and print an error in this case.
+
+Args:
+output_dir: Output directory path to check
+"""
+path = os.path.realpath(output_dir)
+cwd_path = os.path.realpath('.')
+while True:
+if os.path.realpath(path) == cwd_path:
+Print("Cannot use output directory '%s' since it is within the "
+  "current directtory '%s'" % (path, cwd_path))
+sys.exit(1)
+parent = os.path.dirname(path)
+if parent == path:
+break
+path = parent
+
 def DoBuildman(options, args, toolchains=None, make_func=None, boards=None,
clean_dir=False):
 """The main control code for buildman
@@ -252,9 +274,9 @@ def DoBuildman(options, args, toolchains=None, 
make_func=None, boards=None,
 # output directory itself rather than any subdirectory.
 if not options.no_subdirs:
 output_dir = os.path.join(options.output_dir, dirname)
-if (clean_dir and output_dir != options.output_dir and
-os.path.exists(output_dir)):
-shutil.rmtree(output_dir)
+if clean_dir and os.path.exists(output_dir):
+shutil.rmtree(output_dir)
+CheckOutputDir(output_dir)
 builder = Builder(toolchains, output_dir, options.git_dir,
 options.threads, options.jobs, gnu_make=gnu_make, checkout=True,
 show_unknown=options.show_unknown, step=options.step,
diff --git a/tools/buildman/func_test.py b/tools/buildman/func_test.py
index eec0f9bd37..4df1679842 100644
--- a/tools/buildman/func_test.py
+++ b/tools/buildman/func_test.py
@@ -521,3 +521,12 @@ class TestFunctional(unittest.TestCase):
 self._RunControl('-b', self._test_branch, clean_dir=False)
 self.assertEqual(self._builder.count, self._total_builds)
 self.assertEqual(self._builder.fail, 0)
+
+def testBadOutputDir(self):
+"""Test building with an output dir the same as out current dir"""
+self._test_branch = '/__dev/__testbranch'
+with self.assertRaises(SystemExit):
+self._RunControl('-b', self._test_branch, '-o', os.getcwd())
+with self.assertRaises(SystemExit):
+self._RunControl('-b', self._test_branch, '-o',
+ os.path.join(os.getcwd(), 'test'))
-- 
2.17.0.rc1.321.gba9d0f2565-goog

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

[U-Boot] [PATCH] log: Correct missing free() on error in log_add_filter()

[Simon Glass]

If there is a problem with the parameters to log_add_filter(), the memory
allocated is currently not freed. Fix this.

Reported-by: Coverity (CID: 171962)

Signed-off-by: Simon Glass 
---

 common/log.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/common/log.c b/common/log.c
index 680a60f86e..66d5e3ebf8 100644
--- a/common/log.c
+++ b/common/log.c
@@ -224,6 +224,7 @@ int log_add_filter(const char *drv_name, enum 
log_category_t cat_list[],
 {
struct log_filter *filt;
struct log_device *ldev;
+   int ret;
int i;
 
ldev = log_device_find_by_name(drv_name);
@@ -236,8 +237,10 @@ int log_add_filter(const char *drv_name, enum 
log_category_t cat_list[],
if (cat_list) {
filt->flags |= LOGFF_HAS_CAT;
for (i = 0; ; i++) {
-   if (i == ARRAY_SIZE(filt->cat_list))
-   return -ENOSPC;
+   if (i == ARRAY_SIZE(filt->cat_list)) {
+   ret = -ENOSPC;
+   goto err;
+   }
filt->cat_list[i] = cat_list[i];
if (cat_list[i] == LOGC_END)
break;
@@ -246,17 +249,19 @@ int log_add_filter(const char *drv_name, enum 
log_category_t cat_list[],
filt->max_level = max_level;
if (file_list) {
filt->file_list = strdup(file_list);
-   if (!filt->file_list)
-   goto nomem;
+   if (!filt->file_list) {
+   ret = ENOMEM;
+   goto err;
+   }
}
filt->filter_num = ldev->next_filter_num++;
list_add_tail(>sibling_node, >filter_head);
 
return filt->filter_num;
 
-nomem:
+err:
free(filt);
-   return -ENOMEM;
+   return ret;
 }
 
 int log_remove_filter(const char *drv_name, int filter_num)
-- 
2.17.0.rc1.321.gba9d0f2565-goog

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

Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[André Przywara]

Hi,

On 02/04/18 03:30, Simon Glass wrote:
> 
> Hi Andre,
> 
> On 2 April 2018 at 09:43, André Przywara  wrote:
>> Hi,
>>
>> On 01/04/18 14:19, Tom Rini wrote:
>>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
 On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
> Hi Tom,
>
> On 7 August 2017 at 09:39, Tom Rini  wrote:
>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>>
>>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
>>> code, with #ifdefs and different code paths. We should try to move over 
>>> to
>>> this soon so we can drop the old code.

 I hope this will applicable to SPL too?

 If so, we are having SPL size issues with few Allwinner families, if
 enable SPL_DM any suggestions?
>>>
>>> How close, and have you looked at the u-boot-spl.map to see what you can
>>> maybe trim?  Or areas to look at reducing in code complexity?
>>
>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
>> and picked most low hanging fruits already.
>> So far we discussed several mitigations, but mostly to cover the
>> "natural" SPL code size grow over time:
>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
>> padding (for a 2KB architectural alignment). Given that the vectors are
>> used only for debugging purposes, we could scrap them entirely or
>> construct them on the fly in some other SRAM. So would free about 2.5KB,
>> ideally. Lowest hanging fruit so far.
>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
>> encoding. This reduces the size significantly, to about 20KB. The
>> disadvantage is using a second cross-compiler or even a additional
>> cross-compiler for native builds, complicating the build process.
>> I maintain a branch for enabling FEL booting here [1], which provides
>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
>> There are no technical disadvantages in running the SPL in 32-bit, so
>> this is mostly a build issue.
> 
> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
> ARMv7. It should be fairly easy to do,

Yes, but this is merely different compiler *flags*, to the same (cross)
compiler binary. ARM32 and ARM64 are different architectures to GCC, so
require different compiler binaries with different prefixes.
Last time I checked this wasn't easy to integrate into the U-Boot build
system.
One hack could be a "switching script", which filters for, say -m32",
and calls the respective binary. But still we need to somehow set *two*
CROSS_COMPILE prefixes. CROSS_COMPILE_SPL, maybe?
But still it would require to install *two* cross compilers, and would
spoil a completely native build by still requiring a cross compiler.

>> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
>> size and sizeof(long) to be 32-bit and should help, though I haven't
>> been able to successfully compile it yet (relocation types problems).
>> Despite lacking mainline support for AArch64 ILP32 in Linux and
>> glibc(?), GCC supports it for quite a while already. Unknown saving effect.
>> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
>> the 32KB, so we could leverage this. Siarhei knows more about this.
>> 5) Use a TPL. Haven't looked at this in detail yet.
>>
>> So 1) would be the easiest to pursue, but 2.5KB are not enough to offset
>> the >10 KB toll the DM_SPL support actually takes.
> 
> Is this the cost on 64-bit?

Yes, this is AArch64, just enabling DM_SPL_MMC and DM_SPL.

> I wonder if CONFIG_OF_PLATDATA might be an option?

Well, this would be a requirement, I guess, since adding any kind of DT
to the mix makes it even worse.

Cheers,
Andre

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

[U-Boot] [PATCH] vxworks: fixed cpu enable using PSCI on armv8

[Vasyl Vavrychuk]

Without armv8_setup_psci register VBAR_EL3 is not set up property which
makes SMC calls jump to invalid location.

smp_kick_all_cpus is required to make slave cpus leave gic_wait_for_interrupt.
Without this they will never pursue booting process.

Fix was applied to the two ways of booting VxWorks: bootvx and bootm commands.

This implementation is very similiar to what is done in boot_jump_linux
in arch/arm/lib/bootm.c file.

Tested on VxWorks 7 release SR0520 2017-12-08.

Signed-off-by: Vasyl Vavrychuk 
---
 arch/arm/lib/bootm.c | 5 +
 cmd/elf.c| 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index cfc236f964..91a64bec34 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -448,6 +448,11 @@ void boot_prep_vxworks(bootm_headers_t *images)
 }
 void boot_jump_vxworks(bootm_headers_t *images)
 {
+#if defined(CONFIG_ARM64) && defined(CONFIG_ARMV8_PSCI)
+   armv8_setup_psci();
+   smp_kick_all_cpus();
+#endif
+
/* ARM VxWorks requires device tree physical address to be passed */
((void (*)(void *))images->ep)(images->ft_addr);
 }
diff --git a/cmd/elf.c b/cmd/elf.c
index 5b59fc6329..b476202908 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -368,6 +368,11 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
printf("## Starting vxWorks at 0x%08lx ...\n", addr);
 
dcache_disable();
+#if defined(CONFIG_ARM64) && defined(CONFIG_ARMV8_PSCI)
+   armv8_setup_psci();
+   smp_kick_all_cpus();
+#endif
+
 #ifdef CONFIG_X86
/* VxWorks on x86 uses stack to pass parameters */
((asmlinkage void (*)(int))addr)(0);
-- 
2.11.0

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

Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[Mark Kettenis]

> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= 
> Date: Mon, 2 Apr 2018 16:14:29 +0100
> 
> On 02/04/18 13:47, Mark Kettenis wrote:
> 
> Hi,
> 
> >> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= 
> >> Date: Mon, 2 Apr 2018 12:51:50 +0100
> >>
> >> On 02/04/18 12:20, Mark Kettenis wrote:
> >>
> >> 
> >>
>  This feature make U-Boot to have full Linux dts inside, Can't we
>  implement automatic-boot-of-os distro to grab Linux dtb during
>  commands stage like other distro does? Because this make few
>  development struggles for U-Boot project like (few of the comments are
>  repeated from previous mail, but I'm trying to group them all)
>  - Unnecessary to maintain nodes which are not required for bootloader
>  and which doesn't have proper dt drivers.
>  - It becomes more patches for each-and-every sync.
>  - We can compare the sync with Linux dt and simply apply on U-Boot
>  which look not good to project growing.
>  - Increase size(though it 10KB increase) it becomes unnecessary size
>  from U-Boot point-of-view
> >>>
> >>> This is not just about booting Linux.  And even if it was, it means
> >>> that you can only boot on hardware for which a full device tree is
> >>> included in your distro.  So a new board that comes with a usable
> >>> U-Boot in SPI flash still won't work since the right device tree isn't
> >>> there.
> >>
> >> Ah right, I didn't even mention SPI flash in that thread. Thanks!
> >>
> >> Out of curiosity: what OS are you thinking about? Collecting trophies
> >> here ;-) I tried the FreeBSD-current installer the other day, and it
> >> worked pretty well.
> > 
> > OpenBSD.  ARMv8-wise, our support for Allwinner A64/H5 and Rockchip
> > RK3399 is pretty decent these days and Rockchip RK3328 is coming along
> > as well.
> 
> Ah, great! I didn't know that OpenBSD was that far.
> Do you know of anything missing in the DT or UEFI support from mainline
> U-Boot? I put firmware images on my Pine64 github repo[1] for A64 and H5
> boards, which are based on 2018.03 plus this series, if you want to give
> it a try.
> Trying to wrap my around INSTALL.arm64, but you might be faster ;-)
> Does 6.2 provide enough to work? Or shall I wait till the 15th?

6.3 was released today!  Defenitely try that instead of 6.2.

> >  And I'm working on Marvell 8040 support.  There is support
> > for ARMv7 as well which includes many of the older Allwinner SoCs.
> > We don't have the resources to build images for all the different
> > boards that are out there though, which probably is the biggest
> > stumbling block for getting OpenBSD to run.  Our bootloader is UEFI,
> 
> That sounds good!
> 
> > so with a recent enough U-Boot in flash the default install.fs image
> 
> Is that the FFS filesystem in the OpenBSD partition of miniroot.fs?
> Which just contains the bsd.rd kernel + RAM fs?
> The 6.2 directory didn't have an explicit install.fs image.

Hmm, I meant minirootXX.fs (which for 6.3 is called miniroot63.fs).

That is a disk image that can be dd'ed directly to the boot media,
i.e. a uSD card.  It has an MBR partition table, a partition with a
FAT filesystem that has the UEFI bootloader (and Raspberry Pi
firmware) and a partition with an OpenBSD disklabel and an FFS
filesystem that has the bsd.rd kernel that includes the RAM
filesystem.

You can simply overwrite the Pine64 firmware that is already on there
(in the space before the first partition) with your own firmware.  My
Pine64 board is dead, but I tried your firmware on my Orange Pi PC 2
and it works fine.

Mainline U-Boot works fine as well, but it works better if I stick an
updated Linux device tree on the FAT filesystem.  I believe that with
the current U-Boot device tree only one of the USB ports works.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Bryan O'Donoghue]

https://git.linaro.org/landing-teams/working/mbl/u-boot.git/log/?h=linaro-mbl%2bbod

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} - ${ivt_offset}
load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr}
${optee_file_signed}
run warp7_auth_or_fail
else
run loadoptee;
fi

# Set UUID mmcpart will be used to pass root id to kernel
setenv rootpart ${mmcpart}
run finduuid;
run mmcargs;

# Now boot
echo Booting secure Linux/OPTEE OS from mmc ...;
bootm ${optee_addr} - ${fdt_addr};

# Failsafe if something goes wrong
hab_failsafe

Bryan O'Donoghue (17):
  imximage: Specify default IVT offset in IMX image
  warp7: hab: Add a CSF location definition
  warp7: hab: Set environment variable indicating HAB enable
  warp7: defconfig: Enable OPTEE for WaRP7
  warp7: Allocate specific region of memory to OPTEE
  warp7: Print out the OPTEE DRAM region
  warp7: Specify CONFIG_OPTEE_LOAD_ADDR
  warp7: defconfig: Enable CONFIG_SECURE_BOOT
  warp7: defconfig: Enable CONFIG_BOOTM_TEE
  warp7: Make CONFIG_SYS_FDT_ADDR a define
  warp7: Add Kconfig WARP7_ROOT_PART
  warp7: select uuid partition based on rootpart
  warp7: Define the name of a signed boot-script file
  warp7: add 

[U-Boot] [PATCH v2 01/17] imximage: Specify default IVT offset in IMX image

[Bryan O'Donoghue]

This patch adds BOOTROM_IVT_HDR_OFFSET at 0xC00. The BootROM expects to
find the IVT header at a particular offset in an i.MX image.

Defining the expected offset of the IVT header in the first-stage BootROM
image format is of use of later stage authentication routines where those
routines continue to follow the first-stage authentication layout.

This patch defines the first stage offset which later patch make use of.

Signed-off-by: Bryan O'Donoghue 
Cc: Utkarsh Gupta 
Cc: Breno Lima 
Cc: Fabio Estevam 
---
 include/imximage.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/imximage.h b/include/imximage.h
index 553b852..800fd63 100644
--- a/include/imximage.h
+++ b/include/imximage.h
@@ -14,6 +14,9 @@
 #define APP_CODE_BARKER0xB1
 #define DCD_BARKER 0xB17219E9
 
+/* Specify the offset of the IVT in the IMX header as expected by BootROM */
+#define BOOTROM_IVT_HDR_OFFSET 0xC00
+
 /*
  * NOTE: This file must be kept in sync with arch/arm/include/asm/\
  *   mach-imx/imximage.cfg because tools/imximage.c can not
-- 
2.7.4

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

[U-Boot] [PATCH v2 12/17] warp7: select uuid partition based on rootpart

[Bryan O'Donoghue]

Assigning the UUID discovery path to a tweakable environment variable means
that later steps in the boot process - particularly a boot script can
change the target root partition of a particular Linux boot.

Retargeting the rootfs is an important feature when doing ping/pong
upgrades allowing a boot script to select ping or pong as necessary without
reprogramming the bootloader.

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 344042c..54b3b31 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -45,7 +45,8 @@
"ip_dyn=yes\0" \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
"mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
-   "finduuid=part uuid mmc 0:2 uuid\0" \
+   "rootpart=" __stringify(CONFIG_WARP7_ROOT_PART) "\0" \
+   "finduuid=part uuid mmc 0:${rootpart} uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
"loadbootscript=" \
-- 
2.7.4

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

[U-Boot] [PATCH v2 14/17] warp7: add warp7_auth_or_fail

[Bryan O'Donoghue]

Doing secure boot on the WaRP7 using a common image format and the same
variable to represent the base address for each call means we can reduce
down the command to a single environment command.

This patch adds warp7_auth_or_fail as a wrapper around
"hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 0".

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 0ed95d8..454bc1c 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -50,6 +50,7 @@
"finduuid=part uuid mmc 0:${rootpart} uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
+   "warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
0;\0" \
"loadbootscript=" \
"load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
-- 
2.7.4

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

[U-Boot] [PATCH v2 13/17] warp7: Define the name of a signed boot-script file

[Bryan O'Donoghue]

We need to know the name of a signed boot-script, its better to have a
separate variable for this then to simply append some fixed string to an
existing image name.

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 54b3b31..0ed95d8 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -33,6 +33,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
CONFIG_DFU_ENV_SETTINGS \
"script=boot.scr\0" \
+   "script_signed=boot.scr.imx-signed\0" \
"image=zImage\0" \
"console=ttymxc0\0" \
"ethact=usb_ether\0" \
-- 
2.7.4

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

[U-Boot] [PATCH v2 08/17] warp7: defconfig: Enable CONFIG_SECURE_BOOT

[Bryan O'Donoghue]

Various function associated with booting the WaRP7 in High Assurance Boot
(HAB) mode are enabled by switching on CONFIG_SECURE_BOOT.

This patch enables CONFIG_SECURE_BOOT for the WaRP7 defconfig.

Signed-off-by: Bryan O'Donoghue 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index c647cd0..efb6f51 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_MX7=y
+CONFIG_SECURE_BOOT=y
 CONFIG_SYS_TEXT_BASE=0x8780
 CONFIG_TARGET_WARP7=y
 CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
-- 
2.7.4

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

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

[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.

Signed-off-by: Bryan O'Donoghue 
---
 configs/warp7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index d5dc009..13c760d 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -21,7 +21,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_PART=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_SETEXPR=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
-- 
2.7.4

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

[U-Boot] [ANN] U-Boot v2018.05-rc1 released

[Tom Rini]

Hey all,

So it's release day and I've put up v2018.05-rc1.  The merge window is
now closed and I've updated git and the tarballs are also up now.

I'm sure my patch queue is in bad shape as I've been on vacation for the
last week (hence my relative silence).  I also am sad to report I don't
have any blurry fish butt pictures to share either.  I expect to clean
up my queue in the next few days.

I see that around v2018.03-rc1, I talked about taking the patches from
Daniel to enable -Werror in travis-ci builds, and I'm going to see how
close we are to that.  I think the biggest problem was getting switched
to gcc-7 and I think we have that available now.

I also now owe posting some patches to drop ARM STM SPEAR, m5253evbe,
mx31ads, and imx31_phycore.

Finally, we have a DM conversion for CONFIG_BLK coming due, and I need
to catch up on the thread that's been going on the last week and see
where everyone is at on the feasibility of doing this cut-off, and what
it means in very low memory situations too.

I will follow the usual rule of an -rc every other Monday
and we're looking at release on May 7th, 2018.

Thanks all!

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Mon, Apr 02, 2018 at 07:22:39AM +0800, Simon Glass wrote:

> Hi Tom,
> 
> Here's an assortment of things that were in my queue. Test result is here:
> 
> https://travis-ci.org/sglass68/u-boot/builds/360881266
> 
> 
> The following changes since commit 81cf7c8d45935a295991fe2cd1df286f0f47511f:
> 
>   Merge git://git.denx.de/u-boot-ubi (2018-03-25 12:02:13 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git
> 
> for you to fetch changes up to 641599a63df258c3e3cb259c75cdada0cc009d56:
> 
>   image.h: add forward declaration of struct fdt_region (2018-04-01
> 22:19:10 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH v2 15/17] warp7: hab: Set environment variable indicating IVT offset

[Bryan O'Donoghue]

This patch introduces the environment variable ivt_offset. When we define a
load address for Linux or DTB or any file the IVT associated with that file
is prepended. We extract the actual load addresses from u-boot.cfg and feed
these values into the code-signing process - hence we want u-boot to have
the real load addresses exported in uboot.cfg.

ivt_offset represents the addition or subtraction from the load address
that must happen to find an IVT header.

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 454bc1c..fe9b7d5 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -10,6 +10,7 @@
 #define __WARP7_CONFIG_H
 
 #include "mx7_common.h"
+#include 
 
 #define PHYS_SDRAM_SIZESZ_512M
 
@@ -50,6 +51,7 @@
"finduuid=part uuid mmc 0:${rootpart} uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
+   "ivt_offset=" __stringify(BOOTROM_IVT_HDR_OFFSET)"\0"\
"warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
0;\0" \
"loadbootscript=" \
"load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-- 
2.7.4

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

[U-Boot] [PATCH v2 17/17] warp7: Add support for automated secure boot.scr verification

[Bryan O'Donoghue]

This patch adds support for verifying a signed boot.scr. With this in place
it's possible for run-time Linux to update boot.scr to set different
variables such as switching between different boot partitions, pointing to
different kernels etc and for u-boot to verify these changes via the HAB
prior to executing the commands contained in boot.scr.

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index fe9b7d5..f340bff 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -53,6 +53,14 @@
"root=PARTUUID=${uuid} rootwait rw\0" \
"ivt_offset=" __stringify(BOOTROM_IVT_HDR_OFFSET)"\0"\
"warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
0;\0" \
+   "do_bootscript_hab=" \
+   "if test ${hab_enabled} -eq 1; then " \
+   "setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}; " \
+   "setenv script ${script_signed}; " \
+   "load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} 
${script}; " \
+   "run warp7_auth_or_fail; " \
+   "run bootscript; "\
+   "fi;\0" \
"loadbootscript=" \
"load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
@@ -79,6 +87,7 @@
 #define CONFIG_BOOTCOMMAND \
   "mmc dev ${mmcdev};" \
   "mmc dev ${mmcdev}; if mmc rescan; then " \
+  "run do_bootscript_hab;" \
   "if run loadbootscript; then " \
   "run bootscript; " \
   "else " \
-- 
2.7.4

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

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

[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
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 10db716..e12b90b 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -40,6 +40,7 @@
"initrd_high=0x\0" \
"fdt_file=imx7s-warp.dtb\0" \
"fdt_addr=0x8300\0" \
+   "optee_addr=" __stringify(CONFIG_OPTEE_LOAD_ADDR)"\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2] timer: add High Precision Event Timers (HPET) support

[Ivan Gorinov]

On Sat, Mar 31, 2018 at 06:31:03AM -0600, Andy Shevchenko wrote:
> >> > +   tl = readl(regs + HPET_MAIN_COUNT_L);
> >> > +   th = readl(regs + HPET_MAIN_COUNT_H);
> >>
> >> Ditto.
> >
> > If readq() is defined as two read operations in 32-bit code, main counter
> > rollover (low part overflow, high part increment) can happen between them.
> 
> And how this contradicts ther current code?

It just does not make the code simpler, rollover check is
still required if U-Boot is compiled as 32-bit code.

Can we do something like the following?


#ifdef CONFIG_X86_64

static u64 read_main_counter(void *regs)
{
return readq(regs + HPET_MAIN_COUNT);
}

#else

/*
 * Read the main counter as two 32-bit registers,
 * repeat if rollover happens.
 */
static u64 read_main_counter(void *regs)
{
u64 now_tick;
u32 tl, th, th0;

th = readl(regs + HPET_MAIN_COUNT_H);
do {
th0 = th;
tl = readl(regs + HPET_MAIN_COUNT_L);
th = readl(regs + HPET_MAIN_COUNT_H);
now_tick = th;
now_tick <<= 32;
now_tick |= tl;
} while (th != th0);

return now_tick;
}

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

[U-Boot] [PATCH v2 10/17] warp7: Make CONFIG_SYS_FDT_ADDR a define

[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.

Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Ryan Harkin 
---
 board/warp7/Kconfig | 6 ++
 include/configs/warp7.h | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/board/warp7/Kconfig b/board/warp7/Kconfig
index 61c33fb..00df19d 100644
--- a/board/warp7/Kconfig
+++ b/board/warp7/Kconfig
@@ -6,4 +6,10 @@ config SYS_BOARD
 config SYS_CONFIG_NAME
default "warp7"
 
+config SYS_FDT_ADDR
+   hex "FDT load address"
+   default 0x8300
+   help
+ The address the FDT file should be loaded to.
+
 endif
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index e12b90b..344042c 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -39,7 +39,7 @@
"fdt_high=0x\0" \
"initrd_high=0x\0" \
"fdt_file=imx7s-warp.dtb\0" \
-   "fdt_addr=0x8300\0" \
+   "fdt_addr=" __stringify(CONFIG_SYS_FDT_ADDR)"\0" \
"optee_addr=" __stringify(CONFIG_OPTEE_LOAD_ADDR)"\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
-- 
2.7.4

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

[U-Boot] [PATCH v2 11/17] warp7: Add Kconfig WARP7_ROOT_PART

[Bryan O'Donoghue]

Adding CONFIG_WARP7_ROOT_PART allows a defconfig to specify which partition
is use as the root partition on WaRP7, this is a desirable change in order
to support a different partitioning schemes. The default is the current
partition #2.

Signed-off-by: Bryan O'Donoghue 
---
 board/warp7/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/board/warp7/Kconfig b/board/warp7/Kconfig
index 00df19d..c089bca 100644
--- a/board/warp7/Kconfig
+++ b/board/warp7/Kconfig
@@ -6,6 +6,14 @@ config SYS_BOARD
 config SYS_CONFIG_NAME
default "warp7"
 
+config WARP7_ROOT_PART
+   int "Partition number to use for root filesystem"
+   default 2
+   help
+ The partition number to use for root filesystem this is the
+ partition that is typically specified with root=/dev/sdaX or
+ which gets converted into a root=PARTUUID=some_uuid.
+
 config SYS_FDT_ADDR
hex "FDT load address"
default 0x8300
-- 
2.7.4

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

[U-Boot] [PATCH v2 02/17] warp7: hab: Add a CSF location definition

[Bryan O'Donoghue]

In order to correctly produce an image with a IVT/DCD header we need to
define a CSF in imximage.cfg. We just use the mx7 default here.

All we have to do with this option switched on is "make u-boot.imx" and we
then will get

- u-boot.imx
- u-boot.imx.log

The log file is really important because it gives the addresses for the HAB
that we will require to sign the u-boot image using the CST. Since the
addresses can change this logfile is a critical output.

Signed-off-by: Bryan O'Donoghue 
---
 board/warp7/imximage.cfg | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/warp7/imximage.cfg b/board/warp7/imximage.cfg
index 5b42793..51a5bff 100644
--- a/board/warp7/imximage.cfg
+++ b/board/warp7/imximage.cfg
@@ -13,6 +13,10 @@
 #include 
 
 IMAGE_VERSION  2
+#ifdef CONFIG_SECURE_BOOT
+CSF CONFIG_CSF_SIZE
+#endif
+
 BOOT_FROM  sd
 
 /*
-- 
2.7.4

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

[U-Boot] [PATCH v2 04/17] warp7: defconfig: Enable OPTEE for WaRP7

[Bryan O'Donoghue]

Requires setting CONFIG_OPTEE=y and setting an OPTEE TrustZone DRAM base in
include/configs/warp7.h.

Signed-off-by: Bryan O'Donoghue 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index d720bac..3dbcd69 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -44,3 +44,4 @@ CONFIG_USB_ETHER=y
 CONFIG_USB_ETH_CDC=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
 CONFIG_OF_LIBFDT=y
+CONFIG_OPTEE=y
-- 
2.7.4

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

[U-Boot] [PATCH v2 03/17] warp7: hab: Set environment variable indicating HAB enable

[Bryan O'Donoghue]

This patch adds an environment variable called "hab_enabled" which gets set
to a boolean status indicating whether HAB is enabled or not.

Subsequent patches can use this environment variable to determine if its
necessary to run a given binary through the hab_auth_img console command.

Signed-off-by: Bryan O'Donoghue 
---
 board/warp7/warp7.c | 8 
 include/configs/warp7.h | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 327f656..0d3d324 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -203,6 +204,13 @@ int board_late_init(void)
 */
clrsetbits_le16(>wcr, 0, 0x10);
 
+#ifdef CONFIG_SECURE_BOOT
+   /* Determine HAB state */
+   env_set_ulong(HAB_ENABLED_ENVNAME, imx_hab_is_enabled());
+#else
+   env_set_ulong(HAB_ENABLED_ENVNAME, 0);
+#endif
+
 #ifdef CONFIG_SERIAL_TAG
/* Set serial# standard environment variable based on OTP settings */
get_board_serial();
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 98fedb8..10db716 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -139,4 +139,7 @@
 
 #define CONFIG_USBNET_DEV_ADDR "de:ad:be:af:00:01"
 
+/* Environment variable name to represent HAB enable state */
+#define HAB_ENABLED_ENVNAME"hab_enabled"
+
 #endif
-- 
2.7.4

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

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

[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

Signed-off-by: Bryan O'Donoghue 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index efb6f51..d5dc009 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -47,3 +47,4 @@ CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
 CONFIG_OF_LIBFDT=y
 CONFIG_OPTEE=y
 CONFIG_OPTEE_LOAD_ADDR=0x8400
+CONFIG_BOOTM_OPTEE=y
-- 
2.7.4

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

[U-Boot] [PATCH v2 05/17] warp7: Allocate specific region of memory to OPTEE

[Bryan O'Donoghue]

Subtracts CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size.

On WaRP7 we simply define the OPTEE region as from the maximum DRAM address
minus CONFIG_OPTEE_TZDRAM_SIZE bytes.

Note the OPTEE boot process will itself subtract the DRAM region it lives
in from the memory map passed to Linux.

Signed-off-by: Bryan O'Donoghue 
---
 board/warp7/warp7.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 0d3d324..56f0cdd 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -58,6 +58,11 @@ int dram_init(void)
 {
gd->ram_size = PHYS_SDRAM_SIZE;
 
+   /* Subtract the defined OPTEE runtime firmware length */
+#ifdef CONFIG_OPTEE_TZDRAM_SIZE
+   gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE;
+#endif
+
return 0;
 }
 
-- 
2.7.4

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

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Mon, Apr 02, 2018 at 02:11:59PM +0800, Simon Glass wrote:
> Hi Tom,
> 
> On 4 February 2018 at 02:13, Tom Rini  wrote:
> > On Sat, Feb 03, 2018 at 10:12:41AM -0700, Simon Glass wrote:
> >> Hi Tom,
> >>
> >> On 26 January 2018 at 17:50, Tom Rini  wrote:
> >> > On Fri, Jan 26, 2018 at 02:45:29PM -0700, Simon Glass wrote:
> >> >
> >> >> Hi Tom,
> >> >>
> >> >> Here are some additions to logging and 64-bit sandbox support.
> >> >>
> >> >>
> >> >> The following changes since commit 
> >> >> ab12aa24e619b5e81cbde7de88c6d9a19f04313b:
> >> >>
> >> >>   ARM: socfpga: Convert callers of cm_write_with_phase for
> >> >> wait_for_bit_le32 (2018-01-26 13:08:03 -0500)
> >> >>
> >> >> are available in the Git repository at:
> >> >>
> >> >>   git://git.denx.de/u-boot-dm.git
> >> >>
> >> >> for you to fetch changes up to 4e94617bf911595efcecf52d6c9f323744a81cda:
> >> >>
> >> >>   log: add category LOGC_EFI (2018-01-26 12:20:55 -0700)
> >> >>
> >> >
> >> > NAK:
> >> > Starting LLVM-3.8 test
> >> > common/log.c:44:17: warning: implicit conversion from enumeration type 
> >> > 'enum log_category_t' to different enumeration type 'enum uclass_id' 
> >> > [-Wenum-conversion]
> >> > if (log_uc_cat(cat) >= LOGC_NONE)
> >> > ~~ ^~~
> >> > common/log.c:47:36: warning: implicit conversion from enumeration type 
> >> > 'enum log_category_t' to different enumeration type 'enum uclass_id' 
> >> > [-Wenum-conversion]
> >> > return uclass_get_name(log_uc_cat(cat));
> >> >~~ ^~~
> >> > 2 warnings generated.
> >> >
> >> > Also, checkpatch.pl notes that the sandbox64 defconfig isn't caught by
> >> > MAINTAINERS and then I see the 32bit one already isn't.
> >> >
> >> > Finally, I see a bunch of warnings on sandbox64:
> >> > lib/fdtdec.c: In function ‘fdtdec_get_addr_size_auto_noparent’:
> >> > include/fdtdec.h:27:25: warning: large integer implicitly truncated to 
> >> > unsigned type [-Woverflow]
> >> >  #define FDT_ADDR_T_NONE (-1ULL)
> >> >
> >> > That's with my normal 64bit host gcc (5.4.0, Ubuntu 16.04).
> >>
> >> OK I'll drop sandbox64 for now. I'm not sure why buildman was happy,
> >> but I may have missed it because there are already a lot of warnings
> >> with sandbox. I'll see if I can fix those. I need to add clang to my
> >> workflow...
> >
> > It's not too hard.  Note that if you go newer than 3.8 there's a ton of
> > warnings I haven't had time to look into.  And I only test sandbox with
> > clang atm.
> 
> I don't see any warnings doing this:
> 
> $ make -s -j10 HOSTCC=clang-3.8 O=b/sandbox/ sandbox_defconfig all
> $ make -s -j10 HOSTCC=clang-3.8 O=b/sandbox64/ sandbox64_defconfig all
> $
> 
> How do I get the warnings?

They have been fixed since then, I guess it was something else that was
also in that PR at the time?  Thanks!

-- 
Tom


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

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

[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 
---
 board/warp7/warp7.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 56f0cdd..da52b18 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -181,7 +181,17 @@ int checkboard(void)
else
mode = "non-secure";
 
+#ifdef CONFIG_OPTEE_TZDRAM_SIZE
+   unsigned long optee_start, optee_end;
+
+   optee_end = PHYS_SDRAM + PHYS_SDRAM_SIZE;
+   optee_start = optee_end - CONFIG_OPTEE_TZDRAM_SIZE;
+
+   printf("Board: WARP7 in %s mode OPTEE DRAM 0x%08lx-0x%08lx\n",
+  mode, optee_start, optee_end);
+#else
printf("Board: WARP7 in %s mode\n", mode);
+#endif
 
return 0;
 }
-- 
2.7.4

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

Re: [U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

On 4 February 2018 at 02:13, Tom Rini  wrote:
> On Sat, Feb 03, 2018 at 10:12:41AM -0700, Simon Glass wrote:
>> Hi Tom,
>>
>> On 26 January 2018 at 17:50, Tom Rini  wrote:
>> > On Fri, Jan 26, 2018 at 02:45:29PM -0700, Simon Glass wrote:
>> >
>> >> Hi Tom,
>> >>
>> >> Here are some additions to logging and 64-bit sandbox support.
>> >>
>> >>
>> >> The following changes since commit 
>> >> ab12aa24e619b5e81cbde7de88c6d9a19f04313b:
>> >>
>> >>   ARM: socfpga: Convert callers of cm_write_with_phase for
>> >> wait_for_bit_le32 (2018-01-26 13:08:03 -0500)
>> >>
>> >> are available in the Git repository at:
>> >>
>> >>   git://git.denx.de/u-boot-dm.git
>> >>
>> >> for you to fetch changes up to 4e94617bf911595efcecf52d6c9f323744a81cda:
>> >>
>> >>   log: add category LOGC_EFI (2018-01-26 12:20:55 -0700)
>> >>
>> >
>> > NAK:
>> > Starting LLVM-3.8 test
>> > common/log.c:44:17: warning: implicit conversion from enumeration type 
>> > 'enum log_category_t' to different enumeration type 'enum uclass_id' 
>> > [-Wenum-conversion]
>> > if (log_uc_cat(cat) >= LOGC_NONE)
>> > ~~ ^~~
>> > common/log.c:47:36: warning: implicit conversion from enumeration type 
>> > 'enum log_category_t' to different enumeration type 'enum uclass_id' 
>> > [-Wenum-conversion]
>> > return uclass_get_name(log_uc_cat(cat));
>> >~~ ^~~
>> > 2 warnings generated.
>> >
>> > Also, checkpatch.pl notes that the sandbox64 defconfig isn't caught by
>> > MAINTAINERS and then I see the 32bit one already isn't.
>> >
>> > Finally, I see a bunch of warnings on sandbox64:
>> > lib/fdtdec.c: In function ‘fdtdec_get_addr_size_auto_noparent’:
>> > include/fdtdec.h:27:25: warning: large integer implicitly truncated to 
>> > unsigned type [-Woverflow]
>> >  #define FDT_ADDR_T_NONE (-1ULL)
>> >
>> > That's with my normal 64bit host gcc (5.4.0, Ubuntu 16.04).
>>
>> OK I'll drop sandbox64 for now. I'm not sure why buildman was happy,
>> but I may have missed it because there are already a lot of warnings
>> with sandbox. I'll see if I can fix those. I need to add clang to my
>> workflow...
>
> It's not too hard.  Note that if you go newer than 3.8 there's a ton of
> warnings I haven't had time to look into.  And I only test sandbox with
> clang atm.

I don't see any warnings doing this:

$ make -s -j10 HOSTCC=clang-3.8 O=b/sandbox/ sandbox_defconfig all
$ make -s -j10 HOSTCC=clang-3.8 O=b/sandbox64/ sandbox64_defconfig all
$

How do I get the warnings?

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

[U-Boot] [PATCH] ARC: Bump ARC tools used in TravisCI to the most recent release arc-2017.09

[Alexey Brodkin]

This is much more recent version of ARC tools based on GCC 7.1.1 and 
Binutils 2.29.

Signed-off-by: Alexey Brodkin 
---
 .travis.yml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 6cad65fd378d..d83a5e63329a 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -38,7 +38,7 @@ install:
  - echo -e "[toolchain]\nroot = /usr" > ~/.buildman
  - echo -e "aarch64 = /tmp/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu" 
>> ~/.buildman
  - echo -e "arm = /tmp/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf" >> 
~/.buildman
- - echo -e "arc = /tmp/arc_gnu_2016.09_prebuilt_uclibc_le_archs_linux_install" 
>> ~/.buildman
+ - echo -e "arc = /tmp/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install" 
>> ~/.buildman
  - echo -e "\n[toolchain-alias]\nsh = sh4\nopenrisc = or32" >> ~/.buildman
  - cat ~/.buildman
  - virtualenv /tmp/venv
@@ -70,8 +70,8 @@ before_script:
   echo -e "\n[toolchain-prefix]\nx86 = 
${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-" 
>> ~/.buildman;
 fi
   - if [[ "${TOOLCHAIN}" == arc ]]; then
-   wget 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2016.09-release/arc_gnu_2016.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
 &&
-   tar -C /tmp -xf 
arc_gnu_2016.09_prebuilt_uclibc_le_archs_linux_install.tar.gz;
+   wget 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-release/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
 &&
+   tar -C /tmp -xf 
arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install.tar.gz;
 fi
   - if [[ "${TOOLCHAIN}" == *xtensa* ]]; then
wget 
https://github.com/foss-xtensa/toolchain/releases/download/2018.02/x86_64-2018.02-${TOOLCHAIN}.tar.gz
 &&
-- 
2.14.3

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

Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[André Przywara]

On 02/04/18 12:20, Mark Kettenis wrote:



>> This feature make U-Boot to have full Linux dts inside, Can't we
>> implement automatic-boot-of-os distro to grab Linux dtb during
>> commands stage like other distro does? Because this make few
>> development struggles for U-Boot project like (few of the comments are
>> repeated from previous mail, but I'm trying to group them all)
>> - Unnecessary to maintain nodes which are not required for bootloader
>> and which doesn't have proper dt drivers.
>> - It becomes more patches for each-and-every sync.
>> - We can compare the sync with Linux dt and simply apply on U-Boot
>> which look not good to project growing.
>> - Increase size(though it 10KB increase) it becomes unnecessary size
>> from U-Boot point-of-view
> 
> This is not just about booting Linux.  And even if it was, it means
> that you can only boot on hardware for which a full device tree is
> included in your distro.  So a new board that comes with a usable
> U-Boot in SPI flash still won't work since the right device tree isn't
> there.

Ah right, I didn't even mention SPI flash in that thread. Thanks!

Out of curiosity: what OS are you thinking about? Collecting trophies
here ;-) I tried the FreeBSD-current installer the other day, and it
worked pretty well.

> So I Agree with Andre, U-Boot should provide the full device tree if
> possible.  That doesn't mean it shouldn't try to load a device tree
> from the boot media if there is one.  That way users can easily
> update/tweak their device tree without re-flashing the complete
> firmware.

Yes, users should still be able to provide their own DT, if needed.
Actually that's what I often do for Linux development myself.

Thanks!
Andre.

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