Re: [U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Masahiro Yamada]

Hi.


2016-06-28 14:02 GMT+09:00 Peng Fan :
> Hi Tom,
>
> On Fri, Jun 24, 2016 at 06:57:44PM -0400, Tom Rini wrote:
>>On Sun, Jun 19, 2016 at 06:20:52PM +0800, Peng Fan wrote:
>>> Hi Masahiro,
>>>
>>> +Simon
>>> On Fri, Jun 17, 2016 at 07:08:23PM +0900, Masahiro Yamada wrote:
>>> >2016-06-17 18:39 GMT+09:00 Peng Fan :
>>> >> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
>>> >>
>>> >> SoCs supports loading U-Boot from different medias to DRAM, such as
>>> >> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
>>> >> and etc. For i.MX, imximage will generate different IVT headers according
>>> >> to boot medias.
>>> >>
>>> >> Signed-off-by: Peng Fan 
>>> >> Cc: Simon Glass 
>>> >> Cc: Heiko Schocher 
>>> >> Cc: Joe Hershberger 
>>> >> Cc: Bin Meng 
>>> >> Cc: Christophe Ricard 
>>> >> Cc: Nikita Kiryanov 
>>> >> Cc: Francois Retief 
>>> >> Cc: Tom Rini 
>>> >> ---
>>> >>
>>> >> V2:
>>> >>  Move NOR_BOOT to the patch 1/2.
>>> >>  The idea of this patch is for adding different boot media support for
>>> >>  i.MXes. And I'll post out following patches if this patch is accepted.
>>> >>  I ran moveconfig.py, but I did not include the results into a patch.
>>> >>  This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
>>> >>  etc, and I prefer to let board owners to move to defconfig later.
>>> >>
>>> >>  common/Kconfig | 48 
>>> >>  1 file changed, 48 insertions(+)
>>> >>
>>> >> diff --git a/common/Kconfig b/common/Kconfig
>>> >> index 04d092c..f0f6ee1 100644
>>> >> --- a/common/Kconfig
>>> >> +++ b/common/Kconfig
>>> >> @@ -108,6 +108,54 @@ config NOR_BOOT
>>> >>   as the ROM only partially sets up pinmux.  We also default to 
>>> >> using
>>> >>   NOR for environment.
>>> >>
>>> >> +config NAND_BOOT
>>> >> +   bool "Support for booting from NAND flash"
>>> >> +   default n
>>> >> +   help
>>> >> + Enabling this will make a U-Boot binary that is capable of 
>>> >> being
>>> >> + booted via NAND flash. This is not a must, some SoCs need this,
>>> >> + somes not.
>>> >> +
>>> >> +config ONENAND_BOOT
>>> >> +   bool "Support for booting from ONENAND"
>>> >> +   default n
>>> >> +   help
>>> >> + Enabling this will make a U-Boot binary that is capable of 
>>> >> being
>>> >> + booted via ONENAND. This is not a must, some SoCs need this,
>>> >> + somes not.
>>> >> +
>>> >> +config QSPI_BOOT
>>> >> +   bool "Support for booting from QSPI flash"
>>> >> +   default n
>>> >> +   help
>>> >> + Enabling this will make a U-Boot binary that is capable of 
>>> >> being
>>> >> + booted via QSPI flash. This is not a must, some SoCs need this,
>>> >> + somes not.
>>> >> +
>>> >> +config SATA_BOOT
>>> >> +   bool "Support for booting from SATA"
>>> >> +   default n
>>> >> +   help
>>> >> + Enabling this will make a U-Boot binary that is capable of 
>>> >> being
>>> >> + booted via SATA. This is not a must, some SoCs need this,
>>> >> + somes not.
>>> >> +
>>> >> +config SD_BOOT
>>> >> +   bool "Support for booting from SD/EMMC"
>>> >> +   default n
>>> >> +   help
>>> >> + Enabling this will make a U-Boot binary that is capable of 
>>> >> being
>>> >> + booted via SD/EMMC. This is not a must, some SoCs need this,
>>> >> + somes not.
>>> >> +
>>> >> +config SPI_BOOT
>>> >> +   bool "Support for booting from SPI flash"
>>> >> +   default n
>>> >> +   help
>>> >> + Enabling this will make a U-Boot binary that is capable of 
>>> >> being
>>> >> + booted via SPI flash. This is not a must, some SoCs need this,
>>> >> + somes not.
>>> >> +
>>> >>  endmenu
>>> >
>>> >
>>> >Do you intend to replace
>>> >CONFIG_SPL_NOR_SUPPORT
>>> >CONFIG_SPL_NAND_SUPPORT
>>> >CONFIG_SPL_USB_SUPPORT
>>> >CONFIG_SPL_MMC_SUPPORT
>>> >etc. with these options?
>>> >
>>>
>>> I missed these.
>>>
>>> >
>>> >Currently, common/spl/spl.c uses CONFIG_SPL_*_SUPPORT
>>> >to enable/disable capable boot devices.
>>>
>>> I think we could use a common option to replace the ones used in SPL.
>>
>>I'm not sure that CONFIG_xxx_BOOT and CONFIG_SPL_xxx_SUPPORT are the
>>same thing.  For example, CONFIG_NOR_BOOT on am335x means "we are
>>building to support booting from NOR, so include all of that stuff
>>that's normally not included".  While CONFIG_SPL_NAND_SUPPORT means
>>include NAND support in SPL, which is not mutually exclusive with MMC,
>>etc.
>
> ok. Then, better keep them. For i.MX6, CONFIG_XX_BOOT have the same meaning
> with am335x as you said.
>
> Do you have other comments? If not touching SPL, I would 

Re: [U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Peng Fan]

Hi Tom,

On Fri, Jun 24, 2016 at 06:57:44PM -0400, Tom Rini wrote:
>On Sun, Jun 19, 2016 at 06:20:52PM +0800, Peng Fan wrote:
>> Hi Masahiro,
>> 
>> +Simon
>> On Fri, Jun 17, 2016 at 07:08:23PM +0900, Masahiro Yamada wrote:
>> >2016-06-17 18:39 GMT+09:00 Peng Fan :
>> >> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
>> >>
>> >> SoCs supports loading U-Boot from different medias to DRAM, such as
>> >> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
>> >> and etc. For i.MX, imximage will generate different IVT headers according
>> >> to boot medias.
>> >>
>> >> Signed-off-by: Peng Fan 
>> >> Cc: Simon Glass 
>> >> Cc: Heiko Schocher 
>> >> Cc: Joe Hershberger 
>> >> Cc: Bin Meng 
>> >> Cc: Christophe Ricard 
>> >> Cc: Nikita Kiryanov 
>> >> Cc: Francois Retief 
>> >> Cc: Tom Rini 
>> >> ---
>> >>
>> >> V2:
>> >>  Move NOR_BOOT to the patch 1/2.
>> >>  The idea of this patch is for adding different boot media support for
>> >>  i.MXes. And I'll post out following patches if this patch is accepted.
>> >>  I ran moveconfig.py, but I did not include the results into a patch.
>> >>  This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
>> >>  etc, and I prefer to let board owners to move to defconfig later.
>> >>
>> >>  common/Kconfig | 48 
>> >>  1 file changed, 48 insertions(+)
>> >>
>> >> diff --git a/common/Kconfig b/common/Kconfig
>> >> index 04d092c..f0f6ee1 100644
>> >> --- a/common/Kconfig
>> >> +++ b/common/Kconfig
>> >> @@ -108,6 +108,54 @@ config NOR_BOOT
>> >>   as the ROM only partially sets up pinmux.  We also default to 
>> >> using
>> >>   NOR for environment.
>> >>
>> >> +config NAND_BOOT
>> >> +   bool "Support for booting from NAND flash"
>> >> +   default n
>> >> +   help
>> >> + Enabling this will make a U-Boot binary that is capable of being
>> >> + booted via NAND flash. This is not a must, some SoCs need this,
>> >> + somes not.
>> >> +
>> >> +config ONENAND_BOOT
>> >> +   bool "Support for booting from ONENAND"
>> >> +   default n
>> >> +   help
>> >> + Enabling this will make a U-Boot binary that is capable of being
>> >> + booted via ONENAND. This is not a must, some SoCs need this,
>> >> + somes not.
>> >> +
>> >> +config QSPI_BOOT
>> >> +   bool "Support for booting from QSPI flash"
>> >> +   default n
>> >> +   help
>> >> + Enabling this will make a U-Boot binary that is capable of being
>> >> + booted via QSPI flash. This is not a must, some SoCs need this,
>> >> + somes not.
>> >> +
>> >> +config SATA_BOOT
>> >> +   bool "Support for booting from SATA"
>> >> +   default n
>> >> +   help
>> >> + Enabling this will make a U-Boot binary that is capable of being
>> >> + booted via SATA. This is not a must, some SoCs need this,
>> >> + somes not.
>> >> +
>> >> +config SD_BOOT
>> >> +   bool "Support for booting from SD/EMMC"
>> >> +   default n
>> >> +   help
>> >> + Enabling this will make a U-Boot binary that is capable of being
>> >> + booted via SD/EMMC. This is not a must, some SoCs need this,
>> >> + somes not.
>> >> +
>> >> +config SPI_BOOT
>> >> +   bool "Support for booting from SPI flash"
>> >> +   default n
>> >> +   help
>> >> + Enabling this will make a U-Boot binary that is capable of being
>> >> + booted via SPI flash. This is not a must, some SoCs need this,
>> >> + somes not.
>> >> +
>> >>  endmenu
>> >
>> >
>> >Do you intend to replace
>> >CONFIG_SPL_NOR_SUPPORT
>> >CONFIG_SPL_NAND_SUPPORT
>> >CONFIG_SPL_USB_SUPPORT
>> >CONFIG_SPL_MMC_SUPPORT
>> >etc. with these options?
>> >
>> 
>> I missed these.
>> 
>> >
>> >Currently, common/spl/spl.c uses CONFIG_SPL_*_SUPPORT
>> >to enable/disable capable boot devices.
>> 
>> I think we could use a common option to replace the ones used in SPL.
>
>I'm not sure that CONFIG_xxx_BOOT and CONFIG_SPL_xxx_SUPPORT are the
>same thing.  For example, CONFIG_NOR_BOOT on am335x means "we are
>building to support booting from NOR, so include all of that stuff
>that's normally not included".  While CONFIG_SPL_NAND_SUPPORT means
>include NAND support in SPL, which is not mutually exclusive with MMC,
>etc.

ok. Then, better keep them. For i.MX6, CONFIG_XX_BOOT have the same meaning
with am335x as you said.

Do you have other comments? If not touching SPL, I would like to see this
patch set applied.

Thanks,
Peng.
>
>-- 
>Tom


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

Re: [U-Boot] [PATCH v5 6/8] ARMv7: PSCI: ls102xa: check ALREADY_ON or ON_PENDING for CPU_ON

[Chen-Yu Tsai]

On Tue, Jun 14, 2016 at 3:01 PM,   wrote:
> From: Hongbo Zhang 
>
> For the robustness of codes, while powering on a CPU, it is better to check
> if the target CPU is already on or in the process of power on, if yes the
> power on routine shouldn't be executed further and should return with the
> corresponding status immediately.
>
> Signed-off-by: Hongbo Zhang 
> ---
>  arch/arm/cpu/armv7/ls102xa/psci.S | 29 +
>  arch/arm/include/asm/psci.h   |  5 +
>  2 files changed, 34 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S 
> b/arch/arm/cpu/armv7/ls102xa/psci.S
> index a4482e4..0188ade 100644
> --- a/arch/arm/cpu/armv7/ls102xa/psci.S
> +++ b/arch/arm/cpu/armv7/ls102xa/psci.S
> @@ -66,6 +66,22 @@ psci_cpu_on:
> beq out_psci_cpu_on
> mov r1, r0
>
> +   bl  psci_get_cpu_stack_top
> +   sub r0, r0, #PSCI_CPU_STATUS_OFFSET
> +   ldr r5, [r0]
> +
> +   cmp r5, #PSCI_CPU_STATUS_ON
> +   moveq   r0, #ARM_PSCI_RET_ALREADY_ON
> +   beq out_psci_cpu_on
> +
> +   cmp r5, #PSCI_CPU_STATUS_ON_PENDING
> +   moveq   r0, #ARM_PSCI_RET_ON_PENDING
> +   beq out_psci_cpu_on
> +
> +   mov r5, #PSCI_CPU_STATUS_ON_PENDING
> +   str r5, [r0]
> +   dsb
> +
> bl  psci_cpu_on_common
>
> @ Get DCFG base address
> @@ -123,6 +139,12 @@ holdoff_release:
> rev r6, r6
> str r6, [r4, #DCFG_CCSR_SCRATCHRW1]
>
> +   mov r0, r1
> +   bl  psci_get_cpu_stack_top
> +   sub r0, r0, #PSCI_CPU_STATUS_OFFSET
> +   mov r5, #PSCI_CPU_STATUS_ON
> +   str r5, [r0]
> +
> isb
> dsb
>
> @@ -137,6 +159,13 @@ out_psci_cpu_on:
>  psci_cpu_off:
> bl  psci_cpu_off_common
>
> +   bl  psci_get_cpu_id
> +   bl  psci_get_cpu_stack_top
> +   sub r0, r0, #PSCI_CPU_STATUS_OFFSET
> +   mov r5, #PSCI_CPU_STATUS_OFF
> +   str r5, [r0]
> +   dsb

psci_cpu_off_common flushes and disables caches, and turns off SMP.
So the code you're adding might not work as expected? ARM folks
might know more.

The rest looks good, though I expect them to be pulled out into
common helpers and rewritten in C. :)

Regards
ChenYu

> +
>  1: wfi
> b   1b
>
> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
> index bedcd30..89a1ba5 100644
> --- a/arch/arm/include/asm/psci.h
> +++ b/arch/arm/include/asm/psci.h
> @@ -67,6 +67,11 @@
>  #define PSCI_PERCPU_STACK_SIZE 0x400
>  #define PSCI_TARGET_PC_OFFSET  (PSCI_PERCPU_STACK_SIZE - 4)
>  #define PSCI_CONTEXT_ID_OFFSET (PSCI_PERCPU_STACK_SIZE - 8)
> +#define PSCI_CPU_STATUS_OFFSET (PSCI_PERCPU_STACK_SIZE - 12)
> +
> +#define PSCI_CPU_STATUS_OFF0
> +#define PSCI_CPU_STATUS_ON 1
> +#define PSCI_CPU_STATUS_ON_PENDING 2
>
>  #ifndef __ASSEMBLY__
>  int psci_update_dt(void *fdt);
> --
> 2.1.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 8/8] ARMv7: PSCI: ls102xa: move secure text section into OCRAM

[Chen-Yu Tsai]

On Tue, Jun 14, 2016 at 3:01 PM,   wrote:
> From: Hongbo Zhang 
>
> LS1021 offers two secure OCRAM blocks for trustzone.
> This patch moves all the secure text sections into the OCRAM.
>
> Signed-off-by: Wang Dongsheng 
> Signed-off-by: Hongbo Zhang 
> ---
>  arch/arm/include/asm/arch-ls102xa/config.h | 2 +-
>  include/configs/ls1021atwr.h   | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/arch-ls102xa/config.h 
> b/arch/arm/include/asm/arch-ls102xa/config.h
> index 7a0e4bf..4729044 100644
> --- a/arch/arm/include/asm/arch-ls102xa/config.h
> +++ b/arch/arm/include/asm/arch-ls102xa/config.h
> @@ -10,7 +10,7 @@
>  #define CONFIG_SYS_CACHELINE_SIZE  64
>
>  #define OCRAM_BASE_ADDR0x1000
> -#define OCRAM_SIZE 0x0002
> +#define OCRAM_SIZE 0x0001
>  #define OCRAM_BASE_S_ADDR  0x1001
>  #define OCRAM_S_SIZE   0x0001
>
> diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
> index 9d0c4fe..e6fbd77 100644
> --- a/include/configs/ls1021atwr.h
> +++ b/include/configs/ls1021atwr.h
> @@ -12,6 +12,8 @@
>  #define CONFIG_ARMV7_PSCI
>  #define CONFIG_ARMV7_PSCI_1_0
>
> +#define CONFIG_ARMV7_SECURE_BASE   OCRAM_BASE_S_ADDR
> +
>  #define CONFIG_SYS_FSL_CLK
>
>  #define CONFIG_DISPLAY_CPUINFO
> --
> 2.1.4
>

The patch itself looks good. Though I wonder if there's some register
you need to configure to split access to the 2 SRAM blocks? If they
are both secure-only, then everything's fine.

Reviewed-by: Chen-Yu Tsai 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 5/8] ARMv7: PSCI: ls102xa: check target CPU ID before further operations

[Chen-Yu Tsai]

On Tue, Jun 14, 2016 at 3:01 PM,   wrote:
> From: Hongbo Zhang 
>
> The input parameter CPU ID needs to be validated before furher oprations such
> as CPU_ON, this patch introduces the function to do this.
>
> Signed-off-by: Wang Dongsheng 
> Signed-off-by: Hongbo Zhang 
> ---
>  arch/arm/cpu/armv7/ls102xa/psci.S | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S 
> b/arch/arm/cpu/armv7/ls102xa/psci.S
> index 548c507..a4482e4 100644
> --- a/arch/arm/cpu/armv7/ls102xa/psci.S
> +++ b/arch/arm/cpu/armv7/ls102xa/psci.S
> @@ -25,6 +25,34 @@
>  #defineONE_MS  (GENERIC_TIMER_CLK / 1000)
>  #defineRESET_WAIT  (30 * ONE_MS)
>

A note describing the arguments, the return value, and any other affected
registers would be nice. For example r1 is clobbered.

> +.globl psci_check_target_cpu_id
> +psci_check_target_cpu_id:

You probably don't need .globl.

Also you can use ENTRY() or LENTRY() here. These and ENDPROC() below
are defined in linux/linkage.h

> +   @ Get the real CPU number
> +   and r0, r1, #0xff
> +
> +   @ Verify bit[31:24], bits must be zero.
> +   tst r1, #0xff00
> +   bne out_psci_invalid_target_cpu_id
> +
> +   @ Verify Affinity level 2: Cluster, only one cluster in LS1021xa SoC.
> +   tst r1, #0xff
> +   bne out_psci_invalid_target_cpu_id
> +
> +   @ Verify Affinity level 1: Processors, should be in 0xf00 format.
> +   lsr r1, r1, #8
> +   teq r1, #0xf
> +   bne out_psci_invalid_target_cpu_id
> +
> +   @ Verify Affinity level 0: CPU, only 0, 1 are valid values.
> +   cmp r0, #2
> +   bge out_psci_invalid_target_cpu_id
> +
> +   bx  lr
> +
> +out_psci_invalid_target_cpu_id:
> +   mov r0, #ARM_PSCI_RET_INVAL
> +   bx  lr
> +

And you could have an ENDPROC() here.

About the whole function, you could use an extra scratch register,
store ARM_PSCI_RET_INVAL in r0 at the beginning, and directly return
at errors. Kind of like:

if (bit[31:24] != 0)
return ARM_PSCI_RET_INVAL;
if (cluster != 0)
return ARM_PSCI_RET_INVAL;
if (processor != 0xf)
return ARM_PSCI_RET_INVAL;
if (cpu >= 2)
return ARM_PSCI_RET_INVAL;
return cpu;

It's just a different style though. Feel free to keep the current
structure.

The code itself looks good.

Regards
ChenYu

> @ r1 = target CPU
> @ r2 = target PC
>  .globl psci_cpu_on
> @@ -33,7 +61,10 @@ psci_cpu_on:
>
> @ Clear and Get the correct CPU number
> @ r1 = 0xf01
> -   and r1, r1, #0xff
> +   bl  psci_check_target_cpu_id
> +   cmp r0, #ARM_PSCI_RET_INVAL
> +   beq out_psci_cpu_on
> +   mov r1, r0
>
> bl  psci_cpu_on_common
>
> @@ -98,6 +129,7 @@ holdoff_release:
> @ Return
> mov r0, #ARM_PSCI_RET_SUCCESS
>
> +out_psci_cpu_on:
> pop {lr}
> bx  lr
>
> --
> 2.1.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 2/8] ARMv7: PSCI: factor out reusable psci_cpu_on_common

[Hongbo Zhang]

On Tue, Jun 28, 2016 at 10:49 AM, Chen-Yu Tsai  wrote:
> Hi,
>
> On Tue, Jun 14, 2016 at 3:01 PM,   wrote:
>> From: Hongbo Zhang 
>>
>> There are codes for saving target PC in each platform psci_cpu_on routines,
>> these can be factored out as psci_cpu_on_common.
>> Another purpose is that the codes of saving target PC will be changed a bit 
>> and
>> a new context ID will be saved in the following patches, then we can update 
>> the
>> psci_cpu_on_common mainly instead of touching every platform's psci_cpu_on
>> functions more times, this makes it easier for coding and being reviewed.
>>
>> Signed-off-by: Hongbo Zhang 
>> Signed-off-by: Wang Dongsheng 
>> ---
>>  arch/arm/cpu/armv7/ls102xa/psci.S |  5 +
>>  arch/arm/cpu/armv7/mx7/psci.S |  5 +
>>  arch/arm/cpu/armv7/psci.S | 12 
>>  arch/arm/cpu/armv7/sunxi/psci_sun6i.S |  5 +
>>  arch/arm/cpu/armv7/sunxi/psci_sun7i.S |  5 +
>>  arch/arm/mach-tegra/psci.S|  5 +
>>  6 files changed, 17 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S 
>> b/arch/arm/cpu/armv7/ls102xa/psci.S
>> index cf5cd48..548c507 100644
>> --- a/arch/arm/cpu/armv7/ls102xa/psci.S
>> +++ b/arch/arm/cpu/armv7/ls102xa/psci.S
>> @@ -35,10 +35,7 @@ psci_cpu_on:
>> @ r1 = 0xf01
>> and r1, r1, #0xff
>>
>> -   mov r0, r1
>> -   bl  psci_get_cpu_stack_top
>> -   str r2, [r0]
>> -   dsb
>> +   bl  psci_cpu_on_common
>>
>> @ Get DCFG base address
>> movwr4, #(CONFIG_SYS_FSL_GUTS_ADDR & 0x)
>> diff --git a/arch/arm/cpu/armv7/mx7/psci.S b/arch/arm/cpu/armv7/mx7/psci.S
>> index 34c6ab3..74fdc4d 100644
>> --- a/arch/arm/cpu/armv7/mx7/psci.S
>> +++ b/arch/arm/cpu/armv7/mx7/psci.S
>> @@ -29,10 +29,7 @@ psci_arch_init:
>>  psci_cpu_on:
>> push{lr}
>>
>> -   mov r0, r1
>> -   bl  psci_get_cpu_stack_top
>> -   str r2, [r0]
>> -   dsb
>> +   bl  psci_cpu_on_common
>>
>> ldr r2, =psci_cpu_entry
>> bl  imx_cpu_on
>> diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
>> index 8e25300..3b92f1d 100644
>> --- a/arch/arm/cpu/armv7/psci.S
>> +++ b/arch/arm/cpu/armv7/psci.S
>> @@ -253,6 +253,18 @@ ENTRY(psci_enable_smp)
>>  ENDPROC(psci_enable_smp)
>>  .weak psci_enable_smp
>>
>> +/* expects target CPU in r1, target PC in r2 */
>> +ENTRY(psci_cpu_on_common)
>> +   push{lr}
>> +
>> +   mov r0, r1
>> +   bl  psci_get_cpu_stack_top  @ get stack top of target CPU
>> +   str r2, [r0]@ store target PC at stack 
>> top
>> +   dsb
>> +
>> +   pop {pc}
>> +ENDPROC(psci_cpu_on_common)
>> +
>
> Since you are just saving the target PC, why not just name the
> function like that?
>

No, not only saving target PC, you will see later that the newly added
context ID is saved too.
In my previous patches, I save target PC here, and then in later patch
save target ID too, and at last the common function is factored out,
in this way every platform's code are touched too many times.

Copy one paragraph of my cover letter here:
"Move the patch of factoring out psci_cpu_on_common to earlier place 2/8, so
that the following patches can only update the psci_cpu_on_common instead of
touching each platform's psci_cpu_on, this reduces patches size obviously and
make it easier for review."

> See 
> https://github.com/wens/u-boot-sunxi/commit/5a42630107e93bea9aa4da27cc16bdb604993dca
>
>>  ENTRY(psci_cpu_off_common)
>> push{lr}
>>
>> diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S 
>> b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
>> index 90b5bfd..016e491 100644
>> --- a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
>> +++ b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
>> @@ -134,10 +134,7 @@ out:   mcr p15, 0, r7, c1, c1, 0
>>  psci_cpu_on:
>> push{lr}
>>
>> -   mov r0, r1
>> -   bl  psci_get_cpu_stack_top  @ get stack top of target CPU
>> -   str r2, [r0]@ store target PC at stack top
>> -   dsb
>> +   bl  psci_cpu_on_common
>>
>> movwr0, #(SUN6I_CPUCFG_BASE & 0x)
>> movtr0, #(SUN6I_CPUCFG_BASE >> 16)
>> diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S 
>> b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
>> index e15d587..0ebb30e 100644
>> --- a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
>> +++ b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
>> @@ -123,10 +123,7 @@ out:   mcr p15, 0, r7, c1, c1, 0
>>  psci_cpu_on:
>> push{lr}
>>
>> -   mov r0, r1
>> -   bl  psci_get_cpu_stack_top  @ get stack top of target CPU
>> -   str r2, [r0]@ store target PC at stack top
>> -   dsb
>> +   bl  psci_cpu_on_common
>
> The sunxi parts no longer apply. The partial rewrite 

Re: [U-Boot] [PATCH v3 10/12] libfdt: Add overlay application function

[David Gibson]

On Mon, Jun 27, 2016 at 01:40:00PM +0200, Maxime Ripard wrote:
> Hi David,
> 
> On Mon, Jun 27, 2016 at 03:26:07PM +1000, David Gibson wrote:
> > > +static uint32_t overlay_get_target_phandle(const void *fdto, int 
> > > fragment)
> > > +{
> > > + const uint32_t *val;
> > > + int len;
> > > +
> > > + val = fdt_getprop(fdto, fragment, "target", );
> > > + if (!val || (*val == 0x) || (len != sizeof(*val)))
> > > + return 0;
> > 
> > This doesn't distinguish between a missing property (which may
> > indicate a valid overlay using a target-path or some other method)
> > and a badly formatted 'target' property, which is definitely an error
> > in the overlay.
> > 
> > I think those should be treated differently.
> 
> AFAIK, phandles can have any 32 bits values but 0x. In order
> to cover the two cases, we would need to have some error code, but
> that doesn't really work with returning a uint32_t.

Actually phandles can have any value except 0x *or* 0.  So you
can use 0 for "couldn't find" and -1 for "badly formatted".

