[U-Boot] [PATCH] libfdt: Initialize the stack variable

2017-08-23 Thread tien . fong . chee
From: Tien Fong Chee 

Report Coverity log:
The code uses a variable that has not
been initialized, leading to unpredictable
or unintended results.

Signed-off-by: Tien Fong Chee 
---
 lib/libfdt/fdt_wip.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/libfdt/fdt_wip.c b/lib/libfdt/fdt_wip.c
index 45fb964..01adad0 100644
--- a/lib/libfdt/fdt_wip.c
+++ b/lib/libfdt/fdt_wip.c
@@ -115,7 +115,7 @@ int fdt_find_regions(const void *fdt, char * const inc[], 
int inc_count,
 struct fdt_region region[], int max_regions,
 char *path, int path_len, int add_string_tab)
 {
-   int stack[FDT_MAX_DEPTH];
+   int stack[FDT_MAX_DEPTH] = { 0 };
char *end;
int nextoffset = 0;
uint32_t tag;
-- 
1.7.7.4

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


Re: [U-Boot] [PATCH 4/4] sunxi: Remove the MMC index hack

2017-08-23 Thread Chen-Yu Tsai
On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard
 wrote:
> The current code, if there's both an eMMC and an MMC slot available on the
> board, will swap the MMC indices based on whether we booted from the eMMC
> or the MMC. This way, the MMC we're supposed to boot on will always have
> the index 0.
>
> However, this causes various issues, for example when using other
> components that base their behaviour on the MMC index, such as fastboot.
>
> Let's remove that hack, and take the opposite approach. The MMC will always
> have the same index, but the bootcmd will pick the same device than the one
> we booted from. This is done through the introduction of the mmc_bootdev
> environment variable that will be filled by the board code based on the
> boot device informations we can get from the SoC.
>
> In order to not introduce regressions, we also need to adjust the fastboot
> MMC device and the environment device in order to set it to the eMMC, over
> the MMC, like it used to be the case.
>
> Signed-off-by: Maxime Ripard 
> ---
>  board/sunxi/board.c| 20 ++--
>  include/configs/sunxi-common.h | 36 ++--
>  2 files changed, 36 insertions(+), 20 deletions(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index e1d48140878f..664c7d2d8126 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -492,20 +492,6 @@ int board_mmc_init(bd_t *bis)
> return -1;
>  #endif
>
> -#if !defined(CONFIG_SPL_BUILD) && CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
> -   /*
> -* On systems with an emmc (mmc2), figure out if we are booting from
> -* the emmc and if we are make it "mmc dev 0" so that boot.scr, etc.
> -* are searched there first. Note we only do this for u-boot proper,
> -* not for the SPL, see spl_boot_device().
> -*/
> -   if (readb(SPL_ADDR + 0x28) == SUNXI_BOOTED_FROM_MMC2) {
> -   /* Booting from emmc / mmc2, swap */
> -   mmc0->block_dev.devnum = 1;
> -   mmc1->block_dev.devnum = 0;
> -   }
> -#endif
> -
> return 0;
>  }
>  #endif
> @@ -725,12 +711,18 @@ int misc_init_r(void)
>
> setenv("fel_booted", NULL);
> setenv("fel_scriptaddr", NULL);
> +   setenv("mmc_bootdev", NULL);

This doesn't apply on master due to commit 382bee57f19b
("env: Rename setenv() to env_set()").

Works as advertised once fixed and applied.

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


Re: [U-Boot] [PATCH 2/4] arm: sunxi: compile spl_boot_device even for U-Boot

2017-08-23 Thread Chen-Yu Tsai
On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard
 wrote:
> U-Boot itself might need to identify the boot device, for example to be
> able to tell where to load the kernel from when several options are
> possible.
>
> Remove the guard preventing it from being compiled.
>
> Signed-off-by: Maxime Ripard 

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


Re: [U-Boot] [PATCH] blk: Remove various places that do flush cache after read

2017-08-23 Thread Y.b. Lu


> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Wednesday, August 23, 2017 1:29 PM
> To: Y.b. Lu
> Cc: Qiang Zhao; York Sun; Grygorii Strashko; Michal Simek; Angelo
> Dureghello; Kever Yang; Jaehoon Chung; Albert Aribaud; Marcel Ziswiler;
> Markus Niebel; Z.q. Hou; Sumit Garg; Joe Hershberger; Stefan Roese;
> Wenbin Song; Simon Glass; Max Krummenacher; Masahiro Yamada; Tomas Melin;
> Q.y. Gong; Tom Rini; U-Boot Mailing List
> Subject: Re: [PATCH] blk: Remove various places that do flush cache after
> read
> 
> Hi Yangbo,
> 
> On Wed, Aug 23, 2017 at 11:29 AM, Y.b. Lu  wrote:
> > cmd/mmc.c
> >
> > Maybe SD controller on some vendor platforms doesn't support SNOOP.
> > flush_cache() is required to sync between DDR and cache.
> > Should be careful to remove this.
> >
> 
> Please do not top-posting.
> 
> What you mentioned if snoop is not supported, flush_cache() is required,
> is true, however that's not the issue I am trying to fix here. The
> flush_cache() here after a DMA read will cause issues because stale data
> in the cache will overwrite the correct data in the RAM that is DMAed by
> hardware (in this case, MMC controller).
> 

[Lu Yangbo-B47093] Sorry for my misunderstanding. It looks ok to me now.
flush_cache is indeed redundant after DMA reading.


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


Re: [U-Boot] [PATCH 3/4] sunxi: Use spl_boot_device

2017-08-23 Thread Chen-Yu Tsai
On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard
 wrote:
> Our current board code duplicates a bit the spl_boot_device logic. Now that
> we can use that function in the full-flavoured U-Boot, remove that
> duplication and call the function instead.
>
> Signed-off-by: Maxime Ripard 
> ---
>  board/sunxi/board.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 800f412b383d..e1d48140878f 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -720,11 +721,14 @@ static void setup_environment(const void *fdt)
>  int misc_init_r(void)
>  {
> __maybe_unused int ret;
> +   uint boot;
>
> setenv("fel_booted", NULL);
> setenv("fel_scriptaddr", NULL);

This doesn't apply on master due to commit 382bee57f19b
("env: Rename setenv() to env_set()")

ChenYu

> +
> +   boot = spl_boot_device();
> /* determine if we are running in FEL mode */
> -   if (!is_boot0_magic(SPL_ADDR + 4)) { /* eGON.BT0 */
> +   if (boot == BOOT_DEVICE_BOARD) {
> setenv("fel_booted", "1");
> parse_spl_header(SPL_ADDR);
> }
> --
> 2.13.5
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] x86: baytrail: Fix turbo enable

2017-08-23 Thread Bin Meng
On Thu, Aug 17, 2017 at 4:10 PM, Bin Meng  wrote:
> CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED must be turned on for Baytrail.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/cpu/baytrail/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Please pull u-boot-x86

2017-08-23 Thread Bin Meng
Hi Tom,

This contains various fixes and a reworked version of serial RX buffer
support. Hopefully this is the last PR from x86 for v2017.09.

The following changes since commit 90ae53ce1ae665a1b43ecf5ccafc339839392427:

  fastboot: Ensure we treat CONFIG_FASTBOOT_BUF_ADDR as long
(2017-08-22 08:20:02 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-x86.git

for you to fetch changes up to 438505fe696b176cbf56cd34db870e04027d3531:

  x86: tangier: kconfig: Guard tangier-specific options (2017-08-24
11:00:47 +0800)


Bin Meng (11):
  x86: ich-spi: Remove spi_write_protect_region()
  x86: ich-spi: Remove unnecessary assignment in ich_init_controller()
  x86: ich-spi: Don't read cached lock status
  x86: ich-spi: Move opcode registers configuration to another routine
  x86: fsp: Configure SPI opcode registers before SPI is locked down
  x86: kconfig: Imply CMD_PCI
  vbe: Drop vbe_get_video_info()
  x86: Convert CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED to Kconfig
  x86: baytrail: Fix turbo enable
  x86: bayleybay: Adjust VGA rom address
  x86: tangier: kconfig: Guard tangier-specific options

Stefan Roese (4):
  Revert "serial: ns16550: Add RX interrupt buffer support"
  serial: serial-uclass: Add generic serial RX buffer support
  x86: conga-qeval20-qa3-e3845: Select SERIAL_RX_BUFFER via Kconfig
  x86: dfi-bt700: Select SERIAL_RX_BUFFER via Kconfig

 arch/Kconfig|   1 +
 arch/x86/Kconfig|  16 ++
 arch/x86/cpu/baytrail/Kconfig   |   1 +
 arch/x86/cpu/tangier/Kconfig|   4 
 arch/x86/cpu/turbo.c|   2 +-
 arch/x86/lib/fsp/fsp_common.c   |  24
+
 board/congatec/conga-qeval20-qa3-e3845/Kconfig  |   1 +
 board/dfi/dfi-bt700/Kconfig |   1 +
 configs/bayleybay_defconfig |   3 +--
 configs/chromebook_link64_defconfig |   1 -
 configs/chromebook_link_defconfig   |   1 -
 configs/chromebook_samus_defconfig  |   1 -
 configs/chromebox_panther_defconfig |   1 -
 configs/conga-qeval20-qa3-e3845-internal-uart_defconfig |   1 -
 configs/conga-qeval20-qa3-e3845_defconfig   |   1 -
 configs/coreboot-x86_defconfig  |   1 -
 configs/cougarcanyon2_defconfig |   1 -
 configs/crownbay_defconfig  |   1 -
 configs/dfi-bt700-q7x-151_defconfig |   1 -
 configs/edison_defconfig|   1 +
 configs/efi-x86_defconfig   |   1 -
 configs/galileo_defconfig   |   1 -
 configs/minnowmax_defconfig |   1 -
 configs/qemu-x86_64_defconfig   |   1 -
 configs/qemu-x86_defconfig  |   1 -
 configs/qemu-x86_efi_payload32_defconfig|   1 -
 configs/qemu-x86_efi_payload64_defconfig|   1 -
 configs/som-db5800-som-6867_defconfig   |   1 -
 configs/theadorable-x86-dfi-bt700_defconfig |   1 -
 drivers/pci/pci_rom.c   |  41

 drivers/serial/Kconfig  |  19 ++---
 drivers/serial/ns16550.c| 123
+--
 drivers/serial/serial-uclass.c  |  48
--
 drivers/spi/ich.c   | 102
++--
 drivers/spi/ich.h   |   2 --
 include/ns16550.h   |  10 -
 include/serial.h|  10 -
 include/vbe.h   |   2 --
 scripts/config_whitelist.txt|   1 -
 39 files changed, 162 insertions(+), 269 deletions(-)

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


Re: [U-Boot] [PATCH 2/4] serial: serial-uclass: Add generic serial RX buffer support

2017-08-23 Thread Bin Meng
On Thu, Aug 17, 2017 at 3:11 PM, Bin Meng  wrote:
> On Wed, Aug 16, 2017 at 11:37 PM, Stefan Roese  wrote:
>> Pasting longer lines into the U-Boot console prompt sometimes leads to
>> characters missing. One problem here is the small 16-byte FIFO of the
>> legacy NS16550 UART, e.g. on x86 platforms.
>>
>> This patch now introduces a Kconfig option to enable RX buffer support
>> for all DM based serial drivers. With this option enabled, I was
>> able paste really long lines into the U-Boot console, without any
>> characters missing.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Simon Glass 
>> Cc: Bin Meng 
>> Cc: Tom Rini 
>> ---
>>  drivers/serial/Kconfig | 15 +
>>  drivers/serial/serial-uclass.c | 48 
>> --
>>  include/serial.h   | 10 -
>>  3 files changed, 70 insertions(+), 3 deletions(-)
>>
>
> Great!
>
> Reviewed-by: Bin Meng 
>
> Tested on MinnowMax
> Tested-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] x86: kconfig: Imply CMD_PCI

2017-08-23 Thread Bin Meng
On Wed, Aug 16, 2017 at 8:43 PM, Stefan Roese  wrote:
> On 16.08.2017 14:46, Bin Meng wrote:
>>
>> Let's imply the 'pci' command to access the de facto interconnect
>> bus in an x86 system.
>>
>> Signed-off-by: Bin Meng 
>
>
> Reviewed-by: Stefan Roese 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 3/4] x86: conga-qeval20-qa3-e3845: Select SERIAL_RX_BUFFER via Kconfig

2017-08-23 Thread Bin Meng
On Thu, Aug 17, 2017 at 3:11 PM, Bin Meng  wrote:
> On Wed, Aug 16, 2017 at 11:37 PM, Stefan Roese  wrote:
>> To support more input characters (longer stings pasted into the U-Boot
>> prompt) without dropping, lets selects the recently added UART RX
>> buffer for these boards.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Simon Glass 
>> Cc: Bin Meng 
>> ---
>>  board/congatec/conga-qeval20-qa3-e3845/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] x86: Convert CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED to Kconfig

2017-08-23 Thread Bin Meng
On Thu, Aug 17, 2017 at 4:10 PM, Bin Meng  wrote:
> This converts CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED to a Kconfig option.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/Kconfig | 7 +++
>  arch/x86/cpu/turbo.c | 2 +-
>  scripts/config_whitelist.txt | 1 -
>  3 files changed, 8 insertions(+), 2 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] x86: tangier: kconfig: Guard tangier-specific options

2017-08-23 Thread Bin Meng
On Mon, Aug 21, 2017 at 5:08 PM, Andy Shevchenko
 wrote:
> On Sun, 2017-08-20 at 04:33 -0700, Bin Meng wrote:
>> These options should not be exposed to other platforms.
>>
>
> Fair enough.
> Thanks for taking care of this!
>
> Acked-by: Andy Shevchenko 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] x86: bayleybay: Adjust VGA rom address

2017-08-23 Thread Bin Meng
On Sun, Aug 20, 2017 at 7:32 PM, Bin Meng  wrote:
> Adjust VGA rom address to 0xfffb so that u-boot.rom image can be
> built again.
>
> Signed-off-by: Bin Meng 
> ---
>
>  configs/bayleybay_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] Revert "serial: ns16550: Add RX interrupt buffer support"

2017-08-23 Thread Bin Meng
On Thu, Aug 17, 2017 at 3:11 PM, Bin Meng  wrote:
> On Wed, Aug 16, 2017 at 11:37 PM, Stefan Roese  wrote:
>> This reverts commit 6822cf3ec7c8768b8727573b8f4b2cb3d870b881.
>>
>> As Bin Meng has tested and pointed out, we don't need the RX interrupt
>> for the RX buffer support at all. Just reading all available characters
>> into a buffer is sufficient to solve the problem with the dropped
>> characters upon long lines pasted into the U-Boot prompt. Since this
>> RX buffer support can be implemented in a generic way, without any
>> device specifica (e.g. for the ns16550), I'll post a new patch with
>> a new serial RX buffer support for DM, which all DM based serial
>> drivers can use.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Simon Glass 
>> Cc: Bin Meng 
>> Cc: Tom Rini 
>> ---
>>  drivers/serial/Kconfig   |  10 
>>  drivers/serial/ns16550.c | 123 
>> ++-
>>  include/ns16550.h|  10 
>>  3 files changed, 5 insertions(+), 138 deletions(-)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4] x86: dfi-bt700: Select SERIAL_RX_BUFFER via Kconfig

2017-08-23 Thread Bin Meng
On Thu, Aug 17, 2017 at 3:11 PM, Bin Meng  wrote:
> On Wed, Aug 16, 2017 at 11:37 PM, Stefan Roese  wrote:
>> To support more input characters (longer stings pasted into the U-Boot
>> prompt) without dropping, lets selects the recently added UART RX
>> buffer for these boards.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Simon Glass 
>> Cc: Bin Meng 
>> ---
>>  board/dfi/dfi-bt700/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] vbe: Drop vbe_get_video_info()

2017-08-23 Thread Bin Meng
On Wed, Aug 16, 2017 at 10:35 PM, Bin Meng  wrote:
> With DM video, this is not used any more. Drop it.
>
> Signed-off-by: Bin Meng 
> ---
>
>  drivers/pci/pci_rom.c | 41 -
>  include/vbe.h |  2 --
>  2 files changed, 43 deletions(-)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/5] x86: ich-spi: Move opcode registers configuration to another routine

2017-08-23 Thread Bin Meng
On Wed, Aug 16, 2017 at 2:19 PM, Stefan Roese  wrote:
> On 16.08.2017 07:38, Bin Meng wrote:
>>
>> At present the ICH SPI opcode registers configuration is done in the
>> ich_spi_remove() routine, a little bit weird but that's how current.
>> Linux MTD driver works. This changes to move the opcode registers
>> configuration to a separate routine ich_spi_config_opcode() which
>> might be called by U-Boot itself as well.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>   drivers/spi/ich.c | 22 --
>>   1 file changed, 16 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
>> index d4888f5..373bc26 100644
>> --- a/drivers/spi/ich.c
>> +++ b/drivers/spi/ich.c
>> @@ -338,6 +338,21 @@ static int ich_status_poll(struct ich_spi_priv *ctlr,
>> u16 bitmask,
>> return -ETIMEDOUT;
>>   }
>>   +void ich_spi_config_opcode(struct udevice *dev)
>> +{
>> +   struct ich_spi_priv *ctlr = dev_get_priv(dev);
>> +
>> +   /*
>> +* PREOP, OPTYPE, OPMENU1/OPMENU2 registers can be locked down
>> +* to prevent accidental or intentional writes. Before they get
>> +* locked down, these registers should be initialized properly.
>> +*/
>> +   ich_writew(ctlr, SPI_OPPREFIX, ctlr->preop);
>> +   ich_writew(ctlr, SPI_OPTYPE, ctlr->optype);
>> +   ich_writel(ctlr, SPI_OPMENU_LOWER, ctlr->opmenu);
>> +   ich_writel(ctlr, SPI_OPMENU_UPPER, ctlr->opmenu + sizeof(u32));
>> +}
>> +
>>   static int ich_spi_xfer(struct udevice *dev, unsigned int bitlen,
>> const void *dout, void *din, unsigned long flags)
>>   {
>> @@ -585,16 +600,11 @@ static int ich_spi_probe(struct udevice *dev)
>> static int ich_spi_remove(struct udevice *bus)
>>   {
>> -   struct ich_spi_priv *ctlr = dev_get_priv(bus);
>> -
>> /*
>>  * Configure SPI controller so that the Linux MTD driver can fully
>>  * access the SPI NOR chip
>>  */
>> -   ich_writew(ctlr, SPI_OPPREFIX, ctlr->preop);
>> -   ich_writew(ctlr, SPI_OPTYPE, ctlr->optype);
>> -   ich_writel(ctlr, SPI_OPMENU_LOWER, ctlr->opmenu);
>> -   ich_writel(ctlr, SPI_OPMENU_UPPER, ctlr->opmenu + sizeof(u32));
>> +   ich_spi_config_opcode(bus);
>> return 0;
>>   }
>>
>
> Reviewed-by: Stefan Roese 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 5/5] x86: fsp: Configure SPI opcode registers before SPI is locked down

