Re: [U-Boot] [PATCH 15/15] imx: add i.MX8MQ EVK support

2018-11-12 Thread Jon Nettleton
On Fri, Nov 9, 2018 at 8:06 PM Troy Kisky
 wrote:
>
> On 11/9/2018 1:17 AM, Peng Fan wrote:
> > Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> > firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> > DRAM
>
>
> > +
> > +static struct dram_cfg_param lpddr4_ddrc_cfg[] = {
> > + /* Start to config, default 3200mbps */
> > + /* dis_dq=1, indicates no reads or writes are issued to SDRAM */
> > + { DDRC_DBG1(0), 0x0001 },
>
>
> Just a little elaboration on how a structure might work here
>
> #define DDRC_ADDR(reg, x) &((struct ddrc *)(DDRC_IPS_BASE_ADDR(x))->reg)
>
> { DDRC_ADDR(dbg1, 0), 0x0001 },
>
>
>
> Thanks for working on this Peng!
>
>
> BR
> Troy

Yes thanks for working on this Peng.  Just to clarify one thing.  Do
you have a script that is generating the structures from output of the
mx8m_ddr_tool, or is the mx8m_ddr_tool being changed to output the
structures?

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


Re: [U-Boot] [PATCH v2 07/29] riscv: add Kconfig entries for the code model

2018-11-12 Thread Bin Meng
Hi Lukas,

On Wed, Oct 31, 2018 at 11:01 PM Auer, Lukas
 wrote:
>
> Hi Bin,
>
> On Wed, 2018-10-31 at 10:13 +0800, Bin Meng wrote:
> > Hi Lukas,
> >
> > On Tue, Oct 30, 2018 at 8:57 PM Lukas Auer
> >  wrote:
> > >
> > > RISC-V has two code models, medium low (medlow) and medium any
> > > (medany).
> > > Medlow limits addressable memory to a single 2 GiB range between
> > > the
> > > absolute addresses -2 GiB and +2 GiB. Medany limits addressable
> > > memory
> > > to any single 2 GiB address range.
> > > By default, medlow is selected on 32-bit systems and medany on 64-
> > > bit
> > > systems. This matches the configuration in Linux.
> > >
> > > The -mcmodel compiler flag is selected according to the Kconfig
> > > configuration.
> > >
> > > Signed-off-by: Lukas Auer 
> > > ---
> > >
> > > Changes in v2:
> > > - Change ISA string construction, as suggested by Bin Meng
> > >
> > >  arch/riscv/Kconfig  | 19 +++
> > >  arch/riscv/Makefile |  9 -
> > >  2 files changed, 27 insertions(+), 1 deletion(-)
> > >
> >
> > I had a further look at this, and I suspect we should stick to medlow
> > for U-Boot, even for 64-bit. As U-Boot will be only running within
> > the
> > low 4GB memory space even for 64-bit. Adding medany seems
> > unnecessary.
> >
> > Regards,
> > Bin
>
> You are right, however I think it's actually because U-Boot is compiled
> as a position independent binary. U-Boot can be relocated above what's
> addressable with 32-bit if the memory is large enough. This should
> cause issues with medlow.
> I suspects that's the reason, but I am not entirely sure. What do you
> think?

Sorry I missed this email. I just found in your v3 this patch was
dropped. I think this is still needed to explicitly pass the code
model to the compiler. I believe we only need change to:

+choice
+   prompt "Code Model"
+   default CMODEL_MEDLOW

I can include the modified patch in my upcoming series.

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


Re: [U-Boot] [PATCH v2] fsl-lsch3: soc: Enable AHB read support for Flexspi controller

2018-11-12 Thread Ashish Kumar


> -Original Message-
> From: York Sun
> Sent: Tuesday, November 13, 2018 3:34 AM
> To: Ashish Kumar 
> Cc: u-boot@lists.denx.de; Rajat Srivastava ; Yogesh
> Narayan Gaur 
> Subject: Re: [PATCH v2] fsl-lsch3: soc: Enable AHB read support for Flexspi
> controller
> 
> On 11/2/18 8:59 AM, York Sun wrote:
> > On 9/26/18 4:10 AM, Ashish Kumar wrote:
> >> Enable AHB support for Flexspi controller interface meaning memory
> >> can be accessed via md command using absolute addresses
> >>
> >> Signed-off-by: Yogesh Gaur 
> >> Signed-off-by: Rajat Srivastava 
> >> Signed-off-by: Ashish Kumar 
> >> ---
> >> v2:
> >>  1. Rename FSPI to FlexSPI in description and comments  2.
> >> s/cmd/command  3. Add macro and comments to improve readablity of
> >> code in soc.c  4. Add declaration in soc.h for fspi_ahb_init()
> >>
> >>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 10 +
> >>  arch/arm/cpu/armv8/fsl-layerscape/soc.c   | 44 +++
> >>  .../arm/include/asm/arch-fsl-layerscape/soc.h |  7 +++
> >>  3 files changed, 61 insertions(+)
> >>
> >> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> index 5280d33ec8..70f26973e9 100644
> >> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> @@ -327,6 +327,16 @@ config SYS_FSPI_AHB_INIT
> >>  performed. Default LUT programmed in AHB mode is Fast Read
> command
> >>  with 4-byte addressing enabled.
> >
> > SYS_FSPI_AHB_INIT doesn't exist yet.
> >
> >>
> >> +config FSPI_AHB_EN_4BYTE
> >> +  bool "Enable 4-byte Fast Read command for AHB mode"
> >> +  depends on NXP_FSPI
> >> +  default n
> >> +  help
> >> +The default setting for FlexSPI AHB bus just supports 3-byte
> addressing.
> >> +But some FlexSPI flash sizes are up to 64MBytes.
> >> +This flag enables fast read command for AHB mode and modifies
> required
> >> +LUT to support full FlexSPI flash.
> >> +
> >
> > NXP_FSPI doesn't exist yet.
> >
> > Do you have dependency I missed?
> >
> 
> Please fix your patch asap.
I have created v3[http://patchwork.ozlabs.org/patch/996846/] adding dependency 
patch information.

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


[U-Boot] [PATCH v3] fsl-lsch3: soc: Enable AHB read support for Flexspi controller

2018-11-12 Thread Ashish Kumar
Enable AHB support for Flexspi controller interface meaning
memory can be accessed via md command using absolute addresses

Signed-off-by: Yogesh Gaur 
Signed-off-by: Rajat Srivastava 
Signed-off-by: Ashish Kumar 
---
v3:
Depends upon http://patchwork.ozlabs.org/patch/975009/
v2:
 1. Rename FSPI to FlexSPI in description and comments
 2. s/cmd/command
 3. Add macro and comments to improve readablity of code in soc.c
 4. Add declaration in soc.h for fspi_ahb_init()

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 10 +
 arch/arm/cpu/armv8/fsl-layerscape/soc.c   | 44 +++
 .../arm/include/asm/arch-fsl-layerscape/soc.h |  7 +++
 3 files changed, 61 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 5280d33ec8..70f26973e9 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -327,6 +327,16 @@ config SYS_FSPI_AHB_INIT
  performed. Default LUT programmed in AHB mode is Fast Read command
  with 4-byte addressing enabled.
 
+config FSPI_AHB_EN_4BYTE
+   bool "Enable 4-byte Fast Read command for AHB mode"
+   depends on NXP_FSPI
+   default n
+   help
+ The default setting for FlexSPI AHB bus just supports 3-byte 
addressing.
+ But some FlexSPI flash sizes are up to 64MBytes.
+ This flag enables fast read command for AHB mode and modifies required
+ LUT to support full FlexSPI flash.
+
 config SYS_CCI400_OFFSET
hex "Offset for CCI400 base"
depends on SYS_FSL_HAS_CCI400
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 3f15cb08ff..0a0e112a88 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -640,6 +640,47 @@ void fsl_lsch2_early_init_f(void)
 }
 #endif
 
+#ifdef CONFIG_FSPI_AHB_EN_4BYTE
+int fspi_ahb_init(void)
+{
+   /* Enable 4bytes address support and fast read */
+   u32 *fspi_lut, lut_key, *fspi_key;
+
+   fspi_key = (void *)SYS_NXP_FSPI_ADDR + SYS_NXP_FSPI_LUTKEY_BASE_ADDR;
+   fspi_lut = (void *)SYS_NXP_FSPI_ADDR + SYS_NXP_FSPI_LUT_BASE_ADDR;
+
+   lut_key = in_be32(fspi_key);
+
+   if (lut_key == SYS_NXP_FSPI_LUTKEY) {
+   /* That means the register is BE */
+   out_be32(fspi_key, SYS_NXP_FSPI_LUTKEY);
+   /* Unlock the lut table */
+   out_be32(fspi_key + 1, SYS_NXP_FSPI_LUTCR_UNLOCK);
+   /* Create READ LUT */
+   out_be32(fspi_lut, 0x0820040c);
+   out_be32(fspi_lut + 1, 0x24003008);
+   out_be32(fspi_lut + 2, 0x);
+   /* Lock the lut table */
+   out_be32(fspi_key, SYS_NXP_FSPI_LUTKEY);
+   out_be32(fspi_key + 1, SYS_NXP_FSPI_LUTCR_LOCK);
+   } else {
+   /* That means the register is LE */
+   out_le32(fspi_key, SYS_NXP_FSPI_LUTKEY);
+   /* Unlock the lut table */
+   out_le32(fspi_key + 1, SYS_NXP_FSPI_LUTCR_UNLOCK);
+   /* Create READ LUT */
+   out_le32(fspi_lut, 0x0820040c);
+   out_le32(fspi_lut + 1, 0x24003008);
+   out_le32(fspi_lut + 2, 0x);
+   /* Lock the lut table */
+   out_le32(fspi_key, SYS_NXP_FSPI_LUTKEY);
+   out_le32(fspi_key + 1, SYS_NXP_FSPI_LUTCR_LOCK);
+   }
+
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_QSPI_AHB_INIT
 /* Enable 4bytes address support and fast read */
 int qspi_ahb_init(void)
@@ -688,6 +729,9 @@ int board_late_init(void)
 #ifdef CONFIG_QSPI_AHB_INIT
qspi_ahb_init();
 #endif
+#ifdef CONFIG_FSPI_AHB_EN_4BYTE
+   fspi_ahb_init();
+#endif
 
return 0;
 }
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h 
b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
index 61b6e4bf07..84450c76ed 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
@@ -102,6 +102,13 @@ void init_pfe_scfg_dcfg_regs(void);
 int qspi_ahb_init(void);
 #endif
 
+#ifdef CONFIG_FSPI_AHB_EN_4BYTE
+#define SYS_NXP_FSPI_LUTCR_LOCK0x0001
+#define SYS_NXP_FSPI_LUTCR_UNLOCK  0x0002
+#define SYS_NXP_FSPI_LUTKEY0x5AF05AF0
+int fspi_ahb_init(void);
+#endif
+
 void cpu_name(char *name);
 #ifdef CONFIG_SYS_FSL_ERRATUM_A009635
 void erratum_a009635(void);
-- 
2.17.1

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


Re: [U-Boot] [PATCH v3 00/28] General fixes / cleanup for RISC-V and improvements to qemu-riscv

2018-11-12 Thread Rick Chen
Bin Meng  於 2018年11月13日 週二 下午2:49寫道:
>
> Hi Rick,
>
> On Tue, Nov 13, 2018 at 2:41 PM Rick Chen  wrote:
> >
> > > > This patch series includes general fixes and cleanup for RISC-V. It 
> > > > also adds
> > > > support for booting Linux on qemu-riscv. At the moment, only single-core
> > > > systems are supported. Support for multi-core systems will be added 
> > > > with a
> > > > future patch series.
> > > >
> > > > To boot Linux on qemu-riscv, Linux must be compiled into BBL as a 
> > > > payload. BBL
> > > > must be included in a FIT image and supplied to QEMU with the -kernel
> > > > parameter. Its location in memory is embedded in the device tree, which 
> > > > QEMU
> > > > passes to u-boot.
> > > > To test this, QEMU and riscv-pk (BBL) must be modified. QEMU is 
> > > > modified to add
> > > > support for loading binary files (FIT images in this case) in addition 
> > > > to ELF files.
> > > > riscv-pk must be modified to adjust the link address. A pull request 
> > > > for QEMU,
> > > > which implements this, is available at [1]. A modified version of 
> > > > riscv-pk is
> > > > available at [2].
> > > >
> > > > This series applies on top of u-boot-dm/next.
> > > >
> >
> > Hi Lukas
> >
> > Apply on top of u-boot-dm/next is ok.
> > But apply on u-boot.git will have some conflicts.
> >
>
> Lukas's series is based on the VirtIO support which is currently in
> the u-boot-dm/master tree. I believe Simon is going to send a PR as
> soon as merge window opens tomorrow if everything goes well.
>
> > Applying: riscv: qemu: use device tree passed by prior boot stage
> > error: patch failed: board/emulation/qemu-riscv/qemu-riscv.c:9
> > error: board/emulation/qemu-riscv/qemu-riscv.c: patch does not apply
> > Patch failed at 0001 riscv: qemu: use device tree passed by prior boot stage
> >
> > May I ask which tree do you want to merge into mainline ?
> > from dm tree or riscv tree ?
> > So the merge of patch work  can go smoothly.
> >
>
> I think you can wait for Simon's dm tree get merged in u-boot/master,
> then file PR after that. Thanks!
>

Hi Bin

Got it.

Thanks
Rick

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


Re: [U-Boot] [PATCH v3 00/28] General fixes / cleanup for RISC-V and improvements to qemu-riscv

2018-11-12 Thread Bin Meng
Hi Rick,

On Tue, Nov 13, 2018 at 2:41 PM Rick Chen  wrote:
>
> > > This patch series includes general fixes and cleanup for RISC-V. It also 
> > > adds
> > > support for booting Linux on qemu-riscv. At the moment, only single-core
> > > systems are supported. Support for multi-core systems will be added with a
> > > future patch series.
> > >
> > > To boot Linux on qemu-riscv, Linux must be compiled into BBL as a 
> > > payload. BBL
> > > must be included in a FIT image and supplied to QEMU with the -kernel
> > > parameter. Its location in memory is embedded in the device tree, which 
> > > QEMU
> > > passes to u-boot.
> > > To test this, QEMU and riscv-pk (BBL) must be modified. QEMU is modified 
> > > to add
> > > support for loading binary files (FIT images in this case) in addition to 
> > > ELF files.
> > > riscv-pk must be modified to adjust the link address. A pull request for 
> > > QEMU,
> > > which implements this, is available at [1]. A modified version of 
> > > riscv-pk is
> > > available at [2].
> > >
> > > This series applies on top of u-boot-dm/next.
> > >
>
> Hi Lukas
>
> Apply on top of u-boot-dm/next is ok.
> But apply on u-boot.git will have some conflicts.
>

Lukas's series is based on the VirtIO support which is currently in
the u-boot-dm/master tree. I believe Simon is going to send a PR as
soon as merge window opens tomorrow if everything goes well.

> Applying: riscv: qemu: use device tree passed by prior boot stage
> error: patch failed: board/emulation/qemu-riscv/qemu-riscv.c:9
> error: board/emulation/qemu-riscv/qemu-riscv.c: patch does not apply
> Patch failed at 0001 riscv: qemu: use device tree passed by prior boot stage
>
> May I ask which tree do you want to merge into mainline ?
> from dm tree or riscv tree ?
> So the merge of patch work  can go smoothly.
>

I think you can wait for Simon's dm tree get merged in u-boot/master,
then file PR after that. Thanks!

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


Re: [U-Boot] [PATCH v3 00/28] General fixes / cleanup for RISC-V and improvements to qemu-riscv

2018-11-12 Thread Rick Chen
> > This patch series includes general fixes and cleanup for RISC-V. It also 
> > adds
> > support for booting Linux on qemu-riscv. At the moment, only single-core
> > systems are supported. Support for multi-core systems will be added with a
> > future patch series.
> >
> > To boot Linux on qemu-riscv, Linux must be compiled into BBL as a payload. 
> > BBL
> > must be included in a FIT image and supplied to QEMU with the -kernel
> > parameter. Its location in memory is embedded in the device tree, which QEMU
> > passes to u-boot.
> > To test this, QEMU and riscv-pk (BBL) must be modified. QEMU is modified to 
> > add
> > support for loading binary files (FIT images in this case) in addition to 
> > ELF files.
> > riscv-pk must be modified to adjust the link address. A pull request for 
> > QEMU,
> > which implements this, is available at [1]. A modified version of riscv-pk 
> > is
> > available at [2].
> >
> > This series applies on top of u-boot-dm/next.
> >

Hi Lukas

Apply on top of u-boot-dm/next is ok.
But apply on u-boot.git will have some conflicts.

Applying: riscv: qemu: use device tree passed by prior boot stage
error: patch failed: board/emulation/qemu-riscv/qemu-riscv.c:9
error: board/emulation/qemu-riscv/qemu-riscv.c: patch does not apply
Patch failed at 0001 riscv: qemu: use device tree passed by prior boot stage

May I ask which tree do you want to merge into mainline ?
from dm tree or riscv tree ?
So the merge of patch work  can go smoothly.

Thanks

Rick


> > [1]: https://github.com/riscv/riscv-qemu/pull/175
> > [2]: https://github.com/lukasauer/riscv-pk/tree/riscv-u-boot
> >
> > Changes in v3:
> > - New patch to add VirtIO distro boot command
> > - New patch to enable distro boot on qemu-riscv32/64
> > - Adapt code and commit message to distro boot
> > - Replace printf with debug
> > - Clarify debug messages if no chosen node is found
> >
> > Changes in v2:
> > - Replace the description of RISCV_ISA_C with that of the Linux kernel, as
> > suggested by Bin Meng
> > - Change ISA string construction, as suggested by Bin Meng
> > - Remove 0-padding in the format string to avoid printing 16 digits on RV32I
> > systems
> > - New patch to replace patch "riscv: remove CONFIG_INIT_CRITICAL"
> > - Drop removal of code that stores the contents of a2; this broke the board
> > ax25-ae350. The code will be removed again in a future patch.
> > - Rebase onto u-boot-dm/next
> > - Rebase onto u-boot-dm/next
> > - Move prototype location to match the location of the function in ofnode.c
> > - Rebase onto u-boot-dm/next
> > - Boot Linux with the device tree provided by the prior boot stage
> > - New patch
> >
> > Bin Meng (1):
> >   Drop CONFIG_INIT_CRITICAL
> >
> > Lukas Auer (27):
> >   tools: .gitignore: add prelink-riscv
> >   dts: riscv: update makefile to also clean the RISC-V dts directory
> >   riscv: rename CPU_RISCV_32/64 to match architecture names
> > ARCH_RV32I/64I
> >   riscv: select CONFIG_PHYS_64BIT on RV64I systems
> >   riscv: add Kconfig entries for the C and A ISA extensions
> >   riscv: set -march and -mabi based on the Kconfig configuration
> >   riscv: enable -fdata-sections
> >   riscv: fix use of incorrectly sized variables
> >   riscv: make use of the barrier functions from Linux
> >   riscv: do not reimplement generic io functions
> >   riscv: complete the list of exception codes
> >   riscv: treat undefined exception codes as reserved
> >   riscv: hang on unhandled exceptions
> >   riscv: implement the invalidate_icache_* functions
> >   riscv: fix inconsistent use of spaces and tabs in start.S
> >   riscv: align mtvec on a 4-byte boundary
> >   riscv: remove unused labels in start.S
> >   riscv: do not blindly modify the mstatus CSR
> >   riscv: save hart ID and device tree passed by prior boot stage
> >   riscv: qemu: use device tree passed by prior boot stage
> >   riscv: qemu: support booting Linux
> >   riscv: align bootm implementation with that of other architectures
> >   distro_bootcmd: add VirtIO distro boot command
> >   riscv: qemu: enable distro boot
> >   dm: core: add missing prototype for ofnode_read_u64
> >   riscv: qemu: detect and boot the kernel passed by QEMU
> >   riscv: qemu: clear kernel-start/-end in device tree as workaround for
> > BBL
> >
> >  arch/nds32/cpu/n1213/start.S|  51 
> >  arch/riscv/Kconfig  |  28 +-
> >  arch/riscv/Makefile |  20 ++
> >  arch/riscv/config.mk|   7 +-
> >  arch/riscv/cpu/cpu.c|   6 +
> >  arch/riscv/cpu/start.S  | 342 
> >  arch/riscv/include/asm/barrier.h|  67 +
> >  arch/riscv/include/asm/io.h |  48 +---
> >  arch/riscv/include/asm/posix_types.h|   6 +-
> >  arch/riscv/include/asm/types.h  |   4 +
> >  arch/riscv/lib/bootm.c  |  97 +--
> >  arch/riscv/lib/cache.c  |  10 +
> >  arch/riscv/lib/interrupts.c   

Re: [U-Boot] [PATCH v3 27/28] riscv: qemu: detect and boot the kernel passed by QEMU

2018-11-12 Thread Bin Meng
On Fri, Nov 9, 2018 at 9:00 PM Lukas Auer
 wrote:
>
> QEMU embeds the location of the kernel image in the device tree. Store
> this address in the environment as variable kernel_start. It is used in
> the board-local distro boot command QEMU to boot the kernel with the
> U-Boot device tree. The QEMU boot command is added as the first boot
> target device.
>
> Signed-off-by: Lukas Auer 
> ---
>
> Changes in v3:
> - Adapt code and commit message to distro boot
> - Replace printf with debug
> - Clarify debug messages if no chosen node is found
>
> Changes in v2:
> - Rebase onto u-boot-dm/next
> - Boot Linux with the device tree provided by the prior boot stage
>
>  board/emulation/qemu-riscv/Kconfig  |  1 +
>  board/emulation/qemu-riscv/qemu-riscv.c | 29 +
>  include/configs/qemu-riscv.h| 10 +
>  3 files changed, 40 insertions(+)
>

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


Re: [U-Boot] [PATCH v3 24/28] distro_bootcmd: add VirtIO distro boot command

2018-11-12 Thread Bin Meng
On Fri, Nov 9, 2018 at 9:00 PM Lukas Auer
 wrote:
>
> Add a boot command to distro boot to support disks connected over the
> VirtIO bus. The boot command uses the shared block environment.
>
> Signed-off-by: Lukas Auer 
> ---
>
> Changes in v3:
> - New patch to add VirtIO distro boot command
>
> Changes in v2: None
>
>  doc/README.distro   |  3 ++-
>  include/config_distro_bootcmd.h | 13 +
>  2 files changed, 15 insertions(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v3 25/28] riscv: qemu: enable distro boot

2018-11-12 Thread Bin Meng
On Fri, Nov 9, 2018 at 9:00 PM Lukas Auer
 wrote:
>
> Enable distro boot on the qemu-riscv32/64 boards. Supported boot target
> devices are VirtIO and DHCP.
>
> Signed-off-by: Lukas Auer 
> ---
>
> Changes in v3:
> - New patch to enable distro boot on qemu-riscv32/64
>
> Changes in v2: None
>
>  configs/qemu-riscv32_defconfig |  2 ++
>  configs/qemu-riscv64_defconfig |  2 ++
>  include/configs/qemu-riscv.h   | 14 +-
>  3 files changed, 17 insertions(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH 3/4] fs: prevent overwriting reserved memory

2018-11-12 Thread Simon Goldschmidt
On Tue, Nov 13, 2018 at 3:23 AM Fabio Estevam  wrote:
>
> Hi Simon,
>
> On Mon, Nov 12, 2018 at 7:25 PM Simon Goldschmidt
>  wrote:
>
> > diff --git a/fs/fs.c b/fs/fs.c
> > index adae98d021..4baf6b1c39 100644
> > --- a/fs/fs.c
> > +++ b/fs/fs.c
> > @@ -428,13 +428,57 @@ int fs_size(const char *filename, loff_t *size)
> > return ret;
> >  }
> >
> > -int fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
> > -   loff_t *actread)
> > +#ifdef CONFIG_LMB
>
> Unrelated to your series, but I was wondering if we could get rid of
> the CONFIG_LMB option.
>
> As far as I can see all the architectures define it, the only
> exception being arch/sh.
>
> If you agree I can send a patch after your series gets applied that
> removes CONFIG_LMB.