> Or maybe we can simply remove all the checks but the missing property,
> and let fdt_node_offset_by_phandle deal with the improper values?
> 
> > 
> > > + return fdt32_to_cpu(*val);
> > > +}
> > > +
> > > +static int overlay_get_target(const void *fdt, const void *fdto,
> > > +   int fragment)
> > > +{
> > > + uint32_t phandle;
> > > + const char *path;
> > > +
> > > + /* Try first to do a phandle based lookup */
> > > + phandle = overlay_get_target_phandle(fdto, fragment);
> > > + if (phandle)
> > > + return fdt_node_offset_by_phandle(fdt, phandle);
> > > +
> > > + /* And then a path based lookup */
> > > + path = fdt_getprop(fdto, fragment, "target-path", NULL);
> > > + if (!path)
> > > + return -FDT_ERR_NOTFOUND;
> > > +
> > > + return fdt_path_offset(fdt, path);
> > > +}
> > > +
> > > +static int overlay_phandle_add_offset(void *fdt, int node,
> > > +   const char *name, uint32_t delta)
> > > +{
> > > + const uint32_t *val;
> > > + uint32_t adj_val;
> > > + int len;
> > > +
> > > + val = fdt_getprop(fdt, node, name, );
> > > + if (!val)
> > > + return len;
> > > +
> > > + if (len != sizeof(*val))
> > > + return -FDT_ERR_BADSTRUCTURE;
> > > +
> > > + adj_val = fdt32_to_cpu(*val);
> > > + adj_val += delta;
> > 
> > You should probably check for overflow here.
> > 
> > > +
> > > + return fdt_setprop_inplace_u32(fdt, node, name, adj_val);
> > > +}
> > > +
> > > +static int overlay_adjust_node_phandles(void *fdto, int node,
> > > + uint32_t delta)
> > > +{
> > > + bool found = false;
> > > + int child;
> > > + int ret;
> > > +
> > > + ret = overlay_phandle_add_offset(fdto, node, "phandle", delta);
> > > + if (ret && ret != -FDT_ERR_NOTFOUND)
> > > + return ret;
> > > +
> > > + if (!ret)
> > > + found = true;
> > > +
> > > + ret = overlay_phandle_add_offset(fdto, node, "linux,phandle", delta);
> > > + if (ret && ret != -FDT_ERR_NOTFOUND)
> > > + return ret;
> > 
> > I think the check for phandle vs. linux,phandle should be folded into
> > overlay_phandle_add_offset().
> 
> I created overlay_phandle_add_offset to avoid duplicating the getprop,
> offset, setprop, pattern which I don't think is a good idea.
> 
> And we'll have to have that kind of errors construct anyway to know if
> we modified any of the two, which is a success, or none, which is a
> failure.

Hm.. ok, you convinced me.

> > > + /*
> > > +  * If neither phandle nor linux,phandle have been found return
> > > +  * an error.
> > > +  */
> > > + if (!found && !ret)
> > > + return ret;
> > > +
> > > + fdt_for_each_subnode(fdto, child, node)
> > > + overlay_adjust_node_phandles(fdto, child, delta);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int overlay_adjust_local_phandles(void *fdto, uint32_t delta)
> > > +{
> > > + /*
> > > +  * Start adjusting the phandles from the overlay root
> > > +  */
> > > + return overlay_adjust_node_phandles(fdto, 0, delta);
> > > +}
> > > +
> > > +static int overlay_update_local_node_references(void *fdto,
> > > + int tree_node,
> > > + int fixup_node,
> > > + uint32_t delta)
> > > +{
> > > + int fixup_prop;
> > > + int fixup_child;
> > > + int ret;
> > > +
> > > + fdt_for_each_property_offset(fixup_prop, fdto, fixup_node) {
> > > + const uint32_t *val = NULL;
> > > + uint32_t adj_val, index;
> > > + const char *name;
> > > + int fixup_len;
> > > + int tree_len;
> > > +
> > > + val = fdt_getprop_by_offset(fdto, fixup_prop,
> > > + , _len);
> > > + if (!val)
> > > + return fixup_len;
> > > + index = fdt32_to_cpu(*val);
> > 
> > This still doesn't handle the case of multiple fixups 

Re: [U-Boot] [PATCH v3 04/12] libfdt: Add new headers and defines

[David Gibson]

On Mon, Jun 27, 2016 at 09:25:27AM +0200, Maxime Ripard wrote:
> Hi David,
> 
> On Mon, Jun 27, 2016 at 01:39:06AM +1000, David Gibson wrote:
> > On Fri, Jun 24, 2016 at 04:27:49PM +0200, Maxime Ripard wrote:
> > > The libfdt overlay support introduces a bunch of new includes and
> > > functions.
> > > 
> > > Make sure we are able to build it by adding the needed glue.
> > > 
> > > Signed-off-by: Maxime Ripard 
> > 
> > Is this intended only for downstream u-boot only, or also for upstream
> > libfdt?
> 
> U-Boot only.
> 
> > If it's u-boot only, you don't really need the #ifdef UBOOT.
> 
> Unfortunately, libfdt_env.h is also included by some userspace tools
> in U-Boot, which make use of strtoul while simple_strtoul is not
> defined there (and we should rely on libc's anyway), leading to
> link errors.

Ah, ok.  The ifdef makes sense then.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


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

Re: [U-Boot] [PATCH v3 07/12] libfdt: Add fdt_setprop_inplace_by_index

[David Gibson]

On Mon, Jun 27, 2016 at 11:16:52AM +0200, Maxime Ripard wrote:
> On Mon, Jun 27, 2016 at 01:45:11AM +1000, David Gibson wrote:
> > On Fri, Jun 24, 2016 at 04:27:52PM +0200, Maxime Ripard wrote:
> > > Add a function to modify inplace a property starting from a given index.
> > > 
> > > This is especially useful when the property is an array of values, and you
> > > want to update one of them without changing the DT size.
> > > 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > >  include/libfdt.h | 34 +++---
> > >  lib/libfdt/fdt_wip.c | 13 -
> > >  2 files changed, 39 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/include/libfdt.h b/include/libfdt.h
> > > index 4643be5adf39..2c8a42bcb667 100644
> > > --- a/include/libfdt.h
> > > +++ b/include/libfdt.h
> > > @@ -1032,6 +1032,27 @@ int fdt_size_cells(const void *fdt, int 
> > > nodeoffset);
> > >  /* Write-in-place functions   */
> > >  /**/
> > >  
> > > +/**
> > > + * fdt_setprop_inplace_namelen_by_index - change a property's value,
> > > + *but not its size
> > > + * @fdt: pointer to the device tree blob
> > > + * @nodeoffset: offset of the node whose property to change
> > > + * @name: name of the property to change
> > > + * @namelen: number of characters of name to consider
> > > + * @index: index of the property to change in the array
> > > + * @val: pointer to data to replace the property value with
> > > + * @len: length of the property value
> > > + *
> > > + * Identical to fdt_setprop_inplace(), but modifies the given property
> > > + * starting from the given index, and using only the first characters
> > > + * of the name. It is useful when you want to manipulate only one value 
> > > of
> > > + * an array and you have a string that doesn't end with \0.
> > > + */
> > > +int fdt_setprop_inplace_namelen_by_index(void *fdt, int nodeoffset,
> > > +  const char *name, int namelen,
> > > +  uint32_t index, const void *val,
> > > +  int len);
> > 
> > This looks like a good addition to upstream, but I don't like the
> > name.  I'd suggest fdt_setprop_inplace_namelen_partial() because it
> > only overwrite part of the existing property value.
> 
> Ack.
> 
> > > +
> > >  /**
> > >   * fdt_setprop_inplace - change a property's value, but not its size
> > >   * @fdt: pointer to the device tree blob
> > > @@ -1060,8 +1081,13 @@ int fdt_size_cells(const void *fdt, int 
> > > nodeoffset);
> > >   *   -FDT_ERR_BADSTRUCTURE,
> > >   *   -FDT_ERR_TRUNCATED, standard meanings
> > >   */
> > > -int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
> > > - const void *val, int len);
> > > +static inline int fdt_setprop_inplace(void *fdt, int nodeoffset,
> > > +   const char *name, const void *val,
> > > +   int len)
> > > +{
> > > + return fdt_setprop_inplace_namelen_by_index(fdt, nodeoffset, name,
> > > + strlen(name), 0, val, len);
> > 
> > This effectively removes the error if len is not equal to the existing
> > property length, so that needs to be put back.
> 
> So I'm not really sure what you want me to do.
> 
> I can't check for the property length, since it would prevent that
> function from working, I can't check for the length + index, since we
> might update only a few bytes in the middle, and we want to keep that
> error case.
> 
> Or should I just forgive about merging the two functions and just
> duplicate the two?

No, what I'm suggesting is that fdt_setprop_inplace(), whether or not
it is implemented using fdt_setprop_inplace_partial() *also* checks
that the existing property length exactly matches the replacement
length, and fails otherwise.

Doing this without too much code duplication might involve a private
internal function, or maybe it's just simpler to duplicate.  But those
are the semantics they should have.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


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

Re: [U-Boot] [PATCH v5 3/8] ARMv7: PSCI: update the place of saving target PC

[Chen-Yu Tsai]

On Tue, Jun 14, 2016 at 3:01 PM,   wrote:
> From: Hongbo Zhang 
>
> The legacy code saves target PC at stack top, this patch changes it to stack
> bottom, because we will save more contents for PSCI v1.0, by this way we don't
> need to adjust the stack pointer when more contents are saved.
>
> Signed-off-by: Hongbo Zhang 
> Signed-off-by: Wang Dongsheng 
> ---
>  arch/arm/cpu/armv7/psci.S   | 9 +
>  arch/arm/include/asm/psci.h | 4 
>  2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
> index 3b92f1d..5b235df 100644
> --- a/arch/arm/cpu/armv7/psci.S
> +++ b/arch/arm/cpu/armv7/psci.S
> @@ -259,7 +259,8 @@ ENTRY(psci_cpu_on_common)
>
> mov r0, r1
> bl  psci_get_cpu_stack_top  @ get stack top of target CPU
> -   str r2, [r0]@ store target PC at stack top
> +   sub r5, r0, #PSCI_TARGET_PC_OFFSET
> +   str r2, [r5]@ store target PC

IMO having a separate function for this would be better.
It would be clearer, and easier to reuse or replace.

Also you should save and restore r5 across this function.

> dsb
>
> pop {pc}
> @@ -286,14 +287,13 @@ ENDPROC(psci_cpu_off_common)
>
>  @ expects CPU ID in r0 and returns stack top in r0
>  ENTRY(psci_get_cpu_stack_top)
> -   mov r5, #0x400  @ 1kB of stack per CPU
> +   mov r5, #PSCI_PERCPU_STACK_SIZE @ 1kB of stack per CPU
> mul r0, r0, r5
>
> ldr r5, =psci_text_end  @ end of monitor text
> add r5, r5, #0x2000 @ Skip two pages
> lsr r5, r5, #12 @ Align to start of page
> lsl r5, r5, #12
> -   sub r5, r5, #4  @ reserve 1 word for target PC
> sub r0, r5, r0  @ here's our stack!

This does not apply. r5 was changed to r3.

>
> bx  lr
> @@ -306,7 +306,8 @@ ENTRY(psci_cpu_entry)
>
> bl  psci_get_cpu_id @ CPU ID => r0
> bl  psci_get_cpu_stack_top  @ stack top => r0
> -   ldr r0, [r0]@ target PC at stack top
> +   sub r0, r0, #PSCI_TARGET_PC_OFFSET
> +   ldr r0, [r0]@ get target PC
> b   _do_nonsec_entry
>  ENDPROC(psci_cpu_entry)
>
> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
> index 2367ec0..cb08544 100644
> --- a/arch/arm/include/asm/psci.h
> +++ b/arch/arm/include/asm/psci.h
> @@ -63,6 +63,10 @@
>  #define ARM_PSCI_1_0_FN_STAT_RESIDENCY ARM_PSCI_0_2_FN(16)
>  #define ARM_PSCI_1_0_FN_STAT_COUNT ARM_PSCI_0_2_FN(17)
>
> +/* size of percpu stack, 1kB */
> +#define PSCI_PERCPU_STACK_SIZE 0x400
> +#define PSCI_TARGET_PC_OFFSET  (PSCI_PERCPU_STACK_SIZE - 4)

I think you want PSCI_PERCPU_STACK_SIZE?

A stack starts at 0x400 and goes down to 0x0. You want to store
the target PC at 0x0, not 0x4.

Regards
ChenYu

> +
>  #ifndef __ASSEMBLY__
>  int psci_update_dt(void *fdt);
>  void psci_board_init(void);
> --
> 2.1.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 4/8] ARMv7: PSCI: add codes to save context ID for CPU_ON

[Chen-Yu Tsai]

Hi,

On Tue, Jun 14, 2016 at 3:01 PM,   wrote:
> From: Hongbo Zhang 
>
> According to latest PSCI specification, the context ID is needed by CPU_ON.
> This patch saves context ID to the second lowest address of the stack (next to
> where target PC is saved), and restores it to r0 when needed while target CPU
> booting up.

Interesting. This doesn't seem to be used by Linux yet. This led me using r3
as a scratch register. See below.

>
> Signed-off-by: Hongbo Zhang 
> Signed-off-by: Wang Dongsheng 
> ---
>  arch/arm/cpu/armv7/nonsec_virt.S | 7 +++
>  arch/arm/cpu/armv7/psci.S| 4 +++-
>  arch/arm/include/asm/psci.h  | 1 +
>  3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv7/nonsec_virt.S 
> b/arch/arm/cpu/armv7/nonsec_virt.S
> index b7563ed..6566643 100644
> --- a/arch/arm/cpu/armv7/nonsec_virt.S
> +++ b/arch/arm/cpu/armv7/nonsec_virt.S
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  .arch_extension sec
>  .arch_extension virt
> @@ -89,6 +90,12 @@ _secure_monitor:
> movne   r4, #0
> mcrrne  p15, 4, r4, r4, c14 @ Reset CNTVOFF to zero
>  1:
> +#ifdef CONFIG_ARMV7_PSCI
> +   bl  psci_get_cpu_id
> +   bl  psci_get_cpu_stack_top
> +   sub r0, r0, #PSCI_CONTEXT_ID_OFFSET
> +   ldr r0, [r0]@ get Context ID in r0

You should do this in psci_cpu_entry, for a couple of reasons:

  - That is also where the target PC is loaded.

  - It is PSCI specific.

  - All first time SMC calls would go through _secure_monitor.
This includes when U-boot jumps into the kernel through
_do_nonsec_entry, at which point you don't have a proper value
stored, while U-boot passes 0 here. See:

  
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/lib/bootm.c;h=0838d89907b9a2eb81f4ebb31d8c045e031c5e11;hb=HEAD#l324

> +#endif
> mov lr, ip
> mov ip, #(F_BIT | I_BIT | A_BIT)@ Set A, I and F
> tst lr, #1  @ Check for Thumb PC
> diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
> index 5b235df..3ba9e51 100644
> --- a/arch/arm/cpu/armv7/psci.S
> +++ b/arch/arm/cpu/armv7/psci.S
> @@ -253,7 +253,7 @@ ENTRY(psci_enable_smp)
>  ENDPROC(psci_enable_smp)
>  .weak psci_enable_smp
>
> -/* expects target CPU in r1, target PC in r2 */
> +/* expects target CPU in r1, target PC in r2, target conetxt ID in r3 */
>  ENTRY(psci_cpu_on_common)
> push{lr}
>
> @@ -261,6 +261,8 @@ ENTRY(psci_cpu_on_common)
> bl  psci_get_cpu_stack_top  @ get stack top of target CPU

r3 get overwritten in psci_get_cpu_stack_top in

  
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=dae08d228122e4ad296077106520a4db3ca17872

Some of the functions now follow the ARM calling conventions.
You should save r3 and possibly other registers across any function
calls.

Regards
ChenYu

> sub r5, r0, #PSCI_TARGET_PC_OFFSET
> str r2, [r5]@ store target PC
> +   sub r5, r0, #PSCI_CONTEXT_ID_OFFSET
> +   str r3, [r5]@ store target context ID
> dsb
>
> pop {pc}
> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
> index cb08544..bedcd30 100644
> --- a/arch/arm/include/asm/psci.h
> +++ b/arch/arm/include/asm/psci.h
> @@ -66,6 +66,7 @@
>  /* size of percpu stack, 1kB */
>  #define PSCI_PERCPU_STACK_SIZE 0x400
>  #define PSCI_TARGET_PC_OFFSET  (PSCI_PERCPU_STACK_SIZE - 4)
> +#define PSCI_CONTEXT_ID_OFFSET (PSCI_PERCPU_STACK_SIZE - 8)
>
>  #ifndef __ASSEMBLY__
>  int psci_update_dt(void *fdt);
> --
> 2.1.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 2/8] ARMv7: PSCI: factor out reusable psci_cpu_on_common

[Chen-Yu Tsai]

Hi,

On Tue, Jun 14, 2016 at 3:01 PM,   wrote:
> From: Hongbo Zhang 
>
> There are codes for saving target PC in each platform psci_cpu_on routines,
> these can be factored out as psci_cpu_on_common.
> Another purpose is that the codes of saving target PC will be changed a bit 
> and
> a new context ID will be saved in the following patches, then we can update 
> the
> psci_cpu_on_common mainly instead of touching every platform's psci_cpu_on
> functions more times, this makes it easier for coding and being reviewed.
>
> Signed-off-by: Hongbo Zhang 
> Signed-off-by: Wang Dongsheng 
> ---
>  arch/arm/cpu/armv7/ls102xa/psci.S |  5 +
>  arch/arm/cpu/armv7/mx7/psci.S |  5 +
>  arch/arm/cpu/armv7/psci.S | 12 
>  arch/arm/cpu/armv7/sunxi/psci_sun6i.S |  5 +
>  arch/arm/cpu/armv7/sunxi/psci_sun7i.S |  5 +
>  arch/arm/mach-tegra/psci.S|  5 +
>  6 files changed, 17 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S 
> b/arch/arm/cpu/armv7/ls102xa/psci.S
> index cf5cd48..548c507 100644
> --- a/arch/arm/cpu/armv7/ls102xa/psci.S
> +++ b/arch/arm/cpu/armv7/ls102xa/psci.S
> @@ -35,10 +35,7 @@ psci_cpu_on:
> @ r1 = 0xf01
> and r1, r1, #0xff
>
> -   mov r0, r1
> -   bl  psci_get_cpu_stack_top
> -   str r2, [r0]
> -   dsb
> +   bl  psci_cpu_on_common
>
> @ Get DCFG base address
> movwr4, #(CONFIG_SYS_FSL_GUTS_ADDR & 0x)
> diff --git a/arch/arm/cpu/armv7/mx7/psci.S b/arch/arm/cpu/armv7/mx7/psci.S
> index 34c6ab3..74fdc4d 100644
> --- a/arch/arm/cpu/armv7/mx7/psci.S
> +++ b/arch/arm/cpu/armv7/mx7/psci.S
> @@ -29,10 +29,7 @@ psci_arch_init:
>  psci_cpu_on:
> push{lr}
>
> -   mov r0, r1
> -   bl  psci_get_cpu_stack_top
> -   str r2, [r0]
> -   dsb
> +   bl  psci_cpu_on_common
>
> ldr r2, =psci_cpu_entry
> bl  imx_cpu_on
> diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
> index 8e25300..3b92f1d 100644
> --- a/arch/arm/cpu/armv7/psci.S
> +++ b/arch/arm/cpu/armv7/psci.S
> @@ -253,6 +253,18 @@ ENTRY(psci_enable_smp)
>  ENDPROC(psci_enable_smp)
>  .weak psci_enable_smp
>
> +/* expects target CPU in r1, target PC in r2 */
> +ENTRY(psci_cpu_on_common)
> +   push{lr}
> +
> +   mov r0, r1
> +   bl  psci_get_cpu_stack_top  @ get stack top of target CPU
> +   str r2, [r0]@ store target PC at stack top
> +   dsb
> +
> +   pop {pc}
> +ENDPROC(psci_cpu_on_common)
> +

Since you are just saving the target PC, why not just name the
function like that?

See 
https://github.com/wens/u-boot-sunxi/commit/5a42630107e93bea9aa4da27cc16bdb604993dca

>  ENTRY(psci_cpu_off_common)
> push{lr}
>
> diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S 
> b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
> index 90b5bfd..016e491 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
> +++ b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
> @@ -134,10 +134,7 @@ out:   mcr p15, 0, r7, c1, c1, 0
>  psci_cpu_on:
> push{lr}
>
> -   mov r0, r1
> -   bl  psci_get_cpu_stack_top  @ get stack top of target CPU
> -   str r2, [r0]@ store target PC at stack top
> -   dsb
> +   bl  psci_cpu_on_common
>
> movwr0, #(SUN6I_CPUCFG_BASE & 0x)
> movtr0, #(SUN6I_CPUCFG_BASE >> 16)
> diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S 
> b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
> index e15d587..0ebb30e 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
> +++ b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
> @@ -123,10 +123,7 @@ out:   mcr p15, 0, r7, c1, c1, 0
>  psci_cpu_on:
> push{lr}
>
> -   mov r0, r1
> -   bl  psci_get_cpu_stack_top  @ get stack top of target CPU
> -   str r2, [r0]@ store target PC at stack top
> -   dsb
> +   bl  psci_cpu_on_common

The sunxi parts no longer apply. The partial rewrite in C has
landed in master.

Regards
ChenYu

>
> movwr0, #(SUN7I_CPUCFG_BASE & 0x)
> movtr0, #(SUN7I_CPUCFG_BASE >> 16)
> diff --git a/arch/arm/mach-tegra/psci.S b/arch/arm/mach-tegra/psci.S
> index b836da1..8a0147c 100644
> --- a/arch/arm/mach-tegra/psci.S
> +++ b/arch/arm/mach-tegra/psci.S
> @@ -90,10 +90,7 @@ ENDPROC(psci_cpu_off)
>  ENTRY(psci_cpu_on)
> push{lr}
>
> -   mov r0, r1
> -   bl  psci_get_cpu_stack_top  @ get stack top of target CPU
> -   str r2, [r0]@ store target PC at stack top
> -   dsb
> +   bl  psci_cpu_on_common
>
> ldr r6, =TEGRA_RESET_EXCEPTION_VECTOR
> ldr r5, =psci_cpu_entry
> --
> 2.1.4
>
___
U-Boot mailing list

Re: [U-Boot] [PATCH 2/2] arm64: add better spin-table support

[Chen-Yu Tsai]

Hi,

On Mon, Jun 27, 2016 at 6:47 PM, Andre Przywara  wrote:
> Hi Masahiro,
>
> On 25/06/16 05:08, Masahiro Yamada wrote:
>> Hi Andre,
>>
>>
>> 2016-06-19 19:33 GMT+09:00 André Przywara :
>>> Hi,
>>>
>>> On 19/06/16 09:57, Masahiro Yamada wrote:
 2016-06-18 18:40 GMT+09:00 Linus Walleij :
> On Fri, Jun 17, 2016 at 2:51 PM, Masahiro Yamada
>  wrote:
>
>> There are two enable methods supported by ARM64 Linux; psci and
>> spin-table.  The latter is simpler and easier to use for quick SoC
>> bring-up.
>>
>> So, I used the spin-table for my first ARMv8 SoC porting, but I
>> found its support in U-Boot was poor.  It is true there exists a
>> code fragment for the spin code in arch/arm/cpu/armv8/start.S,
>> but I see some problems:
>
> Is part of the motivation for this approach to boot an ARMv8 system
> without using the ARM Trusted Firmware?
>
> Yours,
> Linus Walleij

 Yes, exactly.

 It would be the best choice
 to switch over to PSCI with ATF in a long run,
 but, I decided to use spin-table for the initial SoC bring-up
 because of tight schedule.
>>>
>>> So if you don't have an ATF port ready, why not use U-Boot's PSCI
>>> implementation meanwhile? I think there are efforts underway to make
>>> PSCI enablement for random new boards a walk in the park (by making the
>>> PSCI support as generic as possible, CCing Chen-Yu for this).
>>
>>
>> So, you mean U-Boot can serve PSCI for ARMv8 SoCs without ATF, right?
>> (and efforts underway for further improvement)
>
> Yes, if I am not mistaken then there are patches floating around to
> achieve this.

The first part of the PSCI rework is already in master.
The second part is here:

http://lists.denx.de/pipermail/u-boot/2016-June/258484.html

Or a rebased version:

https://github.com/wens/u-boot-sunxi/tree/psci-improve-part2

>> I know PSCI support is available for ARMv7
>> (arch/arm/cpu/armv7/psci.S),
>> but I could not find PSCI implementation
>> in arch/arm/cpu/armv8/ directory in the mainline U-Boot.
>
> I think that's work in progress (as in "on the ML").

My work is still focused on ARMv7. However, with a lot of the code
rewritten in C and modularized, I see no reason it could be moved
up to arch/arm and reused for ARMv8. Same probably goes for the
non-secure related stuff, but I haven't looked into those yet.

The remaining bits of assembly for PSCI are:

  - exception vector table
  - PSCI secure monitor entry
  - stack setup
  - CPU entry function
  - ARMv7(?) SMP toggling (can be done in C with inline assembly)
  - ARMv7 specific cache flush

My only ARMv8 board (Pine64) is still gathering dust, and Andre
is already working on an ATF port, so it's unlikely I will spend
time there. Also I'm very unfamiliar with ARMv8.

>> I checked Chen-Yu's patches on Patchwork,
>> but I think they are mostly for improvement of ARMv7 PSCI support.
>>
>> If I am missing something,
>> could you point me to the reference, please?
>
> I think you found this yourself already in that other mail of yours?
>
>>> IIRC the spin-table boot method was just introduced to cope with cores
>>> that don't have EL3 and thus cannot provide PSCI services the normal way
>>> (and that don't want to or cannot sacrifice EL2 for that).
>>> So I am a bit wary of proliferating this SMP method.
>>
>> Proliferating?
>>
>> Many of ARM 32bit SoCs have vendor-specific SMP methods.
>
> Yes, and this is a massive PITA, but hard to change now.

Get everyone on board with PSCI? :)

Regards
ChenYu

>> On the other hand, ARM64 only has two methods; psci and spin-table.
>
> For a reason: Actually we just wanted to have PSCI only, but it turns
> out that it's not easily possible on cores that don't implement EL3
> (which is architecturally allowed and also implemented).
> So spin-table support was added to provide a fall-back for those cases.
> But if you have the choice, then PSCI is your friend.
> Please note that any support for another SMP method is very unlikely to
> ever get merged into upstream Linux.
>
>> Is this a problem?
>
> As mentioned, if you have a proper PSCI framework (as we are about to
> get for U-Boot and which ATF already provides), adding SMP support is
> not more involved than implementing spin tables. After all it's about
> specifying the pen address and possibly providing per-core power hooks.
>
> Cheers,
> Andre.
>
>>> Wouldn't it be better to help making U-Boot's PSCI stack as easy to use
>>> as possible? I don't see technical reasons that adding PSCI support for
>>> a board should be harder or more involved than adding spin-table support
>>> - in the end you need to tell it about the SMP pen, maybe providing (or
>>> faking?) reset and shutdown for 0.2 compliance.
>>
>>
>> Right.
>>
>> My motivation is to bring up Linux quickly
>> before ATF becomes ready.
>>
>> From your 

Re: [U-Boot] [RFC PATCH v1] usb: spl: fix USB errata for FSL SPL targets

[Marek Vasut]

On 06/28/2016 01:02 AM, York Sun wrote:
> Commit 9262367 moved USB errata workaround to a C file but didn't
> build it for SPL targets.
> 
> Signed-off-by: York Sun 
> CC: Sriram Dash 
> CC: Rajesh Bhagat 
> 
> ---
> Please review this patch. It fixed the compiling errors introduced by
> 9262367. Not sure if this is the way USB errata should be handled.
> 
>  drivers/Makefile| 7 +++
>  drivers/usb/common/Makefile | 8 ++--
>  include/configs/km/kmp204x-common.h | 1 +
>  3 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 1723958..88774ba 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -39,6 +39,13 @@ obj-$(CONFIG_OMAP_USB_PHY) += usb/phy/
>  obj-$(CONFIG_SPL_SATA_SUPPORT) += block/
>  obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += block/
>  obj-$(CONFIG_SPL_MMC_SUPPORT) += block/
> +ifdef CONFIG_USB_EHCI_FSL
> +CONFIG_SPL_USB_ERRATA = y
> +endif
> +ifdef CONFIG_USB_XHCI_FSL
> +CONFIG_SPL_USB_ERRATA = y
> +endif
> +obj-$(CONFIG_SPL_USB_ERRATA) += usb/common/

I really dislike the naming here, I'd say just do

obj-$(CONFIG_USB_EHCI_FSL) += usb/common/
obj-$(CONFIG_USB_XHCI_FSL) += usb/common/

>  else
>  
> diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
> index aee7e32..f073e1c 100644
> --- a/drivers/usb/common/Makefile
> +++ b/drivers/usb/common/Makefile
> @@ -4,5 +4,9 @@
>  #
>  
>  obj-$(CONFIG_DM_USB) += common.o
> -obj-$(CONFIG_USB_EHCI_FSL) += fsl-dt-fixup.o fsl-errata.o
> -obj-$(CONFIG_USB_XHCI_FSL) += fsl-dt-fixup.o fsl-errata.o
> +obj-$(CONFIG_USB_EHCI_FSL) += fsl-errata.o
> +obj-$(CONFIG_USB_XHCI_FSL) += fsl-errata.o
> +ifndef CONFIG_SPL_BUILD
> +obj-$(CONFIG_USB_EHCI_FSL) += fsl-dt-fixup.o
> +obj-$(CONFIG_USB_XHCI_FSL) += fsl-dt-fixup.o
> +endif

Either the filename is misnamed or this is real broken design.
I would expect that a filename with -dt- in it's name should
depend on CONFIG_*FDT* , but not on CONFIG_SPL_BUILD.

> diff --git a/include/configs/km/kmp204x-common.h 
> b/include/configs/km/kmp204x-common.h
> index 028623d..5bdda22 100644
> --- a/include/configs/km/kmp204x-common.h
> +++ b/include/configs/km/kmp204x-common.h
> @@ -406,6 +406,7 @@ int get_scl(void);
>  #endif
>  
>  #define __USB_PHY_TYPE   utmi
> +#define CONFIG_USB_EHCI_FSL
>  
>  /*
>   * Environment Configuration
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 0/3] Add generic ioremap / iounmap defines

[Masahiro Yamada]

I ran Buildman for the whole series, and I did not see any regression.

01: Merge branch 'master' of git://git.denx.de/u-boot-uniphier
  openrisc:  +   openrisc-generic
   arc:  +   tb100 axs101 axs103
  blackfin:  +   bf533-stamp cm-bf527
   arm:  +   socfpga_is1
   powerpc:  +   P1022DS_36BIT_NAND T2080QDS_SPIFLASH T1042RDB_PI_SPIFLASH 
P1010RDB-PA_36BIT_NAND P1010RDB-PB_SDCARD T1042D4RDB_NAND T4240RDB_SDCARD 
P1010RDB-PB_36BIT_NAND P1022DS_36BIT_SDCARD P1010RDB-PB_36BIT_SDCARD 
P1022DS_NAND T4160QDS_NAND T1042RDB_PI_NAND T2080RDB_NAND P1022DS_SDCARD 
T1042RDB_PI_SDCARD T2081QDS_NAND T4160QDS_SDCARD T2080QDS_SDCARD 
T4240QDS_SDCARD P1010RDB-PA_SPIFLASH T1040RDB_SDCARD B4860QDS_NAND 
P1010RDB-PA_36BIT_SDCARD T1040D4RDB_SDCARD T1040D4RDB_SPIFLASH T2080QDS_NAND 
T1040D4RDB_NAND P1010RDB-PB_SPIFLASH P1010RDB-PA_NAND T1040RDB_SPIFLASH kmcoge4 
T2081QDS_SDCARD T2081QDS_SPIFLASH T4240QDS_NAND B4420QDS_NAND T1040RDB_NAND 
P1010RDB-PA_SDCARD T2080RDB_SPIFLASH P1010RDB-PB_NAND T1042D4RDB_SPIFLASH 
P1022DS_SPIFLASH T1042D4RDB_SDCARD kmlion1 P1022DS_36BIT_SPIFLASH 
P1010RDB-PB_36BIT_SPIFLASH T2080RDB_SDCARD P1010RDB-PA_36BIT_SPIFLASH
 [snip lots of error messages we have in the mainline]
02: types.h: move and redefine resource_size_t
03: arm, nds32, sh: remove useless ioremap()/iounmap() defines
04: linux/io.h: add generic ioremap()/iounmap() defines


Changes in v2:
  - Use #ifndef CONFIG_HAVE_ARCH_IOREMAP instead of #ifndef CONFIG_MIPS

Masahiro Yamada (3):
  types.h: move and redefine resource_size_t
  arm, nds32, sh: remove useless ioremap()/iounmap() defines
  linux/io.h: add generic ioremap()/iounmap() defines

 arch/Kconfig |  4 
 arch/arm/include/asm/io.h| 34 --
 arch/arm/include/asm/types.h |  1 -
 arch/nds32/include/asm/io.h  | 34 --
 arch/sh/include/asm/io.h | 33 -
 include/linux/io.h   | 16 
 include/linux/types.h|  4 
 7 files changed, 24 insertions(+), 102 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH v2 1/3] types.h: move and redefine resource_size_t

[Masahiro Yamada]

Currently, this is only defined in arch/arm/include/asm/types.h,
so move it to include/linux/types.h to make it available for all
architectures.

I defined it with phys_addr_t as Linux does.  I needed to surround
the define with #ifdef __KERNEL__ ... #endif to avoid build errors
in tools building.  (Host tools should not include 
in the first place, but this is already messy in U-Boot...)

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/include/asm/types.h | 1 -
 include/linux/types.h| 4 
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
index d108915..9af7353 100644
--- a/arch/arm/include/asm/types.h
+++ b/arch/arm/include/asm/types.h
@@ -71,5 +71,4 @@ typedef u32 dma_addr_t;
 
 #endif /* __KERNEL__ */
 
-typedef unsigned long resource_size_t;
 #endif
diff --git a/include/linux/types.h b/include/linux/types.h
index 6f75be4..416fa66 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -124,6 +124,10 @@ typedef__UINT64_TYPE__ u_int64_t;
 typedef__INT64_TYPE__  int64_t;
 #endif
 
+#ifdef __KERNEL__
+typedef phys_addr_t resource_size_t;
+#endif
+
 /*
  * Below are truly Linux-specific types that should never collide with
  * any application/library that wants linux/types.h.
-- 
1.9.1

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

[U-Boot] [PATCH v2 3/3] linux/io.h: add generic ioremap()/iounmap() defines

[Masahiro Yamada]

For most of architectures in U-Boot, virtual address is straight
mapped to physical address.  So, it makes sense to have generic
defines of ioremap and friends in .

All of them are just empty and will disappear at compile time, but
they will be helpful to implement drivers which are counterparts of
Linux ones.

I notice MIPS already has its own implementation, so I added a
Kconfig symbol CONFIG_HAVE_ARCH_IOREMAP which MIPS (and maybe
Sandbox as well) can select.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Use #ifndef CONFIG_HAVE_ARCH_IOREMAP instead of #ifndef CONFIG_MIPS

 arch/Kconfig   |  4 
 include/linux/io.h | 16 
 2 files changed, 20 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 566f044..8090a45 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1,6 +1,9 @@
 config CREATE_ARCH_SYMLINK
bool
 
+config HAVE_ARCH_IOREMAP
+   bool
+
 choice
prompt "Architecture select"
default SANDBOX
@@ -33,6 +36,7 @@ config MICROBLAZE
 
 config MIPS
bool "MIPS architecture"
+   select HAVE_ARCH_IOREMAP
select HAVE_PRIVATE_LIBGCC
select SUPPORT_OF_CONTROL
 
diff --git a/include/linux/io.h b/include/linux/io.h
index 1b36a22..a104b7e 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -5,6 +5,22 @@
 #ifndef _LINUX_IO_H
 #define _LINUX_IO_H
 
+#include 
+#include 
 #include 
 
+#ifndef CONFIG_HAVE_ARCH_IOREMAP
+static inline void __iomem *ioremap(resource_size_t offset,
+   resource_size_t size)
+{
+   return (void __iomem *)(unsigned long)offset;
+}
+
+static inline void iounmap(void __iomem *addr)
+{
+}
+
+#define devm_ioremap(dev, offset, size)ioremap(offset, size)
+#endif
+
 #endif /* _LINUX_IO_H */
-- 
1.9.1

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

[U-Boot] [PATCH v2 2/3] arm, nds32, sh: remove useless ioremap()/iounmap() defines

[Masahiro Yamada]

These defines are valid only when iomem_valid_addr is defined,
but I do not see such defines anywhere.  Remove.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/include/asm/io.h   | 34 --
 arch/nds32/include/asm/io.h | 34 --
 arch/sh/include/asm/io.h| 33 -
 3 files changed, 101 deletions(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 9d185a6..6121f1d 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -292,40 +292,6 @@ static inline void __raw_readsl(unsigned long addr, void 
*data, int longlen)
 #define readsb(a, d, s)__raw_readsb((unsigned long)a, d, s)
 
 /*
- * ioremap and friends.
- *
- * ioremap takes a PCI memory address, as specified in
- * linux/Documentation/IO-mapping.txt.  If you want a
- * physical address, use __ioremap instead.
- */
-extern void * __ioremap(unsigned long offset, size_t size, unsigned long 
flags);
-extern void __iounmap(void *addr);
-
-/*
- * Generic ioremap support.
- *
- * Define:
- *  iomem_valid_addr(off,size)
- *  iomem_to_phys(off)
- */
-#ifdef iomem_valid_addr
-#define __arch_ioremap(off,sz,nocache) \
- ({\
-   unsigned long _off = (off), _size = (sz);   \
-   void *_ret = (void *)0; \
-   if (iomem_valid_addr(_off, _size))  \
-   _ret = __ioremap(iomem_to_phys(_off),_size,nocache);\
-   _ret;   \
- })
-
-#define __arch_iounmap __iounmap
-#endif
-
-#define ioremap(off,sz)__arch_ioremap((off),(sz),0)
-#define ioremap_nocache(off,sz)__arch_ioremap((off),(sz),1)
-#define iounmap(_addr) __arch_iounmap(_addr)
-
-/*
  * DMA-consistent mapping functions.  These allocate/free a region of
  * uncached, unwrite-buffered mapped memory space for use with DMA
  * devices.  This is the "generic" version.  The PCI specific version
diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h
index 04708e9..b2c4d0e 100644
--- a/arch/nds32/include/asm/io.h
+++ b/arch/nds32/include/asm/io.h
@@ -344,40 +344,6 @@ static inline void writesl(unsigned int *addr, const void 
* data, int longlen)
 #define insl_p(port, to, len)  insl(port, to, len)
 
 /*
- * ioremap and friends.
- *
- * ioremap takes a PCI memory address, as specified in
- * linux/Documentation/IO-mapping.txt.  If you want a
- * physical address, use __ioremap instead.
- */
-extern void *__ioremap(unsigned long offset, size_t size, unsigned long flags);
-extern void __iounmap(void *addr);
-
-/*
- * Generic ioremap support.
- *
- * Define:
- *  iomem_valid_addr(off,size)
- *  iomem_to_phys(off)
- */
-#ifdef iomem_valid_addr
-#define __arch_ioremap(off, sz, nocache)   \
-({ \
-   unsigned long _off = (off), _size = (sz);   \
-   void *_ret = (void *)0; \
-   if (iomem_valid_addr(_off, _size))  \
-   _ret = __ioremap(iomem_to_phys(_off), _size, 0);\
-   _ret;   \
-})
-
-#define __arch_iounmap __iounmap
-#endif
-
-#define ioremap(off, sz)   __arch_ioremap((off), (sz), 0)
-#define ioremap_nocache(off, sz)   __arch_ioremap((off), (sz), 1)
-#define iounmap(_addr) __arch_iounmap(_addr)
-
-/*
  * DMA-consistent mapping functions.  These allocate/free a region of
  * uncached, unwrite-buffered mapped memory space for use with DMA
  * devices.  This is the "generic" version.  The PCI specific version
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 0a00db3..5dc27be 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -128,39 +128,6 @@ extern void __raw_readsl(unsigned int addr, void *data, 
int longlen);
 #define in_8(port) inb(port)
 #define in_le16(port)  inw(port)
 #define in_le32(port)  inl(port)
-/*
- * ioremap and friends.
- *
- * ioremap takes a PCI memory address, as specified in
- * linux/Documentation/IO-mapping.txt.  If you want a
- * physical address, use __ioremap instead.
- */
-extern void *__ioremap(unsigned long offset, size_t size, unsigned long flags);
-extern void __iounmap(void *addr);
-
-/*
- * Generic ioremap support.
- *
- * Define:
- *  iomem_valid_addr(off,size)
- *  iomem_to_phys(off)
- */
-#ifdef iomem_valid_addr
-#define __arch_ioremap(off, sz, nocache)   \
-({ \
-   unsigned long 

Re: [U-Boot] [PATCH 3/3] linux/io.h: add generic ioremap()/iounmap() defines

[Masahiro Yamada]

Hi Daniel,

2016-06-27 18:57 GMT+09:00 Daniel Schwierzeck :
>
>
> Am 27.06.2016 um 10:32 schrieb Masahiro Yamada:
>> For most of architectures in U-Boot, virtual address is straight
>> mapped to physical address.  So, it makes sense to have generic
>> defines of ioremap and friends in .
>>
>> All of them are just empty and will disappear at compile time, but
>> they will be helpful to implement drivers which are counterparts of
>> Linux ones.
>>
>> I notice MIPS already has its own implementation, so I surrounded
>> the defines with #ifndef CONFIG_MIPS ... #endif.  I guess Sandbox
>> will need its own implementation as well.
>>
>
> how about introducing a Kconfig symbol like CONFIG_HAVE_ARCH_IOREMAP
> which MIPS and Sandbox can select?

Good idea!

I will do so in v2.




-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,4/5] fastboot: sparse: implement reserve()

[Tom Rini]

On Tue, Jun 07, 2016 at 11:19:38AM -0700, Steve Rae wrote:

> In order to process the CHUNK_TYPE_DONT_CARE properly, there is
> a requirement to be able to 'reserve' a specified number of blocks
> in the storage media. Because of the special handling of "bad blocks"
> in NAND devices, this is implemented in a storage abstraction function.
> 
> Signed-off-by: Steve Rae 
> Reviewed-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 5/5] fastboot: sparse: improve CHUNK_TYPE_FILL write performance

[Tom Rini]

On Tue, Jun 07, 2016 at 11:19:39AM -0700, Steve Rae wrote:

> - increase the size of the fill buffer
> - testing has shown a 10x improvement when the sparse image
>   has large CHUNK_TYPE_FILL chunks
> 
> Signed-off-by: Steve Rae 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] please pull u-boot-samsung master

[Tom Rini]

On Mon, Jun 27, 2016 at 04:13:37PM +0900, Minkyu Kang wrote:

> Dear Tom,
> 
> The following changes since commit 4141e85bcd79c0b9b16def710e527f165107b7af:
> 
>   kbuild: avoid race between dtbs and dt/dt.dtb targets (2016-06-24 17:24:41 
> -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-samsung master
> 
> for you to fetch changes up to ca2ec9adc951cc3798e9b0c3773cdcc613232a22:
> 
>   mmc: dw_mmc: fix the wrong AND operation (2016-06-27 09:43:26 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 3/5] fastboot: sparse: resync common/image-sparse.c (part 2)

[Tom Rini]

On Tue, Jun 07, 2016 at 11:19:37AM -0700, Steve Rae wrote:

> - update fastboot_okay() and fastboot_fail()
> 
> This file originally came from upstream code.
> 
> While retaining the storage abstraction feature, this is the second
> set of the changes required to resync with the
>   cmd_flash_mmc_sparse_img()
> in the file
>   aboot.c
> from
>   
> https://us.codeaurora.org/cgit/quic/la/kernel/lk/plain/app/aboot/aboot.c?h=LE.BR.1.2.1
> 
> Signed-off-by: Steve Rae 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PULL] u-boot-atmel/master -> u-boot/master

[Tom Rini]

On Sun, Jun 26, 2016 at 08:38:41PM +0200, Andreas Bießmann wrote:

> Hi Tom,
> 
> please pull the following into u-boot/master for 2016.07.
> 
> It contains the spl_boot_mode() change from Marek which was delegated partly
> to you and partly to me on patchwork.
> The rest is DT support for some Siemens boards which where sent before MW
> close but missed in my last pull request. I hope you'll take it since it
> touches only the three boards.
> 
> Compile tests are clean, except for them already broken in
> 4141e85bcd79c0b9b16def710e527f165107b7af:
> 
> 01: kbuild: avoid race between dtbs and dt/dt.dtb targets
>arm:  +   omap3_overo igep0030_nand mx31pdk igep0020_nand socfpga_is1
>omap4_sdp4430 omap4_panda
> 
> (some section overflows with my toolchain and socfpga_is1 is broken for
> CONFIG_BOOTDELAY change)
> 
> Andreas
> 
> The following changes since commit 4141e85bcd79c0b9b16def710e527f165107b7af:
> 
>   kbuild: avoid race between dtbs and dt/dt.dtb targets (2016-06-24 17:24:41 
> -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-atmel.git master
> 
> for you to fetch changes up to 8e6e8221c78ed283a45f8598c65ffe4d287dcf42:
> 
>   arm: at91: taurus/axm: add DM and DTS support (2016-06-26 20:17:22 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 2/5] fastboot: sparse: resync common/image-sparse.c (part 1)

[Tom Rini]

On Tue, Jun 07, 2016 at 11:19:36AM -0700, Steve Rae wrote:

> This file originally came from upstream code.
> 
> While retaining the storage abstraction feature, this is the first
> set of the changes required to resync with the
>   cmd_flash_mmc_sparse_img()
> in the file
>   aboot.c
> from
>   
> https://us.codeaurora.org/cgit/quic/la/kernel/lk/plain/app/aboot/aboot.c?h=LE.BR.1.2.1
> 
> Signed-off-by: Steve Rae 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/5] fastboot: sparse: remove session-id logic

[Tom Rini]

On Tue, Jun 07, 2016 at 11:19:35AM -0700, Steve Rae wrote:

> This "session-id" alogrithm is not required, and currently corrupts
> the stored image whenever more the one "session" is required.
> 
> Signed-off-by: Steve Rae 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] maintainers: new email address

[Tom Rini]

On Mon, Jun 27, 2016 at 04:11:32PM -0700, Steve Rae wrote:

> Update the email address for the boards that I maintain.
> 
> Signed-off-by: Steve Rae 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] maintainers: new email address

