Re: [U-Boot] [PATCHv2] da850: Add instructions to copy AIS image to NAND

2017-03-19 Thread Sekhar Nori
Hi Axel,

On Friday 17 March 2017 09:25 PM, Axel Haslam wrote:
> Add instructions to write an AIS image to NAND
> by using the u-boot nand tools.
> 
> Signed-off-by: Axel Haslam 
> ---
> Changes in V2:
> - add erase command before write
> - Add write info when MTD partitions are defined
> 
>  board/davinci/da8xxevm/README.da850 | 41 
> +
>  1 file changed, 41 insertions(+)
> 
> diff --git a/board/davinci/da8xxevm/README.da850 
> b/board/davinci/da8xxevm/README.da850
> index 29cb4ec..519267e 100644
> --- a/board/davinci/da8xxevm/README.da850
> +++ b/board/davinci/da8xxevm/README.da850
> @@ -47,6 +47,47 @@ U-Boot > sf erase 0 +32
>  U-Boot > tftp u-boot.ais
>  U-Boot > sf write c070 0 $filesize
>  
> +Flashing the images to NAND
> +===
> +The AIS image can be written to NAND using the u-boot "nand" commands.
> +
> +Example:
> +
> +OMAPL138_LCDK requires the AIS image to be written to the second block of
> +the NAND flash.
> +
> +From the "nand info" command we see that the second block would start at
> +offset 0x2:
> +
> +  U-Boot > nand info
> +  sector size  128 KiB (0x2)
> +  Page size   2048 b
> +
> +From the tftp command we see that we need to copy 0x74908 bytes from
> +memory address 0xc070 (0x75000 if we align a page of 2048):
> +
> +  U-Boot > tftp u-boot.ais
> +  Load address: 0xc070
> +  Bytes transferred = 477448 (74908 hex)
> +
> +The commands to write the image from memory to NAND would be:
> +
> +  U-Boot > nand erase 0x2 0x75000
> +  U-Boot > nand write 0xc070 0x2 0x75000
> +
> +Alternatively, MTD partitions may be defined. Using "mtdparts" to
> +conveniently have a bootloader partition starting at the second block
> +(offset 0x2):
> +
> +  setenv mtdids nand0=davinci_nand.0
> +  setenv mtdparts mtdparts=davinci_nand.0:128k(bootenv),2m(bootloader)
> +
> +In this case the commands would be simplified to:
> +
> +  U-Boot > tftp u-boot.ais
> +  U-Boot > nand erase.part bootloader
> +  U-Boot > nand write 0xc070 bootloader

Looks good to me now.

Perhaps the mtdparts setting above can be part of the default
environment itself ? So the additional step of setting them up can be
avoided. But that will be a separate patch.

Thanks,
Sekhar

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


Re: [U-Boot] [PATCH v4 1/2] spl: Add spl_early_init()

2017-03-19 Thread Lokesh Vutla
Hi Simon,