Sure, that would clean things up.

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


Re: [U-Boot] [PATCH v2] ARM: Samsung: Add Exynos5422-based Odroid HC2 support

2018-11-12 Thread Anand Moon
Hi Dirk,

On Mon, 12 Nov 2018 at 23:54, Dirk Meul  wrote:
>
> Hi Anand Moon,
>
> with U-Boot 2018.11-rc3-00062-g26cc40d8c4 and booting Fedora 28 Server
> I have no problems with a *warm boot* of my Odroid HC2. So I think this
> is not a general problem.
>
> My u-boot.bin was created using:
> $ ARCH=arm CROSS_COMPILE=arm-linux-gnu- make odroid-xu3_defconfig
> $ ARCH=arm CROSS_COMPILE=arm-linux-gnu- make -j $(nproc)
> on Fedora 28 Workstation.
>
> BR,
> Dirk
>

I could be distro issue with Arch Linux I will recheck on other distro.

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


[U-Boot] [PATCH v2] qemu-arm: Enable VirtIO distro target

2018-11-12 Thread Sumit Garg
With -device virtio-blk-device,drive=hd0, it could detect distro boot
target.

Signed-off-by: Sumit Garg 
---

Changes in v2:
Change boot order to SCSI; VIRTIO; DHCP as DHCP is quiet slow, so kept
as last boot option.

Depends on https://patchwork.ozlabs.org/patch/995524/ which adds VirtIO
distro boot command.

 include/configs/qemu-arm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index fedc466..33dcce0 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -25,6 +25,7 @@
 
 #define BOOT_TARGET_DEVICES(func) \
func(SCSI, scsi, 0) \
+   func(VIRTIO, virtio, 0) \
func(DHCP, dhcp, na)
 
 #include 
-- 
2.7.4

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


Re: [U-Boot] [PATCH] qemu-arm: Enable VirtIO distro target

2018-11-12 Thread Sumit Garg
Hi Tuomas,

On Tue, 13 Nov 2018 at 00:23, Tuomas Tynkkynen  wrote:
>
> Hi Sumit,
>
> On Mon, 12 Nov 2018 15:29:08 +0530
> Sumit Garg  wrote:
>
> > With -device virtio-blk-device,drive=hd0, it could detect distro boot
> > target.
> >
> > Signed-off-by: Sumit Garg 
> > ---
> ...
> > diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> > index fedc466..437c3ae 100644
> > --- a/include/configs/qemu-arm.h
> > +++ b/include/configs/qemu-arm.h
> > @@ -25,7 +25,8 @@
> >
> >  #define BOOT_TARGET_DEVICES(func) \
> >   func(SCSI, scsi, 0) \
> > - func(DHCP, dhcp, na)
> > + func(DHCP, dhcp, na) \
> > + func(VIRTIO, virtio, 0)
> >
> >  #include 
> >
>
> I think typically DHCP is the very last boot option since it can take
> quite long to notice if there's no DHCP server on the network and fall
> back to the next option. So perhaps an order of
>
> SCSI; VIRTIO; DHCP
>

Yeah it does makes sense. Will change in v2.

-Sumit

> would be better.
>
> Other than that, looks fine to me.
>
> - Tuomas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] imx8: scu: Update call to lists_bind_fdt()

2018-11-12 Thread Simon Glass
On 12 November 2018 at 08:02, Bin Meng  wrote:
> This commit should be squashed into
>
> commit 2bba642dbaa4 ("dm: core: Respect drivers with the
> DM_FLAG_PRE_RELOC flag in lists_bind_fdt()")
>
> on u-boot-dm/master branch.
>
> Signed-off-by: Bin Meng 
> ---
>
>  drivers/misc/imx8/scu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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


Re: [U-Boot] [PATCH 1/2] Revert "imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO"

2018-11-12 Thread Simon Glass
On 12 November 2018 at 08:02, Bin Meng  wrote:
>
> This reverts commit c5bbfaf05dc8592b479a44df6abaadbab54fec2b.
>
> Disabling CONFIG_DISPLAY_CPUINFO was a temporary solution to get
> the v2018.11 release out. Now the merge window opens, revert it.
>
> Signed-off-by: Bin Meng 
> ---
>
>  configs/imx8qxp_mek_defconfig | 1 -
>  1 file changed, 1 deletion(-)

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


Re: [U-Boot] [PATCH v2 4/4] cmd: adc: add an option to scan some or all available channels

2018-11-12 Thread Simon Glass
On 12 November 2018 at 06:04, Fabrice Gasnier  wrote:
> Add new option to 'adc' command to do a single scan of:
> - some channel(s), using mask argument
> - all channels available on an ADC device (when optional mask is omitted).
>
> Signed-off-by: Fabrice Gasnier 
> ---
>
> Changes in v2: None
>
>  cmd/adc.c | 55 ++-
>  1 file changed, 54 insertions(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH v2 2/4] cmd: adc: add info on channel mask

2018-11-12 Thread Simon Glass
On 12 November 2018 at 06:03, Fabrice Gasnier  wrote:
> Enhance adc info command to report also the channel mask.
>
> Signed-off-by: Fabrice Gasnier 
> ---
>
> Changes in v2: None
>
>  cmd/adc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH v2 3/4] cmd: adc: print single conversion also in uV

2018-11-12 Thread Simon Glass
On 12 November 2018 at 06:04, Fabrice Gasnier  wrote:
> Use newly introduced adc_raw_to_uV() API to print conversion result
> both as raw value and micro-volts by default.
>
> Signed-off-by: Fabrice Gasnier 
> ---
>
> Changes in v2: None
>
>  cmd/adc.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

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


Re: [U-Boot] [PATCH v2 1/4] dm: adc: add uclass's mask and conversion helpers

2018-11-12 Thread Simon Glass
On 12 November 2018 at 06:03, Fabrice Gasnier  wrote:
> Add two functions to ADC uclass's:
> - adc_raw_to_uV() to ease ADC raw value conversion to microvolts
> - adc_channel_mask() to get channels on consumer side
>
> Signed-off-by: Fabrice Gasnier 
> ---
>
> Changes in v2:
> - Add calls to the new functions in test/dm/adc.c as suggested by Simon
>
>  drivers/adc/adc-uclass.c | 37 +
>  include/adc.h| 21 +
>  test/dm/adc.c| 36 
>  3 files changed, 94 insertions(+)

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


Re: [U-Boot] [PATCH 3/4] fs: prevent overwriting reserved memory

2018-11-12 Thread Fabio Estevam
Hi Simon,

On Mon, Nov 12, 2018 at 7:25 PM Simon Goldschmidt
 wrote:

> diff --git a/fs/fs.c b/fs/fs.c
> index adae98d021..4baf6b1c39 100644
> --- a/fs/fs.c
> +++ b/fs/fs.c
> @@ -428,13 +428,57 @@ int fs_size(const char *filename, loff_t *size)
> return ret;
>  }
>
> -int fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
> -   loff_t *actread)
> +#ifdef CONFIG_LMB

Unrelated to your series, but I was wondering if we could get rid of
the CONFIG_LMB option.

As far as I can see all the architectures define it, the only
exception being arch/sh.

If you agree I can send a patch after your series gets applied that
removes CONFIG_LMB.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [ANN] U-Boot v2018.11 delayed a day

2018-11-12 Thread Marek Vasut
On 11/13/2018 02:12 AM, Tom Rini wrote:
> On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:
>> On 11/12/2018 11:25 PM, Tom Rini wrote:
>>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
 On 11/12/2018 10:40 PM, Tom Rini wrote:
> Hey all,
>
> Since Jagan promise a v2 SPI PR for some build fixes that we should have
> in the release and I believe didn't get them out before the end of his
> day, I'm letting everyone know now to expect the release tomorrow
> instead, thanks!

 Will anyone have any chance to test those fixes to verify they didn't
 break anything ?
>>>
>>> Since they're obvious enough by inspection, I'm not worried about it.
>>
>> Which patches are those ?
> 
> The ones in question?

Yes, is there a list ?

 I believe this is yet another manifestation of the problems of the 2
 month release cycle, which I think is too short and stressful.
>>>
>>> And I believe that's a red herring.  All the same I am still considering
>>> changes.
>>
>> I'd really like to know how do other maintainers feel about this 2 month
>> release cycle vs. for example 3 month like Linux does. I think the later
>> is about right, 2 months is too short.
> 
> Yes, I've asked before and there's a few people in the same camp as you,
> and there's a few people who like 2 months, and there's a large number
> of no strong opinions.  That's why I'm still thinking about changing
> things again.

Maybe we need a poll ?

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


Re: [U-Boot] [ANN] U-Boot v2018.11 delayed a day

2018-11-12 Thread Tom Rini
On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:
> On 11/12/2018 11:25 PM, Tom Rini wrote:
> > On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
> >> On 11/12/2018 10:40 PM, Tom Rini wrote:
> >>> Hey all,
> >>>
> >>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
> >>> in the release and I believe didn't get them out before the end of his
> >>> day, I'm letting everyone know now to expect the release tomorrow
> >>> instead, thanks!
> >>
> >> Will anyone have any chance to test those fixes to verify they didn't
> >> break anything ?
> > 
> > Since they're obvious enough by inspection, I'm not worried about it.
> 
> Which patches are those ?

The ones in question?

> >> I believe this is yet another manifestation of the problems of the 2
> >> month release cycle, which I think is too short and stressful.
> > 
> > And I believe that's a red herring.  All the same I am still considering
> > changes.
> 
> I'd really like to know how do other maintainers feel about this 2 month
> release cycle vs. for example 3 month like Linux does. I think the later
> is about right, 2 months is too short.

Yes, I've asked before and there's a few people in the same camp as you,
and there's a few people who like 2 months, and there's a large number
of no strong opinions.  That's why I'm still thinking about changing
things again.

-- 
Tom


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


Re: [U-Boot] [ANN] U-Boot v2018.11 delayed a day

2018-11-12 Thread Marek Vasut
On 11/12/2018 11:25 PM, Tom Rini wrote:
> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
>> On 11/12/2018 10:40 PM, Tom Rini wrote:
>>> Hey all,
>>>
>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
>>> in the release and I believe didn't get them out before the end of his
>>> day, I'm letting everyone know now to expect the release tomorrow
>>> instead, thanks!
>>
>> Will anyone have any chance to test those fixes to verify they didn't
>> break anything ?
> 
> Since they're obvious enough by inspection, I'm not worried about it.

Which patches are those ?

>> I believe this is yet another manifestation of the problems of the 2
>> month release cycle, which I think is too short and stressful.
> 
> And I believe that's a red herring.  All the same I am still considering
> changes.

I'd really like to know how do other maintainers feel about this 2 month
release cycle vs. for example 3 month like Linux does. I think the later
is about right, 2 months is too short.

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


Re: [U-Boot] [ANN] U-Boot v2018.11 delayed a day

2018-11-12 Thread Tom Rini
On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
> On 11/12/2018 10:40 PM, Tom Rini wrote:
> > Hey all,
> > 
> > Since Jagan promise a v2 SPI PR for some build fixes that we should have
> > in the release and I believe didn't get them out before the end of his
> > day, I'm letting everyone know now to expect the release tomorrow
> > instead, thanks!
> 
> Will anyone have any chance to test those fixes to verify they didn't
> break anything ?

Since they're obvious enough by inspection, I'm not worried about it.

> I believe this is yet another manifestation of the problems of the 2
> month release cycle, which I think is too short and stressful.

And I believe that's a red herring.  All the same I am still considering
changes.

-- 
Tom


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


Re: [U-Boot] [ANN] U-Boot v2018.11 delayed a day

2018-11-12 Thread Marek Vasut
On 11/12/2018 10:40 PM, Tom Rini wrote:
> Hey all,
> 
> Since Jagan promise a v2 SPI PR for some build fixes that we should have
> in the release and I believe didn't get them out before the end of his
> day, I'm letting everyone know now to expect the release tomorrow
> instead, thanks!

Will anyone have any chance to test those fixes to verify they didn't
break anything ?

I believe this is yet another manifestation of the problems of the 2
month release cycle, which I think is too short and stressful.

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


Re: [U-Boot] [PATCH v2] fsl-lsch3: soc: Enable AHB read support for Flexspi controller

2018-11-12 Thread York Sun
On 11/2/18 8:59 AM, York Sun wrote:
> On 9/26/18 4:10 AM, Ashish Kumar wrote:
>> Enable AHB support for Flexspi controller interface meaning
>> memory can be accessed via md command using absolute addresses
>>
>> Signed-off-by: Yogesh Gaur 
>> Signed-off-by: Rajat Srivastava 
>> Signed-off-by: Ashish Kumar 
>> ---
>> v2:
>>  1. Rename FSPI to FlexSPI in description and comments
>>  2. s/cmd/command
>>  3. Add macro and comments to improve readablity of code in soc.c
>>  4. Add declaration in soc.h for fspi_ahb_init()
>>
>>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 10 +
>>  arch/arm/cpu/armv8/fsl-layerscape/soc.c   | 44 +++
>>  .../arm/include/asm/arch-fsl-layerscape/soc.h |  7 +++
>>  3 files changed, 61 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
>> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>> index 5280d33ec8..70f26973e9 100644
>> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>> @@ -327,6 +327,16 @@ config SYS_FSPI_AHB_INIT
>>performed. Default LUT programmed in AHB mode is Fast Read command
>>with 4-byte addressing enabled.
> 
> SYS_FSPI_AHB_INIT doesn't exist yet.
> 
>>  
>> +config FSPI_AHB_EN_4BYTE
>> +bool "Enable 4-byte Fast Read command for AHB mode"
>> +depends on NXP_FSPI
>> +default n
>> +help
>> +  The default setting for FlexSPI AHB bus just supports 3-byte 
>> addressing.
>> +  But some FlexSPI flash sizes are up to 64MBytes.
>> +  This flag enables fast read command for AHB mode and modifies required
>> +  LUT to support full FlexSPI flash.
>> +
> 
> NXP_FSPI doesn't exist yet.
> 
> Do you have dependency I missed?
> 

Please fix your patch asap.

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


Re: [U-Boot] [PULL] Please pull u-boot-imx: u-boot-imx-20181112

2018-11-12 Thread Tom Rini
On Mon, Nov 12, 2018 at 01:03:12PM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> still a couple of fixes (colibri_vf could not be built):
> 
> The following changes since commit c5bbfaf05dc8592b479a44df6abaadbab54fec2b:
> 
>   imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO (2018-11-07 12:13:45 -0500)
> 
> are available in the Git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20181112
> 
> for you to fetch changes up to 43e6f94cbcaf193aeedcf86e85a3ff4c79f66773:
> 
>   imx: mkimage: add size check to the u-boot.imx make target (2018-11-12
> 11:08:53 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


[U-Boot] [ANN] U-Boot v2018.11 delayed a day

2018-11-12 Thread Tom Rini
Hey all,

Since Jagan promise a v2 SPI PR for some build fixes that we should have
in the release and I believe didn't get them out before the end of his
day, I'm letting everyone know now to expect the release tomorrow
instead, thanks!

-- 
Tom


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


[U-Boot] [PATCH 3/4] fs: prevent overwriting reserved memory

2018-11-12 Thread Simon Goldschmidt
This fixes CVE-2018-18440 ("insufficient boundary checks in filesystem
image load") by using lmb to check the load size of a file against
reserved memory addresses.

Signed-off-by: Simon Goldschmidt 
---

 fs/fs.c   | 56 ---
 include/lmb.h |  2 ++
 lib/lmb.c | 13 
 3 files changed, 68 insertions(+), 3 deletions(-)

diff --git a/fs/fs.c b/fs/fs.c
index adae98d021..4baf6b1c39 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -428,13 +428,57 @@ int fs_size(const char *filename, loff_t *size)
return ret;
 }
 
-int fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
-   loff_t *actread)
+#ifdef CONFIG_LMB
+/* Check if a file may be read to the given address */
+static int fs_read_lmb_check(const char *filename, ulong addr, loff_t offset,
+loff_t len, struct fstype_info *info)
+{
+   struct lmb lmb;
+   int ret;
+   loff_t size;
+   loff_t read_len;
+
+   /* get the actual size of the file */
+   ret = info->size(filename, );
+   if (ret)
+   return ret;
+   if (offset >= size) {
+   /* offset >= EOF, no bytes will be written */
+   return 0;
+   }
+   read_len = size - offset;
+
+   /* limit to 'len' if it is smaller */
+   if (len && len < read_len)
+   read_len = len;
+
+   lmb_init_and_reserve(, gd->bd->bi_dram[0].start,
+gd->bd->bi_dram[0].size, (void *)gd->fdt_blob);
+   lmb_dump_all();
+
+   if (lmb_alloc_addr(, addr, read_len) == addr)
+   return 0;
+
+   printf("** Reading file would overwrite reserved memory **\n");
+   return -1;
+}
+#endif
+
+static int _fs_read(const char *filename, ulong addr, loff_t offset, loff_t 
len,
+   int do_lmb_check, loff_t *actread)
 {
struct fstype_info *info = fs_get_info(fs_type);
void *buf;
int ret;
 
+#ifdef CONFIG_LMB
+   if (do_lmb_check) {
+   ret = fs_read_lmb_check(filename, addr, offset, len, info);
+   if (ret)
+   return ret;
+   }
+#endif
+
/*
 * We don't actually know how many bytes are being read, since len==0
 * means read the whole file.
@@ -451,6 +495,12 @@ int fs_read(const char *filename, ulong addr, loff_t 
offset, loff_t len,
return ret;
 }
 
+int fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
+   loff_t *actread)
+{
+   return _fs_read(filename, addr, offset, len, 0, actread);
+}
+
 int fs_write(const char *filename, ulong addr, loff_t offset, loff_t len,
 loff_t *actwrite)
 {
@@ -621,7 +671,7 @@ int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[],
pos = 0;
 
time = get_timer(0);
-   ret = fs_read(filename, addr, pos, bytes, _read);
+   ret = _fs_read(filename, addr, pos, bytes, 1, _read);
time = get_timer(time);
if (ret < 0)
return 1;
diff --git a/include/lmb.h b/include/lmb.h
index bc06f175e1..810a37d5a5 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -31,6 +31,8 @@ struct lmb {
 extern struct lmb lmb;
 
 extern void lmb_init(struct lmb *lmb);
+extern void lmb_init_and_reserve(struct lmb *lmb, phys_addr_t base,
+phys_size_t size, void *fdt_blob);
 extern long lmb_add(struct lmb *lmb, phys_addr_t base, phys_size_t size);
 extern long lmb_reserve(struct lmb *lmb, phys_addr_t base, phys_size_t size);
 extern phys_addr_t lmb_alloc(struct lmb *lmb, phys_size_t size, ulong align);
diff --git a/lib/lmb.c b/lib/lmb.c
index c3af2fd5fc..99a4aaa09e 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -104,6 +104,19 @@ void lmb_init(struct lmb *lmb)
lmb->reserved.size = 0;
 }
 
+/* Initialize the struct, add memory and call arch/board reserve functions */
+void lmb_init_and_reserve(struct lmb *lmb, phys_addr_t base, phys_size_t size,
+ void *fdt_blob)
+{
+   lmb_init(lmb);
+   lmb_add(lmb, base, size);
+   arch_lmb_reserve(lmb);
+   board_lmb_reserve(lmb);
+
+   if (IMAGE_ENABLE_OF_LIBFDT)
+   boot_fdt_add_mem_rsv_regions(lmb, fdt_blob);
+}
+
 /* This routine called with relocation disabled. */
 static long lmb_add_region(struct lmb_region *rgn, phys_addr_t base, 
phys_size_t size)
 {
-- 
2.17.1

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


[U-Boot] [PATCH 4/4] bootm: use new common function lmb_init_and_reserve

2018-11-12 Thread Simon Goldschmidt
This reduces duplicate code only.

Signed-off-by: Simon Goldschmidt 
---

 common/bootm.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/common/bootm.c b/common/bootm.c
index 8bf84ebcb7..31e4f0f794 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -56,15 +56,11 @@ static void boot_start_lmb(bootm_headers_t *images)
ulong   mem_start;
phys_size_t mem_size;
 
-   lmb_init(>lmb);
-
mem_start = env_get_bootm_low();
mem_size = env_get_bootm_size();
 
-   lmb_add(>lmb, (phys_addr_t)mem_start, mem_size);
-
-   arch_lmb_reserve(>lmb);
-   board_lmb_reserve(>lmb);
+   lmb_init_and_reserve(>lmb, (phys_addr_t)mem_start, mem_size,
+NULL);
 }
 #else
 #define lmb_reserve(lmb, base, size)
-- 
2.17.1

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


[U-Boot] [PATCH 2/4] lib: lmb: add function lmb_alloc_addr

2018-11-12 Thread Simon Goldschmidt
This new function behaves like lmb_alloc, but it tries to allocate a
pre-specified address range. Unlike lmb_reserve, this address range
must be inside one of the memory ranges that has been set up with
lmb_add.

Signed-off-by: Simon Goldschmidt 
---

 include/lmb.h |  1 +
 lib/lmb.c | 26 ++
 2 files changed, 27 insertions(+)

diff --git a/include/lmb.h b/include/lmb.h
index f04d058093..bc06f175e1 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -38,6 +38,7 @@ extern phys_addr_t lmb_alloc_base(struct lmb *lmb, 
phys_size_t size, ulong align
phys_addr_t max_addr);
 extern phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong 
align,
  phys_addr_t max_addr);