[Steve Rae]

Update the email address for the boards that I maintain.

Signed-off-by: Steve Rae 
---
- motivated to do it now because of [1] which closes next Monday
- Tim Kryger has been gone for ~2 years
[1] 
http://www.cypress.com/news/cypress-acquire-broadcom-s-wireless-internet-things-business-0

 board/broadcom/bcm11130/MAINTAINERS| 2 +-
 board/broadcom/bcm11130_nand/MAINTAINERS   | 2 +-
 board/broadcom/bcm23550_w1d/MAINTAINERS| 2 +-
 board/broadcom/bcm28155_ap/MAINTAINERS | 2 +-
 board/broadcom/bcm28155_w1d/MAINTAINERS| 2 +-
 board/broadcom/bcm911360_entphn-ns/MAINTAINERS | 2 +-
 board/broadcom/bcm911360_entphn/MAINTAINERS| 2 +-
 board/broadcom/bcm911360k/MAINTAINERS  | 2 +-
 board/broadcom/bcm958300k-ns/MAINTAINERS   | 2 +-
 board/broadcom/bcm958300k/MAINTAINERS  | 2 +-
 board/broadcom/bcm958305k/MAINTAINERS  | 2 +-
 board/broadcom/bcm958622hr/MAINTAINERS | 2 +-
 12 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/board/broadcom/bcm11130/MAINTAINERS 
b/board/broadcom/bcm11130/MAINTAINERS
index b22e86f..5478350 100644
--- a/board/broadcom/bcm11130/MAINTAINERS
+++ b/board/broadcom/bcm11130/MAINTAINERS
@@ -1,5 +1,5 @@
 BCM11130 BOARD
-M: Steve Rae 
+M: Steve Rae 
 S: Maintained
 F: board/broadcom/bcm28155_ap/
 F: include/configs/bcm_ep_board.h
diff --git a/board/broadcom/bcm11130_nand/MAINTAINERS 
b/board/broadcom/bcm11130_nand/MAINTAINERS
index 881db5b..4cf66b7 100644
--- a/board/broadcom/bcm11130_nand/MAINTAINERS
+++ b/board/broadcom/bcm11130_nand/MAINTAINERS
@@ -1,5 +1,5 @@
 BCM11130_NAND BOARD
-M: Steve Rae 
+M: Steve Rae 
 S: Maintained
 F: board/broadcom/bcm28155_ap/
 F: include/configs/bcm_ep_board.h
diff --git a/board/broadcom/bcm23550_w1d/MAINTAINERS 
b/board/broadcom/bcm23550_w1d/MAINTAINERS
index fdaa539..bde6337 100644
--- a/board/broadcom/bcm23550_w1d/MAINTAINERS
+++ b/board/broadcom/bcm23550_w1d/MAINTAINERS
@@ -1,5 +1,5 @@
 BCM23550_W1D BOARD
-M: Steve Rae 
+M: Steve Rae 
 S: Maintained
 F: board/broadcom/bcm23550_w1d/
 F: include/configs/bcm23550_w1d.h
diff --git a/board/broadcom/bcm28155_ap/MAINTAINERS 
b/board/broadcom/bcm28155_ap/MAINTAINERS
index a74c394..e1e99d0 100644
--- a/board/broadcom/bcm28155_ap/MAINTAINERS
+++ b/board/broadcom/bcm28155_ap/MAINTAINERS
@@ -1,5 +1,5 @@
 BCM28155_AP BOARD
-M: Tim Kryger 
+M: Steve Rae 
 S: Maintained
 F: board/broadcom/bcm28155_ap/
 F: include/configs/bcm28155_ap.h
diff --git a/board/broadcom/bcm28155_w1d/MAINTAINERS 
b/board/broadcom/bcm28155_w1d/MAINTAINERS
index a436490..c0558e7 100644
--- a/board/broadcom/bcm28155_w1d/MAINTAINERS
+++ b/board/broadcom/bcm28155_w1d/MAINTAINERS
@@ -1,5 +1,5 @@
 BCM28155_W1D BOARD
-M: Steve Rae 
+M: Steve Rae 
 S: Maintained
 F: board/broadcom/bcm28155_ap/
 F: include/configs/bcm28155_ap.h
diff --git a/board/broadcom/bcm911360_entphn-ns/MAINTAINERS 
b/board/broadcom/bcm911360_entphn-ns/MAINTAINERS
index b5f0207..8b831d8 100644
--- a/board/broadcom/bcm911360_entphn-ns/MAINTAINERS
+++ b/board/broadcom/bcm911360_entphn-ns/MAINTAINERS
@@ -1,5 +1,5 @@
 BCM911360_ENTPHN-NS BOARD
-M: Steve Rae 
+M: Steve Rae 
 S: Maintained
 F: board/broadcom/bcmcygnus/
 F: include/configs/bcm_ep_board.h
diff --git a/board/broadcom/bcm911360_entphn/MAINTAINERS 
b/board/broadcom/bcm911360_entphn/MAINTAINERS
index fb7ee2b..d4f6aef 100644
--- a/board/broadcom/bcm911360_entphn/MAINTAINERS
+++ b/board/broadcom/bcm911360_entphn/MAINTAINERS
@@ -1,5 +1,5 @@
 BCM911360_ENTPHN BOARD
-M: Steve Rae 
+M: Steve Rae 
 S: Maintained
 F: board/broadcom/bcmcygnus/
 F: include/configs/bcm_ep_board.h
diff --git a/board/broadcom/bcm911360k/MAINTAINERS 
b/board/broadcom/bcm911360k/MAINTAINERS
index 754a15f..32e6032 100644
--- a/board/broadcom/bcm911360k/MAINTAINERS
+++ b/board/broadcom/bcm911360k/MAINTAINERS
@@ -1,5 +1,5 @@
 BCM911360K BOARD
-M: Steve Rae 
+M: Steve Rae 
 S: Maintained
 F: board/broadcom/bcmcygnus/
 F: include/configs/bcm_ep_board.h
diff --git a/board/broadcom/bcm958300k-ns/MAINTAINERS 
b/board/broadcom/bcm958300k-ns/MAINTAINERS
index 763401a..237d344 100644
--- a/board/broadcom/bcm958300k-ns/MAINTAINERS
+++ b/board/broadcom/bcm958300k-ns/MAINTAINERS
@@ -1,5 +1,5 @@
 BCM958300K-NS BOARD
-M: Steve Rae 
+M: Steve Rae 
 S: Maintained
 F: board/broadcom/bcmcygnus/
 F: include/configs/bcm_ep_board.h
diff --git a/board/broadcom/bcm958300k/MAINTAINERS 

[U-Boot] [RFC PATCH v1] usb: spl: fix USB errata for FSL SPL targets

[York Sun]

Commit 9262367 moved USB errata workaround to a C file but didn't
build it for SPL targets.

Signed-off-by: York Sun 
CC: Sriram Dash 
CC: Rajesh Bhagat 

---
Please review this patch. It fixed the compiling errors introduced by
9262367. Not sure if this is the way USB errata should be handled.

 drivers/Makefile| 7 +++
 drivers/usb/common/Makefile | 8 ++--
 include/configs/km/kmp204x-common.h | 1 +
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 1723958..88774ba 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -39,6 +39,13 @@ obj-$(CONFIG_OMAP_USB_PHY) += usb/phy/
 obj-$(CONFIG_SPL_SATA_SUPPORT) += block/
 obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += block/
 obj-$(CONFIG_SPL_MMC_SUPPORT) += block/
+ifdef CONFIG_USB_EHCI_FSL
+CONFIG_SPL_USB_ERRATA = y
+endif
+ifdef CONFIG_USB_XHCI_FSL
+CONFIG_SPL_USB_ERRATA = y
+endif
+obj-$(CONFIG_SPL_USB_ERRATA) += usb/common/
 
 else
 
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index aee7e32..f073e1c 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -4,5 +4,9 @@
 #
 
 obj-$(CONFIG_DM_USB) += common.o
-obj-$(CONFIG_USB_EHCI_FSL) += fsl-dt-fixup.o fsl-errata.o
-obj-$(CONFIG_USB_XHCI_FSL) += fsl-dt-fixup.o fsl-errata.o
+obj-$(CONFIG_USB_EHCI_FSL) += fsl-errata.o
+obj-$(CONFIG_USB_XHCI_FSL) += fsl-errata.o
+ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_USB_EHCI_FSL) += fsl-dt-fixup.o
+obj-$(CONFIG_USB_XHCI_FSL) += fsl-dt-fixup.o
+endif
diff --git a/include/configs/km/kmp204x-common.h 
b/include/configs/km/kmp204x-common.h
index 028623d..5bdda22 100644
--- a/include/configs/km/kmp204x-common.h
+++ b/include/configs/km/kmp204x-common.h
@@ -406,6 +406,7 @@ int get_scl(void);
 #endif
 
 #define __USB_PHY_TYPE utmi
+#define CONFIG_USB_EHCI_FSL
 
 /*
  * Environment Configuration
-- 
2.7.4

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

[U-Boot] [PATCH 2/4] tools/env: javadoc for fw_printenv, fw_getenv and fw_parse_script

[Andreas Fenkart]

there are two groups of functions:
- application ready tools: fw_setenv/fw_getenv/fw_parse_script
these are used, when creating a single binary containing multiple
tools (busybox like)
- file access like: open/read/write/close
above functions are implemented on top of these. applications
can use those to modify several variables without creating a
temporary batch script file

Signed-off-by: Andreas Fenkart 
---
 tools/env/fw_env.h | 75 +-
 1 file changed, 74 insertions(+), 1 deletion(-)

diff --git a/tools/env/fw_env.h b/tools/env/fw_env.h
index dac964d..8bf74f3 100644
--- a/tools/env/fw_env.h
+++ b/tools/env/fw_env.h
@@ -67,12 +67,85 @@ struct env_opts {
 
 int parse_aes_key(char *key, uint8_t *bin_key);
 
+/**
+ * fw_printenv - print one or several environment variables
+ *
+ * @argc  number of variables names to be printed, print all if 0
+ * @argv  array of variable names to be printed
+ * @value_only  do not repeat the variable name, only print the value,
+ *  only one variable allowed with this option, argc must be 1
+ * @opts  encryption key, configuration file, defaults are used if NULL
+ */
 int fw_printenv(int argc, char *argv[], int value_only, struct env_opts *opts);
-char *fw_getenv(char *name);
+
+/**
+ * fw_setenv - adds or removes one variable from the environment
+ *
+ * @argc  number of strings in argv, argv[0] is variable name,
+ *  argc==1 means erase variable, argc > 1 means add a variable
+ * @argv  argv[0] is variable name, argv[1..argc-1] are concatenated separated
+ *   by single blank and set as the new value of the variable
+ * @opts  how to retrieve environment from flash, defaults are used if NULL
+ * @ret   EROFS if variable must not be changed (ethaddr, serial#)
+ */
 int fw_setenv(int argc, char *argv[], struct env_opts *opts);
+
+/**
+ * fw_parse_script - add/remove multiple variables with a batch script
+ *
+ * @fname  batch script file name
+ * @opts  encryption key, configuration file, defaults are used if NULL
+ *
+ * Script Syntax:
+ *   key [[space]+ value]
+ *   lines starting with '#' treated as comment
+ *
+ *   A variable without value will be deleted. Any number of spaces are allowed
+ *   between key and value. The value starts with the first non-space character
+ *   and ends with newline. No comments allowed on these lines.  Spaces inside
+ *   the value are preserved verbatim.
+ *
+ * Script Example:"
+ *   netdev eth0
+ *   kernel_addr40
+ *   foospaces   are copied verbatim
+ *   # delete variable bar
+ *   bar\n"
+ */
 int fw_parse_script(char *fname, struct env_opts *opts);
+
+
+/**
+ * fw_env_open - read enviroment from flash and cache it in RAM
+ *
+ * @opts  encryption key, configuration file, defaults are used if NULL
+ */
 int fw_env_open(struct env_opts *opts);
+
+/**
+ * fw_getenv - lookup variable in RAM cache
+ *
+ * @name  variable to be searched
+ * @ret   NULL if not found
+ */
+char *fw_getenv(char *name);
+
+/**
+ * fw_env_write - set/clear a single variable in the RAM cache
+ *
+ * This is called in sequence to update the environment in RAM without updating
+ * the copy in flash after each set
+ *
+ * @name  variable
+ * @value delete variable if NULL, otherwise create or overwrite the variable
+ */
 int fw_env_write(char *name, char *value);
+
+/**
+ * fw_env_close - writes environment from RAM back to flash
+ *
+ * @opts  encryption key, configuration file, defaults are used if NULL
+ */
 int fw_env_close(struct env_opts *opts);
 
 unsigned long crc32(unsigned long, const unsigned char *, unsigned);
-- 
2.8.1

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

[U-Boot] [PATCH 1/4] tools/env: return with error if redundant environments have unequal size

[Andreas Fenkart]

From: Andreas Fenkart 

For double buffering to work, the target buffer must always be big
enough to hold all data. This can only be ensured if buffers are of
equal size, otherwise one must be smaller and we risk data loss
when copying from the bigger to the smaller buffer.

Signed-off-by: Andreas Fenkart 
---
 tools/env/fw_env.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 692abda..b1c8217 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1382,18 +1382,19 @@ static int parse_config(struct env_opts *opts)
return -1;
}
 