On Wednesday 15 March 2017 08:13 PM, Simon Glass wrote:
> From: Eddie Cai 
> 
> At present malloc_base/_limit/_ptr are not initialised in spl_init() when
> we call spl_init() in board_init_f(). This is due to a recent change aimed
> at avoiding overwriting the malloc area set up on some boards by
> spl_relocate_stack_gd().
> 
> However if CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN is not defined, we now
> skip setting up the memory area in spl_init() which is obviously wrong.
> 
> To fix this, add a new function spl_early_init() which can be called in
> board_init_f().
> 
> Fixes: b3d2861e (spl: Remove overwrite of relocated malloc limit)
> Signed-off-by: Eddie Cai 
> Rewrote spl_{,early_}init() to avoid duplicate code:
> Rewrite/expand commit message:
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Rewrote spl_{,early_}init() to avoid duplicate code
> - Rewrite commit message
> 
>  common/spl/spl.c  | 46 
> +--
>  include/asm-generic/global_data.h |  1 +
>  include/spl.h | 24 +---
>  3 files changed, 57 insertions(+), 14 deletions(-)
> 
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 766fb3d6f4..2bc8b42027 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -170,22 +170,20 @@ __weak void __noreturn jump_to_image_no_args(struct 
> spl_image_info *spl_image)
>   image_entry();
>  }
>  
> -int spl_init(void)
> +static int spl_common_init(bool setup_malloc)
>  {
>   int ret;
>  
> - debug("spl_init()\n");
> -/*
> - * with CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN we set malloc_base and
> - * malloc_limit in spl_relocate_stack_gd
> - */
> -#if defined(CONFIG_SYS_MALLOC_F_LEN) && \
> - !defined(CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN)
> + debug("spl_early_init()\n");
> +
> +#if defined(CONFIG_SYS_MALLOC_F_LEN)
> + if (setup_malloc) {
>  #ifdef CONFIG_MALLOC_F_ADDR
> - gd->malloc_base = CONFIG_MALLOC_F_ADDR;
> + gd->malloc_base = CONFIG_MALLOC_F_ADDR;
>  #endif
> - gd->malloc_limit = CONFIG_SYS_MALLOC_F_LEN;
> - gd->malloc_ptr = 0;
> + gd->malloc_limit = CONFIG_SYS_MALLOC_F_LEN;
> + gd->malloc_ptr = 0;
> + }
>  #endif
>   if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)) {
>   ret = fdtdec_setup();
> @@ -202,6 +200,32 @@ int spl_init(void)
>   return ret;
>   }
>   }
> +
> + return 0;
> +}
> +
> +int spl_early_init(void)
> +{
> + int ret;
> +
> + ret = spl_common_init(true);
> + if (ret)
> + return ret;
> + gd->flags |= GD_FLG_SPL_EARLY_INIT;
> +
> + return 0;
> +}
> +
> +int spl_init(void)
> +{
> + int ret;
> +
> + if (!(gd->flags & GD_FLG_SPL_EARLY_INIT)) {
> + ret = spl_common_init(
> + !IS_ENABLED(CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN));

IS_ENABLED(CONFIG defined as hex) is always false. So this will always
return true and overriding the malloc_limit, which is causing boot
failures on DRA7xx based boards.:wq

Thanks and regards,
Lokesh

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


Re: [U-Boot] [PATCH] libfdt: use CONFIG_IS_ENABLED for OF_LIBFDT

2017-03-19 Thread Vignesh R


On Saturday 18 March 2017 12:16 AM, Simon Glass wrote:
> Hi,
> 
> On 13 February 2017 at 01:08, Lokesh Vutla  wrote:
>>
>>
>> On Monday 13 February 2017 01:04 PM, Vignesh R wrote:
>>> Use CONFIG_IS_ENABLED() macro to check whether OF_LIBFDT is enabled, so
>>> that code block is compiled irrespective of SPL or U-Boot build
>>> depending on CONFIG_SPL_OF_LIBFDT(for SPL) or CONFIG_OF_LIBFDT(for
>>> U-Boot).
>>>
>>> Signed-off-by: Vignesh R 
>>
>> Reviewed-by: Lokesh Vutla 
>>
>> Thanks and regards,
>> Lokesh
> 
> Unfortunately this breaks boards which use SPL and OF_CONTROL:
> 
> 06: dtoc: make ScanTree recurse into subnodes
>aarch64:  +   xilinx_zynqmp_zc1751_xm018_dc4 xilinx_zynqmp_zcu102
> xilinx_zynqmp_zc1751_xm015_dc1 xilinx_zynqmp_zc1751_xm019_dc5
> xilinx_zynqmp_zc1751_xm016_dc2 xilinx_zynqmp_ep
> xilinx_zynqmp_zcu102_revB
>arm:  +   socfpga_de0_nano_soc uniphier_pro4 uniphier_ld4_sld8
> zynq_zc770_xm010 zynq_zc770_xm012 zynq_zc706 evb-rk3288 socfpga_arria5
> zynq_zybo rock2 socfpga_socrates uniphier_sld3 zynq_microzed
> socfpga_sr1500 tinker-rk3288 zynq_zed socfpga_de1_soc firefly-rk3288
> sama5d2_xplained_spiflash topic_miami sama5d2_xplained_mmc
> socfpga_sockit zynq_zc702 socfpga_is1 zynq_picozed fennec-rk3288
> zynq_zc770_xm011 zynq_zc770_xm013 popmetal-rk3288 socfpga_mcvevk
> topic_miamiplus socfpga_cyclone5 socfpga_vining_fpga
> uniphier_pxs2_ld6b
> microblaze:  +   microblaze-generic
>x86:  +   qemu-x86_64 chromebook_link64
> +lib/built-in.o: In function `fdtdec_get_addr_size_fixed':
> +build/../lib/fdtdec.c:117: undefined reference to `fdt_translate_address'
> +make[2]: *** [spl/u-boot-spl] Error 1
> +make[1]: *** [spl/u-boot-spl] Error 2
> +build/../lib/fdtdec.
> 
> You can move the position of fdt_support.o in common/Makefile to fix this.
> 
> It also bloats SPL on many boards which currently don't need address
> translation. For example firefly-rk3288 goes from ~20KB to ~26KB.
> 
> Can you add an option to enable address translation in SPL perhaps?

Yes, there is OF_TRANSLATE. I have posted v2 with the changes:
https://patchwork.ozlabs.org/patch/740789/

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


[U-Boot] [PATCH v2] libfdt: use CONFIG_IS_ENABLED for OF_LIBFDT

2017-03-19 Thread Vignesh R
Use CONFIG_IS_ENABLED() macro to check whether OF_TRANSLATE is enabled, so
that code block is compiled irrespective of SPL or U-Boot build
and fdt address translation is used.

Signed-off-by: Vignesh R 
---

v2:
* Depend on OF_TRANSLATE instead of OF_LIBFDT so that boards like
  chromebook_link64_defconfig compile fine.

 lib/fdtdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 81f47ef2c7f4..1edfbf2d3921 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -112,7 +112,7 @@ fdt_addr_t fdtdec_get_addr_size_fixed(const void *blob, int 
node,
return FDT_ADDR_T_NONE;
}
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_OF_LIBFDT)
+#if CONFIG_IS_ENABLED(OF_TRANSLATE)
if (translate)
addr = fdt_translate_address(blob, node, prop_addr);
else
-- 
2.11.0

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


Re: [U-Boot] Linker error when using CONFIG_SPL_SYS_MALLOC_SIMPLE=y

2017-03-19 Thread Lokesh Vutla


On Saturday 18 March 2017 12:03 AM, Dan Murphy wrote:
> Simon
> 
> On 03/17/2017 01:24 PM, Simon Glass wrote:
>> +ML
>>
>> Hi Dan,
>>
>> On 17 March 2017 at 12:16, Dan Murphy  wrote:
>>> Simon
>>>
>>> I wanted to drop you a note to see if you have any advice on how to fix 
>>> this issue.
>>>
>>> In the attached .config file we enable
>>>
>>> CONFIG_SPL_SYS_MALLOC_SIMPLE and CONFIG_SPL_DFU_SUPPORT which we need 
>>> CONFIG_SPL_DFU_RAM
>>>
>>> When doing this we find that there is a build error
>>>
>>> common/built-in.o: In function `xrealloc':
>>> common/cli_hush.c:3349: undefined reference to `realloc_simple'
>>> common/built-in.o: In function `done_word':
>>> common/cli_hush.c:2494: undefined reference to `realloc_simple'
>>> cli_hush.c:2499: undefined reference to `realloc_simple'
>>> common/built-in.o: In function `b_check_space':
>>> common/cli_hush.c:876: undefined reference to `realloc_simple'
>>> make[1]: *** [spl/u-boot-spl] Error 1
>>> make: *** [spl/u-boot-spl] Error 2
>>>
>>> In digging into this I am finding that realloc_simple is not defined 
>>> anywhere in uboot.  malloc_simple.c seems
>>> to be missing the implementation.
>>>
>>> I am looking to see if you have a patch that fixes this issue or if you can 
>>> guide us to a resolution.
>>>
>>> Right now our only work around is to disable the HUSH_PARSER or turn off 
>>> the MALLOC simple.  Which according to
>>> Lokesh, CC'd, is needed for DM support.
>> So SPL is using hush? Is there a description somewhere of what it does
>> with that?
> 
> HUSH_PARSER was added to the TI config in commit adad96e60 configs: Re-sync 
> HUSH options.
> 
> HUSH calls realloc in the builtin functions.  I am not sure what SPL would do 
> with the HUSH.
> 
>> If you have enough space for hush I wonder whether you can just use
>> full malloc() in SPL? You could implement realloc_simple() by just
>> calling malloc_simple() and copying the old data over, but it is
>> inefficient.
> We could work around it but the undef reference will still exist for other 
> code that would need realloc.
> 
> Lokesh
> 
> Do we run out of room using full malloc support in the SPL with the DM code 
> added?

No, we should be able to use full malloc support in SPL in case of
DRA7xx/AM57xx. But it is unnecessary overhead ti size of SPL. I still
did not understand why HUSH_PARSER is needed for SPL.

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


Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power

2017-03-19 Thread Simon Glass
Hi Andy,

On 15 March 2017 at 12:25, Andy Shevchenko
 wrote:
> On some systems SDHCI controllers may be powered off and it's required
> to bring them on before accessing.
>
> SDHCI generic driver currently lacks any mean of doing it. Call the same
> board_power_mmc_init() at sdhci_init() stage.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mmc/sdhci.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 93cefd89cd..54a7e379ff 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -469,6 +469,8 @@ static int sdhci_init(struct mmc *mmc)
>  {
> struct sdhci_host *host = mmc->priv;
>
> +   board_mmc_power_init();

You should be using driver model for this (CONFIG_DM_MMC*). So either
get the power supply from the device tree and enable it, or do this in
the board code.

> +
> sdhci_reset(host, SDHCI_RESET_ALL);
>
> if ((host->quirks & SDHCI_QUIRK_32BIT_DMA_ADDR) && !aligned_buffer) {
> --
> 2.11.0
>

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


Re: [U-Boot] [U-Boot 2/3] cmd: add rockusb command

2017-03-19 Thread Simon Glass
Hi Eddie,

On 15 March 2017 at 01:56, Eddie Cai  wrote:
>
> this patch add rockusb command. the usage is
> rockusb  [] 
> e.g. rockusb 0 mmc 0
>
> Signed-off-by: Eddie Cai 
> ---
>  cmd/Kconfig   | 12 +
>  cmd/Makefile  |  1 +
>  cmd/rockusb.c | 79 
> +++
>  include/rockusb.h | 13 +
>  4 files changed, 105 insertions(+)
>  create mode 100644 cmd/rockusb.c
>  create mode 100644 include/rockusb.h

Can you please add some documentation on how to use this command and
what host tools you need?

>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index ef53156..dac2cc0 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -475,6 +475,18 @@ config CMD_DFU
>   Enables the command "dfu" which is used to have U-Boot create a DFU
>   class device via USB.
>
> +config CMD_ROCKUSB
> +bool "rockusb"
> +select USB_FUNCTION_ROCKUSB
> +help
> +  Enables the command "rockusb" which is used to have U-Boot create a
> +  Rockusb class device via USB.

Does this mean Rockchip-class device?

> +
> +config USB_FUNCTION_ROCKUSB
> +bool "Enable USB rockusb gadget"
> +help
> +  This enables the USB part of the rockusb gadget.
> +
>  config CMD_USB_MASS_STORAGE
> bool "UMS usb mass storage"
> help
> diff --git a/cmd/Makefile b/cmd/Makefile
> index f13bb8c..f5f1663 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -141,6 +141,7 @@ endif
>
>  obj-$(CONFIG_CMD_USB) += usb.o disk.o
>  obj-$(CONFIG_CMD_FASTBOOT) += fastboot.o
> +obj-$(CONFIG_CMD_ROCKUSB) += rockusb.o
>  obj-$(CONFIG_CMD_FS_UUID) += fs_uuid.o

Can you put it in alphabetical order if possible?

>
>  obj-$(CONFIG_CMD_USB_MASS_STORAGE) += usb_mass_storage.o
> diff --git a/cmd/rockusb.c b/cmd/rockusb.c
> new file mode 100644
> index 000..f5bd86e
> --- /dev/null
> +++ b/cmd/rockusb.c
> @@ -0,0 +1,79 @@
> +/*
> + * Copyright (C) 2017 Eddie Cai 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Should go above usb.h

> +

remove extra blank line

> +
> +static int do_rockusb(cmd_tbl_t *cmdtp, int flag, int argc, char *const 
> argv[])
> +{
> +   int controller_index, dev_index;
> +   char *usb_controller;
> +   char *devtype;
> +   char *devnum;
> +   int ret;
> +
> +   if (argc < 2)
> +   return CMD_RET_USAGE;
> +
> +   usb_controller = argv[1];
> +   controller_index = simple_strtoul(usb_controller, NULL, 0);
> +
> +   if (argc >= 4) {
> +   devtype = argv[2];
> +   devnum  = argv[3];
> +   } else {
> +   devtype = "mmc";
> +   devnum  = argv[2];
> +   }
> +   dev_index = simple_strtoul(devnum, NULL, 0);
> +   rockusb_dev_init(devtype, dev_index);

Can this fail, e.g. if index is out of range?

> +
> +   ret = board_usb_init(controller_index, USB_INIT_DEVICE);
> +   if (ret) {
> +   error("USB init failed: %d", ret);
> +   return CMD_RET_FAILURE;
> +   }
> +
> +   g_dnl_clear_detach();
> +   ret = g_dnl_register("usb_dnl_rockusb");
> +   if (ret)
> +   return ret;

Commands should return either 0 or CMD_RET_FAILURE.

> +   printf("do_rockusb1\n");

Do you want this?

> +   if (!g_dnl_board_usb_cable_connected()) {
> +   puts("\rUSB cable not detected.\n" \
> +"Command exit.\n");
> +   ret = CMD_RET_FAILURE;
> +   goto exit;
> +   }
> +
> +   while (1) {
> +   if (g_dnl_detach())
> +   break;
> +   if (ctrlc())
> +   break;
> +   usb_gadget_handle_interrupts(controller_index);
> +   }
> +   printf("do_rockusb2\n");

Do you want this?

> +   ret = CMD_RET_SUCCESS;
> +
> +exit:
> +   g_dnl_unregister();
> +   g_dnl_clear_detach();
> +   board_usb_cleanup(controller_index, USB_INIT_DEVICE);
> +
> +   return ret;
> +}
> +
> +U_BOOT_CMD(rockusb, 4, 1, do_rockusb,
> +   "Use the ROCKUSB",

Can you add a little more here?

> +   "rockusb  []   e.g. rockusb 0 mmc 
> 0\n"
> +   "devtype defaults to mmc"
> +);
> diff --git a/include/rockusb.h b/include/rockusb.h
> new file mode 100644
> index 000..cdea63d
> --- /dev/null
> +++ b/include/rockusb.h

Can this go in include/asm instead?

> @@ -0,0 +1,13 @@
> +/*
> + * (C) Copyright 2017
> + *
> + * Eddie Cai 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +#ifndef _ROCKUSB_H_
> +#define _ROCKUSB_H_
> +
> +void rockusb_dev_init(char *dev_type, int dev_index);

Please add a function comment.

> +
> +#endif /* _ROCKUSB_H_ */
> --
> 2.7.4
>

Regards,
Simon

Re: [U-Boot] [PATCH v2 1/2] x86: Add SCU IPC driver for Intel MID platforms

2017-03-19 Thread Simon Glass
Hi Andy,

On 15 March 2017 at 12:42, Andy Shevchenko
 wrote:
> From: Felipe Balbi 
>
> Intel MID platforms have few microcontrollers inside SoC, one of them
> is so called System Controller Unit (SCU).
>
> Here is the driver to communicate with microcontroller.
>
> Signed-off-by: Vincent Tinelli 
> Signed-off-by: Felipe Balbi 
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/Kconfig   |   2 +
>  arch/x86/include/asm/cpu.h |   1 +
>  arch/x86/include/asm/scu.h |  28 
>  arch/x86/lib/Makefile  |   1 +
>  arch/x86/lib/scu.c | 168 
> +
>  5 files changed, 200 insertions(+)
>  create mode 100644 arch/x86/include/asm/scu.h
>  create mode 100644 arch/x86/lib/scu.c

Since this is a v2 patch can you please include a change log?

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


Re: [U-Boot] [U-Boot 3/3] rockchip: rk3288: enable rockusb support on rk3288 based device

2017-03-19 Thread Simon Glass
Hi Eddie.

On 15 March 2017 at 01:56, Eddie Cai  wrote:
> this patch enable rockusb support on rk3288 based device.
>
> Signed-off-by: Eddie Cai 
> ---
>  include/configs/rk3288_common.h | 4 
>  1 file changed, 4 insertions(+)

I think this should be done in Kconfig.

>
> diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
> index b5606d4..b19a34d 100644
> --- a/include/configs/rk3288_common.h
> +++ b/include/configs/rk3288_common.h
> @@ -74,6 +74,10 @@
>  #define CONFIG_FASTBOOT_BUF_ADDR   CONFIG_SYS_LOAD_ADDR
>  #define CONFIG_FASTBOOT_BUF_SIZE   0x0800
>
> +/* rockusb  */
> +#define CONFIG_CMD_ROCKUSB
> +#define CONFIG_USB_FUNCTION_ROCKUSB
> +
>  /* usb mass storage */
>  #define CONFIG_USB_FUNCTION_MASS_STORAGE
>  #define CONFIG_CMD_USB_MASS_STORAGE
> --
> 2.7.4
>

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


Re: [U-Boot] Linker error when using CONFIG_SPL_SYS_MALLOC_SIMPLE=y

2017-03-19 Thread Simon Glass
Hi Dan,

On 17 March 2017 at 12:58, Dan Murphy  wrote:
> Simon
>
> On 03/17/2017 01:46 PM, Simon Glass wrote:
>> Hi Dan,
>>
>> On 17 March 2017 at 12:33, Dan Murphy  wrote:
>>> Simon
>>>
>>> On 03/17/2017 01:24 PM, Simon Glass wrote:
 +ML

 Hi Dan,

 On 17 March 2017 at 12:16, Dan Murphy  wrote:
> Simon
>
> I wanted to drop you a note to see if you have any advice on how to fix 
> this issue.
>
> In the attached .config file we enable
>
> CONFIG_SPL_SYS_MALLOC_SIMPLE and CONFIG_SPL_DFU_SUPPORT which we need 
> CONFIG_SPL_DFU_RAM
>
> When doing this we find that there is a build error
>
> common/built-in.o: In function `xrealloc':
> common/cli_hush.c:3349: undefined reference to `realloc_simple'
> common/built-in.o: In function `done_word':
> common/cli_hush.c:2494: undefined reference to `realloc_simple'
> cli_hush.c:2499: undefined reference to `realloc_simple'
> common/built-in.o: In function `b_check_space':
> common/cli_hush.c:876: undefined reference to `realloc_simple'
> make[1]: *** [spl/u-boot-spl] Error 1
> make: *** [spl/u-boot-spl] Error 2
>
> In digging into this I am finding that realloc_simple is not defined 
> anywhere in uboot.  malloc_simple.c seems
> to be missing the implementation.
>
> I am looking to see if you have a patch that fixes this issue or if you 
> can guide us to a resolution.
>
> Right now our only work around is to disable the HUSH_PARSER or turn off 
> the MALLOC simple.  Which according to
> Lokesh, CC'd, is needed for DM support.
 So SPL is using hush? Is there a description somewhere of what it does
 with that?
>>> HUSH_PARSER was added to the TI config in commit adad96e60 configs: Re-sync 
>>> HUSH options.
>>>
>>> HUSH calls realloc in the builtin functions.  I am not sure what SPL would 
>>> do with the HUSH.
>>>
 If you have enough space for hush I wonder whether you can just use
 full malloc() in SPL? You could implement realloc_simple() by just
 calling malloc_simple() and copying the old data over, but it is
 inefficient.
>>> We could work around it but the undef reference will still exist for other 
>>> code that would need realloc.
>> Right, but the point of simple malloc() is to be simple, and realloc()
>> is assumed not to be needed until you have a proper malloc().
>
> By proper malloc you mean the dlmalloc code?
>
> If thats true then why is realloc even defined in the simple malloc case?

To avoid it trying to use realloc(). Perhaps instead of a link error
it should be defined to some sort of error message?

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


Re: [U-Boot] [U-Boot 0/3] introduce Rockchip rockusb

2017-03-19 Thread Eddie Cai
2017-03-17 5:26 GMT+08:00 Marek Vasut :

> On 03/15/2017 08:56 AM, Eddie Cai wrote:
> > rockusb is a protocol run between host pc and device. it help people get
> device
> > info, flash image to device. this patch implement rockusb on device side.
>
> What is the benefit of this yet-another NIH protocol compared to ie.
> DFU/UMS/Thor/Fastboot ?
>
This is mostly  used on Rockchip chipset. All the rockchip SoC boot rom and
develop tools implement this protocol.
So we want to use the same protocol which compatible with current tools.


> > Eddie Cai (3):
> >   drivers: usb: gadget: add the rockusb gadget
> >   cmd: add rockusb command
> >   rockchip: rk3288: enable rockusb support on rk3288 based device
> >
> >  cmd/Kconfig |  12 +
> >  cmd/Makefile|   1 +
> >  cmd/rockusb.c   |  79 
> >  drivers/usb/gadget/Makefile |   1 +
> >  drivers/usb/gadget/f_rockusb.c  | 801 ++
> ++
> >  include/configs/rk3288_common.h |   4 +
> >  include/rockusb.h   |  13 +
> >  7 files changed, 911 insertions(+)
> >  create mode 100644 cmd/rockusb.c
> >  create mode 100644 drivers/usb/gadget/f_rockusb.c
> >  create mode 100644 include/rockusb.h
> >
>
>
> --
> Best regards,
> Marek Vasut
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] imx: mx6slevk: use SPI_BOOT

2017-03-19 Thread Peng Fan
Ping.. any comments?

On Sat, Mar 04, 2017 at 10:45:42AM +0800, Peng Fan wrote:
>Use SPI_BOOT instead of SYS_BOOT_SPINOR.
>
>Signed-off-by: Peng Fan 
>Cc: Stefano Babic 
>---
> configs/mx6slevk_spinor_defconfig | 3 ++-
> include/configs/mx6slevk.h| 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/configs/mx6slevk_spinor_defconfig 
>b/configs/mx6slevk_spinor_defconfig
>index 7c0a3a8..e1c9118 100644
>--- a/configs/mx6slevk_spinor_defconfig
>+++ b/configs/mx6slevk_spinor_defconfig
>@@ -1,7 +1,8 @@
> CONFIG_ARM=y
> CONFIG_ARCH_MX6=y
> CONFIG_TARGET_MX6SLEVK=y
>-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg,MX6SL,SYS_BOOT_SPINOR"
>+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg,MX6SL"
>+CONFIG_SPI_BOOT=y
> CONFIG_BOOTDELAY=3
> CONFIG_BOARD_EARLY_INIT_F=y
> CONFIG_HUSH_PARSER=y
>diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
>index 3e7e5a3..19dcc5c 100644
>--- a/include/configs/mx6slevk.h
>+++ b/include/configs/mx6slevk.h
>@@ -145,7 +145,7 @@
> /* Environment organization */
> #define CONFIG_ENV_SIZE   SZ_8K
> 
>-#if defined CONFIG_SYS_BOOT_SPINOR
>+#if defined CONFIG_SPI_BOOT
> #define CONFIG_ENV_IS_IN_SPI_FLASH
> #define CONFIG_ENV_OFFSET   (768 * 1024)
> #define CONFIG_ENV_SECT_SIZE(64 * 1024)
>-- 
>2.6.2
>
Thanks,
Peng.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] spi: mxc_spi: support driver model