+extern phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base, 
phys_size_t size);
 extern int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr);
 extern long lmb_free(struct lmb *lmb, phys_addr_t base, phys_size_t size);
 
diff --git a/lib/lmb.c b/lib/lmb.c
index 8dc703d996..c3af2fd5fc 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -324,6 +324,32 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t 
size, ulong align, phy
return 0;
 }
 
+/*
+ * Try to allocate a specific address range: must be in defined memory but not
+ * reserved
+ */
+phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base, phys_size_t size)
+{
+   long j;
+
+   /* Check if the requested address is in one of the memory regions */
+   j = lmb_overlaps_region(>memory, base, size);
+   if (j >= 0) {
+   /*
+* Check if the requested end address is in the same memory
+* region we found.
+*/
+   if (lmb_addrs_overlap(lmb->memory.region[j].base,
+ lmb->memory.region[j].size, base + size -
+ 1, 1)) {
+   /* ok, reserve the memory */
+   if (!lmb_reserve(lmb, base, size))
+   return base;
+   }
+   }
+   return 0;
+}
+
 int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
 {
int i;
-- 
2.17.1

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


[U-Boot] [PATCH 1/4] lib: lmb: reserving overlapping regions should fail

2018-11-12 Thread Simon Goldschmidt
lmb_add_region handles overlapping regions wrong: instead of merging
or rejecting to add a new reserved region that overlaps an existing
one, it just adds the new region.

Since internally the same function is used for lmb_alloc, change
lmb_add_region to reject overlapping regions.

Signed-off-by: Simon Goldschmidt 
---

 lib/lmb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/lmb.c b/lib/lmb.c
index 1705417348..8dc703d996 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -136,6 +136,9 @@ static long lmb_add_region(struct lmb_region *rgn, 
phys_addr_t base, phys_size_t
rgn->region[i].size += size;
coalesced++;
break;
+   } else if (lmb_addrs_overlap(base, size, rgnbase, rgnsize)) {
+   /* regions overlap */
+   return -1;
}
}
 
-- 
2.17.1

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


[U-Boot] [PATCH 0/4] Fix CVE-2018-18440

2018-11-12 Thread Simon Goldschmidt
This series fixes CVE-2018-18440 ("insufficient boundary checks in
filesystem image load") by adding restrictions to the 'load'
command. The functions from lmb.c are used to setup regions of
allowed and reserved memory. Then, the file size to load is checked
against these addresses and loading the file is aborted if it would
overwrite reserved memory.

The memory reservation code is reused from bootm/image.

Note that this doesn't yet fix CVE-2018-18439 ("insufficient
boundary checks in network image boot"), which is somewhat similar.

Note that patman warnings are in old code only or due to adopting
the file's coding style.

Simon Goldschmidt (4):
  lib: lmb: reserving overlapping regions should fail
  lib: lmb: add function lmb_alloc_addr
  fs: prevent overwriting reserved memory
  bootm: use new common function lmb_init_and_reserve

 common/bootm.c |  8 ++--
 fs/fs.c| 56 +++---
 include/lmb.h  |  3 +++
 lib/lmb.c  | 42 +
 4 files changed, 100 insertions(+), 9 deletions(-)

-- 
2.17.1

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


[U-Boot] [PATCH v2 1/1] efi_selftest: don't hang on missing timer

2018-11-12 Thread Heinrich Schuchardt
qemu-riscv32_defconfig and qemu-riscv64_defconfig do not supply a timer.
This causes the EFI selftest to hang on tests which require a timer.

So let's disable CONFIG_TIMER for these boards and use this variable to
decide which tests have to be disabled.

Signed-off-by: Heinrich Schuchardt 
---
v2:
add missing obj-y += \
---
 configs/qemu-riscv32_defconfig |  1 +
 configs/qemu-riscv64_defconfig |  1 +
 lib/efi_selftest/Makefile  | 10 +++---
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
index ff1fb1f30ec..70da323bdc1 100644
--- a/configs/qemu-riscv32_defconfig
+++ b/configs/qemu-riscv32_defconfig
@@ -3,4 +3,5 @@ CONFIG_TARGET_QEMU_VIRT=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
+# CONFIG_TIMER is not set
 CONFIG_OF_BOARD=y
diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
index d6c1a5d646a..258f395b9d5 100644
--- a/configs/qemu-riscv64_defconfig
+++ b/configs/qemu-riscv64_defconfig
@@ -4,4 +4,5 @@ CONFIG_CPU_RISCV_64=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
+# CONFIG_TIMER is not set
 CONFIG_OF_BOARD=y
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 4b1c0bb84b1..aec498fbcf2 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -19,7 +19,6 @@ efi_selftest_console.o \
 efi_selftest_crc32.o \
 efi_selftest_devicepath.o \
 efi_selftest_devicepath_util.o \
-efi_selftest_events.o \
 efi_selftest_event_groups.o \
 efi_selftest_exception.o \
 efi_selftest_exitbootservices.o \
@@ -32,11 +31,16 @@ efi_selftest_snp.o \
 efi_selftest_textinput.o \
 efi_selftest_textinputex.o \
 efi_selftest_textoutput.o \
-efi_selftest_tpl.o \
 efi_selftest_unicode_collation.o \
 efi_selftest_util.o \
-efi_selftest_variables.o \
+efi_selftest_variables.o
+
+ifeq ($(CONFIG_TIMER),)
+obj-y += \
+efi_selftest_events.o \
+efi_selftest_tpl.o \
 efi_selftest_watchdog.o
+endif
 
 obj-$(CONFIG_CPU_V7) += efi_selftest_unaligned.o
 
-- 
2.19.1

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


[U-Boot] [PATCH 1/1] efi_selftest: don't hang on missing timer

2018-11-12 Thread Heinrich Schuchardt
qemu-riscv32_defconfig and qemu-riscv64_defconfig do not supply a timer.
This causes the EFI selftest to hang on tests which require a timer.

So let's disable CONFIG_TIMER for these boards and use this variable to
decide which tests have to be disabled.

Signed-off-by: Heinrich Schuchardt 
---
 configs/qemu-riscv32_defconfig | 1 +
 configs/qemu-riscv64_defconfig | 1 +
 lib/efi_selftest/Makefile  | 9 ++---
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
index ff1fb1f30ec..70da323bdc1 100644
--- a/configs/qemu-riscv32_defconfig
+++ b/configs/qemu-riscv32_defconfig
@@ -3,4 +3,5 @@ CONFIG_TARGET_QEMU_VIRT=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
+# CONFIG_TIMER is not set
 CONFIG_OF_BOARD=y
diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
index d6c1a5d646a..258f395b9d5 100644
--- a/configs/qemu-riscv64_defconfig
+++ b/configs/qemu-riscv64_defconfig
@@ -4,4 +4,5 @@ CONFIG_CPU_RISCV_64=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
+# CONFIG_TIMER is not set
 CONFIG_OF_BOARD=y
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 743b4820449..8f2f09522e6 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -19,7 +19,6 @@ efi_selftest_console.o \
 efi_selftest_crc32.o \
 efi_selftest_devicepath.o \
 efi_selftest_devicepath_util.o \
-efi_selftest_events.o \
 efi_selftest_event_groups.o \
 efi_selftest_exception.o \
 efi_selftest_exitbootservices.o \
@@ -33,11 +32,15 @@ efi_selftest_snp.o \
 efi_selftest_textinput.o \
 efi_selftest_textinputex.o \
 efi_selftest_textoutput.o \
-efi_selftest_tpl.o \
 efi_selftest_unicode_collation.o \
 efi_selftest_util.o \
-efi_selftest_variables.o \
+efi_selftest_variables.o
+
+ifeq ($(CONFIG_TIMER),)
+efi_selftest_events.o \
+efi_selftest_tpl.o \
 efi_selftest_watchdog.o
+endif
 
 obj-$(CONFIG_CPU_V7) += efi_selftest_unaligned.o
 
-- 
2.19.1

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


Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities

2018-11-12 Thread Simon Goldschmidt

On 12.11.2018 19:03, Heinrich Schuchardt wrote:

On 11/12/18 7:56 AM, Simon Goldschmidt wrote:

On Mon, Nov 12, 2018 at 12:22 AM Heinrich Schuchardt  wrote:

On 11/11/18 3:22 PM, Wolfgang Denk wrote:

Dear Andrea,

In message <20181109094615.gc9...@lambda.inversepath.com> you wrote:

Exactly, merely checking RAM size is not sufficient. The specific memory
layout would need to be accounted for which means understanding where the
stack and heap are located, their direction of growth and to ensure that the
loaded payload can never overwrite them along with all other U-Boot data
segments.

This is pretty easy.  On all architectures I'm aware of the stack
has the lowest location in memory, and is growing downward.


This is not easy given that the stack and heap size I think can only be
guessed and not precisely limited, additionally board configurations have the
ability to set arbitrary stack, relocation and load addresses which
complicates things even further in understanding exactly how the memory
layout is set.

I think this is not that complicated.  At least in standard U-Boot
(not speaking for SPL) it should be sufficient to check the current
stack pointer (which is easy to read) and take this a upper limit of
available/allowed memory. If we add some reasonable safety margin
(say, 1 MB or so) we should be really safe.

Unfortunately this does not hold true. E.g. the Odroid-C2 has the secure
monitor in the middle of the RAM. You would not want to overwrite those
addresses.

For a board with a device tree all reserved memory areas should be
secured against overwriting.

That's why I proposed to use the already existing memory reservation
scheme 'lmb' (used in loading boot images).

In your case, 'board_lmb_reserve' should make sure the secure monitor
does not get overwritten.
The 'arch_lmb_reserve' function for arm already ensures U-Boot text,
heap and stack don't get overwritten. It could be improved to reserve
+1M to the current stack pointer where it does reserve +4K now.

If board_lmb_reserve() should be the solution I would prefer that not
each individual board calls board_lmb_reserve() but that some common
code is used to iterate over the memory reservations in the device tree.


I know that the efi loader has its own scheme of memory reservation. I 
just thought it cleaner to stay with lmb for fs_load and tftp as lmb is 
already used in image loading/booting.


But using the memory reservations from U-Boot device tree definitively 
makes sense, thanks for the hint. This should probably be done for the 
bootm code, too...


Simon



Cheers

Heinrich


I am working on a patch for the 'load' issue (which could be reused
for the tftp issue). There are some problems with the existing lmb
code though, which delayed me a bit. However, given that this doesn't
make it into the 2018.11 release, anyway, I figured some more days to
get it cleaner won't hurt...

Simon


Best regards

Heinrich


Additionally, your patch checks the loaded file's size without taking
the load address into account. So unless I read that wrong, your check
is only valid for 'addr == 0'.

The approach is also not appliccable to networ boot; with TFTP we
don't know the image size in advance.

Eventyally the boundary checking should be done where the image
content actually gets copied to memory.

Best regards,

Wolfgang Denk


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



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


Re: [U-Boot] [PATCH] qemu-arm: Enable VirtIO distro target

2018-11-12 Thread Tuomas Tynkkynen
Hi Sumit,

On Mon, 12 Nov 2018 15:29:08 +0530
Sumit Garg  wrote:

> With -device virtio-blk-device,drive=hd0, it could detect distro boot
> target.
> 
> Signed-off-by: Sumit Garg 
> ---
...
> diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> index fedc466..437c3ae 100644
> --- a/include/configs/qemu-arm.h
> +++ b/include/configs/qemu-arm.h
> @@ -25,7 +25,8 @@
>  
>  #define BOOT_TARGET_DEVICES(func) \
>   func(SCSI, scsi, 0) \
> - func(DHCP, dhcp, na)
> + func(DHCP, dhcp, na) \
> + func(VIRTIO, virtio, 0)
>  
>  #include 
>  

I think typically DHCP is the very last boot option since it can take
quite long to notice if there's no DHCP server on the network and fall
back to the next option. So perhaps an order of

SCSI; VIRTIO; DHCP

would be better.

Other than that, looks fine to me.

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


Re: [U-Boot] [PATCH V2 6/6] test: vboot: add padding pss for rsa signature

2018-11-12 Thread Clément Péron
Hi Philippe,

On Mon, 12 Nov 2018 at 18:41, Philippe REYNES
 wrote:
>
> Hi Clément,
>
> You're right, those its are in an old-format style.
> I can add a patch in this serie or send a separate
> patch to clean the style.
>
> What solution do you prefer ?
I'm not a maintainer but in this case I would have send a V3 if it's
not merged or send a separate patch if it's already merged.

If you send a V3, don't forget to add the "Reviewed-by" tags.

Regards,
Clement

>
> Regards,
> Philippe
>
>
> - Mail original -
> De: "Clément Péron" 
> À: s...@chromium.org
> Cc: "philippe reynes" , "michal simek" 
> , "joe hershberger" , "Marek 
> Vasut" , "yamada masahiro" , 
> aford...@gmail.com, "woods technical" , "teddy 
> reed" , "jun nie" , "peng fan" 
> , "keguang zhang" , "andre 
> przywara" , "philipp tomsich" 
> , "bin chen" , 
> j...@jsg.id.au, nom...@palism.com, swar...@nvidia.com, "paul burton" 
> , "alex kiernan" , "u-boot" 
> 
> Envoyé: Samedi 3 Novembre 2018 18:11:57
> Objet: Re: [PATCH V2 6/6] test: vboot: add padding pss for rsa signature
>
> Hi,
>
> I'm not an expert but regarding commit
> b8790ebeec13c882979dc986947397738d9f38aa I think you should drop the
> unit-address in its files.
>
> "The DT spec demands a unit-address of a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Fix all occurences in the FIT image example files where this was not
> observed, to not give bad examples to the reader.
> "
>
> Regards,
> Clement
>
> On Sat, 3 Nov 2018 at 07:08, Simon Glass  wrote:
> >
> > On 25 October 2018 at 03:29, Philippe Reynes
> >  wrote:
> > > The padding pss is now supported for rsa signature.
> > > This add test with padding pss on vboot test.
> > >
> > > Signed-off-by: Philippe Reynes 
> > > ---
> > >  test/py/tests/test_vboot.py | 10 +++---
> > >  test/py/tests/vboot/sign-configs-sha1-pss.its   | 46 
> > > +
> > >  test/py/tests/vboot/sign-configs-sha256-pss.its | 46 
> > > +
> > >  test/py/tests/vboot/sign-images-sha1-pss.its| 44 
> > > +++
> > >  test/py/tests/vboot/sign-images-sha256-pss.its  | 44 
> > > +++
> > >  5 files changed, 186 insertions(+), 4 deletions(-)
> > >  create mode 100644 test/py/tests/vboot/sign-configs-sha1-pss.its
> > >  create mode 100644 test/py/tests/vboot/sign-configs-sha256-pss.its
> > >  create mode 100644 test/py/tests/vboot/sign-images-sha1-pss.its
> > >  create mode 100644 test/py/tests/vboot/sign-images-sha256-pss.its
> > >
> > > Changelog:
> > > v2:
> > > - new patch in the serie
> > > - add vboot for pss padding (thanks Simon Glass)
> >
> > Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2] ARM: Samsung: Add Exynos5422-based Odroid HC2 support

2018-11-12 Thread Dirk Meul
Hi Anand Moon,

with U-Boot 2018.11-rc3-00062-g26cc40d8c4 and booting Fedora 28 Server
I have no problems with a *warm boot* of my Odroid HC2. So I think this
is not a general problem.

My u-boot.bin was created using:
$ ARCH=arm CROSS_COMPILE=arm-linux-gnu- make odroid-xu3_defconfig
$ ARCH=arm CROSS_COMPILE=arm-linux-gnu- make -j $(nproc)
on Fedora 28 Workstation.

BR,
Dirk