2017-08-23 Thread Bin Meng
On Wed, Aug 16, 2017 at 2:21 PM, Stefan Roese  wrote:
> On 16.08.2017 07:38, Bin Meng wrote:
>>
>> Some Intel FSP (like Braswell) does SPI lock-down during the call
>> to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is done,
>> it's bootloader's responsibility to configure the SPI controller's
>> opcode registers properly otherwise SPI controller driver doesn't
>> know how to communicate with the SPI flash device.
>>
>> This introduces a Kconfig option CONFIG_FSP_LOCKDOWN_SPI for such
>> FSPs. When it is on, U-Boot will configure the SPI opcode registers
>> before the lock-down.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>   arch/x86/Kconfig  |  9 +
>>   arch/x86/lib/fsp/fsp_common.c | 24 
>>   2 files changed, 33 insertions(+)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index c26710b..5373082 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -401,6 +401,15 @@ config FSP_BROKEN_HOB
>>   do not overwrite the important boot service data which is used
>> by
>>   FSP, otherwise the subsequent call to fsp_notify() will fail.
>>   +config FSP_LOCKDOWN_SPI
>> +   bool
>> +   depends on HAVE_FSP
>> +   help
>> + Some Intel FSP (like Braswell) does SPI lock-down during the
>> call
>> + to fsp_notify(INIT_PHASE_BOOT). This option should be turned on
>> + for such FSP and U-Boot will configure the SPI opcode registers
>> + before the lock-down.
>> +
>>   config ENABLE_MRC_CACHE
>> bool "Enable MRC cache"
>> depends on !EFI && !SYS_COREBOOT
>> diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
>> index 3397bb8..320d87d 100644
>> --- a/arch/x86/lib/fsp/fsp_common.c
>> +++ b/arch/x86/lib/fsp/fsp_common.c
>> @@ -19,6 +19,8 @@
>> DECLARE_GLOBAL_DATA_PTR;
>>   +extern void ich_spi_config_opcode(struct udevice *dev);
>> +
>>   int checkcpu(void)
>>   {
>> return 0;
>> @@ -49,6 +51,28 @@ void board_final_cleanup(void)
>>   {
>> u32 status;
>>   +#ifdef CONFIG_FSP_LOCKDOWN_SPI
>> +   struct udevice *dev;
>> +
>> +   /*
>> +* Some Intel FSP (like Braswell) does SPI lock-down during the
>> call
>> +* to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is
>> done,
>> +* it's bootloader's responsibility to configure the SPI
>> controller's
>> +* opcode registers properly otherwise SPI controller driver
>> doesn't
>> +* know how to communicate with the SPI flash device.
>> +*
>> +* Note we cannot do such configuration elsewhere (eg: during the
>> SPI
>> +* controller driver's probe() routine), becasue:
>
>
> because

Fixed this, and

>
>> +*
>> +* 1). U-Boot SPI controller driver does not set the lock-down bit
>> +* 2). Any SPI transfer will corrupt the contents of these
>> registers
>> +*
>> +* Hence we have to do it right here before SPI lock-down bit is
>> set.
>> +*/
>> +   if (!uclass_first_device_err(UCLASS_SPI, ))
>> +   ich_spi_config_opcode(dev);
>> +#endif
>> +
>> /* call into FspNotify */
>> debug("Calling into FSP (notify phase INIT_PHASE_BOOT): ");
>> status = fsp_notify(NULL, INIT_PHASE_BOOT);
>>
>
> Reviewed-by: Stefan Roese 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 3/5] x86: ich-spi: Don't read cached lock status

2017-08-23 Thread Bin Meng
On Wed, Aug 16, 2017 at 2:19 PM, Stefan Roese  wrote:
> On 16.08.2017 07:38, Bin Meng wrote:
>>
>> At present the ICH SPI controller driver reads the controller lock
>> status from its register in the probe routine and saves the lock
>> status to a member of priv. Later the driver uses the cached status
>> from priv to judge whether the controller setting is locked and do
>> different setup.
>>
>> But such logic is only valid when there is only the SPI controller
>> driver that touches the SPI hardware. In fact the lock status change
>> can be trigged outside the driver, eg: during the fsp_notify() call
>> when Intel FSP is used.
>>
>> This changes the driver to read the lock status every time when an
>> SPI transfer is initiated instead of reading the cached one.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>   drivers/spi/ich.c | 29 +++--
>>   drivers/spi/ich.h |  2 --
>>   2 files changed, 23 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
>> index 909eefc..d4888f5 100644
>> --- a/drivers/spi/ich.c
>> +++ b/drivers/spi/ich.c
>> @@ -126,7 +126,6 @@ static int ich_init_controller(struct udevice *dev,
>> if (plat->ich_version == ICHV_7) {
>> struct ich7_spi_regs *ich7_spi = sbase;
>>   - ctlr->ichspi_lock = readw(_spi->spis) & SPIS_LOCK;
>> ctlr->opmenu = offsetof(struct ich7_spi_regs, opmenu);
>> ctlr->menubytes = sizeof(ich7_spi->opmenu);
>> ctlr->optype = offsetof(struct ich7_spi_regs, optype);
>> @@ -141,7 +140,6 @@ static int ich_init_controller(struct udevice *dev,
>> } else if (plat->ich_version == ICHV_9) {
>> struct ich9_spi_regs *ich9_spi = sbase;
>>   - ctlr->ichspi_lock = readw(_spi->hsfs) & HSFS_FLOCKDN;
>> ctlr->opmenu = offsetof(struct ich9_spi_regs, opmenu);
>> ctlr->menubytes = sizeof(ich9_spi->opmenu);
>> ctlr->optype = offsetof(struct ich9_spi_regs, optype);
>> @@ -186,6 +184,23 @@ static inline void spi_use_in(struct spi_trans
>> *trans, unsigned bytes)
>> trans->bytesin -= bytes;
>>   }
>>   +static bool spi_lock_status(struct ich_spi_platdata *plat, void *sbase)
>> +{
>> +   int lock = 0;
>> +
>> +   if (plat->ich_version == ICHV_7) {
>> +   struct ich7_spi_regs *ich7_spi = sbase;
>> +
>> +   lock = readw(_spi->spis) & SPIS_LOCK;
>> +   } else if (plat->ich_version == ICHV_9) {
>> +   struct ich9_spi_regs *ich9_spi = sbase;
>> +
>> +   lock = readw(_spi->hsfs) & HSFS_FLOCKDN;
>> +   }
>> +
>> +   return lock != 0;
>> +}
>> +
>>   static void spi_setup_type(struct spi_trans *trans, int data_bytes)
>>   {
>> trans->type = 0xFF;
>> @@ -219,14 +234,15 @@ static void spi_setup_type(struct spi_trans *trans,
>> int data_bytes)
>> }
>>   }
>>   -static int spi_setup_opcode(struct ich_spi_priv *ctlr, struct spi_trans
>> *trans)
>> +static int spi_setup_opcode(struct ich_spi_priv *ctlr, struct spi_trans
>> *trans,
>> +   bool lock)
>>   {
>> uint16_t optypes;
>> uint8_t opmenu[ctlr->menubytes];
>> trans->opcode = trans->out[0];
>> spi_use_out(trans, 1);
>> -   if (!ctlr->ichspi_lock) {
>> +   if (!lock) {
>> /* The lock is off, so just use index 0. */
>> ich_writeb(ctlr, trans->opcode, ctlr->opmenu);
>> optypes = ich_readw(ctlr, ctlr->optype);
>> @@ -336,6 +352,7 @@ static int ich_spi_xfer(struct udevice *dev, unsigned
>> int bitlen,
>> struct spi_trans *trans = >trans;
>> unsigned type = flags & (SPI_XFER_BEGIN | SPI_XFER_END);
>> int using_cmd = 0;
>> +   bool lock = spi_lock_status(plat, ctlr->base);
>> int ret;
>> /* We don't support writing partial bytes */
>> @@ -399,7 +416,7 @@ static int ich_spi_xfer(struct udevice *dev, unsigned
>> int bitlen,
>> ich_writeb(ctlr, SPIS_CDS | SPIS_FCERR, ctlr->status);
>> spi_setup_type(trans, using_cmd ? bytes : 0);
>> -   opcode_index = spi_setup_opcode(ctlr, trans);
>> +   opcode_index = spi_setup_opcode(ctlr, trans, lock);
>> if (opcode_index < 0)
>> return -EINVAL;
>> with_address = spi_setup_offset(trans);
>> @@ -412,7 +429,7 @@ static int ich_spi_xfer(struct udevice *dev, unsigned
>> int bitlen,
>>  * in order to prevent the Management Engine from
>>  * issuing a transaction between WREN and DATA.
>>  */
>> -   if (!ctlr->ichspi_lock)
>> +   if (!lock)
>> ich_writew(ctlr, trans->opcode, ctlr->preop);
>> return 0;
>> }
>> diff --git a/drivers/spi/ich.h b/drivers/spi/ich.h
>> index dcb8a90..c867c57 100644
>> --- a/drivers/spi/ich.h
>> +++ b/drivers/spi/ich.h
>> @@ 

Re: [U-Boot] [PATCH 2/5] x86: ich-spi: Remove unnecessary assignment in ich_init_controller()

2017-08-23 Thread Bin Meng
On Wed, Aug 16, 2017 at 2:18 PM, Stefan Roese  wrote:
> On 16.08.2017 07:38, Bin Meng wrote:
>>
>> There is no need to do another assignment to ich7_spi.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>   drivers/spi/ich.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
>> index 46dd9a8..909eefc 100644
>> --- a/drivers/spi/ich.c
>> +++ b/drivers/spi/ich.c
>> @@ -126,7 +126,6 @@ static int ich_init_controller(struct udevice *dev,
>> if (plat->ich_version == ICHV_7) {
>> struct ich7_spi_regs *ich7_spi = sbase;
>>   - ich7_spi = (struct ich7_spi_regs *)sbase;
>> ctlr->ichspi_lock = readw(_spi->spis) & SPIS_LOCK;
>> ctlr->opmenu = offsetof(struct ich7_spi_regs, opmenu);
>> ctlr->menubytes = sizeof(ich7_spi->opmenu);
>>
>
> Reviewed-by: Stefan Roese 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/5] x86: ich-spi: Remove spi_write_protect_region()

2017-08-23 Thread Bin Meng
On Wed, Aug 16, 2017 at 2:18 PM, Stefan Roese  wrote:
> On 16.08.2017 07:38, Bin Meng wrote:
>>
>> This routine is not called anywhere.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>   drivers/spi/ich.c | 50
>> --
>>   1 file changed, 50 deletions(-)
>>
>> diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
>> index bf2e99b..46dd9a8 100644
>> --- a/drivers/spi/ich.c
>> +++ b/drivers/spi/ich.c
>> @@ -539,56 +539,6 @@ static int ich_spi_xfer(struct udevice *dev, unsigned
>> int bitlen,
>> return 0;
>>   }
>>   -/*
>> - * This uses the SPI controller from the Intel Cougar Point and Panther
>> Point
>> - * PCH to write-protect portions of the SPI flash until reboot. The
>> changes
>> - * don't actually take effect until the HSFS[FLOCKDN] bit is set, but
>> that's
>> - * done elsewhere.
>> - */
>> -int spi_write_protect_region(struct udevice *dev, uint32_t lower_limit,
>> -uint32_t length, int hint)
>> -{
>> -   struct udevice *bus = dev->parent;
>> -   struct ich_spi_priv *ctlr = dev_get_priv(bus);
>> -   uint32_t tmplong;
>> -   uint32_t upper_limit;
>> -
>> -   if (!ctlr->pr) {
>> -   printf("%s: operation not supported on this chipset\n",
>> -  __func__);
>> -   return -ENOSYS;
>> -   }
>> -
>> -   if (length == 0 ||
>> -   lower_limit > (0xUL - length) + 1 ||
>> -   hint < 0 || hint > 4) {
>> -   printf("%s(0x%x, 0x%x, %d): invalid args\n", __func__,
>> -  lower_limit, length, hint);
>> -   return -EPERM;
>> -   }
>> -
>> -   upper_limit = lower_limit + length - 1;
>> -
>> -   /*
>> -* Determine bits to write, as follows:
>> -*  31 Write-protection enable (includes erase operation)
>> -*  30:29  reserved
>> -*  28:16  Upper Limit (FLA address bits 24:12, with 11:0 ==
>> 0xfff)
>> -*  15 Read-protection enable
>> -*  14:13  reserved
>> -*  12:0   Lower Limit (FLA address bits 24:12, with 11:0 ==
>> 0x000)
>> -*/
>> -   tmplong = 0x8000 |
>> -   ((upper_limit & 0x01fff000) << 4) |
>> -   ((lower_limit & 0x01fff000) >> 12);
>> -
>> -   printf("%s: writing 0x%08x to %p\n", __func__, tmplong,
>> -  >pr[hint]);
>> -   ctlr->pr[hint] = tmplong;
>> -
>> -   return 0;
>> -}
>> -
>>   static int ich_spi_probe(struct udevice *dev)
>>   {
>> struct ich_spi_platdata *plat = dev_get_platdata(dev);
>>
>
> Reviewed-by: Stefan Roese 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 08/15] dm: mmc: sunxi: Pass private data around explicitly

2017-08-23 Thread Chen-Yu Tsai
On Tue, Aug 15, 2017 at 5:35 AM, Simon Glass  wrote:
> Hi Chen-Yu,
>
> On 8 August 2017 at 21:27, Chen-Yu Tsai  wrote:
>> Hi Simon,
>>
>> On Wed, Jul 5, 2017 at 3:31 AM, Simon Glass  wrote:
>>> At present the driver-private data is obtained in various functions by
>>> various means. With driver model this is provided automatically. Without
>>> driver model it comes from a C array declared at the top of the file.
>>>
>>> Adjust internal functions so that they are passed the private data as
>>> a parameter, allowing the caller to obtain it using either means.
>>>
>>> Signed-off-by: Simon Glass 
>>
>> eMMC is currently broken for sunxi on my Orangepi Plus 2E.
>> I've narrowed it down to this patch.
>>
>> It seems the driver or device is now referencing the wrong
>> controller. On versions before this patch, for MMC1 (or eMMC):
>>
>> => mmc dev 1
>> switch to partitions #0, OK
>> mmc1(part 0) is current device
>> => mmc info
>> Device: SUNXI SD/MMC
>> Manufacturer ID: 15
>> OEM: 100
>> Name: AWPD3
>> Tran Speed: 5200
>> Rd Block Len: 512
>> MMC version 5.0
>> High Capacity: Yes
>> Capacity: 14.6 GiB
>> Bus Width: 8-bit
>> Erase Group Size: 512 KiB
>> HC WP Group Size: 8 MiB
>> User Capacity: 14.6 GiB WRREL
>> Boot Capacity: 4 MiB ENH
>> RPMB Capacity: 4 MiB ENH
>>
>>
>> On later versions I get:
>>
>> => mmc dev 1
>> switch to partitions #0, OK
>> mmc1 is current device
>> => mmc info
>> Device: SUNXI SD/MMC
>> Manufacturer ID: 27
>> OEM: 5048
>> Name: SD08G
>> Tran Speed: 5000
>> Rd Block Len: 512
>> SD version 3.0
>> High Capacity: Yes
>> Capacity: 7.4 GiB
>> Bus Width: 1-bit
>> Erase Group Size: 512 Bytes
>>
>>
>> For reference, mmc0 looks like:
>>
>> => mmc dev 0
>> switch to partitions #0, OK
>> mmc0 is current device
>> => mmc info
>> Device: SUNXI SD/MMC
>> Manufacturer ID: 27
>> OEM: 5048
>> Name: SD08G
>> Tran Speed: 5000
>> Rd Block Len: 512
>> SD version 3.0
>> High Capacity: Yes
>> Capacity: 7.4 GiB
>> Bus Width: 4-bit
>> Erase Group Size: 512 Bytes
>>
>>
>> So it seems somewhere down the line, the driver is getting
>> passed the wrong set of priv data.
>
> Are you sure it was this patch?
>
> The ordering may have changed because there was a strange hack in the
> code before. There was some discussion about it but unfortunately I
> cannot find the thread right now. Can you take a look?

Indeed it was this patch. Maxime's latest patch [1] fixes it.
And looks like the hacks are on their way out as well.

ChenYu

[1] https://lists.denx.de/pipermail/u-boot/2017-August/303443.html
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] mmc: sunxi: fix legacy MMC initialisation

2017-08-23 Thread Chen-Yu Tsai
On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard
 wrote:
> The driver-model rework changed, among other things, the way the private
> data were moved around. It now uses the private field in the struct mmc.
>
> However, the mmc_create argument was changed in the process to always pass
> the array we used to have to store our private structures.
>
> The basically means that all the MMC driver instances will now have the
> private data of the first instance, which obviously doesn't work very well.
>
> Pass the proper pointer to mmc_create.
>
> Fixes: 034e226bc77e ("dm: mmc: sunxi: Pass private data around explicitly")
> Signed-off-by: Maxime Ripard 

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


Re: [U-Boot] [PATCH 1/2] [rfc] parse the second area of android image

2017-08-23 Thread Andy Yan
Hi Tom and other maintainers:

2017-07-13 2:25 GMT+08:00 Tom Rini :

> On Tue, Jul 11, 2017 at 03:56:03PM +1000, Bin Chen wrote:
>
> > The second area of android image was intended to put a 2nd stage
> > bootloader but in practice were rarely used (in my knowledge).
> >
> > An proposal was made to the AOSP to (re)use the second area as the
> dtb[1],
> > This patch itself doesn't depend on that proposal being accepted but it
> won't
> > be that helpful as well if that proposal won't be accepted. But don't do
> > any harm as well.
> >
> > [1] https://android-review.googlesource.com/#/c/417447/
> > Signed-off-by: Bin Chen 
>
> Reviewed-by: Tom Rini 
>
>

Can we get this patch applied now[1/2]?Because some  ARM32 platforms also
want to use the second area to stored dtb or other resource .



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


Re: [U-Boot] [PATCH] sunxi: Enable random UUIDs when GPT is enabled

2017-08-23 Thread Tom Rini
On Wed, Aug 23, 2017 at 04:06:55PM +0200, Maxime Ripard wrote:

> We can create GPT partitions without a UUID, but we need to have
> RANDOM_UUID enabled to do that. Enable it.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  include/configs/sunxi-common.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 07c7ffd7f204..75bf668ecdb3 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -270,6 +270,10 @@ extern int soft_i2c_gpio_scl;
>  /* GPIO */
>  #define CONFIG_SUNXI_GPIO
>  
> +#ifdef CONFIG_EFI_PARTITION
> +#define CONFIG_RANDOM_UUID   1
> +#endif
> +
>  #ifdef CONFIG_VIDEO
>  /*
>   * The amount of RAM to keep free at the top of RAM when relocating u-boot,

Can you please add a Kconfig entry for RANDOM_UUID in cmd/Kconfig under
CMD_GPT (the only user of the code) ?  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 v4 1/1] efi_loader: write protocol GUID in OpenProtocol

2017-08-23 Thread Heinrich Schuchardt
On 08/18/2017 05:45 PM, Heinrich Schuchardt wrote:
> To understand what is happening in OpenProtocol or LocateProtocol
> it is necessary to know the protocol interface GUID.
> Let's write a debug message.
> 
> Cc: Rob Clark 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v4:
>   use %pUl format string
>   correct indention of output
> v3:
>   commit message changed
> v2:
>   fix typo in commit message
> ---
>  include/efi_loader.h  |  8 
>  lib/efi_loader/efi_boottime.c | 11 +++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 870854fb61..5b20af808b 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -17,6 +17,7 @@
>  
>  int __efi_entry_check(void);
>  int __efi_exit_check(void);
> +const char *__efi_nesting(void);
>  const char *__efi_nesting_inc(void);
>  const char *__efi_nesting_dec(void);
>  
> @@ -64,6 +65,13 @@ const char *__efi_nesting_dec(void);
>   debug("%sEFI: Return From: %s\n", __efi_nesting_dec(), #exp); \
>   } while(0)
>  
> +/*
> + * Write GUID
> + */
> +#define EFI_PRINT_GUID(txt, guid) ({ \
> + debug("%sEFI: %s %pUl\n", __efi_nesting(), txt, guid); \
> + })
> +
>  extern struct efi_runtime_services efi_runtime_services;
>  extern struct efi_system_table systab;
>  
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 5aeaeeca75..6af033458b 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -112,6 +112,11 @@ static const char *indent_string(int level)
>   return [max - level];
>  }
>  
> +const char *__efi_nesting(void)
> +{
> + return indent_string(nesting_level);
> +}
> +
>  const char *__efi_nesting_inc(void)
>  {
>   return indent_string(nesting_level++);
> @@ -1163,6 +1170,8 @@ static efi_status_t EFIAPI 
> efi_locate_protocol(efi_guid_t *protocol,
>   if (!protocol || !protocol_interface)
>   return EFI_EXIT(EFI_INVALID_PARAMETER);
>  
> + EFI_PRINT_GUID("protocol", protocol);
> +
>   list_for_each(lhandle, _obj_list) {
>   struct efi_object *efiobj;
>  
> @@ -1366,6 +1375,8 @@ static efi_status_t EFIAPI efi_open_protocol(
>   goto out;
>   }
>  
> + EFI_PRINT_GUID("protocol", protocol);
> +
>   switch (attributes) {
>   case EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL:
>   case EFI_OPEN_PROTOCOL_GET_PROTOCOL:
> 

Hello Rob,

with the patch installed I sometimes got failures on Travis when grub is
loaded.
https://travis-ci.org/xypron2/u-boot/builds/267753128?utm_source=github_status_medium=notification

I added some code for debugging and found that after efi_exit is called
it opens the EFI_LOADED_IMAGE_PROTOCOL.

This leads to an error in __efi_entry_check():

do_bootefi_exec:270 Jumping to 0x9ee22400

previous call
/home/travis/build/xypron2/u-boot/lib/efi_loader/efi_boottime.c(869)
efi_exit, ret = 0

  EFI: protocol 5b1b31a1-9562-11d2-8e3f-00a0c969723b

previous call
/home/travis/build/xypron2/u-boot/lib/efi_loader/efi_boottime.c(1567)
efi_open_protocol, ret = 0

previous call
/home/travis/build/xypron2/u-boot/lib/efi_loader/efi_boottime.c(1365)
efi_locate_protocol, ret = 0

previous call
/home/travis/build/xypron2/u-boot/lib/efi_loader/efi_console.c(54)
efi_cin_get_mode, ret = 0

previous call
/home/travis/build/xypron2/u-boot/lib/efi_loader/efi_boottime.c(1365)
efi_locate_protocol, ret = 0

previous call
/home/travis/build/xypron2/u-boot/lib/efi_loader/efi_console.c(54)
efi_cin_get_mode, ret = 0

/home/travis/build/xypron2/u-boot/lib/efi_loader/efi_boottime.c:227:
efi_allocate_pages_ext: Assertion `__efi_entry_check()' failed.

resetting ...

I will work on a patch to fix it.

Regards

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


[U-Boot] [PATCH 6/8] include/configs: drop default definitions of CONFIG_SYS_MAXARGS

2017-08-23 Thread Thomas Petazzoni
Now that include/config_fallbacks.h define a sane fallback for
CONFIG_SYS_MAXARGS, we can drop the definition of this constant in all
configurations that were using the default value.

Signed-off-by: Thomas Petazzoni 
---
 include/configs/10m50_devboard.h  | 1 -
 include/configs/3c120_devboard.h  | 1 -
 include/configs/B4860QDS.h| 1 -
 include/configs/BSC9131RDB.h  | 1 -
 include/configs/BSC9132QDS.h  | 1 -
 include/configs/C29XPCIE.h| 1 -
 include/configs/M5208EVBE.h   | 1 -
 include/configs/M52277EVB.h   | 1 -
 include/configs/M5235EVB.h| 1 -
 include/configs/M5249EVB.h| 1 -
 include/configs/M5253DEMO.h   | 1 -
 include/configs/M5253EVBE.h   | 1 -
 include/configs/M5272C3.h | 1 -
 include/configs/M5275EVB.h| 1 -
 include/configs/M5282EVB.h| 1 -
 include/configs/M53017EVB.h   | 1 -
 include/configs/M5329EVB.h| 1 -
 include/configs/M5373EVB.h| 1 -
 include/configs/M54418TWR.h   | 1 -
 include/configs/M54451EVB.h   | 1 -
 include/configs/M54455EVB.h   | 1 -
 include/configs/M5475EVB.h| 1 -
 include/configs/M5485EVB.h| 1 -
 include/configs/MCR3000.h | 1 -
 include/configs/MPC8308RDB.h  | 1 -
 include/configs/MPC8313ERDB.h | 1 -
 include/configs/MPC8315ERDB.h | 1 -
 include/configs/MPC8323ERDB.h | 1 -
 include/configs/MPC832XEMDS.h | 1 -
 include/configs/MPC8349EMDS.h | 1 -
 include/configs/MPC8349ITX.h  | 1 -
 include/configs/MPC837XEMDS.h | 1 -
 include/configs/MPC837XERDB.h | 1 -
 include/configs/MPC8536DS.h   | 1 -
 include/configs/MPC8540ADS.h  | 1 -
 include/configs/MPC8541CDS.h  | 1 -
 include/configs/MPC8544DS.h   | 1 -
 include/configs/MPC8548CDS.h  | 1 -
 include/configs/MPC8555CDS.h  | 1 -
 include/configs/MPC8560ADS.h  | 1 -
 include/configs/MPC8568MDS.h  | 1 -
 include/configs/MPC8572DS.h   | 1 -
 include/configs/MPC8610HPCD.h | 1 -
 include/configs/MPC8641HPCN.h | 1 -
 include/configs/MigoR.h   | 1 -
 include/configs/P1010RDB.h| 1 -
 include/configs/P1022DS.h | 1 -
 include/configs/P1023RDB.h| 1 -
 include/configs/P2041RDB.h| 1 -
 include/configs/T102xQDS.h| 1 -
 include/configs/T102xRDB.h| 1 -
 include/configs/T1040QDS.h| 1 -
 include/configs/T104xRDB.h| 1 -
 include/configs/T208xQDS.h| 1 -
 include/configs/T208xRDB.h| 1 -
 include/configs/T4240RDB.h| 1 -
 include/configs/TQM834x.h | 1 -
 include/configs/UCP1020.h | 1 -
 include/configs/adp-ae3xx.h   | 3 ---
 include/configs/adp-ag101p.h  | 3 ---
 include/configs/amcore.h  | 2 --
 include/configs/ap121.h   | 1 -
 include/configs/ap143.h   | 1 -
 include/configs/ap325rxa.h| 2 --
 include/configs/ap_sh4a_4a.h  | 2 --
 include/configs/apf27.h   | 1 -
 include/configs/armadillo-800eva.h| 1 -
 include/configs/aspeed-common.h   | 1 -
 include/configs/astro_mcf5373l.h  | 1 -
 include/configs/at91-sama5_common.h   | 1 -
 include/configs/at91rm9200ek.h| 1 -
 include/configs/at91sam9260ek.h   | 1 -
 include/configs/at91sam9261ek.h   | 1 -
 include/configs/at91sam9263ek.h   | 1 -
 include/configs/at91sam9m10g45ek.h| 1 -
 include/configs/at91sam9n12ek.h   | 1 -
 include/configs/at91sam9rlek.h| 1 -
 include/configs/at91sam9x5ek.h| 1 -
 include/configs/axs10x.h  | 1 -
 include/configs/boston.h  | 1 -
 include/configs/calimain.h| 1 -
 include/configs/cm_t35.h  | 1 -
 include/configs/cobra5272.h   | 1 -
 include/configs/colibri_pxa270.h  | 1 -
 include/configs/colibri_vf.h  | 1 -
 include/configs/controlcenterd.h  | 1 -
 include/configs/corenet_ds.h  | 1 -
 include/configs/corvus.h  | 1 -
 include/configs/cyrus.h   | 1 -
 include/configs/da850evm.h| 1 -
 include/configs/dbau1x00.h| 2 --
 include/configs/devkit3250.h  | 1 -
 include/configs/ea20.h| 1 -
 include/configs/eb_cpu5282.h  | 1 -
 include/configs/ecovec.h  | 2 --
 include/configs/edb93xx.h | 1 -
 include/configs/edminiv2.h| 1 -
 include/configs/espt.h| 1 -
 include/configs/ethernut5.h   | 1 -
 include/configs/exynos-common.h   | 1 -
 include/configs/exynos7420-common.h   | 1 -
 include/configs/h2200.h   | 1 -
 include/configs/highbank.h| 1 -
 include/configs/hrcon.h   | 1 -
 include/configs/hsdk.h| 1 -
 

Re: [U-Boot] [PATCH] pico-imx7d: Add support for secure boot

2017-08-23 Thread Vanessa Ayumi Maegima
Hi Fabio,

On Wed, Aug 23, 2017 at 11:11 AM, Fabio Estevam  wrote:

> Hi Vanessa,
>
> On Wed, Aug 23, 2017 at 11:05 AM, Vanessa Maegima
>  wrote:
> > Add a new defconfig to enable secure boot on pico-imx7d.
>
> Please explain in the commit log why you are adding this new defconfig.
>
> Anyway, I understant that this could be useful if someone tries to
> boot this board with NXP 4.1.15 kernel.
>
> Not sure it is worth the effort of adding a new defconfig only for
> this purpose as mainline kernel can be used with existing U-Boot
> defconfig.
>

​I made this patch to enable booting with linux-fslc 4.1 kernel,
but if you think it is not worth maintaining a new defconfig we
can skip it.​
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 8/8] include/configs: remove numerous CONFIG_SYS_BARGSIZE definitions

2017-08-23 Thread Thomas Petazzoni
This commit removes definitions of CONFIG_SYS_BARGSIZE defined to be
equal to CONFIG_SYS_CBSIZE in numerous configuration files.

We remove such definitions in two situations:

 - CONFIG_SYS_CBSIZE is otherwise not defined in the board
   configuration file, which means the default value of
   CONFIG_SYS_CBSIZE == 256 applies. In this case, the default value
   of CONFIG_SYS_BARGSIZE == 512 (common/image.c) is suitable, as it is
   larger.

 - CONFIG_SYS_CBSIZE is defined in the board configuration file, but
   to a value equal or less than 512. In this case, the default value
   of CONFIG_SYS_BARGSIZE == 512 (common.image.c) is suitable, as it
   is equal or larger.

Signed-off-by: Thomas Petazzoni 
---
 include/configs/10m50_devboard.h | 1 -
 include/configs/3c120_devboard.h | 1 -
 include/configs/B4860QDS.h   | 1 -
 include/configs/BSC9132QDS.h | 2 --
 include/configs/C29XPCIE.h   | 2 --
 include/configs/M5208EVBE.h  | 1 -
 include/configs/M52277EVB.h  | 2 --
 include/configs/M5235EVB.h   | 1 -
 include/configs/M5249EVB.h   | 2 --
 include/configs/M5253DEMO.h  | 2 --
 include/configs/M5253EVBE.h  | 2 --
 include/configs/M5272C3.h| 1 -
 include/configs/M5275EVB.h   | 2 --
 include/configs/M5282EVB.h   | 2 --
 include/configs/M53017EVB.h  | 1 -
 include/configs/M5329EVB.h   | 1 -
 include/configs/M5373EVB.h   | 1 -
 include/configs/M54418TWR.h  | 3 ---
 include/configs/M54455EVB.h  | 2 --
 include/configs/M5475EVB.h   | 1 -
 include/configs/M5485EVB.h   | 1 -
 include/configs/MCR3000.h| 1 -
 include/configs/MPC8315ERDB.h| 3 ---
 include/configs/MPC8323ERDB.h| 3 ---
 include/configs/MPC832XEMDS.h| 3 ---
 include/configs/MPC8349EMDS.h| 3 ---
 include/configs/MPC8349ITX.h | 3 ---
 include/configs/MPC837XEMDS.h| 3 ---
 include/configs/MPC837XERDB.h| 3 ---
 include/configs/MPC8536DS.h  | 1 -
 include/configs/MPC8540ADS.h | 2 --
 include/configs/MPC8541CDS.h | 1 -
 include/configs/MPC8544DS.h  | 1 -
 include/configs/MPC8548CDS.h | 1 -
 include/configs/MPC8555CDS.h | 1 -
 include/configs/MPC8568MDS.h | 1 -
 include/configs/MPC8572DS.h  | 1 -
 include/configs/MPC8610HPCD.h| 2 --
 include/configs/MPC8641HPCN.h| 2 --
 include/configs/P1010RDB.h   | 2 --
 include/configs/P1022DS.h| 1 -
 include/configs/P1023RDB.h   | 2 --
 include/configs/P2041RDB.h   | 2 --
 include/configs/T102xQDS.h   | 1 -
 include/configs/T102xRDB.h   | 1 -
 include/configs/T1040QDS.h   | 1 -
 include/configs/T104xRDB.h   | 1 -
 include/configs/T208xQDS.h   | 1 -
 include/configs/T208xRDB.h   | 1 -
 include/configs/T4240RDB.h   | 1 -
 include/configs/TQM834x.h| 3 ---
 include/configs/UCP1020.h| 1 -
 include/configs/adp-ae3xx.h  | 3 ---
 include/configs/adp-ag101p.h | 3 ---
 include/configs/advantech_dms-ba16.h | 2 --
 include/configs/am3517_crane.h   | 2 --
 include/configs/am3517_evm.h | 2 --
 include/configs/amcore.h | 3 ---
 include/configs/aspeed-common.h  | 2 --
 include/configs/astro_mcf5373l.h | 2 --
 include/configs/axs10x.h | 1 -
 include/configs/bur_cfg_common.h | 2 --
 include/configs/cm_t35.h | 2 --
 include/configs/cm_t3517.h   | 2 --
 include/configs/cobra5272.h  | 2 --
 include/configs/colibri_pxa270.h | 1 -
 include/configs/controlcenterd.h | 1 -
 include/configs/corenet_ds.h | 1 -
 include/configs/cyrus.h  | 1 -
 include/configs/dragonboard410c.h| 1 -
 include/configs/edb93xx.h| 2 --
 include/configs/flea3.h  | 1 -
 include/configs/ge_bx50v3.h  | 2 --
 include/configs/hikey.h  | 1 -
 include/configs/hsdk.h   | 1 -
 include/configs/imx31_phycore.h  | 2 --
 include/configs/integrator-common.h  | 1 -
 include/configs/ls1012a_common.h | 1 -
 include/configs/ls1021aiot.h | 1 -
 include/configs/ls1021aqds.h | 1 -
 include/configs/ls1021atwr.h | 1 -
 include/configs/ls1043a_common.h | 1 -
 include/configs/ls1043aqds.h | 1 -
 include/configs/ls1046a_common.h | 1 -
 include/configs/ls1046aqds.h | 1 -
 include/configs/ls2080a_common.h | 1 -
 include/configs/meson-gxbb-common.h  | 1 -
 include/configs/mx25pdk.h| 2 --
 include/configs/mx31ads.h| 1 -
 include/configs/mx31pdk.h| 2 --
 include/configs/mx35pdk.h| 1 -
 include/configs/mx51evk.h| 1 -
 include/configs/mx53ard.h| 2 --
 include/configs/mx53cx9020.h | 2 --
 include/configs/mx53evk.h| 2 --
 

[U-Boot] [PATCH 7/8] include/configs: remove default values of CONFIG_SYS_BARGSIZE

2017-08-23 Thread Thomas Petazzoni
CONFIG_SYS_BARGSIZE is already defined to 512 in common/image.c when
not defined. Therefore, there is no point in having board
configuration files define it to 512.

Signed-off-by: Thomas Petazzoni 
---
 include/configs/MigoR.h| 1 -
 include/configs/ap325rxa.h | 2 --
 include/configs/ap_sh4a_4a.h   | 2 --
 include/configs/armadillo-800eva.h | 1 -
 include/configs/ecovec.h   | 2 --
 include/configs/espt.h | 2 --
 include/configs/kzm9g.h| 1 -
 include/configs/mpr2.h | 1 -
 include/configs/ms7720se.h | 2 --
 include/configs/ms7722se.h | 1 -
 include/configs/ms7750se.h | 1 -
 include/configs/r0p7734.h  | 2 --
 include/configs/r2dplus.h  | 1 -
 include/configs/r7780mp.h  | 1 -
 include/configs/rcar-gen2-common.h | 1 -
 include/configs/rsk7203.h  | 2 --
 include/configs/sh7752evb.h| 1 -
 include/configs/sh7753evb.h| 1 -
 include/configs/sh7757lcr.h| 1 -
 include/configs/sh7763rdp.h| 2 --
 include/configs/sh7785lcr.h| 1 -
 include/configs/shmin.h| 2 --
 22 files changed, 31 deletions(-)

diff --git a/include/configs/MigoR.h b/include/configs/MigoR.h
index cd10372..3cf2f09 100644
--- a/include/configs/MigoR.h
+++ b/include/configs/MigoR.h
@@ -27,7 +27,6 @@
 #define CONFIG_SYS_TEXT_BASE   0x8FFC
 #define CONFIG_SYS_LONGHELP/* undef to save memory */
 #define CONFIG_SYS_PBSIZE  256 /* Buffer size for 
Console output */
-#define CONFIG_SYS_BARGSIZE512 /* Buffer size for Boot 
Arguments passed to kernel */
 #define CONFIG_SYS_BAUDRATE_TABLE  { 115200 }  /* List of legal 
baudrate settings for this board */
 
 /* SCIF */
diff --git a/include/configs/ap325rxa.h b/include/configs/ap325rxa.h
index c63913a..1140a70 100644
--- a/include/configs/ap325rxa.h
+++ b/include/configs/ap325rxa.h
@@ -33,8 +33,6 @@
 /* Monitor Command Prompt */
 /* Buffer size for Console output */
 #define CONFIG_SYS_PBSIZE  256
-/* Buffer size for Boot Arguments passed to kernel */
-#define CONFIG_SYS_BARGSIZE512
 /* List of legal baudrate settings for this board */
 #define CONFIG_SYS_BAUDRATE_TABLE  { 38400 }
 
diff --git a/include/configs/ap_sh4a_4a.h b/include/configs/ap_sh4a_4a.h
index 8acaee1..ab3d40c 100644
--- a/include/configs/ap_sh4a_4a.h
+++ b/include/configs/ap_sh4a_4a.h
@@ -33,8 +33,6 @@
 /* Monitor Command Prompt */
 /* Buffer size for Console output */
 #define CONFIG_SYS_PBSIZE  256
-/* Buffer size for Boot Arguments passed to kernel */
-#define CONFIG_SYS_BARGSIZE512
 /* List of legal baudrate settings for this board */
 #define CONFIG_SYS_BAUDRATE_TABLE  { 115200 }
 
diff --git a/include/configs/armadillo-800eva.h 
b/include/configs/armadillo-800eva.h
index bea1e72..66ae76b 100644
--- a/include/configs/armadillo-800eva.h
+++ b/include/configs/armadillo-800eva.h
@@ -36,7 +36,6 @@
 
 #define CONFIG_SYS_LONGHELP
 #define CONFIG_SYS_PBSIZE  256
-#define CONFIG_SYS_BARGSIZE512
 #define CONFIG_SYS_BAUDRATE_TABLE  { 115200 }
 
 /* SCIF */
diff --git a/include/configs/ecovec.h b/include/configs/ecovec.h
index 8c8f68f..8cb3efc 100644
--- a/include/configs/ecovec.h
+++ b/include/configs/ecovec.h
@@ -66,8 +66,6 @@
 /* Monitor Command Prompt */
 /* Buffer size for Console output */
 #define CONFIG_SYS_PBSIZE  256
-/* Buffer size for Boot Arguments passed to kernel */
-#define CONFIG_SYS_BARGSIZE512
 /* List of legal baudrate settings for this board */
 #define CONFIG_SYS_BAUDRATE_TABLE  { 115200 }
 
diff --git a/include/configs/espt.h b/include/configs/espt.h
index 934b52a..628406a 100644
--- a/include/configs/espt.h
+++ b/include/configs/espt.h
@@ -25,8 +25,6 @@
 #define CONFIG_SYS_TEXT_BASE   0x8FFC
 #define CONFIG_SYS_LONGHELP/* undef to save memory */
 #define CONFIG_SYS_PBSIZE  256 /* Buffer size for Console 
output */
-#define CONFIG_SYS_BARGSIZE512 /* Buffer size for Boot Arguments
-   passed to 
kernel */
 #define CONFIG_SYS_BAUDRATE_TABLE  { 115200 }  /* List of legal 
baudrate

settings for this board */
 
diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h
index b408cd4..a260d0e 100644
--- a/include/configs/kzm9g.h
+++ b/include/configs/kzm9g.h
@@ -41,7 +41,6 @@
 /* prompt */
 #define CONFIG_SYS_LONGHELP
 #define CONFIG_SYS_PBSIZE  256
-#define CONFIG_SYS_BARGSIZE512
 #define CONFIG_SYS_BAUDRATE_TABLE  { 115200 }
 
 /* SCIF */
diff --git a/include/configs/mpr2.h b/include/configs/mpr2.h
index 761558c..14b0492 100644
--- a/include/configs/mpr2.h
+++ b/include/configs/mpr2.h
@@ -24,7 +24,6 @@
 
 /* U-Boot internals */
 #define 

[U-Boot] [PATCH 5/8] include/config_fallbacks.h: add default for CONFIG_SYS_MAXARGS

2017-08-23 Thread Thomas Petazzoni
CONFIG_SYS_MAXARGS contains the maximum number of arguments accepted
by U-Boot commands. Since the vast majority of the platforms define it
to 16, it makes sense to have a default definition to 16, which will
allow to remove this definition from a significant number of
platforms.

It will allow to remove the default definition from 216 platform .h
files, leaving only 56 platforms with non-default values (15, 24, 32,
48, 64, 96, 128 or 256).

Signed-off-by: Thomas Petazzoni 
---
 include/config_fallbacks.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h
index 09fcee4..85725bd 100644
--- a/include/config_fallbacks.h
+++ b/include/config_fallbacks.h
@@ -84,6 +84,10 @@
 #define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) 
+ 16)
 #endif
 
+#ifndef CONFIG_SYS_MAXARGS
+#define CONFIG_SYS_MAXARGS 16
+#endif
+
 #ifndef CONFIG_FIT_SIGNATURE
 #define CONFIG_IMAGE_FORMAT_LEGACY
 #endif
-- 
2.9.4

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


[U-Boot] [PATCH 3/8] include/config_fallbacks.h: change fallback for CONFIG_SYS_PBSIZE

2017-08-23 Thread Thomas Petazzoni
Most of the platforms are using CONFIG_SYS_CBSIZE +
sizeof(CONFIG_SYS_PROMPT) + 16 as their value for CONFIG_SYS_PBSIZE,
so let's adopt this for the fallback value of CONFIG_SYS_PBSIZE.

This will allow us to drop an explicit definition of CONFIG_SYS_PBSIZE
from a large number of platforms.

Signed-off-by: Thomas Petazzoni 
---
 include/config_fallbacks.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h
index f9461f0..09fcee4 100644
--- a/include/config_fallbacks.h
+++ b/include/config_fallbacks.h
@@ -81,7 +81,7 @@
 #endif
 
 #ifndef CONFIG_SYS_PBSIZE
-#define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + 128)
+#define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) 
+ 16)
 #endif
 
 #ifndef CONFIG_FIT_SIGNATURE
-- 
2.9.4

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


[U-Boot] [PATCH 2/8] include/configs: remove CONFIG_SYS_CBSIZE when the default value is used

2017-08-23 Thread Thomas Petazzoni
Now that include/config_fallbacks.h define a sane fallback for
CONFIG_SYS_CBSIZE, we can drop the definition of this constant in all
configurations that were using the default value.

Signed-off-by: Thomas Petazzoni 
---
 include/configs/10m50_devboard.h| 1 -
 include/configs/3c120_devboard.h| 1 -
 include/configs/B4860QDS.h  | 5 -
 include/configs/BSC9132QDS.h| 5 -
 include/configs/C29XPCIE.h  | 1 -
 include/configs/M5208EVBE.h | 6 --
 include/configs/M52277EVB.h | 5 -
 include/configs/M5235EVB.h  | 6 --
 include/configs/M5249EVB.h  | 5 -
 include/configs/M5253DEMO.h | 5 -
 include/configs/M5253EVBE.h | 5 -
 include/configs/M5272C3.h   | 6 --
 include/configs/M5275EVB.h  | 5 -
 include/configs/M5282EVB.h  | 5 -
 include/configs/M53017EVB.h | 6 --
 include/configs/M5329EVB.h  | 6 --
 include/configs/M5373EVB.h  | 6 --
 include/configs/M54418TWR.h | 5 -
 include/configs/M54451EVB.h | 5 -
 include/configs/M54455EVB.h | 5 -
 include/configs/M5475EVB.h  | 6 --
 include/configs/M5485EVB.h  | 6 --
 include/configs/MCR3000.h   | 1 -
 include/configs/MPC8315ERDB.h   | 6 --
 include/configs/MPC8323ERDB.h   | 6 --
 include/configs/MPC832XEMDS.h   | 6 --
 include/configs/MPC8349EMDS.h   | 6 --
 include/configs/MPC8349ITX.h| 6 --
 include/configs/MPC837XEMDS.h   | 6 --
 include/configs/MPC837XERDB.h   | 6 --
 include/configs/MPC8536DS.h | 5 -
 include/configs/MPC8540ADS.h| 6 --
 include/configs/MPC8541CDS.h| 5 -
 include/configs/MPC8544DS.h | 5 -
 include/configs/MPC8548CDS.h| 5 -
 include/configs/MPC8555CDS.h| 5 -
 include/configs/MPC8560ADS.h| 6 --
 include/configs/MPC8568MDS.h| 5 -
 include/configs/MPC8572DS.h | 5 -
 include/configs/MPC8610HPCD.h   | 6 --
 include/configs/MPC8641HPCN.h   | 6 --
 include/configs/MigoR.h | 1 -
 include/configs/P1010RDB.h  | 5 -
 include/configs/P1022DS.h   | 5 -
 include/configs/P1023RDB.h  | 5 -
 include/configs/P2041RDB.h  | 5 -
 include/configs/T102xQDS.h  | 5 -
 include/configs/T102xRDB.h  | 5 -
 include/configs/T1040QDS.h  | 5 -
 include/configs/T104xRDB.h  | 5 -
 include/configs/T208xQDS.h  | 5 -
 include/configs/T208xRDB.h  | 5 -
 include/configs/T4240RDB.h  | 5 -
 include/configs/TQM834x.h   | 6 --
 include/configs/UCP1020.h   | 5 -
 include/configs/adp-ae3xx.h | 1 -
 include/configs/adp-ag101p.h| 1 -
 include/configs/amcore.h| 6 --
 include/configs/ap121.h | 1 -
 include/configs/ap143.h | 1 -
 include/configs/ap325rxa.h  | 2 --
 include/configs/ap_sh4a_4a.h| 2 --
 include/configs/armadillo-800eva.h  | 1 -
 include/configs/aspeed-common.h | 1 -
 include/configs/astro_mcf5373l.h| 5 -
 include/configs/at91-sama5_common.h | 1 -
 include/configs/at91rm9200ek.h  | 1 -
 include/configs/at91sam9260ek.h | 1 -
 include/configs/at91sam9261ek.h | 1 -
 include/configs/at91sam9263ek.h | 1 -
 include/configs/at91sam9m10g45ek.h  | 1 -
 include/configs/at91sam9n12ek.h | 1 -
 include/configs/at91sam9rlek.h  | 1 -
 include/configs/at91sam9x5ek.h  | 1 -
 include/configs/axs10x.h| 1 -
 include/configs/boston.h| 1 -
 include/configs/cm_t35.h| 1 -
 include/configs/cobra5272.h | 5 -
 include/configs/colibri_pxa270.h| 1 -
 include/configs/controlcenterd.h| 5 -
 include/configs/corenet_ds.h| 5 -
 include/configs/corvus.h| 1 -
 include/configs/cyrus.h | 5 -
 include/configs/dbau1x00.h  | 1 -
 include/configs/ecovec.h| 2 --
 include/configs/espt.h  | 1 -
 include/configs/ethernut5.h | 1 -
 include/configs/h2200.h | 3 ---
 include/configs/hsdk.h  | 1 -
 include/configs/imx31_phycore.h | 2 --
 include/configs/integrator-common.h | 1 -
 include/configs/kzm9g.h | 1 -
 include/configs/ls1021aiot.h| 1 -
 include/configs/ls1021aqds.h| 1 -
 include/configs/ls1021atwr.h| 1 -
 include/configs/malta.h | 1 -
 include/configs/mpr2.h  | 1 -
 include/configs/ms7720se.h  | 1 -
 include/configs/ms7722se.h  | 1 -
 include/configs/ms7750se.h  | 1 -
 include/configs/mx31ads.h   | 1 -
 include/configs/mx31pdk.h   | 1 -
 include/configs/mx35pdk.h   | 1 -
 include/configs/mx51evk.h   | 1 -
 

[U-Boot] [PATCH 1/8] include/config_fallbacks.h: add default for CONFIG_SYS_CBSIZE

2017-08-23 Thread Thomas Petazzoni
CONFIG_SYS_CBSIZE contains the buffer size for input for the
console. The vast majority of platforms define them to some reasonable
value (256, 512 or 1024 bytes), and it is quite annoying to repeat
this definition for all platforms while it isn't really HW-related.

Therefore, let's provide a sane fallback value in config_fallbacks.h,
so that platforms can rely on it instead of having to explicitly
define it.

We use 1024 when KGDB is enabled, and 256 otherwise, which is what the
majority of the platforms are doing.

Signed-off-by: Thomas Petazzoni 
---
 include/config_fallbacks.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h
index 961a83d..f9461f0 100644
--- a/include/config_fallbacks.h
+++ b/include/config_fallbacks.h
@@ -71,6 +71,15 @@
 #define CONFIG_LIB_RAND
 #endif
 
+/* Console I/O Buffer Size */
+#ifndef CONFIG_SYS_CBSIZE
+#if defined(CONFIG_CMD_KGDB)
+#define CONFIG_SYS_CBSIZE  1024
+#else
+#define CONFIG_SYS_CBSIZE  256
+#endif
+#endif
+
 #ifndef CONFIG_SYS_PBSIZE
 #define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + 128)
 #endif
-- 
2.9.4

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


[U-Boot] [PATCH 0/8] Clean up CONFIG_SYS_{CBSIZE, PBSIZE, MAXARGS, BARGSIZE} definitions

2017-08-23 Thread Thomas Petazzoni
Hello,

While adding support for new platforms, I found out that many, many
platforms define pretty much the same values for:

 CONFIG_SYS_CBSIZE
 CONFIG_SYS_PBSIZE
 CONFIG_SYS_MAXARGS
 CONFIG_SYS_BARGSIZE

with just a few platforms deviating from the values that have clearly
been copy/pasted over and over again all over the place.

In this patch series, I propose to have U-Boot define some sane
defaults for those 4 configuration options, and cleanup all the board
configuration files that were using the default values. This leads to
the removal of 1300+ lines.

Of course, this is all open for discussion, and at this point, I have
only done minimal build testing, as my goal is to get the discussion
started.

Open questions:

 - Do we really need to have all those remaining boards with
   custom/arbitrary values for those configuration options?

 - Does it really makes sense for those configuration options to be
   customized in board configuration files? For example, the size of
   the kernel command line is not at all tied to the underlying
   hardware, but rather how much arguments the user wants to pass to
   the kernel. Ditto for the maximum number of arguments passed to
   U-Boot commands. Perhaps we want to remove those options entirely
   from the .h files, and simply have a Kconfig option instead?

Also, let me know if I have missed some existing work in this area.

Thanks for your feedback!

Thomas Petazzoni

Thomas Petazzoni (8):
  include/config_fallbacks.h: add default for CONFIG_SYS_CBSIZE
  include/configs: remove CONFIG_SYS_CBSIZE when the default value is
used
  include/config_fallbacks.h: change fallback for CONFIG_SYS_PBSIZE
  include/configs: drop default definitions of CONFIG_SYS_PBSIZE
  include/config_fallbacks.h: add default for CONFIG_SYS_MAXARGS
  include/configs: drop default definitions of CONFIG_SYS_MAXARGS
  include/configs: remove default values of CONFIG_SYS_BARGSIZE
  include/configs: remove numerous CONFIG_SYS_BARGSIZE definitions

 include/config_fallbacks.h | 15 ++-
 include/configs/10m50_devboard.h   |  6 --
 include/configs/3c120_devboard.h   |  6 --
 include/configs/B4860QDS.h |  8 
 include/configs/BSC9131RDB.h   |  3 ---
 include/configs/BSC9132QDS.h   | 10 --
 include/configs/C29XPCIE.h |  6 --
 include/configs/M5208EVBE.h|  9 -
 include/configs/M52277EVB.h|  9 -
 include/configs/M5235EVB.h |  9 -
 include/configs/M5249EVB.h |  9 -
 include/configs/M5253DEMO.h|  9 -
 include/configs/M5253EVBE.h|  9 -
 include/configs/M5272C3.h  |  9 -
 include/configs/M5275EVB.h |  9 -
 include/configs/M5282EVB.h |  9 -
 include/configs/M53017EVB.h|  9 -
 include/configs/M5329EVB.h |  9 -
 include/configs/M5373EVB.h |  9 -
 include/configs/M54418TWR.h| 12 
 include/configs/M54451EVB.h|  7 ---
 include/configs/M54455EVB.h|  9 -
 include/configs/M5475EVB.h |  9 -
 include/configs/M5485EVB.h |  9 -
 include/configs/MCR3000.h  |  4 
 include/configs/MPC8308RDB.h   |  3 ---
 include/configs/MPC8313ERDB.h  |  4 
 include/configs/MPC8315ERDB.h  | 12 
 include/configs/MPC8323ERDB.h  | 12 
 include/configs/MPC832XEMDS.h  | 12 
 include/configs/MPC8349EMDS.h  | 12 
 include/configs/MPC8349ITX.h   | 12 
 include/configs/MPC837XEMDS.h  | 12 
 include/configs/MPC837XERDB.h  | 12 
 include/configs/MPC8536DS.h|  9 -
 include/configs/MPC8540ADS.h   | 10 --
 include/configs/MPC8541CDS.h   |  8 
 include/configs/MPC8544DS.h|  8 
 include/configs/MPC8548CDS.h   |  8 
 include/configs/MPC8555CDS.h   |  8 
 include/configs/MPC8560ADS.h   |  8 
 include/configs/MPC8568MDS.h   |  8 
 include/configs/MPC8569MDS.h   |  2 --
 include/configs/MPC8572DS.h|  8 
 include/configs/MPC8610HPCD.h  | 10 --
 include/configs/MPC8641HPCN.h  | 10 --
 include/configs/MigoR.h|  3 ---
 include/configs/P1010RDB.h | 10 --
 include/configs/P1022DS.h  |  9 -
 include/configs/P1023RDB.h | 10 --
 include/configs/P2041RDB.h | 11 ---
 include/configs/T102xQDS.h |  8 
 include/configs/T102xRDB.h |  8 
 include/configs/T1040QDS.h |  8 
 include/configs/T104xRDB.h |  8 

[U-Boot] Using USB on AM3517-EVM in U-Boot

2017-08-23 Thread Adam Ford
I have never tried to use the USB in U-Boot, but it appears broken in
U-Boot 2017.09-rc2.

When I run 'usb start' I get

starting USB...
USB0:   Port not available.


Is this the expected behavior?

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


Re: [U-Boot] rk3288: 32KB SPL size restriction

2017-08-23 Thread Jagan Teki
On Thu, Aug 24, 2017 at 12:33 AM, Jagan Teki  wrote:
> On Thu, Aug 24, 2017 at 12:28 AM, Dr. Philipp Tomsich
>  wrote:
>>
>>> On 23 Aug 2017, at 20:44, Jagan Teki  wrote:
>>>
>>> On Wed, Aug 23, 2017 at 6:22 PM, Dr. Philipp Tomsich
>>>  wrote:

> On 23 Aug 2017, at 13:19, Jagan Teki  wrote:
>
> Hi Philipp,
>
> On Tue, Aug 22, 2017 at 5:41 PM, Dr. Philipp Tomsich
>  wrote:
>>
>>> On 22 Aug 2017, at 14:05, Jagan Teki  wrote:
>>>
>>> Philipp and Kever - Thanks for the response.
>>>
>>> Few comment below.
>>>
>>> On Thu, Aug 17, 2017 at 2:02 PM, Dr. Philipp Tomsich
>>>  wrote:
 Jagan,

> On 17 Aug 2017, at 08:39, Kever Yang  
> wrote:
>
> Hi Jagan,
>
>
> On 08/10/2017 05:07 PM, Jagan Teki wrote:
>> Hi Simon/Philipp or any,
>>
>> I believe rk3288 has 20KB BootRom and 100KB internal SRAM and current
>> u-boot can archive the maximum size of u-boot-spl-dtb.bin which the
>> boot ROM will read is 32KB, do we have any possibility to increase 
>> the
>> SPL size here.
>
> The limitation is decide by the boot rom design, so we are not able
> to change this. Most of Rockchip SoCs have this limitation except 
> RK3399.
>
> Thanks,
> - Kever
>>
>> # ./tools/mkimage -n rk3288 -T rksd -d ./spl/u-boot-spl-dtb.bin 
>> out.img
>> Warning: SPL image is too large (size 0x9000) and will not boot
>> Error: image verification failed
>>
>> I tried to increase the spl_size from spl_infos (on tools/rkcommon.c)
>> but not able to boot.

 I should have read this more carefully (I only parsed the 20KB and
 jumped to the conclusion that your had the error already when crossing
 the 20KB limit—even though 0x8000 bytes where allowed in mkimage)…
>>>
>>> Sorry I really didn't understand the size constraint here, because SPL
>>> can be boot file after ROM handoff. Can't this sit on 100KB of SRAM?
>>
>> The ROM usually has different size constraints for each stage.
>>
>> E.g. for the RK3368 (just been there, done that), the first stage has a
>> 0x7000 byte limit and the next stage (loaded to 0x0 in DRAM) has a
>> much larger limit. Note that the SRAM on the 3368 has a capacity of
>> 0x1 bytes, so the size limit is also quite pronounced.
>
> OK, by looking at your rk3368[1] patch I think the first stage runs
> under 0x7000 is TPL? and next stage(probably SPL) doesn't have limit
> since SPL running here in DDR since DDR initialized DDR in TPL itself.
> this is what the space distributed here?

 Yes, although there is some size limit even for SPL.
 If you are going for a falcon-mode implementation on the 3288, you will
 probably want to use TPL for DRAM setup and maybe clocking up the
 cores (I don’t know the constraints on what clocks the BROM needs
 untouched) and then have SPL w/ falcon mode loaded by the BROM.
>>>
>>> So, TPL should have DDR and MMC, and fit into 0x8000 bytes and SPL
>>> will load from MMC and launch u-boot. Do we need spl_bootrom in TPL
>>> instead of MMC? if so where we need to copy SPL?
>>
>> You probably just want DRAM-init and clocking and have everything else
>> in SPL (for the falcon use-case).  The BROM will magically load the SPL
>> stage for you, so no need for MMC support in TPL.
>
> How does BROM will load SPL here? with
> CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y ? because I will copy TPL at 64
> sector of MMC card and where should I copy SPL?

OK, TPL_ROCKCHIP_BACK_TO_BROM should have back_to_bootrom So we need
to append the mkimaged-TPL with SPL and copy to 64 so-that ROM loads
SPL by handoff from TPL.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


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

2017-08-23 Thread Jagan Teki
On Wed, Aug 23, 2017 at 8:20 PM, Stefano Babic  wrote:
> Hi Peng,
>
> On 09/08/2017 07:09, 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/mx6qsabresd board.
>>
>> Signed-off-by: Peng Fan 
>> Cc: Jagan Teki 
>> cc: Stefano Babic 

Applied to u-boot-spi/next

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 13/13] board: ti: dra76: Add dt support

2017-08-23 Thread Tom Rini
On Mon, Aug 21, 2017 at 12:51:01PM +0530, Lokesh Vutla wrote:

> Add support for selecting proper dtb for
> dra76x u-boot from FIT.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
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 v2 11/13] arm: dts: dra7: sync DT with latest Linux

2017-08-23 Thread Tom Rini
On Mon, Aug 21, 2017 at 12:50:59PM +0530, Lokesh Vutla wrote:

> Sync all dra7* specific dts files with the upstream
> kernel including changes queued for 4.14
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v4.14/dt-v3
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
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] board: ti: am571x: Add 666MHz support for AM571x IDK

2017-08-23 Thread Tom Rini
On Tue, Aug 22, 2017 at 01:52:58PM +0530, Lokesh Vutla wrote:

> From: Steve Kipisz 
> 
> AM571x supports DDR running at 666MHz. Right now it is
> clocked at 532MHz which is lower than what is supported.
> In order to have maximum performance on AM571-IDK,
> switch DDR to 666MHz.
> 
> Signed-off-by: Steve Kipisz 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
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 v2 12/13] arm: dts: Add u-boot specific compatibles

2017-08-23 Thread Tom Rini
On Mon, Aug 21, 2017 at 12:51:00PM +0530, Lokesh Vutla wrote:

> Separate out u-boot specific compatibles from dts files.
> This will help in syncing dts files in future.
> Also these will get deleted eventually once respective drivers
> are capable of handling Linux dts files.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
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 v2 03/13] arm: dra7: Kconfig: Select LP87565 related configs

2017-08-23 Thread Tom Rini
On Mon, Aug 21, 2017 at 12:50:51PM +0530, Lokesh Vutla wrote:

> LP87565 is present on dra76-evm. Select it for
> TARGET_DRA7XX_EVM.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
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] configs: SECURE_BOOT: Enable CONFIG_CMD_EXT4_WRITE

2017-08-23 Thread Tom Rini
On Wed, Aug 23, 2017 at 10:59:21AM +0530, Sumit Garg wrote:

> As part of chain of trust with confidentiality along with distro
> boot, linux kernel image needs to be stored in encrypted form on
> ext4 boot partition. So enable CONFIG_CMD_EXT4_WRITE in all Secure
> Boot defconfigs.
> 
> Signed-off-by: Sumit Garg 

You should imply or select this, I suspect, from
boards/freescale/common/Kconfig somewhere, 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] rk3288: 32KB SPL size restriction

2017-08-23 Thread Jagan Teki
On Thu, Aug 24, 2017 at 12:28 AM, Dr. Philipp Tomsich
 wrote:
>
>> On 23 Aug 2017, at 20:44, Jagan Teki  wrote:
>>
>> On Wed, Aug 23, 2017 at 6:22 PM, Dr. Philipp Tomsich
>>  wrote:
>>>
 On 23 Aug 2017, at 13:19, Jagan Teki  wrote:

 Hi Philipp,

 On Tue, Aug 22, 2017 at 5:41 PM, Dr. Philipp Tomsich
  wrote:
>
>> On 22 Aug 2017, at 14:05, Jagan Teki  wrote:
>>
>> Philipp and Kever - Thanks for the response.
>>
>> Few comment below.
>>
>> On Thu, Aug 17, 2017 at 2:02 PM, Dr. Philipp Tomsich
>>  wrote:
>>> Jagan,
>>>
 On 17 Aug 2017, at 08:39, Kever Yang  wrote:

 Hi Jagan,


 On 08/10/2017 05:07 PM, Jagan Teki wrote:
> Hi Simon/Philipp or any,
>
> I believe rk3288 has 20KB BootRom and 100KB internal SRAM and current
> u-boot can archive the maximum size of u-boot-spl-dtb.bin which the
> boot ROM will read is 32KB, do we have any possibility to increase the
> SPL size here.

 The limitation is decide by the boot rom design, so we are not able
 to change this. Most of Rockchip SoCs have this limitation except 
 RK3399.

 Thanks,
 - Kever
>
> # ./tools/mkimage -n rk3288 -T rksd -d ./spl/u-boot-spl-dtb.bin 
> out.img
> Warning: SPL image is too large (size 0x9000) and will not boot
> Error: image verification failed
>
> I tried to increase the spl_size from spl_infos (on tools/rkcommon.c)
> but not able to boot.
>>>
>>> I should have read this more carefully (I only parsed the 20KB and
>>> jumped to the conclusion that your had the error already when crossing
>>> the 20KB limit—even though 0x8000 bytes where allowed in mkimage)…
>>
>> Sorry I really didn't understand the size constraint here, because SPL
>> can be boot file after ROM handoff. Can't this sit on 100KB of SRAM?
>
> The ROM usually has different size constraints for each stage.
>
> E.g. for the RK3368 (just been there, done that), the first stage has a
> 0x7000 byte limit and the next stage (loaded to 0x0 in DRAM) has a
> much larger limit. Note that the SRAM on the 3368 has a capacity of
> 0x1 bytes, so the size limit is also quite pronounced.

 OK, by looking at your rk3368[1] patch I think the first stage runs
 under 0x7000 is TPL? and next stage(probably SPL) doesn't have limit
 since SPL running here in DDR since DDR initialized DDR in TPL itself.
 this is what the space distributed here?
>>>
>>> Yes, although there is some size limit even for SPL.
>>> If you are going for a falcon-mode implementation on the 3288, you will
>>> probably want to use TPL for DRAM setup and maybe clocking up the
>>> cores (I don’t know the constraints on what clocks the BROM needs
>>> untouched) and then have SPL w/ falcon mode loaded by the BROM.
>>
>> So, TPL should have DDR and MMC, and fit into 0x8000 bytes and SPL
>> will load from MMC and launch u-boot. Do we need spl_bootrom in TPL
>> instead of MMC? if so where we need to copy SPL?
>
> You probably just want DRAM-init and clocking and have everything else
> in SPL (for the falcon use-case).  The BROM will magically load the SPL
> stage for you, so no need for MMC support in TPL.

How does BROM will load SPL here? with
CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y ? because I will copy TPL at 64
sector of MMC card and where should I copy SPL?

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] rk3288: 32KB SPL size restriction

2017-08-23 Thread Dr. Philipp Tomsich

> On 23 Aug 2017, at 20:44, Jagan Teki  wrote:
> 
> On Wed, Aug 23, 2017 at 6:22 PM, Dr. Philipp Tomsich
>  wrote:
>> 
>>> On 23 Aug 2017, at 13:19, Jagan Teki  wrote:
>>> 
>>> Hi Philipp,
>>> 
>>> On Tue, Aug 22, 2017 at 5:41 PM, Dr. Philipp Tomsich
>>>  wrote:
 
> On 22 Aug 2017, at 14:05, Jagan Teki  wrote:
> 
> Philipp and Kever - Thanks for the response.
> 
> Few comment below.
> 
> On Thu, Aug 17, 2017 at 2:02 PM, Dr. Philipp Tomsich
>  wrote:
>> Jagan,
>> 
>>> On 17 Aug 2017, at 08:39, Kever Yang  wrote:
>>> 
>>> Hi Jagan,
>>> 
>>> 
>>> On 08/10/2017 05:07 PM, Jagan Teki wrote:
 Hi Simon/Philipp or any,
 
 I believe rk3288 has 20KB BootRom and 100KB internal SRAM and current
 u-boot can archive the maximum size of u-boot-spl-dtb.bin which the
 boot ROM will read is 32KB, do we have any possibility to increase the
 SPL size here.
>>> 
>>> The limitation is decide by the boot rom design, so we are not able
>>> to change this. Most of Rockchip SoCs have this limitation except 
>>> RK3399.
>>> 
>>> Thanks,
>>> - Kever
 
 # ./tools/mkimage -n rk3288 -T rksd -d ./spl/u-boot-spl-dtb.bin out.img
 Warning: SPL image is too large (size 0x9000) and will not boot
 Error: image verification failed
 
 I tried to increase the spl_size from spl_infos (on tools/rkcommon.c)
 but not able to boot.
>> 
>> I should have read this more carefully (I only parsed the 20KB and
>> jumped to the conclusion that your had the error already when crossing
>> the 20KB limit—even though 0x8000 bytes where allowed in mkimage)…
> 
> Sorry I really didn't understand the size constraint here, because SPL
> can be boot file after ROM handoff. Can't this sit on 100KB of SRAM?
 
 The ROM usually has different size constraints for each stage.
 
 E.g. for the RK3368 (just been there, done that), the first stage has a
 0x7000 byte limit and the next stage (loaded to 0x0 in DRAM) has a
 much larger limit. Note that the SRAM on the 3368 has a capacity of
 0x1 bytes, so the size limit is also quite pronounced.
>>> 
>>> OK, by looking at your rk3368[1] patch I think the first stage runs
>>> under 0x7000 is TPL? and next stage(probably SPL) doesn't have limit
>>> since SPL running here in DDR since DDR initialized DDR in TPL itself.
>>> this is what the space distributed here?
>> 
>> Yes, although there is some size limit even for SPL.
>> If you are going for a falcon-mode implementation on the 3288, you will
>> probably want to use TPL for DRAM setup and maybe clocking up the
>> cores (I don’t know the constraints on what clocks the BROM needs
>> untouched) and then have SPL w/ falcon mode loaded by the BROM.
> 
> So, TPL should have DDR and MMC, and fit into 0x8000 bytes and SPL
> will load from MMC and launch u-boot. Do we need spl_bootrom in TPL
> instead of MMC? if so where we need to copy SPL?

You probably just want DRAM-init and clocking and have everything else
in SPL (for the falcon use-case).  The BROM will magically load the SPL
stage for you, so no need for MMC support in TPL.

I don’t know the constraints on the RK3288, so I can’t comment on whether
it’s 0x8000 or some other number…

> My understanding is that TPL should have DDR and MMC and create
> mkimage (that anyway fits within 0x8000) and SPL should have all +
> falcon support and copy the SPL in 128KB. So-that TPL will load SPL
> from MMC same way as how SPL loads U-Boot in current code.

In this configuration, the TPL would be rather small and SPL will do
almost all of the heavy lifting.
TPL:DRAM init (and possibly some of the clocking)
SPL:clocks, MMC, falcon-loader

> 
> thanks!
> -- 
> Jagan Teki
> Free Software Engineer | www.openedev.com
> U-Boot, Linux | Upstream Maintainer
> Hyderabad, India.

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


Re: [U-Boot] rk3288: 32KB SPL size restriction

2017-08-23 Thread Jagan Teki
On Wed, Aug 23, 2017 at 6:22 PM, Dr. Philipp Tomsich
 wrote:
>
>> On 23 Aug 2017, at 13:19, Jagan Teki  wrote:
>>
>> Hi Philipp,
>>
>> On Tue, Aug 22, 2017 at 5:41 PM, Dr. Philipp Tomsich
>>  wrote:
>>>
 On 22 Aug 2017, at 14:05, Jagan Teki  wrote:

 Philipp and Kever - Thanks for the response.

 Few comment below.

 On Thu, Aug 17, 2017 at 2:02 PM, Dr. Philipp Tomsich
  wrote:
> Jagan,
>
>> On 17 Aug 2017, at 08:39, Kever Yang  wrote:
>>
>> Hi Jagan,
>>
>>
>> On 08/10/2017 05:07 PM, Jagan Teki wrote:
>>> Hi Simon/Philipp or any,
>>>
>>> I believe rk3288 has 20KB BootRom and 100KB internal SRAM and current
>>> u-boot can archive the maximum size of u-boot-spl-dtb.bin which the
>>> boot ROM will read is 32KB, do we have any possibility to increase the
>>> SPL size here.
>>
>> The limitation is decide by the boot rom design, so we are not able
>> to change this. Most of Rockchip SoCs have this limitation except RK3399.
>>
>> Thanks,
>> - Kever
>>>
>>> # ./tools/mkimage -n rk3288 -T rksd -d ./spl/u-boot-spl-dtb.bin out.img
>>> Warning: SPL image is too large (size 0x9000) and will not boot
>>> Error: image verification failed
>>>
>>> I tried to increase the spl_size from spl_infos (on tools/rkcommon.c)
>>> but not able to boot.
>
> I should have read this more carefully (I only parsed the 20KB and
> jumped to the conclusion that your had the error already when crossing
> the 20KB limit—even though 0x8000 bytes where allowed in mkimage)…

 Sorry I really didn't understand the size constraint here, because SPL
 can be boot file after ROM handoff. Can't this sit on 100KB of SRAM?
>>>
>>> The ROM usually has different size constraints for each stage.
>>>
>>> E.g. for the RK3368 (just been there, done that), the first stage has a
>>> 0x7000 byte limit and the next stage (loaded to 0x0 in DRAM) has a
>>> much larger limit. Note that the SRAM on the 3368 has a capacity of
>>> 0x1 bytes, so the size limit is also quite pronounced.
>>
>> OK, by looking at your rk3368[1] patch I think the first stage runs
>> under 0x7000 is TPL? and next stage(probably SPL) doesn't have limit
>> since SPL running here in DDR since DDR initialized DDR in TPL itself.
>> this is what the space distributed here?
>
> Yes, although there is some size limit even for SPL.
> If you are going for a falcon-mode implementation on the 3288, you will
> probably want to use TPL for DRAM setup and maybe clocking up the
> cores (I don’t know the constraints on what clocks the BROM needs
> untouched) and then have SPL w/ falcon mode loaded by the BROM.

So, TPL should have DDR and MMC, and fit into 0x8000 bytes and SPL
will load from MMC and launch u-boot. Do we need spl_bootrom in TPL
instead of MMC? if so where we need to copy SPL?

My understanding is that TPL should have DDR and MMC and create
mkimage (that anyway fits within 0x8000) and SPL should have all +
falcon support and copy the SPL in 128KB. So-that TPL will load SPL
from MMC same way as how SPL loads U-Boot in current code.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] disk: part: align buffer so it can be used with DMA enabled drivers

2017-08-23 Thread Stefan Agner
From: Stefan Agner 

When using ISO partitions with a DMA enabled block device driver
reading the ISO partition leads to unaligned DMA operations:
  CACHE: Misaligned operation at range [bffb7da8, bffb85a8]

Align the buffer to make sure we pass a buffer which works for
DMA operations.

Signed-off-by: Stefan Agner 
---

 disk/part_iso.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disk/part_iso.c b/disk/part_iso.c
index bb8ed658f2..8aef251f4e 100644
--- a/disk/part_iso.c
+++ b/disk/part_iso.c
@@ -24,7 +24,7 @@
 #undef CHECK_FOR_POWERPC_PLATTFORM
 #define CD_SECTSIZE 2048
 
-static unsigned char tmpbuf[CD_SECTSIZE];
+static unsigned char tmpbuf[CD_SECTSIZE] __aligned(ARCH_DMA_MINALIGN);
 
 unsigned long iso_dread(struct blk_desc *block_dev, lbaint_t start,
 lbaint_t blkcnt, void *buffer)
-- 
2.14.1

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


Re: [U-Boot] [PATCH] blk: Remove various places that do flush cache after read

2017-08-23 Thread York Sun
On 08/21/2017 08:42 PM, Bin Meng wrote:
> All these places seem to inherit the codes from the MMC driver where
> a FIXME was put in the comment. However the correct operation after
> read should be cache invalidate, not flush.
> 
> The underlying drivers should be responsible for the cache operation.
> Remove these codes completely.
> 
> Signed-off-by: Bin Meng 
> ---
> 
>   arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 15 ---
>   board/toradex/common/tdx-cfg-block.c|  2 --
>   cmd/mmc.c   |  2 --
>   drivers/block/blk-uclass.c  |  3 ---
>   drivers/block/blk_legacy.c  |  3 ---
>   drivers/net/fm/fm.c |  2 --
>   drivers/net/phy/cortina.c   |  2 --
>   drivers/qe/qe.c |  2 --
>   8 files changed, 31 deletions(-)
> 

Tested on LS1043ARDB with SD and NAND boot for PPA and FM.

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


Re: [U-Boot] [PATCH] blk: Remove various places that do flush cache after read

2017-08-23 Thread York Sun
On 08/22/2017 03:53 PM, Bin Meng wrote:
> Hi York,
> 
> On Wed, Aug 23, 2017 at 12:49 AM, York Sun  wrote:
>> On 08/21/2017 08:42 PM, Bin Meng wrote:
>>> All these places seem to inherit the codes from the MMC driver where
>>> a FIXME was put in the comment. However the correct operation after
>>> read should be cache invalidate, not flush.
>>>
>>> The underlying drivers should be responsible for the cache operation.
>>> Remove these codes completely.
>>>
>>> Signed-off-by: Bin Meng 
>>> ---
>>>
>>>arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 15 ---
>>>board/toradex/common/tdx-cfg-block.c|  2 --
>>>cmd/mmc.c   |  2 --
>>>drivers/block/blk-uclass.c  |  3 ---
>>>drivers/block/blk_legacy.c  |  3 ---
>>>drivers/net/fm/fm.c |  2 --
>>>drivers/net/phy/cortina.c   |  2 --
>>>drivers/qe/qe.c |  2 --
>>>8 files changed, 31 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c 
>>> b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
>>> index 24ddb5d..bbf8bba 100644
>>> --- a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
>>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
>>> @@ -107,9 +107,6 @@ int ppa_init(void)
>>>return -EIO;
>>>}
>>>
>>> - /* flush cache after read */
>>> - flush_cache((ulong)fitp, cnt * 512);
>>> -
>>
>> NACK here.
>>
>>
>>>ret = fdt_check_header(fitp);
>>>if (ret) {
>>>free(fitp);
>>> @@ -134,9 +131,6 @@ int ppa_init(void)
>>>}
>>>debug("Read PPA header to 0x%p\n", ppa_hdr_ddr);
>>>
>>> - /* flush cache after read */
>>> - flush_cache((ulong)ppa_hdr_ddr, cnt * 512);
>>> -
>>>ppa_esbc_hdr = (uintptr_t)ppa_hdr_ddr;
>>>#endif
>>>
>>> @@ -164,9 +158,6 @@ int ppa_init(void)
>>>return -EIO;
>>>}
>>>
>>> - /* flush cache after read */
>>> - flush_cache((ulong)ppa_fit_addr, cnt * 512);
>>> -
>>>#elif defined(CONFIG_SYS_LS_PPA_FW_IN_NAND)
>>>struct fdt_header fit;
>>>
>>> @@ -208,9 +199,6 @@ int ppa_init(void)
>>>}
>>>debug("Read PPA header to 0x%p\n", ppa_hdr_ddr);
>>>
>>> - /* flush cache after read */
>>> - flush_cache((ulong)ppa_hdr_ddr, fw_length);
>>> -
>>>ppa_esbc_hdr = (uintptr_t)ppa_hdr_ddr;
>>>#endif
>>>
>>> @@ -232,9 +220,6 @@ int ppa_init(void)
>>>   CONFIG_SYS_LS_PPA_FW_ADDR);
>>>return -EIO;
>>>}
>>> -
>>> - /* flush cache after read */
>>> - flush_cache((ulong)ppa_fit_addr, fw_length);
>>>#else
>>>#error "No CONFIG_SYS_LS_PPA_FW_IN_xxx defined"
>>>#endif
>>
>> Hold on for ppa.c. We need to flush the cache after reading PPA image
>> and it header after loading. These images need to be flushed into main
>> memory. I will need to confirm with our team if we can remove flushing here.
>>
> 
> For the first 3 parts in this ppa.c file, I see they are all reading
> PPA image from MMC while MMC driver is using DMA so this is wrong (as
> I mentioned in the commit message I suspect they are all copy/paste
> from the MMC driver).
> 
> The only questionable change is the last one which is reading
> something from NAND and if NAND driver is not using DMA, that cache
> flush is needed as you pointed out.
> 

Bin,

Our internal team agrees with the removing flushing for MMC.
Give me some time to test NAND.

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


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

2017-08-23 Thread Stefano Babic
Hi Peng,

On 09/08/2017 07:09, 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/mx6qsabresd board.
> 
> Signed-off-by: Peng Fan 
> Cc: Jagan Teki 
> cc: Stefano Babic 
> ---
> 

Reviewed-by: Stefano Babic 

Regards,
Stefano

> V2:
>  return -ENODEV when dev_get_addr not return a valid value.
>  Pass error value from dm_gpio_set_value to caller, if error happends.
> 
>  drivers/spi/mxc_spi.c | 181 
> +-
>  1 file changed, 149 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
> index e1562c3..41f0cfc 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;
> @@ -51,6 +50,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 +58,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 +216,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 +331,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 +342,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 +356,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 +368,39 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
> bitlen, const void *dout,
>   }
>  
>   if (flags & SPI_XFER_END) {
> - 

Re: [U-Boot] [PATCH] imx: mx7: psci: add copyright and license

2017-08-23 Thread Stefano Babic
On 17/08/2017 11:48, Peng Fan wrote:
> Add copyright and license header.
> 
> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> ---
>  arch/arm/mach-imx/mx7/psci-mx7.c | 7 +++
>  arch/arm/mach-imx/mx7/psci.S | 7 +++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c 
> b/arch/arm/mach-imx/mx7/psci-mx7.c
> index 502552d..7f429b0 100644
> --- a/arch/arm/mach-imx/mx7/psci-mx7.c
> +++ b/arch/arm/mach-imx/mx7/psci-mx7.c
> @@ -1,3 +1,10 @@
> +/*
> + * Copyright (C) 2015-2016 Freescale Semiconductor, Inc.
> + * Copyright 2017 NXP
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-imx/mx7/psci.S b/arch/arm/mach-imx/mx7/psci.S
> index 96e88d6..fc5eb34 100644
> --- a/arch/arm/mach-imx/mx7/psci.S
> +++ b/arch/arm/mach-imx/mx7/psci.S
> @@ -1,3 +1,10 @@
> +/*
> + * Copyright (C) 2015-2016 Freescale Semiconductor, Inc.
> + * Copyright 2017 NXP
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
>  #include 
>  #include 
>  
> 

Applied to u-boot-imx -master, 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] pico-imx7d: Add support for secure boot

2017-08-23 Thread Fabio Estevam
Hi Vanessa,

On Wed, Aug 23, 2017 at 11:05 AM, Vanessa Maegima
 wrote:
> Add a new defconfig to enable secure boot on pico-imx7d.

Please explain in the commit log why you are adding this new defconfig.

Anyway, I understant that this could be useful if someone tries to
boot this board with NXP 4.1.15 kernel.

Not sure it is worth the effort of adding a new defconfig only for
this purpose as mainline kernel can be used with existing U-Boot
defconfig.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] sunxi: Enable random UUIDs when GPT is enabled

2017-08-23 Thread Maxime Ripard
We can create GPT partitions without a UUID, but we need to have
RANDOM_UUID enabled to do that. Enable it.

Signed-off-by: Maxime Ripard 
---
 include/configs/sunxi-common.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 07c7ffd7f204..75bf668ecdb3 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -270,6 +270,10 @@ extern int soft_i2c_gpio_scl;
 /* GPIO */
 #define CONFIG_SUNXI_GPIO
 
+#ifdef CONFIG_EFI_PARTITION
+#define CONFIG_RANDOM_UUID 1
+#endif
+
 #ifdef CONFIG_VIDEO
 /*
  * The amount of RAM to keep free at the top of RAM when relocating u-boot,
-- 
2.13.5

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


[U-Boot] [PATCH] pico-imx7d: Add support for secure boot

2017-08-23 Thread Vanessa Maegima
Add a new defconfig to enable secure boot on pico-imx7d.

Signed-off-by: Vanessa Maegima 
---
 board/technexion/pico-imx7d/MAINTAINERS  |  1 +
 board/technexion/pico-imx7d/pico-imx7d.c |  9 +++-
 configs/pico-imx7d_secure_defconfig  | 35 
 3 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 configs/pico-imx7d_secure_defconfig

diff --git a/board/technexion/pico-imx7d/MAINTAINERS 
b/board/technexion/pico-imx7d/MAINTAINERS
index 3ab1aa6..3dd8bd6 100644
--- a/board/technexion/pico-imx7d/MAINTAINERS
+++ b/board/technexion/pico-imx7d/MAINTAINERS
@@ -4,3 +4,4 @@ S:  Maintained
 F: board/technexion/pico-imx7d/
 F: include/configs/pico-imx7d.h
 F: configs/pico-imx7d_defconfig
+F: configs/pico-imx7d_secure_defconfig
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
b/board/technexion/pico-imx7d/pico-imx7d.c
index b4c9be7..988f8a5 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -278,7 +278,14 @@ int board_late_init(void)
 
 int checkboard(void)
 {
-   puts("Board: i.MX7D PICOSOM\n");
+   char *mode;
+
+   if (IS_ENABLED(CONFIG_ARMV7_BOOT_SEC_DEFAULT))
+   mode = "secure";
+   else
+   mode = "non-secure";
+
+   printf("Board: i.MX7D PICOSOM in %s mode\n", mode);
 
return 0;
 }
diff --git a/configs/pico-imx7d_secure_defconfig 
b/configs/pico-imx7d_secure_defconfig
new file mode 100644
index 000..5d4e016
--- /dev/null
+++ b/configs/pico-imx7d_secure_defconfig
@@ -0,0 +1,35 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX7=y
+CONFIG_TARGET_PICO_IMX7D=y
+CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
+CONFIG_IMX_RDC=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/technexion/pico-imx7d/imximage.cfg"
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_MXC_USB_OTG_HACTIVE=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_CI_UDC=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="FSL"
+CONFIG_G_DNL_VENDOR_NUM=0x0525
+CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
+CONFIG_OF_LIBFDT=y
-- 
2.7.4

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


[U-Boot] [PATCH 3/4] part: efi: make gpt_fill_pte take the device descriptor

2017-08-23 Thread Maxime Ripard
The gpt_fill_pte will need to access the device block size. Let's pass the
device descriptor as an argument.

Signed-off-by: Maxime Ripard 
---
 disk/part_efi.c | 7 ---
 include/part.h  | 6 --
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index fa95ce12329a..807d01de39d0 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -428,8 +428,9 @@ int write_gpt_table(struct blk_desc *dev_desc,
return -1;
 }
 
-int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
-   disk_partition_t *partitions, int parts)
+int gpt_fill_pte(struct blk_desc *dev_desc,
+gpt_header *gpt_h, gpt_entry *gpt_e,
+disk_partition_t *partitions, int parts)
 {
lbaint_t offset = (lbaint_t)le64_to_cpu(gpt_h->first_usable_lba);
lbaint_t last_usable_lba = (lbaint_t)
@@ -633,7 +634,7 @@ int gpt_restore(struct blk_desc *dev_desc, char 
*str_disk_guid,
goto err;
 
/* Generate partition entries */
-   ret = gpt_fill_pte(gpt_h, gpt_e, partitions, parts_count);
+   ret = gpt_fill_pte(dev_desc, gpt_h, gpt_e, partitions, parts_count);
if (ret)
goto err;
 
diff --git a/include/part.h b/include/part.h
index 0cd803a9334f..0d5c99836b25 100644
--- a/include/part.h
+++ b/include/part.h
@@ -289,6 +289,7 @@ int write_gpt_table(struct blk_desc *dev_desc,
 /**
  * gpt_fill_pte(): Fill the GPT partition table entry
  *
+ * @param dev_desc - block device descriptor
  * @param gpt_h - GPT header representation
  * @param gpt_e - GPT partition table entries
  * @param partitions - list of partitions
@@ -296,8 +297,9 @@ int write_gpt_table(struct blk_desc *dev_desc,
  *
  * @return zero on success
  */
-int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
-   disk_partition_t *partitions, int parts);
+int gpt_fill_pte(struct blk_desc *dev_desc,
+gpt_header *gpt_h, gpt_entry *gpt_e,
+disk_partition_t *partitions, int parts);
 
 /**
  * gpt_fill_header(): Fill the GPT header
-- 
2.13.5

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


[U-Boot] [PATCH 1/4] part: efi: Fix offset

2017-08-23 Thread Maxime Ripard
Both the config option and the DT options specify the offset to set the GPT
at in bytes, yet the code treats those values as block numbers.

Fix that.

Signed-off-by: Maxime Ripard 
---
 disk/part_efi.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 71c3cb3f78d9..75d0a78f0a1f 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -534,6 +534,7 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
 static uint32_t partition_entries_offset(struct blk_desc *dev_desc)
 {
uint32_t offset_blks = 2;
+   uint32_t __maybe_unused offset_bytes;
int __maybe_unused config_offset;
 
 #if defined(CONFIG_EFI_PARTITION_ENTRIES_OFF)
@@ -545,8 +546,9 @@ static uint32_t partition_entries_offset(struct blk_desc 
*dev_desc)
 * the disk) for the entries can be set in
 * CONFIG_EFI_PARTITION_ENTRIES_OFF.
 */
-   offset_blks =
+   offset_bytes =
PAD_TO_BLOCKSIZE(CONFIG_EFI_PARTITION_ENTRIES_OFF, dev_desc);
+   offset_blks = offset_bytes / dev_desc->blksz;
 #endif
 
 #if defined(CONFIG_OF_CONTROL)
@@ -558,8 +560,10 @@ static uint32_t partition_entries_offset(struct blk_desc 
*dev_desc)
config_offset = fdtdec_get_config_int(gd->fdt_blob,
  
"u-boot,efi-partition-entries-offset",
  -EINVAL);
-   if (config_offset != -EINVAL)
-   offset_blks = PAD_TO_BLOCKSIZE(config_offset, dev_desc);
+   if (config_offset != -EINVAL) {
+   offset_bytes = PAD_TO_BLOCKSIZE(config_offset, dev_desc);
+   offset_blks = offset_bytes / dev_desc->blksz;
+   }
 #endif
 
debug("efi: partition entries offset (in blocks): %d\n", offset_blks);
-- 
2.13.5

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


[U-Boot] [PATCH 4/4] part: efi: Disable overlap check

2017-08-23 Thread Maxime Ripard
The current code checks that no partitions overlap with the GPT partition
table using the offset of the first LBA usable for that partition.

This works fine, unless you have a partition entry that is further away
than it usually is and you want to create partitions in the gap between the
GPT header and the GPT partition entries, for example to reflash a
bootloader that needs to be set there.

Rework the test to something a bit smarter that checks whether a partition
would overlap with either the GPT header or the partition entries, no
matter where it is on the disk.

Partitions that do not have a start LBA specified will still start at the
first LBA usable set in the GPT header, to avoid weird behaviours.

Signed-off-by: Maxime Ripard 
---
 disk/part_efi.c | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 807d01de39d0..2973d52f6abb 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -445,24 +445,38 @@ int gpt_fill_pte(struct blk_desc *dev_desc,
char *str_type_guid;
unsigned char *bin_type_guid;
 #endif
+   size_t hdr_start = gpt_h->my_lba;
+   size_t hdr_end = hdr_start + 1;
+
+   size_t pte_start = gpt_h->partition_entry_lba;
+   size_t pte_end = pte_start +
+   gpt_h->num_partition_entries * gpt_h->sizeof_partition_entry /
+   dev_desc->blksz;
 
for (i = 0; i < parts; i++) {
/* partition starting lba */
lbaint_t start = partitions[i].start;
lbaint_t size = partitions[i].size;
 
-   if (start && (start < offset)) {
-   printf("Partition overlap\n");
-   return -1;
-   }
-
if (start) {
-   gpt_e[i].starting_lba = cpu_to_le64(start);
offset = start + size;
} else {
-   gpt_e[i].starting_lba = cpu_to_le64(offset);
+   start = offset;
offset += size;
}
+
+   /*
+* If our partition overlaps with either the GPT
+* header, or the partition entry, reject it.
+*/
+   if (((start <= hdr_end && hdr_start <= (start + size)) ||
+(start <= pte_end && pte_start <= (start + size {
+   printf("Partition overlap\n");
+   return -1;
+   }
+
+   gpt_e[i].starting_lba = cpu_to_le64(start);
+
if (offset > (last_usable_lba + 1)) {
printf("Partitions layout exceds disk size\n");
return -1;
-- 
2.13.5

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


[U-Boot] [PATCH 2/4] part: efi: rework the partition start and size in gpt_fill_pte

2017-08-23 Thread Maxime Ripard
The start variable is only used inside a loop, and is never affected inside
it, so it's a purely local variable.

In the same way the partition size is accessed several times, so we can
store it in a variable.

Signed-off-by: Maxime Ripard 
---
 disk/part_efi.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 75d0a78f0a1f..fa95ce12329a 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -432,7 +432,6 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
disk_partition_t *partitions, int parts)
 {
lbaint_t offset = (lbaint_t)le64_to_cpu(gpt_h->first_usable_lba);
-   lbaint_t start;
lbaint_t last_usable_lba = (lbaint_t)
le64_to_cpu(gpt_h->last_usable_lba);
int i, k;
@@ -448,24 +447,27 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
 
for (i = 0; i < parts; i++) {
/* partition starting lba */
-   start = partitions[i].start;
+   lbaint_t start = partitions[i].start;
+   lbaint_t size = partitions[i].size;
+
if (start && (start < offset)) {
printf("Partition overlap\n");
return -1;
}
+
if (start) {
gpt_e[i].starting_lba = cpu_to_le64(start);
-   offset = start + partitions[i].size;
+   offset = start + size;
} else {
gpt_e[i].starting_lba = cpu_to_le64(offset);
-   offset += partitions[i].size;
+   offset += size;
}
if (offset > (last_usable_lba + 1)) {
printf("Partitions layout exceds disk size\n");
return -1;
}
/* partition ending lba */
-   if ((i == parts - 1) && (partitions[i].size == 0))
+   if ((i == parts - 1) && (size == 0))
/* extend the last partition to maximuim */
gpt_e[i].ending_lba = gpt_h->last_usable_lba;
else
@@ -525,7 +527,7 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
debug("%s: name: %s offset[%d]: 0x" LBAF
  " size[%d]: 0x" LBAF "\n",
  __func__, partitions[i].name, i,
- offset, i, partitions[i].size);
+ offset, i, size);
}
 
return 0;
-- 
2.13.5

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


Re: [U-Boot] [PATCH] sunxi: usb_phy: invert the USB phy_ctl condition

2017-08-23 Thread Jagan Teki
On Wed, Aug 23, 2017 at 5:01 PM, Maxime Ripard
 wrote:
> All the new SoCs from Allwinner since the A33 have had the phy_ctl offset
> at 0x410 instead of 0x404 that was used on the previous SoCs.
>
> Instead of adding more and more special cases as the number of SoCs grow,
> let's invert the test to have 0x410 by default, and the (hopefully) fixed
> number of old SoCs being the exception.
>
> Suggested-by: Siarhei Siamashka 
> Suggested-by: Chen-Yu Tsai 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] rk3288: 32KB SPL size restriction

2017-08-23 Thread Dr. Philipp Tomsich

> On 23 Aug 2017, at 13:19, Jagan Teki  wrote:
> 
> Hi Philipp,
> 
> On Tue, Aug 22, 2017 at 5:41 PM, Dr. Philipp Tomsich
>  wrote:
>> 
>>> On 22 Aug 2017, at 14:05, Jagan Teki  wrote:
>>> 
>>> Philipp and Kever - Thanks for the response.
>>> 
>>> Few comment below.
>>> 
>>> On Thu, Aug 17, 2017 at 2:02 PM, Dr. Philipp Tomsich
>>>  wrote:
 Jagan,
 
> On 17 Aug 2017, at 08:39, Kever Yang  wrote:
> 
> Hi Jagan,
> 
> 
> On 08/10/2017 05:07 PM, Jagan Teki wrote:
>> Hi Simon/Philipp or any,
>> 
>> I believe rk3288 has 20KB BootRom and 100KB internal SRAM and current
>> u-boot can archive the maximum size of u-boot-spl-dtb.bin which the
>> boot ROM will read is 32KB, do we have any possibility to increase the
>> SPL size here.
> 
> The limitation is decide by the boot rom design, so we are not able
> to change this. Most of Rockchip SoCs have this limitation except RK3399.
> 
> Thanks,
> - Kever
>> 
>> # ./tools/mkimage -n rk3288 -T rksd -d ./spl/u-boot-spl-dtb.bin out.img
>> Warning: SPL image is too large (size 0x9000) and will not boot
>> Error: image verification failed
>> 
>> I tried to increase the spl_size from spl_infos (on tools/rkcommon.c)
>> but not able to boot.
 
 I should have read this more carefully (I only parsed the 20KB and
 jumped to the conclusion that your had the error already when crossing
 the 20KB limit—even though 0x8000 bytes where allowed in mkimage)…
>>> 
>>> Sorry I really didn't understand the size constraint here, because SPL
>>> can be boot file after ROM handoff. Can't this sit on 100KB of SRAM?
>> 
>> The ROM usually has different size constraints for each stage.
>> 
>> E.g. for the RK3368 (just been there, done that), the first stage has a
>> 0x7000 byte limit and the next stage (loaded to 0x0 in DRAM) has a
>> much larger limit. Note that the SRAM on the 3368 has a capacity of
>> 0x1 bytes, so the size limit is also quite pronounced.
> 
> OK, by looking at your rk3368[1] patch I think the first stage runs
> under 0x7000 is TPL? and next stage(probably SPL) doesn't have limit
> since SPL running here in DDR since DDR initialized DDR in TPL itself.
> this is what the space distributed here?

Yes, although there is some size limit even for SPL.
If you are going for a falcon-mode implementation on the 3288, you will
probably want to use TPL for DRAM setup and maybe clocking up the
cores (I don’t know the constraints on what clocks the BROM needs
untouched) and then have SPL w/ falcon mode loaded by the BROM.


> 
> [1] 
> http://git.denx.de/?p=u-boot-rockchip.git;a=commitdiff;h=a55e4971569d2aa0150a1521876c928927e18471
> 
> thanks!
> -- 
> Jagan Teki
> Free Software Engineer | www.openedev.com
> U-Boot, Linux | Upstream Maintainer
> Hyderabad, India.

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


Re: [U-Boot] [PATCH] serial: nulldev: Add nulldev serial driver

2017-08-23 Thread Bin Meng
Hi Wilson,

On Wed, Aug 23, 2017 at 12:51 PM, Wilson Lee  wrote:
> From: Keng Soon Cheah 
>
> Some device the serial console's initialization cannot run early during
> the boot process. Hence, nulldev serial device is helpful on that
> situation.
>
> This commit is to adding nulldev serial driver. This will allows the
> default console to be specified as a nulldev.

Can you elaborate more on what issue this patch is going to resolve?

>
> Signed-off-by: Joe Hershberger 
> Signed-off-by: Keng Soon Cheah 
> Cc: Chen Yee Chew 
> Signed-off-by: Wilson Lee 
> ---
>
>  drivers/serial/Kconfig  |   7 +++
>  drivers/serial/Makefile |   1 +
>  drivers/serial/serial.c |   2 +
>  drivers/serial/serial_nulldev.c | 103 
> 
>  include/serial.h|   2 +
>  5 files changed, 115 insertions(+)
>  create mode 100644 drivers/serial/serial_nulldev.c
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index a8e9978..5064edf 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -409,6 +409,13 @@ config MXC_UART
>   If you have a machine based on a Motorola IMX CPU you
>   can enable its onboard serial port by enabling this option.
>
> +config NULLDEV_SERIAL
> +   bool "Null serial device"
> +   help
> + Select this to enable null serial device support. A null serial
> + device merely acts as a placeholder for a serial device and does
> + nothing for all it's operation.
> +
>  config PIC32_SERIAL
> bool "Support for Microchip PIC32 on-chip UART"
> depends on DM_SERIAL && MACH_PIC32
> diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
> index 72a6996..7adcee3 100644
> --- a/drivers/serial/Makefile
> +++ b/drivers/serial/Makefile
> @@ -49,6 +49,7 @@ obj-$(CONFIG_BCM283X_MU_SERIAL) += serial_bcm283x_mu.o
>  obj-$(CONFIG_MSM_SERIAL) += serial_msm.o
>  obj-$(CONFIG_MVEBU_A3700_UART) += serial_mvebu_a3700.o
>  obj-$(CONFIG_MPC8XX_CONS) += serial_mpc8xx.o
> +obj-$(CONFIG_NULLDEV_SERIAL) += serial_nulldev.o
>
>  ifndef CONFIG_SPL_BUILD
>  obj-$(CONFIG_USB_TTY) += usbtty.o
> diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
> index cc4bdcb..b902162 100644
> --- a/drivers/serial/serial.c
> +++ b/drivers/serial/serial.c
> @@ -138,6 +138,7 @@ serial_initfunc(mpc8xx_serial_initialize);
>  serial_initfunc(mxc_serial_initialize);
>  serial_initfunc(mxs_auart_initialize);
>  serial_initfunc(ns16550_serial_initialize);
> +serial_initfunc(nulldev_serial_initialize);
>  serial_initfunc(oc_serial_initialize);
>  serial_initfunc(p3mx_serial_initialize);
>  serial_initfunc(pl01x_serial_initialize);
> @@ -225,6 +226,7 @@ void serial_initialize(void)
> mxc_serial_initialize();
> mxs_auart_initialize();
> ns16550_serial_initialize();
> +   nulldev_serial_initialize();

Please stop adding non-DM driver.

> oc_serial_initialize();
> p3mx_serial_initialize();
> pl01x_serial_initialize();
> diff --git a/drivers/serial/serial_nulldev.c b/drivers/serial/serial_nulldev.c
> new file mode 100644
> index 000..0545a74
> --- /dev/null
> +++ b/drivers/serial/serial_nulldev.c
> @@ -0,0 +1,103 @@
> +/*
> + * Copyright (c) 2015 National Instruments
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +
> +#ifndef CONFIG_DM_SERIAL
> +
> +static int nulldev_init(void)
> +{
> +   /* nulldev is empty! */
> +   return 0;
> +}
> +
> +static void nulldev_setbrg(void)
> +{
> +   /* nulldev is empty! */
> +}
> +
> +static void nulldev_putc(const char c)
> +{
> +   /* nulldev is empty! */
> +}
> +
> +static void nulldev_puts(const char *s)
> +{
> +   /* nulldev is empty! */
> +}
> +
> +static int nulldev_input(void)
> +{
> +   /* nulldev is empty! */
> +   return 0;
> +}
> +
> +struct serial_device nulldev_serial_device = {
> +   "nulldev",
> +   nulldev_init,
> +   NULL,
> +   nulldev_setbrg,
> +   nulldev_input,
> +   nulldev_input,
> +   nulldev_putc,
> +   nulldev_puts,
> +};
> +
> +void nulldev_serial_initialize(void)
> +{
> +   serial_register(_serial_device);
> +}
> +
> +__weak struct serial_device *default_serial_console(void)
> +{
> +   return _serial_device;
> +}
> +
> +#else /* CONFIG_DM_SERIAL */
> +
> +static int nulldev_serial_setbrg(struct udevice *dev, int baudrate)
> +{
> +   return 0;
> +}
> +
> +static int nulldev_serial_getc(struct udevice *dev)
> +{
> +   return -EAGAIN;
> +}
> +
> +static int nulldev_serial_input(struct udevice *dev)
> +{
> +   return 0;
> +}
> +
> +static int nulldev_serial_putc(struct udevice *dev, const char ch)
> +{
> +   return 0;
> +}
> +
> +static const struct udevice_id nulldev_serial_ids[] = {
> +   { .compatible 

Re: [U-Boot] [PATCH v2 0/8] imx: add USB Serial Download Protocol (SDP) support

2017-08-23 Thread Fabio Estevam
On Wed, Aug 23, 2017 at 5:43 AM, Stefano Babic  wrote:

> I have merged the whole series to u-boot-imx. Many thanks for your
> effort, this was in the TODO list for i.MX since a long time !

Yes, very nice job, Stefan!

I will be using it soon on mx6sabresd, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/4] mmc: sunxi: fix legacy MMC initialisation

2017-08-23 Thread Maxime Ripard
The driver-model rework changed, among other things, the way the private
data were moved around. It now uses the private field in the struct mmc.

However, the mmc_create argument was changed in the process to always pass
the array we used to have to store our private structures.

The basically means that all the MMC driver instances will now have the
private data of the first instance, which obviously doesn't work very well.

Pass the proper pointer to mmc_create.

Fixes: 034e226bc77e ("dm: mmc: sunxi: Pass private data around explicitly")
Signed-off-by: Maxime Ripard 
---
 drivers/mmc/sunxi_mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 588574fab6a9..30f1f76e9f8c 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -498,7 +498,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
if (ret)
return NULL;
 
-   return mmc_create(cfg, mmc_host);
+   return mmc_create(cfg, priv);
 }
 #else
 
-- 
2.13.5

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


[U-Boot] [PATCH 4/4] sunxi: Remove the MMC index hack

2017-08-23 Thread Maxime Ripard
The current code, if there's both an eMMC and an MMC slot available on the
board, will swap the MMC indices based on whether we booted from the eMMC
or the MMC. This way, the MMC we're supposed to boot on will always have
the index 0.

However, this causes various issues, for example when using other
components that base their behaviour on the MMC index, such as fastboot.

Let's remove that hack, and take the opposite approach. The MMC will always
have the same index, but the bootcmd will pick the same device than the one
we booted from. This is done through the introduction of the mmc_bootdev
environment variable that will be filled by the board code based on the
boot device informations we can get from the SoC.

In order to not introduce regressions, we also need to adjust the fastboot
MMC device and the environment device in order to set it to the eMMC, over
the MMC, like it used to be the case.

Signed-off-by: Maxime Ripard 
---
 board/sunxi/board.c| 20 ++--
 include/configs/sunxi-common.h | 36 ++--
 2 files changed, 36 insertions(+), 20 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index e1d48140878f..664c7d2d8126 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -492,20 +492,6 @@ int board_mmc_init(bd_t *bis)
return -1;
 #endif
 
-#if !defined(CONFIG_SPL_BUILD) && CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
-   /*
-* On systems with an emmc (mmc2), figure out if we are booting from
-* the emmc and if we are make it "mmc dev 0" so that boot.scr, etc.
-* are searched there first. Note we only do this for u-boot proper,
-* not for the SPL, see spl_boot_device().
-*/
-   if (readb(SPL_ADDR + 0x28) == SUNXI_BOOTED_FROM_MMC2) {
-   /* Booting from emmc / mmc2, swap */
-   mmc0->block_dev.devnum = 1;
-   mmc1->block_dev.devnum = 0;
-   }
-#endif
-
return 0;
 }
 #endif
@@ -725,12 +711,18 @@ int misc_init_r(void)
 
setenv("fel_booted", NULL);
setenv("fel_scriptaddr", NULL);
+   setenv("mmc_bootdev", NULL);
 
boot = spl_boot_device();
/* determine if we are running in FEL mode */
if (boot == BOOT_DEVICE_BOARD) {
setenv("fel_booted", "1");
parse_spl_header(SPL_ADDR);
+   /* or if we booted from MMC, and which one */
+   } else if (boot == BOOT_DEVICE_MMC1) {
+   setenv("mmc_bootdev", "0");
+   } else if (boot == BOOT_DEVICE_MMC2) {
+   setenv("mmc_bootdev", "1");
}
 
setup_environment(gd->fdt_blob);
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 07c7ffd7f204..79dc30cc 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -148,7 +148,13 @@
 #endif
 
 #if defined(CONFIG_ENV_IS_IN_MMC)
-#define CONFIG_SYS_MMC_ENV_DEV 0   /* first detected MMC 
controller */
+#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
+/* If we have two devices (most likely eMMC + MMC), favour the eMMC */
+#define CONFIG_SYS_MMC_ENV_DEV 1
+#else
+/* Otherwise, use the only device we have */
+#define CONFIG_SYS_MMC_ENV_DEV 0
+#endif
 #define CONFIG_SYS_MMC_MAX_DEVICE  4
 #elif defined(CONFIG_ENV_IS_NOWHERE)
 #define CONFIG_ENV_SIZE(128 << 10)
@@ -328,9 +334,15 @@ extern int soft_i2c_gpio_scl;
 #define CONFIG_FASTBOOT_FLASH
 
 #ifdef CONFIG_MMC
+#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
+/* If we have two devices (most likely eMMC + MMC), favour the eMMC */
+#define CONFIG_FASTBOOT_FLASH_MMC_DEV  1
+#else
+/* Otherwise, use the only device we have */
 #define CONFIG_FASTBOOT_FLASH_MMC_DEV  0
 #endif
 #endif
+#endif
 
 #ifdef CONFIG_USB_FUNCTION_MASS_STORAGE
 #endif
@@ -405,15 +417,28 @@ extern int soft_i2c_gpio_scl;
"ramdisk ram " RAMDISK_ADDR_R " 0x400\0"
 
 #ifdef CONFIG_MMC
-#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0)
 #if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
-#define BOOT_TARGET_DEVICES_MMC_EXTRA(func) func(MMC, mmc, 1)
+#define BOOTENV_DEV_MMC_AUTO(devtypeu, devtypel, instance) \
+   BOOTENV_DEV_MMC(MMC, mmc, 0)\
+   BOOTENV_DEV_MMC(MMC, mmc, 1)\
+   "bootcmd_mmc_auto=" \
+   "if test ${mmc_bootdev} -eq 1; then "   \
+   "run bootcmd_mmc1; "\
+   "run bootcmd_mmc0; "\
+   "elif test ${mmc_bootdev} -eq 0; then " \
+   "run bootcmd_mmc0; "\
+   "run bootcmd_mmc1; "\
+   "fi\0"
+
+#define BOOTENV_DEV_NAME_MMC_AUTO(devtypeu, devtypel, instance) \
+   "mmc_auto "
+

[U-Boot] [PATCH 3/4] sunxi: Use spl_boot_device

2017-08-23 Thread Maxime Ripard
Our current board code duplicates a bit the spl_boot_device logic. Now that
we can use that function in the full-flavoured U-Boot, remove that
duplication and call the function instead.

Signed-off-by: Maxime Ripard 
---
 board/sunxi/board.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 800f412b383d..e1d48140878f 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -720,11 +721,14 @@ static void setup_environment(const void *fdt)
 int misc_init_r(void)
 {
__maybe_unused int ret;
+   uint boot;
 
setenv("fel_booted", NULL);
setenv("fel_scriptaddr", NULL);
+
+   boot = spl_boot_device();
/* determine if we are running in FEL mode */
-   if (!is_boot0_magic(SPL_ADDR + 4)) { /* eGON.BT0 */
+   if (boot == BOOT_DEVICE_BOARD) {
setenv("fel_booted", "1");
parse_spl_header(SPL_ADDR);
}
-- 
2.13.5

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


[U-Boot] [PATCH 2/4] arm: sunxi: compile spl_boot_device even for U-Boot

2017-08-23 Thread Maxime Ripard
U-Boot itself might need to identify the boot device, for example to be
able to tell where to load the kernel from when several options are
possible.

Remove the guard preventing it from being compiled.

Signed-off-by: Maxime Ripard 
---
 arch/arm/mach-sunxi/board.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 65b1ebd83787..f5e977b4183d 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -14,9 +14,7 @@
 #include 
 #include 
 #include 
-#ifdef CONFIG_SPL_BUILD
 #include 
-#endif
 #include 
 #include 
 #include 
@@ -210,7 +208,6 @@ void s_init(void)
eth_init_board();
 }
 
-#ifdef CONFIG_SPL_BUILD
 DECLARE_GLOBAL_DATA_PTR;
 
 /* The sunxi internal brom will try to loader external bootloader
@@ -261,6 +258,7 @@ u32 spl_boot_mode(const u32 boot_device)
return MMCSD_MODE_RAW;
 }
 
+#ifdef CONFIG_SPL_BUILD
 void board_init_f(ulong dummy)
 {
spl_init();
-- 
2.13.5

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


[U-Boot] [PATCH 0/4] mmc: sunxi: index hack removal

2017-08-23 Thread Maxime Ripard
Hi,

Here is an attempt at removing the hack in the sunxi code to switch
the MMC indices depending on the boot device.

It's based on Siarhei's suggestion to go through an environment
variable set by the code, and then having a script in our default
bootcmd to change the boot order in order to always favour the boot
device, instead of always picking the external MMC first.

Let me know what you think,
Maxime

Maxime Ripard (4):
  mmc: sunxi: fix legacy MMC initialisation
  arm: sunxi: compile spl_boot_device even for U-Boot
  sunxi: Use spl_boot_device
  sunxi: Remove the MMC index hack

 arch/arm/mach-sunxi/board.c|  4 +---
 board/sunxi/board.c| 26 +++---
 drivers/mmc/sunxi_mmc.c|  2 +-
 include/configs/sunxi-common.h | 36 ++--
 4 files changed, 43 insertions(+), 25 deletions(-)

-- 
2.13.5

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


[U-Boot] [PATCH] sunxi: usb_phy: invert the USB phy_ctl condition

2017-08-23 Thread Maxime Ripard
All the new SoCs from Allwinner since the A33 have had the phy_ctl offset
at 0x410 instead of 0x404 that was used on the previous SoCs.

Instead of adding more and more special cases as the number of SoCs grow,
let's invert the test to have 0x410 by default, and the (hopefully) fixed
number of old SoCs being the exception.

Suggested-by: Siarhei Siamashka 
Suggested-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/mach-sunxi/usb_phy.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-sunxi/usb_phy.c b/arch/arm/mach-sunxi/usb_phy.c
index 9bf0b5633d4a..2f1cad1aad9e 100644
--- a/arch/arm/mach-sunxi/usb_phy.c
+++ b/arch/arm/mach-sunxi/usb_phy.c
@@ -18,12 +18,18 @@
 #include 
 #include 
 
-#define SUNXI_USB_PMU_IRQ_ENABLE   0x800
-#ifdef CONFIG_MACH_SUN8I_A33
-#define SUNXI_USB_CSR  0x410
-#else
+#if defined(CONFIG_MACH_SUN4I) || \
+   defined(CONFIG_MACH_SUN5I) ||  \
+   defined(CONFIG_MACH_SUN6I) ||  \
+   defined(CONFIG_MACH_SUN7I) ||  \
+   defined(CONFIG_MACH_SUN8I_A23) ||  \
+   defined(CONFIG_MACH_SUN9I)
 #define SUNXI_USB_CSR  0x404
+#else
+#define SUNXI_USB_CSR  0x410
 #endif
+
+#define SUNXI_USB_PMU_IRQ_ENABLE   0x800
 #define SUNXI_USB_PASSBY_EN1
 
 #define SUNXI_EHCI_AHB_ICHR8_EN(1 << 10)
-- 
2.13.5

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


Re: [U-Boot] rk3288: 32KB SPL size restriction

2017-08-23 Thread Jagan Teki
Hi Philipp,

On Tue, Aug 22, 2017 at 5:41 PM, Dr. Philipp Tomsich
 wrote:
>
>> On 22 Aug 2017, at 14:05, Jagan Teki  wrote:
>>
>> Philipp and Kever - Thanks for the response.
>>
>> Few comment below.
>>
>> On Thu, Aug 17, 2017 at 2:02 PM, Dr. Philipp Tomsich
>>  wrote:
>>> Jagan,
>>>
 On 17 Aug 2017, at 08:39, Kever Yang  wrote:

 Hi Jagan,


 On 08/10/2017 05:07 PM, Jagan Teki wrote:
> Hi Simon/Philipp or any,
>
> I believe rk3288 has 20KB BootRom and 100KB internal SRAM and current
> u-boot can archive the maximum size of u-boot-spl-dtb.bin which the
> boot ROM will read is 32KB, do we have any possibility to increase the
> SPL size here.

 The limitation is decide by the boot rom design, so we are not able
 to change this. Most of Rockchip SoCs have this limitation except RK3399.

 Thanks,
 - Kever
>
> # ./tools/mkimage -n rk3288 -T rksd -d ./spl/u-boot-spl-dtb.bin out.img
> Warning: SPL image is too large (size 0x9000) and will not boot
> Error: image verification failed
>
> I tried to increase the spl_size from spl_infos (on tools/rkcommon.c)
> but not able to boot.
>>>
>>> I should have read this more carefully (I only parsed the 20KB and
>>> jumped to the conclusion that your had the error already when crossing
>>> the 20KB limit—even though 0x8000 bytes where allowed in mkimage)…
>>
>> Sorry I really didn't understand the size constraint here, because SPL
>> can be boot file after ROM handoff. Can't this sit on 100KB of SRAM?
>
> The ROM usually has different size constraints for each stage.
>
> E.g. for the RK3368 (just been there, done that), the first stage has a
> 0x7000 byte limit and the next stage (loaded to 0x0 in DRAM) has a
> much larger limit. Note that the SRAM on the 3368 has a capacity of
> 0x1 bytes, so the size limit is also quite pronounced.

OK, by looking at your rk3368[1] patch I think the first stage runs
under 0x7000 is TPL? and next stage(probably SPL) doesn't have limit
since SPL running here in DDR since DDR initialized DDR in TPL itself.
this is what the space distributed here?

[1] 
http://git.denx.de/?p=u-boot-rockchip.git;a=commitdiff;h=a55e4971569d2aa0150a1521876c928927e18471

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] mmc: sunxi: Support new mode

2017-08-23 Thread Jaehoon Chung
Hi,

On 08/23/2017 07:03 PM, Maxime Ripard wrote:
> Almost all of the newer Allwinner SoCs have a new operating mode for the
> eMMC clocks that needs to be enabled in both the clock and the MMC
> controller.
> 
> Details about that mode are sparse, and the name itself (new mode vs old
> mode) doesn't give much details, but it seems that the it changes the
> sampling of the MMC clock. One side effect is also that it divides the
> parent clock rate by 2.
> 
> Add support for it through a Kconfig option.

Well, i don't know exactly what mode likes your mention..
I think it can be got from dt if it's provided from controller IP or SoC.
how about?

Best Regards,
Jaehoon Chung

> 
> Signed-off-by: Maxime Ripard 
> 
> ---
> Changes from v1:
>   - Switched to IS_ENABLED when possible
>   - Added some defines
>   - Tried to put more details in the commit log
>   - Added a depends on in the Kconfig option
> ---
>  arch/arm/include/asm/arch-sunxi/clock_sun8i_a83t.h |  1 +
>  arch/arm/include/asm/arch-sunxi/mmc.h  | 11 ++---
>  drivers/mmc/Kconfig|  4 
>  drivers/mmc/sunxi_mmc.c| 27 
> +++---
>  4 files changed, 37 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun8i_a83t.h 
> b/arch/arm/include/asm/arch-sunxi/clock_sun8i_a83t.h
> index 5e1346e5242a..5dfcbf3b017b 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun8i_a83t.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun8i_a83t.h
> @@ -220,6 +220,7 @@ struct sunxi_ccm_reg {
>  #define CCM_MMC_CTRL_SCLK_DLY(x) ((x) << 20)
>  #define CCM_MMC_CTRL_OSCM24  (0x0 << 24)
>  #define CCM_MMC_CTRL_PLL6(0x1 << 24)
> +#define CCM_MMC_CTRL_MODE_SEL_NEW(0x1 << 30)
>  #define CCM_MMC_CTRL_ENABLE  (0x1 << 31)
>  
>  #define CCM_USB_CTRL_PHY0_RST (0x1 << 0)
> diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h 
> b/arch/arm/include/asm/arch-sunxi/mmc.h
> index cb52e648731c..69f737f3bffc 100644
> --- a/arch/arm/include/asm/arch-sunxi/mmc.h
> +++ b/arch/arm/include/asm/arch-sunxi/mmc.h
> @@ -35,16 +35,19 @@ struct sunxi_mmc {
>   u32 cbcr;   /* 0x48 CIU byte count */
>   u32 bbcr;   /* 0x4c BIU byte count */
>   u32 dbgc;   /* 0x50 debug enable */
> - u32 res0[11];
> + u32 res0;   /* 0x54 reserved */
> + u32 a12a;   /* 0x58 Auto command 12 argument */
> + u32 ntsr;   /* 0x5c New timing set register */
> + u32 res1[8];
>   u32 dmac;   /* 0x80 internal DMA control */
>   u32 dlba;   /* 0x84 internal DMA descr list base address */
>   u32 idst;   /* 0x88 internal DMA status */
>   u32 idie;   /* 0x8c internal DMA interrupt enable */
>   u32 chda;   /* 0x90 */
>   u32 cbda;   /* 0x94 */
> - u32 res1[26];
> + u32 res2[26];
>  #ifdef CONFIG_SUNXI_GEN_SUN6I
> - u32 res2[64];
> + u32 res3[64];
>  #endif
>   u32 fifo;   /* 0x100 / 0x200 FIFO access address */
>  };
> @@ -116,6 +119,8 @@ struct sunxi_mmc {
>  #define SUNXI_MMC_STATUS_CARD_DATA_BUSY  (0x1 << 9)
>  #define SUNXI_MMC_STATUS_DATA_FSM_BUSY   (0x1 << 10)
>  
> +#define SUNXI_MMC_NTSR_MODE_SEL_NEW  (0x1 << 31)
> +
>  #define SUNXI_MMC_IDMAC_RESET(0x1 << 0)
>  #define SUNXI_MMC_IDMAC_FIXBURST (0x1 << 1)
>  #define SUNXI_MMC_IDMAC_ENABLE   (0x1 << 7)
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 51a87cdd77dc..9075b346036b 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -389,6 +389,10 @@ config MMC_SUNXI
> This selects support for the SD/MMC Host Controller on
> Allwinner sunxi SoCs.
>  
> +config MMC_SUNXI_HAS_NEW_MODE
> + bool
> + depends on MMC_SUNXI
> +
>  config GENERIC_ATMEL_MCI
>   bool "Atmel Multimedia Card Interface support"
>   depends on DM_MMC && BLK && DM_MMC_OPS && ARCH_AT91
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 588574fab6a9..bc638ae2e64a 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -96,6 +96,18 @@ static int mmc_resource_init(int sdc_no)
>  static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
>  {
>   unsigned int pll, pll_hz, div, n, oclk_dly, sclk_dly;
> + bool new_mode = false;
> + u32 val = 0;
> +
> + if (IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE) && (priv->mmc_no == 2))
> + new_mode = true;
> +
> + /*
> +  * The MMC clock has an extra /2 post-divider when operating in the new
> +  * mode.
> +  */
> + if (new_mode)
> + hz = hz * 2;
>  
>   if (hz <= 2400) {
>   pll = CCM_MMC_CTRL_OSCM24;
> @@ -152,9 +164,18 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
> unsigned int hz)
>  

[U-Boot] [PATCH] serial: nulldev: Add nulldev serial driver

2017-08-23 Thread Wilson Lee
From: Keng Soon Cheah 

Some device the serial console's initialization cannot run early during
the boot process. Hence, nulldev serial device is helpful on that
situation.

This commit is to adding nulldev serial driver. This will allows the
default console to be specified as a nulldev.

Signed-off-by: Joe Hershberger 
Signed-off-by: Keng Soon Cheah 
Cc: Chen Yee Chew 
Signed-off-by: Wilson Lee 
---

 drivers/serial/Kconfig  |   7 +++
 drivers/serial/Makefile |   1 +
 drivers/serial/serial.c |   2 +
 drivers/serial/serial_nulldev.c | 103 
 include/serial.h|   2 +
 5 files changed, 115 insertions(+)
 create mode 100644 drivers/serial/serial_nulldev.c

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index a8e9978..5064edf 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -409,6 +409,13 @@ config MXC_UART
  If you have a machine based on a Motorola IMX CPU you
  can enable its onboard serial port by enabling this option.
 
+config NULLDEV_SERIAL
+   bool "Null serial device"
+   help
+ Select this to enable null serial device support. A null serial
+ device merely acts as a placeholder for a serial device and does
+ nothing for all it's operation.
+
 config PIC32_SERIAL
bool "Support for Microchip PIC32 on-chip UART"
depends on DM_SERIAL && MACH_PIC32
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 72a6996..7adcee3 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_BCM283X_MU_SERIAL) += serial_bcm283x_mu.o
 obj-$(CONFIG_MSM_SERIAL) += serial_msm.o
 obj-$(CONFIG_MVEBU_A3700_UART) += serial_mvebu_a3700.o
 obj-$(CONFIG_MPC8XX_CONS) += serial_mpc8xx.o
+obj-$(CONFIG_NULLDEV_SERIAL) += serial_nulldev.o
 
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_USB_TTY) += usbtty.o
diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index cc4bdcb..b902162 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -138,6 +138,7 @@ serial_initfunc(mpc8xx_serial_initialize);
 serial_initfunc(mxc_serial_initialize);
 serial_initfunc(mxs_auart_initialize);
 serial_initfunc(ns16550_serial_initialize);
+serial_initfunc(nulldev_serial_initialize);
 serial_initfunc(oc_serial_initialize);
 serial_initfunc(p3mx_serial_initialize);
 serial_initfunc(pl01x_serial_initialize);
@@ -225,6 +226,7 @@ void serial_initialize(void)
mxc_serial_initialize();
mxs_auart_initialize();
ns16550_serial_initialize();
+   nulldev_serial_initialize();
oc_serial_initialize();
p3mx_serial_initialize();
pl01x_serial_initialize();
diff --git a/drivers/serial/serial_nulldev.c b/drivers/serial/serial_nulldev.c
new file mode 100644
index 000..0545a74
--- /dev/null
+++ b/drivers/serial/serial_nulldev.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (c) 2015 National Instruments
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+
+#ifndef CONFIG_DM_SERIAL
+
+static int nulldev_init(void)
+{
+   /* nulldev is empty! */
+   return 0;
+}
+
+static void nulldev_setbrg(void)
+{
+   /* nulldev is empty! */
+}
+
+static void nulldev_putc(const char c)
+{
+   /* nulldev is empty! */
+}
+
+static void nulldev_puts(const char *s)
+{
+   /* nulldev is empty! */
+}
+
+static int nulldev_input(void)
+{
+   /* nulldev is empty! */
+   return 0;
+}
+
+struct serial_device nulldev_serial_device = {
+   "nulldev",
+   nulldev_init,
+   NULL,
+   nulldev_setbrg,
+   nulldev_input,
+   nulldev_input,
+   nulldev_putc,
+   nulldev_puts,
+};
+
+void nulldev_serial_initialize(void)
+{
+   serial_register(_serial_device);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+   return _serial_device;
+}
+
+#else /* CONFIG_DM_SERIAL */
+
+static int nulldev_serial_setbrg(struct udevice *dev, int baudrate)
+{
+   return 0;
+}
+
+static int nulldev_serial_getc(struct udevice *dev)
+{
+   return -EAGAIN;
+}
+
+static int nulldev_serial_input(struct udevice *dev)
+{
+   return 0;
+}
+
+static int nulldev_serial_putc(struct udevice *dev, const char ch)
+{
+   return 0;
+}
+
+static const struct udevice_id nulldev_serial_ids[] = {
+   { .compatible = "nulldev-serial" },
+   { }
+};
+
+
+const struct dm_serial_ops nulldev_serial_ops = {
+   .putc = nulldev_serial_putc,
+   .getc = nulldev_serial_getc,
+   .setbrg = nulldev_serial_setbrg,
+};
+
+U_BOOT_DRIVER(serial_nulldev) = {
+   .name   = "serial_nulldev",
+   .id = UCLASS_SERIAL,
+   .of_match = nulldev_serial_ids,
+   .ops= _serial_ops,
+};
+
+#endif /* CONFIG_DM_SERIAL */
diff --git a/include/serial.h b/include/serial.h
index f417196..087cabe 100644
--- 

[U-Boot] [PATCH] net: macb: Add support for Xilinx Zynq SoC

2017-08-23 Thread Wilson Lee
Although Xilinx Zynq SoC was using MACB similar hardware. However,
U-boot MACB driver was not supporting Xilinx Zynq SoC. This patch is
to add support for the Xilinx Zynq SoC to the existing MACB network
driver.

This patch is to add Zynq GEM DMA Config, provide callback
function for different linkspeed for case of using Xilinx Zynq
Programmable Logic as GMII to RGMII convertor.

This patch convert the return value to use error codes.

Signed-off-by: Wilson Lee 
Cc: Chen Yee Chew 
Cc: Keng Soon Cheah 
Cc: Joe Hershberger 
Cc: Wenyou Yang 
---

 drivers/net/Kconfig |  7 +
 drivers/net/macb.c  | 91 ++---
 drivers/net/macb.h  |  1 +
 3 files changed, 87 insertions(+), 12 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 5ceea44..6c54f93 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -177,6 +177,13 @@ config MACB
  GEM (Gigabit Ethernet MAC) found in some ARM SoC devices.
  Say Y to include support for the MACB/GEM chip.
 
+config MACB_ZYNQ
+   bool "Cadence MACB/GEM Ethernet Interface for Xilinx Zynq"
+   depends on MACB
+   help
+ The Cadence MACB ethernet interface was used on Zynq platform.
+ Say Y to enable support for the MACB/GEM in Zynq chip.
+
 config PCH_GBE
bool "Intel Platform Controller Hub EG20T GMAC driver"
depends on DM_ETH && DM_PCI
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index f9373db..e62aefc 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -52,6 +52,22 @@ DECLARE_GLOBAL_DATA_PTR;
 #define MACB_TX_TIMEOUT1000
 #define MACB_AUTONEG_TIMEOUT   500
 
+#ifdef CONFIG_MACB_ZYNQ
+/* INCR4 AHB bursts */
+#define MACB_ZYNQ_GEM_DMACR_BLENGTH0x0004
+/* Use full configured addressable space (8 Kb) */
+#define MACB_ZYNQ_GEM_DMACR_RXSIZE 0x0300
+/* Use full configured addressable space (4 Kb) */
+#define MACB_ZYNQ_GEM_DMACR_TXSIZE 0x0400
+/* Set RXBUF with use of 128 byte */
+#define MACB_ZYNQ_GEM_DMACR_RXBUF  0x0002
+#define MACB_ZYNQ_GEM_DMACR_INIT \
+   (MACB_ZYNQ_GEM_DMACR_BLENGTH | \
+   MACB_ZYNQ_GEM_DMACR_RXSIZE | \
+   MACB_ZYNQ_GEM_DMACR_TXSIZE | \
+   MACB_ZYNQ_GEM_DMACR_RXBUF)
+#endif
+
 struct macb_dma_desc {
u32 addr;
u32 ctrl;
@@ -461,13 +477,25 @@ static int macb_phy_find(struct macb_device *macb, const 
char *name)
phy_id = macb_mdio_read(macb, MII_PHYSID1);
if (phy_id != 0x) {
printf("%s: PHY present at %d\n", name, i);
-   return 1;
+   return 0;
}
}
 
/* PHY isn't up to snuff */
printf("%s: PHY not found\n", name);
 
+   return -ENODEV;
+}
+
+/**
+ * macb_linkspd_cb - Linkspeed change callback function
+ * @regs:  Base Register of MACB devices
+ * @speed: Linkspeed
+ * Returns 0 when operation success and negative errno number
+ * when operation failed.
+ */
+int __weak macb_linkspd_cb(void *regs, unsigned int speed)
+{
return 0;
 }
 
@@ -483,18 +511,20 @@ static int macb_phy_init(struct macb_device *macb, const 
char *name)
u32 ncfgr;
u16 phy_id, status, adv, lpa;
int media, speed, duplex;
+   int ret;
int i;
 
arch_get_mdio_control(name);
/* Auto-detect phy_addr */
-   if (!macb_phy_find(macb, name))
-   return 0;
+   ret = macb_phy_find(macb, name);
+   if (ret)
+   return ret;
 
/* Check if the PHY is up to snuff... */
phy_id = macb_mdio_read(macb, MII_PHYSID1);
if (phy_id == 0x) {
printf("%s: No PHY present\n", name);
-   return 0;
+   return -ENODEV;
}
 
 #ifdef CONFIG_PHYLIB
@@ -530,7 +560,7 @@ static int macb_phy_init(struct macb_device *macb, const 
char *name)
if (!(status & BMSR_LSTATUS)) {
printf("%s: link down (status: 0x%04x)\n",
   name, status);
-   return 0;
+   return -ENETDOWN;
}
 
/* First check for GMAC and that it is GiB capable */
@@ -554,7 +584,11 @@ static int macb_phy_init(struct macb_device *macb, const 
char *name)
 
macb_writel(macb, NCFGR, ncfgr);
 
-   return 1;
+   ret = macb_linkspd_cb(macb->regs, _1000BASET);
+   if (ret)
+   return ret;
+
+   return 0;
}
}
 
@@ -573,13 +607,21 @@ static int macb_phy_init(struct macb_device *macb, const 
char *name)
 
ncfgr = macb_readl(macb, NCFGR);

[U-Boot] rk3xxx.dtsi /usb_host missing specific compatible

2017-08-23 Thread Artturi Alm
Hi,


no idea if this is the right place to mail about this, but i got
suggested this node is out-of-norm, and the diff below fixes that
for me on rk3188.

-Artturi


diff --git a/arch/arm/dts/rk3xxx.dtsi b/arch/arm/dts/rk3xxx.dtsi
index 6d9e36d235..21f2afc104 100644
--- a/arch/arm/dts/rk3xxx.dtsi
+++ b/arch/arm/dts/rk3xxx.dtsi
@@ -157,7 +157,7 @@
};
 
usb_host: usb@101c {
-   compatible = "snps,dwc2";
+   compatible = "rockchip,rk3066-usb", "snps,dwc2";
reg = <0x101c 0x4>;
interrupts = ;
clocks = < HCLK_OTG1>;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/2] sunxi: Enable MMC new mode for A83T

2017-08-23 Thread Maxime Ripard
The eMMC controller for the A83T uses the new operating mode. Enable it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/mach-sunxi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 94412bac0c1d..8d56d591d97a 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -127,6 +127,7 @@ config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
select SUNXI_GEN_SUN6I
+   select MMC_SUNXI_HAS_NEW_MODE
select SUPPORT_SPL
 
 config MACH_SUN8I_H3
-- 
2.13.5

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


[U-Boot] [PATCH v2 1/2] mmc: sunxi: Support new mode

2017-08-23 Thread Maxime Ripard
Almost all of the newer Allwinner SoCs have a new operating mode for the
eMMC clocks that needs to be enabled in both the clock and the MMC
controller.

Details about that mode are sparse, and the name itself (new mode vs old
mode) doesn't give much details, but it seems that the it changes the
sampling of the MMC clock. One side effect is also that it divides the
parent clock rate by 2.

Add support for it through a Kconfig option.

Signed-off-by: Maxime Ripard 

---
Changes from v1:
  - Switched to IS_ENABLED when possible
  - Added some defines
  - Tried to put more details in the commit log
  - Added a depends on in the Kconfig option
---
 arch/arm/include/asm/arch-sunxi/clock_sun8i_a83t.h |  1 +
 arch/arm/include/asm/arch-sunxi/mmc.h  | 11 ++---
 drivers/mmc/Kconfig|  4 
 drivers/mmc/sunxi_mmc.c| 27 +++---
 4 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun8i_a83t.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun8i_a83t.h
index 5e1346e5242a..5dfcbf3b017b 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun8i_a83t.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun8i_a83t.h
@@ -220,6 +220,7 @@ struct sunxi_ccm_reg {
 #define CCM_MMC_CTRL_SCLK_DLY(x)   ((x) << 20)
 #define CCM_MMC_CTRL_OSCM24(0x0 << 24)
 #define CCM_MMC_CTRL_PLL6  (0x1 << 24)
+#define CCM_MMC_CTRL_MODE_SEL_NEW  (0x1 << 30)
 #define CCM_MMC_CTRL_ENABLE(0x1 << 31)
 
 #define CCM_USB_CTRL_PHY0_RST (0x1 << 0)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h 
b/arch/arm/include/asm/arch-sunxi/mmc.h
index cb52e648731c..69f737f3bffc 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -35,16 +35,19 @@ struct sunxi_mmc {
u32 cbcr;   /* 0x48 CIU byte count */
u32 bbcr;   /* 0x4c BIU byte count */
u32 dbgc;   /* 0x50 debug enable */
-   u32 res0[11];
+   u32 res0;   /* 0x54 reserved */
+   u32 a12a;   /* 0x58 Auto command 12 argument */
+   u32 ntsr;   /* 0x5c New timing set register */
+   u32 res1[8];
u32 dmac;   /* 0x80 internal DMA control */
u32 dlba;   /* 0x84 internal DMA descr list base address */
u32 idst;   /* 0x88 internal DMA status */
u32 idie;   /* 0x8c internal DMA interrupt enable */
u32 chda;   /* 0x90 */
u32 cbda;   /* 0x94 */
-   u32 res1[26];
+   u32 res2[26];
 #ifdef CONFIG_SUNXI_GEN_SUN6I
-   u32 res2[64];
+   u32 res3[64];
 #endif
u32 fifo;   /* 0x100 / 0x200 FIFO access address */
 };
@@ -116,6 +119,8 @@ struct sunxi_mmc {
 #define SUNXI_MMC_STATUS_CARD_DATA_BUSY(0x1 << 9)
 #define SUNXI_MMC_STATUS_DATA_FSM_BUSY (0x1 << 10)
 
+#define SUNXI_MMC_NTSR_MODE_SEL_NEW(0x1 << 31)
+
 #define SUNXI_MMC_IDMAC_RESET  (0x1 << 0)
 #define SUNXI_MMC_IDMAC_FIXBURST   (0x1 << 1)
 #define SUNXI_MMC_IDMAC_ENABLE (0x1 << 7)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 51a87cdd77dc..9075b346036b 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -389,6 +389,10 @@ config MMC_SUNXI
  This selects support for the SD/MMC Host Controller on
  Allwinner sunxi SoCs.
 
+config MMC_SUNXI_HAS_NEW_MODE
+   bool
+   depends on MMC_SUNXI
+
 config GENERIC_ATMEL_MCI
bool "Atmel Multimedia Card Interface support"
depends on DM_MMC && BLK && DM_MMC_OPS && ARCH_AT91
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 588574fab6a9..bc638ae2e64a 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -96,6 +96,18 @@ static int mmc_resource_init(int sdc_no)
 static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
 {
unsigned int pll, pll_hz, div, n, oclk_dly, sclk_dly;
+   bool new_mode = false;
+   u32 val = 0;
+
+   if (IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE) && (priv->mmc_no == 2))
+   new_mode = true;
+
+   /*
+* The MMC clock has an extra /2 post-divider when operating in the new
+* mode.
+*/
+   if (new_mode)
+   hz = hz * 2;
 
if (hz <= 2400) {
pll = CCM_MMC_CTRL_OSCM24;
@@ -152,9 +164,18 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
unsigned int hz)
 #endif
}
 
-   writel(CCM_MMC_CTRL_ENABLE | pll | CCM_MMC_CTRL_SCLK_DLY(sclk_dly) |
-  CCM_MMC_CTRL_N(n) | CCM_MMC_CTRL_OCLK_DLY(oclk_dly) |
-  CCM_MMC_CTRL_M(div), priv->mclkreg);
+   if (new_mode) {
+#ifdef CONFIG_MMC_SUNXI_HAS_NEW_MODE
+   val = CCM_MMC_CTRL_MODE_SEL_NEW;
+   writel(SUNXI_MMC_NTSR_MODE_SEL_NEW, 

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

2017-08-23 Thread Peng Fan
Ping.. It's two weeks since sent out for review.

Thanks,
Peng.

On Wed, Aug 09, 2017 at 01:09:33PM +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/mx6qsabresd board.
>
>Signed-off-by: Peng Fan 
>Cc: Jagan Teki 
>cc: Stefano Babic 
>---
>
>V2:
> return -ENODEV when dev_get_addr not return a valid value.
> Pass error value from dm_gpio_set_value to caller, if error happends.
>
> drivers/spi/mxc_spi.c | 181 +-
> 1 file changed, 149 insertions(+), 32 deletions(-)
>
>diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
>index e1562c3..41f0cfc 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;
>@@ -51,6 +50,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 +58,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 +216,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 +331,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 +342,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 +356,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 +368,39 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
>bitlen, const void *dout,
>   }
> 
>   if (flags & SPI_XFER_END) {
>-  spi_cs_deactivate(slave);
>+  mxc_spi_cs_deactivate(mxcs);
>   }
> 
>   return 0;
> }

Re: [U-Boot] [PATCH 2/2] pinctrl: imx7ulp: Add new info instance for iomuxc1

2017-08-23 Thread Stefano Babic
On 14/08/2017 12:09, Peng Fan wrote:
> To i.MX7ULP, we need to create two info instances for
> iomux0 and iomux1 respectively, otherwise iomuxc0/1 will
> share one info instance and use one base, because imx_pinctrl_probe
> will use info to store base address and etc. But iomuxc0/1
> actually have different base address.
> 
> Signed-off-by: Peng Fan 
> Cc: Simon Glass 
> Cc: Stefano Babic 
> ---
>  drivers/pinctrl/nxp/pinctrl-imx7ulp.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pinctrl/nxp/pinctrl-imx7ulp.c 
> b/drivers/pinctrl/nxp/pinctrl-imx7ulp.c
> index 4a893e5..618ce6a 100644
> --- a/drivers/pinctrl/nxp/pinctrl-imx7ulp.c
> +++ b/drivers/pinctrl/nxp/pinctrl-imx7ulp.c
> @@ -12,7 +12,11 @@
>  
>  #include "pinctrl-imx.h"
>  
> -static struct imx_pinctrl_soc_info imx7ulp_pinctrl_soc_info = {
> +static struct imx_pinctrl_soc_info imx7ulp_pinctrl_soc_info0 = {
> + .flags = ZERO_OFFSET_VALID | SHARE_MUX_CONF_REG | CONFIG_IBE_OBE,
> +};
> +
> +static struct imx_pinctrl_soc_info imx7ulp_pinctrl_soc_info1 = {
>   .flags = ZERO_OFFSET_VALID | SHARE_MUX_CONF_REG | CONFIG_IBE_OBE,
>  };
>  
> @@ -25,8 +29,8 @@ static int imx7ulp_pinctrl_probe(struct udevice *dev)
>  }
>  
>  static const struct udevice_id imx7ulp_pinctrl_match[] = {
> - { .compatible = "fsl,imx7ulp-iomuxc-0", .data = 
> (ulong)_pinctrl_soc_info },
> - { .compatible = "fsl,imx7ulp-iomuxc-1", .data = 
> (ulong)_pinctrl_soc_info },
> + { .compatible = "fsl,imx7ulp-iomuxc-0", .data = 
> (ulong)_pinctrl_soc_info0 },
> + { .compatible = "fsl,imx7ulp-iomuxc-1", .data = 
> (ulong)_pinctrl_soc_info1 },
>   { /* sentinel */ }
>  };
>  
> 
Applied to u-boot-imx, -master, 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/2] pinctrl: imx: Fix mask when SHARE_MUX_CONF_REG is set

2017-08-23 Thread Stefano Babic
On 14/08/2017 12:09, Peng Fan wrote:
> when using SHARE_MUX_CONF_REG, wrong mask is used for
> writing config value, which causes mux value is cleared.
> 
> Signed-off-by: Peng Fan 
> Cc: Simon Glass 
> Cc: Stefano Babic 
> ---
>  drivers/pinctrl/nxp/pinctrl-imx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/nxp/pinctrl-imx.c 
> b/drivers/pinctrl/nxp/pinctrl-imx.c
> index 1b6107f..32cbac9 100644
> --- a/drivers/pinctrl/nxp/pinctrl-imx.c
> +++ b/drivers/pinctrl/nxp/pinctrl-imx.c
> @@ -158,7 +158,7 @@ static int imx_pinctrl_set_state(struct udevice *dev, 
> struct udevice *config)
>   if (!(config_val & IMX_NO_PAD_CTL)) {
>   if (info->flags & SHARE_MUX_CONF_REG) {
>   clrsetbits_le32(info->base + conf_reg,
> - info->mux_mask, config_val);
> + ~info->mux_mask, config_val);
>   } else {
>   writel(config_val, info->base + conf_reg);
>   }
> 

Applied to u-boot-imx, -master, 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 v2 0/8] imx: add USB Serial Download Protocol (SDP) support

2017-08-23 Thread Stefano Babic
Hi Stefan,

On 16/08/2017 20:00, Stefan Agner wrote:
> From: Stefan Agner 
> 
> This series adds NXP's Serial Download Protocol (SDP) support via
> USB for SPL/U-Boot. It allows to download U-Boot via USB from a
> (recovered) SPL using the same tools used to download SPL itself
> (specifically imx_usb, but also sb_loader seems to work).
> 
> The idea has been brought up when the first targets started to make
> use of SPL for DDR initialization, see:
> https://lists.denx.de/pipermail/u-boot/2015-July/220330.html
> 
> The initial SDP implementation (patch 2) requires the payload to
> have the imx specific headers (hence the move of the imx header
> file in patch 1).
> 
> Patch 3 extends image header support beyond the SDP specification,
> specifically implements also support for U-Boot headers. This
> allows to use the same SPL/U-Boot binaries for recovery as used on
> the regular boot device (SD/eMMC). For that to work also the host
> side imx_usb tools needed an extension, currently available here:
> 
> https://github.com/toradex/imx_loader/tree/imx_usb_batch_mode_refactored
> 
> (in case this patchset gets accepted in U-Boot, I plan to push
> these imx_usb changes upstream as well)
> 
> The full patchset allows to download SPL and U-Boot over USB to a
> target in recovery mode using the same usb_imx utility. Refer to
> the new README.sdp for details how to use usb_imx in combination
> with this implementation.
> 
> Changes in v2:
> - Changed function signature of sdp_init/sdp_handle to allow specifying
>   which USB controller should be used.
> - Use #defines for security mode
> - Improved types used in format strings
> - Changed function signature of sdp_init/sdp_handle
> - Use BOOT_DEVICE_BOARD
> 
> Stefan Agner (8):
>   imx: move imximage header to common location
>   usb: gadget: add SDP driver
>   usb: gadget: sdp: extend images compatible for jumps
>   cmd: add sdp command
>   spl: add serial download protocol (SDP) support
>   doc: add Serial Download Protocol documentation
>   apalis/colibri_imx6: use independent USB PID for SPL
>   apalis/colibri_imx6: enable SDP by default
> 

I have merged the whole series to u-boot-imx. Many thanks for your
effort, this was in the TODO list for i.MX since a long time !

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


[U-Boot] Please pull from u-boot-i2c

2017-08-23 Thread Heiko Schocher

Hello Tom,

please pull from u-boot-i2c master

The following changes since commit 90ae53ce1ae665a1b43ecf5ccafc339839392427:

  fastboot: Ensure we treat CONFIG_FASTBOOT_BUF_ADDR as long (2017-08-22 
08:20:02 -0400)

are available in the git repository at:

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

for you to fetch changes up to a430556ecb630d26880b34b914b6ec29f5454d01:

  i2c: muxes: add i2c gpio multiplexer driver (2017-08-23 07:04:56 +0200)


Patrice Chotard (1):
  i2c: add i2c driver for stm32

Peng Fan (1):
  i2c: muxes: add i2c gpio multiplexer driver

 doc/device-tree-bindings/i2c/i2c-stm32.txt |  30 +
 drivers/i2c/Kconfig|  20 +++
 drivers/i2c/Makefile   |   1 +
 drivers/i2c/muxes/Kconfig  |   9 ++
 drivers/i2c/muxes/Makefile |   1 +
 drivers/i2c/muxes/i2c-mux-gpio.c   | 138 
 drivers/i2c/stm32f7_i2c.c  | 882 
+

 7 files changed, 1081 insertions(+)
 create mode 100644 doc/device-tree-bindings/i2c/i2c-stm32.txt
 create mode 100644 drivers/i2c/muxes/i2c-mux-gpio.c
 create mode 100644 drivers/i2c/stm32f7_i2c.c

travis builds fine
https://travis-ci.org/hsdenx/u-boot-i2c/builds/267451392

also my weekly u-boot tbot builds show no errors.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] i2c: muxes: add i2c gpio multiplexer driver

2017-08-23 Thread Heiko Schocher

Hello Peng Fan,

Am 14.08.2017 um 12:00 schrieb Peng Fan:

Add an i2c mux driver providing access to i2c bus segments using a
hardware MUX sitting on a master bus and controlled through gpio pins.

E.G. something like:

  --  --  Bus segment 1   - - - - -
 |  | SCL/SDA|  |-- |   |
 |  ||  |
 |  ||  | Bus segment 2 |   |
 |  Linux   | GPIO 1..N  |   MUX|---   Devices
 |  ||  |   |   |
 |  ||  | Bus segment M
 |  ||  |---|   |
  --  --  - - - - -

SCL/SDA of the master I2C bus is multiplexed to bus segment 1..M
according to the settings of the GPIO pins 1..N.

Note commit log from kernel
commit 92ed1a76("i2c: Add generic I2C multiplexer using GPIO API")

Signed-off-by: Peng Fan 
Tested-by: Peng Fan  (i.MX6QP-Sabreauto)
Cc: Heiko Schocher 
Cc: Stefano Babic 
Cc: Simon Glass 
---
  drivers/i2c/muxes/Kconfig|   9 +++
  drivers/i2c/muxes/Makefile   |   1 +
  drivers/i2c/muxes/i2c-mux-gpio.c | 138 +++
  3 files changed, 148 insertions(+)
  create mode 100644 drivers/i2c/muxes/i2c-mux-gpio.c


Applied to u-boot-i2c master

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/1] i2c: add i2c driver for stm32

2017-08-23 Thread Heiko Schocher

Hello Partrice,

Am 09.08.2017 um 14:45 schrieb patrice.chot...@st.com:

From: Patrice Chotard 

Add i2c driver which can be used on both STM32F7 and STM32H7.
This I2C block supports the following features:
  _ Slave and master modes
  _ Multimaster capability
  _ Standard-mode (up to 100 kHz)
  _ Fast-mode (up to 400 kHz)
  _ Fast-mode Plus (up to 1 MHz)
  _ 7-bit and 10-bit addressing mode
  _ Multiple 7-bit slave addresses (2 addresses, 1 with configurable mask)
  _ All 7-bit addresses acknowledge mode
  _ General call
  _ Programmable setup and hold times
  _ Easy to use event management
  _ Optional clock stretching
  _ Software reset

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrice Chotard 
---

v2: _ add I2C controller description in Kconfig
_ rename stm32_i2c_dev struct to stm32_i2c_priv
_ add comment for stm32_i2c_handle_reload()
_ split stm32_i2c_compute_timing() code and add :
_ stm32_i2c_compute_solutions() which computes list of possible 
timings candidate
_ stm32_i2c_choose_solution() which selects the best timing
_ use #defines instead of hard coded vlaue for speed in
  stm32_i2c_set_bus_speed() and in i2c_specs[] array
_ move part of code of stm32_i2c_probe() inside 
stm32_ofdata_to_platdata()

  doc/device-tree-bindings/i2c/i2c-stm32.txt |  30 +
  drivers/i2c/Kconfig|  20 +
  drivers/i2c/Makefile   |   1 +
  drivers/i2c/stm32f7_i2c.c  | 882 +
  4 files changed, 933 insertions(+)
  create mode 100644 doc/device-tree-bindings/i2c/i2c-stm32.txt
  create mode 100644 drivers/i2c/stm32f7_i2c.c


Applied to u-boot-i2c.git master

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] LVDS dual channel support on A10,A20,A31s mods.

2017-08-23 Thread far5893

Hi,
i make a little changes to
lcdc.h and sunxi_diplay.h to make dual channel LVDS interface working :

-lcdc.h

#define SUNXI_LCDC_TCON0_LVDS_INTF_CH(n)    ((n) << 30) /* LVDS Dual channel 
0=single 1=dual*/

and in

-sunxi_diplay.h (line 830).

#ifdef CONFIG_VIDEO_LCD_IF_LVDS
    if (mode->yres <= 768) ch=0; /*Single channel*/
    if ((mode->yres <= 800) & (sunxi_display.depth == 18)) ch=0; /*Single 
channel*/
    if ((mode->yres > 768) & (sunxi_display.depth == 24)) ch=1; /*Dual channel*/

    if(ch) printf ("Dual Channel Mode\n");
    else   printf ("Single Channel Mode\n");


    writel(SUNXI_LCDC_TCON0_LVDS_INTF_BITWIDTH(val) |
       SUNXI_LCDC_TCON0_LVDS_CLK_SEL_TCON0 |
   SUNXI_LCDC_TCON0_LVDS_INTF_CH(ch), >tcon0_lvds_intf);
#endif

there are another patch from plaes sended but nothing happen.

https://lists.denx.de/pipermail/u-boot/2017-March/284805.html

These mods are  tested  on cubieboard1 and 2 , banana pi M2 (A31s) and dual 
channel lcd  displays
i'm not a software developer so patching tree and submit is out from my 
knowledge


Thank
Miky




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


Re: [U-Boot] [PATCH v2 2/2] driver: spi: add rockchip sfc support

2017-08-23 Thread Andy Yan

ping


On 2017年08月08日 09:43, Andy Yan wrote:

SFC stands for Serial Flash Controller on some
rockchip platforms such as RV1108/RK3128.

This patch add support for it with Standard,Dual,Quad
mode.

Signed-off-by: Andy Yan 

---

Changes in v2:
- fix the wrong reference in Makefile, which should be rockchip_sfc.o
   not rk_sfc.o

  drivers/spi/Kconfig|   8 +
  drivers/spi/Makefile   |   1 +
  drivers/spi/rockchip_sfc.c | 402 +
  drivers/spi/rockchip_sfc.h |  82 +
  4 files changed, 493 insertions(+)
  create mode 100644 drivers/spi/rockchip_sfc.c
  create mode 100644 drivers/spi/rockchip_sfc.h

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 8a8e8e4..52c4993 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -99,6 +99,14 @@ config ROCKCHIP_SPI
  This uses driver model and requires a device tree binding to
  operate.
  
+config ROCKCHIP_SFC

+   bool "Rockchip SFC driver"
+   help
+ Enable the Rockchip SFC driver, used to access SPI NOR flash
+ on Rockchip SoCs.
+ This uses driver model and requires a device tree binding to
+ operate.
+
  config SANDBOX_SPI
bool "Sandbox SPI driver"
depends on SANDBOX && DM
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 9f8b86d..052c608 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_MXS_SPI) += mxs_spi.o
  obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o
  obj-$(CONFIG_PIC32_SPI) += pic32_spi.o
  obj-$(CONFIG_ROCKCHIP_SPI) += rk_spi.o
+obj-$(CONFIG_ROCKCHIP_SFC) += rockchip_sfc.o
  obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
  obj-$(CONFIG_SH_SPI) += sh_spi.o
  obj-$(CONFIG_SH_QSPI) += sh_qspi.o
diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c
new file mode 100644
index 000..4388e51
--- /dev/null
+++ b/drivers/spi/rockchip_sfc.c
@@ -0,0 +1,402 @@
+/*
+ * sfc driver for rockchip
+ *
+ * (C) Copyright 2008-2016 Rockchip Electronics
+ * Yifeng.zhao, Software Engineering, .
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rockchip_sfc.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+enum rockchip_sfc_if_type {
+   IF_TYPE_STD,
+   IF_TYPE_DUAL,
+   IF_TYPE_QUAD,
+};
+
+struct rockchip_sfc_platdata {
+   s32 frequency;
+   fdt_addr_t base;
+};
+
+struct rockchip_sfc {
+   struct rockchip_sfc_reg *regbase;
+   struct clk clk;
+   unsigned int max_freq;
+   unsigned int mode;
+   unsigned int speed_hz;
+   u32 cmd;
+   u32 addr;
+};
+
+static int rockchip_sfc_ofdata_to_platdata(struct udevice *bus)
+{
+   struct rockchip_sfc_platdata *plat = dev_get_platdata(bus);
+   struct rockchip_sfc *sfc = dev_get_priv(bus);
+   const void *blob = gd->fdt_blob;
+   int node = dev_of_offset(bus);
+   int subnode;
+   int ret;
+
+   plat->base = devfdt_get_addr(bus);
+
+   ret = clk_get_by_index(bus, 0, >clk);
+   if (ret < 0) {
+   debug("Could not get clock for %s: %d\n", bus->name, ret);
+   return ret;
+   }
+
+   subnode = fdt_first_subnode(blob, node);
+   if (subnode < 0) {
+   debug("Error: subnode with SPI flash config missing!\n");
+   return -ENODEV;
+   }
+
+   plat->frequency = fdtdec_get_int(blob, subnode, "spi-max-frequency",
+1);
+
+   return 0;
+}
+
+static int rockchip_sfc_probe(struct udevice *bus)
+{
+   struct rockchip_sfc_platdata *plat = dev_get_platdata(bus);
+   struct rockchip_sfc *sfc = dev_get_priv(bus);
+   int ret;
+
+   sfc->regbase = (struct rockchip_sfc_reg *)plat->base;
+
+   sfc->max_freq = plat->frequency;
+
+   ret = clk_set_rate(>clk, sfc->max_freq);
+   if (ret < 0) {
+   debug("%s: Failed to set clock: %d\n", __func__, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int rockchip_sfc_reset(struct rockchip_sfc *sfc)
+{
+   struct rockchip_sfc_reg *regs = sfc->regbase;
+   int tbase = get_timer(0);
+   u32 rcvr;
+   int ret = 0;
+
+   writel(SFC_RESET, >rcvr);
+   do {
+   rcvr = readl(>rcvr);
+   if (get_timer(tbase) > 1000) {
+   debug("sfc reset timeout\n");
+   ret =  -ETIMEDOUT;
+   break;
+   }
+   udelay(1);
+   } while (rcvr);
+
+   writel(0x, >iclr);
+
+   debug("sfc reset\n");
+
+   return ret;
+}
+
+static u8 rockchip_sfc_get_if_type(struct rockchip_sfc *sfc)
+{
+   int type = IF_TYPE_STD;
+
+   if (sfc->cmd & SFC_WR) {
+   if (sfc->mode & SPI_TX_QUAD)
+   type = IF_TYPE_QUAD;
+   

Re: [U-Boot] [PATCH 0/2] board: ti: am57xx: Add DT support for BeagleBoard-X15 revC

2017-08-23 Thread Łukasz Majewski

On 08/23/2017 08:09 AM, Lokesh Vutla wrote:

Now that we have synced DTS from Latest Linux kernel, add dt support
for BeagleBoard-X15 revC. Board detection support is already added for
this board.

Lokesh Vutla (2):
  board: ti: am57xx: Add dt support for BeagleBoard-X15 revC
  env: ti: boot: Select dtb name for X15 revC

 arch/arm/dts/Makefile   | 1 +
 board/ti/am57xx/board.c | 3 +++
 configs/am57xx_evm_defconfig| 2 +-
 configs/am57xx_hs_evm_defconfig | 2 +-
 include/environment/ti/boot.h   | 2 ++
 5 files changed, 8 insertions(+), 2 deletions(-)



Reviewed-by: Łukasz Majewski 

--
Best regards,

Lukasz Majewski

--

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


[U-Boot] [PATCH] rockchip: clk: rk3368: always run rkclk_init when driver probe

2017-08-23 Thread Andy Yan
commit 4bebf94e8544("rockchip: clk: rk3368: do not change
CPLL/GPLL before returning to BROM") limits the pll can only
be setup in SPL stage, but there are still some rk3368 based
boards have not use SPL yet, so they need run rkclk_init to
setup the pll in full u-boot stage, otherwise the clk_set_rate
function will run into wrong logic, because it assume that all
the pll have been set to the desired frequency.

Signed-off-by: Andy Yan 
---

 drivers/clk/rockchip/clk_rk3368.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index 2be1f57..ee754f0 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -47,14 +47,12 @@ struct pll_div {
   (_nr * _no) == hz, #hz "Hz cannot be hit with PLL " \
   "divisors on line " __stringify(__LINE__));
 
-#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
 static const struct pll_div apll_l_init_cfg = PLL_DIVISORS(APLL_L_HZ, 12, 2);
 static const struct pll_div apll_b_init_cfg = PLL_DIVISORS(APLL_B_HZ, 1, 2);
 #if !defined(CONFIG_TPL_BUILD)
 static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 1, 2);
 static const struct pll_div cpll_init_cfg = PLL_DIVISORS(CPLL_HZ, 1, 6);
 #endif
-#endif
 
 static ulong rk3368_clk_get_rate(struct clk *clk);
 
@@ -85,7 +83,6 @@ static uint32_t rkclk_pll_get_rate(struct rk3368_cru *cru,
}
 }
 
-#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
 static int rkclk_set_pll(struct rk3368_cru *cru, enum rk3368_pll_id pll_id,
 const struct pll_div *div)
 {
@@ -125,9 +122,7 @@ static int rkclk_set_pll(struct rk3368_cru *cru, enum 
rk3368_pll_id pll_id,
 
return 0;
 }
-#endif
 
-#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
 static void rkclk_init(struct rk3368_cru *cru)
 {
u32 apllb, aplll, dpll, cpll, gpll;
@@ -152,7 +147,7 @@ static void rkclk_init(struct rk3368_cru *cru)
debug("%s apllb(%d) apll(%d) dpll(%d) cpll(%d) gpll(%d)\n",
   __func__, apllb, aplll, dpll, cpll, gpll);
 }
-#endif
+
 
 #if !IS_ENABLED(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(MMC_SUPPORT)
 static ulong rk3368_mmc_get_clk(struct rk3368_cru *cru, uint clk_id)
@@ -473,9 +468,8 @@ static int rk3368_clk_probe(struct udevice *dev)
 
priv->cru = map_sysmem(plat->dtd.reg[1], plat->dtd.reg[3]);
 #endif
-#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
+
rkclk_init(priv->cru);
-#endif
 
return 0;
 }
-- 
2.7.4


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


Re: [U-Boot] [PATCH] spi: fsl_qspi: Add controller busy check before new spi operation

2017-08-23 Thread Suresh Gupta


> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, August 23, 2017 10:57 AM
> To: Suresh Gupta 
> Cc: u-boot@lists.denx.de; Jagan Teki 
> Subject: Re: [U-Boot] [PATCH] spi: fsl_qspi: Add controller busy check before
> new spi operation
> 
> On Tue, Aug 22, 2017 at 4:19 PM, Suresh Gupta 
> wrote:
> > Thanks  Jagan for reviewing the code.
> > Please find comments in line
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> Sent: Monday, August 21, 2017 7:53 PM
> >> To: Suresh Gupta 
> >> Cc: u-boot@lists.denx.de; Jagan Teki 
> >> Subject: Re: [U-Boot] [PATCH] spi: fsl_qspi: Add controller busy
> >> check before new spi operation
> >>
> >> On Mon, Aug 21, 2017 at 3:56 PM, Suresh Gupta 
> >> wrote:
> >> > It is recommended to check either controller is free to take new
> >> > spi action. The IP_ACC and AHB_ACC bits indicates that the
> >> > controller is busy in IP or AHB mode respectively.
> >> > And the BUSY bit indicates that the controller is currently busy
> >> > handling a transaction to an external flash device
> >> >
> >> > Signed-off-by: Suresh Gupta 
> >> > ---
> >> >  drivers/spi/fsl_qspi.c | 26 ++
> >> > drivers/spi/fsl_qspi.h |  4 
> >> >  2 files changed, 30 insertions(+)
> >> >
> >> > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
> >> > 1dfa89a..69e9712 100644
> >> > --- a/drivers/spi/fsl_qspi.c
> >> > +++ b/drivers/spi/fsl_qspi.c
> >> > @@ -165,6 +165,27 @@ static inline u32 qspi_endian_xchg(u32 data)
> >> > #endif  }
> >> >
> >> > +static inline u32 qspi_controller_busy(struct fsl_qspi_priv *priv) {
> >> > +   u32 sr;
> >> > +   u32 retry = 5;
> >> > +
> >> > +   do {
> >> > +   sr = qspi_read32(priv->flags, >regs->sr);
> >> > +   if ((sr & QSPI_SR_BUSY_MASK) ||
> >>
> >> Does this bit need? we can check the busy-state with AHB_ACC and
> >> IP_ACC
> >
> > The definition of the three bits is
> > Bit2 - AHB_ACC: AHB Access: Asserted when the transaction currently
> executed was initiated by AHB bus.
> > Bit1 - IP_ACC: IP Access: Asserted when transaction currently executed was
> initiated by IP bus.
> > Bit0 - BUSY: Module Busy: Asserted when module is currently busy handling a
> transaction to an external flash device.
> >
> > Also, the below are statements mentioned in the IP Block Guide For AHB
> > Access: Since the read access is triggered via the AHB bus, the
> QSPI_SR[AHB_ACC]
> > status bit is set driving in turn the QSPI_SR[BUSY] bit 
> > until the
> transaction is finished.
> > For IP Access: Since the read access is triggered by an IP command the 
> > IP_ACC
> status bit and
> > the BUSY bit are both set (both are located in the Status 
> > Register
> (QSPI_SR) ).
> >
> > So, BUSY flag is set when the controller is busy in communication with FLASH
> and this is true for both IP and AHB mode.
> > That’s the reason checking all three status bits ensures us that controller 
> > is
> free.
> >
> >>
> >> > +   (sr & QSPI_SR_AHB_ACC_MASK) ||
> >> > +   (sr & QSPI_SR_IP_ACC_MASK)) {
> >> > +   debug("The controller is busy, sr = 0x%x\n", sr);
> >> > +   udelay(1);
> >> > +   } else {
> >> > +   break;
> >> > +   }
> >> > +   } while (--retry);
> >>
> >> These retry and infine loop doesn't seems OK, how about using wait_for_bit?
> > Ok, I will use below and send a new patch
> >
> > ret = wait_for_bit(__func__, regs->sr,
> >   QSPI_SR_BUSY_MASK |
> >   QSPI_SR_AHB_ACC_MASK |
> >   QSPI_SR_IP_ACC_MASK,
> >   false, 1000, false);
> >>
> >> > +
> >> > +   return (sr & QSPI_SR_BUSY_MASK) ||
> >> > +   (sr & QSPI_SR_AHB_ACC_MASK) || (sr &
> >> > + QSPI_SR_IP_ACC_MASK);
> >>
> >> I didn't understand why these bits need to return?
> > After wait_for_bit, this is not required
> >
> >> and when will the LUT trigger?
> > The check is added as it is recommended that before any new transaction,
> these bits should be 0 i.e. controller is not busy.
> > This check is required before all new types of transaction with FLASH.
> > So I added this in qspi_xfer() which intern calls actual hardware 
> > operations like
> qspi_op_write, qspi_op_erase, qspi_ahb_read, qspi_op_rdsr etc., which triggers
> the LUT.
> 
> What about moving this in claim_bus?, because xfer will call each transfer 
> with
> each transaction.and of course while probe or each operation claim_bus is
> initiating.
> 
I will check and let you know tomorrow. 


> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream
> 

[U-Boot] [PATCH 2/2] env: ti: boot: Select dtb name for X15 revC

2017-08-23 Thread Lokesh Vutla
Select dtb name for am57xx BeagleBoard-X15 revC

Signed-off-by: Lokesh Vutla 
---
 include/environment/ti/boot.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h
index 01f7f7a300..dabfb37204 100644
--- a/include/environment/ti/boot.h
+++ b/include/environment/ti/boot.h
@@ -50,6 +50,8 @@
"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
"if test $board_name = beagle_x15_revb1; then " \
"setenv fdtfile am57xx-beagle-x15-revb1.dtb; fi;" \
+   "if test $board_name = beagle_x15_revc; then " \
+   "setenv fdtfile am57xx-beagle-x15-revc.dtb; fi;" \
"if test $board_name = am572x_idk; then " \
"setenv fdtfile am572x-idk.dtb; fi;" \
"if test $board_name = am57xx_evm; then " \
-- 
2.13.0

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


[U-Boot] [PATCH 0/2] board: ti: am57xx: Add DT support for BeagleBoard-X15 revC

2017-08-23 Thread Lokesh Vutla
Now that we have synced DTS from Latest Linux kernel, add dt support
for BeagleBoard-X15 revC. Board detection support is already added for
this board.

Lokesh Vutla (2):
  board: ti: am57xx: Add dt support for BeagleBoard-X15 revC
  env: ti: boot: Select dtb name for X15 revC

 arch/arm/dts/Makefile   | 1 +
 board/ti/am57xx/board.c | 3 +++
 configs/am57xx_evm_defconfig| 2 +-
 configs/am57xx_hs_evm_defconfig | 2 +-
 include/environment/ti/boot.h   | 2 ++
 5 files changed, 8 insertions(+), 2 deletions(-)

-- 
2.13.0

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


[U-Boot] [PATCH 1/2] board: ti: am57xx: Add dt support for BeagleBoard-X15 revC

2017-08-23 Thread Lokesh Vutla
Add support for selecting proper dtb for
am57xx BeagleBoard X15 revC u-boot from FIT

Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/Makefile   | 1 +
 board/ti/am57xx/board.c | 3 +++
 configs/am57xx_evm_defconfig| 2 +-
 configs/am57xx_hs_evm_defconfig | 2 +-
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f1dbdce9be..174c1c3f11 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -178,6 +178,7 @@ dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb 
dra7-evm.dtb   \
dra72-evm-revc.dtb dra71-evm.dtb dra76-evm.dtb
 dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb \
am57xx-beagle-x15-revb1.dtb \
+   am57xx-beagle-x15-revc.dtb \
am572x-idk.dtb  \
am571x-idk.dtb
 dtb-$(CONFIG_TARGET_STV0991) += stv0991.dtb
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 3d15cb1dbf..f79aefd400 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -1063,6 +1063,9 @@ int board_fit_config_name_match(const char *name)
if (board_is_x15_revb1()) {
if (!strcmp(name, "am57xx-beagle-x15-revb1"))
return 0;
+   } else if (board_is_x15_revc()) {
+   if (!strcmp(name, "am57xx-beagle-x15-revc"))
+   return 0;
} else if (!strcmp(name, "am57xx-beagle-x15")) {
return 0;
}
diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index 11be1ad27f..f3fcda7b61 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -40,7 +40,7 @@ CONFIG_CMD_SPL=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1 am572x-idk 
am571x-idk"
+CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1 
am57xx-beagle-x15-revc am572x-idk am571x-idk"
 CONFIG_DM=y
 CONFIG_SPL_DM=y
 # CONFIG_BLK is not set
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index 91baa2b53e..d322c37326 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -43,7 +43,7 @@ CONFIG_FASTBOOT_FLASH_MMC_DEV=1
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1 am572x-idk 
am571x-idk"
+CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1 
am57xx-beagle-x15-revc am572x-idk am571x-idk"
 CONFIG_DM=y
 CONFIG_SPL_DM=y
 # CONFIG_BLK is not set
-- 
2.13.0

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