2017-03-19 Thread Peng Fan
Ping.. any comments?

On Sat, Mar 04, 2017 at 10:47:06AM +0800, Peng Fan wrote:
>Add driver model support for mxc spi driver.
>Most functions are restructured to be reused by DM and non-DM.
>Tested on mx6slevk board.
>
>Signed-off-by: Peng Fan 
>Cc: Jagan Teki 
>cc: Stefano Babic 
>---
> drivers/spi/mxc_spi.c | 185 +-
> 1 file changed, 152 insertions(+), 33 deletions(-)
>
>diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
>index fc2786e..431e042 100644
>--- a/drivers/spi/mxc_spi.c
>+++ b/drivers/spi/mxc_spi.c
>@@ -5,6 +5,7 @@
>  */
> 
> #include 
>+#include 
> #include 
> #include 
> #include 
>@@ -14,6 +15,8 @@
> #include 
> #include 
> 
>+DECLARE_GLOBAL_DATA_PTR;
>+
> #ifdef CONFIG_MX27
> /* i.MX27 has a completely wrong register layout and register definitions in 
> the
>  * datasheet, the correct one is in the Freescale's Linux driver */
>@@ -22,10 +25,6 @@
> "See linux mxc_spi driver from Freescale for details."
> #endif
> 
>-static unsigned long spi_bases[] = {
>-  MXC_SPI_BASE_ADDRESSES
>-};
>-
> __weak int board_spi_cs_gpio(unsigned bus, unsigned cs)
> {
>   return -1;
>@@ -40,6 +39,8 @@ __weak int board_spi_cs_gpio(unsigned bus, unsigned cs)
> #define CONFIG_SYS_SPI_MXC_WAIT   (CONFIG_SYS_HZ/100) /* 10 
> ms */
> #endif
> 
>+#define MXC_SPI_MAX_FREQ  2000
>+
> struct mxc_spi_slave {
>   struct spi_slave slave;
>   unsigned long   base;
>@@ -51,6 +52,7 @@ struct mxc_spi_slave {
>   int ss_pol;
>   unsigned intmax_hz;
>   unsigned intmode;
>+  struct gpio_desc ss;
> };
> 
> static inline struct mxc_spi_slave *to_mxc_spi_slave(struct spi_slave *slave)
>@@ -58,19 +60,24 @@ static inline struct mxc_spi_slave 
>*to_mxc_spi_slave(struct spi_slave *slave)
>   return container_of(slave, struct mxc_spi_slave, slave);
> }
> 
>-void spi_cs_activate(struct spi_slave *slave)
>+static void mxc_spi_cs_activate(struct mxc_spi_slave *mxcs)
> {
>-  struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
>-  if (mxcs->gpio > 0)
>-  gpio_set_value(mxcs->gpio, mxcs->ss_pol);
>+  if (CONFIG_IS_ENABLED(DM_SPI)) {
>+  dm_gpio_set_value(>ss, mxcs->ss_pol);
>+  } else {
>+  if (mxcs->gpio > 0)
>+  gpio_set_value(mxcs->gpio, mxcs->ss_pol);
>+  }
> }
> 
>-void spi_cs_deactivate(struct spi_slave *slave)
>+static void mxc_spi_cs_deactivate(struct mxc_spi_slave *mxcs)
> {
>-  struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
>-  if (mxcs->gpio > 0)
>-  gpio_set_value(mxcs->gpio,
>-!(mxcs->ss_pol));
>+  if (CONFIG_IS_ENABLED(DM_SPI)) {
>+  dm_gpio_set_value(>ss, !(mxcs->ss_pol));
>+  } else {
>+  if (mxcs->gpio > 0)
>+  gpio_set_value(mxcs->gpio, !(mxcs->ss_pol));
>+  }
> }
> 
> u32 get_cspi_div(u32 div)
>@@ -211,10 +218,9 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, 
>unsigned int cs)
> }
> #endif
> 
>-int spi_xchg_single(struct spi_slave *slave, unsigned int bitlen,
>+int spi_xchg_single(struct mxc_spi_slave *mxcs, unsigned int bitlen,
>   const u8 *dout, u8 *din, unsigned long flags)
> {
>-  struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
>   int nbytes = DIV_ROUND_UP(bitlen, 8);
>   u32 data, cnt, i;
>   struct cspi_regs *regs = (struct cspi_regs *)mxcs->base;
>@@ -327,8 +333,9 @@ int spi_xchg_single(struct spi_slave *slave, unsigned int 
>bitlen,
> 
> }
> 
>-int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
>-  void *din, unsigned long flags)
>+static int mxc_spi_xfer_internal(struct mxc_spi_slave *mxcs,
>+   unsigned int bitlen, const void *dout,
>+   void *din, unsigned long flags)
> {
>   int n_bytes = DIV_ROUND_UP(bitlen, 8);
>   int n_bits;
>@@ -337,11 +344,11 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
>bitlen, const void *dout,
>   u8 *p_outbuf = (u8 *)dout;
>   u8 *p_inbuf = (u8 *)din;
> 
>-  if (!slave)
>-  return -1;
>+  if (!mxcs)
>+  return -EINVAL;
> 
>   if (flags & SPI_XFER_BEGIN)
>-  spi_cs_activate(slave);
>+  mxc_spi_cs_activate(mxcs);
> 
>   while (n_bytes > 0) {
>   if (n_bytes < MAX_SPI_BYTES)
>@@ -351,7 +358,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
>const void *dout,
> 
>   n_bits = blk_size * 8;
> 
>-  ret = spi_xchg_single(slave, n_bits, p_outbuf, p_inbuf, 0);
>+  ret = spi_xchg_single(mxcs, n_bits, p_outbuf, p_inbuf, 0);
> 
>   if (ret)
>   return ret;
>@@ -363,12 +370,39 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
>bitlen, const void *dout,
>   }
> 
>   if (flags & SPI_XFER_END) {
>- 

Re: [U-Boot] [PATCH 00/16] RFC: Board init using driver model

2017-03-19 Thread Tom Rini
On Sun, Mar 19, 2017 at 12:59:19PM -0600, Simon Glass wrote:
> At present we have a lot of ad-hoc init functions related to boards, for
> example board_early_init_f(), board_misc_init_f() and dram_init().
> 
> There are used in different ways by different boards as useful hooks to
> do the required init and sequence it correctly. Some functions are always
> enabled but have a __weak default. Some are controlled by the existence
> of a CONFIG.
> 
> There are two main init sequences: board_init_f() (f for running from
> read-only flash) which runs before relocation and board_init_r() (r for
> relocated) which runs afterwards.
> 
> One problem with the current sequence is that it has a lot of
> arch-specific #ifdefs around various functions. There are also #ifdefs
> for various features. There has been quite a bit of discussion about how
> to tidy this up and at least one RFC series[1].
> 
> Now that we have driver model we can use this to deal with the init
> sequences. This approach has several advantages:
> 
> - We have a path to remove the #ifdefs
> - It is easy for multiple parts of the code to implement the same hook
> - We can track what is called and what is not
> - We don't need weak functions
> - We can eventually adjust the sequence to improve naming or to add new
> init phases
> - It provides a model for how we might deal with ft_board_setup() and
> friends
> 
> This series starts the process of replacing the pre-relocation init
> sequence with a driver-model solution. It defines a uclass, adds tests
> and converts sandbox and a few x86 boards over to use this new setup.
> 
> This series is not ready for use yet as the rest of the init sequence
> hooks need to be converted. But there is enough here to show the idea.
> 
> Comments welcome.
> 
> [1] https://lists.denx.de/pipermail/u-boot/2011-August/098718.html

How does this look, size wise?  With all of these conversions and
clean-ups, we really need to be size concious as well as it all keeps
adding up.  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCHv2 1/3] Kconfig: Migrate CONFIG_BAUDRATE

2017-03-19 Thread Tom Rini
On Sun, Mar 19, 2017 at 02:46:41PM -0400, Tom Rini wrote:

> From: Philipp Tomsich 
> 
> Move this in to Kconfig with a default of 115200.
> 
> Signed-off-by: Philipp Tomsich 
> [trini: Run moveconfig.py, reword commit slightly]
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
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

2017-03-19 Thread Tom Rini
On Sun, Mar 19, 2017 at 06:07:47PM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
> The following changes since commit 2808576491ae36b6ea96743005058f370d936beb:
> 
>   arm64: booti: allow to place kernel image anywhere in physical memory
> (2017-03-14 20:40:23 -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to d883fcc6bbb2fcc3df90857fee99c2f543a0289c:
> 
>   imx: ventana: add EMMC configuration (2017-03-19 17:39:59 +0100)
> 

With a small fixup to arch/arm/dts/imx6ul-isiot.dtsi, applied to
u-boot/master, thanks!

-- 
Tom


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


[U-Boot] U-boot multi-file format

2017-03-19 Thread Diego
Hi all,

I'm trying to use the multi-file format mentioned in pages 12-13 of "U-Boot – 
Multi image booting scenarios" PDF slides.

I'd like to use FIT format, but I already have units in the field without 
CONFIG_FIT.

So I'd like to use the legacy U-Boot multi-file format, but I don't understand 
the format that should be used for the ramdisk. I already have a multi-file 
image that boots the kernel with the dtb, but it crashes when the ramdisk is 
needed (looking for an address outside of physical memory limits).

Which format should be used for the ramdisk? ext3.gz initrd? cpio.gz initramfs?

Thanks for any help!

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


[U-Boot] [PATCH 12/16] dm: x86: board: Add a BOARD_F_RESERVE_ARCH driver

2017-03-19 Thread Simon Glass
Add support for reserving initial memory.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/cpu.c | 41 -
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 8fa6953588..893bec5c5c 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -254,7 +254,7 @@ int cpu_init_r(void)
 }
 
 #ifndef CONFIG_EFI_STUB
-int reserve_arch(void)
+static int cpu_x86_reserve_arch(void)
 {
 #ifdef CONFIG_ENABLE_MRC_CACHE
mrccache_reserve();
@@ -266,4 +266,43 @@ int reserve_arch(void)
 
return 0;
 }
+
+#ifndef CONFIG_BOARD_ENABLE
+int reserve_arch(void)
+{
+   return cpu_x86_reserve_arch();
+}
+#endif
+
+#endif /* !CONFIG_EFI_STUB */
+
+static int cpu_x86_phase(struct udevice *dev, enum board_phase_t phase)
+{
+#ifndef CONFIG_EFI_STUB
+   return cpu_x86_reserve_arch();
+#else
+   return 0;
 #endif
+}
+
+static int cpu_x86_board_probe(struct udevice *dev)
+{
+   return board_support_phase(dev, BOARD_F_RESERVE_ARCH);
+}
+
+static const struct board_ops cpu_x86_board_ops = {
+   .phase  = cpu_x86_phase,
+};
+
+/* Name this starting with underscore so it will be called last */
+U_BOOT_DRIVER(_cpu_x86_board_drv) = {
+   .name   = "cpu_x86_board",
+   .id = UCLASS_BOARD,
+   .ops= _x86_board_ops,
+   .probe  = cpu_x86_board_probe,
+   .flags  = DM_FLAG_PRE_RELOC,
+};
+
+U_BOOT_DEVICE(cpu_x86_board) = {
+   .name   = "cpu_x86_board",
+};
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 14/16] dm: x86: board: ivybridge: Switch to use CONFIG_BOARD

2017-03-19 Thread Simon Glass
Enable CONFIG_BOARD_ENABLE so that the new board init is used.

Signed-off-by: Simon Glass 
---

 configs/chromebook_link64_defconfig | 1 +
 configs/chromebook_link_defconfig   | 1 +
 configs/chromebox_panther_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/chromebook_link64_defconfig 
b/configs/chromebook_link64_defconfig
index 749cfd43b0..074b4a6a1a 100644
--- a/configs/chromebook_link64_defconfig
+++ b/configs/chromebook_link64_defconfig
@@ -19,6 +19,7 @@ CONFIG_SPL_LOAD_FIT=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_BOARD_ENABLE=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_CPU_SUPPORT=y
 CONFIG_SPL_I2C_SUPPORT=y
diff --git a/configs/chromebook_link_defconfig 
b/configs/chromebook_link_defconfig
index 5ebb556f90..7588bc8f8e 100644
--- a/configs/chromebook_link_defconfig
+++ b/configs/chromebook_link_defconfig
@@ -11,6 +11,7 @@ CONFIG_FIT=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_BOARD_ENABLE=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_CPU=y
 # CONFIG_CMD_IMLS is not set
diff --git a/configs/chromebox_panther_defconfig 
b/configs/chromebox_panther_defconfig
index 0d65a90eba..fac227cb2a 100644
--- a/configs/chromebox_panther_defconfig
+++ b/configs/chromebox_panther_defconfig
@@ -9,6 +9,7 @@ CONFIG_FIT=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_BOARD_ENABLE=y
 CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 05/16] dm: board: Add a command to view phase info