-   if (HaveRedundEnv && stat (DEVNAME (1), )) {
-   fprintf (stderr,
-   "Cannot access MTD device %s: %s\n",
-   DEVNAME (1), strerror (errno));
-   return -1;
-   }
+   if (HaveRedundEnv) {
+   if (stat(DEVNAME(1), )) {
+   fprintf(stderr,
+   "Cannot access MTD device %s: %s\n",
+   DEVNAME(1), strerror(errno));
+   return -1;
+   }
 
-   if (HaveRedundEnv && ENVSIZE(0) != ENVSIZE(1)) {
-   ENVSIZE(0) = ENVSIZE(1) = min(ENVSIZE(0), ENVSIZE(1));
-   fprintf(stderr,
-   "Redundant environments have inequal size, set to 
0x%08lx\n",
-   ENVSIZE(1));
+   if (ENVSIZE(0) != ENVSIZE(1)) {
+   fprintf(stderr,
+   "Redundant environments have unequal size");
+   return -1;
+   }
}
 
usable_envsize = CUR_ENVSIZE - sizeof(uint32_t);
-- 
2.8.1

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

[U-Boot] [PATCH 4/4] tools/env: reuse fw_getenv in fw_printenv function

[Andreas Fenkart]

Try to avoid adhoc iteration of the environment. Reuse fw_getenv
to find the variables that should be printed. Only use open-coded
iteration when printing all variables.
For backwards compatibility, keep emitting a newline when
printing with noheader.

Signed-off-by: Andreas Fenkart 
---
 tools/env/fw_env.c | 44 +---
 1 file changed, 17 insertions(+), 27 deletions(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index ca839d1..9733950 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -249,9 +249,14 @@ int parse_aes_key(char *key, uint8_t *bin_key)
  */
 int fw_printenv(int argc, char *argv[], int value_only, struct env_opts *opts)
 {
-   char *env, *nxt;
int i, rc = 0;
 
+   if (value_only && argc != 1) {
+   fprintf(stderr,
+   "## Error: `-n' option requires exactly one 
argument\n");
+   return -1;
+   }
+
if (!opts)
opts = _opts;
 
@@ -259,6 +264,7 @@ int fw_printenv(int argc, char *argv[], int value_only, 
struct env_opts *opts)
return -1;
 
if (argc == 0) {/* Print all env variables  */
+   char *env, *nxt;
for (env = environment.data; *env; env = nxt + 1) {
for (nxt = env; *nxt; ++nxt) {
if (nxt >= [ENV_SIZE]) {
@@ -273,39 +279,23 @@ int fw_printenv(int argc, char *argv[], int value_only, 
struct env_opts *opts)
return 0;
}
 
-   if (value_only && argc != 1) {
-   fprintf(stderr,
-   "## Error: `-n' option requires exactly one 
argument\n");
-   return -1;
-   }
-
-   for (i = 0; i < argc; ++i) {/* print single env variables   */
+   for (i = 0; i < argc; ++i) {/* print a subset of env variables */
char *name = argv[i];
char *val = NULL;
 
-   for (env = environment.data; *env; env = nxt + 1) {
-
-   for (nxt = env; *nxt; ++nxt) {
-   if (nxt >= [ENV_SIZE]) {
-   fprintf (stderr, "## Error: "
-   "environment not terminated\n");
-   return -1;
-   }
-   }
-   val = envmatch (name, env);
-   if (val) {
-   if (!value_only) {
-   fputs (name, stdout);
-   putc ('=', stdout);
-   }
-   puts (val);
-   break;
-   }
-   }
+   val = fw_getenv(name);
if (!val) {
fprintf (stderr, "## Error: \"%s\" not defined\n", 
name);
rc = -1;
+   continue;
}
+
+   if (value_only) {
+   puts(val);
+   break;
+   }
+
+   printf("%s=%s\n", name, val);
}
 
return rc;
-- 
2.8.1

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

[U-Boot] [PATCH 3/4] tools/env: move envmatch further up in file to avoid forward declarations

[Andreas Fenkart]

From: Andreas Fenkart 

forward declaration not needed when re-ordered

Signed-off-by: Andreas Fenkart 
---
 tools/env/fw_env.c | 38 ++
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index b1c8217..ca839d1 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -121,7 +121,6 @@ static unsigned char obsolete_flag = 0;
 #include 
 
 static int flash_io (int mode);
-static char *envmatch (char * s1, char * s2);
 static int parse_config(struct env_opts *opts);
 
 #if defined(CONFIG_FILE)
@@ -147,6 +146,24 @@ static char *skip_blanks(char *s)
 }
 
 /*
+ * s1 is either a simple 'name', or a 'name=value' pair.
+ * s2 is a 'name=value' pair.
+ * If the names match, return the value of s2, else NULL.
+ */
+static char *envmatch(char *s1, char *s2)
+{
+   if (s1 == NULL || s2 == NULL)
+   return NULL;
+
+   while (*s1 == *s2++)
+   if (*s1++ == '=')
+   return s2;
+   if (*s1 == '\0' && *(s2 - 1) == '=')
+   return s2;
+   return NULL;
+}
+
+/**
  * Search the environment for a variable.
  * Return the value, if found, or NULL, if not found.
  */
@@ -1121,25 +1138,6 @@ exit:
 }
 
 /*
- * s1 is either a simple 'name', or a 'name=value' pair.
- * s2 is a 'name=value' pair.
- * If the names match, return the value of s2, else NULL.
- */
-
-static char *envmatch (char * s1, char * s2)
-{
-   if (s1 == NULL || s2 == NULL)
-   return NULL;
-
-   while (*s1 == *s2++)
-   if (*s1++ == '=')
-   return s2;
-   if (*s1 == '\0' && *(s2 - 1) == '=')
-   return s2;
-   return NULL;
-}
-
-/*
  * Prevent confusion if running from erased flash memory
  */
 int fw_env_open(struct env_opts *opts)
-- 
2.8.1

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

[U-Boot] [PATCH 0/4] tools/env: minor refactorings

[Andreas Fenkart]

various patches, see individual patch descriptions

Andreas Fenkart (4):
  tools/env: return with error if redundant environments have unequal
size
  tools/env: javadoc for fw_printenv, fw_getenv and fw_parse_script
  tools/env: move envmatch further up in file to avoid forward
declarations
  tools/env: reuse fw_getenv in fw_printenv function

 tools/env/fw_env.c | 105 -
 tools/env/fw_env.h |  75 +-
 2 files changed, 121 insertions(+), 59 deletions(-)

-- 
2.8.1

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

[U-Boot] [PATCH] arm: mmc: increase MMC SDHCI read status timeout

[Steve Rae]

Otherwise,  ocassionally see errors like this:
  Flashing sparse image at offset 2078720
  Flashing Sparse Image
  sdhci_send_command: Timeout for status update!
  mmc fail to send stop cmd
  write_sparse_image: Write failed, block #2181088 [0]

This does not affect the actual writing speed, which is controlled by
the default value:
  CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT

It only increases the retries when reading:
  SDHCI_INT_STATUS
to avoid the timeout error.

Signed-off-by: Steve Rae 
---
as per the discussion in:
http://lists.denx.de/pipermail/u-boot/2016-June/258966.html
this supercedes:
http://patchwork.ozlabs.org/patch/615994/

 drivers/mmc/sdhci.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 5c71ab8..aa4cd4f 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -127,6 +127,7 @@ static int sdhci_transfer_data(struct sdhci_host *host, 
struct mmc_data *data,
 #define CONFIG_SDHCI_CMD_MAX_TIMEOUT   3200
 #endif
 #define CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT   100
+#define CONFIG_SDHCI_READ_STATUS_TIMEOUT   1000
 
 static int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
   struct mmc_data *data)
@@ -243,9 +244,9 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
if (stat & SDHCI_INT_ERROR)
break;
} while (((stat & mask) != mask) &&
-(get_timer(start) < CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT));
+(get_timer(start) < CONFIG_SDHCI_READ_STATUS_TIMEOUT));
 
-   if (get_timer(start) >= CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT) {
+   if (get_timer(start) >= CONFIG_SDHCI_READ_STATUS_TIMEOUT) {
if (host->quirks & SDHCI_QUIRK_BROKEN_R1B)
return 0;
else {
-- 
1.8.5

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

Re: [U-Boot] [PATCH] nitrogen6x : Use generic distro configuration

[Troy Kisky]

On 6/24/2016 8:59 AM, Fabien Lahoudere wrote:
> In order to simplify the use of various images on various media
> for nitrogen6x, the configuration of the board must follow the
> generic distro configuration (doc/README.distro).
> 
> In order to boot your old rootfs, move your kernel and your device
> tree in /boot/. Then create /boot/extlinux/extlinux.conf with for
> example:
> 
> default Buildroot
> 
> label Buildroot
>   kernel /boot/zImage
>   append console=ttymxc1,115200 root=/dev/mmcblk0p1 rootwait rw
>   fdtdir /boot
> 
> Signed-off-by: Fabien Lahoudere 
...
> +
> diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h
> index fb49322..75cbc84 100644
> --- a/include/configs/mx6_common.h
> +++ b/include/configs/mx6_common.h
> +#define CONFIG_EXTRA_ENV_SETTINGS \
> + "fdtfile=" CONFIG_FDTFILE "\0" \
> + "fdt_addr_r=" __stringify(CONFIG_FDTADDR) "\0"  \
> + "fdt_addr=" __stringify(CONFIG_FDTADDR) "\0" \
> + "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
> + "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
> + "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
> + "ramdisk_addr_r=" __stringify(CONFIG_RAMDISKADDR) "\0" \
> + "ramdiskaddr=" __stringify(CONFIG_RAMDISKADDR) "\0" \
> + BOOTENV
> +
> +#endif
> +

This should probably be called something like CONFIG_EXTRA_DEFAULT_ENV_SETTINGS
and the board files could contain

#define CONFIG_EXTRA_ENV_SETTINGS CONFIG_EXTRA_DEFAULT_ENV_SETTINGS \
"extra=more stuff\0" \


I would not remove any environment variables in this patch except for redundant 
things.

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

Re: [U-Boot] [PATCH 2/2] arm64: add better spin-table support

[york sun]

On 06/24/2016 09:15 PM, Masahiro Yamada wrote:
> Hi York,
>
> 2016-06-21 1:30 GMT+09:00 york sun :
>> On 06/19/2016 03:34 AM, André Przywara wrote:
>>> Hi,
>>>
>>> On 19/06/16 09:57, Masahiro Yamada wrote:
 2016-06-18 18:40 GMT+09:00 Linus Walleij :
> On Fri, Jun 17, 2016 at 2:51 PM, Masahiro Yamada
>  wrote:
>
>> There are two enable methods supported by ARM64 Linux; psci and
>> spin-table.  The latter is simpler and easier to use for quick SoC
>> bring-up.
>>
>> So, I used the spin-table for my first ARMv8 SoC porting, but I
>> found its support in U-Boot was poor.  It is true there exists a
>> code fragment for the spin code in arch/arm/cpu/armv8/start.S,
>> but I see some problems:
>
> Is part of the motivation for this approach to boot an ARMv8 system
> without using the ARM Trusted Firmware?
>
> Yours,
> Linus Walleij

 Yes, exactly.

 It would be the best choice
 to switch over to PSCI with ATF in a long run,
 but, I decided to use spin-table for the initial SoC bring-up
 because of tight schedule.
>>>
>>> So if you don't have an ATF port ready, why not use U-Boot's PSCI
>>> implementation meanwhile? I think there are efforts underway to make
>>> PSCI enablement for random new boards a walk in the park (by making the
>>> PSCI support as generic as possible, CCing Chen-Yu for this).
>>>
>>> IIRC the spin-table boot method was just introduced to cope with cores
>>> that don't have EL3 and thus cannot provide PSCI services the normal way
>>> (and that don't want to or cannot sacrifice EL2 for that).
>>> So I am a bit wary of proliferating this SMP method.
>>>
>>> Wouldn't it be better to help making U-Boot's PSCI stack as easy to use
>>> as possible? I don't see technical reasons that adding PSCI support for
>>> a board should be harder or more involved than adding spin-table support
>>> - in the end you need to tell it about the SMP pen, maybe providing (or
>>> faking?) reset and shutdown for 0.2 compliance.
>>>
>>
>> We have a team working on PSCI for ARMv8. The patches are floating and
>> need some minor fix. With these patches, PSCI will be used instead of
>> spin-table. However, a trusted firmware (or other kind) is required.
>>
>
>
> That's great.
>
>
> So, what should we do about this patch?
>
>
> I admit PSCI with ATF is the best way in the end,
> but I believe having a simpler alternative should not hurt.
>

I support using spin table as alternative. I see you already sent out v2 
patch. It would be easier to maintain if we consolidate existing code 
with generic code.

York


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

Re: [U-Boot] [PATCH v2] include: usb: Rename USB controller base address mapping

[york sun]

On 06/16/2016 08:58 PM, Rajesh Bhagat wrote:
>
>
>> -Original Message-
>> From: york sun
>> Sent: Friday, June 17, 2016 9:07 AM
>> To: Rajesh Bhagat ; u-boot@lists.denx.de
>> Cc: qianyu.g...@freescale.com; mingkai...@freescale.com;
>> prabha...@freescale.com
>> Subject: Re: [PATCH v2] include: usb: Rename USB controller base address 
>> mapping
>>
>> On 06/16/2016 08:28 PM, Rajesh Bhagat wrote:
>>>
>>>
 -Original Message-
 From: york sun
 Sent: Thursday, June 16, 2016 9:13 PM
 To: Rajesh Bhagat ; u-boot@lists.denx.de
 Cc: qianyu.g...@freescale.com; mingkai...@freescale.com;
 prabha...@freescale.com
 Subject: Re: [PATCH v2] include: usb: Rename USB controller base
 address mapping

 On 06/07/2016 06:29 AM, Rajesh Bhagat wrote:
> Remove Soc specific defines and use generic chasis specific defines
> for USB controller base address mapping.
>
> Signed-off-by: Rajesh Bhagat 
> ---
> Changes in v2:
> - Rebased patch for latest u-boot


 

> diff --git a/include/linux/usb/xhci-fsl.h
> b/include/linux/usb/xhci-fsl.h index 253eddf..199f366 100644
> --- a/include/linux/usb/xhci-fsl.h
> +++ b/include/linux/usb/xhci-fsl.h
> @@ -51,22 +51,18 @@ struct fsl_xhci {
>   struct dwc3 *dwc3_reg;
> };
>
> -#if defined(CONFIG_LS102XA)
> -#define CONFIG_SYS_FSL_XHCI_USB1_ADDR
> CONFIG_SYS_LS102XA_XHCI_USB1_ADDR
> +#if defined(CONFIG_LS102XA) || defined(CONFIG_LS1012A) #define
> +CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_XHCI_USB1_ADDR
> #define CONFIG_SYS_FSL_XHCI_USB2_ADDR 0
> #define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0
> #elif defined(CONFIG_LS2080A)
> -#define CONFIG_SYS_FSL_XHCI_USB1_ADDR
> CONFIG_SYS_LS2080A_XHCI_USB1_ADDR -#define
> CONFIG_SYS_FSL_XHCI_USB2_ADDR
>> CONFIG_SYS_LS2080A_XHCI_USB2_ADDR
> -#define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0 -#elif
> defined(CONFIG_LS1043A) || defined(CONFIG_LS1012A) -#define
> CONFIG_SYS_FSL_XHCI_USB1_ADDR
>> CONFIG_SYS_LS1043A_XHCI_USB1_ADDR
> -#define CONFIG_SYS_FSL_XHCI_USB2_ADDR
> CONFIG_SYS_LS1043A_XHCI_USB2_ADDR -#define
> CONFIG_SYS_FSL_XHCI_USB3_ADDR
>> CONFIG_SYS_LS1043A_XHCI_USB3_ADDR -
 #elif
> defined(CONFIG_LS1012A) -#define CONFIG_SYS_FSL_XHCI_USB1_ADDR
> CONFIG_SYS_LS1043A_XHCI_USB1_ADDR -#define
> CONFIG_SYS_FSL_XHCI_USB2_ADDR 0
> +#define CONFIG_SYS_FSL_XHCI_USB1_ADDR
>> CONFIG_SYS_XHCI_USB1_ADDR
> +#define CONFIG_SYS_FSL_XHCI_USB2_ADDR
>> CONFIG_SYS_XHCI_USB2_ADDR
> #define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0
> +#elif defined(CONFIG_LS1043A)
> +#define CONFIG_SYS_FSL_XHCI_USB1_ADDR
>> CONFIG_SYS_XHCI_USB1_ADDR
> +#define CONFIG_SYS_FSL_XHCI_USB2_ADDR
>> CONFIG_SYS_XHCI_USB2_ADDR
> +#define CONFIG_SYS_FSL_XHCI_USB3_ADDR
>> CONFIG_SYS_XHCI_USB3_ADDR
> #endif
>>>
>>> Hello York,
>>>

 Do you plan to consolidate the above section?

>>>
>>> Do you mean making the macro defines common as below?
>>>
>>> #define CONFIG_SYS_FSL_XHCI_USB1_ADDR 0 #define
>>> CONFIG_SYS_FSL_XHCI_USB2_ADDR 0 #define
>> CONFIG_SYS_FSL_XHCI_USB3_ADDR
>>> 0
>>>
>>> #if defined(CONFIG_LS102XA) || defined(CONFIG_LS1012A) ||
>> defined(CONFIG_LS2080A)
>>> || defined(CONFIG_LS2085A) || defined(CONFIG_LS1043A) #undef
>>> CONFIG_SYS_FSL_XHCI_USB1_ADDR #define
>> CONFIG_SYS_FSL_XHCI_USB1_ADDR
>>> CONFIG_SYS_XHCI_USB1_ADDR #endif
>>>
>>> #if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A) ||
>>> defined(CONFIG_LS1043A) #undef CONFIG_SYS_FSL_XHCI_USB2_ADDR #define
>>> CONFIG_SYS_FSL_XHCI_USB2_ADDR CONFIG_SYS_XHCI_USB2_ADDR #endif
>>>
>>> #if defined(CONFIG_LS1043A)
>>> #undef CONFIG_SYS_FSL_XHCI_USB3_ADDR
>>> #define CONFIG_SYS_FSL_XHCI_USB3_ADDR CONFIG_SYS_XHCI_USB3_ADDR
>> #endif
>>>
>
> Hello York,
>
>>
>> No. I mean to replace this section as
>>
>> #ifndef CONFIG_SYS_FSL_XHCI_USB1_ADDR
>> #define CONFIG_SYS_FSL_XHCI_USB1_ADDR 0
>> #endif
>> #ifndef CONFIG_SYS_FSL_XHCI_USB2_ADD
>> #define CONFIG_SYS_FSL_XHCI_USB2_ADD 0
>> #endif
>> #ifndef CONFIG_SYS_FSL_XHCI_USB3_ADD
>> #define CONFIG_SYS_FSL_XHCI_USB3_ADD 0
>> #endif
>>
>> Then you don't need to check SoC macros at all.
>>
>
> Actually, we are trying to re-use macros defined in chasis specific files for 
> other platform
> of same chasis i.e. LS1012A. For example,
>
> File: arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
>
> Original:
> #define CONFIG_SYS_LS1043A_XHCI_USB1_ADDR   (CONFIG_SYS_IMMR + 0x01f0)
> #define CONFIG_SYS_LS1043A_XHCI_USB2_ADDR   (CONFIG_SYS_IMMR + 0x0200)
> #define CONFIG_SYS_LS1043A_XHCI_USB3_ADDR   (CONFIG_SYS_IMMR + 0x0210)
>
> Proposed (Made macros common):
> #define CONFIG_SYS_XHCI_USB1_ADDR   (CONFIG_SYS_IMMR + 0x01f0)
> #define CONFIG_SYS_XHCI_USB2_ADDR   (CONFIG_SYS_IMMR + 0x0200)
> #define 

[U-Boot] [PATCH v3 9/9] doc: Update info on using secure devices from TI

[Andreas Dannenberg]

Adds information regarding SPL handling the loading and processing of
secured u-boot images as part of the second stage boot the SPL does.
Introduces the description of a new interface script in the TI SECDEV
Package which handles the creation and prep of secured binary images.

Signed-off-by: Daniel Allred 
Signed-off-by: Andreas Dannenberg 
Reviewed-by: Simon Glass 
---
 doc/README.ti-secure | 177 +++
 1 file changed, 123 insertions(+), 54 deletions(-)

diff --git a/doc/README.ti-secure b/doc/README.ti-secure
index 7fc9b9b..54c996d 100644
--- a/doc/README.ti-secure
+++ b/doc/README.ti-secure
@@ -19,69 +19,80 @@ control restrictions. Access must be requested and granted 
by TI before the
 package is viewable and downloadable. Contact TI, either online or by way
 of a local TI representative, to request access.
 
-When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process requires
-the presence and use of these tools in order to create a viable boot image.
-The build process will look for the environment variable TI_SECURE_DEV_PKG,
-which should be the path of the installed SECDEV package. If the
-TI_SECURE_DEV_PKG variable is not defined or if it is defined but doesn't
-point to a valid SECDEV package, a warning is issued during the build to
-indicate that a final secure bootable image was not created.
-
-Within the SECDEV package exists an image creation script:
-
-${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
-
-This is called as part of the SPL/u-boot build process. As the secure boot
-image formats and requirements differ between secure SOC from TI, the
-purpose of this script is to abstract these details as much as possible.
-
-The script is basically the only required interface to the TI SECDEV package
-for secure TI devices.
-
-Invoking the script for AM43xx Secure Devices
-=
-
-create-boot-image.sh
-
- is a value that specifies the type of the image to generate OR
-the action the image generation tool will take. Valid values are:
-   SPI_X-LOADER - Generates an image for SPI flash (byte swapped)
-   XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
-   ISSW - Generates an image for all other boot modes
-
- is the full path and filename of the public world boot loader
-binary file (depending on the boot media, this is usually either
-u-boot-spl.bin or u-boot.bin).
-
- is the full path and filename of the final secure image. The
-output binary images should be used in place of the standard non-secure
-binary images (see the platform-specific user's guides and releases notes
-for how the non-secure images are typically used)
+Booting of U-Boot SPL
+=
+
+   When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process
+   requires the presence and use of these tools in order to create a
+   viable boot image. The build process will look for the environment
+   variable TI_SECURE_DEV_PKG, which should be the path of the installed
+   SECDEV package. If the TI_SECURE_DEV_PKG variable is not defined or
+   if it is defined but doesn't point to a valid SECDEV package, a
+   warning is issued during the build to indicate that a final secure
+   bootable image was not created.
+
+   Within the SECDEV package exists an image creation script:
+
+   ${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
+
+   This is called as part of the SPL/u-boot build process. As the secure
+   boot image formats and requirements differ between secure SOC from TI,
+   the purpose of this script is to abstract these details as much as
+   possible.
+
+   The script is basically the only required interface to the TI SECDEV
+   package for creating a bootable SPL image for secure TI devices.
+
+   Invoking the script for AM43xx Secure Devices
+   =
+
+   create-boot-image.sh \
+  
+
+is a value that specifies the type of the image to
+   generate OR the action the image generation tool will take. Valid
+   values are:
+   SPI_X-LOADER - Generates an image for SPI flash (byte
+   swapped)
+   XIP_X-LOADER - Generates a single stage u-boot for
+   NOR/QSPI XiP
+   ISSW - Generates an image for all other boot modes
+
+is the full path and filename of the public world boot
+   loaderbinary file (depending on the boot media, this is usually
+   either u-boot-spl.bin or u-boot.bin).
+
+is the full path and filename of the final secure
+   image. The output binary images should be used in place of the standard
+   non-secure binary images (see the platform-specific user's guides and
+   releases notes for how the non-secure images are typically used)

[U-Boot] [PATCH v3 5/9] arm: omap-common: Update to generate secure U-Boot FIT blob

[Andreas Dannenberg]

Adds commands so that when a secure device is in use and the SPL is
built to load a FIT image (with combined U-Boot binary and various
DTBs), these components that get fed into the FIT are all processed to
be signed/encrypted/etc. as per the operations performed by the
secure-binary-image.sh script of the TI SECDEV package. Furthermore,
perform minor comments cleanup to make better use of the available
space.

Signed-off-by: Daniel Allred 
Signed-off-by: Andreas Dannenberg 
Reviewed-by: Simon Glass 
---
 arch/arm/cpu/armv7/omap-common/config_secure.mk | 75 -
 1 file changed, 61 insertions(+), 14 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk 
b/arch/arm/cpu/armv7/omap-common/config_secure.mk
index c7bb101..1122439 100644
--- a/arch/arm/cpu/armv7/omap-common/config_secure.mk
+++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk
@@ -12,8 +12,8 @@ cmd_mkomapsecimg = 
$(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \
$(if $(KBUILD_VERBOSE:1=), >/dev/null)
 else
 cmd_mkomapsecimg = $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \
-$(patsubst u-boot_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \
-$(if $(KBUILD_VERBOSE:1=), >/dev/null)
+   $(patsubst u-boot_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \
+   $(if $(KBUILD_VERBOSE:1=), >/dev/null)
 endif
 else
 cmd_mkomapsecimg = echo "WARNING:" \
@@ -25,14 +25,33 @@ cmd_mkomapsecimg = echo "WARNING: TI_SECURE_DEV_PKG 
environment" \
"variable must be defined for TI secure devices. $@ was NOT created!"
 endif
 
+ifdef CONFIG_SPL_LOAD_FIT
+quiet_cmd_omapsecureimg = SECURE  $@
+ifneq ($(TI_SECURE_DEV_PKG),)
+ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh),)
+cmd_omapsecureimg = $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
+   $< $@ \
+   $(if $(KBUILD_VERBOSE:1=), >/dev/null)
+else
+cmd_omapsecureimg = echo "WARNING:" \
+   "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
+   "$@ was NOT created!"; cp $< $@
+endif
+else
+cmd_omapsecureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
+   "variable must be defined for TI secure devices." \
+   "$@ was NOT created!"; cp $< $@
+endif
+endif
+
+
 # Standard X-LOADER target (QPSI, NOR flash)
 u-boot-spl_HS_X-LOADER: $(obj)/u-boot-spl.bin
$(call if_changed,mkomapsecimg)
 
-# For MLO targets (SD card boot) the final file name
-# that is copied to the SD card fAT partition must
-# be MLO, so we make a copy of the output file to a
-# new file with that name
+# For MLO targets (SD card boot) the final file name that is copied to the SD
+# card FAT partition must be MLO, so we make a copy of the output file to a new
+# file with that name
 u-boot-spl_HS_MLO: $(obj)/u-boot-spl.bin
$(call if_changed,mkomapsecimg)
@if [ -f $@ ]; then \
@@ -51,16 +70,44 @@ u-boot-spl_HS_ULO: $(obj)/u-boot-spl.bin
 u-boot-spl_HS_ISSW: $(obj)/u-boot-spl.bin
$(call if_changed,mkomapsecimg)
 
-# For SPI flash on AM335x and AM43xx, these
-# require special byte swap handling so we use
-# the SPI_X-LOADER target instead of X-LOADER
-# and let the create-boot-image.sh script handle
-# that
+# For SPI flash on AM335x and AM43xx, these require special byte swap handling
+# so we use the SPI_X-LOADER target instead of X-LOADER and let the
+# create-boot-image.sh script handle that
 u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin
$(call if_changed,mkomapsecimg)
 
-# For supporting single stage XiP QSPI on AM43xx, the
-# image is a full u-boot file, not an SPL. In this case
-# the mkomapsecimg command looks for a u-boot-HS_* prefix
+# For supporting single stage XiP QSPI on AM43xx, the image is a full u-boot
+# file, not an SPL. In this case the mkomapsecimg command looks for a
+# u-boot-HS_* prefix
 u-boot_HS_XIP_X-LOADER: $(obj)/u-boot.bin
$(call if_changed,mkomapsecimg)
+
+# For supporting the SPL loading and interpreting of FIT images whose
+# components are pre-processed before being integrated into the FIT image in
+# order to secure them in some way
+ifdef CONFIG_SPL_LOAD_FIT
+
+MKIMAGEFLAGS_u-boot_HS.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
+   -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
+   -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
+   $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST)))
+
+OF_LIST_TARGETS = $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst 
",,$(CONFIG_OF_LIST)))
+$(OF_LIST_TARGETS): dtbs
+
+%_HS.dtb: %.dtb
+   $(call if_changed,omapsecureimg)
+   $(Q)if [ -f $@ ]; then \
+   cp -f $@ $<; \
+   fi
+
+u-boot-nodtb_HS.bin: u-boot-nodtb.bin
+   $(call if_changed,omapsecureimg)
+
+u-boot_HS.img: u-boot-nodtb_HS.bin u-boot.img $(patsubst 
%.dtb,%_HS.dtb,$(OF_LIST_TARGETS))
+   $(call if_changed,mkimage)
+   $(Q)if [ -f $@ ]; then \
+   cp -f $@ u-boot.img; \
+   

[U-Boot] [PATCH v3 2/9] arm: omap-common: add secure smc entry

[Andreas Dannenberg]

From: Daniel Allred 

Add an interface for calling secure ROM APIs across a range of OMAP and
OMAP compatible high-security (HS) device variants. While at it, also
perform minor cleanup/alignment without any change in functionality.

Signed-off-by: Daniel Allred 
Signed-off-by: Andreas Dannenberg 
Reviewed-by: Simon Glass 
Reviewed-by: Tom Rini 
---
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 45 --
 arch/arm/include/asm/omap_common.h |  6 
 2 files changed, 42 insertions(+), 9 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 5283135..66a3b3d 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -16,9 +16,10 @@
 #include 
 #include 
 
+.arch_extension sec
+
 #ifdef CONFIG_SPL
 ENTRY(save_boot_params)
-
ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
str r0, [r1]
b   save_boot_params_ret
@@ -26,14 +27,40 @@ ENDPROC(save_boot_params)
 #endif
 
 ENTRY(omap_smc1)
-   PUSH{r4-r12, lr}@ save registers - ROM code may pollute
+   push{r4-r12, lr}@ save registers - ROM code may pollute
@ our registers
-   MOV r12, r0 @ Service
-   MOV r0, r1  @ Argument
-   DSB
-   DMB
-   .word   0xe1600070  @ SMC #0 - hand assembled for GCC versions
-   @ call ROM Code API for the service requested
+   mov r12, r0 @ Service
+   mov r0, r1  @ Argument
 
-   POP {r4-r12, pc}
+   dsb
+   dmb
+   smc 0   @ SMC #0 to enter monitor mode
+   @ call ROM Code API for the service requested
+   pop {r4-r12, pc}
 ENDPROC(omap_smc1)
+
+ENTRY(omap_smc_sec)
+   push{r4-r12, lr}@ save registers - ROM code may pollute
+   @ our registers
+   mov r6, #0xFF   @ Indicate new Task call
+   mov r12, #0x00  @ Secure Service ID in R12
+
+   dsb
+   dmb
+   smc 0   @ SMC #0 to enter monitor mode
+
+   b   omap_smc_sec_end @ exit at end of the service execution
+   nop
+
+   @ In case of IRQ happening in Secure, then ARM will branch here.
+   @ At that moment, IRQ will be pending and ARM will jump to Non Secure
+   @ IRQ handler
+   mov r12, #0xFE
+
+   dsb
+   dmb
+   smc 0   @ SMC #0 to enter monitor mode
+
+omap_smc_sec_end:
+   pop {r4-r12, pc}
+ENDPROC(omap_smc_sec)
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 07f3848..605c549 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -627,6 +627,12 @@ void recalibrate_iodelay(void);
 
 void omap_smc1(u32 service, u32 val);
 
+/*
+ * Low-level helper function used when performing secure ROM calls on high-
+ * security (HS) device variants by doing a specially-formed smc entry.
+ */
+u32 omap_smc_sec(u32 service, u32 proc_id, u32 flag, u32 *params);
+
 void enable_edma3_clocks(void);
 void disable_edma3_clocks(void);
 
-- 
2.6.4

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

[U-Boot] [PATCH v3 3/9] arm: omap-common: add secure rom call API for secure devices

[Andreas Dannenberg]

Adds a generic C-callable API for making secure ROM calls on OMAP and
OMAP-compatible devices. This API provides the important function of
flushing the ROM call arguments to memory from the cache, so that the
secure world will have a coherent view of those arguments. Then is
simply calls the omap_smc_sec routine.

Signed-off-by: Daniel Allred 
Signed-off-by: Andreas Dannenberg 
Reviewed-by: Simon Glass 
Reviewed-by: Tom Rini 
---
 arch/arm/cpu/armv7/omap-common/Makefile |  2 ++
 arch/arm/cpu/armv7/omap-common/sec-common.c | 51 +
 arch/arm/include/asm/omap_sec_common.h  | 21 
 3 files changed, 74 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/omap-common/sec-common.c
 create mode 100644 arch/arm/include/asm/omap_sec_common.h

diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
b/arch/arm/cpu/armv7/omap-common/Makefile
index 87a7ac0..3172bae 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -36,3 +36,5 @@ obj-y += boot-common.o
 obj-y  += lowlevel_init.o
 
 obj-y  += mem-common.o
+
+obj-$(CONFIG_TI_SECURE_DEVICE) += sec-common.o
diff --git a/arch/arm/cpu/armv7/omap-common/sec-common.c 
b/arch/arm/cpu/armv7/omap-common/sec-common.c
new file mode 100644
index 000..4ec736f
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/sec-common.c
@@ -0,0 +1,51 @@
+/*
+ *
+ * Common security related functions for OMAP devices
+ *
+ * (C) Copyright 2016
+ * Texas Instruments, 
+ *
+ * Daniel Allred 
+ * Andreas Dannenberg 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+static uint32_t secure_rom_call_args[5] __aligned(ARCH_DMA_MINALIGN);
+
+u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...)
+{
+   int i;
+   u32 num_args;
+   va_list ap;
+
+   va_start(ap, flag);
+
+   num_args = va_arg(ap, u32);
+
+   if (num_args > 4)
+   return 1;
+
+   /* Copy args to aligned args structure */
+   for (i = 0; i < num_args; i++)
+   secure_rom_call_args[i + 1] = va_arg(ap, u32);
+
+   secure_rom_call_args[0] = num_args;
+
+   va_end(ap);
+
+   /* if data cache is enabled, flush the aligned args structure */
+   flush_dcache_range(
+   (unsigned int)_rom_call_args[0],
+   (unsigned int)_rom_call_args[0] +
+   roundup(sizeof(secure_rom_call_args), ARCH_DMA_MINALIGN));
+
+   return omap_smc_sec(service, proc_id, flag, secure_rom_call_args);
+}
diff --git a/arch/arm/include/asm/omap_sec_common.h 
b/arch/arm/include/asm/omap_sec_common.h
new file mode 100644
index 000..1f50f83
--- /dev/null
+++ b/arch/arm/include/asm/omap_sec_common.h
@@ -0,0 +1,21 @@
+/*
+ * (C) Copyright 2016
+ * Texas Instruments, 
+ *
+ * Andreas Dannenberg 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef_OMAP_SEC_COMMON_H_
+#define_OMAP_SEC_COMMON_H_
+
+#include 
+
+/*
+ * Invoke secure ROM API on high-security (HS) device variants. It formats
+ * the variable argument list into the format expected by the ROM code before
+ * triggering the actual low-level smc entry.
+ */
+u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...);
+
+#endif /* _OMAP_SEC_COMMON_H_ */
-- 
2.6.4

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

[U-Boot] [PATCH v3 1/9] arm: cache: add missing dummy functions for when dcache disabled

[Andreas Dannenberg]

From: Daniel Allred 

Adds missing flush_dcache_range and invalidate_dcache_range dummy
(empty) placeholder functions to the #else portion of the #ifndef
CONFIG_SYS_DCACHE_OFF, where full implementations of these functions
are defined.

Signed-off-by: Daniel Allred 
Signed-off-by: Andreas Dannenberg 
Reviewed-by: Simon Glass 
Reviewed-by: Tom Rini 
---
 arch/arm/cpu/armv7/cache_v7.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index dc309da..24fe0c5 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -195,6 +195,14 @@ void flush_dcache_all(void)
 {
 }
 
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
 void arm_init_before_mmu(void)
 {
 }
-- 
2.6.4

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

[U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs

[Andreas Dannenberg]

This is an updated version of a patch series that introduces a generic way
to optionally post-process blobs as they get extracted by the SPL from the
u-boot.img FIT image, and uses this scheme to perform some authentication/
decryption related processing on TI's high-secure (HS) SoC variants. For
additional background please see here [1].


Changes PATCH v3->PATCH v3:
- Added Kconfig option help explaining the process of customizing the SPL
  FIT post-processing (Simon's feecback)
- Added new Reviewed-by: tags from Tom and Simon
- Rebased on latest U-Boot upstream/master and re-tested

Changes PATCH->PATCH v2:
- Added some glue code to suppress SPL "Authentication passed" log messages
  in case of UART/Y-Modem boot (thanks Lokesh)
- Dropped the .NOTPARALLEL make hack when building the 'dtbs' target. Now, we
  rely on Yamada-san's patch [2] that fixes this on a more global scale
- Fixed some typos (thanks Yamada-san)
- Turned the __weak function call for inserting a post-processing function
  into a Kconfig option (thanks Simon). Also enabled that Kconfig option
  on applicable AM43xx HS, AM57xx HS, DRA7xx HS, and DRA72xx HS device
  variants defconfig files (note there is a dependency on [3] which renames
  the AM437x HS defconfig file)
- Introduced a new header file omap_sec_common.h for commom security API as
  using omap_common.h as done previously led to issues trying to use this file
  on AM43xx type devices. This device family (and AM335x as well) is not
  supported by omap_common.h, and trying to include this file into AM43xx board
  files leads to all kinds of issues (the registers and definitions are simply
  not compatible)
- Re-ordered the series so that the Kconfig option is introduced after all
  of the building blocks have been put into place (generic infrastructure and
  the TI-specific implementation).
- Minor readme update to account for the new Kconfig option

Changes RFC->PATCH:
- Update of README.ti-secure
- Unification of some of the secure ROM API call stuff between AM43xx and
  OMAP5-based platforms by moving those into common files
- Replacement of puts() with printf()
- Minor build simplification/cleanup
- Addition of "Reviewed-by:" comments for files that were pretty much carried
  over from the RFC as-is
- Addition of AM437x HS device build support (was missing in RFC)
- Removal of some redundant conditional compile directives
- Rebased on upstream U-Boot commit "Prepare v2016.07-rc2"


--
Andreas Dannenberg
Texas Instruments Inc


[1] http://lists.denx.de/pipermail/u-boot/2016-June/258716.html
[2] http://lists.denx.de/pipermail/u-boot/2016-June/258912.html
[3] http://lists.denx.de/pipermail/u-boot/2016-June/258896.html


Andreas Dannenberg (5):
  arm: omap-common: add secure rom call API for secure devices
  arm: omap-common: secure ROM signature verify API
  arm: omap-common: Update to generate secure U-Boot FIT blob
  arm: omap5: add U-Boot FIT signing and SPL image post-processing
  doc: Update info on using secure devices from TI

Daniel Allred (3):
  arm: cache: add missing dummy functions for when dcache disabled
  arm: omap-common: add secure smc entry
  spl: fit: add support for post-processing of images

Madan Srinivas (1):
  arm: am4x: add U-Boot FIT signing and SPL image post-processing

 Kconfig |  14 ++
 arch/arm/cpu/armv7/am33xx/config.mk |   1 +
 arch/arm/cpu/armv7/cache_v7.c   |   8 ++
 arch/arm/cpu/armv7/omap-common/Makefile |   2 +
 arch/arm/cpu/armv7/omap-common/config_secure.mk |  75 --
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S  |  45 --
 arch/arm/cpu/armv7/omap-common/sec-common.c | 139 +++
 arch/arm/cpu/armv7/omap5/config.mk  |   3 +
 arch/arm/include/asm/omap_common.h  |   6 +
 arch/arm/include/asm/omap_sec_common.h  |  30 
 board/ti/am43xx/board.c |   8 ++
 board/ti/am57xx/board.c |   8 ++
 board/ti/dra7xx/evm.c   |   9 ++
 common/spl/spl_fit.c|  21 ++-
 configs/am43xx_hs_evm_defconfig |   1 +
 configs/am57xx_hs_evm_defconfig |   1 +
 configs/dra7xx_hs_evm_defconfig |   1 +
 doc/README.ti-secure| 177 
 include/image.h |  17 +++
 19 files changed, 484 insertions(+), 82 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/sec-common.c
 create mode 100644 arch/arm/include/asm/omap_sec_common.h

-- 
2.6.4

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

[U-Boot] [PATCH v3 4/9] arm: omap-common: secure ROM signature verify API

[Andreas Dannenberg]

Adds an API that verifies a signature attached to an image (binary
blob). This API is basically a entry to a secure ROM service provided by
the device and accessed via an SMC call, using a particular calling
convention.

Signed-off-by: Daniel Allred 
Signed-off-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---
 arch/arm/cpu/armv7/omap-common/sec-common.c | 88 +
 arch/arm/include/asm/omap_sec_common.h  |  9 +++
 2 files changed, 97 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap-common/sec-common.c 
b/arch/arm/cpu/armv7/omap-common/sec-common.c
index 4ec736f..246a239 100644
--- a/arch/arm/cpu/armv7/omap-common/sec-common.c
+++ b/arch/arm/cpu/armv7/omap-common/sec-common.c
@@ -17,6 +17,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+/* Index for signature verify ROM API */
+#define API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX(0x000E)
 
 static uint32_t secure_rom_call_args[5] __aligned(ARCH_DMA_MINALIGN);
 
@@ -49,3 +54,86 @@ u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...)
 
return omap_smc_sec(service, proc_id, flag, secure_rom_call_args);
 }
+
+static u32 find_sig_start(char *image, size_t size)
+{
+   char *image_end = image + size;
+   char *sig_start_magic = "CERT_";
+   int magic_str_len = strlen(sig_start_magic);
+   char *ch;
+
+   while (--image_end > image) {
+   if (*image_end == '_') {
+   ch = image_end - magic_str_len + 1;
+   if (!strncmp(ch, sig_start_magic, magic_str_len))
+   return (u32)ch;
+   }
+   }
+   return 0;
+}
+
+int secure_boot_verify_image(void **image, size_t *size)
+{
+   int result = 1;
+   u32 cert_addr, sig_addr;
+   size_t cert_size;
+
+   /* Perform cache writeback on input buffer */
+   flush_dcache_range(
+   (u32)*image,
+   (u32)*image + roundup(*size, ARCH_DMA_MINALIGN));
+
+   cert_addr = (uint32_t)*image;
+   sig_addr = find_sig_start((char *)*image, *size);
+
+   if (sig_addr == 0) {
+   printf("No signature found in image!\n");
+   result = 1;
+   goto auth_exit;
+   }
+
+   *size = sig_addr - cert_addr;   /* Subtract out the signature size */
+   cert_size = *size;
+
+   /* Check if image load address is 32-bit aligned */
+   if (!IS_ALIGNED(cert_addr, 4)) {
+   printf("Image is not 4-byte aligned!\n");
+   result = 1;
+   goto auth_exit;
+   }
+
+   /* Image size also should be multiple of 4 */
+   if (!IS_ALIGNED(cert_size, 4)) {
+   printf("Image size is not 4-byte aligned!\n");
+   result = 1;
+   goto auth_exit;
+   }
+
+   /* Call ROM HAL API to verify certificate signature */
+   debug("%s: load_addr = %x, size = %x, sig_addr = %x\n", __func__,
+ cert_addr, cert_size, sig_addr);
+
+   result = secure_rom_call(
+   API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX, 0, 0,
+   4, cert_addr, cert_size, sig_addr, 0x);
+auth_exit:
+   if (result != 0) {
+   printf("Authentication failed!\n");
+   printf("Return Value = %08X\n", result);
+   hang();
+   }
+
+   /*
+* Output notification of successful authentication as well the name of
+* the signing certificate used to re-assure the user that the secure
+* code is being processed as expected. However suppress any such log
+* output in case of building for SPL and booting via YMODEM. This is
+* done to avoid disturbing the YMODEM serial protocol transactions.
+*/
+   if (!(IS_ENABLED(CONFIG_SPL_BUILD) &&
+ IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) &&
+ spl_boot_device() == BOOT_DEVICE_UART))
+   printf("Authentication passed: %s\n", (char *)sig_addr);
+
+   return result;
+}
diff --git a/arch/arm/include/asm/omap_sec_common.h 
b/arch/arm/include/asm/omap_sec_common.h
index 1f50f83..842f2af 100644
--- a/arch/arm/include/asm/omap_sec_common.h
+++ b/arch/arm/include/asm/omap_sec_common.h
@@ -18,4 +18,13 @@
  */
 u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...);
 
+/*
+ * Invoke a secure ROM API on high-secure (HS) device variants that can be used
+ * to verify a secure blob by authenticating and optionally decrypting it. The
+ * exact operation performed depends on how the certificate that was embedded
+ * into the blob during the signing/encryption step when the secure blob was
+ * first created.
+ */
+int secure_boot_verify_image(void **p_image, size_t *p_size);
+
 #endif /* _OMAP_SEC_COMMON_H_ */
-- 
2.6.4

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

[U-Boot] [PATCH v3 6/9] spl: fit: add support for post-processing of images

[Andreas Dannenberg]

From: Daniel Allred 

The next stage boot loader image and the selected FDT can be post-
processed by board/platform/device-specific code, which can include
modifying the size and altering the starting source address before
copying these binary blobs to their final destination. This might be
desired to do things like strip headers or footers attached to the
images before they were packaged into the FIT, or to perform operations
such as decryption or authentication. Introduce new configuration
option CONFIG_SPL_FIT_IMAGE_POST_PROCESS to allow controlling this
feature. If enabled, a platform-specific post-process function must
be provided.

Signed-off-by: Daniel Allred 
Signed-off-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---
 Kconfig  | 14 ++
 common/spl/spl_fit.c | 21 -
 include/image.h  | 17 +
 3 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/Kconfig b/Kconfig
index 3ceff25..2afbaaf 100644
--- a/Kconfig
+++ b/Kconfig
@@ -313,6 +313,20 @@ config SPL_LOAD_FIT
  particular it can handle selecting from multiple device tree
  and passing the correct one to U-Boot.
 
+config SPL_FIT_IMAGE_POST_PROCESS
+   bool "Enable post-processing of FIT artifacts after loading by the SPL"
+   depends on SPL_LOAD_FIT && TI_SECURE_DEVICE
+   help
+ Allows doing any sort of manipulation to blobs after they got 
extracted
+ from the U-Boot FIT image like stripping off headers or modifying the
+ size of the blob, verification, authentication, decryption etc. in a
+ platform or board specific way. In order to use this feature a 
platform
+ or board-specific implementation of board_fit_image_post_process() 
must
+ be provided. Also, anything done during this post-processing step 
would
+ need to be comprehended in how the images were prepared before being
+ injected into the FIT creation (i.e. the blobs would have been pre-
+ processed before being added to the FIT image).
+
 config SYS_CLK_FREQ
depends on ARC || ARCH_SUNXI
int "CPU clock frequency"
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 9874708..069e94d 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -132,7 +132,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
sector, void *fit)
int data_offset, data_size;
int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
int src_sector;
-   void *dst;
+   void *dst, *src;
 
/*
 * Figure out where the external images start. This is the base for the
@@ -206,8 +206,13 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
sector, void *fit)
return -EIO;
debug("image: dst=%p, data_offset=%x, size=%x\n", dst, data_offset,
  data_size);
-   memcpy(dst, dst + get_aligned_image_overhead(info, data_offset),
-  data_size);
+   src = dst + get_aligned_image_overhead(info, data_offset);
+
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+   board_fit_image_post_process((void **), (size_t *)_size);
+#endif
+
+   memcpy(dst, src, data_size);
 
/* Figure out which device tree the board wants to use */
fdt_len = spl_fit_select_fdt(fit, images, _offset);
@@ -236,8 +241,14 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
sector, void *fit)
 */
debug("fdt: dst=%p, data_offset=%x, size=%x\n", dst, fdt_offset,
  fdt_len);
-   memcpy(load_ptr + data_size,
-  dst + get_aligned_image_overhead(info, fdt_offset), fdt_len);
+   src = dst + get_aligned_image_overhead(info, fdt_offset);
+   dst = load_ptr + data_size;
+
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+   board_fit_image_post_process((void **), (size_t *)_len);
+#endif
+
+   memcpy(dst, src, fdt_len);
 
return 0;
 }
diff --git a/include/image.h b/include/image.h
index d788c26..93d39e1 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1173,4 +1173,21 @@ void android_print_contents(const struct andr_img_hdr 
*hdr);
  */
 int board_fit_config_name_match(const char *name);
 
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+/**
+ * board_fit_image_post_process() - Do any post-process on FIT binary data
+ *
+ * This is used to do any sort of image manipulation, verification, decryption
+ * etc. in a platform or board specific way. Obviously, anything done here 
would
+ * need to be comprehended in how the images were prepared before being 
injected
+ * into the FIT creation (i.e. the binary blobs would have been pre-processed
+ * before being added to the FIT image).
+ *
+ * @image: pointer to the image start pointer
+ * @size: pointer to the image size
+ * @return no return value (failure should be handled internally)
+ */
+void board_fit_image_post_process(void **p_image, size_t *p_size);

[U-Boot] [PATCH v3 7/9] arm: omap5: add U-Boot FIT signing and SPL image post-processing

[Andreas Dannenberg]

Modify the SPL build procedure for AM57xx and DRA7xx high-security (HS)
device variants to create a secure u-boot_HS.img FIT blob that contains
U-Boot and DTB artifacts signed with a TI-specific process based on the
CONFIG_TI_SECURE_DEVICE config option and the externally-provided image
signing tool.

Also populate the corresponding FIT image post processing call to be
performed during SPL runtime.

Signed-off-by: Daniel Allred 
Signed-off-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---
 arch/arm/cpu/armv7/omap5/config.mk | 3 +++
 board/ti/am57xx/board.c| 8 
 board/ti/dra7xx/evm.c  | 9 +
 configs/am57xx_hs_evm_defconfig| 1 +
 configs/dra7xx_hs_evm_defconfig| 1 +
 5 files changed, 22 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap5/config.mk 
b/arch/arm/cpu/armv7/omap5/config.mk
index a7e55a5..d245572 100644
--- a/arch/arm/cpu/armv7/omap5/config.mk
+++ b/arch/arm/cpu/armv7/omap5/config.mk
@@ -15,5 +15,8 @@ else
 ALL-y  += MLO
 endif
 else
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y   += u-boot_HS.img
+endif
 ALL-y  += u-boot.img
 endif
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 08cf14d..927d136 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -750,3 +751,10 @@ int board_fit_config_name_match(const char *name)
return -1;
 }
 #endif
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+   secure_boot_verify_image(p_image, p_size);
+}
+#endif
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 0394e4e..f9382b8 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -830,3 +832,10 @@ int board_fit_config_name_match(const char *name)
return -1;
 }
 #endif
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+   secure_boot_verify_image(p_image, p_size);
+}
+#endif
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index e01e504..01a4701 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -40,4 +40,5 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_FIT=y
 CONFIG_SPL_OF_LIBFDT=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
 CONFIG_OF_LIST="am57xx-beagle-x15"
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 6933ab5..eb01f41 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -58,4 +58,5 @@ CONFIG_G_DNL_PRODUCT_NUM=0xd022
 CONFIG_FIT=y
 CONFIG_SPL_OF_LIBFDT=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
 CONFIG_OF_LIST="dra7-evm dra72-evm"