Am Montag, den 12.11.2018, 13:06 +0530 schrieb Anand Moon:
> Hi Dirk Meul
> 
> On Tue, 23 Oct 2018 at 16:08, Dirk Meul 
> wrote:
> > 
> > From: Dirk Meul 
> > Date: Sun, 14 Oct 2018 17:14:17 +0200
> > 
> > Odroid HC2 board is based on Odroid XU4 board, like the Odroid HC1.
> > 
> > The linux kernel does not provide a hc2 DTB so the hc1 DTB is also
> > used
> > for the Odroid HC2.
> > 
> > Resend because MUA changed whitespace.
> > 
> > Signed-off-by: Dirk Meul 
> > Acked-by: Marek Szyprowski 
> > Reviewed-by: Lukasz Majewski 
> > ---
> >  board/samsung/common/exynos5-dt-types.c | 16 +---
> >  board/samsung/common/exynos5-dt.c   |  4 ++--
> >  configs/odroid-xu3_defconfig|  2 +-
> >  include/samsung/exynos5-dt-types.h  |  2 ++
> >  4 files changed, 18 insertions(+), 6 deletions(-)
> > 
> > diff --git a/board/samsung/common/exynos5-dt-types.c
> > b/board/samsung/common/exynos5-dt-types.c
> > index 4473968db6..7a86e91877 100644
> > --- a/board/samsung/common/exynos5-dt-types.c
> > +++ b/board/samsung/common/exynos5-dt-types.c
> > @@ -24,14 +24,15 @@ static const struct udevice_id board_ids[] = {
> >  };
> > 
> >  /**
> > - * Odroix XU3/XU4/HC1 board revisions (from
> > HC1_MAIN_REV0.1_20170630.pdf):
> > + * Odroix XU3/XU4/HC1/HC2 board revisions (from
> > HC1+_HC2_MAIN_REV0.1_20171017.pdf):
> >   * Rev   ADCmax  Board
> >   * 0.1 0 XU3 0.1
> >   * 0.2   372 XU3 0.2 | XU3L - no DISPLAYPORT (probe I2C0:0x40
> > / INA231)
> >   * 0.3  1280 XU4 0.1
> >   * 0.4   739 XU4 0.2
> >   * 0.5  1016 XU4+Air0.1 (Passive cooling)
> > - * 0.6  1308 XU4S 0.1 (HC1)
> > + * 0.6  1309 XU4-HC1 0.1
> > + * 0.7  1470 XU4-HC1+ 0.1 (HC2)
> >   * Use +1% for ADC value tolerance in the array below, the code
> > loops until
> >   * the measured ADC value is lower than then ADCmax from the
> > array.
> >   */
> > @@ -39,7 +40,8 @@ struct odroid_rev_info odroid_info[] = {
> > { EXYNOS5_BOARD_ODROID_XU3_REV01, 1, 10, "xu3" },
> > { EXYNOS5_BOARD_ODROID_XU3_REV02, 2, 375, "xu3" },
> > { EXYNOS5_BOARD_ODROID_XU4_REV01, 1, 1293, "xu4" },
> > -   { EXYNOS5_BOARD_ODROID_HC1_REV01, 1, 1321, "hc1" },
> > +   { EXYNOS5_BOARD_ODROID_HC1_REV01, 1, 1322, "hc1" },
> > +   { EXYNOS5_BOARD_ODROID_HC2_REV01, 1, 1484, "hc1" },
> > { EXYNOS5_BOARD_ODROID_UNKNOWN, 0, 4095, "unknown" },
> >  };
> > 
> > @@ -144,6 +146,14 @@ bool board_is_odroidhc1(void)
> > return false;
> >  }
> > 
> > +bool board_is_odroidhc2(void)
> > +{
> > +   if (gd->board_type == EXYNOS5_BOARD_ODROID_HC2_REV01)
> > +   return true;
> > +
> > +   return false;
> > +}
> > +
> >  bool board_is_generic(void)
> >  {
> > if (gd->board_type == EXYNOS5_BOARD_GENERIC)
> > diff --git a/board/samsung/common/exynos5-dt.c
> > b/board/samsung/common/exynos5-dt.c
> > index 8c3a9ea564..c183965b92 100644
> > --- a/board/samsung/common/exynos5-dt.c
> > +++ b/board/samsung/common/exynos5-dt.c
> > @@ -179,7 +179,7 @@ char *get_dfu_alt_system(char *interface, char
> > *devstr)
> >  {
> > char *info = "Not supported!";
> > 
> > -   if (board_is_odroidxu4() || board_is_odroidhc1())
> > +   if (board_is_odroidxu4() || board_is_odroidhc1() ||
> > board_is_odroidhc2())
> > return info;
> > 
> > return env_get("dfu_alt_system");
> > @@ -192,7 +192,7 @@ char *get_dfu_alt_boot(char *interface, char
> > *devstr)
> > char *alt_boot;
> > int dev_num;
> > 
> > -   if (board_is_odroidxu4() || board_is_odroidhc1())
> > +   if (board_is_odroidxu4() || board_is_odroidhc1() ||
> > board_is_odroidhc2())
> > return info;
> > 
> > dev_num = simple_strtoul(devstr, NULL, 10);
> > diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-
> > xu3_defconfig
> > index 258b9781cc..d5c7cc7129 100644
> > --- a/configs/odroid-xu3_defconfig
> > +++ b/configs/odroid-xu3_defconfig
> > @@ -2,7 +2,7 @@ CONFIG_ARM=y
> >  CONFIG_ARCH_EXYNOS=y
> >  CONFIG_SYS_TEXT_BASE=0x43E0
> >  CONFIG_ARCH_EXYNOS5=y
> > -CONFIG_IDENT_STRING=" for ODROID-XU3/XU4/HC1"
> > +CONFIG_IDENT_STRING=" for ODROID-XU3/XU4/HC1/HC2"
> >  CONFIG_DISTRO_DEFAULTS=y
> >  CONFIG_NR_DRAM_BANKS=8
> >  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > diff --git a/include/samsung/exynos5-dt-types.h
> > b/include/samsung/exynos5-dt-types.h
> > index 8e11af30d1..8fe08fe211 100644
> > --- a/include/samsung/exynos5-dt-types.h
> > +++ b/include/samsung/exynos5-dt-types.h
> > @@ -9,6 +9,7 @@ enum {
> > EXYNOS5_BOARD_ODROID_XU3_REV02,
> > 

Re: [U-Boot] Rockchip RV1108 eMMC initialization fail

2018-11-12 Thread Marek Vasut
On 11/12/2018 04:25 PM, alex94 wrote:
> The log for SD card is the same like the one I posted, when using mainline
> u-boot from Denx. When using u-boot from rockchip, the log is slightly
> different, but it is the same error. I will put that log here too as soon as
> I can. 

Command 8 fails, which is the first command to which the card must
respond. Thus, something is fundamentally wrong with the communication
with the card.

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


Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities

2018-11-12 Thread Heinrich Schuchardt
On 11/12/18 7:56 AM, Simon Goldschmidt wrote:
> On Mon, Nov 12, 2018 at 12:22 AM Heinrich Schuchardt  
> wrote:
>>
>> On 11/11/18 3:22 PM, Wolfgang Denk wrote:
>>> Dear Andrea,
>>>
>>> In message <20181109094615.gc9...@lambda.inversepath.com> you wrote:

 Exactly, merely checking RAM size is not sufficient. The specific memory
 layout would need to be accounted for which means understanding where the
 stack and heap are located, their direction of growth and to ensure that 
 the
 loaded payload can never overwrite them along with all other U-Boot data
 segments.
>>>
>>> This is pretty easy.  On all architectures I'm aware of the stack
>>> has the lowest location in memory, and is growing downward.
>>>
 This is not easy given that the stack and heap size I think can only be
 guessed and not precisely limited, additionally board configurations have 
 the
 ability to set arbitrary stack, relocation and load addresses which
 complicates things even further in understanding exactly how the memory
 layout is set.
>>>
>>> I think this is not that complicated.  At least in standard U-Boot
>>> (not speaking for SPL) it should be sufficient to check the current
>>> stack pointer (which is easy to read) and take this a upper limit of
>>> available/allowed memory. If we add some reasonable safety margin
>>> (say, 1 MB or so) we should be really safe.
>>
>> Unfortunately this does not hold true. E.g. the Odroid-C2 has the secure
>> monitor in the middle of the RAM. You would not want to overwrite those
>> addresses.
>>
>> For a board with a device tree all reserved memory areas should be
>> secured against overwriting.
> 
> That's why I proposed to use the already existing memory reservation
> scheme 'lmb' (used in loading boot images).
> 
> In your case, 'board_lmb_reserve' should make sure the secure monitor
> does not get overwritten.
> The 'arch_lmb_reserve' function for arm already ensures U-Boot text,
> heap and stack don't get overwritten. It could be improved to reserve
> +1M to the current stack pointer where it does reserve +4K now.

If board_lmb_reserve() should be the solution I would prefer that not
each individual board calls board_lmb_reserve() but that some common
code is used to iterate over the memory reservations in the device tree.

Cheers

Heinrich

> 
> I am working on a patch for the 'load' issue (which could be reused
> for the tftp issue). There are some problems with the existing lmb
> code though, which delayed me a bit. However, given that this doesn't
> make it into the 2018.11 release, anyway, I figured some more days to
> get it cleaner won't hurt...
> 
> Simon
> 
>>
>> Best regards
>>
>> Heinrich
>>
>>>
> Additionally, your patch checks the loaded file's size without taking
> the load address into account. So unless I read that wrong, your check
> is only valid for 'addr == 0'.
>>>
>>> The approach is also not appliccable to networ boot; with TFTP we
>>> don't know the image size in advance.
>>>
>>> Eventyally the boundary checking should be done where the image
>>> content actually gets copied to memory.
>>>
>>> Best regards,
>>>
>>> Wolfgang Denk
>>>
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
> 

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


[U-Boot] [PATCH v2 9/9] efi_selftest: check fdt is marked as runtime data

2018-11-12 Thread Heinrich Schuchardt
Check that the memory area containing the device tree is marked as runtime
data.

Signed-off-by: Heinrich Schuchardt 
---
v2:
no change
---
 lib/efi_selftest/efi_selftest_memory.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/lib/efi_selftest/efi_selftest_memory.c 
b/lib/efi_selftest/efi_selftest_memory.c
index 0623e8e62da..24b4438ce4f 100644
--- a/lib/efi_selftest/efi_selftest_memory.c
+++ b/lib/efi_selftest/efi_selftest_memory.c
@@ -6,13 +6,17 @@
  *
  * This unit test checks the following runtime services:
  * AllocatePages, FreePages, GetMemoryMap
+ *
+ * The memory type used for the device tree is checked.
  */
 
 #include 
 
 #define EFI_ST_NUM_PAGES 8
 
+static const efi_guid_t fdt_guid = EFI_FDT_GUID;
 static struct efi_boot_services *boottime;
+static u64 fdt_addr;
 
 /**
  * setup() - setup unit test
@@ -24,8 +28,20 @@ static struct efi_boot_services *boottime;
 static int setup(const efi_handle_t handle,
 const struct efi_system_table *systable)
 {
+   size_t i;
+
boottime = systable->boottime;
 
+   for (i = 0; i < systable->nr_tables; ++i) {
+   if (!efi_st_memcmp(>tables[i].guid, _guid,
+  sizeof(efi_guid_t))) {
+   if (fdt_addr) {
+   efi_st_error("Duplicate device tree\n");
+   return EFI_ST_FAILURE;
+   }
+   fdt_addr = (uintptr_t)systable->tables[i].table;
+   }
+   }
return EFI_ST_SUCCESS;
 }
 
@@ -152,6 +168,14 @@ static int execute(void)
return EFI_ST_FAILURE;
}
 
+   /* Check memory reservation for the device tree */
+   if (fdt_addr &&
+   find_in_memory_map(map_size, memory_map, desc_size, fdt_addr,
+  EFI_RUNTIME_SERVICES_DATA) != EFI_ST_SUCCESS) {
+   efi_st_error
+   ("Device tree not marked as runtime services data\n");
+   return EFI_ST_FAILURE;
+   }
return EFI_ST_SUCCESS;
 }
 
-- 
2.19.1

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


[U-Boot] [PATCH v2 7/9] efi_loader: fix memory mapping for sandbox

2018-11-12 Thread Heinrich Schuchardt
The sandbox is using a virtual address space. The addresses used insided
the flattened device tree use the virtual address space. The EFI subsystem
uses the addressable address space and this is where the fdt is stored.

Fix all incorrect addresses for the fdt.

Signed-off-by: Heinrich Schuchardt 
---
v2:
use copy of fdt not the original fdt
---
 cmd/bootefi.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 2c9b2eb8b6f..50253ea1859 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -185,12 +185,16 @@ static efi_status_t copy_fdt(ulong *fdt_addrp)
 * Give us at least 12 KiB of breathing room in case the device tree
 * needs to be expanded later.
 */
-   fdt = map_sysmem(*fdt_addrp, 0);
+   fdt = (void *)*fdt_addrp;
fdt_pages = efi_size_in_pages(fdt_totalsize(fdt) + 0x3000);
fdt_size = fdt_pages << EFI_PAGE_SHIFT;
 
-   /* Safe fdt location is at 127MB */
-   new_fdt_addr = fdt_ram_start + (127 * 1024 * 1024) + fdt_size;
+   /*
+* Safe fdt location is at 127 MiB. On the sandbox convert from the
+* virtual address space.
+*/
+   new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
+fdt_size, 0);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
 EFI_RUNTIME_SERVICES_DATA, fdt_pages,
 _fdt_addr);
@@ -205,8 +209,7 @@ static efi_status_t copy_fdt(ulong *fdt_addrp)
goto done;
}
}
-
-   new_fdt = map_sysmem(new_fdt_addr, fdt_size);
+   new_fdt = (void *)(uintptr_t)new_fdt_addr;
memcpy(new_fdt, fdt, fdt_totalsize(fdt));
fdt_set_totalsize(new_fdt, fdt_size);
 
@@ -278,6 +281,9 @@ static void efi_carve_out_dt_rsv(void *fdt)
if (fdt_get_mem_rsv(fdt, i, , ) != 0)
continue;
 
+   /* Convert from sandbox address space. */
+   addr = (uintptr_t)map_sysmem(addr, 0);
+
/*
 * Do not carve out the device tree. It is already marked as
 * EFI_RUNTIME_SERVICES_DATA
@@ -297,9 +303,8 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
 {
bootm_headers_t img = { 0 };
efi_status_t ret;
-   void *fdt;
+   void *fdt = (void *)fdt_addr;
 
-   fdt = map_sysmem(fdt_addr, 0);
if (fdt_check_header(fdt)) {
printf("ERROR: invalid device tree\n");
return EFI_INVALID_PARAMETER;
@@ -309,9 +314,8 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
ret = copy_fdt(_addr);
if (ret)
return ret;
+   fdt = (void *)fdt_addr;
 
-   unmap_sysmem(fdt);
-   fdt = map_sysmem(fdt_addr, 0);
if (image_setup_libfdt(, fdt, 0, NULL)) {
printf("ERROR: failed to process device tree\n");
return EFI_LOAD_ERROR;
-- 
2.19.1

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


[U-Boot] [PATCH v2 6/9] efi_loader: macro efi_size_in_pages()

2018-11-12 Thread Heinrich Schuchardt
When allocating EFI memory pages the size in bytes has to be converted to
pages.

Provide a macro efi_size_in_pages() for this conversion.
Use it in the EFI subsystem and correct related comments.

Signed-off-by: Heinrich Schuchardt 
---
v2:
no change
---
 cmd/bootefi.c   | 15 ++-
 include/efi_loader.h| 11 ++-
 lib/efi_loader/efi_memory.c |  6 +++---
 3 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index c73e6228d3e..2c9b2eb8b6f 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -154,7 +154,7 @@ static void set_load_options(struct efi_loaded_image 
*loaded_image_info,
  * copy_fdt() - Copy the device tree to a new location available to EFI
  *
  * The FDT is relocated into a suitable location within the EFI memory map.
- * An additional 12KB is added to the space in case the device tree needs to be
+ * Additional 12 KiB are added to the space in case the device tree needs to be
  * expanded later with fdt_open_into().
  *
  * @fdt_addr:  On entry, address of start of FDT. On exit, address of relocated
@@ -182,14 +182,12 @@ static efi_status_t copy_fdt(ulong *fdt_addrp)
}
 
/*
-* Give us at least 4KB of breathing room in case the device tree needs
-* to be expanded later. Round up to the nearest EFI page boundary.
+* Give us at least 12 KiB of breathing room in case the device tree
+* needs to be expanded later.
 */
fdt = map_sysmem(*fdt_addrp, 0);
-   fdt_size = fdt_totalsize(fdt);
-   fdt_size += 4096 * 3;
-   fdt_size = ALIGN(fdt_size + EFI_PAGE_SIZE - 1, EFI_PAGE_SIZE);
-   fdt_pages = fdt_size >> EFI_PAGE_SHIFT;
+   fdt_pages = efi_size_in_pages(fdt_totalsize(fdt) + 0x3000);
+   fdt_size = fdt_pages << EFI_PAGE_SHIFT;
 
/* Safe fdt location is at 127MB */
new_fdt_addr = fdt_ram_start + (127 * 1024 * 1024) + fdt_size;
@@ -287,8 +285,7 @@ static void efi_carve_out_dt_rsv(void *fdt)
if (addr == (uintptr_t)fdt)
continue;
 
-   pages = ALIGN(size + (addr & EFI_PAGE_MASK), EFI_PAGE_SIZE) >>
-   EFI_PAGE_SHIFT;
+   pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
addr &= ~EFI_PAGE_MASK;
if (!efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
false))
diff --git a/include/efi_loader.h b/include/efi_loader.h
index bdb806cfce4..244e754e8fd 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -350,7 +350,16 @@ struct efi_simple_file_system_protocol 
*efi_simple_file_system(
 /* open file from device-path: */
 struct efi_file_handle *efi_file_from_path(struct efi_device_path *fp);
 
-
+/**
+ * efi_size_in_pages() - convert size in bytes to size in pages
+ *
+ * This macro returns the number of EFI memory pages required to hold 'size'
+ * bytes.
+ *
+ * @size:  size in bytes
+ * Return: size in pages
+ */
+#define efi_size_in_pages(size) ((size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT)
 /* Generic EFI memory allocator, call this to get memory */
 void *efi_alloc(uint64_t len, int memory_type);
 /* More specific EFI memory allocator, called by EFI payloads */
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 490e4921cce..5c387fa8024 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -400,7 +400,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
 void *efi_alloc(uint64_t len, int memory_type)
 {
uint64_t ret = 0;
-   uint64_t pages = (len + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
+   uint64_t pages = efi_size_in_pages(len);
efi_status_t r;
 
r = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES, memory_type, pages,
@@ -444,8 +444,8 @@ efi_status_t efi_allocate_pool(int pool_type, efi_uintn_t 
size, void **buffer)
 {
efi_status_t r;
struct efi_pool_allocation *alloc;
-   u64 num_pages = (size + sizeof(struct efi_pool_allocation) +
-EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
+   u64 num_pages = efi_size_in_pages(size +
+ sizeof(struct efi_pool_allocation));
 
if (!buffer)
return EFI_INVALID_PARAMETER;
-- 
2.19.1

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


[U-Boot] [PATCH v2 8/9] efi_loader: do not use magic address for fdt

2018-11-12 Thread Heinrich Schuchardt
We currently place the flattened device tree 127 MiB from the start of the
first memory bank. This may be in a reserved memory area.

So let's change the sequence: first create memory reservations and then
copy the device tree.

Do not use any magic address.

Signed-off-by: Heinrich Schuchardt 
---
v2:
Remove code handling memory reservation for the fdt.
---
 cmd/bootefi.c | 32 +++-
 1 file changed, 7 insertions(+), 25 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 50253ea1859..251d8403bcc 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -189,32 +189,20 @@ static efi_status_t copy_fdt(ulong *fdt_addrp)
fdt_pages = efi_size_in_pages(fdt_totalsize(fdt) + 0x3000);
fdt_size = fdt_pages << EFI_PAGE_SHIFT;
 
-   /*
-* Safe fdt location is at 127 MiB. On the sandbox convert from the
-* virtual address space.
-*/
-   new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
-fdt_size, 0);
+   new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
 EFI_RUNTIME_SERVICES_DATA, fdt_pages,
 _fdt_addr);
if (ret != EFI_SUCCESS) {
-   /* If we can't put it there, put it somewhere */
-   new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
-   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, fdt_pages,
-_fdt_addr);
-   if (ret != EFI_SUCCESS) {
-   printf("ERROR: Failed to reserve space for FDT\n");
-   goto done;
-   }
+   printf("ERROR: Failed to allocate memory for FDT\n");
+   return ret;
}
new_fdt = (void *)(uintptr_t)new_fdt_addr;
memcpy(new_fdt, fdt, fdt_totalsize(fdt));
fdt_set_totalsize(new_fdt, fdt_size);
 
*fdt_addrp = new_fdt_addr;
-done:
+
return ret;
 }
 
@@ -284,13 +272,6 @@ static void efi_carve_out_dt_rsv(void *fdt)
/* Convert from sandbox address space. */
addr = (uintptr_t)map_sysmem(addr, 0);
 
-   /*
-* Do not carve out the device tree. It is already marked as
-* EFI_RUNTIME_SERVICES_DATA
-*/
-   if (addr == (uintptr_t)fdt)
-   continue;
-
pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
addr &= ~EFI_PAGE_MASK;
if (!efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
@@ -310,6 +291,9 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
return EFI_INVALID_PARAMETER;
}
 
+   /* Create memory reservation as indicated by the device tree */
+   efi_carve_out_dt_rsv(fdt);
+
/* Prepare fdt for payload */
ret = copy_fdt(_addr);
if (ret)
@@ -321,8 +305,6 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
return EFI_LOAD_ERROR;
}
 
-   efi_carve_out_dt_rsv(fdt);
-
/* Link to it in the efi tables */
ret = efi_install_configuration_table(_guid_fdt, fdt);
if (ret != EFI_SUCCESS)
-- 
2.19.1

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


[U-Boot] [PATCH v2 2/9] efi_loader: fix efi_find_free_memory()

2018-11-12 Thread Heinrich Schuchardt
In efi_find_free_memory() the sandbox uses its virtual address space.
Add the missing mapping.

Signed-off-by: Heinrich Schuchardt 
---
v2:
no change
---
 lib/efi_loader/efi_memory.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index dc282fe249f..c0277355056 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -294,6 +294,9 @@ static uint64_t efi_find_free_memory(uint64_t len, uint64_t 
max_addr)
 {
struct list_head *lhandle;
 
+   /* Map to virtual address on sandbox */
+   max_addr = map_to_sysmem((void *)(uintptr_t)max_addr);
+
/*
 * Prealign input max address, so we simplify our matching
 * logic below and can just reuse it as return pointer.
-- 
2.19.1

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


[U-Boot] [PATCH v2 3/9] efi_loader: memory reservation for fdt

2018-11-12 Thread Heinrich Schuchardt
In copy_fdt() we allocate EFI pages for the fdt plus extra 12 KiB as
EFI_RUNTIME_SERVICES_DATA. Afterwards in efi_install_fdt() we overwrite
part of this memory allocation by marking it as EFI_BOOT_SERVICES_DATA.

Remove the code marking the fdt as EFI_BOOT_SERVICES_DATA.

Cf. commit 17ff6f02f5ad ("efi_loader: store DT in EFI_RUNTIME_SERVICES_DATA
memory")

Signed-off-by: Heinrich Schuchardt 
---
v2:
change
---
 cmd/bootefi.c | 21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index e16ed4adba9..f2950817a13 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -157,12 +157,11 @@ static void set_load_options(struct efi_loaded_image 
*loaded_image_info,
  * An additional 12KB is added to the space in case the device tree needs to be
  * expanded later with fdt_open_into().
  *
- * @fdt_addr: On entry, address of start of FDT. On exit, address of relocated
- * FDT start
- * @fdt_sizep: Returns new size of FDT, including
- * @return new relocated address of FDT
+ * @fdt_addr:  On entry, address of start of FDT. On exit, address of relocated
+ * FDT start
+ * Return: status code
  */
-static efi_status_t copy_fdt(ulong *fdt_addrp, ulong *fdt_sizep)
+static efi_status_t copy_fdt(ulong *fdt_addrp)
 {
unsigned long fdt_ram_start = -1L, fdt_pages;
efi_status_t ret = 0;
@@ -214,7 +213,6 @@ static efi_status_t copy_fdt(ulong *fdt_addrp, ulong 
*fdt_sizep)
fdt_set_totalsize(new_fdt, fdt_size);
 
*fdt_addrp = new_fdt_addr;
-   *fdt_sizep = fdt_size;
 done:
return ret;
 }
@@ -292,7 +290,6 @@ static void efi_carve_out_dt_rsv(void *fdt)
 static efi_status_t efi_install_fdt(ulong fdt_addr)
 {
bootm_headers_t img = { 0 };
-   ulong fdt_pages, fdt_size, fdt_start;
efi_status_t ret;
void *fdt;
 
@@ -303,13 +300,12 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
}
 
/* Prepare fdt for payload */
-   ret = copy_fdt(_addr, _size);
+   ret = copy_fdt(_addr);
if (ret)
return ret;
 
unmap_sysmem(fdt);
fdt = map_sysmem(fdt_addr, 0);
-   fdt_size = fdt_totalsize(fdt);
if (image_setup_libfdt(, fdt, 0, NULL)) {
printf("ERROR: failed to process device tree\n");
return EFI_LOAD_ERROR;
@@ -322,13 +318,6 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
if (ret != EFI_SUCCESS)
return EFI_OUT_OF_RESOURCES;
 
-   /* And reserve the space in the memory map */
-   fdt_start = fdt_addr;
-   fdt_pages = fdt_size >> EFI_PAGE_SHIFT;
-
-   ret = efi_add_memory_map(fdt_start, fdt_pages,
-EFI_BOOT_SERVICES_DATA, true);
-
return ret;
 }
 
-- 
2.19.1

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


[U-Boot] [PATCH v2 5/9] efi_loader: correct efi_add_known_memory()

2018-11-12 Thread Heinrich Schuchardt
If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the
number of memory pages may be incorrectly calculated.

We have to round up the start address and to round down the end address
to determine which complete pages are provided by the memory bank.

Signed-off-by: Heinrich Schuchardt 
---
v2:
no change
---
 lib/efi_loader/efi_memory.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index c0277355056..490e4921cce 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -563,13 +563,21 @@ __weak void efi_add_known_memory(void)
 
/* Add RAM */
for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
-   u64 ram_start = gd->bd->bi_dram[i].start;
-   u64 ram_size = gd->bd->bi_dram[i].size;
-   u64 start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
-   u64 pages = (ram_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
+   u64 ram_end, ram_start, pages;
 
-   efi_add_memory_map(start, pages, EFI_CONVENTIONAL_MEMORY,
-  false);
+   ram_start = gd->bd->bi_dram[i].start;
+   ram_end = ram_start + gd->bd->bi_dram[i].size;
+
+   /* Remove partial pages */
+   ram_end &= ~EFI_PAGE_MASK;
+   ram_start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
+
+   if (ram_end > ram_start) {
+   pages = (ram_end - ram_start) >> EFI_PAGE_SHIFT;
+
+   efi_add_memory_map(ram_start, pages,
+  EFI_CONVENTIONAL_MEMORY, false);
+   }
}
 }
 