2017-03-19 Thread Simon Glass
Add a 'board phases' command ('boa' or 'boa p' for short) which shows
which board phases have been run and how many devices provided an
implementation of each phase. Sample output:

=> board phases
  1 arch_cpu_init_dm
  0 board_early_init_f
  1 checkcpu
  0 misc_init_f
  1 dram_init
  1 reserve_arch

Signed-off-by: Simon Glass 
---

 cmd/Kconfig  |  8 
 cmd/Makefile |  1 +
 cmd/board.c  | 58 ++
 3 files changed, 67 insertions(+)
 create mode 100644 cmd/board.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 25e3b783a8..9b93f213b7 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -126,6 +126,14 @@ config CMD_BDI
help
  Print board info
 
+config CMD_BOARD
+   bool "board"
+   default y if BOARD
+   help
+ Provides access to board-specific drivers. This includes information
+ about which board init was completed as well as the board
+ description.
+
 config CMD_CONFIG
bool "config"
select BUILD_BIN2C
diff --git a/cmd/Makefile b/cmd/Makefile
index f13bb8c11e..4b1d183514 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -16,6 +16,7 @@ obj-y += version.o
 obj-$(CONFIG_CMD_AES) += aes.o
 obj-$(CONFIG_CMD_AMBAPP) += ambapp.o
 obj-$(CONFIG_CMD_ARMFLASH) += armflash.o
+obj-$(CONFIG_CMD_BOARD) += board.o
 obj-$(CONFIG_SOURCE) += source.o
 obj-$(CONFIG_CMD_SOURCE) += source.o
 obj-$(CONFIG_CMD_BDI) += bdinfo.o
diff --git a/cmd/board.c b/cmd/board.c
new file mode 100644
index 00..3ee91ca25d
--- /dev/null
+++ b/cmd/board.c
@@ -0,0 +1,58 @@
+/*
+ * Board driver commands
+ *
+ * Copyright (c) 2017 Google, Inc
+ * Written by Simon Glass 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const char * const phase_name[] = {
+   [BOARD_F_ARCH_CPU_INIT_DM] = "arch_cpu_init_dm",
+   [BOARD_F_EARLY_INIT_F] = "board_early_init_f",
+   [BOARD_F_CHECKCPU] = "checkcpu",
+   [BOARD_F_MISC_INIT_F] = "misc_init_f",
+   [BOARD_F_DRAM_INIT] = "dram_init",
+   [BOARD_F_RESERVE_ARCH] = "reserve_arch",
+   [BOARD_PHASE_TEST] = "test",
+   [BOARD_PHASE_INVALID] = "invalid",
+
+};
+
+static void board_list_phases(void)
+{
+   enum board_phase_t phase;
+
+   for (phase = BOARD_PHASE_FIRST; phase < BOARD_PHASE_TEST; phase++)
+   printf("%3d %s\n", gd->phase_count[phase], phase_name[phase]);
+}
+
+static int do_board(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   int cmd = 'p';
+
+   if (argc > 1)
+   cmd = argv[1][0];
+
+   switch (cmd) {
+   case 'p': /* phases */
+   board_list_phases();
+   break;
+   default:
+   return CMD_RET_FAILURE;
+   }
+
+   return 0;
+}
+
+U_BOOT_CMD(
+   board,  2,  0,  do_board,
+   "Access board information",
+   "phases\t- Show information about completed board init phases"
+);
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 15/16] dm: x86: board: ivybridge: Remove old board init code

2017-03-19 Thread Simon Glass
Remove the legacy board init code since it is no-longer used.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/ivybridge/cpu.c | 16 +---
 arch/x86/cpu/ivybridge/sdram.c   |  7 ---
 arch/x86/cpu/ivybridge/sdram_nop.c   |  7 ---
 arch/x86/lib/spl.c   | 13 -
 board/google/chromebook_link/link.c  |  7 ---
 board/google/chromebox_panther/panther.c |  7 ---
 6 files changed, 1 insertion(+), 56 deletions(-)

diff --git a/arch/x86/cpu/ivybridge/cpu.c b/arch/x86/cpu/ivybridge/cpu.c
index 96e69ef792..e7e6c3168a 100644
--- a/arch/x86/cpu/ivybridge/cpu.c
+++ b/arch/x86/cpu/ivybridge/cpu.c
@@ -84,13 +84,6 @@ static int do_arch_cpu_init_dm(void)
return 0;
 }
 
-#ifndef CONFIG_BOARD_ENABLE
-int arch_cpu_init_dm(void)
-{
-   return do_arch_cpu_init_dm();
-}
-#endif
-
 #define PCH_EHCI0_TEMP_BAR0 0xe800
 #define PCH_EHCI1_TEMP_BAR0 0xe8000400
 #define PCH_XHCI_TEMP_BAR0  0xe8001000
@@ -133,7 +126,7 @@ static void enable_usb_bar(struct udevice *bus)
pci_bus_write_config(bus, usb3, PCI_COMMAND, cmd, PCI_SIZE_32);
 }
 
-static int ivybridge_checkcpu(void)
+int ivybridge_checkcpu(void)
 {
enum pei_boot_mode_t boot_mode = PEI_BOOT_NONE;
struct udevice *dev, *lpc;
@@ -192,13 +185,6 @@ static int ivybridge_checkcpu(void)
return 0;
 }
 
-#ifndef CONFIG_BOARD_ENABLE
-int print_cpuinfo(void)
-{
-   return ivybridge_checkcpu();
-}
-#endif
-
 void board_debug_uart_init(void)
 {
/* This enables the debug UART */
diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
index 2484ed4859..eb4d04f8da 100644
--- a/arch/x86/cpu/ivybridge/sdram.c
+++ b/arch/x86/cpu/ivybridge/sdram.c
@@ -559,10 +559,3 @@ int ivybridge_dram_init(void)
 
return 0;
 }
-
-#ifndef CONFIG_BOARD_ENABLE
-int dram_init(void)
-{
-   return ivybridge_dram_init();
-}
-#endif
diff --git a/arch/x86/cpu/ivybridge/sdram_nop.c 
b/arch/x86/cpu/ivybridge/sdram_nop.c
index 641d099bbf..6bf5366410 100644
--- a/arch/x86/cpu/ivybridge/sdram_nop.c
+++ b/arch/x86/cpu/ivybridge/sdram_nop.c
@@ -18,13 +18,6 @@ int nop_dram_init(void)
return 0;
 }
 
-#ifndef CONFIG_BOARD_ENABLE
-int dram_init(void)
-{
-   return nop_dram_init();
-}
-#endif
-
 static int cpu_x86_nop_phase(struct udevice *dev, enum board_phase_t phase)
 {
switch (phase) {
diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
index a4c1a3ac35..0d40a6f41e 100644
--- a/arch/x86/lib/spl.c
+++ b/arch/x86/lib/spl.c
@@ -48,7 +48,6 @@ static int x86_spl_init(void)
return ret;
}
preloader_console_init();
-#ifdef CONFIG_BOARD_ENABLE
ret = board_walk_phase(BOARD_F_CHECKCPU);
if (ret) {
debug("%s: BOARD_F_CHECKCPU failed\n", __func__);
@@ -59,18 +58,6 @@ static int x86_spl_init(void)
debug("%s: BOARD_F_DRAM_INIT failed\n", __func__);
return ret;
}
-#else
-   ret = print_cpuinfo();
-   if (ret) {
-   debug("%s: print_cpuinfo() failed\n", __func__);
-   return ret;
-   }
-   ret = dram_init();
-   if (ret) {
-   debug("%s: dram_init() failed\n", __func__);
-   return ret;
-   }
-#endif
memset(&__bss_start, 0, (ulong)&__bss_end - (ulong)&__bss_start);
 
/* TODO(s...@chromium.org): Consider calling cpu_init_r() here */
diff --git a/board/google/chromebook_link/link.c 
b/board/google/chromebook_link/link.c
index 99b1c91edc..64e7c1a08d 100644
--- a/board/google/chromebook_link/link.c
+++ b/board/google/chromebook_link/link.c
@@ -16,10 +16,3 @@ int arch_early_init_r(void)
 {
return 0;
 }
-
-#ifndef CONFIG_BOARD_ENABLE
-int board_early_init_f(void)
-{
-   return 0;
-}
-#endif
diff --git a/board/google/chromebox_panther/panther.c 
b/board/google/chromebox_panther/panther.c
index 151cdd719d..ed60e44264 100644
--- a/board/google/chromebox_panther/panther.c
+++ b/board/google/chromebox_panther/panther.c
@@ -11,10 +11,3 @@ int arch_early_init_r(void)
 {
return 0;
 }
-
-#ifndef CONFIG_BOARD_ENABLE
-int board_early_init_f(void)
-{
-   return 0;
-}
-#endif
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 00/16] RFC: Board init using driver model

2017-03-19 Thread Simon Glass
At present we have a lot of ad-hoc init functions related to boards, for
example board_early_init_f(), board_misc_init_f() and dram_init().

There are used in different ways by different boards as useful hooks to
do the required init and sequence it correctly. Some functions are always
enabled but have a __weak default. Some are controlled by the existence
of a CONFIG.

There are two main init sequences: board_init_f() (f for running from
read-only flash) which runs before relocation and board_init_r() (r for
relocated) which runs afterwards.

One problem with the current sequence is that it has a lot of
arch-specific #ifdefs around various functions. There are also #ifdefs
for various features. There has been quite a bit of discussion about how
to tidy this up and at least one RFC series[1].

Now that we have driver model we can use this to deal with the init
sequences. This approach has several advantages:

- We have a path to remove the #ifdefs
- It is easy for multiple parts of the code to implement the same hook
- We can track what is called and what is not
- We don't need weak functions
- We can eventually adjust the sequence to improve naming or to add new
init phases
- It provides a model for how we might deal with ft_board_setup() and
friends

This series starts the process of replacing the pre-relocation init
sequence with a driver-model solution. It defines a uclass, adds tests
and converts sandbox and a few x86 boards over to use this new setup.

This series is not ready for use yet as the rest of the init sequence
hooks need to be converted. But there is enough here to show the idea.

Comments welcome.

[1] https://lists.denx.de/pipermail/u-boot/2011-August/098718.html


Simon Glass (16):
  x86: Drop leading spaces in cpu_x86_get_desc()
  x86: Display the SPL banner only once
  x86: config: Enable dhrystone command for link
  dm: board: Add a uclass for init functions
  dm: board: Add a command to view phase info
  dm: board: Adjust pre-relocation init hooks
  dm: board: Support printing CPU info using the uclass
  dm: sandbox: Convert to using driver-model baord init
  dm: board: Add tests for the board uclass
  dm: board: Add documentation
  dm: x86: board: Enable CONFIG_BOARD
  dm: x86: board: Add a BOARD_F_RESERVE_ARCH driver
  dm: x86: board: ivybridge: Add support for CONFIG_BOARD
  dm: x86: board: ivybridge: Switch to use CONFIG_BOARD
  dm: x86: board: ivybridge: Remove old board init code
  dm: board: Add information about the new board init to the README

 README|   3 +
 arch/Kconfig  |   5 +
 arch/sandbox/dts/test.dts |  12 ++
 arch/sandbox/include/asm/state.h  |   3 +
 arch/sandbox/include/asm/test.h   |   9 ++
 arch/x86/cpu/coreboot/coreboot.c  |   2 +
 arch/x86/cpu/cpu.c|  41 -
 arch/x86/cpu/cpu_x86.c|   6 +-
 arch/x86/cpu/ivybridge/cpu.c  |  57 +--
 arch/x86/cpu/ivybridge/sdram.c|   6 +-
 arch/x86/cpu/ivybridge/sdram_nop.c|  36 -
 arch/x86/cpu/x86_64/cpu.c |   2 +
 arch/x86/include/asm/arch-ivybridge/sandybridge.h |   7 +
 arch/x86/lib/spl.c|  11 +-
 board/google/chromebook_link/link.c   |   5 -
 board/google/chromebox_panther/panther.c  |   5 -
 board/sandbox/sandbox.c   |  44 +-
 cmd/Kconfig   |   8 +
 cmd/Makefile  |   1 +
 cmd/board.c   |  58 +++
 common/Kconfig|  31 
 common/board_f.c  |  58 ++-
 common/init/Makefile  |   1 +
 common/init/board-uclass.c| 108 +
 configs/chromebook_link64_defconfig   |   2 +
 configs/chromebook_link_defconfig |   2 +
 configs/chromebox_panther_defconfig   |   1 +
 doc/driver-model/board-info.txt   | 181 ++
 drivers/cpu/cpu-uclass.c  |  19 +++
 drivers/misc/Makefile |   1 +
 drivers/misc/board_sandbox.c  |  44 ++
 include/asm-generic/global_data.h |   5 +
 include/board.h   | 170 
 include/cpu.h |   5 +
 include/dm/uclass-id.h|   1 +
 test/dm/Makefile  |   1 +
 test/dm/board.c   |  74 +
 37 files changed, 980 insertions(+), 45 deletions(-)
 create mode 100644 cmd/board.c
 create mode 100644 common/init/board-uclass.c
 create mode 100644 doc/driver-model/board-info.txt
 

[U-Boot] [PATCH 11/16] dm: x86: board: Enable CONFIG_BOARD

2017-03-19 Thread Simon Glass
Enable this option so we can use board drivers.

Signed-off-by: Simon Glass 
---

 arch/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index f07070db18..2133a88c99 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -89,6 +89,8 @@ config X86
select CREATE_ARCH_SYMLINK
select HAVE_PRIVATE_LIBGCC
select SUPPORT_OF_CONTROL
+   select BOARD
+   select SPL_BOARD if SPL
select DM
select DM_KEYBOARD
select DM_SERIAL
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 13/16] dm: x86: board: ivybridge: Add support for CONFIG_BOARD