-- 
2.6.4

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

[U-Boot] [PATCH v3 8/9] arm: am4x: add U-Boot FIT signing and SPL image post-processing

[Andreas Dannenberg]

From: Madan Srinivas 

Modify the SPL build procedure for AM437x high-security (HS) device
variants to create a secure u-boot_HS.img FIT blob that contains U-Boot
and DTB artifacts signed (and optionally encrypted) with a TI-specific
process based on the CONFIG_TI_SECURE_DEVICE config option and the
externally-provided image signing tool.

Also populate the corresponding FIT image post processing call to be
performed during SPL runtime.

Signed-off-by: Madan Srinivas 
Signed-off-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---
 arch/arm/cpu/armv7/am33xx/config.mk | 1 +
 board/ti/am43xx/board.c | 8 
 configs/am43xx_hs_evm_defconfig | 1 +
 3 files changed, 10 insertions(+)

diff --git a/arch/arm/cpu/armv7/am33xx/config.mk 
b/arch/arm/cpu/armv7/am33xx/config.mk
index 6d95d32..ab94708 100644
--- a/arch/arm/cpu/armv7/am33xx/config.mk
+++ b/arch/arm/cpu/armv7/am33xx/config.mk
@@ -26,6 +26,7 @@ endif
 else
 ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
 ALL-$(CONFIG_QSPI_BOOT) += u-boot_HS_XIP_X-LOADER
+ALL-y  += u-boot_HS.img
 endif
 ALL-y  += u-boot.img
 endif
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index f005762..27c311e 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -862,3 +863,10 @@ int board_fit_config_name_match(const char *name)
return -1;
 }
 #endif
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+   secure_boot_verify_image(p_image, p_size);
+}
+#endif
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 4856a19..68dfb6c 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -13,6 +13,7 @@ CONFIG_SPL_STACK_R=y
 CONFIG_FIT=y
 CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1, NAND"
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
-- 
2.6.4

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

Re: [U-Boot] u-boot-x86 sf probe fail

[杜睿哲_Pegatron]

Hi Bin,

Sorry for the late.
I applied the patch and it seems to work. I'll do more tests. Thanks.

Regards,
Hilbert

This e-mail and its attachment may contain PEGATRON Corp information that is 
confidential or privileged, and are solely for the use of the individual to 
whom this e-mail is addressed. If you are not the intended recipient or have 
received it accidentally, please immediately notify the sender by reply e-mail 
and destroy all copies of this email and its attachment. Please be advised that 
any unauthorized use, disclosure, distribution or copying of this email or its 
attachment is strictly prohibited.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] arm64: add better and more generic spin-table support

[Masahiro Yamada]

There are two enable methods supported by ARM64 Linux; psci and
spin-table.  The latter is simpler and helpful for quick SoC bring
up.  My main motivation for this patch is to improve the spin-table
support, which allows us to boot an ARMv8 system without the ARM
Trusted Firmware.

Currently, we have multi-entry code in arch/arm/cpu/armv8/start.S
and the spin-table is supported in a really ad-hoc way, and I see
some problems:

  - We must hard-code CPU_RELEASE_ADDR so that it matches the
"cpu-release-addr" property in the DT that comes from the
kernel tree.

  - The Documentation/arm64/booting.txt in Linux requires that
the release address must be zero-initialized, but it is not
cared by the common code in U-Boot.  We must do it in a board
function.

  - There is no systematic way to protect the spin-table code from
the kernel.  We are supposed to do it in a board specific manner,
but it is difficult to predict where the spin-table code will be
located after the relocation.  So, it also makes difficult to
hard-code /memreserve/ in the DT of the kernel.

So, here is a patch to solve those problems; the DT is run-time
modified to reserve the spin-table code (+ cpu-release-addr).
Also, the "cpu-release-addr" property is set to an appropriate
address after the relocation, which means we no longer need the
hard-coded CPU_RELEASE_ADDR.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Move all code under arch/arm
  - Avoid building spin-table code for SPL

 arch/arm/cpu/armv8/Kconfig | 18 +++
 arch/arm/cpu/armv8/Makefile|  3 ++
 arch/arm/cpu/armv8/spin_table.c| 63 ++
 arch/arm/cpu/armv8/spin_table_v8.S | 23 ++
 arch/arm/cpu/armv8/start.S | 10 +++---
 arch/arm/include/asm/spin_table.h  | 14 +
 arch/arm/lib/bootm-fdt.c   |  7 +
 7 files changed, 134 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/spin_table.c
 create mode 100644 arch/arm/cpu/armv8/spin_table_v8.S
 create mode 100644 arch/arm/include/asm/spin_table.h

diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 3d19bbf..acf2460 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -3,4 +3,22 @@ if ARM64
 config ARMV8_MULTIENTRY
 boolean "Enable multiple CPUs to enter into U-Boot"
 
+config ARMV8_SPIN_TABLE
+   bool "Support spin-table enable method"
+   depends on ARMV8_MULTIENTRY && OF_LIBFDT
+   help
+ Say Y here to support "spin-table" enable method for booting Linux.
+
+ To use this feature, you must do:
+   - Specify enable-method = "spin-table" in each CPU node in the
+ Device Tree you are using to boot the kernel
+   - Let secondary CPUs in U-Boot (in a board specific manner)
+ before the master CPU jumps to the kernel
+
+ U-Boot automatically does:
+   - Set "cpu-release-addr" property of each CPU node
+ (overwrites it if already exists).
+   - Reserve the code for the spin-table and the release address
+ via a /memreserve/ region in the Device Tree.
+
 endif
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index bf8644c..f6eb9f4 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -15,6 +15,9 @@ obj-y += cache.o
 obj-y  += tlb.o
 obj-y  += transition.o
 obj-y  += fwcall.o
+ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_ARMV8_SPIN_TABLE) += spin_table.o spin_table_v8.o
+endif
 
 obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
 obj-$(CONFIG_S32V234) += s32v234/