-- 
2.19.1

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


[U-Boot] [PATCH v2 1/9] fdt_support: fdt reservations on the sandbox

2018-11-12 Thread Heinrich Schuchardt
On the sandbox the memory addresses in the device tree refer to the virtual
address space of the sandbox. This implies that the memory reservations for
the fdt also have to be converted to this address space.

Signed-off-by: Heinrich Schuchardt 
---
v2:
no change
---
 common/fdt_support.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index e6daa67990d..ec6af92dbba 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -240,7 +241,8 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
initrd_end)
}
}
 
-   err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start);
+   err = fdt_add_mem_rsv((void *)(uintptr_t)map_to_sysmem(fdt),
+ initrd_start, initrd_end - initrd_start);
if (err < 0) {
printf("fdt_initrd: %s\n", fdt_strerror(err));
return err;
@@ -633,7 +635,8 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
fdt_set_totalsize(blob, actualsize);
 
/* Add the new reservation */
-   ret = fdt_add_mem_rsv(blob, (uintptr_t)blob, actualsize);
+   ret = fdt_add_mem_rsv((void *)(uintptr_t)map_to_sysmem(blob),
+ (uintptr_t)blob, actualsize);
if (ret < 0)
return ret;
 
-- 
2.19.1

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


[U-Boot] [PATCH v2 0/9] efi_loader: fix fdt handling

2018-11-12 Thread Heinrich Schuchardt
This patch series fixes several errors in the handling of addresses on the
sandbox when setting up the flattened device tree.

The memory type used for the fdt is corrected. It is checked by a unit
test.

A macro is supplied to calculate the numbers of pages needed for a buffer.

---
v2:
Use copied fdt not the original one.
Remove code handling memory reservation for the fdt.

Heinrich Schuchardt (9):
  fdt_support: fdt reservations on the sandbox
  efi_loader: fix efi_find_free_memory()
  efi_loader: memory reservation for fdt
  efi_loader: carving out memory reservations
  efi_loader: correct efi_add_known_memory()
  efi_loader: macro efi_size_in_pages()
  efi_loader: fix memory mapping for sandbox
  efi_loader: do not use magic address for fdt
  efi_selftest: check fdt is marked as runtime data

 cmd/bootefi.c  | 73 ++
 common/fdt_support.c   |  7 ++-
 include/efi_loader.h   | 11 +++-
 lib/efi_loader/efi_memory.c| 29 ++
 lib/efi_selftest/efi_selftest_memory.c | 24 +
 5 files changed, 86 insertions(+), 58 deletions(-)

-- 
2.19.1

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


[U-Boot] [PATCH v2 4/9] efi_loader: carving out memory reservations

2018-11-12 Thread Heinrich Schuchardt
The "Devicetree Specification 0.2" does not prescribe that memory
reservations must be EFI page aligned. So let's not make such an
assumption in our code.

Do not carve out the pages for the device tree. This memory area is
already marked as EFI_RUNTIME_SERVICES_DATA.

Signed-off-by: Heinrich Schuchardt 
---
v2:
no change
---
 cmd/bootefi.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f2950817a13..c73e6228d3e 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -280,7 +280,16 @@ static void efi_carve_out_dt_rsv(void *fdt)
if (fdt_get_mem_rsv(fdt, i, , ) != 0)
continue;
 
-   pages = ALIGN(size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT;
+   /*
+* Do not carve out the device tree. It is already marked as
+* EFI_RUNTIME_SERVICES_DATA
+*/
+   if (addr == (uintptr_t)fdt)
+   continue;
+
+   pages = ALIGN(size + (addr & EFI_PAGE_MASK), EFI_PAGE_SIZE) >>
+   EFI_PAGE_SHIFT;
+   addr &= ~EFI_PAGE_MASK;
if (!efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
false))
printf("FDT memrsv map %d: Failed to add to map\n", i);
-- 
2.19.1

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


Re: [U-Boot] [PATCH V2 6/6] test: vboot: add padding pss for rsa signature

2018-11-12 Thread Philippe REYNES
Hi Clément,

You're right, those its are in an old-format style.
I can add a patch in this serie or send a separate
patch to clean the style.

What solution do you prefer ?

Regards,
Philippe


- Mail original -
De: "Clément Péron" 
À: s...@chromium.org
Cc: "philippe reynes" , "michal simek" 
, "joe hershberger" , "Marek 
Vasut" , "yamada masahiro" , 
aford...@gmail.com, "woods technical" , "teddy reed" 
, "jun nie" , "peng fan" 
, "keguang zhang" , "andre przywara" 
, "philipp tomsich" 
, "bin chen" , 
j...@jsg.id.au, nom...@palism.com, swar...@nvidia.com, "paul burton" 
, "alex kiernan" , "u-boot" 

Envoyé: Samedi 3 Novembre 2018 18:11:57
Objet: Re: [PATCH V2 6/6] test: vboot: add padding pss for rsa signature

Hi,

I'm not an expert but regarding commit
b8790ebeec13c882979dc986947397738d9f38aa I think you should drop the
unit-address in its files.

"The DT spec demands a unit-address of a node name to match the "reg"
property in that node. Newer dtc versions will throw warnings if this is
not the case.
Fix all occurences in the FIT image example files where this was not
observed, to not give bad examples to the reader.
"

Regards,
Clement

On Sat, 3 Nov 2018 at 07:08, Simon Glass  wrote:
>
> On 25 October 2018 at 03:29, Philippe Reynes
>  wrote:
> > The padding pss is now supported for rsa signature.
> > This add test with padding pss on vboot test.
> >
> > Signed-off-by: Philippe Reynes 
> > ---
> >  test/py/tests/test_vboot.py | 10 +++---
> >  test/py/tests/vboot/sign-configs-sha1-pss.its   | 46 
> > +
> >  test/py/tests/vboot/sign-configs-sha256-pss.its | 46 
> > +
> >  test/py/tests/vboot/sign-images-sha1-pss.its| 44 
> > +++
> >  test/py/tests/vboot/sign-images-sha256-pss.its  | 44 
> > +++
> >  5 files changed, 186 insertions(+), 4 deletions(-)
> >  create mode 100644 test/py/tests/vboot/sign-configs-sha1-pss.its
> >  create mode 100644 test/py/tests/vboot/sign-configs-sha256-pss.its
> >  create mode 100644 test/py/tests/vboot/sign-images-sha1-pss.its
> >  create mode 100644 test/py/tests/vboot/sign-images-sha256-pss.its
> >
> > Changelog:
> > v2:
> > - new patch in the serie
> > - add vboot for pss padding (thanks Simon Glass)
>
> Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/5] mtd: Use default mtdparts/mtids when not defined in the environment

2018-11-12 Thread Boris Brezillon
On Mon, 12 Nov 2018 15:55:18 +0530
Jagan Teki  wrote:

> On Mon, Nov 12, 2018 at 1:58 PM Boris Brezillon
>  wrote:
> >
> > U-boot provides a mean to define default values for mtdids and mtdparts
> > when they're not defined in the environment. Patch mtd_probe_devices()
> > to use those default values when env_get("mtdparts") or
> > env_get("mtdids") return NULL.
> >
> > This implementation is based on the logic found in cmd/mtdparts.c.
> >
> > Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command")
> > Reported-by: Stefan Roese 
> > Signed-off-by: Boris Brezillon 
> > Tested-by: Stefan Roese 
> > ---
> > Changes in v2:
> > - none  
> 
> Trigger travis-ci [1], will send v2 PR once all built fine.
> 
> [1] https://travis-ci.org/openedev/u-boot-amarula/builds

Looks like mine is all green [1] ;-). And yes, now I have travis-ci
set up to track my u-boot repo, so hopefully I won't end up submitting
patches that regress the tests described in .travis.yaml in the future.
Still, I'd like to insist on that this test result shouldn't replace
human review, which I think is still valuable to spot subtle issues.

Also, I'd like to point that some of the failures caused by the
spi-nand patchset are actually coming from the weird way MTD related
config options are selected/defined in u-boot. This should probably be
simplified somehow, but that's a different story.

[1]https://travis-ci.org/bbrezillon/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] rockchip: rk3188: add support for usb-uart functionality

2018-11-12 Thread Heiko Stuebner
Hi Philipp,

Am Montag, 8. Oktober 2018, 13:01:56 CET schrieb Heiko Stuebner:
> Rockchip socs can route the debug uart pins through the d+ and d- pins
> of one specific usbphy per soc. Add a config option and implement the
> setting on the rk3188.
> 
> Signed-off-by: Heiko Stuebner 

any thoughts on this and patch2?

Thank
Heiko