2017-03-19 Thread Simon Glass
Add hooks for ivybridge boards so they can use CONFIG_BOARD for init.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/coreboot/coreboot.c  |  2 +
 arch/x86/cpu/ivybridge/cpu.c  | 71 +++
 arch/x86/cpu/ivybridge/sdram.c| 13 -
 arch/x86/cpu/ivybridge/sdram_nop.c| 43 +-
 arch/x86/cpu/x86_64/cpu.c |  2 +
 arch/x86/include/asm/arch-ivybridge/sandybridge.h |  7 +++
 arch/x86/lib/spl.c| 13 +
 board/google/chromebook_link/link.c   |  2 +
 board/google/chromebox_panther/panther.c  |  2 +
 9 files changed, 140 insertions(+), 15 deletions(-)

diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index 1b042037bb..609bfcb2da 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -29,6 +29,7 @@ int arch_cpu_init(void)
return x86_cpu_init_f();
 }
 
+#ifndef CONFIG_BOARD_ENABLE
 int board_early_init_f(void)
 {
return 0;
@@ -38,6 +39,7 @@ int print_cpuinfo(void)
 {
return default_print_cpuinfo();
 }
+#endif
 
 static void board_final_cleanup(void)
 {
diff --git a/arch/x86/cpu/ivybridge/cpu.c b/arch/x86/cpu/ivybridge/cpu.c
index c4aca08f0d..96e69ef792 100644
--- a/arch/x86/cpu/ivybridge/cpu.c
+++ b/arch/x86/cpu/ivybridge/cpu.c
@@ -12,6 +12,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -50,10 +51,10 @@ int arch_cpu_init(void)
return x86_cpu_init_f();
 }
 
-int arch_cpu_init_dm(void)
+static int do_arch_cpu_init_dm(void)
 {
struct pci_controller *hose;
-   struct udevice *bus, *dev;
+   struct udevice *bus, *lpc_dev;
int ret;
 
post_code(0x70);
@@ -67,7 +68,7 @@ int arch_cpu_init_dm(void)
/* TODO(s...@chromium.org): Get rid of gd->hose */
gd->hose = hose;
 
-   ret = uclass_first_device_err(UCLASS_LPC, );
+   ret = uclass_first_device_err(UCLASS_LPC, _dev);
if (ret)
return ret;
 
@@ -83,6 +84,13 @@ int arch_cpu_init_dm(void)
return 0;
 }
 
+#ifndef CONFIG_BOARD_ENABLE
+int arch_cpu_init_dm(void)
+{
+   return do_arch_cpu_init_dm();
+}
+#endif
+
 #define PCH_EHCI0_TEMP_BAR0 0xe800
 #define PCH_EHCI1_TEMP_BAR0 0xe8000400
 #define PCH_XHCI_TEMP_BAR0  0xe8001000
@@ -125,12 +133,10 @@ static void enable_usb_bar(struct udevice *bus)
pci_bus_write_config(bus, usb3, PCI_COMMAND, cmd, PCI_SIZE_32);
 }
 
-int print_cpuinfo(void)
+static int ivybridge_checkcpu(void)
 {
enum pei_boot_mode_t boot_mode = PEI_BOOT_NONE;
-   char processor_name[CPU_MAX_NAME_LEN];
struct udevice *dev, *lpc;
-   const char *name;
uint32_t pm1_cnt;
uint16_t pm1_sts;
int ret;
@@ -181,19 +187,62 @@ int print_cpuinfo(void)
}
 
gd->arch.pei_boot_mode = boot_mode;
-
-   /* Print processor name */
-   name = cpu_get_name(processor_name);
-   printf("CPU:   %s\n", name);
-
post_code(POST_CPU_INFO);
 
return 0;
 }
 
+#ifndef CONFIG_BOARD_ENABLE
+int print_cpuinfo(void)
+{
+   return ivybridge_checkcpu();
+}
+#endif
+
 void board_debug_uart_init(void)
 {
/* This enables the debug UART */
pci_x86_write_config(NULL, PCH_LPC_DEV, LPC_EN, COMA_LPC_EN,
 PCI_SIZE_16);
 }
+
+static int cpu_x86_ivybridge_phase(struct udevice *dev,
+  enum board_phase_t phase)
+{
+   switch (phase) {
+   case BOARD_F_ARCH_CPU_INIT_DM:
+   return do_arch_cpu_init_dm();
+   case BOARD_F_CHECKCPU:
+   return ivybridge_checkcpu();
+   case BOARD_F_DRAM_INIT:
+   return ivybridge_dram_init();
+   default:
+   return -ENOSYS;
+   }
+
+   return 0;
+}
+
+static int cpu_x86_ivybridge_board_probe(struct udevice *dev)
+{
+   return board_support_phase_mask(dev,
+   board_phase_mask(BOARD_F_ARCH_CPU_INIT_DM) |
+   board_phase_mask(BOARD_F_CHECKCPU) |
+   board_phase_mask(BOARD_F_DRAM_INIT));
+}
+
+static const struct board_ops cpu_x86_ivybridge_board_ops = {
+   .phase  = cpu_x86_ivybridge_phase,
+};
+
+U_BOOT_DRIVER(cpu_x86_ivybridge_board_drv) = {
+   .name   = "cpu_x86_ivybridge_board",
+   .id = UCLASS_BOARD,
+   .ops= _x86_ivybridge_board_ops,
+   .probe  = cpu_x86_ivybridge_board_probe,
+   .flags  = DM_FLAG_PRE_RELOC,
+};
+
+U_BOOT_DEVICE(cpu_x86_ivybridge_board) = {
+   .name   = "cpu_x86_ivybridge_board",
+};
diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
index 201368c9c7..2484ed4859 100644
--- a/arch/x86/cpu/ivybridge/sdram.c
+++ b/arch/x86/cpu/ivybridge/sdram.c
@@ -401,7 +401,7 @@ static void rcba_config(void)
setbits_le32(RCB_REG(FD), 

[U-Boot] [PATCH 09/16] dm: board: Add tests for the board uclass

2017-03-19 Thread Simon Glass
Add some tests which define some devices and check the operation of the
various init functions.

Signed-off-by: Simon Glass 
---

 arch/sandbox/dts/test.dts| 12 +++
 arch/sandbox/include/asm/state.h |  3 ++
 arch/sandbox/include/asm/test.h  |  9 +
 drivers/misc/Makefile|  1 +
 drivers/misc/board_sandbox.c | 44 
 test/dm/Makefile |  1 +
 test/dm/board.c  | 74 
 7 files changed, 144 insertions(+)
 create mode 100644 drivers/misc/board_sandbox.c
 create mode 100644 test/dm/board.c

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index fff175d1b7..084c3dff63 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -52,6 +52,18 @@
reg = <2 1>;
};
 