diff --git a/arch/arm/cpu/armv8/spin_table.c b/arch/arm/cpu/armv8/spin_table.c
new file mode 100644
index 000..ec1c9b8
--- /dev/null
+++ b/arch/arm/cpu/armv8/spin_table.c
@@ -0,0 +1,63 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ *   Author: Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+int spin_table_update_dt(void *fdt)
+{
+   int cpus_offset, offset;
+   const char *prop;
+   int ret;
+   unsigned long rsv_addr = (unsigned long)_table_reserve_begin;
+   unsigned long rsv_size = _table_reserve_end -
+   _table_reserve_begin;
+
+   cpus_offset = fdt_path_offset(fdt, "/cpus");
+   if (cpus_offset < 0)
+   return -ENODEV;
+
+   for (offset = fdt_first_subnode(fdt, cpus_offset);
+offset >= 0;
+offset = fdt_next_subnode(fdt, offset)) {
+   prop = fdt_getprop(fdt, offset, "device_type", NULL);
+   if (!prop || strcmp(prop, "cpu"))
+   continue;
+
+   /*
+* In the first loop, we check if every CPU node specifies
+* spin-table.  Otherwise, just return successfully to not
+* disturb other 

Re: [U-Boot] board/cirrus/edb93xx/edb93xx.c: "egpio" versus "epgio"?

[Robert P. J. Day]

On Mon, 27 Jun 2016, Robert P. J. Day wrote:

>
>   possibly embarrassing myself here, but i just ran across this in
> edb93xx.c, which looks ... weird, a mixture of "EGPIO" and "EPGIO"
> toward the end of that source file:
>
>   ... snip ...

  never mind, i just noticed that, first, the "edb" boards are listed
in the scrapyard file:

edb9301  arm arm920t716f7ad 2011-07-17
edb9302  arm arm920t716f7ad 2011-07-17
edb9302a arm arm920t716f7ad 2011-07-17
edb9307  arm arm920t716f7ad 2011-07-17
edb9307a arm arm920t716f7ad 2011-07-17
edb9312  arm arm920t716f7ad 2011-07-17
edb9315  arm arm920t716f7ad 2011-07-17
edb9315a arm arm920t716f7ad 2011-07-17

but, weirdly, that source file was added in 2014, with opening
comment:

/*
 * Board initialization for EP93xx

so why is an EP93xx board init file being added under
allegedly scrapped board directory board/cirrus/edb93xx?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[U-Boot] board/cirrus/edb93xx/edb93xx.c: "egpio" versus "epgio"?

[Robert P. J. Day]

  possibly embarrassing myself here, but i just ran across this in
edb93xx.c, which looks ... weird, a mixture of "EGPIO" and "EPGIO"
toward the end of that source file:

  ... snip ...

  int board_mmc_init(bd_t *bis)
  {
struct gpio_regs *regs = (struct gpio_regs *)GPIO_BASE;

ep93xx_set_epgio(CONFIG_MMC_SPI_CS_EPGIO);
ep93xx_dir_epgio_out(CONFIG_MMC_SPI_CS_EPGIO);

  #ifdef CONFIG_MMC_SPI_POWER_EGPIO
ep93xx_dir_epgio_out(CONFIG_MMC_SPI_POWER_EGPIO);
ep93xx_set_epgio(CONFIG_MMC_SPI_POWER_EGPIO);
  #elif defined(CONFIG_MMC_SPI_NPOWER_EGPIO)
ep93xx_dir_epgio_out(CONFIG_MMC_SPI_NPOWER_EGPIO);
ep93xx_clear_epgio(CONFIG_MMC_SPI_NPOWER_EGPIO);
  #endif

... snip ...

  is it just me, or does anyone else find that odd? all occurrences of
the string "epgio" are entirely contained within that single source
file:

$ grep -ri EPGIO *
board/cirrus/edb93xx/edb93xx.c:static void ep93xx_set_epgio(unsigned num)
board/cirrus/edb93xx/edb93xx.c:static void ep93xx_clear_epgio(unsigned num)
board/cirrus/edb93xx/edb93xx.c:static void ep93xx_dir_epgio_out(unsigned num)
board/cirrus/edb93xx/edb93xx.c: ep93xx_clear_epgio(slave->cs);
board/cirrus/edb93xx/edb93xx.c: ep93xx_set_epgio(slave->cs);
board/cirrus/edb93xx/edb93xx.c:#ifndef CONFIG_MMC_SPI_CS_EPGIO
board/cirrus/edb93xx/edb93xx.c:# define CONFIG_MMC_SPI_CS_EPGIO 4
board/cirrus/edb93xx/edb93xx.c: ep93xx_set_epgio(CONFIG_MMC_SPI_CS_EPGIO);
board/cirrus/edb93xx/edb93xx.c: ep93xx_dir_epgio_out(CONFIG_MMC_SPI_CS_EPGIO);
board/cirrus/edb93xx/edb93xx.c: 
ep93xx_dir_epgio_out(CONFIG_MMC_SPI_POWER_EGPIO);
board/cirrus/edb93xx/edb93xx.c: ep93xx_set_epgio(CONFIG_MMC_SPI_POWER_EGPIO);
board/cirrus/edb93xx/edb93xx.c: 
ep93xx_dir_epgio_out(CONFIG_MMC_SPI_NPOWER_EGPIO);
board/cirrus/edb93xx/edb93xx.c: ep93xx_clear_epgio(CONFIG_MMC_SPI_NPOWER_EGPIO);
board/cirrus/edb93xx/edb93xx.c: struct mmc *mmc = mmc_spi_init(0, 
CONFIG_MMC_SPI_CS_EPGIO,
$

  am i just being an idiot in not knowing that that means?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [U-Boot] [PATCH v3 10/12] libfdt: Add overlay application function

[Maxime Ripard]

Hi David,

On Mon, Jun 27, 2016 at 03:26:07PM +1000, David Gibson wrote:
> > +static uint32_t overlay_get_target_phandle(const void *fdto, int fragment)
> > +{
> > +   const uint32_t *val;
> > +   int len;
> > +
> > +   val = fdt_getprop(fdto, fragment, "target", );
> > +   if (!val || (*val == 0x) || (len != sizeof(*val)))
> > +   return 0;
> 
> This doesn't distinguish between a missing property (which may
> indicate a valid overlay using a target-path or some other method)
> and a badly formatted 'target' property, which is definitely an error
> in the overlay.
> 
> I think those should be treated differently.

AFAIK, phandles can have any 32 bits values but 0x. In order
to cover the two cases, we would need to have some error code, but
that doesn't really work with returning a uint32_t.

Or maybe we can simply remove all the checks but the missing property,
and let fdt_node_offset_by_phandle deal with the improper values?

> 
> > +   return fdt32_to_cpu(*val);
> > +}
> > +
> > +static int overlay_get_target(const void *fdt, const void *fdto,
> > + int fragment)
> > +{
> > +   uint32_t phandle;
> > +   const char *path;
> > +
> > +   /* Try first to do a phandle based lookup */
> > +   phandle = overlay_get_target_phandle(fdto, fragment);
> > +   if (phandle)
> > +   return fdt_node_offset_by_phandle(fdt, phandle);
> > +
> > +   /* And then a path based lookup */
> > +   path = fdt_getprop(fdto, fragment, "target-path", NULL);
> > +   if (!path)
> > +   return -FDT_ERR_NOTFOUND;
> > +
> > +   return fdt_path_offset(fdt, path);
> > +}
> > +
> > +static int overlay_phandle_add_offset(void *fdt, int node,
> > + const char *name, uint32_t delta)
> > +{
> > +   const uint32_t *val;
> > +   uint32_t adj_val;
> > +   int len;
> > +
> > +   val = fdt_getprop(fdt, node, name, );
> > +   if (!val)
> > +   return len;
> > +
> > +   if (len != sizeof(*val))
> > +   return -FDT_ERR_BADSTRUCTURE;
> > +
> > +   adj_val = fdt32_to_cpu(*val);
> > +   adj_val += delta;
> 
> You should probably check for overflow here.
> 
> > +
> > +   return fdt_setprop_inplace_u32(fdt, node, name, adj_val);
> > +}
> > +
> > +static int overlay_adjust_node_phandles(void *fdto, int node,
> > +   uint32_t delta)
> > +{
> > +   bool found = false;
> > +   int child;
> > +   int ret;
> > +
> > +   ret = overlay_phandle_add_offset(fdto, node, "phandle", delta);
> > +   if (ret && ret != -FDT_ERR_NOTFOUND)
> > +   return ret;
> > +
> > +   if (!ret)
> > +   found = true;
> > +
> > +   ret = overlay_phandle_add_offset(fdto, node, "linux,phandle", delta);
> > +   if (ret && ret != -FDT_ERR_NOTFOUND)
> > +   return ret;
> 
> I think the check for phandle vs. linux,phandle should be folded into
> overlay_phandle_add_offset().

I created overlay_phandle_add_offset to avoid duplicating the getprop,
offset, setprop, pattern which I don't think is a good idea.

And we'll have to have that kind of errors construct anyway to know if
we modified any of the two, which is a success, or none, which is a
failure.

> > +   /*
> > +* If neither phandle nor linux,phandle have been found return
> > +* an error.
> > +*/
> > +   if (!found && !ret)
> > +   return ret;
> > +
> > +   fdt_for_each_subnode(fdto, child, node)
> > +   overlay_adjust_node_phandles(fdto, child, delta);
> > +
> > +   return 0;
> > +}
> > +
> > +static int overlay_adjust_local_phandles(void *fdto, uint32_t delta)
> > +{
> > +   /*
> > +* Start adjusting the phandles from the overlay root
> > +*/
> > +   return overlay_adjust_node_phandles(fdto, 0, delta);
> > +}
> > +
> > +static int overlay_update_local_node_references(void *fdto,
> > +   int tree_node,
> > +   int fixup_node,
> > +   uint32_t delta)
> > +{
> > +   int fixup_prop;
> > +   int fixup_child;
> > +   int ret;
> > +
> > +   fdt_for_each_property_offset(fixup_prop, fdto, fixup_node) {
> > +   const uint32_t *val = NULL;
> > +   uint32_t adj_val, index;
> > +   const char *name;
> > +   int fixup_len;
> > +   int tree_len;
> > +
> > +   val = fdt_getprop_by_offset(fdto, fixup_prop,
> > +   , _len);
> > +   if (!val)
> > +   return fixup_len;
> > +   index = fdt32_to_cpu(*val);
> 
> This still doesn't handle the case of multiple fixups within the same
> property.  That would be entirely plausible for something like an
> interrupt-map property.

Good point, I'll fix that and add a test case for it.

> > +   val = fdt_getprop(fdto, tree_node, name, _len);
> > +   if (!val)
> > +   return tree_len;
> > +
> > +   adj_val = fdt32_to_cpu(*(val + (index / 

Re: [U-Boot] [PATCH v7 3/9] armv8: Add Secure Monitor/Hypervisor Call (SMC/HVC) infrastructure

[Dirk Behme]

On 25.06.2016 21:04, Mateusz Kulikowski wrote:

Hi Dirk,

On 23.06.2016 13:33, Dirk Behme wrote:
[...]


Idea: perhaps after this series is merged we can add 2 new commands to u-boot 
(SMC/HVC) to
play with hypervisors/secure monitors (and perhaps use some simple 
functionality if needed).


How this should look like?


I thought of something like this (I did such code few times):

u-boot> smc 42 42 42 42 42 42
ret => (0x1, 0x2, 0x3, 0x4)



Could you share any (example?) code you have for such an smc/hvc U-Boot command?


I'm afraid I don't have it anymore :(

SMC call itself is trivial, you can use smc_call @ u-boot:
arch/arm/cpu/armv8/fwcall.c
(this is code for armv8 in 64-bit mode, but you can easily port it to armv7)

As for adding custom commands - just use any existing as template (sleep may be 
a good idea :) ).



Anything like below [1]?


Best regards

Dirk

[1]

From f5fb9bdab3054fdc37ca3fed44703f0dc5c8b083 Mon Sep 17 00:00:00 2001
From: Dirk Behme 
Date: Mon, 27 Jun 2016 12:39:35 +0200
Subject: [PATCH] common: Add ARMv8 smc command

Add a command line interface to do ARMv8 secure monitor calls (smc).

Signed-off-by: Dirk Behme 
---
 common/Makefile  |2 +
 common/cmd_armv8svchvc.c |   60 
++

 2 files changed, 62 insertions(+), 0 deletions(-)
 create mode 100644 common/cmd_armv8svchvc.c

diff --git a/common/Makefile b/common/Makefile
index 252fbf1..5a8dad0 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -191,6 +191,8 @@ obj-$(CONFIG_CMD_SPL) += cmd_spl.o
 obj-$(CONFIG_CMD_ZIP) += cmd_zip.o
 obj-$(CONFIG_CMD_ZFS) += cmd_zfs.o

+obj-$(CONFIG_ARM64) += cmd_armv8svchvc.o
+
 # others
 obj-$(CONFIG_BOOTSTAGE) += bootstage.o
 obj-$(CONFIG_CONSOLE_MUX) += iomux.o
diff --git a/common/cmd_armv8svchvc.c b/common/cmd_armv8svchvc.c
new file mode 100644
index 000..6491704
--- /dev/null
+++ b/common/cmd_armv8svchvc.c
@@ -0,0 +1,60 @@
+/*
+ * (C) Copyright 2016
+ * Robert Bosch Car Multimedia GmbH
+ * Dirk Behme 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+static int do_smc(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])

+{
+   struct pt_regs regs;
+
+   memset(, 0, sizeof(struct pt_regs));
+
+   switch (argc) {
+   case 9:
+   regs.regs[7] = simple_strtoul(argv[8], NULL, 16);
+   /* fall through */
+   case 8:
+   regs.regs[6] = simple_strtoul(argv[7], NULL, 16);
+   /* fall through */
+   case 7:
+   regs.regs[5] = simple_strtoul(argv[6], NULL, 16);
+   /* fall through */
+   case 6:
+   regs.regs[4] = simple_strtoul(argv[5], NULL, 16);
+   /* fall through */
+   case 5:
+   regs.regs[3] = simple_strtoul(argv[4], NULL, 16);
+   /* fall through */
+   case 4:
+   regs.regs[2] = simple_strtoul(argv[3], NULL, 16);
+   /* fall through */
+   case 3:
+   regs.regs[1] = simple_strtoul(argv[2], NULL, 16);
+   /* fall through */
+   case 2:
+   regs.regs[0] = simple_strtoul(argv[1], NULL, 16);
+   break;
+   default:
+   return CMD_RET_USAGE;
+   }
+
+   smc_call();
+
+	printf("ret: x0: 0x%016luX\n x1: 0x%016luX\n x2: 0x%016luX 
x3: 0x%016lX\n",

+  regs.regs[0], regs.regs[1], regs.regs[2], regs.regs[3]);
+
+   return 0;
+}
+
+U_BOOT_CMD(
+   smc ,9,0, do_smc,
+   "do ARMv8 hypervisor call (SMC)",
+   "x0 [x1 x2 x3 x4 x5 x6 x7]\n"
+   "- 8 SMC parameters for the registers x0 - x7"
+);
--
1.6.6.1

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

Re: [U-Boot] [UBOOT PATCH] usb: ehci-hcd: Fix crash when rootdev not initialized

[Hans de Goede]

Hi,

On 27-06-16 10:59, Siva Durga Prasad Paladugu wrote:

This patch fixes the issue on zynq USB failure with DM
when rootdev is not initialized. This variable is initalized
to zero in non driver model case but not in DM.

Signed-off-by: Siva Durga Prasad Paladugu 
---
- Tested on Zynq ZC702 board with USB DM driver model patches
  sent by Simon.


This patch does not seem like the right fix, normally something
like the ehci_ctrl struct would be allocated by dm by setting
priv_auto_alloc_size in the driver description, and then the
data will get calloc-ed. If you're allocating the ehci_ctrl struct
differently and not memsetting it to 0 you may have other bugs
lurking, or may get new bugs when new members get added in the
future.

My advice would be to use priv_auto_alloc_size, see .e.g :
drivers/usb/host/ehci-sunxi.c

If you cannot use that for some reason, make sure to memset
struct ehci_Ctrl to 0 before calling ehci_register()

Regards,

Hans




---
 drivers/usb/host/ehci-hcd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 13aa70d..8adffa6 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1624,6 +1624,8 @@ int ehci_register(struct udevice *dev, struct ehci_hccr 
*hccr,
goto err;
}

+   ctrl->rootdev = 0;
+
ret = ehci_common_init(ctrl, tweaks);
if (ret)
goto err;


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

Re: [U-Boot] [PATCH 01/27] dm: mmc: dwmmc: Add comments to the dwmmc setup functions

[Jaehoon Chung]

Hi Simon,


On 06/13/2016 02:30 PM, Simon Glass wrote:
> These comments were missed when the original code was written. Add them to
> help people port their drivers over.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  include/dwmmc.h | 64 
> +
>  1 file changed, 64 insertions(+)
> 
> diff --git a/include/dwmmc.h b/include/dwmmc.h
> index 335af51..0199def 100644
> --- a/include/dwmmc.h
> +++ b/include/dwmmc.h
> @@ -224,9 +224,73 @@ static inline u8 dwmci_readb(struct dwmci_host *host, 
> int reg)
>   return readb(host->ioaddr + reg);
>  }
>  
> +#ifdef CONFIG_BLK
> +/**
> + * dwmci_setup_cfg() - Set up the configuration for DWMMC
> + *
> + * This is used to set up a DWMMC device when you are using CONFIG_BLK.
> + *
> + * This should be called from your MMC driver's probe() method once you have
> + * the information required.
> + *
> + * Generally your driver will have a platform data structure which holds both
> + * the configuration (struct mmc_config) and the MMC device info (struct 
> mmc).
> + * For example:
> + *
> + * struct rockchip_mmc_plat {
> + *   struct mmc_config cfg;
> + *   struct mmc mmc;
> + * };
> + *
> + * ...
> + *
> + * Inside U_BOOT_DRIVER():
> + *   .platdata_auto_alloc_size = sizeof(struct rockchip_mmc_plat),
> + *
> + * To access platform data:
> + *   struct rockchip_mmc_plat *plat = dev_get_platdata(dev);
> + *
> + * See rockchip_dw_mmc.c for an example.
> + *
> + * @cfg: Configuration structure to fill in (generally >mmc)
> + * @name:Device name (normally dev->name)
> + * @buswidth:Bus width (in bits, such as 4 or 8)
> + * @caps:Host capabilities (MMC_MODE_...)
> + * @max_clk: Maximum supported clock speed in HZ (e.g. 40)
> + * @min_clk: Minimum supported clock speed in HZ (e.g. 15000)

e,g is need to swap max_clk <-> min_clk?

> + */
>  void dwmci_setup_cfg(struct mmc_config *cfg, const char *name, int buswidth,
>uint caps, u32 max_clk, u32 min_clk);
> +
> +/**
> + * dwmci_bind() - Set up a new MMC block device
> + *
> + * This is used to set up a DWMMC block device when you are using CONFIG_BLK.
> + * It should be called from your driver's bind() method.
> + *
> + * See rockchip_dw_mmc.c for an example.
> + *
> + * @dev: Device to set up
> + * @mmc: Pointer to mmc structure (normally >mmc)
> + * @cfg: Empty configuration structure (generally >cfg). This is
> + *   normally all zeroes at this point. The only purpose of passing
> + *   this in is to set mmc->cfg to it.
> + * @return 0 if OK, -ve if the block device could not be created
> + */
>  int dwmci_bind(struct udevice *dev, struct mmc *mmc, struct mmc_config *cfg);
>  
> +#else
> +/**
> + * add_dwmci() - Add a new DWMMC interface
> + *
> + * This is used when you are not using CONFIG_BLK. Convert your driver over!
> + *
> + * @host:DWMMC host structure
> + * @max_clk: Maximum supported clock speed in HZ (e.g. 40)
> + * @min_clk: Minimum supported clock speed in HZ (e.g. 15000)
> + * @return 0 if OK, -ve on error
> + */

Ditto.

I'm starting to covert to DM for dwmmc exynos...
After finishing convert for dwmmc_exynos, I will check in more detail on dwmmc 
core side.

Sorry for checking too late.

Best Regards,
Jaehoon Chung

>  int add_dwmci(struct dwmci_host *host, u32 max_clk, u32 min_clk);
> +#endif /* !CONFIG_BLK */
> +
>  #endif   /* __DWMMC_HW_H */
> 

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

Re: [U-Boot] [PATCH 2/2] arm64: add better spin-table support

[Andre Przywara]

Hi Masahiro,

On 25/06/16 05:08, Masahiro Yamada wrote:
> Hi Andre,
> 
> 
> 2016-06-19 19:33 GMT+09:00 André Przywara :
>> Hi,
>>
>> On 19/06/16 09:57, Masahiro Yamada wrote:
>>> 2016-06-18 18:40 GMT+09:00 Linus Walleij :
 On Fri, Jun 17, 2016 at 2:51 PM, Masahiro Yamada
  wrote:

> There are two enable methods supported by ARM64 Linux; psci and
> spin-table.  The latter is simpler and easier to use for quick SoC
> bring-up.
>
> So, I used the spin-table for my first ARMv8 SoC porting, but I
> found its support in U-Boot was poor.  It is true there exists a
> code fragment for the spin code in arch/arm/cpu/armv8/start.S,
> but I see some problems:

 Is part of the motivation for this approach to boot an ARMv8 system
 without using the ARM Trusted Firmware?

 Yours,
 Linus Walleij
>>>
>>> Yes, exactly.
>>>
>>> It would be the best choice
>>> to switch over to PSCI with ATF in a long run,
>>> but, I decided to use spin-table for the initial SoC bring-up
>>> because of tight schedule.
>>
>> So if you don't have an ATF port ready, why not use U-Boot's PSCI
>> implementation meanwhile? I think there are efforts underway to make
>> PSCI enablement for random new boards a walk in the park (by making the
>> PSCI support as generic as possible, CCing Chen-Yu for this).
> 
> 
> So, you mean U-Boot can serve PSCI for ARMv8 SoCs without ATF, right?
> (and efforts underway for further improvement)

Yes, if I am not mistaken then there are patches floating around to
achieve this.

> I know PSCI support is available for ARMv7
> (arch/arm/cpu/armv7/psci.S),
> but I could not find PSCI implementation
> in arch/arm/cpu/armv8/ directory in the mainline U-Boot.

I think that's work in progress (as in "on the ML").

> I checked Chen-Yu's patches on Patchwork,
> but I think they are mostly for improvement of ARMv7 PSCI support.
> 
> If I am missing something,
> could you point me to the reference, please?

I think you found this yourself already in that other mail of yours?

>> IIRC the spin-table boot method was just introduced to cope with cores
>> that don't have EL3 and thus cannot provide PSCI services the normal way
>> (and that don't want to or cannot sacrifice EL2 for that).
>> So I am a bit wary of proliferating this SMP method.
> 
> Proliferating?
> 
> Many of ARM 32bit SoCs have vendor-specific SMP methods.

Yes, and this is a massive PITA, but hard to change now.

> On the other hand, ARM64 only has two methods; psci and spin-table.

For a reason: Actually we just wanted to have PSCI only, but it turns
out that it's not easily possible on cores that don't implement EL3
(which is architecturally allowed and also implemented).
So spin-table support was added to provide a fall-back for those cases.
But if you have the choice, then PSCI is your friend.
Please note that any support for another SMP method is very unlikely to
ever get merged into upstream Linux.

> Is this a problem?

As mentioned, if you have a proper PSCI framework (as we are about to
get for U-Boot and which ATF already provides), adding SMP support is
not more involved than implementing spin tables. After all it's about
specifying the pen address and possibly providing per-core power hooks.

Cheers,
Andre.

>> Wouldn't it be better to help making U-Boot's PSCI stack as easy to use
>> as possible? I don't see technical reasons that adding PSCI support for
>> a board should be harder or more involved than adding spin-table support
>> - in the end you need to tell it about the SMP pen, maybe providing (or
>> faking?) reset and shutdown for 0.2 compliance.
> 
> 
> Right.
> 
> My motivation is to bring up Linux quickly
> before ATF becomes ready.
> 
> From your statement, I felt
> efforts for the ARMv8 PSCI implementation in U-Boot are underway.
> If so, I am definitely interested in it.
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI

[Christian Didriksson]

Hi!
> 
> Hi!
> 
> On 06/27/2016 11:10 AM, Christian Didriksson wrote:
> > Hi,
> >
> >> On 06/23/2016 06:31 PM, Sylvain Lesne wrote:
> >>> On 06/23/2016 06:14 PM, Marek Vasut wrote:
>  On 06/23/2016 05:58 PM, Sylvain Lesne wrote:
> > Hi Marek, Christian,
> 
>  Hi,
> 
> > On 06/23/2016 03:07 PM, Marek Vasut wrote:
> >> On 06/22/2016 06:37 PM, Christian Didriksson wrote:
> >>> Hi Marek,
> >>
> >> Hi!
> >>
> >>> [..]
> >>>
> >>> I skipped booting from QSPI and started all over with a vanilla
> > 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card
> > and
> >>> booted:
> >>>
> >>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14)
> >>> drivers/ddr/altera/sequencer.c: Preparing to start memory
> >>> calibration
> >>> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
> >>> drivers/ddr/altera/sequencer.c: Calibration complete Trying to
> >>> boot from MMC1
> >>>
> >>> This printout is repeated forever.
> >>>
> >>> I then connected DS5 via the USB-Blaster cable and single
> >>> stepped
> > through the SPL and after a while, down in mmc_init, I loose
> > connection to the target and when I interrupt it the PC is here:
> >>
> >> mmc_init causes data abort ? That is _weird_ .
> >>
> >>> #ifdef CONFIG_SPL_BUILD
> >>>
> >>>   .align  5
> >>> undefined_instruction:
> >>> software_interrupt:
> >>> prefetch_abort:
> >>> data_abort:
> >>> not_used:
> >>> irq:
> >>> fiq:
> >>>
> >>> 1:
> >>>   bl  1b  /*
> >> hang and never return */
> >>>
> >>> #else /* !CONFIG_SPL_BUILD */
> >>>
> >>> I will send you my binary for test on your Rev c board if you
> >>> can
> > find the time.
> >>>
> >>> I also tested the binary you sent me last week and it behaves
> > identically regarding the printouts and reboot.
> >>
> >> Works on my rev C1:
> >>
> >> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14)
> >> drivers/ddr/altera/sequencer.c: Preparing to start memory
> >> calibration
> >> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
> >> drivers/ddr/altera/sequencer.c: Calibration complete Trying to
> >> boot from MMC1
> >>
> >>
> >> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
> >>
> >> CPU:   Altera SoCFPGA Platform
> >> FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> >> BOOT:  SD/MMC External Transceiver (1.8V)
> >>Watchdog enabled
> >> I2C:   ready
> >> DRAM:  1 GiB
> >> MMC:   dwmmc0@ff704000: 0
> >> In:serial
> >> Out:   serial
> >> Err:   serial
> >> Model: Altera SOCFPGA Cyclone V SoC Development Kit
> >> Net:   eth0: ethernet@ff702000
> >> Hit any key to stop autoboot:  0
> >> =>
> >> =>
> >> =>
> >> => ver
> >>
> >> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
> >> arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
> >> crosstool-ng-1.22.0-129-ga41b269) 5.3.0 GNU ld (crosstool-NG
> >> crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
> >>
> >>
> >
> > I think this might be related to something we discussed last month
> > (starting from [1])!
> >
> > Am I right to assume that:
> > - Marek, you have the A2 partition starting at the sector 2048 of
> > the SD card? (I think that this is the partitioning of the
> > reference
> > designs)
> > - Christian, your SD card partitioning is different?
> >
> > The 2016.05 socfpga SPL loads U-Boot from a fixed offset on the SD
> > card, and this could explain why you both have a different
> > behavior if you have different offsets for your partitions!
> 
>  Oh right, thanks for reminding me that your patch broke booting of
>  all SoCFPGA boards which boot from SD card and I had to locally revert
> it.
>  I will send a patch which fixes that now. Would you be able to send
>  a fixed patch ?
> >>>
> >>> Ack, I'm sorry about that! That was obviously not my goal.
> >>> (I see that you just sent a patch to change the partition from 3 to
> >>> 1, and I agree that this is reasonable)
> >>>
> 
> > So, Christian, you could try to move your A2 partition (which
> > contains u-boot-with-spl.sfp ) to the offset that the SPL expects, ie:
> >
> > --8<---8<---
> > $ sudo fdisk -l /dev/sdc
> >
> > Disk /dev/sdc: 7969 MB, 7969177600 bytes
> > 246 heads, 62 sectors/track, 1020 cylinders, total 15564800
> > sectors Units = sectors of 1 * 512 = 512 bytes Sector size
> > (logical/physical): 512 bytes / 512 bytes I/O size
> > (minimum/optimal): 512 bytes / 512 bytes Disk identifier:
> > 0x
> >
> > Device Boot Start End Blocks Id System
> > 

Re: [U-Boot] [PATCH 2/2] usbarmory: Add board_run_command() function

[Stefano Babic]

Hi Andrej,

On 20/06/2016 18:18, Andrej Rosano wrote:

>>
>> I ten to NACK this. You can do exactly the same with a U-Boot script,
>> and if you want to have this as default, you can change your default
>> environment. This is just a wrapper around the hush shell.
> 
> The intention of the patch is to boot the kernel while having the CLI disabled
> (CONFIG_CMDLINE=n). The U-Boot script needs the CLI to be enabled AFAIK.
> 
> It is better having the CLI disabled when using the Verified Boot, otherwise
> there are chances to bypass the FIT image verification (e.g. using md/mw
> commands in case are available):

Why is it not enough to disable the CONSOLE ? I mean, if there is no
user interface (and this is done in a lot of ways, for example setting
stdin / stdout), there is no ways to bypass it because the interface is
not availabel. Or is there some other security issues I am not aware of ?

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] net: designware: Make driver independent from DM_GPIO again

[Alexey Brodkin]

Commit 90b7fc924adf "net: designware: support phy reset device-tree
bindings" made DW GMAC driver dependent on DM_GPIO by unconditional
usage of purely DM_GPIO stuff like:
 * dm_gpio_XXX()
 * gpio_request_by_name()

But since that driver as of today might be easily used without
DM_GPIO (that's the case for Synopsys AXS10x boards) we're
shielding all DM_GPIO things by ifdefs.

Signed-off-by: Alexey Brodkin 
Cc: Simon Glass 
Cc: Beniamino Galvani 
Cc: Joe Hershberger 
Cc: Sjoerd Simons 
Cc: Sonic Zhang 
Cc: Bin Meng 
Cc: Marek Vasut 
---
 drivers/net/designware.c | 10 --
 drivers/net/designware.h |  7 ++-
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 8858f07..8ba72e3 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -80,7 +80,7 @@ static int dw_mdio_write(struct mii_dev *bus, int addr, int 
devad, int reg,
return ret;
 }
 
-#if CONFIG_DM_ETH
+#if defined(CONFIG_DM_ETH) && defined(CONFIG_DM_GPIO)
 static int dw_mdio_reset(struct mii_dev *bus)
 {
struct udevice *dev = bus->priv;
@@ -126,7 +126,7 @@ static int dw_mdio_init(const char *name, void *priv)
bus->read = dw_mdio_read;
bus->write = dw_mdio_write;
snprintf(bus->name, sizeof(bus->name), "%s", name);
-#ifdef CONFIG_DM_ETH
+#if defined(CONFIG_DM_ETH) && defined(CONFIG_DM_GPIO)
bus->reset = dw_mdio_reset;
 #endif
 
@@ -690,11 +690,15 @@ static const struct eth_ops designware_eth_ops = {
 static int designware_eth_ofdata_to_platdata(struct udevice *dev)
 {
struct dw_eth_pdata *dw_pdata = dev_get_platdata(dev);
+#ifdef CONFIG_DM_GPIO
struct dw_eth_dev *priv = dev_get_priv(dev);
+#endif
struct eth_pdata *pdata = _pdata->eth_pdata;
const char *phy_mode;
const fdt32_t *cell;
+#ifdef CONFIG_DM_GPIO
int reset_flags = GPIOD_IS_OUT;
+#endif
int ret = 0;
 
pdata->iobase = dev_get_addr(dev);
@@ -712,6 +716,7 @@ static int designware_eth_ofdata_to_platdata(struct udevice 
*dev)
if (cell)
pdata->max_speed = fdt32_to_cpu(*cell);
 
+#ifdef CONFIG_DM_GPIO
if (fdtdec_get_bool(gd->fdt_blob, dev->of_offset,
"snps,reset-active-low"))
reset_flags |= GPIOD_ACTIVE_LOW;
@@ -724,6 +729,7 @@ static int designware_eth_ofdata_to_platdata(struct udevice 
*dev)
} else if (ret == -ENOENT) {
ret = 0;
}
+#endif
 
return ret;
 }
diff --git a/drivers/net/designware.h b/drivers/net/designware.h
index 51ba769..d345c5b 100644
--- a/drivers/net/designware.h
+++ b/drivers/net/designware.h
@@ -8,7 +8,9 @@
 #ifndef _DW_ETH_H
 #define _DW_ETH_H
 
-#include 
+#ifdef CONFIG_DM_GPIO
+#include 
+#endif
 
 #define CONFIG_TX_DESCR_NUM16
 #define CONFIG_RX_DESCR_NUM16
@@ -234,7 +236,10 @@ struct dw_eth_dev {
 #ifndef CONFIG_DM_ETH
struct eth_device *dev;
 #endif
+#ifdef CONFIG_DM_GPIO
struct gpio_desc reset_gpio;
+#endif
+
struct phy_device *phydev;
struct mii_dev *bus;
 };
-- 
2.5.5

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

Re: [U-Boot] [PATCH 3/3] linux/io.h: add generic ioremap()/iounmap() defines

[Daniel Schwierzeck]

Am 27.06.2016 um 10:32 schrieb Masahiro Yamada:
> For most of architectures in U-Boot, virtual address is straight
> mapped to physical address.  So, it makes sense to have generic
> defines of ioremap and friends in .
> 
> All of them are just empty and will disappear at compile time, but
> they will be helpful to implement drivers which are counterparts of
> Linux ones.
> 
> I notice MIPS already has its own implementation, so I surrounded
> the defines with #ifndef CONFIG_MIPS ... #endif.  I guess Sandbox
> will need its own implementation as well.
> 

how about introducing a Kconfig symbol like CONFIG_HAVE_ARCH_IOREMAP
which MIPS and Sandbox can select?

-- 
- Daniel



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI

[Sylvain Lesne]

Hi!

On 06/27/2016 11:10 AM, Christian Didriksson wrote:
> Hi,
> 
>> On 06/23/2016 06:31 PM, Sylvain Lesne wrote:
>>> On 06/23/2016 06:14 PM, Marek Vasut wrote:
 On 06/23/2016 05:58 PM, Sylvain Lesne wrote:
> Hi Marek, Christian,

 Hi,

> On 06/23/2016 03:07 PM, Marek Vasut wrote:
>> On 06/22/2016 06:37 PM, Christian Didriksson wrote:
>>> Hi Marek,
>>
>> Hi!
>>
>>> [..]
>>>
>>> I skipped booting from QSPI and started all over with a vanilla
> 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card and
>>> booted:
>>>
>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14)
>>> drivers/ddr/altera/sequencer.c: Preparing to start memory
>>> calibration
>>> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
>>> drivers/ddr/altera/sequencer.c: Calibration complete Trying to
>>> boot from MMC1
>>>
>>> This printout is repeated forever.
>>>
>>> I then connected DS5 via the USB-Blaster cable and single stepped
> through the SPL and after a while, down in mmc_init, I loose
> connection to the target and when I interrupt it the PC is here:
>>
>> mmc_init causes data abort ? That is _weird_ .
>>
>>> #ifdef CONFIG_SPL_BUILD
>>>
>>> .align  5
>>> undefined_instruction:
>>> software_interrupt:
>>> prefetch_abort:
>>> data_abort:
>>> not_used:
>>> irq:
>>> fiq:
>>>
>>> 1:
>>> bl  1b  /*
>> hang and never return */
>>>
>>> #else   /* !CONFIG_SPL_BUILD */
>>>
>>> I will send you my binary for test on your Rev c board if you can
> find the time.
>>>
>>> I also tested the binary you sent me last week and it behaves
> identically regarding the printouts and reboot.
>>
>> Works on my rev C1:
>>
>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14)
>> drivers/ddr/altera/sequencer.c: Preparing to start memory
>> calibration
>> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
>> drivers/ddr/altera/sequencer.c: Calibration complete Trying to boot
>> from MMC1
>>
>>
>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>>
>> CPU:   Altera SoCFPGA Platform
>> FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
>> BOOT:  SD/MMC External Transceiver (1.8V)
>>Watchdog enabled
>> I2C:   ready
>> DRAM:  1 GiB
>> MMC:   dwmmc0@ff704000: 0
>> In:serial
>> Out:   serial
>> Err:   serial
>> Model: Altera SOCFPGA Cyclone V SoC Development Kit
>> Net:   eth0: ethernet@ff702000
>> Hit any key to stop autoboot:  0
>> =>
>> =>
>> =>
>> => ver
>>
>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>> arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
>> crosstool-ng-1.22.0-129-ga41b269) 5.3.0 GNU ld (crosstool-NG
>> crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
>>
>>
>
> I think this might be related to something we discussed last month
> (starting from [1])!
>
> Am I right to assume that:
> - Marek, you have the A2 partition starting at the sector 2048 of
> the SD card? (I think that this is the partitioning of the reference
> designs)
> - Christian, your SD card partitioning is different?
>
> The 2016.05 socfpga SPL loads U-Boot from a fixed offset on the SD
> card, and this could explain why you both have a different behavior
> if you have different offsets for your partitions!

 Oh right, thanks for reminding me that your patch broke booting of
 all SoCFPGA boards which boot from SD card and I had to locally revert it.
 I will send a patch which fixes that now. Would you be able to send a
 fixed patch ?
>>>
>>> Ack, I'm sorry about that! That was obviously not my goal.
>>> (I see that you just sent a patch to change the partition from 3 to 1,
>>> and I agree that this is reasonable)
>>>

> So, Christian, you could try to move your A2 partition (which
> contains u-boot-with-spl.sfp ) to the offset that the SPL expects, ie:
>
> --8<---8<---
> $ sudo fdisk -l /dev/sdc
>
> Disk /dev/sdc: 7969 MB, 7969177600 bytes
> 246 heads, 62 sectors/track, 1020 cylinders, total 15564800 sectors
> Units = sectors of 1 * 512 = 512 bytes Sector size
> (logical/physical): 512 bytes / 512 bytes I/O size
> (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x
>
> Device Boot Start End Blocks Id System
> /dev/sdc1 200 300 50+ b W95 FAT32
> /dev/sdc2 14000 199 993000 83 Linux
> /dev/sdc3 2048 4096 1024+ a2 Unknown

 The A2 partition should be partition 1, please do not use this
 crippled layout by placing the bootloader partition at the end of
 boot media. I don't know who invented 

Re: [U-Boot] [PATCH v3 07/12] libfdt: Add fdt_setprop_inplace_by_index

[Maxime Ripard]

On Mon, Jun 27, 2016 at 01:45:11AM +1000, David Gibson wrote:
> On Fri, Jun 24, 2016 at 04:27:52PM +0200, Maxime Ripard wrote:
> > Add a function to modify inplace a property starting from a given index.
> > 
> > This is especially useful when the property is an array of values, and you
> > want to update one of them without changing the DT size.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  include/libfdt.h | 34 +++---
> >  lib/libfdt/fdt_wip.c | 13 -
> >  2 files changed, 39 insertions(+), 8 deletions(-)
> > 
> > diff --git a/include/libfdt.h b/include/libfdt.h
> > index 4643be5adf39..2c8a42bcb667 100644
> > --- a/include/libfdt.h
> > +++ b/include/libfdt.h
> > @@ -1032,6 +1032,27 @@ int fdt_size_cells(const void *fdt, int nodeoffset);
> >  /* Write-in-place functions   */
> >  /**/
> >  
> > +/**
> > + * fdt_setprop_inplace_namelen_by_index - change a property's value,
> > + *but not its size
> > + * @fdt: pointer to the device tree blob
> > + * @nodeoffset: offset of the node whose property to change
> > + * @name: name of the property to change
> > + * @namelen: number of characters of name to consider
> > + * @index: index of the property to change in the array
> > + * @val: pointer to data to replace the property value with
> > + * @len: length of the property value
> > + *
> > + * Identical to fdt_setprop_inplace(), but modifies the given property
> > + * starting from the given index, and using only the first characters
> > + * of the name. It is useful when you want to manipulate only one value of
> > + * an array and you have a string that doesn't end with \0.
> > + */
> > +int fdt_setprop_inplace_namelen_by_index(void *fdt, int nodeoffset,
> > +const char *name, int namelen,
> > +uint32_t index, const void *val,
> > +int len);
> 
> This looks like a good addition to upstream, but I don't like the
> name.  I'd suggest fdt_setprop_inplace_namelen_partial() because it
> only overwrite part of the existing property value.

Ack.

> > +
> >  /**
> >   * fdt_setprop_inplace - change a property's value, but not its size
> >   * @fdt: pointer to the device tree blob
> > @@ -1060,8 +1081,13 @@ int fdt_size_cells(const void *fdt, int nodeoffset);
> >   * -FDT_ERR_BADSTRUCTURE,
> >   * -FDT_ERR_TRUNCATED, standard meanings
> >   */
> > -int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
> > -   const void *val, int len);
> > +static inline int fdt_setprop_inplace(void *fdt, int nodeoffset,
> > + const char *name, const void *val,
> > + int len)
> > +{
> > +   return fdt_setprop_inplace_namelen_by_index(fdt, nodeoffset, name,
> > +   strlen(name), 0, val, len);
> 
> This effectively removes the error if len is not equal to the existing
> property length, so that needs to be put back.

So I'm not really sure what you want me to do.

I can't check for the property length, since it would prevent that
function from working, I can't check for the length + index, since we
might update only a few bytes in the middle, and we want to keep that
error case.

Or should I just forgive about merging the two functions and just
duplicate the two?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

Re: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI

[Christian Didriksson]

Hi,

> On 06/23/2016 06:31 PM, Sylvain Lesne wrote:
> > On 06/23/2016 06:14 PM, Marek Vasut wrote:
> >> On 06/23/2016 05:58 PM, Sylvain Lesne wrote:
> >>> Hi Marek, Christian,
> >>
> >> Hi,
> >>
> >>> On 06/23/2016 03:07 PM, Marek Vasut wrote:
>  On 06/22/2016 06:37 PM, Christian Didriksson wrote:
> > Hi Marek,
> 
>  Hi!
> 
> > [..]
> >
> > I skipped booting from QSPI and started all over with a vanilla
> >>> 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card and
> > booted:
> >
> > U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14)
> > drivers/ddr/altera/sequencer.c: Preparing to start memory
> > calibration
> > drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
> > drivers/ddr/altera/sequencer.c: Calibration complete Trying to
> > boot from MMC1
> >
> > This printout is repeated forever.
> >
> > I then connected DS5 via the USB-Blaster cable and single stepped
> >>> through the SPL and after a while, down in mmc_init, I loose
> >>> connection to the target and when I interrupt it the PC is here:
> 
>  mmc_init causes data abort ? That is _weird_ .
> 
> > #ifdef CONFIG_SPL_BUILD
> >
> > .align  5
> > undefined_instruction:
> > software_interrupt:
> > prefetch_abort:
> > data_abort:
> > not_used:
> > irq:
> > fiq:
> >
> > 1:
> > bl  1b  /*
> hang and never return */
> >
> > #else   /* !CONFIG_SPL_BUILD */
> >
> > I will send you my binary for test on your Rev c board if you can
> >>> find the time.
> >
> > I also tested the binary you sent me last week and it behaves
> >>> identically regarding the printouts and reboot.
> 
>  Works on my rev C1:
> 
>  U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14)
>  drivers/ddr/altera/sequencer.c: Preparing to start memory
>  calibration
>  drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
>  drivers/ddr/altera/sequencer.c: Calibration complete Trying to boot
>  from MMC1
> 
> 
>  U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
> 
>  CPU:   Altera SoCFPGA Platform
>  FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
>  BOOT:  SD/MMC External Transceiver (1.8V)
> Watchdog enabled
>  I2C:   ready
>  DRAM:  1 GiB
>  MMC:   dwmmc0@ff704000: 0
>  In:serial
>  Out:   serial
>  Err:   serial
>  Model: Altera SOCFPGA Cyclone V SoC Development Kit
>  Net:   eth0: ethernet@ff702000
>  Hit any key to stop autoboot:  0
>  =>
>  =>
>  =>
>  => ver
> 
>  U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>  arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
>  crosstool-ng-1.22.0-129-ga41b269) 5.3.0 GNU ld (crosstool-NG
>  crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
> 
> 
> >>>
> >>> I think this might be related to something we discussed last month
> >>> (starting from [1])!
> >>>
> >>> Am I right to assume that:
> >>> - Marek, you have the A2 partition starting at the sector 2048 of
> >>> the SD card? (I think that this is the partitioning of the reference
> >>> designs)
> >>> - Christian, your SD card partitioning is different?
> >>>
> >>> The 2016.05 socfpga SPL loads U-Boot from a fixed offset on the SD
> >>> card, and this could explain why you both have a different behavior
> >>> if you have different offsets for your partitions!
> >>
> >> Oh right, thanks for reminding me that your patch broke booting of
> >> all SoCFPGA boards which boot from SD card and I had to locally revert it.
> >> I will send a patch which fixes that now. Would you be able to send a
> >> fixed patch ?
> >
> > Ack, I'm sorry about that! That was obviously not my goal.
> > (I see that you just sent a patch to change the partition from 3 to 1,
> > and I agree that this is reasonable)
> >
> >>
> >>> So, Christian, you could try to move your A2 partition (which
> >>> contains u-boot-with-spl.sfp ) to the offset that the SPL expects, ie:
> >>>
> >>> --8<---8<---
> >>> $ sudo fdisk -l /dev/sdc
> >>>
> >>> Disk /dev/sdc: 7969 MB, 7969177600 bytes
> >>> 246 heads, 62 sectors/track, 1020 cylinders, total 15564800 sectors
> >>> Units = sectors of 1 * 512 = 512 bytes Sector size
> >>> (logical/physical): 512 bytes / 512 bytes I/O size
> >>> (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x
> >>>
> >>> Device Boot Start End Blocks Id System
> >>> /dev/sdc1 200 300 50+ b W95 FAT32
> >>> /dev/sdc2 14000 199 993000 83 Linux
> >>> /dev/sdc3 2048 4096 1024+ a2 Unknown
> >>
> >> The A2 partition should be partition 1, please do not use this
> >> crippled layout by placing the bootloader partition at the end of
> >> boot media. I don't know who invented that, but that's a design disaster.
> >
> > I don't know either, 

[U-Boot] [UBOOT PATCH] usb: ehci-hcd: Fix crash when rootdev not initialized

[Siva Durga Prasad Paladugu]

This patch fixes the issue on zynq USB failure with DM
when rootdev is not initialized. This variable is initalized
to zero in non driver model case but not in DM.

Signed-off-by: Siva Durga Prasad Paladugu 
---
- Tested on Zynq ZC702 board with USB DM driver model patches
  sent by Simon.
---
 drivers/usb/host/ehci-hcd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 13aa70d..8adffa6 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1624,6 +1624,8 @@ int ehci_register(struct udevice *dev, struct ehci_hccr 
*hccr,
goto err;
}
 
+   ctrl->rootdev = 0;
+
ret = ehci_common_init(ctrl, tweaks);
if (ret)
goto err;
-- 
2.1.1

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

[U-Boot] [PATCH 0/3] Add generic ioremap / iounmap defines

[Masahiro Yamada]

I ran Buildman for the whole series, and I did not see any regression.

01: Merge branch 'master' of git://git.denx.de/u-boot-uniphier
  openrisc:  +   openrisc-generic
   arc:  +   tb100 axs101 axs103
  blackfin:  +   bf533-stamp cm-bf527
   arm:  +   socfpga_is1
   powerpc:  +   P1022DS_36BIT_NAND T2080QDS_SPIFLASH T1042RDB_PI_SPIFLASH 
P1010RDB-PA_36BIT_NAND P1010RDB-PB_SDCARD T1042D4RDB_NAND T4240RDB_SDCARD 
P1010RDB-PB_36BIT_NAND P1022DS_36BIT_SDCARD P1010RDB-PB_36BIT_SDCARD 
P1022DS_NAND T4160QDS_NAND T1042RDB_PI_NAND T2080RDB_NAND P1022DS_SDCARD 
T1042RDB_PI_SDCARD T2081QDS_NAND T4160QDS_SDCARD T2080QDS_SDCARD 
T4240QDS_SDCARD P1010RDB-PA_SPIFLASH T1040RDB_SDCARD B4860QDS_NAND 
P1010RDB-PA_36BIT_SDCARD T1040D4RDB_SDCARD T1040D4RDB_SPIFLASH T2080QDS_NAND 
T1040D4RDB_NAND P1010RDB-PB_SPIFLASH P1010RDB-PA_NAND T1040RDB_SPIFLASH kmcoge4 
T2081QDS_SDCARD T2081QDS_SPIFLASH T4240QDS_NAND B4420QDS_NAND T1040RDB_NAND 
P1010RDB-PA_SDCARD T2080RDB_SPIFLASH P1010RDB-PB_NAND T1042D4RDB_SPIFLASH 
P1022DS_SPIFLASH T1042D4RDB_SDCARD kmlion1 P1022DS_36BIT_SPIFLASH 
P1010RDB-PB_36BIT_SPIFLASH T2080RDB_SDCARD P1010RDB-PA_36BIT_SPIFLASH
 [snip lots of error messages we have in the mainline]
02: types.h: move and redefine resource_size_t
03: arm, nds32, sh: remove useless ioremap()/iounmap() defines
04: linux/io.h: add generic ioremap()/iounmap() defines



Masahiro Yamada (3):
  types.h: move and redefine resource_size_t
  arm, nds32, sh: remove useless ioremap()/iounmap() defines
  linux/io.h: add generic ioremap()/iounmap() defines

 arch/arm/include/asm/io.h| 34 --
 arch/arm/include/asm/types.h |  1 -
 arch/nds32/include/asm/io.h  | 34 --
 arch/sh/include/asm/io.h | 33 -
 include/linux/io.h   | 16 
 include/linux/types.h|  4 
 6 files changed, 20 insertions(+), 102 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH 1/3] types.h: move and redefine resource_size_t

[Masahiro Yamada]

Currently, this is only defined in arch/arm/include/asm/types.h,
so move it to include/linux/types.h to make it available for all
architectures.

I defined it with phys_addr_t as Linux does.  I needed to surround
the define with #ifdef __KERNEL__ ... #endif to avoid build errors
in tools building.  (Host tools should not include 
in the first place, but this is already messy in U-Boot...)

Signed-off-by: Masahiro Yamada 
---

 arch/arm/include/asm/types.h | 1 -
 include/linux/types.h| 4 
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
index d108915..9af7353 100644
--- a/arch/arm/include/asm/types.h
+++ b/arch/arm/include/asm/types.h
@@ -71,5 +71,4 @@ typedef u32 dma_addr_t;
 
 #endif /* __KERNEL__ */
 
-typedef unsigned long resource_size_t;
 #endif
diff --git a/include/linux/types.h b/include/linux/types.h
index 6f75be4..416fa66 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -124,6 +124,10 @@ typedef__UINT64_TYPE__ u_int64_t;
 typedef__INT64_TYPE__  int64_t;
 #endif
 
+#ifdef __KERNEL__
+typedef phys_addr_t resource_size_t;
+#endif
+
 /*
  * Below are truly Linux-specific types that should never collide with
  * any application/library that wants linux/types.h.
-- 
1.9.1

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

[U-Boot] [PATCH 2/3] arm, nds32, sh: remove useless ioremap()/iounmap() defines

[Masahiro Yamada]

These defines are valid only when iomem_valid_addr is defined,
but I do not see such defines anywhere.  Remove.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/include/asm/io.h   | 34 --
 arch/nds32/include/asm/io.h | 34 --
 arch/sh/include/asm/io.h| 33 -
 3 files changed, 101 deletions(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 9d185a6..6121f1d 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -292,40 +292,6 @@ static inline void __raw_readsl(unsigned long addr, void 
*data, int longlen)
 #define readsb(a, d, s)__raw_readsb((unsigned long)a, d, s)
 
 /*
- * ioremap and friends.
- *
- * ioremap takes a PCI memory address, as specified in
- * linux/Documentation/IO-mapping.txt.  If you want a
- * physical address, use __ioremap instead.
- */
-extern void * __ioremap(unsigned long offset, size_t size, unsigned long 
flags);
-extern void __iounmap(void *addr);
-
-/*
- * Generic ioremap support.
- *
- * Define:
- *  iomem_valid_addr(off,size)
- *  iomem_to_phys(off)
- */
-#ifdef iomem_valid_addr
-#define __arch_ioremap(off,sz,nocache) \
- ({\
-   unsigned long _off = (off), _size = (sz);   \
-   void *_ret = (void *)0; \
-   if (iomem_valid_addr(_off, _size))  \
-   _ret = __ioremap(iomem_to_phys(_off),_size,nocache);\
-   _ret;   \
- })
-
-#define __arch_iounmap __iounmap
-#endif
-
-#define ioremap(off,sz)__arch_ioremap((off),(sz),0)
-#define ioremap_nocache(off,sz)__arch_ioremap((off),(sz),1)
-#define iounmap(_addr) __arch_iounmap(_addr)
-
-/*
  * DMA-consistent mapping functions.  These allocate/free a region of
  * uncached, unwrite-buffered mapped memory space for use with DMA
  * devices.  This is the "generic" version.  The PCI specific version
diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h
index 04708e9..b2c4d0e 100644
--- a/arch/nds32/include/asm/io.h
+++ b/arch/nds32/include/asm/io.h
@@ -344,40 +344,6 @@ static inline void writesl(unsigned int *addr, const void 
* data, int longlen)
 #define insl_p(port, to, len)  insl(port, to, len)
 
 /*
- * ioremap and friends.
- *
- * ioremap takes a PCI memory address, as specified in
- * linux/Documentation/IO-mapping.txt.  If you want a
- * physical address, use __ioremap instead.
- */
-extern void *__ioremap(unsigned long offset, size_t size, unsigned long flags);
-extern void __iounmap(void *addr);
-
-/*
- * Generic ioremap support.
- *
- * Define:
- *  iomem_valid_addr(off,size)
- *  iomem_to_phys(off)
- */
-#ifdef iomem_valid_addr
-#define __arch_ioremap(off, sz, nocache)   \
-({ \
-   unsigned long _off = (off), _size = (sz);   \
-   void *_ret = (void *)0; \
-   if (iomem_valid_addr(_off, _size))  \
-   _ret = __ioremap(iomem_to_phys(_off), _size, 0);\
-   _ret;   \
-})
-
-#define __arch_iounmap __iounmap
-#endif
-
-#define ioremap(off, sz)   __arch_ioremap((off), (sz), 0)
-#define ioremap_nocache(off, sz)   __arch_ioremap((off), (sz), 1)
-#define iounmap(_addr) __arch_iounmap(_addr)
-
-/*
  * DMA-consistent mapping functions.  These allocate/free a region of
  * uncached, unwrite-buffered mapped memory space for use with DMA
  * devices.  This is the "generic" version.  The PCI specific version
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 0a00db3..5dc27be 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -128,39 +128,6 @@ extern void __raw_readsl(unsigned int addr, void *data, 
int longlen);
 #define in_8(port) inb(port)
 #define in_le16(port)  inw(port)
 #define in_le32(port)  inl(port)
-/*
- * ioremap and friends.
- *
- * ioremap takes a PCI memory address, as specified in
- * linux/Documentation/IO-mapping.txt.  If you want a
- * physical address, use __ioremap instead.
- */
-extern void *__ioremap(unsigned long offset, size_t size, unsigned long flags);
-extern void __iounmap(void *addr);
-
-/*
- * Generic ioremap support.
- *
- * Define:
- *  iomem_valid_addr(off,size)
- *  iomem_to_phys(off)
- */
-#ifdef iomem_valid_addr
-#define __arch_ioremap(off, sz, nocache)   \
-({ \
-   unsigned long _off = (off), _size = 

[U-Boot] [PATCH 3/3] linux/io.h: add generic ioremap()/iounmap() defines

[Masahiro Yamada]

For most of architectures in U-Boot, virtual address is straight
mapped to physical address.  So, it makes sense to have generic
defines of ioremap and friends in .

All of them are just empty and will disappear at compile time, but
they will be helpful to implement drivers which are counterparts of
Linux ones.

I notice MIPS already has its own implementation, so I surrounded
the defines with #ifndef CONFIG_MIPS ... #endif.  I guess Sandbox
will need its own implementation as well.

Signed-off-by: Masahiro Yamada 
---

 include/linux/io.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/linux/io.h b/include/linux/io.h
index 1b36a22..ca23caa 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -5,6 +5,22 @@
 #ifndef _LINUX_IO_H
 #define _LINUX_IO_H
 
+#include 
+#include 
 #include 
 
+#ifndef CONFIG_MIPS
+static inline void __iomem *ioremap(resource_size_t offset,
+   resource_size_t size)
+{
+   return (void __iomem *)(unsigned long)offset;
+}
+
+static inline void iounmap(void __iomem *addr)
+{
+}
+
+#define devm_ioremap(dev, offset, size)ioremap(offset, size)
+#endif
+
 #endif /* _LINUX_IO_H */
-- 
1.9.1

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

[U-Boot] [PATCH v3] rockchip: rk3288: Change method of loading u-boot

[Ziyuan Xu]

From: Xu Ziyuan 

If we would like to boot from SD card, we have to implement mmc driver
in SPL stage, and get a slightly large spl binrary. RK3288's bootrom code
has the ability to load spl and u-boot, then boot.

If CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM is enabled, the spl will
return to bootrom in board_init_f(), then bootrom load u-boot binrary.

This patch does that.

Loading sequence after rework:
bootrom ==> spl ==> bootrom ==> u-boot

Signed-off-by: Ziyuan Xu 
---

Changes in v3:
- Add CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM for enabling this feature
- Update doc/README.rockchip to instruct how to use it
- Detailed commit message

Changes in v2:
- Add sdcard iomux initlization in board_init() to fix sdmmc command
sending timeout issue when booting from eMMC

 arch/arm/mach-rockchip/Makefile|  1 +
 arch/arm/mach-rockchip/board.c | 33 ++
 arch/arm/mach-rockchip/rk3036/Makefile |  1 -
 arch/arm/mach-rockchip/rk3288-board-spl.c  |  5 +++-
 .../mach-rockchip/{rk3036 => }/save_boot_param.S   |  2 +-
 doc/README.rockchip| 14 +
 include/configs/rk3288_common.h|  4 +++
 7 files changed, 57 insertions(+), 3 deletions(-)
 rename arch/arm/mach-rockchip/{rk3036 => }/save_boot_param.S (90%)

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 55567cb..8e0c0ab 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -7,6 +7,7 @@
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
+obj-y += save_boot_param.o
 else
 obj-$(CONFIG_ROCKCHIP_RK3288) += board.o
 endif
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 816540e..bcb2c9e 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -10,12 +10,45 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
 {
+#ifdef CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM
+   struct udevice *pinctrl;
+   int ret;
+
+/*
+ * We need to implement sdcard iomux here for the further
+ * initlization, otherwise, it'll hit sdcard command sending
+ * timeout exception.
+ */
+   ret = uclass_get_device(UCLASS_PINCTRL, 0, );
+   if (ret) {
+   debug("%s: Cannot find pinctrl device\n", __func__);
+   goto err;
+   }
+   ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_SDCARD);
+   if (ret) {
+   debug("%s: Failed to set up SD card\n", __func__);
+   goto err;
+   }
+
+   return 0;
+err:
+   printf("board_init: Error %d\n", ret);
+
+   /* No way to report error here */
+   hang();
+
+   return -1;
+#else
return 0;
+#endif
 }
 
 int dram_init(void)
diff --git a/arch/arm/mach-rockchip/rk3036/Makefile 
b/arch/arm/mach-rockchip/rk3036/Makefile
index 97d299d..6095777 100644
--- a/arch/arm/mach-rockchip/rk3036/Makefile
+++ b/arch/arm/mach-rockchip/rk3036/Makefile
@@ -10,4 +10,3 @@ obj-y += syscon_rk3036.o
 endif
 
 obj-y += sdram_rk3036.o
-obj-y += save_boot_param.o
diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c 
b/arch/arm/mach-rockchip/rk3288-board-spl.c
index e133cca..5de060c 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -149,7 +149,7 @@ static int configure_emmc(struct udevice *pinctrl)
return 0;
 }
 #endif
-
+extern void back_to_bootrom(void);
 void board_init_f(ulong dummy)
 {
struct udevice *pinctrl;
@@ -204,6 +204,9 @@ void board_init_f(ulong dummy)
debug("DRAM init failed: %d\n", ret);
return;
}
+#ifdef CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM
+   back_to_bootrom();
+#endif
 }
 
 static int setup_led(void)