> ---
>  .../include/asm/arch-rockchip/grf_rk3188.h| 42 +++
>  arch/arm/mach-rockchip/Kconfig|  8 
>  arch/arm/mach-rockchip/rk3188-board-spl.c | 27 ++--
>  3 files changed, 73 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3188.h 
> b/arch/arm/include/asm/arch-rockchip/grf_rk3188.h
> index 28a159c5b7..d05197670d 100644
> --- a/arch/arm/include/asm/arch-rockchip/grf_rk3188.h
> +++ b/arch/arm/include/asm/arch-rockchip/grf_rk3188.h
> @@ -205,4 +205,46 @@ enum {
>   ATO_AE_SHIFT= 0,
>   ATO_AE_MASK = 1,
>  };
> +
> +/* GRF_UOC_CON0 */
> +enum {
> + SIDDQ_SHIFT = 13,
> + SIDDQ_MASK  = 1 << SIDDQ_SHIFT,
> +
> + BYPASSSEL_SHIFT = 9,
> + BYPASSSEL_MASK  = 1 << BYPASSSEL_SHIFT,
> +
> + BYPASSDMEN_SHIFT= 8,
> + BYPASSDMEN_MASK = 1 << BYPASSDMEN_SHIFT,
> +
> + UOC_DISABLE_SHIFT   = 4,
> + UOC_DISABLE_MASK= 1 << UOC_DISABLE_SHIFT,
> +
> + COMMON_ON_N_SHIFT   = 0,
> + COMMON_ON_N_MASK= 1 << COMMON_ON_N_SHIFT,
> +};
> +
> +/* GRF_UOC_CON2 */
> +enum {
> + SOFT_CON_SEL_SHIFT  = 2,
> + SOFT_CON_SEL_MASK   = 1 << SOFT_CON_SEL_SHIFT,
> +};
> +
> +/* GRF_UOC0_CON3 */
> +enum {
> + TERMSEL_FULLSPEED_SHIFT = 5,
> + TERMSEL_FULLSPEED_MASK  = 1 << TERMSEL_FULLSPEED_SHIFT,
> +
> + XCVRSELECT_SHIFT= 3,
> + XCVRSELECT_FSTRANSC = 1,
> + XCVRSELECT_MASK = 3 << XCVRSELECT_SHIFT,
> +
> + OPMODE_SHIFT= 1,
> + OPMODE_NODRIVING= 1,
> + OPMODE_MASK = 3 << OPMODE_SHIFT,
> +
> + SUSPENDN_SHIFT  = 0,
> + SUSPENDN_MASK   = 1 << SUSPENDN_SHIFT,
> +};
> +
>  #endif
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 145d96b1f0..0e15f7b859 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -156,6 +156,14 @@ config ROCKCHIP_RV1108
> The Rockchip RV1108 is a ARM-based SoC with a single-core Cortex-A7
> and a DSP.
>  
> +config ROCKCHIP_USB_UART
> + bool "Route uart output to usb pins"
> + help
> +   Rockchip SoCs have the ability to route the signals of the debug
> +   uart through the d+ and d- pins of a specific usb phy to enable
> +   some form of closed-case debugging. With this option supported
> +   SoCs will enable this routing as a debug measure.
> +
>  config SPL_ROCKCHIP_BACK_TO_BROM
>   bool "SPL returns to bootrom"
>   default y if ROCKCHIP_RK3036
> diff --git a/arch/arm/mach-rockchip/rk3188-board-spl.c 
> b/arch/arm/mach-rockchip/rk3188-board-spl.c
> index 98ca971b88..4a810ef696 100644
> --- a/arch/arm/mach-rockchip/rk3188-board-spl.c
> +++ b/arch/arm/mach-rockchip/rk3188-board-spl.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -92,18 +93,17 @@ static int setup_arm_clock(void)
>   return ret;
>  }
>  
> +#define GRF_BASE 0x20008000
> +
>  void board_init_f(ulong dummy)
>  {
> + struct rk3188_grf * const grf = (void *)GRF_BASE;
>   struct udevice *pinctrl, *dev;
>   int ret;
>  
>   /* Example code showing how to enable the debug UART on RK3188 */
>  #ifdef EARLY_UART
> -#include 
>   /* Enable early UART on the RK3188 */
> -#define GRF_BASE 0x20008000
> - struct rk3188_grf * const grf = (void *)GRF_BASE;
> -
>   rk_clrsetreg(>gpio1b_iomux,
>GPIO1B1_MASK << GPIO1B1_SHIFT |
>GPIO1B0_MASK << GPIO1B0_SHIFT,
> @@ -124,6 +124,25 @@ void board_init_f(ulong dummy)
>   printch('\n');
>  #endif
>  
> +#ifdef CONFIG_ROCKCHIP_USB_UART
> + rk_clrsetreg(>uoc0_con[0],
> +  SIDDQ_MASK | UOC_DISABLE_MASK | COMMON_ON_N_MASK,
> +  1 << SIDDQ_SHIFT | 1 << UOC_DISABLE_SHIFT |
> +  1 << COMMON_ON_N_SHIFT);
> + rk_clrsetreg(>uoc0_con[2],
> +  SOFT_CON_SEL_MASK, 1 << SOFT_CON_SEL_SHIFT);
> + rk_clrsetreg(>uoc0_con[3],
> +  OPMODE_MASK | XCVRSELECT_MASK |
> +  TERMSEL_FULLSPEED_MASK | SUSPENDN_MASK,
> +  OPMODE_NODRIVING << OPMODE_SHIFT |
> +  XCVRSELECT_FSTRANSC << XCVRSELECT_SHIFT |
> +  1 << TERMSEL_FULLSPEED_SHIFT |
> +  1 << SUSPENDN_SHIFT);
> + rk_clrsetreg(>uoc0_con[0],
> +  BYPASSSEL_MASK | BYPASSDMEN_MASK,
> +  1 << BYPASSSEL_SHIFT | 1 << BYPASSDMEN_SHIFT);
> +#endif
> +
>   ret = 

Re: [U-Boot] Rockchip RV1108 eMMC initialization fail

2018-11-12 Thread alex94
The log for SD card is the same like the one I posted, when using mainline
u-boot from Denx. When using u-boot from rockchip, the log is slightly
different, but it is the same error. I will put that log here too as soon as
I can. 



--
Sent from: http://u-boot.10912.n7.nabble.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Rockchip RV1108 eMMC initialization fail

2018-11-12 Thread alex94
I tried it, but the same error still occurs :/



--
Sent from: http://u-boot.10912.n7.nabble.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 14/15] drivers: ddr: introduce DDR driver for i.MX8M

2018-11-12 Thread Fabio Estevam
Hi Peng,

On Sun, Nov 11, 2018 at 8:51 AM Peng Fan  wrote:

> I tried structure before, see https://patchwork.ozlabs.org/patch/857974/
> But that still not good. There are too many registers, I would like
> to keep current code. The ddr code are used in NXP vendor tree and are used in
> GA release, and the ddr tool will auto generated code, manually converting 
> the current code
> to structure will be also easy to introduce errors.
>
> Stefano, Fabio, what do you think?

I am fine with the current approach from this patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] coreboot: only init usb if necessary

2018-11-12 Thread Bin Meng
Hi Christian,

On Mon, Nov 12, 2018 at 10:39 PM Christian Gmeiner
 wrote:
>
> Hi Bin
>
> Am Mo., 12. Nov. 2018 um 14:44 Uhr schrieb Bin Meng :
> >
> > Hi Christian/Thomas,
> >
> > On Mon, Nov 12, 2018 at 8:44 PM Christian Gmeiner
> >  wrote:
> > >
> > > From: Thomas RIENOESSL 
> > >
> > > Up until now the call to initialize the USB subsystem
> > > was hardcoded for U-Boot running as a coreboot payload.
> > > This was used to enable the use of a USB keyboard
> > > in the U-Boot shell. However not all boards might need
> > > this functionality. As initializing the USB subsystem
> > > can take a considerable amount of time (several
> > > seconds on some boards), we now initialize the
> > > USB subsystem only if U-Boot is configured to use
> > > USB keyboards.
> > >
> > > Signed-off-by: Thomas RIENOESSL 
> > > ---
> > >  arch/x86/cpu/coreboot/coreboot.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> >
> > Looks good to me. Can we also fix the efi-payload one?
> >
>
> Sure - do you prefer two patches (one for coreboot and one for x86:
> efi: payload) or
> shall we put both changes into one patch?

I don't have preference. You can use either way :)

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


[U-Boot] [PATCH 2/2] imx8: scu: Update call to lists_bind_fdt()

2018-11-12 Thread Bin Meng
This commit should be squashed into

commit 2bba642dbaa4 ("dm: core: Respect drivers with the
DM_FLAG_PRE_RELOC flag in lists_bind_fdt()")

on u-boot-dm/master branch.

Signed-off-by: Bin Meng 
---

 drivers/misc/imx8/scu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/imx8/scu.c b/drivers/misc/imx8/scu.c
index 0647ddf..b824ac7 100644
--- a/drivers/misc/imx8/scu.c
+++ b/drivers/misc/imx8/scu.c
@@ -223,7 +223,7 @@ static int imx8_scu_bind(struct udevice *dev)
if (node < 0)
panic("No clk node found\n");
 
-   ret = lists_bind_fdt(dev, offset_to_ofnode(node), );
+   ret = lists_bind_fdt(dev, offset_to_ofnode(node), , true);
if (ret)
return ret;
 
@@ -234,7 +234,7 @@ static int imx8_scu_bind(struct udevice *dev)
if (node < 0)
panic("No iomuxc node found\n");
 
-   ret = lists_bind_fdt(dev, offset_to_ofnode(node), );
+   ret = lists_bind_fdt(dev, offset_to_ofnode(node), , true);
if (ret)
return ret;
 
-- 
2.7.4

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


[U-Boot] [PATCH 1/2] Revert "imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO"

2018-11-12 Thread Bin Meng
This reverts commit c5bbfaf05dc8592b479a44df6abaadbab54fec2b.

Disabling CONFIG_DISPLAY_CPUINFO was a temporary solution to get
the v2018.11 release out. Now the merge window opens, revert it.

Signed-off-by: Bin Meng 
---

 configs/imx8qxp_mek_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig
index a45f3ba..1588416 100644
--- a/configs/imx8qxp_mek_defconfig
+++ b/configs/imx8qxp_mek_defconfig
@@ -6,7 +6,6 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_IMX8QXP_MEK=y
 CONFIG_NR_DRAM_BANKS=3
 CONFIG_BOOTDELAY=3
-# CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_CMD_CPU=y
 # CONFIG_CMD_IMPORTENV is not set
 CONFIG_CMD_CLK=y
-- 
2.7.4

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


Re: [U-Boot] [PATCH] coreboot: only init usb if necessary

2018-11-12 Thread Christian Gmeiner
Hi Bin

Am Mo., 12. Nov. 2018 um 14:44 Uhr schrieb Bin Meng :
>
> Hi Christian/Thomas,
>
> On Mon, Nov 12, 2018 at 8:44 PM Christian Gmeiner
>  wrote:
> >
> > From: Thomas RIENOESSL 
> >
> > Up until now the call to initialize the USB subsystem
> > was hardcoded for U-Boot running as a coreboot payload.
> > This was used to enable the use of a USB keyboard
> > in the U-Boot shell. However not all boards might need
> > this functionality. As initializing the USB subsystem
> > can take a considerable amount of time (several
> > seconds on some boards), we now initialize the
> > USB subsystem only if U-Boot is configured to use
> > USB keyboards.
> >
> > Signed-off-by: Thomas RIENOESSL 
> > ---
> >  arch/x86/cpu/coreboot/coreboot.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
>
> Looks good to me. Can we also fix the efi-payload one?
>

Sure - do you prefer two patches (one for coreboot and one for x86:
efi: payload) or
shall we put both changes into one patch?

-- 
greets
--
Christian Gmeiner, MSc

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


Re: [U-Boot] [PATCH u-boot] spi: Add Amlogic Meson SPI Flash Controller driver

2018-11-12 Thread Wolfgang Denk
Dear Neil,

In message <7206f5df-626e-a367-8933-4e6afb64a...@baylibre.com> you wrote:
> 
> On 06/11/2018 10:25, Neil Armstrong wrote:
> > The Amlogic Meson SoCs embeds a Flash oriented SPI Controller name SPIFC.
> > This driver, ported from the Linux meson-spi-spifc driver, add support
> > for this controller on the Amlogic Meson GX SoCs in U-Boot.
> 
> I found a bug in this driver, I'll send a v2 fixing it.

Then please also fix attribution. See especially bullet # 4 at
http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign

Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Cleverness and Style have no place in getting a project completed.
  -- Tom Christiansen
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] Revert "board_f: Use static print_cpuinfo if CONFIG_CPU is active"

2018-11-12 Thread Bin Meng
Hi Simon,

On Mon, Nov 12, 2018 at 9:58 PM Simon Glass  wrote:
>
> Hi Bin,
>
> On 11 November 2018 at 21:55, Bin Meng  wrote:
> >
> > Hi Simon,
> >
> > On Mon, Nov 12, 2018 at 11:25 AM Simon Glass  wrote:
> > >
> > > Hi Bin,
> > >
> > > On 7 November 2018 at 17:24, Bin Meng  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Thu, Nov 8, 2018 at 1:09 AM Simon Glass  wrote:
> > > > >
> > > > > On 7 November 2018 at 04:50, Bin Meng  wrote:
> > > > > >
> > > > > > This reverts commit c0434407b595f785fc7401237896c48c791b45fd.
> > > > > >
> > > > > > It turns out commit c0434407b595 broke some boards which have DM CPU
> > > > > > driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail
> > > > > > to boot when print_cpuinfo() is called during boot.
> > > > > >
> > > > > > Fixes are already sent to ML and in u-boot-dm/next, however since
> > > > > > we are getting close to the v2018.11 release, it's safer we revert
> > > > > > the original commit.
> > > > > >
> > > > > > This commit should be reverted after v2018.11 release.
> > > > > >
> > > > > > Signed-off-by: Bin Meng 
> > > > > > ---
> > > > > >
> > > > > >  common/board_f.c | 28 
> > > > > >  include/init.h   |  7 ---
> > > > > >  2 files changed, 35 deletions(-)
> > > > >
> > > > > Thanks Bin. I'd like to get u-boot-dm/next set up ready for the merge
> > > > > window, so I presume in that we need to un-revert these changes and
> > > > > then pick up your two series?
> > > > >
> > > >
> > > > That is correct. I can help test u-boot-dm/next.
> > >
> > > OK thank you. It is ready there now.
> > >
> >
> > Do you mean u-boot-dm/next? It looks to me the repo was updated 7 days ago.
>
> Sorry u-boot-dm/testing. However I have pushed it to u-boot-dm/master now.
>
> If you are sending new patches, can you please base on that?

Sure, I will take a look.

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


Re: [U-Boot] [PATCH u-boot] spi: Add Amlogic Meson SPI Flash Controller driver

2018-11-12 Thread Neil Armstrong
Hi,


On 06/11/2018 10:25, Neil Armstrong wrote:
> The Amlogic Meson SoCs embeds a Flash oriented SPI Controller name SPIFC.
> This driver, ported from the Linux meson-spi-spifc driver, add support
> for this controller on the Amlogic Meson GX SoCs in U-Boot.

I found a bug in this driver, I'll send a v2 fixing it.

Neil


> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/spi/Kconfig   |   8 +
>  drivers/spi/Makefile  |   1 +
>  drivers/spi/meson_spifc.c | 368 
> ++
>  3 files changed, 377 insertions(+)
>  create mode 100644 drivers/spi/meson_spifc.c
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 516188e..838a007 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -116,6 +116,14 @@ config ICH_SPI
> access the SPI NOR flash on platforms embedding this Intel
> ICH IP core.
>  
> +config MESON_SPIFC
> + bool "Amlogic Meson SPI Flash Controller driver"
> + depends on ARCH_MESON
> + help
> +   Enable the Amlogic Meson SPI Flash Controller SPIFC) driver.
> +   This driver can be used to access the SPI NOR flash chips on 
> +   Amlogic Meson SoCs.
> +
>  config MT7621_SPI
>   bool "MediaTek MT7621 SPI driver"
>   depends on ARCH_MT7620
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 7242ea7..67b42da 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
>  obj-$(CONFIG_ICH_SPI) +=  ich.o
>  obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
>  obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
> +obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
>  obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
>  obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
>  obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
> diff --git a/drivers/spi/meson_spifc.c b/drivers/spi/meson_spifc.c
> new file mode 100644
> index 000..6fd3d1a
> --- /dev/null
> +++ b/drivers/spi/meson_spifc.c
> @@ -0,0 +1,368 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2014 Beniamino Galvani 
> + * Copyright (C) 2018 BayLibre, SAS
> + * Author: Neil Armstrong 
> + *
> + * Amlogic Meson SPI Flash Controller driver
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* register map */
> +#define REG_CMD  0x00
> +#define REG_ADDR 0x04
> +#define REG_CTRL 0x08
> +#define REG_CTRL10x0c
> +#define REG_STATUS   0x10
> +#define REG_CTRL20x14
> +#define REG_CLOCK0x18
> +#define REG_USER 0x1c
> +#define REG_USER10x20
> +#define REG_USER20x24
> +#define REG_USER30x28
> +#define REG_USER40x2c
> +#define REG_SLAVE0x30
> +#define REG_SLAVE1   0x34
> +#define REG_SLAVE2   0x38
> +#define REG_SLAVE3   0x3c
> +#define REG_C0   0x40
> +#define REG_B8   0x60
> +#define REG_MAX  0x7c
> +
> +/* register fields */
> +#define CMD_USER BIT(18)
> +#define CTRL_ENABLE_AHB  BIT(17)
> +#define CLOCK_SOURCE BIT(31)
> +#define CLOCK_DIV_SHIFT  12
> +#define CLOCK_DIV_MASK   (0x3f << CLOCK_DIV_SHIFT)
> +#define CLOCK_CNT_HIGH_SHIFT 6
> +#define CLOCK_CNT_HIGH_MASK  (0x3f << CLOCK_CNT_HIGH_SHIFT)
> +#define CLOCK_CNT_LOW_SHIFT  0
> +#define CLOCK_CNT_LOW_MASK   (0x3f << CLOCK_CNT_LOW_SHIFT)
> +#define USER_DIN_EN_MS   BIT(0)
> +#define USER_CMP_MODEBIT(2)
> +#define USER_CLK_NOT_INV BIT(7)
> +#define USER_UC_DOUT_SEL BIT(27)
> +#define USER_UC_DIN_SEL  BIT(28)
> +#define USER_UC_MASK ((BIT(5) - 1) << 27)
> +#define USER1_BN_UC_DOUT_SHIFT   17
> +#define USER1_BN_UC_DOUT_MASK(0xff << 16)
> +#define USER1_BN_UC_DIN_SHIFT8
> +#define USER1_BN_UC_DIN_MASK (0xff << 8)
> +#define USER4_CS_POL_HIGHBIT(23)
> +#define USER4_IDLE_CLK_HIGH  BIT(29)
> +#define USER4_CS_ACT BIT(30)
> +#define SLAVE_TRST_DONE  BIT(4)
> +#define SLAVE_OP_MODEBIT(30)
> +#define SLAVE_SW_RST BIT(31)
> +
> +#define SPIFC_BUFFER_SIZE64
> +
> +struct meson_spifc_priv {
> + struct regmap   *regmap;
> + struct clk  clk;
> +};
> +
> +/**
> + * meson_spifc_wait_ready() - wait for the current operation to terminate
> + * @spifc:   the Meson SPI device
> + * Return:   0 on success, a negative value on error
> + */
> +static int meson_spifc_wait_ready(struct meson_spifc_priv *spifc)
> +{
> + u32 data;
> + ulong tbase = get_timer(0);
> +
> + do {
> + regmap_read(spifc->regmap, REG_SLAVE, );
> + if (data & SLAVE_TRST_DONE)
> + return 0;
> + } while (get_timer(tbase) < 5 * CONFIG_SYS_HZ);
> +
> + return -ETIMEDOUT;
> +}
> +
> +/**
> + * 

Re: [U-Boot] [PATCH 1/2] Revert "board_f: Use static print_cpuinfo if CONFIG_CPU is active"

2018-11-12 Thread Simon Glass
Hi Bin,

On 11 November 2018 at 21:55, Bin Meng  wrote:
>
> Hi Simon,
>
> On Mon, Nov 12, 2018 at 11:25 AM Simon Glass  wrote:
> >
> > Hi Bin,
> >
> > On 7 November 2018 at 17:24, Bin Meng  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Thu, Nov 8, 2018 at 1:09 AM Simon Glass  wrote:
> > > >
> > > > On 7 November 2018 at 04:50, Bin Meng  wrote:
> > > > >
> > > > > This reverts commit c0434407b595f785fc7401237896c48c791b45fd.
> > > > >
> > > > > It turns out commit c0434407b595 broke some boards which have DM CPU
> > > > > driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail
> > > > > to boot when print_cpuinfo() is called during boot.
> > > > >
> > > > > Fixes are already sent to ML and in u-boot-dm/next, however since
> > > > > we are getting close to the v2018.11 release, it's safer we revert
> > > > > the original commit.
> > > > >
> > > > > This commit should be reverted after v2018.11 release.
> > > > >
> > > > > Signed-off-by: Bin Meng 
> > > > > ---
> > > > >
> > > > >  common/board_f.c | 28 
> > > > >  include/init.h   |  7 ---
> > > > >  2 files changed, 35 deletions(-)
> > > >
> > > > Thanks Bin. I'd like to get u-boot-dm/next set up ready for the merge
> > > > window, so I presume in that we need to un-revert these changes and
> > > > then pick up your two series?
> > > >
> > >
> > > That is correct. I can help test u-boot-dm/next.
> >
> > OK thank you. It is ready there now.
> >
>
> Do you mean u-boot-dm/next? It looks to me the repo was updated 7 days ago.

Sorry u-boot-dm/testing. However I have pushed it to u-boot-dm/master now.

If you are sending new patches, can you please base on that?

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


Re: [U-Boot] Rockchip RV1108 eMMC initialization fail

2018-11-12 Thread Marek Vasut
On 11/12/2018 10:23 AM, alex94 wrote:
> Hi,
> I am trying to use eMMC as a storage medium for my
> custom board based on Rockchip RV1108. 
> 
> I have already made the changes as described in this thread:
> 
> http://u-boot.10912.n7.nabble.com/Rockchip-RV1108-eMMC-support-not-working-td343843.html#a343866
> 
> about using eMMC with RV1108.
> 
> When U-boot starts, and I try to access the eMMC, here is what I get:
> 
> => mmc info
> CMD_SEND:0
> ARG  0x
> MMC_RSP_NONE
> CMD_SEND:8
> ARG  0x01AA
> RET  -110
> CMD_SEND:55
> ARG  0x
> RET  -110
How does the log look for an SD ? I suspect it's probably clock or
pinmux that's broken.

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


Re: [U-Boot] Rockchip RV1108 eMMC initialization fail

2018-11-12 Thread Otavio Salvador
Hello,

On Mon, Nov 12, 2018 at 10:26 AM alex94
 wrote:
> I am trying to use eMMC as a storage medium for my
> custom board based on Rockchip RV1108.
>
> I have already made the changes as described in this thread:
>
> http://u-boot.10912.n7.nabble.com/Rockchip-RV1108-eMMC-support-not-working-td343843.html#a343866
>
> about using eMMC with RV1108.
>
> When U-boot starts, and I try to access the eMMC, here is what I get:

Did you try my patchset to add it?

https://patchwork.ozlabs.org/project/uboot/list/?series=72834

Please give it a try.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] coreboot: only init usb if necessary

2018-11-12 Thread Bin Meng
Hi Christian/Thomas,

On Mon, Nov 12, 2018 at 8:44 PM Christian Gmeiner
 wrote:
>
> From: Thomas RIENOESSL 
>
> Up until now the call to initialize the USB subsystem
> was hardcoded for U-Boot running as a coreboot payload.
> This was used to enable the use of a USB keyboard
> in the U-Boot shell. However not all boards might need
> this functionality. As initializing the USB subsystem
> can take a considerable amount of time (several
> seconds on some boards), we now initialize the
> USB subsystem only if U-Boot is configured to use
> USB keyboards.
>
> Signed-off-by: Thomas RIENOESSL 
> ---
>  arch/x86/cpu/coreboot/coreboot.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

Looks good to me. Can we also fix the efi-payload one?

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


[U-Boot] [PATCH v2 4/4] cmd: adc: add an option to scan some or all available channels

2018-11-12 Thread Fabrice Gasnier
Add new option to 'adc' command to do a single scan of:
- some channel(s), using mask argument
- all channels available on an ADC device (when optional mask is omitted).

Signed-off-by: Fabrice Gasnier 
---

Changes in v2: None

 cmd/adc.c | 55 ++-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/cmd/adc.c b/cmd/adc.c
index 7360a96..2d635ac 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -95,10 +95,62 @@ static int do_adc_single(cmd_tbl_t *cmdtp, int flag, int 
argc,
return CMD_RET_SUCCESS;
 }
 
+static int do_adc_scan(cmd_tbl_t *cmdtp, int flag, int argc,
+  char *const argv[])
+{
+   struct adc_channel ch[ADC_MAX_CHANNEL];
+   struct udevice *dev;
+   unsigned int ch_mask;
+   int i, chan, ret, uV;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   ret = uclass_get_device_by_name(UCLASS_ADC, argv[1], );
+   if (ret) {
+   pr_err("Can't get the ADC %s: %d\n", argv[1], ret);
+   return CMD_RET_FAILURE;
+   }
+
+   switch (argc) {
+   case 3:
+   ch_mask = simple_strtoul(argv[2], NULL, 0);
+   if (ch_mask)
+   break;
+   case 2:
+   ret = adc_channel_mask(dev, _mask);
+   if (ret) {
+   pr_err("Can't get mask for %s: %d\n", dev->name, ret);
+   return CMD_RET_FAILURE;
+   }
+   break;
+   }
+
+   ret = adc_channels_single_shot(dev->name, ch_mask, ch);
+   if (ret) {
+   pr_err("Can't get single shot for %s (chans mask: 0x%x): %d\n",
+  dev->name, ch_mask, ret);
+   return CMD_RET_FAILURE;
+   }
+
+   for (chan = 0, i = 0; chan < ADC_MAX_CHANNEL; chan++) {
+   if (!(ch_mask & ADC_CHANNEL(chan)))
+   continue;
+   if (!adc_raw_to_uV(dev, ch[i].data, ))
+   printf("[%02d]: %u, %d uV\n", ch[i].id, ch[i].data, uV);
+   else
+   printf("[%02d]: %u\n", ch[i].id, ch[i].data);
+   i++;
+   }
+
+   return CMD_RET_SUCCESS;
+}
+
 static cmd_tbl_t cmd_adc_sub[] = {
U_BOOT_CMD_MKENT(list, 1, 1, do_adc_list, "", ""),
U_BOOT_CMD_MKENT(info, 2, 1, do_adc_info, "", ""),
U_BOOT_CMD_MKENT(single, 3, 1, do_adc_single, "", ""),
+   U_BOOT_CMD_MKENT(scan, 3, 1, do_adc_scan, "", ""),
 };
 
 static int do_adc(cmd_tbl_t *cmdtp, int flag, int argc,
@@ -124,6 +176,7 @@ static int do_adc(cmd_tbl_t *cmdtp, int flag, int argc,
 static char adc_help_text[] =
"list - list ADC devices\n"
"adc info  - Get ADC device info\n"
-   "adc single   - Get Single data of ADC device channel";
+   "adc single   - Get Single data of ADC device channel\n"
+   "adc scan  [channel mask] - Scan all [or masked] ADC channels";
 
 U_BOOT_CMD(adc, 4, 1, do_adc, "ADC sub-system", adc_help_text);
-- 
1.9.1

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


[U-Boot] [PATCH v2 0/4] Add adc uclass's channel mask and conversion helpers and enhance adc cmd

2018-11-12 Thread Fabrice Gasnier
This series adds ADC uclass's helpers to
- retrieve the ADC device available channels
- ease conversions to standard unit (µV)
- enhance 'adc' command to print information on available ADC channels
- enhance 'adc' command to print conversion result both as raw and µV
- enhance 'adc' command to scan once several or all channels

Changes in v2:
- Add calls to the new functions in test/dm/adc.c as suggested by Simon

Fabrice Gasnier (4):
  dm: adc: add uclass's mask and conversion helpers
  cmd: adc: add info on channel mask
  cmd: adc: print single conversion also in uV
  cmd: adc: add an option to scan some or all available channels

 cmd/adc.c| 70 +---
 drivers/adc/adc-uclass.c | 37 +
 include/adc.h| 21 +++
 test/dm/adc.c| 36 +
 4 files changed, 160 insertions(+), 4 deletions(-)

-- 
1.9.1

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


[U-Boot] [PATCH v2 2/4] cmd: adc: add info on channel mask

2018-11-12 Thread Fabrice Gasnier
Enhance adc info command to report also the channel mask.

Signed-off-by: Fabrice Gasnier 
---

Changes in v2: None

 cmd/adc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/cmd/adc.c b/cmd/adc.c
index c8857ed..39f61c1 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -35,7 +35,7 @@ static int do_adc_info(cmd_tbl_t *cmdtp, int flag, int argc,
   char *const argv[])
 {
struct udevice *dev;
-   unsigned int data_mask;
+   unsigned int data_mask, ch_mask;
int ret, vss, vdd;
 
if (argc < 2)
@@ -49,6 +49,10 @@ static int do_adc_info(cmd_tbl_t *cmdtp, int flag, int argc,
 
printf("ADC Device '%s' :\n", argv[1]);
 
+   ret = adc_channel_mask(dev, _mask);
+   if (!ret)
+   printf("channel mask: %x\n", ch_mask);
+
ret = adc_data_mask(dev, _mask);
if (!ret)
printf("data mask: %x\n", data_mask);
-- 
1.9.1

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


[U-Boot] [PATCH v2 1/4] dm: adc: add uclass's mask and conversion helpers

2018-11-12 Thread Fabrice Gasnier
Add two functions to ADC uclass's:
- adc_raw_to_uV() to ease ADC raw value conversion to microvolts
- adc_channel_mask() to get channels on consumer side

Signed-off-by: Fabrice Gasnier 
---

Changes in v2:
- Add calls to the new functions in test/dm/adc.c as suggested by Simon

 drivers/adc/adc-uclass.c | 37 +
 include/adc.h| 21 +
 test/dm/adc.c| 36 
 3 files changed, 94 insertions(+)

diff --git a/drivers/adc/adc-uclass.c b/drivers/adc/adc-uclass.c
index 738c1ea..0a492eb 100644
--- a/drivers/adc/adc-uclass.c
+++ b/drivers/adc/adc-uclass.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -77,6 +78,18 @@ int adc_data_mask(struct udevice *dev, unsigned int 
*data_mask)
return 0;
 }
 
+int adc_channel_mask(struct udevice *dev, unsigned int *channel_mask)
+{
+   struct adc_uclass_platdata *uc_pdata = dev_get_uclass_platdata(dev);
+
+   if (!uc_pdata)
+   return -ENOSYS;
+
+   *channel_mask = uc_pdata->channel_mask;
+
+   return 0;
+}
+
 int adc_stop(struct udevice *dev)
 {
const struct adc_ops *ops = dev_get_driver_ops(dev);
@@ -329,6 +342,30 @@ int adc_vss_value(struct udevice *dev, int *uV)
return 0;
 }
 
+int adc_raw_to_uV(struct udevice *dev, unsigned int raw, int *uV)
+{
+   unsigned int data_mask;
+   int ret, val, vref;
+   u64 raw64 = raw;
+
+   ret = adc_vdd_value(dev, );
+   if (ret)
+   return ret;
+
+   if (!adc_vss_value(dev, ))
+   vref -= val;
+
+   ret = adc_data_mask(dev, _mask);
+   if (ret)
+   return ret;
+
+   raw64 *= vref;
+   do_div(raw64, data_mask);
+   *uV = raw64;
+
+   return 0;
+}
+
 static int adc_vdd_platdata_set(struct udevice *dev)
 {
struct adc_uclass_platdata *uc_pdata = dev_get_uclass_platdata(dev);
diff --git a/include/adc.h b/include/adc.h
index d04c9c4..5841dfb 100644
--- a/include/adc.h
+++ b/include/adc.h
@@ -219,6 +219,17 @@ int adc_channels_data(struct udevice *dev, unsigned int 
channel_mask,
 int adc_data_mask(struct udevice *dev, unsigned int *data_mask);
 
 /**
+ * adc_channel_mask() - get channel mask for given ADC device
+ *
+ * This can be used if adc uclass platform data is filled.
+ *
+ * @dev:   ADC device to check
+ * @channel_mask: pointer to the returned channel bitmask
+ * @return: 0 if OK, -ve on error
+ */
+int adc_channel_mask(struct udevice *dev, unsigned int *channel_mask);
+
+/**
  * adc_channel_single_shot() - get output data of conversion for the ADC
  * device's channel. This function searches for the device with the given name,
  * starts the given channel conversion and returns the output data.
@@ -284,4 +295,14 @@ int adc_vss_value(struct udevice *dev, int *uV);
  */
 int adc_stop(struct udevice *dev);
 