+   board-test0 {
+   compatible = "sandbox,board-test0";
+   };
+
+   board-test1 {
+   compatible = "sandbox,board-test1";
+   };
+
+   board-test2 {
+   compatible = "sandbox,board-test2";
+   };
+
b-test {
reg = <3 1>;
compatible = "denx,u-boot-fdt-test";
diff --git a/arch/sandbox/include/asm/state.h b/arch/sandbox/include/asm/state.h
index 149f28d873..d531531d72 100644
--- a/arch/sandbox/include/asm/state.h
+++ b/arch/sandbox/include/asm/state.h
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /**
@@ -65,6 +66,8 @@ struct sandbox_state {
enum state_terminal_raw term_raw;   /* Terminal raw/cooked */
bool skip_delays;   /* Ignore any time delays (for test) */
bool show_test_output;  /* Don't suppress stdout in tests */
+   /* Return values for board_sandbox */
+   int board_sandbox_ret[BOARD_TEST_COUNT];
 
/* Pointer to information for each SPI bus/cs */
struct sandbox_spi_info spi[CONFIG_SANDBOX_SPI_MAX_BUS]
diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h
index 451a78e590..12b3b9bc1e 100644
--- a/arch/sandbox/include/asm/test.h
+++ b/arch/sandbox/include/asm/test.h
@@ -79,4 +79,13 @@ long sandbox_i2c_rtc_get_set_base_time(struct udevice *dev, 
long base_time);
 
 int sandbox_usb_keyb_add_string(struct udevice *dev, const char *str);
 
+/* For testing the BOARD uclass */
+enum {
+   BOARD_TEST0,
+   BOARD_TEST1,
+   BOARD_TEST2,
+
+   BOARD_TEST_COUNT,
+};
+
 #endif
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e3151ea097..88015cc8af 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -8,6 +8,7 @@
 obj-$(CONFIG_MISC) += misc-uclass.o
 obj-$(CONFIG_ALI152X) += ali512x.o
 obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
+obj-$(CONFIG_SANDBOX) += board_sandbox.o
 obj-$(CONFIG_DS4510)  += ds4510.o
 obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
 ifndef CONFIG_SPL_BUILD
diff --git a/drivers/misc/board_sandbox.c b/drivers/misc/board_sandbox.c
new file mode 100644
index 00..9ccdbfbbe8
--- /dev/null
+++ b/drivers/misc/board_sandbox.c
@@ -0,0 +1,44 @@
+/*
+ * Copyright (c) 2017 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int board_sandbox_phase(struct udevice *dev, enum board_phase_t phase)
+{
+   struct sandbox_state *state = state_get_current();
+   int id = dev_get_driver_data(dev);
+
+   return state->board_sandbox_ret[id];
+}
+
+static int board_sandbox_probe(struct udevice *dev)
+{
+   return board_support_phase(dev, BOARD_PHASE_TEST);
+}
+
+static const struct board_ops board_sandbox_ops = {
+   .phase  = board_sandbox_phase,
+};
+
+
+static const struct udevice_id board_sandbox_ids[] = {
+   { .compatible = "sandbox,board-test0", BOARD_TEST0 },
+   { .compatible = "sandbox,board-test1", BOARD_TEST1 },
+   { .compatible = "sandbox,board-test2", BOARD_TEST2 },
+   { }
+};
+
+U_BOOT_DRIVER(board_sandbox_drv) = {
+   .name   = "board_sandbox",
+   .id = UCLASS_BOARD,
+   .ops= _sandbox_ops,
+   .of_match   = board_sandbox_ids,
+   .probe  = board_sandbox_probe,
+};
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 1885e17c38..c84a966708 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_UT_DM) += test-uclass.o
 # subsystem you must add sandbox tests here.
 obj-$(CONFIG_UT_DM) += core.o
 ifneq ($(CONFIG_SANDBOX),)
+obj-$(CONFIG_BOARD) += board.o
 obj-$(CONFIG_BLK) += blk.o
 obj-$(CONFIG_CLK) += clk.o
 obj-$(CONFIG_DM_ETH) += eth.o
diff --git a/test/dm/board.c b/test/dm/board.c
new file mode 100644
index 00..986746632b
--- /dev/null
+++ b/test/dm/board.c
@@ -0,0 +1,74 @@
+/*
+ * Copyright (C) 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Test 

[U-Boot] [PATCH 10/16] dm: board: Add documentation

2017-03-19 Thread Simon Glass
Add some documentation for the new board init system. This describes how
it works and how to migrate to it.

Signed-off-by: Simon Glass 
---

 doc/driver-model/board-info.txt | 181 
 1 file changed, 181 insertions(+)
 create mode 100644 doc/driver-model/board-info.txt

diff --git a/doc/driver-model/board-info.txt b/doc/driver-model/board-info.txt
new file mode 100644
index 00..86db096e28
--- /dev/null
+++ b/doc/driver-model/board-info.txt
@@ -0,0 +1,181 @@
+How to handle board init with Driver Model
+==
+
+Motivation
+--
+
+At present U-Boot has a lot of ad-hoc init functions related to boards, for
+board_early_init_f, board_misc_init_f() and dram_init().
+
+There are used in different ways by different boards as useful hooks to
+do the required init and sequence it correctly. Some functions are always
+enabled but have a __weak default. Some are controlled by the existence
+of a CONFIG.
+
+There are two main init sequences: board_init_f() (f for running from
+read-only flash) which runs before relocation and board_init_r() (r for
+relocated) which runs afterwards.
+
+One problem with the current sequence is that it has a lot of
+arch-specific #ifdefs around various functions. There are also #ifdefs
+for various features. With a driver-model based approach it should be
+possible to remove these over time since the board-specific code can move into
+drivers and does not need to be called from the init sequence.
+
+
+Design
+--
+
+A new uclass (UCLASS_BOARD) is defined. The uclass has one important method:
+phase(). This is called to handle a particular phase of board init. Phases are
+defined by enum board_phase_t. For example, the existing board_early_init_f()
+function is replaced by the BOARD_F_EARLY_INIT_F phase.
+
+When the init sequence wants to initiate the BOARD_F_EARLY_INIT_F phase it
+calls the phase() method of all the devices that implement that phase. It
+knows which ones implement it because they call board_support_phase() or
+board_support_phase_mask() in their probe method to register which phases they
+support.
+
+Multiple devices can implement the same phase. The init sequence calls these
+devices one by one. It is also possible for a device to 'claim' a phase, such
+that no further devices are called. The ordering of devices is as per the
+usual driver-model approach: the same order as the device tree nodes, or
+ordered by device name in the case of U_BOOT_DEVICE() declarations.
+
+With this approach a call to board_early_init_f() is replaced with a call to
+board_walk_opt_phase() which handles the phase but does not complain if no
+device handles it. For a mandatory phase, board_walk_phase() can be used.
+
+After starting up you can use the 'board phases' command to see what phases
+were executed:
+
+   => board phases
+   1 arch_cpu_init_dm
+   0 board_early_init_f
+   1 checkcpu
+   0 misc_init_f
+   1 dram_init
+   1 reserve_arch
+
+This shows that four phases were executed and each had a single device which
+handled that phase.
+
+
+Example
+---
+
+Below is an example with sandbox:
+
+
+static int sandbox_phase(struct udevice *dev, enum board_phase_t phase)
+{
+   struct sandbox_state *state = state_get_current();
+
+   switch (phase) {
+   case BOARD_F_DRAM_INIT:
+   gd->ram_size = state->ram_size;
+   return 0;
+   default:
+   return -ENOSYS;
+   }
+
+   return 0;
+}
+
+static int sandbox_board_probe(struct udevice *dev)
+{
+   return board_support_phase(dev, BOARD_F_DRAM_INIT);
+}
+
+static const struct board_ops sandbox_board_ops = {
+   .phase  = sandbox_phase,
+};
+
+/* Name this starting with underscore so it will be called last */
+U_BOOT_DRIVER(_sandbox_board_drv) = {
+   .name   = "sandbox_board",
+   .id = UCLASS_BOARD,
+   .ops= _board_ops,
+   .probe  = sandbox_board_probe,
+   .flags  = DM_FLAG_PRE_RELOC,
+};
+
+U_BOOT_DEVICE(sandbox_board) = {
+   .name   = "sandbox_board",
+};
+
+
+This is a normal driver which supports the phase() method. The U_BOOT_DEVICE()
+declaration instantiates the device. It supports only one phase:
+BOARD_F_DRAM_INIT.
+
+If you look at common/board_f.c you will see how dram_init() uses this:
+
+int dram_init(void)
+{
+   return board_walk_phase(BOARD_F_DRAM_INIT);
+}
+
+That call will end up calling:
+
+   sandbox_phase(dev, BOARD_F_DRAM_INIT)
+
+There is quite a bit of boilerplate with the driver declaration. It would be
+quite easy to replace most of it with a macro, like:
+
+U_BOOT_BOARD_DRV(_sandbox_board, _sandbox_board_drv);
+
+but for now this is not attempted, to keep everything in the open.
+
+
+Porting suggestions
+---
+
+You may find that you have all of your init handlers in a single file in your
+board 

[U-Boot] [PATCH 04/16] dm: board: Add a uclass for init functions

2017-03-19 Thread Simon Glass
Add a uclass to handle board init. This allows drivers to be provided to
perform the various phases of init. Functions are provided to call all
devices that can handle a particular phase.

Signed-off-by: Simon Glass 
---

 common/Kconfig|  31 +++
 common/init/Makefile  |   1 +
 common/init/board-uclass.c| 108 
 include/asm-generic/global_data.h |   5 ++
 include/board.h   | 170 ++
 include/dm/uclass-id.h|   1 +
 6 files changed, 316 insertions(+)
 create mode 100644 common/init/board-uclass.c
 create mode 100644 include/board.h

diff --git a/common/Kconfig b/common/Kconfig
index 8f73c8f757..7d2bd15371 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -395,6 +395,36 @@ config DISPLAY_BOARDINFO
 
 menu "Start-up hooks"
 
+config BOARD
+   bool "Support using driver model for board start-up hooks, etc."
+   help
+ This adds support for the board uclass and associated functions. With
+ this you can create and use BOARD drivers. However unless
+ BOARD_ENABLE is also set, the existing init sequence will continue
+ to be used. This is designed to ease migration of boards, since
+ support for both methods can be provided during the transition
+ period.
+
+config SPL_BOARD
+   bool "Support using driver model for board start-up hooks, etc. in SPL"
+   help
+ This adds support for the board uclass and associated functions in
+ SPL. With this you can create and use BOARD drivers. However unless
+ BOARD_ENABLE is also set, the existing init sequence will continue
+ to be used. This is designed to ease migration of boards, since
+ support for both methods can be provided during the transition
+ period.
+
+config BOARD_ENABLE
+   bool "Use driver model instead of ad-hoc board init functions"
+   depends on BOARD
+   help
+ This replaces the ad-hoc start-up functions like board_early_init_f()
+ with a driver-model-based interface. With this enabled, boards
+ provide one or more drivers which implement these phases of init as
+ well as access to the board decription. Existing init functions are
+ no-longer called.
+
 config ARCH_EARLY_INIT_R
bool "Call arch-specific init soon after relocation"
default y if X86
@@ -414,6 +444,7 @@ config ARCH_MISC_INIT
 
 config BOARD_EARLY_INIT_F
bool "Call board-specific init before relocation"
+   depends on !BOARD_ENABLE
default y if X86
help
  Some boards need to perform initialisation as soon as possible
diff --git a/common/init/Makefile b/common/init/Makefile
index 4902635f53..923ce8e139 100644
--- a/common/init/Makefile
+++ b/common/init/Makefile
@@ -5,3 +5,4 @@
 #
 
 obj-y += board_init.o
+obj-$(CONFIG_$(SPL_)BOARD) += board-uclass.o
diff --git a/common/init/board-uclass.c b/common/init/board-uclass.c
new file mode 100644
index 00..2ca65f44da
--- /dev/null
+++ b/common/init/board-uclass.c
@@ -0,0 +1,108 @@
+/*
+ * Board driver interface
+ *
+ * Copyright (c) 2017 Google, Inc
+ * Written by Simon Glass 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_phase(struct udevice *dev, enum board_phase_t phase)
+{
+   struct board_uc_priv *priv = dev_get_uclass_priv(dev);
+   struct board_ops *ops = board_get_ops(dev);
+
+   if (!ops->phase)
+   return -ENOSYS;
+   if (!priv->phase_mask && phase == BOARD_PHASE_FIRST) {
+   printf("Device '%s' supports no phases\n", dev->name);
+   return -EINVAL;
+   }
+   if (!(priv->phase_mask & board_phase_mask(phase)))
+   return -ENOSYS;
+
+   return ops->phase(dev, phase);
+}
+
+int board_walk_phase_count(enum board_phase_t phase, bool verbose)
+{
+   struct udevice *dev;
+   int count = 0;
+   int ret;
+
+   for (ret = uclass_first_device(UCLASS_BOARD, );
+dev;
+uclass_next_device()) {
+   ret = board_phase(dev, phase);
+   if (ret == 0) {
+   count++;
+   } else if (ret == BOARD_PHASE_CLAIMED) {
+   count++;
+   debug("Phase %d claimed by '%s'\n", phase, dev->name);
+   break;
+   } else if (ret != -ENOSYS) {
+   gd->phase_count[phase] += count;
+   return ret;
+   }
+   }
+
+   if (!count) {
+   if (verbose)
+   printf("Unable to find driver for phase %d\n", phase);
+   return -ENOSYS;
+   }
+   gd->phase_count[phase] += count;
+
+   return count;
+}
+
+int board_walk_phase(enum board_phase_t phase)
+{
+   int ret;
+
+   ret = 

[U-Boot] [PATCH 16/16] dm: board: Add information about the new board init to the README

2017-03-19 Thread Simon Glass
Add a brief note pointing to the documentation.

Signed-off-by: Simon Glass 
---

 README | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/README b/README
index aa907ced8a..891da97838 100644
--- a/README
+++ b/README
@@ -222,6 +222,9 @@ See board/sandbox/README.sandbox for more details.
 Board Initialisation Flow:
 --
 
+Note: An effort to organise and perhaps rationalise the many init hooks in the
+init sequence has started. See doc/driver-model/board-info.txt for details.
+
 This is the intended start-up flow for boards. This should apply for both
 SPL and U-Boot proper (i.e. they both follow the same rules).
 
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 07/16] dm: board: Support printing CPU info using the uclass

2017-03-19 Thread Simon Glass
With driver model we can obtain CPU information by calling the CPU uclass.
This avoids ad-hoc code for each board. Change the code to do this when
CONFIG_BOARD is enabled.

Signed-off-by: Simon Glass 
---

 common/board_f.c | 11 ++-
 drivers/cpu/cpu-uclass.c | 19 +++
 include/cpu.h|  5 +
 3 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index df9a64a20f..4d9d2f30c7 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -852,6 +852,15 @@ int reserve_arch(void)
return board_walk_opt_phase(BOARD_F_RESERVE_ARCH);
 }
 
+int print_cpuinfo(void)
+{
+#ifdef CONFIG_CPU
+   return cpu_print_info();
+#else
+   return 0;
+#endif
+}
+
 #else
 
 /* Architecture-specific memory reservation */
@@ -938,7 +947,7 @@ static const init_fnc_t init_sequence_f[] = {
defined(CONFIG_BOARD_ENABLE)
checkcpu,
 #endif
-#if defined(CONFIG_DISPLAY_CPUINFO)
+#if defined(CONFIG_DISPLAY_CPUINFO) || defined(CONFIG_BOARD_ENABLED)
print_cpuinfo,  /* display cpu info (and speed) */
 #endif
 #if defined(CONFIG_DISPLAY_BOARDINFO)
diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c
index c57ac16b3a..2a69ea3af3 100644
--- a/drivers/cpu/cpu-uclass.c
+++ b/drivers/cpu/cpu-uclass.c
@@ -54,6 +54,25 @@ int cpu_get_vendor(struct udevice *dev, char *buf, int size)
return ops->get_vendor(dev, buf, size);
 }
 
+int cpu_print_info(void)
+{
+   struct udevice *dev;
+   char name[60];
+   int ret;
+
+   ret = uclass_first_device(UCLASS_CPU, );
+   if (ret)
+   return ret;
+   if (!dev)
+   return 0;
+   ret = cpu_get_desc(dev, name, sizeof(name));
+   if (ret)
+   return ret;
+   printf("CPU:   %s\n", name);
+
+   return 0;
+}
+
 U_BOOT_DRIVER(cpu_bus) = {
.name   = "cpu_bus",
.id = UCLASS_SIMPLE_BUS,
diff --git a/include/cpu.h b/include/cpu.h
index 954257715a..2d5c373343 100644
--- a/include/cpu.h
+++ b/include/cpu.h
@@ -124,4 +124,9 @@ int cpu_get_count(struct udevice *dev);
  */
 int cpu_get_vendor(struct udevice *dev, char *buf, int size);
 
+/**
+ * cpu_print_info() - Print information about the first CPU
+ */
+int cpu_print_info(void);
+
 #endif
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 06/16] dm: board: Adjust pre-relocation init hooks

2017-03-19 Thread Simon Glass
When CONFIG_BOARD_ENABLED is enabled, replace the existing ad-hoc hooks
with ones based on driver model. These call devices to handle each phase
of init.

Signed-off-by: Simon Glass 
---

 common/board_f.c | 47 ++-
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index 7d1ede0404..df9a64a20f 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -11,7 +11,8 @@
  */
 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -819,6 +820,40 @@ static int initf_dm(void)
return 0;
 }
 