diff --git a/arch/arm/mach-rockchip/rk3036/save_boot_param.S 
b/arch/arm/mach-rockchip/save_boot_param.S
similarity index 90%
rename from arch/arm/mach-rockchip/rk3036/save_boot_param.S
rename to arch/arm/mach-rockchip/save_boot_param.S
index 778ec83..85b407b 100644
--- a/arch/arm/mach-rockchip/rk3036/save_boot_param.S
+++ b/arch/arm/mach-rockchip/save_boot_param.S
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2015 Google, Inc
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
  *
  * SPDX-License-Identifier: GPL-2.0+
  */
diff --git a/doc/README.rockchip b/doc/README.rockchip
index e0572c8..4c6a04e 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -119,6 +119,20 @@ something like:
Hit any key to stop autoboot:  0
=>
 
+The rockchip bootrom could load and boot an initial spl, then continue to
+load a second level bootloader(ie. u-boot) as soon as it return to bootrom.
+Therefore RK3288 has another loading sequence like RK3036. The option of
+U-Boot is controlled with this setting in 

[U-Boot] [PATCH v3 0/6] autoboot cleanups

[Masahiro Yamada]

1/6 moves CONFIG_BOOTDELAY for a new SOCFPGA board.

The rest of this series are clean-ups of autoboot code.


Masahiro Yamada (6):
  ARM: socfpga: move CONFIG_BOOTDELAY to Kconfig for IS1 board
  doc: bootdelay: drop explanation about CONFIG_BOOTDELAY from README
  autoboot: remove CONFIG_ZERO_BOOTDELAY_CHECK
  autoboot: rename abortboot_{keyed, normal} to __abortboot
  autoboot: move CONFIG_SILENT_CONSOLE handling
  autoboot: move bootdelay >= 0 check to abortboot()

 README | 17 
 common/Kconfig |  4 +-
 common/autoboot.c  | 49 --
 configs/brppt1_mmc_defconfig   |  2 +-
 configs/brppt1_nand_defconfig  |  2 +-
 configs/brppt1_spi_defconfig   |  2 +-
 configs/brxre1_defconfig   |  2 +-
 configs/cairo_defconfig|  2 +-
 .../controlcenterd_TRAILBLAZER_DEVELOP_defconfig   |  2 +-
 configs/controlcenterd_TRAILBLAZER_defconfig   |  2 +-
 configs/omap3_evm_quick_mmc_defconfig  |  2 +-
 configs/omap3_evm_quick_nand_defconfig |  2 +-
 configs/socfpga_is1_defconfig  |  4 +-
 doc/README.autoboot|  8 
 include/configs/CPCI2DP.h  |  2 -
 include/configs/CPCI4052.h |  2 -
 include/configs/MIP405.h   |  1 -
 include/configs/PIP405.h   |  1 -
 include/configs/PLU405.h   |  1 -
 include/configs/PMC405DE.h |  1 -
 include/configs/PMC440.h   |  1 -
 include/configs/VCMA9.h|  1 -
 include/configs/VOM405.h   |  1 -
 include/configs/a3m071.h   |  1 -
 include/configs/amcc-common.h  |  1 -
 include/configs/apf27.h|  1 -
 include/configs/calimain.h |  1 -
 include/configs/cm_t35.h   |  2 -
 include/configs/cm_t3517.h |  2 -
 include/configs/cm_t43.h   |  1 -
 include/configs/devkit3250.h   |  1 -
 include/configs/digsy_mtc.h|  1 -
 include/configs/dlvision-10g.h |  2 -
 include/configs/exynos-common.h|  2 -
 include/configs/gdppc440etx.h  |  2 -
 include/configs/hrcon.h|  2 -
 include/configs/intip.h|  2 -
 include/configs/io.h   |  2 -
 include/configs/io64.h |  2 -
 include/configs/iocon.h|  2 -
 include/configs/legoev3.h  |  1 -
 include/configs/meesc.h|  2 -
 include/configs/omap3_logic.h  |  1 -
 include/configs/pcm030.h   |  5 ---
 include/configs/r7780mp.h  |  3 --
 include/configs/s5p_goni.h |  2 -
 include/configs/smdk2410.h |  1 -
 include/configs/smdkc100.h |  3 --
 include/configs/snapper9260.h  |  1 -
 include/configs/snapper9g45.h  |  1 -
 include/configs/socfpga_is1.h  |  1 -
 include/configs/spear-common.h |  1 -
 include/configs/strider.h  |  2 -
 include/configs/theadorable.h  |  1 -
 include/configs/tricorder.h|  1 -
 include/configs/uniphier.h |  2 -
 include/configs/vinco.h|  1 -
 include/configs/work_92105.h   |  2 -
 include/configs/x600.h |  1 -
 include/configs/xilinx-ppc.h   |  1 -
 60 files changed, 30 insertions(+), 141 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH v3 3/6] autoboot: remove CONFIG_ZERO_BOOTDELAY_CHECK

[Masahiro Yamada]

As the help message of CONFIG_BOOTDELAY says, CONFIG_BOOTDELAY=-2
means the autoboot with no delay, with no abort check even if
CONFIG_ZERO_BOOTDELAY_CHECK is defined.

To sum up, the autoboot behaves as follows:

 [1] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=y
autoboot with no delay, but you can abort it by key input

 [2] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
autoboot with no delay, with no check for abort

 [3] CONFIG_BOOTDELAY=-1
disable autoboot

 [4] CONFIG_BOOTDELAY=-2
autoboot with no delay, with no check for abort

As you notice, [2] and [4] come to the same result, which means we
do not need CONFIG_ZERO_BOOTDELAY_CHECK.  We can control all the
cases only by CONFIG_BOOTDELAY, like this:

 [1] CONFIG_BOOTDELAY=0
autoboot with no delay, but you can abort it by key input

 [2] CONFIG_BOOTDELAY=-1
disable autoboot

 [3] CONFIG_BOOTDELAY=-2
autoboot with no delay, with no check for abort

This commit converts the logic as follow:
  CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
--> CONFIG_BOOTDELAY=-2

Signed-off-by: Masahiro Yamada 
Reviewed-by: Stefan Roese 
Acked-by: Igor Grinberg 
Reviewed-by: Simon Glass 
Acked-by: Vladimir Zapolskiy 
Reviewed-by: Heiko Schocher 
Acked-by: Christian Riesch 
Acked-by: Hannes Schmelzer 
---

Changes in v3:
  - Tidy up garbages after CONFIG_ZERO_BOOTDELAY_CHECK removes

Changes in v2: None

 common/Kconfig   | 2 +-
 common/autoboot.c| 6 +-
 configs/brppt1_mmc_defconfig | 2 +-
 configs/brppt1_nand_defconfig| 2 +-
 configs/brppt1_spi_defconfig | 2 +-
 configs/brxre1_defconfig | 2 +-
 configs/cairo_defconfig  | 2 +-
 configs/controlcenterd_TRAILBLAZER_DEVELOP_defconfig | 2 +-
 configs/controlcenterd_TRAILBLAZER_defconfig | 2 +-
 configs/omap3_evm_quick_mmc_defconfig| 2 +-
 configs/omap3_evm_quick_nand_defconfig   | 2 +-
 doc/README.autoboot  | 8 
 include/configs/CPCI2DP.h| 2 --
 include/configs/CPCI4052.h   | 2 --
 include/configs/MIP405.h | 1 -
 include/configs/PIP405.h | 1 -
 include/configs/PLU405.h | 1 -
 include/configs/PMC405DE.h   | 1 -
 include/configs/PMC440.h | 1 -
 include/configs/VCMA9.h  | 1 -
 include/configs/VOM405.h | 1 -
 include/configs/a3m071.h | 1 -
 include/configs/amcc-common.h| 1 -
 include/configs/apf27.h  | 1 -
 include/configs/calimain.h   | 1 -
 include/configs/cm_t35.h | 2 --
 include/configs/cm_t3517.h   | 2 --
 include/configs/cm_t43.h | 1 -
 include/configs/devkit3250.h | 1 -
 include/configs/digsy_mtc.h  | 1 -
 include/configs/dlvision-10g.h   | 2 --
 include/configs/exynos-common.h  | 2 --
 include/configs/gdppc440etx.h| 2 --
 include/configs/hrcon.h  | 2 --
 include/configs/intip.h  | 2 --
 include/configs/io.h | 2 --
 include/configs/io64.h   | 2 --
 include/configs/iocon.h  | 2 --
 include/configs/legoev3.h| 1 -
 include/configs/meesc.h  | 2 --
 include/configs/omap3_logic.h| 1 -
 include/configs/pcm030.h | 5 -
 include/configs/r7780mp.h| 3 ---
 include/configs/s5p_goni.h   | 2 --
 include/configs/smdk2410.h   | 1 -
 include/configs/smdkc100.h   | 3 ---
 include/configs/snapper9260.h| 1 -
 include/configs/snapper9g45.h| 1 -
 include/configs/spear-common.h   | 1 -
 include/configs/strider.h| 2 --
 include/configs/theadorable.h| 1 -
 include/configs/tricorder.h  | 1 -
 include/configs/uniphier.h   | 2 --
 include/configs/vinco.h  | 1 -
 include/configs/work_92105.h | 2 --
 include/configs/x600.h  