+/**
+ * adc_raw_to_uV() - converts raw value to microvolts for given ADC device.
+ *
+ * @dev: ADC device used from conversion
+ * @raw: raw value to convert
+ * @uV: converted value in microvolts
+ * @return:  0 on success or -ve on error
+ */
+int adc_raw_to_uV(struct udevice *dev, unsigned int raw, int *uV);
+
 #endif
diff --git a/test/dm/adc.c b/test/dm/adc.c
index 13eda3b..904c449 100644
--- a/test/dm/adc.c
+++ b/test/dm/adc.c
@@ -22,10 +22,14 @@
 static int dm_test_adc_bind(struct unit_test_state *uts)
 {
struct udevice *dev;
+   unsigned int channel_mask;
 
ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
ut_asserteq_str(SANDBOX_ADC_DEVNAME, dev->name);
 
+   ut_assertok(adc_channel_mask(dev, _mask));
+   ut_asserteq((1 << SANDBOX_ADC_CHANNELS) - 1, channel_mask);
+
return 0;
 }
 DM_TEST(dm_test_adc_bind, DM_TESTF_SCAN_FDT);
@@ -160,3 +164,35 @@ static int dm_test_adc_multi_channel_shot(struct 
unit_test_state *uts)
return 0;
 }
 DM_TEST(dm_test_adc_multi_channel_shot, DM_TESTF_SCAN_FDT);
+
+
+static const int dm_test_adc_uV_data[SANDBOX_ADC_CHANNELS] = {
+   ((u64)SANDBOX_ADC_CHANNEL0_DATA * SANDBOX_BUCK2_INITIAL_EXPECTED_UV) /
+   SANDBOX_ADC_DATA_MASK,
+   ((u64)SANDBOX_ADC_CHANNEL1_DATA * SANDBOX_BUCK2_INITIAL_EXPECTED_UV) /
+   SANDBOX_ADC_DATA_MASK,
+   ((u64)SANDBOX_ADC_CHANNEL2_DATA * SANDBOX_BUCK2_INITIAL_EXPECTED_UV) /
+   SANDBOX_ADC_DATA_MASK,
+   ((u64)SANDBOX_ADC_CHANNEL3_DATA * SANDBOX_BUCK2_INITIAL_EXPECTED_UV) /
+   SANDBOX_ADC_DATA_MASK,
+};
+
+static int dm_test_adc_raw_to_uV(struct unit_test_state *uts)
+{
+   struct adc_channel *tdata = adc_channel_test_data;
+   unsigned int i, data;
+   struct udevice *dev;
+   int uV;
+
+   ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
+   /* Test each ADC channel's value in microvolts */
+   for (i = 0; i < SANDBOX_ADC_CHANNELS; i++, tdata++) {
+   

[U-Boot] [PATCH v2 3/4] cmd: adc: print single conversion also in uV

2018-11-12 Thread Fabrice Gasnier
Use newly introduced adc_raw_to_uV() API to print conversion result
both as raw value and micro-volts by default.

Signed-off-by: Fabrice Gasnier 
---

Changes in v2: None

 cmd/adc.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/cmd/adc.c b/cmd/adc.c
index 39f61c1..7360a96 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -71,8 +71,9 @@ static int do_adc_info(cmd_tbl_t *cmdtp, int flag, int argc,
 static int do_adc_single(cmd_tbl_t *cmdtp, int flag, int argc,
 char *const argv[])
 {
+   struct udevice *dev;
unsigned int data;
-   int ret;
+   int ret, uV;
 
if (argc < 3)
return CMD_RET_USAGE;
@@ -85,7 +86,11 @@ static int do_adc_single(cmd_tbl_t *cmdtp, int flag, int 
argc,
return CMD_RET_FAILURE;
}
 
-   printf("%u\n", data);
+   ret = uclass_get_device_by_name(UCLASS_ADC, argv[1], );
+   if (!ret && !adc_raw_to_uV(dev, data, ))
+   printf("%u, %d uV\n", data, uV);
+   else
+   printf("%u\n", data);
 
return CMD_RET_SUCCESS;
 }
-- 
1.9.1

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


Re: [U-Boot] Pull request, v2018.11: u-boot-spi/master

2018-11-12 Thread Jagan Teki
On Mon, Nov 12, 2018 at 10:19 AM Jagan Teki  wrote:
>
> Hi Tom,

Please ignore this, will send v2 for the same.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] coreboot: only init usb if necessary

2018-11-12 Thread Christian Gmeiner
From: Thomas RIENOESSL 

Up until now the call to initialize the USB subsystem
was hardcoded for U-Boot running as a coreboot payload.
This was used to enable the use of a USB keyboard
in the U-Boot shell. However not all boards might need
this functionality. As initializing the USB subsystem
can take a considerable amount of time (several
seconds on some boards), we now initialize the
USB subsystem only if U-Boot is configured to use
USB keyboards.

Signed-off-by: Thomas RIENOESSL 
---
 arch/x86/cpu/coreboot/coreboot.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index a6fd3a849a..915341fe12 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -77,7 +77,8 @@ int last_stage_init(void)
timestamp_add_to_bootstage();
 
/* start usb so that usb keyboard can be used as input device */
-   usb_init();
+   if (IS_ENABLED(CONFIG_USB_KEYBOARD))
+   usb_init();
 
board_final_cleanup();
 
-- 
2.19.1

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


Re: [U-Boot] [PATCH 1/2] spl_spi: Read default speed and mode values from DT

2018-11-12 Thread Patrick DELAUNAY
Hi Simon,

> From: Simon Goldschmidt 
> Sent: vendredi 9 novembre 2018 07:45
> Subject: Re: [PATCH 1/2] spl_spi: Read default speed and mode values from DT
> Importance: High
> 
> On Thu, Nov 8, 2018 at 5:58 PM Patrick Delaunay 
> wrote:
> >
> > In case of DT boot, don't read default speed and mode for SPI from
> > CONFIG_*, instead read from DT node.
> >
> > Signed-off-by: Christophe Kerello 
> > Signed-off-by: Patrick Delaunay 
> > ---
> >
> >  common/spl/spl_spi.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c index
> > 8cd4830..3cefc9a 100644
> > --- a/common/spl/spl_spi.c
> > +++ b/common/spl/spl_spi.c
> > @@ -78,11 +78,18 @@ static int spl_spi_load_image(struct spl_image_info
> *spl_image,
> > /*
> >  * Load U-Boot image from SPI flash into RAM
> >  */
> > -
> > +#ifdef CONFIG_DM_SPI_FLASH
> > +   /* In DM mode defaults will be taken from DT */
> > +   flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
> > +   CONFIG_SF_DEFAULT_CS,
> > +   0,
> > +   0);
> 
> Code duplication is never good. Wouldn't it be nicer to only have an #if for 
> the
> two differing parameters (e.g. via local variables) instead of duplicating the
> function call?

Ok. I take the point and I will update the patchset with local variable in v2.
I just wait few day to be sure it is the only remark.

> Simon
> 
> > +#else
> > flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
> > CONFIG_SF_DEFAULT_CS,
> > CONFIG_SF_DEFAULT_SPEED,
> > CONFIG_SF_DEFAULT_MODE);
> > +#endif
> > if (!flash) {
> > puts("SPI probe failed.\n");
> > return -ENODEV;
> > --
> > 2.7.4
> >

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


[U-Boot] USB: ci_udc fails to link in SPL when DM is active

2018-11-12 Thread Sven Schwermer
Hi,

I’m trying to build an SPL image for an iMX7 platform with the following 
options active:

CONFIG_SPL=y
CONFIG_SPL_USB_GADGET_SUPPORT=y
CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_CMD_USB=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_CI_UDC=y
CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_USB_FUNCTION_SDP=y

This leads to the SPL failing to link:

  LD  spl/u-boot-spl
drivers/built-in.o: In function `usb_gadget_register_driver':
/root/u-boot/drivers/usb/gadget/ci_udc.c:1019: undefined reference to 
`usb_setup_ehci_gadget'
scripts/Makefile.spl:364: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 1
Makefile:1539: recipe for target 'spl/u-boot-spl' failed
make: *** [spl/u-boot-spl] Error 2

Is DM_USB in SPL with this driver not supported or should I have configured 
something else? I’m using the current mainline master branch.

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


[U-Boot] Rockchip RV1108 eMMC initialization fail

2018-11-12 Thread alex94
Hi,
I am trying to use eMMC as a storage medium for my
custom board based on Rockchip RV1108. 

I have already made the changes as described in this thread:

http://u-boot.10912.n7.nabble.com/Rockchip-RV1108-eMMC-support-not-working-td343843.html#a343866

about using eMMC with RV1108.

When U-boot starts, and I try to access the eMMC, here is what I get:

=> mmc info
CMD_SEND:0
ARG  0x
MMC_RSP_NONE
CMD_SEND:8
ARG  0x01AA
RET  -110
CMD_SEND:55
ARG  0x
RET  -110
CMD_SEND:0
ARG  0x
MMC_RSP_NONE
CMD_SEND:1
ARG  0x
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:0
ARG  0x
MMC_RSP_NONE
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x003F8000 
CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0xC03F8000 
CMD_SEND:2
ARG  0x
MMC_RSP_R2   0x07FF 
 0x 
 0x 
 0x 

DUMPING DATA
000 - 07 FF FF FF 
004 - FF FF FF FF 
008 - FF FF FF FF 
012 - FF FF FF FF 
CMD_SEND:3
ARG  0x0001
RET  -110


So, as the last line says, I get Linux error code -110, which means
"Connection timed out".

Here is info about the card I am using:

Flash Info:
Manufacturer: SAMSUNG,value=00
Flash Size: 7457MB
Block Size: 512KB
Page Size: 2KB
ECC Bits: 0
Access Time: 40
Flash CS: Flash<0>

I have also tried with different SD cards on Rockchip MINI EVB RV1108 board, 
but I get the same error.

I get the same error with U-boot from Rockchip, and mainline U-boot from
Denx.

Any ideas?

Thanks,
Alex



--
Sent from: http://u-boot.10912.n7.nabble.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] rpi: Enable command bmp

2018-11-12 Thread Adam Heinrich
This patch enables the bmp command (with gzip support enabled) on all
Raspberry Pi boards.

The value of CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (required by
CONFIG_VIDEO_BMP_GZIP) is set to match resolution of the "official"
7 inch LCD.

Signed-off-by: Adam Heinrich 
Cc: Alexander Graf 
---
 configs/rpi_0_w_defconfig   | 1 +
 configs/rpi_2_defconfig | 1 +
 configs/rpi_3_32b_defconfig | 1 +
 configs/rpi_3_defconfig | 1 +
 configs/rpi_defconfig   | 1 +
 include/configs/rpi.h   | 7 +++
 6 files changed, 12 insertions(+)

diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
index d5bf01b76e..c809b12279 100644
--- a/configs/rpi_0_w_defconfig
+++ b/configs/rpi_0_w_defconfig
@@ -9,6 +9,7 @@ CONFIG_MISC_INIT_R=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_CMD_BMP=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
index a50a815759..1afc3470c4 100644
--- a/configs/rpi_2_defconfig
+++ b/configs/rpi_2_defconfig
@@ -9,6 +9,7 @@ CONFIG_MISC_INIT_R=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_CMD_BMP=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
index ec395d29ed..380fb81977 100644
--- a/configs/rpi_3_32b_defconfig
+++ b/configs/rpi_3_32b_defconfig
@@ -10,6 +10,7 @@ CONFIG_MISC_INIT_R=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_CMD_BMP=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig
index ac99f2000a..b3e7c20b76 100644
--- a/configs/rpi_3_defconfig
+++ b/configs/rpi_3_defconfig
@@ -10,6 +10,7 @@ CONFIG_MISC_INIT_R=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_CMD_BMP=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig
index db42ffd135..8eb8fda029 100644
--- a/configs/rpi_defconfig
+++ b/configs/rpi_defconfig
@@ -9,6 +9,7 @@ CONFIG_MISC_INIT_R=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_CMD_BMP=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index 37be6dbeeb..58defc0c2a 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -63,6 +63,13 @@
 #define CONFIG_LCD_DT_SIMPLEFB
 #define CONFIG_VIDEO_BCM2835

+#ifdef CONFIG_DM_VIDEO
+#define CONFIG_BMP_24BPP
+#define CONFIG_BMP_32BPP
+#define CONFIG_VIDEO_BMP_GZIP
+#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE  ((800 * 480 * 4) + 54)
+#endif
+
 #ifdef CONFIG_CMD_USB
 #define CONFIG_TFTP_TSIZE
 #endif
-- 
2.17.1

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


[U-Boot] [PULL] Please pull u-boot-imx: u-boot-imx-20181112

2018-11-12 Thread Stefano Babic
Hi Tom,

still a couple of fixes (colibri_vf could not be built):

The following changes since commit c5bbfaf05dc8592b479a44df6abaadbab54fec2b:

  imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO (2018-11-07 12:13:45 -0500)

are available in the Git repository at:

  git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20181112

for you to fetch changes up to 43e6f94cbcaf193aeedcf86e85a3ff4c79f66773:

  imx: mkimage: add size check to the u-boot.imx make target (2018-11-12
11:08:53 +0100)


Fix build vf boards + fix gpr_init()


Christoph Niedermaier (1):
  imx: imx6: perform gpr_init only on suitable cpu types

Marcel Ziswiler (4):
  board: toradex: colibri_vf: efi_loader: unset
CONFIG_EFI_UNICODE_CAPITALIZATION
  board: toradex: colibri_vf: unset CONFIG_CMDLINE_EDITING
  board: toradex: colibri_vf: drop SPI support
  imx: mkimage: add size check to the u-boot.imx make target

 arch/arm/mach-imx/Makefile   | 16 
 arch/arm/mach-imx/mx6/soc.c  |  8 
 configs/colibri_vf_defconfig |  6 ++
 3 files changed, 26 insertions(+), 4 deletions(-)

Best regards,
Stefano

-- 
=
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
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1 2/2] imx: mkimage: add size check to the u-boot.imx make target

2018-11-12 Thread Stefano Babic
On 09/11/18 15:35, Marcel Ziswiler wrote:
> Hi Stefano
> 
> On Thu, 2018-11-08 at 15:07 +0100, Stefano Babic wrote:
>> Hi Marcel,
>>
>> On 08/11/18 02:55, Fabio Estevam wrote:
>>> [Adding Stefano]
>>>
>>> On Wed, Nov 7, 2018 at 8:41 PM Marcel Ziswiler >>> wrote:

 From: Marcel Ziswiler 

 The make macro to check if the binary exceeds the board size
 limit is
 taken straight from the root Makefile.

 Without this and e.g. enabled EFI Vybrid fails booting as the
 regular
 size limit check does not take the final u-boot.imx binary size
 into
 account which is bigger due to alignment as well as IMX header
 stuff.

 Signed-off-by: Marcel Ziswiler 
>>>
>>> Reviewed-by: Fabio Estevam 
>>>
>>> Hi Stefano, maybe this could be material for 2018.11?
>>>
>>
>> Added both patches to u-boot-imx, check is effective, now size is too
>> much and build fails:
>>
>>
>> Building current source for 1 boards (1 thread, 8 jobs per thread)
>>arm:  +   colibri_vf
>> +u-boot.imx exceeds file size limit:
>> +  limit:  520192 bytes
>> +  actual: 526104 bytes
>> +  excess: 5912 bytes
>> +make[2]: *** [u-boot.imx] Error 1
>> +make[1]: *** [u-boot.imx] Error 2
>> +make: *** [sub-make] Error 2
>> 001 /1  colibri_vf
>>
>> Can you take a look ?
> 
> I sent a v2 additionally dropping CONFIG_CMDLINE_EDITING and SPI
> support saving another 8 Kb which for me makes it work right back to
> GCC 6.1.1 which I believe is anyway about as far back as one can go
> even compiling U-Boot. Can you please give that another go?

Merged the patchset, it works in my build. I will send PR to Tom.

Regards,
Stefano


-- 
=
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
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4 2/5] Use _AC and UL macros from linux/const.h

2018-11-12 Thread Daniel Schwierzeck
Am So., 11. Nov. 2018 um 11:33 Uhr schrieb Baruch Siach :
>
> Drop the _AC and UL macros from common.h. Linux headers is the original
> source of this macro, so keep its definition in the same header.
>
> Update existing users of these macros to include const.h directly.
>
> Cc: Daniel Schwierzeck 
> Cc: Rick Chen 
> Reviewed-by: Tom Rini 
> Reviewed-by: Rick Chen 
> Signed-off-by: Baruch Siach 
> ---
> v4: Squash the spaces.h change in to this commit
>
> v3: New patch in this series
> ---
>  arch/arm/include/asm/armv8/mmu.h| 2 ++
>  arch/mips/include/asm/mach-generic/spaces.h | 2 +-
>  arch/riscv/include/asm/csr.h| 2 ++
>  include/common.h| 9 -
>  4 files changed, 5 insertions(+), 10 deletions(-)
>

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


Re: [U-Boot] [PATCH v4 3/5] MIPS: drop asm/const.h

2018-11-12 Thread Daniel Schwierzeck
Am So., 11. Nov. 2018 um 11:33 Uhr schrieb Baruch Siach :
>
> Commit 86f21c96f467368 (mips: Use common _AC macro now.) removed the _AC
> definition from const.h. All other macros defined in const.h are not
> used anywhere, and there is now no user of this header. Remove this
> header.
>
> Cc: Daniel Schwierzeck 
> Signed-off-by: Baruch Siach 
> ---
> v4: Drop the spaces.h change from this patch
>
> v3: New patch in this series
> ---
>  arch/mips/include/asm/const.h | 27 ---
>  1 file changed, 27 deletions(-)
>  delete mode 100644 arch/mips/include/asm/const.h
>

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


Re: [U-Boot] [PATCH 2/2] odroid: Update README.odroid for support of Odroid HC1

2018-11-12 Thread Lukasz Majewski
On Mon, 12 Nov 2018 10:32:43 +
Anand Moon  wrote:

> updated READM.odroid for supported Odroid HC1 development board.
> 
> Signed-off-by: Anand Moon 
> ---
>  doc/README.odroid | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/README.odroid b/doc/README.odroid
> index c088ec4cb0..bc77ae3175 100644
> --- a/doc/README.odroid
> +++ b/doc/README.odroid
> @@ -1,11 +1,11 @@
> - U-Boot for Odroid X2/U3/XU3/XU4
> + U-Boot for Odroid X2/U3/XU3/XU4/HC1
>  
>  
>  1. Summary
>  ==
>  This is a quick instruction for setup Odroid boards.
>  Board config: odroid_config for X2/U3
> -Board config: odroid-xu3_config for XU3/XU4
> +Board config: odroid-xu3_config for XU3/XU4/HC1
>  
>  2. Supported devices
>  
> @@ -15,6 +15,7 @@ This U-BOOT config can be used on three boards:
>  with CPU Exynos 4412 rev 2.0 and 2GB of RAM
>  - Odroid XU3
>  - Odroid XU4
> +- Odroid HC1
>  with CPU Exynos5422 and 2GB of RAM
>  
>  3. Boot sequence
> @@ -121,7 +122,9 @@ Supported fdt files are:
>  - exynos4412-odroidx2.dtb
>  - exynos4412-odroidu3.dtb
>  - exynos5422-odroidxu3.dtb
> +- exynos5422-odroidxu3-lite.dtb
>  - exynos5422-odroidxu4.dtb
> +- exynos5422-odroidhc1.dtb
>  
>  Supported kernel files are:
>  - Image.itb

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpA8TfkoU9b5.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] exynos5-dt-types: add missing dtb file for Odroid HC1/HC2

2018-11-12 Thread Lukasz Majewski
On Mon, 12 Nov 2018 10:32:42 +
Anand Moon  wrote:

> Add missing exynos5422-odroidhc1.dtb needed to set for dfu env.
> 
> Signed-off-by: Anand Moon 
> ---
>  include/configs/odroid_xu3.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/odroid_xu3.h
> b/include/configs/odroid_xu3.h index f683ee46e3..b44f58ed15 100644
> --- a/include/configs/odroid_xu3.h
> +++ b/include/configs/odroid_xu3.h
> @@ -61,6 +61,7 @@
>   "exynos5422-odroidxu3.dtb fat 0 1;" \
>   "exynos5422-odroidxu3-lite.dtb fat 0 1;" \
>   "exynos5422-odroidxu4.dtb fat 0 1;" \
> + "exynos5422-odroidhc1.dtb fat 0 1;" \
>   "boot part 0 1;"\
>   "root part 0 2\0"
>  

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpaSsTjr3Zli.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 4/5] cmd: ubi: Remove useless call to mtdparts_init()

2018-11-12 Thread Lukasz Majewski
On Mon, 12 Nov 2018 09:28:08 +0100
Boris Brezillon  wrote:

> Commit c58fb2cdb3e4 ("cmd: ubi: clean the partition handling")
> introduced a call to mtd_probe_devices() in the ubi_attach() path
> and this function takes care of parsing mtdparts/mtdids and
> creating/registering the associated mtd partitions.
> 
> The mtdparts_init() call in the ubi_detach() path is not only
> unnecessary but can sometimes print error messages even when things
> work properly (that's the case with SPI NAND devices that have not
> been probed with 'mtd list'), which is misleading.
> 
> Remove this call to mtdparts_init() and drop the dependency on
> CMD_MTDPARTS.
> 
> Fixes: c58fb2cdb3e4 ("cmd: ubi: clean the partition handling")
> Reported-by: Stefan Roese 
> Signed-off-by: Boris Brezillon 
> Tested-by: Stefan Roese 
> ---
> Changes in v2:
> - Moved after the patches reworking the Kconfig deps
> ---
>  cmd/Kconfig | 1 -
>  cmd/ubi.c   | 5 -
>  2 files changed, 6 deletions(-)
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 9310a8bdb2b7..ad14c9ce7124 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1856,7 +1856,6 @@ endmenu
>  
>  config CMD_UBI
>   tristate "Enable UBI - Unsorted block images commands"
> - select CMD_MTDPARTS
>   select CRC32
>   select MTD_UBI
>   help
> diff --git a/cmd/ubi.c b/cmd/ubi.c
> index 767a4a453640..2b74a9814463 100644
> --- a/cmd/ubi.c
> +++ b/cmd/ubi.c
> @@ -417,11 +417,6 @@ static int ubi_dev_scan(struct mtd_info *info,
> const char *vid_header_offset) 
>  int ubi_detach(void)
>  {
> - if (mtdparts_init() != 0) {
> - printf("Error initializing mtdparts!\n");
> - return 1;
> - }
> -
>  #ifdef CONFIG_CMD_UBIFS
>   /*
>* Automatically unmount UBIFS partition when user

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpL6XEp5ocgg.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 5/5] mtd: Drop duplicate MTD_PARTITIONS Kconfig option

2018-11-12 Thread Lukasz Majewski
On Mon, 12 Nov 2018 09:28:09 +0100
Boris Brezillon  wrote:

> Commit 9c5b00973bce ("Convert CONFIG_MTD_PARTITIONS et al to Kconfig")
> introduced a publicly visible Kconfig entry for the
> CONFIG_MTD_PARTITIONS option, while the rework on MTD partitioning
> was in progress, and we somehow did not notice that the same Kconfig
> entry was added by commit 4048a5c519a8 ("mtd: declare MTD_PARTITIONS
> symbol in Kconfig"), but this time as an invisible entry (this can
> only be selected by other options).
> 
> Keep the non-visible version of this symbol, since MTD_PARTITIONS is
> not something the user should be able to enable/disable directly.
> 
> Fixes: 4048a5c519a8 ("mtd: declare MTD_PARTITIONS symbol in Kconfig")
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v2:
> - Moved after the patches reworking the Kconfig deps
> ---
>  drivers/mtd/Kconfig | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index 11cf12bb5599..0050fb2b9bf1 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -22,12 +22,6 @@ config MTD_DEVICE
> Adds the MTD device infrastructure from the Linux kernel.
> Needed for mtdparts command support.
>  
> -config MTD_PARTITIONS
> - bool "Add MTD Partioning infrastructure"
> - help
> -   Adds the MTD partitioning infrastructure from the Linux
> -   kernel. Needed for UBI support.
> -
>  config FLASH_CFI_DRIVER
>   bool "Enable CFI Flash driver"
>   help


Reviewed-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpwcrv1XOOOh.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/5] mtd: Make {MTDIDS, MTDPARTS}_DEFAULT visible when MTD_PARTITIONS is selected

2018-11-12 Thread Lukasz Majewski
On Mon, 12 Nov 2018 09:28:07 +0100
Boris Brezillon  wrote:

> gwventana configs are relying on CMD_UBI to select CMD_MTDPARTS,
> which is then making {MTDIDS,MTDPARTS}_DEFAULT options available.
> 
> We are about to remove the 'select CMD_MTDPARTS' statement in the
> CMD_UBI entry, but if we do that without first making sure
> {MTDIDS,MTDPARTS}_DEFAULT are visible, we end up with a build
> failure when building gwventana configs.
> 
> Address that by adding a depends on MTD_PARTITIONS to
> {MTDIDS,MTDPARTS}_DEFAULT which does the trick since CMD_UBI selects
> MTD_UBI which in turn selects MTD_PARTITIONS.
> 
> We also get rid of the depends on CMD_MTD, since CMD_MTD also selects
> MTD_PARTITIONS.
> 
> Reported-by: Jagan Teki 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v2:
> - Moved ealier in the series to avoid introducing a build failure
> ---
>  cmd/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index d66f710ad0f8..9310a8bdb2b7 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1728,14 +1728,14 @@ config CMD_MTDPARTS
>  
>  config MTDIDS_DEFAULT
>   string "Default MTD IDs"
> - depends on CMD_MTD || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> + depends on MTD_PARTITIONS || CMD_MTDPARTS || CMD_NAND ||
> CMD_FLASH help
> Defines a default MTD IDs list for use with MTD partitions
> in the Linux MTD command line partitions format.
>  
>  config MTDPARTS_DEFAULT
>   string "Default MTD partition scheme"
> - depends on CMD_MTD || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> + depends on MTD_PARTITIONS || CMD_MTDPARTS || CMD_NAND ||
> CMD_FLASH help
> Defines a default MTD partitioning scheme in the Linux MTD
> command line partitions format

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgp0ZBcFgsXzX.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/5] mtd: Use default mtdparts/mtids when not defined in the environment

2018-11-12 Thread Miquel Raynal
Hi Jagan,

Jagan Teki  wrote on Mon, 12 Nov 2018
15:39:20 +0530:

> On Mon, Nov 12, 2018 at 2:54 PM Miquel Raynal  
> wrote:
> >
> > Hi Boris, Tom,
> >
> > Boris Brezillon  wrote on Mon, 12 Nov 2018
> > 09:28:05 +0100:
> >  
> > > U-boot provides a mean to define default values for mtdids and mtdparts
> > > when they're not defined in the environment. Patch mtd_probe_devices()
> > > to use those default values when env_get("mtdparts") or
> > > env_get("mtdids") return NULL.
> > >
> > > This implementation is based on the logic found in cmd/mtdparts.c.
> > >
> > > Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command")
> > > Reported-by: Stefan Roese 
> > > Signed-off-by: Boris Brezillon 
> > > Tested-by: Stefan Roese 
> > > ---  
> >
> > For the whole series:
> >
> > Reviewed-by: Miquel Raynal 
> >
> > This should be (if possible) in 2018.11, otherwise the release will be
> > buggy with certain configurations. Maybe we should sometimes send PR
> > directly to Tom as MTD is orphaned to avoid latencies between
> > developers/maintainers and reach mainline quickly (at least for the
> > fixes)?  
> 
> ie one of the reason I requesting travis-ci build before sending the
> generic changes.

Yes, we should have run a CI test first. I am not complaining at all
about the time between having the series posted and you testing it. I
understand this delay and really, I can't blame you for that. I'm just
saying that this is the second time we (almost?) miss a release because
of the additional delays between us, which are, IMHO, not really needed
while there is no actual code review as long as we do run Travis.


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


Re: [U-Boot] [PATCH v2 2/5] dfu: nand: Add missing dependency on CMD_MTDPARTS

2018-11-12 Thread Lukasz Majewski
Hi Boris,

> dfu_fill_entity_nand() uses find_dev_and_part() and mtdparts_init()
> which are provided by cmd/mtdparts.c.
> 
> Add the dependency to avoid build failures when CMD_MTDPARTS is not
> selected.
> 
> Reported-by: Jagan Teki 
> Fixes: 6828e602b722d ("dfu: Migrate to Kconfig")
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v2:
> - Moved ealier in the series to avoid introducing a build failure
> ---
>  drivers/dfu/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig
> index 51ab484c2a49..4692736c9d24 100644
> --- a/drivers/dfu/Kconfig
> +++ b/drivers/dfu/Kconfig
> @@ -30,6 +30,7 @@ config DFU_MMC
>  
>  config DFU_NAND
>   bool "NAND back end for DFU"
> + depends on CMD_MTDPARTS
>   help
> This option enables using DFU to read and write to NAND
> based storage.


Acked-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpx60_KLnSbq.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/5] mtd: Use default mtdparts/mtids when not defined in the environment

2018-11-12 Thread Lukasz Majewski
Hi Boris,

> U-boot provides a mean to define default values for mtdids and
> mtdparts when they're not defined in the environment. Patch
> mtd_probe_devices() to use those default values when
> env_get("mtdparts") or env_get("mtdids") return NULL.
> 
> This implementation is based on the logic found in cmd/mtdparts.c.
> 
> Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command")
> Reported-by: Stefan Roese 
> Signed-off-by: Boris Brezillon 
> Tested-by: Stefan Roese 
> ---
> Changes in v2:
> - none
> ---
>  drivers/mtd/mtd_uboot.c | 62
> +++-- 1 file changed, 60
> insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/mtd_uboot.c b/drivers/mtd/mtd_uboot.c
> index 7d7a11c990d6..1d0a505754f2 100644
> --- a/drivers/mtd/mtd_uboot.c
> +++ b/drivers/mtd/mtd_uboot.c
> @@ -92,12 +92,70 @@ static void mtd_probe_uclass_mtd_devs(void) { }
>  #endif
>  
>  #if defined(CONFIG_MTD_PARTITIONS)
> +extern void board_mtdparts_default(const char **mtdids,
> +const char **mtdparts);
> +
> +static const char *get_mtdids(void)
> +{
> + __maybe_unused const char *mtdparts = NULL;
> + const char *mtdids = env_get("mtdids");
> +
> + if (mtdids)
> + return mtdids;
> +
> +#if defined(CONFIG_SYS_MTDPARTS_RUNTIME)
> + board_mtdparts_default(, );
> +#elif defined(MTDIDS_DEFAULT)
> + mtdids = MTDIDS_DEFAULT;
> +#elif defined(CONFIG_MTDIDS_DEFAULT)
> + mtdids = CONFIG_MTDIDS_DEFAULT;
> +#endif
> +
> + if (mtdids)
> + env_set("mtdids", mtdids);
> +
> + return mtdids;
> +}
> +
> +#define MTDPARTS_MAXLEN 512
> +
> +static const char *get_mtdparts(void)
> +{
> + __maybe_unused const char *mtdids = NULL;
> + static char tmp_parts[MTDPARTS_MAXLEN];
> + static bool use_defaults = true;
> + const char *mtdparts = NULL;
> +
> + if (gd->flags & GD_FLG_ENV_READY)
> + mtdparts = env_get("mtdparts");
> + else if (env_get_f("mtdparts", tmp_parts,
> sizeof(tmp_parts) != -1))
> + mtdparts = tmp_parts;
> +
> + if (mtdparts || !use_defaults)
> + return mtdparts;
> +
> +#if defined(CONFIG_SYS_MTDPARTS_RUNTIME)
> + board_mtdparts_default(, );
> +#elif defined(MTDPARTS_DEFAULT)
> + mtdparts = MTDPARTS_DEFAULT;
> +#elif defined(CONFIG_MTDPARTS_DEFAULT)
> + mtdparts = CONFIG_MTDPARTS_DEFAULT;
> +#endif
> +
> + if (mtdparts)
> + env_set("mtdparts", mtdparts);
> +
> + use_defaults = false;
> +
> + return mtdparts;
> +}
> +
>  int mtd_probe_devices(void)
>  {
>   static char *old_mtdparts;
>   static char *old_mtdids;
> - const char *mtdparts = env_get("mtdparts");
> - const char *mtdids = env_get("mtdids");
> + const char *mtdparts = get_mtdparts();
> + const char *mtdids = get_mtdids();
>   bool remaining_partitions = true;
>   struct mtd_info *mtd;
>  

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpCsw9uVB2bw.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/2] odroid: Update README.odroid for support of Odroid HC1

2018-11-12 Thread Anand Moon
updated READM.odroid for supported Odroid HC1 development board.

Signed-off-by: Anand Moon 
---
 doc/README.odroid | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/doc/README.odroid b/doc/README.odroid
index c088ec4cb0..bc77ae3175 100644
--- a/doc/README.odroid
+++ b/doc/README.odroid
@@ -1,11 +1,11 @@
- U-Boot for Odroid X2/U3/XU3/XU4
+ U-Boot for Odroid X2/U3/XU3/XU4/HC1
 
 
 1. Summary
 ==
 This is a quick instruction for setup Odroid boards.
 Board config: odroid_config for X2/U3
-Board config: odroid-xu3_config for XU3/XU4
+Board config: odroid-xu3_config for XU3/XU4/HC1
 
 2. Supported devices
 
@@ -15,6 +15,7 @@ This U-BOOT config can be used on three boards:
 with CPU Exynos 4412 rev 2.0 and 2GB of RAM
 - Odroid XU3
 - Odroid XU4
+- Odroid HC1
 with CPU Exynos5422 and 2GB of RAM
 
 3. Boot sequence
@@ -121,7 +122,9 @@ Supported fdt files are:
 - exynos4412-odroidx2.dtb
 - exynos4412-odroidu3.dtb
 - exynos5422-odroidxu3.dtb
+- exynos5422-odroidxu3-lite.dtb
 - exynos5422-odroidxu4.dtb
+- exynos5422-odroidhc1.dtb
 
 Supported kernel files are:
 - Image.itb
-- 
2.19.1

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


[U-Boot] [PATCH 1/2] exynos5-dt-types: add missing dtb file for Odroid HC1/HC2

2018-11-12 Thread Anand Moon
Add missing exynos5422-odroidhc1.dtb needed to set for dfu env.

Signed-off-by: Anand Moon 
---
 include/configs/odroid_xu3.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/odroid_xu3.h b/include/configs/odroid_xu3.h
index f683ee46e3..b44f58ed15 100644
--- a/include/configs/odroid_xu3.h
+++ b/include/configs/odroid_xu3.h
@@ -61,6 +61,7 @@
"exynos5422-odroidxu3.dtb fat 0 1;" \
"exynos5422-odroidxu3-lite.dtb fat 0 1;" \
"exynos5422-odroidxu4.dtb fat 0 1;" \
+   "exynos5422-odroidhc1.dtb fat 0 1;" \
"boot part 0 1;"\
"root part 0 2\0"
 
-- 
2.19.1

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


Re: [U-Boot] [PATCH v2 1/5] mtd: Use default mtdparts/mtids when not defined in the environment

2018-11-12 Thread Jagan Teki
On Mon, Nov 12, 2018 at 1:58 PM Boris Brezillon
 wrote:
>
> U-boot provides a mean to define default values for mtdids and mtdparts
> when they're not defined in the environment. Patch mtd_probe_devices()
> to use those default values when env_get("mtdparts") or
> env_get("mtdids") return NULL.
>
> This implementation is based on the logic found in cmd/mtdparts.c.
>
> Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command")
> Reported-by: Stefan Roese 
> Signed-off-by: Boris Brezillon 
> Tested-by: Stefan Roese 
> ---
> Changes in v2:
> - none

Trigger travis-ci [1], will send v2 PR once all built fine.

[1] https://travis-ci.org/openedev/u-boot-amarula/builds
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/5] mtd: Use default mtdparts/mtids when not defined in the environment

2018-11-12 Thread Jagan Teki
On Mon, Nov 12, 2018 at 2:54 PM Miquel Raynal  wrote:
>
> Hi Boris, Tom,
>
> Boris Brezillon  wrote on Mon, 12 Nov 2018
> 09:28:05 +0100:
>
> > U-boot provides a mean to define default values for mtdids and mtdparts
> > when they're not defined in the environment. Patch mtd_probe_devices()
> > to use those default values when env_get("mtdparts") or
> > env_get("mtdids") return NULL.
> >
> > This implementation is based on the logic found in cmd/mtdparts.c.
> >
> > Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command")
> > Reported-by: Stefan Roese 
> > Signed-off-by: Boris Brezillon 
> > Tested-by: Stefan Roese 
> > ---
>
> For the whole series:
>
> Reviewed-by: Miquel Raynal 
>
> This should be (if possible) in 2018.11, otherwise the release will be
> buggy with certain configurations. Maybe we should sometimes send PR
> directly to Tom as MTD is orphaned to avoid latencies between
> developers/maintainers and reach mainline quickly (at least for the
> fixes)?

ie one of the reason I requesting travis-ci build before sending the
generic changes.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] qemu-arm: Enable VirtIO distro target

2018-11-12 Thread Sumit Garg
With -device virtio-blk-device,drive=hd0, it could detect distro boot
target.

Signed-off-by: Sumit Garg 
---

Depends on https://patchwork.ozlabs.org/patch/995524/ which adds VirtIO
distro boot command.

 include/configs/qemu-arm.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index fedc466..437c3ae 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -25,7 +25,8 @@
 
 #define BOOT_TARGET_DEVICES(func) \
func(SCSI, scsi, 0) \
-   func(DHCP, dhcp, na)
+   func(DHCP, dhcp, na) \
+   func(VIRTIO, virtio, 0)
 
 #include 
 
-- 
2.7.4

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


Re: [U-Boot] [PATCH v2 1/5] mtd: Use default mtdparts/mtids when not defined in the environment

2018-11-12 Thread Miquel Raynal
Hi Boris, Tom,

Boris Brezillon  wrote on Mon, 12 Nov 2018
09:28:05 +0100:

> U-boot provides a mean to define default values for mtdids and mtdparts
> when they're not defined in the environment. Patch mtd_probe_devices()
> to use those default values when env_get("mtdparts") or
> env_get("mtdids") return NULL.
> 
> This implementation is based on the logic found in cmd/mtdparts.c.
> 
> Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command")
> Reported-by: Stefan Roese 
> Signed-off-by: Boris Brezillon 
> Tested-by: Stefan Roese 
> ---

For the whole series:

Reviewed-by: Miquel Raynal 

This should be (if possible) in 2018.11, otherwise the release will be
buggy with certain configurations. Maybe we should sometimes send PR
directly to Tom as MTD is orphaned to avoid latencies between
developers/maintainers and reach mainline quickly (at least for the
fixes)?

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


Re: [U-Boot] [PATCH 1/2] dfu: nand: Add missing dependency on CMD_MTDPARTS

2018-11-12 Thread Boris Brezillon
On Mon, 12 Nov 2018 12:41:15 +0530
Jagan Teki  wrote:

> On Mon, Nov 12, 2018 at 12:15 PM Boris Brezillon
>  wrote:
> >
> > Hi Jagan,
> >
> > On Mon, 12 Nov 2018 10:13:40 +0530
> > Jagan Teki  wrote:
> >  
> > > On Sat, Nov 10, 2018 at 4:52 PM Boris Brezillon
> > >  wrote:  
> > > >
> > > > dfu_fill_entity_nand() uses find_dev_and_part() and mtdparts_init()
> > > > which are provided by cmd/mtdparts.c.
> > > >
> > > > Add the dependency to avoid build failures when CMD_MTDPARTS is not
> > > > selected.
> > > >
> > > > Reported-by: Jagan Teki 
> > > > Fixes: 6828e602b722d ("dfu: Migrate to Kconfig")
> > > > Signed-off-by: Boris Brezillon 
> > > > ---
> > > >  drivers/dfu/Kconfig | 1 +
> > > >  1 file changed, 1 insertion(+)  
> > >
> > > Squashed both patches into "cmd: ubi: Remove useless call to
> > > mtdparts_init()" patch.  
> >
> > Sorry to complain again, but I don't think this was the right thing to
> > do. Those 2 patches are unrelated to "cmd: ubi: Remove useless call to  
> > ->mtdparts_init()", it's just that this commit uncovers problems in the  
> > dependency definition of the DFU_NAND and MTD{PARTS,IDS}_DEFAULT
> > options.
> >
> > If you want to keep things bisectable, it would be preferable to
> > move those 2 commits before "cmd: ubi: Remove useless call to  
> > ->mtdparts_init()" (and rework the commit messages accordingly).  
> 
> I was concentrated to move this on the release, anyway please send the
> series again will push it during MW.

Is it too late to queue it for the current release (I see v2018.11 has
not been tagged yet)?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 5/5] mtd: Drop duplicate MTD_PARTITIONS Kconfig option

2018-11-12 Thread Boris Brezillon
Commit 9c5b00973bce ("Convert CONFIG_MTD_PARTITIONS et al to Kconfig")
introduced a publicly visible Kconfig entry for the
CONFIG_MTD_PARTITIONS option, while the rework on MTD partitioning
was in progress, and we somehow did not notice that the same Kconfig
entry was added by commit 4048a5c519a8 ("mtd: declare MTD_PARTITIONS
symbol in Kconfig"), but this time as an invisible entry (this can
only be selected by other options).

Keep the non-visible version of this symbol, since MTD_PARTITIONS is
not something the user should be able to enable/disable directly.

Fixes: 4048a5c519a8 ("mtd: declare MTD_PARTITIONS symbol in Kconfig")
Signed-off-by: Boris Brezillon 
---
Changes in v2:
- Moved after the patches reworking the Kconfig deps
---
 drivers/mtd/Kconfig | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 11cf12bb5599..0050fb2b9bf1 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -22,12 +22,6 @@ config MTD_DEVICE
  Adds the MTD device infrastructure from the Linux kernel.
  Needed for mtdparts command support.
 
-config MTD_PARTITIONS
-   bool "Add MTD Partioning infrastructure"
-   help
- Adds the MTD partitioning infrastructure from the Linux
- kernel. Needed for UBI support.
-
 config FLASH_CFI_DRIVER
bool "Enable CFI Flash driver"
help
-- 
2.17.1

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


  1   2   >