+#ifdef CONFIG_BOARD_ENABLE
+
+int arch_cpu_init_dm(void)
+{
+   return board_walk_opt_phase(BOARD_F_ARCH_CPU_INIT_DM);
+}
+
+int board_early_init_f(void)
+{
+   return board_walk_opt_phase(BOARD_F_EARLY_INIT_F);
+}
+
+int checkcpu(void)
+{
+   return board_walk_opt_phase(BOARD_F_CHECKCPU);
+}
+
+int misc_init_f(void)
+{
+   return board_walk_opt_phase(BOARD_F_MISC_INIT_F);
+}
+
+int dram_init(void)
+{
+   return board_walk_phase(BOARD_F_DRAM_INIT);
+}
+
+int reserve_arch(void)
+{
+   return board_walk_opt_phase(BOARD_F_RESERVE_ARCH);
+}
+
+#else
+
 /* Architecture-specific memory reservation */
 __weak int reserve_arch(void)
 {
@@ -829,6 +864,7 @@ __weak int arch_cpu_init_dm(void)
 {
return 0;
 }
+#endif /* !CONFIG_BOARD_ENABLE_ENABLED */
 
 static const init_fnc_t init_sequence_f[] = {
 #ifdef CONFIG_SANDBOX
@@ -851,7 +887,7 @@ static const init_fnc_t init_sequence_f[] = {
initf_dm,
arch_cpu_init_dm,
mark_bootstage, /* need timer, go after init dm */
-#if defined(CONFIG_BOARD_EARLY_INIT_F)
+#if defined(CONFIG_BOARD_EARLY_INIT_F) || defined(CONFIG_BOARD_ENABLE)
board_early_init_f,
 #endif
/* TODO: can any of this go into arch_cpu_init()? */
@@ -898,7 +934,8 @@ static const init_fnc_t init_sequence_f[] = {
 #if defined(CONFIG_MPC83xx)
prt_83xx_rsr,
 #endif
-#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SH)
+#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SH) || \
+   defined(CONFIG_BOARD_ENABLE)
checkcpu,
 #endif
 #if defined(CONFIG_DISPLAY_CPUINFO)
@@ -908,7 +945,7 @@ static const init_fnc_t init_sequence_f[] = {
show_board_info,
 #endif
INIT_FUNC_WATCHDOG_INIT
-#if defined(CONFIG_MISC_INIT_F)
+#if defined(CONFIG_MISC_INIT_F) || defined(CONFIG_BOARD_ENABLE)
misc_init_f,
 #endif
INIT_FUNC_WATCHDOG_RESET
@@ -922,7 +959,7 @@ static const init_fnc_t init_sequence_f[] = {
/* TODO: unify all these dram functions? */
 #if defined(CONFIG_ARM) || defined(CONFIG_X86) || defined(CONFIG_NDS32) || \
defined(CONFIG_MICROBLAZE) || defined(CONFIG_AVR32) || \
-   defined(CONFIG_SH)
+   defined(CONFIG_SH) || defined(CONFIG_SANDBOX)
dram_init,  /* configure available RAM banks */
 #endif
 #if defined(CONFIG_MIPS) || defined(CONFIG_PPC) || defined(CONFIG_M68K)
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 08/16] dm: sandbox: Convert to using driver-model baord init

2017-03-19 Thread Simon Glass
Adjust the existing hooks to use a driver instead.

Signed-off-by: Simon Glass 
---

 arch/Kconfig|  3 +++
 board/sandbox/sandbox.c | 44 ++--
 2 files changed, 41 insertions(+), 6 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 76c690f667..f07070db18 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -64,6 +64,9 @@ config SANDBOX
bool "Sandbox"
select BOARD_LATE_INIT
select SUPPORT_OF_CONTROL
+   select BOARD
+   select SPL_BOARD
+   select BOARD_ENABLE
select DM
select DM_KEYBOARD
select DM_SPI_FLASH
diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index b41e9decb3..1eea20cbcb 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -41,12 +42,6 @@ unsigned long timer_read_counter(void)
 }
 #endif
 
-int dram_init(void)
-{
-   gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
-   return 0;
-}
-
 #ifdef CONFIG_BOARD_LATE_INIT
 int board_late_init(void)
 {
@@ -63,3 +58,40 @@ int board_late_init(void)
return 0;
 }
 #endif
+
+static int sandbox_phase(struct udevice *dev, enum board_phase_t phase)
+{
+   struct sandbox_state *state = state_get_current();
+
+   switch (phase) {
+   case BOARD_F_DRAM_INIT:
+   gd->ram_size = state->ram_size;
+   return 0;
+   default:
+   return -ENOSYS;
+   }
+
+   return 0;
+}
+
+static int sandbox_board_probe(struct udevice *dev)
+{
+   return board_support_phase(dev, BOARD_F_DRAM_INIT);
+}
+
+static const struct board_ops sandbox_board_ops = {
+   .phase  = sandbox_phase,
+};
+
+/* Name this starting with underscore so it will be called last */
+U_BOOT_DRIVER(_sandbox_board_drv) = {
+   .name   = "sandbox_board",
+   .id = UCLASS_BOARD,
+   .ops= _board_ops,
+   .probe  = sandbox_board_probe,
+   .flags  = DM_FLAG_PRE_RELOC,
+};
+
+U_BOOT_DEVICE(sandbox_board) = {
+   .name   = "sandbox_board",
+};
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 03/16] x86: config: Enable dhrystone command for link

2017-03-19 Thread Simon Glass
Enable this command so we can get an approximate performance measurement.

Signed-off-by: Simon Glass 
---

 configs/chromebook_link64_defconfig | 1 +
 configs/chromebook_link_defconfig   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/chromebook_link64_defconfig 
b/configs/chromebook_link64_defconfig
index 3ab34cd72b..749cfd43b0 100644
--- a/configs/chromebook_link64_defconfig
+++ b/configs/chromebook_link64_defconfig
@@ -86,4 +86,5 @@ CONFIG_FRAMEBUFFER_VESA_MODE_11A=y
 CONFIG_VIDEO_IVYBRIDGE_IGD=y
 CONFIG_CONSOLE_SCROLL_LINES=5
 CONFIG_USE_PRIVATE_LIBGCC=y
+CONFIG_CMD_DHRYSTONE=y
 CONFIG_TPM=y
diff --git a/configs/chromebook_link_defconfig 
b/configs/chromebook_link_defconfig
index 85b7d5fcd9..5ebb556f90 100644
--- a/configs/chromebook_link_defconfig
+++ b/configs/chromebook_link_defconfig
@@ -69,4 +69,5 @@ CONFIG_FRAMEBUFFER_VESA_MODE_11A=y
 CONFIG_VIDEO_IVYBRIDGE_IGD=y
 CONFIG_CONSOLE_SCROLL_LINES=5
 CONFIG_USE_PRIVATE_LIBGCC=y
+CONFIG_CMD_DHRYSTONE=y
 CONFIG_TPM=y
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 02/16] x86: Display the SPL banner only once

2017-03-19 Thread Simon Glass
At present on a cold reboot we must reset the CPU to get it to full speed.
With 64-bit U-Boot this happens in SPL. At present we print the banner
before doing this, the end result being that we print the banner twice.
Print the banner a little later (after the CPU is ready) to avoid this.

Signed-off-by: Simon Glass 
---

 arch/x86/lib/spl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
index ed2d40b552..fa93d64a7a 100644
--- a/arch/x86/lib/spl.c
+++ b/arch/x86/lib/spl.c
@@ -37,8 +37,6 @@ static int x86_spl_init(void)
debug("%s: spl_init() failed\n", __func__);
return ret;
}
-   preloader_console_init();
-
ret = arch_cpu_init();
if (ret) {
debug("%s: arch_cpu_init() failed\n", __func__);
@@ -49,6 +47,7 @@ static int x86_spl_init(void)
debug("%s: arch_cpu_init_dm() failed\n", __func__);
return ret;
}
+   preloader_console_init();
ret = print_cpuinfo();
if (ret) {
debug("%s: print_cpuinfo() failed\n", __func__);
-- 
2.12.0.367.g23dc2f6d3c-goog

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


[U-Boot] [PATCH 01/16] x86: Drop leading spaces in cpu_x86_get_desc()

2017-03-19 Thread Simon Glass
The Intel CPU name can have leading spaces. Remove them since they are not
useful.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/cpu_x86.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/cpu/cpu_x86.c b/arch/x86/cpu/cpu_x86.c
index 8be14b5929..b465b14a94 100644
--- a/arch/x86/cpu/cpu_x86.c
+++ b/arch/x86/cpu/cpu_x86.c
@@ -41,10 +41,14 @@ int cpu_x86_get_vendor(struct udevice *dev, char *buf, int 
size)
 
 int cpu_x86_get_desc(struct udevice *dev, char *buf, int size)
 {
+   char *ptr;
+
if (size < CPU_MAX_NAME_LEN)
return -ENOSPC;
 
-   cpu_get_name(buf);
+   ptr = cpu_get_name(buf);
+   if (ptr != buf)
+   strcpy(buf, ptr);
 
return 0;
 }
-- 
2.12.0.367.g23dc2f6d3c-goog

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


Re: [U-Boot] [PATCH v2 10/14] drivers: net: phy: add MV88E6xx options to Kconfig

2017-03-19 Thread Joe Hershberger
On Fri, Mar 17, 2017 at 9:29 AM, Tim Harvey  wrote:
> Signed-off-by: Tim Harvey 
> ---
> v2: moved options to drivers/net/phy where MV88E6xx config already lived
>
> Signed-off-by: Tim Harvey 
> ---

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


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

2017-03-19 Thread Stefano Babic
Hi Tom,

please pull from u-boot-imx, thanks !

The following changes since commit 2808576491ae36b6ea96743005058f370d936beb:

  arm64: booti: allow to place kernel image anywhere in physical memory
(2017-03-14 20:40:23 -0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to d883fcc6bbb2fcc3df90857fee99c2f543a0289c:

  imx: ventana: add EMMC configuration (2017-03-19 17:39:59 +0100)


Fabio Estevam (3):
  mx7: Fix speed grade entry
  mx7: Fix the get_cpu_speed_grade_hz() return values
  mx7: Add 1.2GHz speed grade entry

Jagan Teki (25):
  configs: imx6: Don't define USDHC2_BASE_ADDR
  arm: imx6ul: Add Engicam Is.IoT MX6UL Starter Kit initial support
  arm: dts: imx6ul-isiot: Add I2C nodes
  imx6: isiotmx6ul: Add I2C support
  arm: dts: imx6ul-isiot: Add FEC node
  imx6: isiotmx6ul: Add FEC support
  imx6: isiotmx6ul: Add NAND support
  imx6: isiotmx6ul: Add nandboot env support
  imx6ul: isiotmx6ul: Enable I2C support
  i.MX6: engicam: Include dts files under MAINTAINERS
  imx6: Add imx6_src_get_boot_mode
  imx: spl: Update NAND bootmode detection bit
  imx: Use IMX6_BMODE_* macros instead of numericals
  imx6: Add src_base structure define macro
  imx6: isiotmx6ul: Update SPL board boot order for eMMC
  i.MX6UL: isiot: Add eMMC boot support
  i.MX6UL: isiot: Add modeboot env via board_late_init
  i.MX6UL: isiot: Add mmc_late_init
  i.MX6UL: isiot: Switch the mmc env based on devno
  arm: dts: imx6qdl-icore-rqs: Add eMMC node
  imx6: icorem6_rqs: Update SPL board boot order for eMMC
  imx6: icorem6_rqs: Add eMMC boot support
  i.MX6Q: icorem6_rqs: Add modeboot env via board_late_init
  i.MX6Q: icorem6_rqs: Add mmc_late_init
  i.MX6Q: isiot: Switch the mmc env based on devno

Lukasz Majewski (1):
  MCCMON6: defconfig: Move 'quiet' console parameter to 'console'
env variable

Markus Niebel (7):
  imx6: tqma6: implement power_init_board
  imx6: tqma6: use lower driver stength for I2C pins
  imx6: tqma6: disable spi CS unused in U-Boot
  imx6: tqma6: adjust ethernet phy reset delay
  mx6: tqma6: clear enet clk sel for mba6
  arm: imx6: tqma6: use CONFIG_TQM6x for SOM specific settings
  arm: imx6: tqma6: add support for TQMa6DL variant

Peng Fan (17):
  imx: mx7ulp: Add mx7ulp to Kconfig
  imx: mx7ulp: add registers header file
  imx: mx7ulp: add iomux driver to support IOMUXC0 and IOMUXC1
  imx: mx7ulp: Add clock framework and functions
  imx: mx7ulp: Add soc level initialization codes and functions
  gpio: Add Rapid GPIO2P driver for i.MX7ULP
  mxc_ocotp: Update driver to support OCOTP controller on i.MX7ULP
  pinctrl: Add i.MX7ULP pinctrl driver
  i2c: lpi2c: add lpi2c driver for i.MX7ULP
  serial: lpuart: restructure lpuart driver
  serial: lpuart: add i.MX7ULP support
  mx7ulp: Add HAB boot support
  arm: dts: add i.MX7ULP dtsi file
  mmc: fsl_esdhc: support i.MX7ULP
  imx: imx7ulp: add EVK board support
  imx: mx7ulp_evk: enable mmc/regulator support
  tools: imximage: add set bit command

Stefan Agner (8):
  toradex apalis/colibri: use common USB product id fallback
  toradex apalis/colibri: add device tree overlay support
  colibri_imx7/colibri_imx6/apalis_imx6: limit bootm memory
  colibri_imx7: implement board level USB PHY mode
  colibri_imx7: setup PMIC sleep mode configuration
  colibri_imx7: use device-tree for MTD partitions
  colibri_imx7: split and resize firmware MTD partition
  ARM: vf610: move to standard arch/board approach

Sébastien Szymanski (3):
  dm: imx: serial: add i.MX6UL support
  arm: i.MX6UL: add Armadeus Systems OPOS6UL SoM and OPOS6ULDev
carrier board
  arm: dts: imx6ul: add usbotg aliases

Tim Harvey (9):
  imx: ventana: add additional DRAM configurations
  imx: ventana: config: add gzwrite support
  imx: ventana: move mmc_init to common
  imx: ventana: use mmc_root in boot scripts
  imx: ventana: change name of rs232_en to indicate polarity
  imx: ventana: fix hwconfig
  imx: ventana: make OTG VBUS power enable board specific
  imx: ventana: make SD3_VSELECT board specific
  imx: ventana: add EMMC configuration

Ye Li (3):
  imx: mx7ulp: Implement the clock functions for i2c driver
  mx7ulp: Add iomux pins header file
  wdog: Add the watchdog driver for MX7ULP.

 arch/arm/Kconfig  |   36 ++
 arch/arm/Makefile |2 +-
 arch/arm/cpu/armv7/Makefile   |3 +-
 arch/arm/cpu/armv7/mx6/Kconfig|   27 
 arch/arm/cpu/armv7/mx6/Makefile   |1 +
 arch/arm/cpu/armv7/mx6/opos6ul.c  

Re: [U-Boot] [PATCH v2 10/14] drivers: net: phy: add MV88E6xx options to Kconfig

2017-03-19 Thread Stefano Babic
Hi Tim,

On 17/03/2017 15:29, Tim Harvey wrote:
> Signed-off-by: Tim Harvey 
> ---
> v2: moved options to drivers/net/phy where MV88E6xx config already lived
> 
> Signed-off-by: Tim Harvey 
> ---
>  drivers/net/phy/Kconfig | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 1d514e9..6ee8bc3 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -15,6 +15,19 @@ if PHYLIB
>  config MV88E61XX_SWITCH
>   bool "Marvel MV88E61xx Ethernet switch PHY support."
>  
> +if MV88E61XX_SWITCH
> +
> +config MV88E61XX_CPU_PORT
> + int "CPU Port"
> +
> +config MV88E61XX_PHY_PORTS
> + hex "Bitmask of PHY Ports"
> +
> +config MV88E61XX_FIXED_PORTS
> + hex "Bitmask of PHYless serdes Ports"
> +
> +endif # MV88E61XX_SWITCH
> +
>  config PHYLIB_10G
>   bool "Generic 10G PHY support"
>  
> 

Reviewed-by: Stefano Babic 

Tim, I have already applied 1-9 to u-boot-imx- Last patches depend on
this one, so I let them in stand-by.

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 13/17] aspeed: Add support for Clocks needed by MACs

2017-03-19 Thread Tom Rini
On Thu, Mar 16, 2017 at 02:36:20PM -0700, Maxim Sloyko wrote:
> Add support for clocks needed by MACs to ast2500 clock driver.
> The clocks are D2-PLL, which is used by both MACs and PCLK_MAC1 and
> PCLK_MAC2 for MAC1 and MAC2 respectively.
> 
> The rate of D2-PLL is hardcoded to 250MHz -- the value used in Aspeed
> SDK. It is not entirely clear from the datasheet how this clock is used
> by MACs, so not clear if the rate would ever need to be different. So,
> for now, hardcoding it is probably safer.
> 
> The rate of PCLK_MAC{1,2} is chosen based on MAC speed selected through
> hardware strapping.
> 
> So, the network driver would only need to enable these clocks, no need
> to configure the rate.
> 
> Signed-off-by: Maxim Sloyko 
> ---
> 
>  arch/arm/dts/ast2500-u-boot.dtsi   |   8 +
>  arch/arm/include/asm/arch-aspeed/scu_ast2500.h |  62 +-
>  drivers/clk/aspeed/clk_ast2500.c   | 265 
> ++---
>  include/dt-bindings/clock/ast2500-scu.h|   2 +
>  4 files changed, 304 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/arm/dts/ast2500-u-boot.dtsi 
> b/arch/arm/dts/ast2500-u-boot.dtsi
> index faeeec1be4..f826646095 100644
> --- a/arch/arm/dts/ast2500-u-boot.dtsi
> +++ b/arch/arm/dts/ast2500-u-boot.dtsi
> @@ -61,3 +61,11 @@
>   };
>   };
>  };
> +
> + {
> + clocks = < PCLK_MAC1>, < PLL_D2PLL>;
> +};
> +
> + {
> + clocks = < PCLK_MAC2>, < PLL_D2PLL>;
> +};