Re: [U-Boot] [PATCH v3 1/6] ARM: socfpga: move CONFIG_BOOTDELAY to Kconfig for IS1 board

[Stefan Roese]

On 27.06.2016 09:22, Masahiro Yamada wrote:

This recently added board missed the tree-wide migration of
CONFIG_BOOTDELAY.

Signed-off-by: Masahiro Yamada 
Acked-by: Pavel Machek 
Reviewed-by: Heiko Schocher 


Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 09/12] libfdt: Add fdt_getprop_namelen_w

[Maxime Ripard]

On Mon, Jun 27, 2016 at 01:49:29AM +1000, David Gibson wrote:
> On Fri, Jun 24, 2016 at 04:27:54PM +0200, Maxime Ripard wrote:
> > Add a function to retrieve a writeable property only by the first
> > characters of its name.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  include/libfdt.h | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/include/libfdt.h b/include/libfdt.h
> > index dbe8a0efca87..b8758de3ae54 100644
> > --- a/include/libfdt.h
> > +++ b/include/libfdt.h
> > @@ -619,6 +619,13 @@ const void *fdt_getprop_by_offset(const void *fdt, int 
> > offset,
> >   */
> >  const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
> > const char *name, int namelen, int *lenp);
> > +static inline void *fdt_getprop_namelen_w(void *fdt, int nodeoffset,
> > + const char *name, int namelen,
> > + int *lenp)
> > +{
> > +   return (void *)(uintptr_t)fdt_getprop_namelen(fdt, nodeoffset, name,
> > + namelen, lenp);
> > +}
> 
> I believe you used this in your new setprop_inpace implementation.  So
> the series needs to be re-ordered to avoid breaking bisection.

You're right, sorry for that.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v3 04/12] libfdt: Add new headers and defines

[Maxime Ripard]

Hi David,

On Mon, Jun 27, 2016 at 01:39:06AM +1000, David Gibson wrote:
> On Fri, Jun 24, 2016 at 04:27:49PM +0200, Maxime Ripard wrote:
> > The libfdt overlay support introduces a bunch of new includes and
> > functions.
> > 
> > Make sure we are able to build it by adding the needed glue.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Is this intended only for downstream u-boot only, or also for upstream
> libfdt?

U-Boot only.

> If it's u-boot only, you don't really need the #ifdef UBOOT.

Unfortunately, libfdt_env.h is also included by some userspace tools
in U-Boot, which make use of strtoul while simple_strtoul is not
defined there (and we should rely on libc's anyway), leading to
link errors.

Maxime


-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

[U-Boot] [PATCH v3 4/6] autoboot: rename abortboot_{keyed, normal} to __abortboot

[Masahiro Yamada]

Because abortboot_keyed() and abortboot_normal() are not compiled
at the same time, we can rename both of them to __abortboot().
This allows to drop #ifdef from the caller.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Stefan Roese 
Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
---

Changes in v3: None
Changes in v2: None

 common/autoboot.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/common/autoboot.c b/common/autoboot.c
index 35deece..eb31c88 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -182,7 +182,7 @@ static int passwd_abort(uint64_t etime)
  * Watch for 'delay' seconds for autoboot stop or autoboot delay string.
  * returns: 0 -  no key string, allow autoboot 1 - got key string, abort
  */
-static int abortboot_keyed(int bootdelay)
+static int __abortboot(int bootdelay)
 {
int abort;
uint64_t etime = endtick(bootdelay);
@@ -216,7 +216,7 @@ static int abortboot_keyed(int bootdelay)
 static int menukey;
 #endif
 
-static int abortboot_normal(int bootdelay)
+static int __abortboot(int bootdelay)
 {
int abort = 0;
unsigned long ts;
@@ -274,11 +274,7 @@ static int abortboot_normal(int bootdelay)
 
 static int abortboot(int bootdelay)
 {
-#ifdef CONFIG_AUTOBOOT_KEYED
-   return abortboot_keyed(bootdelay);
-#else
-   return abortboot_normal(bootdelay);
-#endif
+   return __abortboot(bootdelay);
 }
 
 static void process_fdt_options(const void *blob)
-- 
1.9.1

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

[U-Boot] [PATCH v3 2/6] doc: bootdelay: drop explanation about CONFIG_BOOTDELAY from README

[Masahiro Yamada]

The same information now exists in common/Kconfig.  Do not duplicate
documentation from the point of view of maintainability.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
---

Changes in v3: None
Changes in v2: None

 README | 17 -
 common/Kconfig |  2 ++
 2 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/README b/README
index 03bed18..26d5ad2 100644
--- a/README
+++ b/README
@@ -890,23 +890,6 @@ The following options need to be configured:
'Sane' compilers will generate smaller code if
CONFIG_PRE_CON_BUF_SZ is a power of 2
 
-- Boot Delay:  CONFIG_BOOTDELAY - in seconds
-   Delay before automatically booting the default image;
-   set to -1 to disable autoboot.
-   set to -2 to autoboot with no delay and not check for abort
-   (even when CONFIG_ZERO_BOOTDELAY_CHECK is defined).
-
-   See doc/README.autoboot for these options that
-   work with CONFIG_BOOTDELAY. None are required.
-   CONFIG_BOOT_RETRY_TIME
-   CONFIG_BOOT_RETRY_MIN
-   CONFIG_AUTOBOOT_KEYED
-   CONFIG_AUTOBOOT_PROMPT
-   CONFIG_AUTOBOOT_DELAY_STR
-   CONFIG_AUTOBOOT_STOP_STR
-   CONFIG_ZERO_BOOTDELAY_CHECK
-   CONFIG_RESET_TO_RETRY
-
 - Autoboot Command:
CONFIG_BOOTCOMMAND
Only needed when CONFIG_BOOTDELAY is enabled;
diff --git a/common/Kconfig b/common/Kconfig
index ada4ddb..a94c7b9 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -107,6 +107,8 @@ config BOOTDELAY
  set to -2 to autoboot with no delay and not check for abort
  (even when CONFIG_ZERO_BOOTDELAY_CHECK is defined).
 
+ See doc/README.autoboot for details.
+
 config CONSOLE_RECORD
bool "Console recording"
help
-- 
1.9.1

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

[U-Boot] [PATCH v3 6/6] autoboot: move bootdelay >= 0 check to abortboot()

[Masahiro Yamada]

Move the bootdelay >= 0 check to the caller, which simplifies
the callees.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Stefan Roese 
Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
---

Changes in v3: None
Changes in v2: None

 common/autoboot.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/common/autoboot.c b/common/autoboot.c
index fb13139..c52bad8 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -187,9 +187,6 @@ static int __abortboot(int bootdelay)
int abort;
uint64_t etime = endtick(bootdelay);
 
-   if (bootdelay < 0)
-   return 0;
-
 #  ifdef CONFIG_AUTOBOOT_PROMPT
/*
 * CONFIG_AUTOBOOT_PROMPT includes the %d for all boards.
@@ -219,20 +216,16 @@ static int __abortboot(int bootdelay)
 #ifdef CONFIG_MENUPROMPT
printf(CONFIG_MENUPROMPT);
 #else
-   if (bootdelay >= 0)
-   printf("Hit any key to stop autoboot: %2d ", bootdelay);
+   printf("Hit any key to stop autoboot: %2d ", bootdelay);
 #endif
 
/*
 * Check if key already pressed
-* Don't check if bootdelay < 0
 */
-   if (bootdelay >= 0) {
-   if (tstc()) {   /* we got a key press   */
-   (void) getc();  /* consume input*/
-   puts("\b\b\b 0");
-   abort = 1;  /* don't auto boot  */
-   }
+   if (tstc()) {   /* we got a key press   */
+   (void) getc();  /* consume input*/
+   puts("\b\b\b 0");
+   abort = 1;  /* don't auto boot  */
}
 
while ((bootdelay > 0) && (!abort)) {
@@ -264,9 +257,10 @@ static int __abortboot(int bootdelay)
 
 static int abortboot(int bootdelay)
 {
-   int abort;
+   int abort = 0;
 
-   abort = __abortboot(bootdelay);
+   if (bootdelay >= 0)
+   abort = __abortboot(bootdelay);
 
 #ifdef CONFIG_SILENT_CONSOLE
if (abort)
-- 
1.9.1

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

[U-Boot] [PATCH v3 5/6] autoboot: move CONFIG_SILENT_CONSOLE handling

[Masahiro Yamada]

Factor out the same code from the callees to the caller.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Stefan Roese 
Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
---

Changes in v3: None
Changes in v2:
  - Fix build error when CONFIG_SILENT_CONSOLE is enabled

 common/autoboot.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/common/autoboot.c b/common/autoboot.c
index eb31c88..fb13139 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -202,11 +202,6 @@ static int __abortboot(int bootdelay)
if (!abort)
debug_bootkeys("key timeout\n");
 
-#ifdef CONFIG_SILENT_CONSOLE
-   if (abort)
-   gd->flags &= ~GD_FLG_SILENT;
-#endif
-
return abort;
 }
 
@@ -263,18 +258,22 @@ static int __abortboot(int bootdelay)
 
putc('\n');
 
-#ifdef CONFIG_SILENT_CONSOLE
-   if (abort)
-   gd->flags &= ~GD_FLG_SILENT;
-#endif
-
return abort;
 }
 # endif/* CONFIG_AUTOBOOT_KEYED */
 
 static int abortboot(int bootdelay)
 {
-   return __abortboot(bootdelay);
+   int abort;
+
+   abort = __abortboot(bootdelay);
+
+#ifdef CONFIG_SILENT_CONSOLE
+   if (abort)
+   gd->flags &= ~GD_FLG_SILENT;
+#endif
+
+   return abort;
 }
 
 static void process_fdt_options(const void *blob)
-- 
1.9.1

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

[U-Boot] [PATCH v3 1/6] ARM: socfpga: move CONFIG_BOOTDELAY to Kconfig for IS1 board

[Masahiro Yamada]

This recently added board missed the tree-wide migration of
CONFIG_BOOTDELAY.

Signed-off-by: Masahiro Yamada 
Acked-by: Pavel Machek 
Reviewed-by: Heiko Schocher 
---

Changes in v3: None
Changes in v2: None

 configs/socfpga_is1_defconfig | 4 +---
 include/configs/socfpga_is1.h | 1 -
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/configs/socfpga_is1_defconfig b/configs/socfpga_is1_defconfig
index 7d43c72..658770b 100644
--- a/configs/socfpga_is1_defconfig
+++ b/configs/socfpga_is1_defconfig
@@ -9,14 +9,13 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_is1"
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
 CONFIG_FIT=y
+CONFIG_BOOTDELAY=3
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_GREPENV=y
-# CONFIG_CMD_MEMTEST is not set
 # CONFIG_CMD_FLASH is not set
-# CONFIG_CMD_MMC is not set
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_I2C=y
@@ -36,7 +35,6 @@ CONFIG_SYS_I2C_DW=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
-CONFIG_SPI_FLASH_USE_4K_SECTORS=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/include/configs/socfpga_is1.h b/include/configs/socfpga_is1.h
index 6f5dfce..cc07253 100644
--- a/include/configs/socfpga_is1.h
+++ b/include/configs/socfpga_is1.h
@@ -19,7 +19,6 @@
 #define PHYS_SDRAM_1_SIZE  0x1000
 
 /* Booting Linux */
-#define CONFIG_BOOTDELAY   3
 #define CONFIG_BOOTFILE"zImage"
 #define CONFIG_BOOTARGS"console=ttyS0," 
__stringify(CONFIG_BAUDRATE)
 #define CONFIG_LOADADDR0x0100
-- 
1.9.1

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

Re: [U-Boot] uImage load address and entry point with Minnowboard

[vinoth eswaran]

On Fri, Jun 24, 2016 at 1:57 PM, Wolfgang Denk  wrote:
> Dear Vinoth,
>
> In message 
> 

[U-Boot] please pull u-boot-samsung master

[Minkyu Kang]

Dear Tom,

The following changes since commit 4141e85bcd79c0b9b16def710e527f165107b7af:

  kbuild: avoid race between dtbs and dt/dt.dtb targets (2016-06-24 17:24:41 
-0400)

are available in the git repository at:

  git://git.denx.de/u-boot-samsung master

for you to fetch changes up to ca2ec9adc951cc3798e9b0c3773cdcc613232a22:

  mmc: dw_mmc: fix the wrong AND operation (2016-06-27 09:43:26 +0900)


Jaehoon Chung (1):
  mmc: dw_mmc: fix the wrong AND operation

 drivers/mmc/dw_mmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 10/12] libfdt: Add overlay application function

[Maxime Ripard]

Hi Simon,

On Sat, Jun 25, 2016 at 08:53:58PM -0600, Simon Glass wrote:
> Hi Maxime,
> 
> On 24 June 2016 at 08:27, Maxime Ripard
>  wrote:
> > The device tree overlays are a good way to deal with user-modifyable
> > boards or boards with some kind of an expansion mechanism where we can
> > easily plug new board in (like the BBB, the Raspberry Pi or the CHIP).
> >
> > Add a new function to merge overlays with a base device tree.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >  include/libfdt.h |  30 
> >  lib/Kconfig  |   5 +
> >  lib/libfdt/Makefile  |   2 +
> >  lib/libfdt/fdt_overlay.c | 381 
> > +++
> >  4 files changed, 418 insertions(+)
> >  create mode 100644 lib/libfdt/fdt_overlay.c
> >
> 
> Is there a change log?

Yes, in the cover letter.

> > +static int overlay_update_local_node_references(void *fdto,
> > +   int tree_node,
> > +   int fixup_node,
> > +   uint32_t delta)
> > +{
> 
> Please add function comments for all of these.

Ack

> > +static int overlay_update_local_references(void *dto, uint32_t delta)
> > +{
> > +   int fixups;
> > +
> > +   fixups = fdt_path_offset(dto, "/__local_fixups__");
> > +   if (fixups < 0) {
> > +   /*
> > +* There's no local phandles to adjust, bail out
> 
> On on line:
> 
> /* There's not local ... */

Ok.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

Re: [U-Boot] U-boot support for FIT image with 64 bit Linux Kernel

[vinoth eswaran]

On Sun, Jun 26, 2016 at 4:53 AM, Simon Glass  wrote:
>
> +Bin
>
> Hi,
>
> On 23 June 2016 at 08:45, vinoth eswaran  wrote:
> > Hello,
> >
> > I am working on an embedded project with the u-boot and Minnowboard
> > max. With compressed kernel (bzImage) everything works fine, I want to
> > check the performance with
> > uncompressed kernel (vmlinux).
> >
> > So for creating the image.fit file I followed the instructions as per
> > the file x86-fit-boot.txt except that I have changed the compression
> > to none in the image.its file since I want to check the uncompressed
> > Kernel
> >
> > data = /incbin/("./vmlinux.bin");
> > type = "kernel";
> > arch = "x86";
> > os = "linux";
> > compression = "none";
>
> Do you have a load address?
>
> >
> > The bootcmd is "bootcmd=fatload mmc 1:1 0x0200 image.fit ; bootm
> > 0x0200". Now I am seeing that the
> > start up hangs after printing the commands starting kernel ... and the
> > time summary. Do you have any idea why it is happening?
> >
> > reading imagefit
> > 14566018 bytes read in 317 ms (43.8 MiB/s)
> > ## Loading kernel from FIT Image at 0200 ...
> >Using 'config@1' configuration
> >Verifying Hash Integrity ... OK
> >Trying 'kernel@1' kernel subimage
> >  Description:  Vanilla Linux kernel
> >  Created:  2016-06-23  14:22:21 UTC
> >  Type: Kernel Image
> >  Compression:  uncompressed
> >  Data Start:   0x02e8
> >  Data Size:14548992 Bytes = 13.9 MiB
> >  Architecture: Intel x86
> >  OS:   Linux
> >  Load Address: 0x0100
> >  Entry Point:  0x
> >  Hash algo:sha1
> >  Hash value:   5a0bddcbf1f54ac989fff662fc43fb5fc801ebbc
> >Verifying Hash Integrity ... sha1+ OK
> > ## Loading setup from FIT Image at 0200 ...
> >Using 'config@1' configuration
> >Trying 'setup@1' setup subimage
> >  Description:  Linux setup.bin
> >  Created:  2016-06-23  14:22:21 UTC
> >  Type: x86 setup.bin
> >  Compression:  uncompressed
> >  Data Start:   0x02de01d0
> >  Data Size:15708 Bytes = 15.3 KiB
> >  Hash algo:sha1
> >  Hash value:   08ffa163d054b9b0f5b11d4b3db2a16247cee395
> >Verifying Hash Integrity ... sha1+ OK
> >Loading setup from 0x02de01d0 to 0x0009
> >Loading Kernel Image ... OK
> > Setup at 0x09
> > Magic signature found
> > Kernel command line: "quiet"
> >
> > Starting kernel ...
> >
> >
> > I have seen in the document that it doesn't support for 64 bit kernel
> > and the document link given is now not accessible.
> > http://wiki.osdev.org/64-bit_Higher_Half_Kernel_with_GRUB_2
>
> Actually this comment is incorrect:
>
> "Note: these instructions assume a 32-bit kernel. U-Boot does not currently
> support booting a 64-bit kernel as it has no way of going into 64-bit mode on
> x86."
>
> U-Boot supports this. But you need to use x86_64 as the image type
> instead of x86.
>
> Are you booting with a 32- or 64-bit kernel?
>
> Perhaps try without the 'qiuet'?
>

Thanks for reply, your information helped me. But I would like to
request to sort this message when using x86_64 as architecture type in
the mkimage. The following debug message when creating the FIT image
guided me in the wrong path for the past few days, as I thought x86_64
is not supported and I need to use x86. With arch=x86_64 while
creating FIT/uImage,

   Invalid CPU Type - valid names are: alpha, arm, x86, ia64, m68k,
microblaze, mips, mips64, nios2, powerpc, ppc, s390, sh, sparc,
sparc64, blackfin, avr32
  Architecture: Unknown Architecture

Also the image type used for setup.bin. With image type= x86_setup

Invalid Image Type - valid names are: filesystem, firmware,
flat_dt, imximage, kernel, kwbimage, multi, omapimage, ramdisk,
script, standalone, flat_dt, kwbimage, imximage, ublimage

Many Thanks:)

Now with x86_64 as arch type I could run the system again. I should
have ignored the message and tested initially, but also confusions
with Load and entry addresses let me to stay blank.

>
> >
> > Mit Freundlichen Grüßen
> > VinothKumar
> > +49 1798909072
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 12/12] tests: Introduce DT overlay tests

[David Gibson]

On Mon, Jun 27, 2016 at 08:30:28AM +0200, Maxime Ripard wrote:
> Hi David,
> 
> On Mon, Jun 27, 2016 at 03:26:58PM +1000, David Gibson wrote:
> > On Fri, Jun 24, 2016 at 04:27:57PM +0200, Maxime Ripard wrote:
> > > This adds a bunch of unit tests for the "fdt apply" command.
> > > 
> > > They've all been run successfully in the sandbox. However, as you still
> > > require an out-of-tree dtc with overlay support, this is disabled by
> > > default.
> > > 
> > > Acked-by: Simon Glass 
> > > Acked-by: Pantelis Antoniou 
> > > Signed-off-by: Maxime Ripard 
> > 
> > These tests are geared for the u-boot tree, but for upstream
> > application we really need testcases that fit within dtc/libfdt as
> > well.  It would be good if you can adapt some or all of these tests to
> > work in that context.
> 
> That's the plan ! :)

Ok, great.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


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

Re: [U-Boot] [PATCH v3 12/12] tests: Introduce DT overlay tests

[Maxime Ripard]

Hi David,

On Mon, Jun 27, 2016 at 03:26:58PM +1000, David Gibson wrote:
> On Fri, Jun 24, 2016 at 04:27:57PM +0200, Maxime Ripard wrote:
> > This adds a bunch of unit tests for the "fdt apply" command.
> > 
> > They've all been run successfully in the sandbox. However, as you still
> > require an out-of-tree dtc with overlay support, this is disabled by
> > default.
> > 
> > Acked-by: Simon Glass 
> > Acked-by: Pantelis Antoniou 
> > Signed-off-by: Maxime Ripard 
> 
> These tests are geared for the u-boot tree, but for upstream
> application we really need testcases that fit within dtc/libfdt as
> well.  It would be good if you can adapt some or all of these tests to
> work in that context.

That's the plan ! :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v3 00/12] cmd: fdt: Add device tree overlays support

[Maxime Ripard]

Hi David,

On Mon, Jun 27, 2016 at 01:37:19AM +1000, David Gibson wrote:
> On Fri, Jun 24, 2016 at 04:27:45PM +0200, Maxime Ripard wrote:
> > Hi,
> > 
> > The device tree overlays are a great solution to the issue raised by
> > the bunch expandable boards we find everywhere these days, like the
> > Beaglebone, Raspberry Pi or CHIP.
> > 
> > However, most of the time, the overlays are applied through a
> > mechanism involving the firmware request interface in Linux, that is
> > only fully functional once the userspace has been mounted and is
> > running.
> > 
> > Some expansion boards might need to be enabled before that, because
> > they simply need to patch the DT early on, or need to be initialized
> > early in order to be fully functional, or because they provide access
> > to the root filesystem.
> > 
> > In these cases, having the bootloader applying the overlay before
> > Linux starts seems like the easiest solution.
> > 
> > This implementation doesn't provide all the Linux fancyness though,
> > there's no transactional application, which means that if the overlay
> > cannot be applied for a reason while you're still halfway through the
> > application, you're probably screwed. It also cannot remove an
> > overlay, but I don't think that it is currently a use-case.
> > 
> > There's still a bunch of work to extend the libfdt unit tests to test
> > the new functions introduced, but these patches will be submitted
> > in a near future.
> 
> Are you planning to send a new version of (the relevant portions of)
> these against upstream libfdt?

Of course, I just only have to work on the test cases now.

Simon wanted to merge this in U-Boot for the next merge window, and
then sync with libfdt when it would be merged, hence why I posted it
first.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

[U-Boot] [PATCH v2 5/5] tools: patman: Handle missing 'END' in non-last commit of a series

[Bin Meng]

The following python error:

Traceback (most recent call last):
  File "./tools/patman/patman", line 144, in 
series = patchstream.FixPatches(series, args)
  File "./tools/patman/patchstream.py", line 477, in FixPatches
commit = series.commits[count]
IndexError: list index out of range

is seen when:

- 'END' is missing in those tags
- those tags are put in the last part in a commit message
- the commit is not the last commit of the series

Add testing logic to see if a new commit starts.

Signed-off-by: Bin Meng 

---

Changes in v2:
- New patch to handle missing 'END' in non-last commit of a series

 tools/patman/patchstream.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index 0612612..69d5cfb 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -177,9 +177,10 @@ class PatchStream:
 elif commit_match:
 self.state = STATE_MSG_HEADER
 
-# If a tag is detected
+# If a tag is detected, or a new commit starts
 if series_tag_match or commit_tag_match or \
-   cover_match or cover_cc_match or signoff_match:
+   cover_match or cover_cc_match or signoff_match or \
+   self.state == STATE_MSG_HEADER:
 # but we are already in a section, this means 'END' is missing
 # for that section, fix it up.
 if self.in_section:
-- 
2.7.4

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

[U-Boot] [PATCH v2 2/5] tools: patman: Handle tag sections without an 'END'

[Bin Meng]

'Cover-letter', 'Series-notes' and 'Commit-notes' tags require an
'END' to be put at the end of its section. If we forget to put an
'END' in those sections, and these sections are followed by another
patman tag, patman generates incorrect patches. This adds codes to
handle such scenario.

Signed-off-by: Bin Meng 
Acked-by: Simon Glass 

---

Changes in v2:
- Update commit message to explain when such scenario is hit
- Add cover_match to the test logic
- Generate warning for missing 'END' case

 tools/patman/patchstream.py | 20 
 1 file changed, 20 insertions(+)

diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index 2c4efc5..ce8ffb8 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -169,6 +169,26 @@ class PatchStream:
 elif commit_match:
 self.state = STATE_MSG_HEADER
 
+# If a tag is detected, but we are already in a section,
+# this means 'END' is missing for that section, fix it up.
+if series_tag_match or commit_tag_match or \
+   cover_match or cover_cc_match or signoff_match:
+if self.in_section:
+self.warn.append("Missing 'END' in section '%s'" % 
self.in_section)
+if self.in_section == 'cover':
+self.series.cover = self.section
+elif self.in_section == 'notes':
+if self.is_log:
+self.series.notes += self.section
+elif self.in_section == 'commit-notes':
+if self.is_log:
+self.commit.notes += self.section
+else:
+self.warn.append("Unknown section '%s'" % self.in_section)
+self.in_section = None
+self.skip_blank = True
+self.section = []
+
 # If we are in a section, keep collecting lines until we see END
 if self.in_section:
 if line == 'END':
-- 
2.7.4

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

[U-Boot] [PATCH v2 4/5] tools: patman: Handle missing blank line for 'Series-changes'

[Bin Meng]

'Series-changes' uses blank line to indicate its end. If that is
missing, series internal state variable 'in_change' may be wrong.
Correct its state.

Signed-off-by: Bin Meng 
Acked-by: Simon Glass 

---

Changes in v2:
- Geneate warning when blank line is not found in 'Series-changes'

 tools/patman/patchstream.py | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index 9ae977f..0612612 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -177,10 +177,11 @@ class PatchStream:
 elif commit_match:
 self.state = STATE_MSG_HEADER
 
-# If a tag is detected, but we are already in a section,
-# this means 'END' is missing for that section, fix it up.
+# If a tag is detected
 if series_tag_match or commit_tag_match or \
cover_match or cover_cc_match or signoff_match:
+# but we are already in a section, this means 'END' is missing
+# for that section, fix it up.
 if self.in_section:
 self.warn.append("Missing 'END' in section '%s'" % 
self.in_section)
 if self.in_section == 'cover':
@@ -196,6 +197,11 @@ class PatchStream:
 self.in_section = None
 self.skip_blank = True
 self.section = []
+# but we are already in a change list, that means a blank line
+# is missing, fix it up.
+if self.in_change:
+self.warn.append("Missing 'blank line' in section 
'Series-changes'")
+self.in_change = 0
 
 # If we are in a section, keep collecting lines until we see END
 if self.in_section:
-- 
2.7.4

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

[U-Boot] [PATCH v2 1/5] tools: patman: Use cover_match for 'Cover-letter'

[Bin Meng]

Like other patman tags, use a new variable cover_match to indicate
a match for 'Cover-letter'.

Signed-off-by: Bin Meng 

---

Changes in v2:
- New patch to use cover_match for 'Cover-letter'

 tools/patman/patchstream.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index 27d031e..2c4efc5 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -150,6 +150,7 @@ class PatchStream:
 # Handle state transition and skipping blank lines
 series_tag_match = re_series_tag.match(line)
 commit_tag_match = re_commit_tag.match(line)
+cover_match = re_cover.match(line)
 cover_cc_match = re_cover_cc.match(line)
 signoff_match = re_signoff.match(line)
 tag_match = None
@@ -203,7 +204,7 @@ class PatchStream:
 self.skip_blank = False
 
 # Detect the start of a cover letter section
-elif re_cover.match(line):
+elif cover_match:
 self.in_section = 'cover'
 self.skip_blank = False
 
-- 
2.7.4

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

[U-Boot] [PATCH v2 3/5] tools: patman: Generate cover letter correctly when 'END' is missing

[Bin Meng]

If 'END' is missing in a 'Cover-letter' section, and that section
happens to show up at the very end of the commit message, and the
commit is the last commit of the series, patman fails to generate
cover letter for us. Handle this in CloseCommit of patchstream.

Signed-off-by: Bin Meng 

---

Changes in v2:
- Update commit message to explain when such case is hit
- Reset in_section, skip_blank and section variables too

 tools/patman/patchstream.py | 8 
 1 file changed, 8 insertions(+)

diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index ce8ffb8..9ae977f 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -112,6 +112,14 @@ class PatchStream:
 if self.commit and self.is_log:
 self.series.AddCommit(self.commit)
 self.commit = None
+# If 'END' is missing in a 'Cover-letter' section, and that section
+# happens to show up at the very end of the commit message, this is
+# the chance for us to fix it up.
+if self.in_section == 'cover' and self.is_log:
+self.series.cover = self.section
+self.in_section = None
+self.skip_blank = True
+self.section = []
 
 def ProcessLine(self, line):
 """Process a single line of a patch file or commit log
-- 
2.7.4

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

[U-Boot] [PATCH v2 0/5] tools: patman: Fixes to improve handling of various wrong usage

[Bin Meng]

This fixes several issues when abnormal tags are given to patman.
For example, when we forget to put an 'END' after 'Cover-letter',
patman does not handle such cases very well. This adds several
additional checking to let patman be a little more tolerant on
handling such exceptional paths.

This series is available at u-boot-x86/patman-working for testing.

Changes in v2:
- New patch to use cover_match for 'Cover-letter'
- Update commit message to explain when such scenario is hit
- Add cover_match to the test logic
- Generate warning for missing 'END' case
- Update commit message to explain when such case is hit
- Reset in_section, skip_blank and section variables too
- Geneate warning when blank line is not found in 'Series-changes'
- New patch to handle missing 'END' in non-last commit of a series

Bin Meng (5):
  tools: patman: Use cover_match for 'Cover-letter'
  tools: patman: Handle tag sections without an 'END'
  tools: patman: Generate cover letter correctly when 'END' is missing
  tools: patman: Handle missing blank line for 'Series-changes'
  tools: patman: Handle missing 'END' in non-last commit of a series

 tools/patman/patchstream.py | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

-- 
2.7.4

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

[U-Boot] Bug in cbfs

[Yaroslav K.]

Hello.

Current implementation of cbfs prints incorrect file names. In the
file fs/cbfs/cbfs.c
there are lines

swap_file_header(, fileHeader);
if (header.offset < sizeof(const struct cbfs_cachenode *) ||
header.offset > header.len) {
file_cbfs_result = CBFS_BAD_FILE;
return -1;
}
newNode->next = NULL;
newNode->type = header.type;
newNode->data = start + header.offset;
newNode->data_length = header.len;
name_len = header.offset - sizeof(struct cbfs_cachenode *);
newNode->name = (char *)fileHeader +
sizeof(struct cbfs_cachenode *);
newNode->name_length = name_len;
newNode->checksum = header.checksum;

Shouldn't sizeof(const struct cbfs_cachenode *) and sizeof(struct
cbfs_cachenode *)
be replaced with sizeof(struct cbfs_fileheader)?

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