Why is this here and not in the main dts file?  The -u-boot.dtsi is for
stuff that's not appropriate in the upstream dts file.  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 3/3] mx7: Add 1.2GHz speed grade entry

2017-03-19 Thread Stefano Babic


On 22/02/2017 16:43, Fabio Estevam wrote:
> There are recent MX7 parts that have a 1.2GHz speed grade.
> 
> Add support for it.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/cpu/armv7/mx7/soc.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/mx7/soc.c b/arch/arm/cpu/armv7/mx7/soc.c
> index 8cde77b..8422f24 100644
> --- a/arch/arm/cpu/armv7/mx7/soc.c
> +++ b/arch/arm/cpu/armv7/mx7/soc.c
> @@ -105,6 +105,7 @@ struct imx_sec_config_fuse_t const imx_sec_config_fuse = {
>  #define OCOTP_TESTER3_SPEED_800MHZ   0
>  #define OCOTP_TESTER3_SPEED_500MHZ   1
>  #define OCOTP_TESTER3_SPEED_1GHZ 2
> +#define OCOTP_TESTER3_SPEED_1P2GHZ   3
>  
>  u32 get_cpu_speed_grade_hz(void)
>  {
> @@ -125,6 +126,8 @@ u32 get_cpu_speed_grade_hz(void)
>   return 5;
>   case OCOTP_TESTER3_SPEED_1GHZ:
>   return 10;
> + case OCOTP_TESTER3_SPEED_1P2GHZ:
> + return 12;
>   }
>   return 0;
>  }
> 
Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH 2/3] mx7: Fix the get_cpu_speed_grade_hz() return values

2017-03-19 Thread Stefano Babic


On 22/02/2017 16:43, Fabio Estevam wrote:
> According to the MX7D fuse map the following speed grades are available:
> 
> 800  MHz
> 500  MHz
> 1000 MHz
> 1200 MHz
> 
> So simply return the real frequency that corresponds to the speed grade.
> 
> With this change we see on boot:
> 
> CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
> 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/cpu/armv7/mx7/soc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/mx7/soc.c b/arch/arm/cpu/armv7/mx7/soc.c
> index b9fb97b..8cde77b 100644
> --- a/arch/arm/cpu/armv7/mx7/soc.c
> +++ b/arch/arm/cpu/armv7/mx7/soc.c
> @@ -120,11 +120,11 @@ u32 get_cpu_speed_grade_hz(void)
>  
>   switch(val) {
>   case OCOTP_TESTER3_SPEED_800MHZ:
> - return 79200;
> + return 8;
>   case OCOTP_TESTER3_SPEED_500MHZ:
>   return 5;
>   case OCOTP_TESTER3_SPEED_1GHZ:
> - return 99600;
> + return 10;
>   }
>   return 0;
>  }
> 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH 1/3] mx7: Fix speed grade entry

2017-03-19 Thread Stefano Babic


On 22/02/2017 16:43, Fabio Estevam wrote:
> According to the MX7D fuse map the speed grade of the parts, which
> return '1' is 500MHz instead of 850MHz, so fix it accordingly.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/cpu/armv7/mx7/soc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/mx7/soc.c b/arch/arm/cpu/armv7/mx7/soc.c
> index dead1d3..b9fb97b 100644
> --- a/arch/arm/cpu/armv7/mx7/soc.c
> +++ b/arch/arm/cpu/armv7/mx7/soc.c
> @@ -103,7 +103,7 @@ struct imx_sec_config_fuse_t const imx_sec_config_fuse = {
>   */
>  #define OCOTP_TESTER3_SPEED_SHIFT8
>  #define OCOTP_TESTER3_SPEED_800MHZ   0
> -#define OCOTP_TESTER3_SPEED_850MHZ   1
> +#define OCOTP_TESTER3_SPEED_500MHZ   1
>  #define OCOTP_TESTER3_SPEED_1GHZ 2
>  
>  u32 get_cpu_speed_grade_hz(void)
> @@ -121,8 +121,8 @@ u32 get_cpu_speed_grade_hz(void)
>   switch(val) {
>   case OCOTP_TESTER3_SPEED_800MHZ:
>   return 79200;
> - case OCOTP_TESTER3_SPEED_850MHZ:
> - return 85200;
> + case OCOTP_TESTER3_SPEED_500MHZ:
> + return 5;
>   case OCOTP_TESTER3_SPEED_1GHZ:
>   return 99600;
>   }
> 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH 0/7] Toradex config cleanup and Colibri iMX7 enhencements

2017-03-19 Thread Stefano Babic


On 10/03/2017 02:17, Stefan Agner wrote:
> From: Stefan Agner 
> 
> The first two patches are common to all our modules, the next is
> touching all our NXP based modules and the rest of the patches are
> Colibri iMX7 related. Since all patches touch defconfig splitting
> them would lead to merge issues, so I kept them in a single patch
> set. Can this still go through your tree Stefano, including the
> first two patches?
> 
> The patchset is build tested for all our modules and run tested
> on Colibri iMX7.
> 
> --
> Stefan
> 
> 
> Stefan Agner (7):
>   toradex apalis/colibri: use common USB product id fallback
>   toradex apalis/colibri: add device tree overlay support
>   colibri_imx7/colibri_imx6/apalis_imx6: limit bootm memory
>   colibri_imx7: implement board level USB PHY mode
>   colibri_imx7: setup PMIC sleep mode configuration
>   colibri_imx7: use device-tree for MTD partitions
>   colibri_imx7: split and resize firmware MTD partition
> 
>  board/toradex/colibri_imx7/colibri_imx7.c | 57 
> +++
>  configs/apalis_imx6_defconfig |  3 +-
>  configs/apalis_t30_defconfig  |  7 ++--
>  configs/colibri_imx6_defconfig|  3 +-
>  configs/colibri_imx6_nospl_defconfig  |  2 +-
>  configs/colibri_imx7_defconfig|  4 ++-
>  configs/colibri_t20_defconfig |  7 ++--
>  configs/colibri_t30_defconfig |  7 ++--
>  configs/colibri_vf_defconfig  |  3 +-
>  include/configs/apalis_imx6.h |  1 +
>  include/configs/colibri_imx6.h|  1 +
>  include/configs/colibri_imx7.h|  9 +++--
>  12 files changed, 87 insertions(+), 17 deletions(-)
> 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH 1/3] Kconfig: make CONFIG_BAUDRATE a first-class citizen

2017-03-19 Thread Tom Rini
On Fri, Mar 17, 2017 at 08:34:53PM +0100, Philipp Tomsich wrote:

> Signed-off-by: Philipp Tomsich 

I'll migrate this and reword the commit slightly, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCHv2] arm: Migrate SYS_THUMB_BUILD to Kconfig, introduce SPL_SYS_THUMB_BUILD

2017-03-19 Thread Tom Rini
On Sat, Mar 18, 2017 at 09:01:44AM -0400, Tom Rini wrote:

> Today, we have cases where we wish to build all of U-Boot in Thumb2 mode for
> various reasons.  We also have cases where we only build SPL in Thumb2 mode 
> due
> to size constraints and wish to build the rest of the system in ARM mode.  So
> in this migration we introduce a new symbol as well, SPL_SYS_THUMB_BUILD to
> control if we build everything or just SPL (or in theory, just U-Boot) in
> Thumb2 mode.
> 
> Signed-off-by: Tom Rini 
> Acked-by: Siarhei Siamashka 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v3] Add single register pin controller driver

2017-03-19 Thread Felix Brack
Hi James,

On 11.03.2017 12:52, James wrote:
> Hi Felix,
> 
> Not 'hijacking' a patch, just following Linux Developer's Certificate of
> Origin 1.1 guidelines.
> 
> As you know, I contacted you directly with this patch suggestion prior
> to posting to the mailing list (keeping strictly to rule c). I had hoped
> you would make a new version:

See following remark please.

> 
>> On 09.03.2017 08:53, James Balean wrote:
>>> Did you want to test/submit this?
> 
> Perhaps I misinterpreted your response, which stated:
> 

My answer to the question above was: 'If required I will fix and test
things myself. I will then post the next version of the patch ASAP, for
a further review of course.' Please quote completely and correctly.

> On Fri, 10 Mar 2017 at 04:13, Felix Brack  > wrote:
>> This and probably more has to be accessible by _all_ mailing list
> subscribers. Please post there.
> 
> This was confusing, as I could see no way to convert this work to a
> patch of your unapproved v2 patch (being new to this process).
>

Okay, maybe that was a bad formulation, sorry, I will try to rephrase.
Consider this to be my point of view rather then a rule being carved in
stone.
The patch originator posts the patch (this starts a new thread). Now the
probably most important part of the process starts: everyone is invited
to comment on the patch _within the newly started thread_. This will
make sure that the thread started by posting the patch contains all
information that would probably lead to further versions of that patch.
Also this will make sure that everyone interested will be able to follow
the entire discussion. These comments (your's too, of course) are
extremely appreciated - the more eyes looking at a patch, the better.
Whenever possible comments should also contain concrete suggestions
about how to do better as well as a little explanation about why to do
so (imho). After a more or less extensive process of commenting and
resubmitting of the patch the responsible custodian may finally pick it
up to be added to the U-Boot repository.

> On Sat, 11 Mar 2017 at 00:07, Felix Brack  > wrote:
>> Remove this "Signed-off-by" tag as I neither made nor tested these
> modifications. 
> 
> My understanding from the 'submitting patches' guide is that the square
> bracket nomenclature I used indicates minor changes to an existing
> patch, thereby providing you with credit whilst also denoting that you
> do not endorse the changes.
> 
>> What if I fix a
> bug in my v2 patch? Should I then increase from v2 to v4?
> 
> Perhaps someone can clarify, but it seems logical that the version
> number is in order of contribution to the project, rather than being
> tied to any specific user. Especially given the software license it is
> under.
> 
> 
> Kind regards,
> James Balean
> 

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


Re: [U-Boot] [PATCH v3] Add single register pin controller driver

2017-03-19 Thread Felix Brack
Hello Simon,

On 16.03.2017 23:52, Simon Glass wrote:
> Hi,
> 
> On 11 March 2017 at 04:52, James  wrote:
>> Hi Felix,
>>
>> Not 'hijacking' a patch, just following Linux Developer's Certificate of
>> Origin 1.1 guidelines.
>>
>> As you know, I contacted you directly with this patch suggestion prior to
>> posting to the mailing list (keeping strictly to rule c). I had hoped you
>> would make a new version:
>>
>>> On 09.03.2017 08:53, James Balean wrote:
 Did you want to test/submit this?
>>
>> Perhaps I misinterpreted your response, which stated:
>>
>> On Fri, 10 Mar 2017 at 04:13, Felix Brack  wrote:
>>> This and probably more has to be accessible by _all_ mailing list
>> subscribers. Please post there.
>>
>> This was confusing, as I could see no way to convert this work to a patch
>> of your unapproved v2 patch (being new to this process).
>>
>> On Sat, 11 Mar 2017 at 00:07, Felix Brack  wrote:
>>> Remove this "Signed-off-by" tag as I neither made nor tested these
>> modifications.
>>
>> My understanding from the 'submitting patches' guide is that the square
>> bracket nomenclature I used indicates minor changes to an existing patch,
>> thereby providing you with credit whilst also denoting that you do not
>> endorse the changes.
>>
>>> What if I fix a
>> bug in my v2 patch? Should I then increase from v2 to v4?
>>
>> Perhaps someone can clarify, but it seems logical that the version number
>> is in order of contribution to the project, rather than being tied to any
>> specific user. Especially given the software license it is under.
> 
> It is better to make comments on the patch and let the original author
> respin it. If you have not heard after a week then I suppose you can
> resend it with the changes, i.w.c. I think you DO need to keep the
> original author's sign-off and increment the version.
>



> Felix, are you planning to resend this?
>

Yes, I will try to do so next week.

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