[U-Boot] [PATCH 3/3] arm64: layerscape: Move CONFIG_HAS_FSL_DR_USB to Kconfig

[Ran Wang]

Rename to USB_EHCI_FSL, use Kconfig to select ehci accordingly.

Signed-off-by: Ran Wang 
---
 drivers/usb/host/Kconfig |  6 ++
 include/configs/ls1012aqds.h | 11 ---
 include/configs/ls1021aqds.h | 11 ---
 include/configs/ls1021atwr.h | 20 
 4 files changed, 6 insertions(+), 42 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index c79f866..90b2f78 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -186,6 +186,12 @@ config USB_EHCI_GENERIC
---help---
  Enables support for generic EHCI controller.
 
+config USB_EHCI_FSL
+   bool  "Support for FSL on-chip EHCI USB controller"
+   default n
+   select  CONFIG_EHCI_HCD_INIT_AFTER_RESET
+   ---help---
+ Enables support for the on-chip EHCI controller on FSL chips.
 endif # USB_EHCI_HCD
 
 config USB_OHCI_HCD
diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
index af5f37c..bf4262a 100644
--- a/include/configs/ls1012aqds.h
+++ b/include/configs/ls1012aqds.h
@@ -107,17 +107,6 @@
 #define CONFIG_SF_DEFAULT_BUS1
 #define CONFIG_SF_DEFAULT_CS 0
 
-/*
-* USB
-*/
-/* EHCI Support - disbaled by default */
-/*#define CONFIG_HAS_FSL_DR_USB*/
-
-#ifdef CONFIG_HAS_FSL_DR_USB
-#define CONFIG_USB_EHCI_FSL
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#endif
-
 /*  MMC  */
 #ifdef CONFIG_MMC
 #define CONFIG_FSL_ESDHC
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 6669f2f..d088e83 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -394,17 +394,6 @@ unsigned long get_board_ddr_clk(void);
 #endif
 
 /*
- * USB
- */
-/* EHCI Support - disbaled by default */
-/*#define CONFIG_HAS_FSL_DR_USB*/
-
-#ifdef CONFIG_HAS_FSL_DR_USB
-#define CONFIG_USB_EHCI_FSL
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#endif
-
-/*
  * Video
  */
 #ifdef CONFIG_VIDEO_FSL_DCU_FB
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 3db7ef1..15d6638 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -24,26 +24,6 @@
 #define CONFIG_SYS_INIT_RAM_ADDR   OCRAM_BASE_ADDR
 #define CONFIG_SYS_INIT_RAM_SIZE   OCRAM_SIZE
 
-/*
- * USB
- */
-
-/*
- * EHCI Support - disbaled by default as
- * there is no signal coming out of soc on
- * this board for this controller. However,
- * the silicon still has this controller,
- * and anyone can use this controller by
- * taking signals out on their board.
- */
-
-/*#define CONFIG_HAS_FSL_DR_USB*/
-
-#ifdef CONFIG_HAS_FSL_DR_USB
-#define CONFIG_USB_EHCI_FSL
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#endif
-
 #define CONFIG_SYS_CLK_FREQ1
 #define CONFIG_DDR_CLK_FREQ1
 
-- 
2.7.4

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

[U-Boot] [PATCH 2/3] usb: ehci: fsl: Fix some compile warnings.

[Ran Wang]

Signed-off-by: Ran Wang 
---
 drivers/usb/host/ehci-fsl.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 62c431b..17d1fae 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -106,14 +106,14 @@ static int ehci_fsl_probe(struct udevice *dev)
ehci = (struct usb_ehci *)priv->hcd_base;
hccr = (struct ehci_hccr *)(>caplength);
hcor = (struct ehci_hcor *)
-   ((u32)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
+   ((void *)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
 
if (ehci_fsl_init(priv, ehci, hccr, hcor) < 0)
return -ENXIO;
 
-   debug("ehci-fsl: init hccr %x and hcor %x hc_length %d\n",
- (u32)hccr, (u32)hcor,
- (u32)HC_LENGTH(ehci_readl(>cr_capbase)));
+   debug("ehci-fsl: init hccr %p and hcor %p hc_length %d\n",
+ (void *)hccr, (void *)hcor,
+ HC_LENGTH(ehci_readl(>cr_capbase)));
 
return ehci_register(dev, hccr, hcor, _ehci_ops, 0, USB_INIT_HOST);
 }
-- 
2.7.4

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

[U-Boot] [PATCH 1/3] armv8: ls1012a: Add USB 2.0 controller phy type for ls1012aqds board

[Ran Wang]

Without this propertiy, U-Boot will pop warning of 'USB phy type not
defined' when select CONFIG_HAS_FSL_DR_USB.

Signed-off-by: Ran Wang 
---
 arch/arm/dts/fsl-ls1012a-qds.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1012a-qds.dtsi 
b/arch/arm/dts/fsl-ls1012a-qds.dtsi
index dde7134..d17cd99 100644
--- a/arch/arm/dts/fsl-ls1012a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1012a-qds.dtsi
@@ -121,3 +121,8 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+   phy_type = "ulpi";
+};
-- 
2.7.4

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

Re: [U-Boot] [EXT] [PATCH] arm64: mvebu: armada-8k: support SD card environment

[Baruch Siach]

Hi Kostya,

Thanks for reviewing.

On Thu, Dec 14, 2017 at 11:28:18AM +, Kostya Porotchkin wrote:
> > Allow storing the environment on the Macchiatobin SD card. This is
> > useful for distribution of SD card software images. Currently, the
> > environment is always loaded from the SPI flash whose content might be
> > incompatible with SD card kernel loading.
> > 
> > Use the last 64KB of the 32MB boot partition as per the instructions in
> > the Macchiatobin wiki:
> > 
> >   http://wiki.macchiatobin.net/tiki-
> > index.php?page=Setup+alternative+boot+sources
> > 
> > Cc: Konstantin Porotchkin 
> > Signed-off-by: Baruch Siach 
> > ---
> >  include/configs/mvebu_armada-8k.h | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/include/configs/mvebu_armada-8k.h
> > b/include/configs/mvebu_armada-8k.h
> > index d85527434a0a..0457a72e353b 100644
> > --- a/include/configs/mvebu_armada-8k.h
> > +++ b/include/configs/mvebu_armada-8k.h
> > @@ -73,7 +73,12 @@
> >  #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
> >  #define CONFIG_ENV_SPI_MODECONFIG_SF_DEFAULT_MODE
> > 
> > +#if defined(CONFIG_ENV_IS_IN_SPI_FLASH)
> >  #define CONFIG_ENV_OFFSET  0x18 /* as Marvell U-Boot version */
> > +#elif defined(CONFIG_ENV_IS_IN_MMC)
> > +#define CONFIG_SYS_MMC_ENV_DEV 1
> > +#define CONFIG_ENV_OFFSET  0x21f
> > +#endif
>
> I think this will break boot from the on-board eMMC device.
> Maybe the environment offset should be connected to the MMC device ID.
> So it will be different for SD and eMMC.
> The eMMC boot partition is not that big as the space on SD allocated for the 
> boot images.
> Additionally, the SD pre-allocated boot space is not really a constant value.

So what would you suggest? How can we detect the location of the SD/eMMC 
stored environment? Would a per-board 'u-boot,mmc-env-offset' DT property 
help? Maybe move to CONFIG_ENV_IS_IN_FAT?

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 09/13] board: ti: am574x-idk: Add ddr data support

[Lokesh Vutla]

Hi Lukas,

On Monday 18 December 2017 04:46 PM, Lukasz Majewski wrote:
> Hi Lokesh,
> 
>> AM574x-idk has the following DDR parts attached:
>> EMIF1: MT41K256M16HA (1GB with ECC)
>> EMIF2: MT41K256M16HA (1GB without ECC)
>>
>> Enabling 2GB DDR without interleaving between EMIFs. And
>> enabling ECC on EMIF1.
>>
>> Signed-off-by: Lokesh Vutla 
>> Signed-off-by: Krunal Bhargav 
>> ---
>>  board/ti/am57xx/board.c | 47
>> --- 1 file changed, 44
>> insertions(+), 3 deletions(-)
>>
>> diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
>> index 2d14ae54fe..1377c7b1fe 100644
>> --- a/board/ti/am57xx/board.c
>> +++ b/board/ti/am57xx/board.c
>> @@ -89,10 +89,18 @@ static const struct dmm_lisa_map_regs
>> am571x_idk_lisa_regs = { .is_ma_present  = 0x1
>>  };
>>  
>> +static const struct dmm_lisa_map_regs am574x_idk_lisa_regs = {
>> +.dmm_lisa_map_2 = 0xc0600200,
>> +.dmm_lisa_map_3 = 0x80600100,
>> +.is_ma_present  = 0x1
>> +};
>> +
>>  void emif_get_dmm_regs(const struct dmm_lisa_map_regs
>> **dmm_lisa_regs) {
>>  if (board_is_am571x_idk())
>>  *dmm_lisa_regs = _idk_lisa_regs;
>> +else if (board_is_am574x_idk())
>> +*dmm_lisa_regs = _idk_lisa_regs;
>>  else
>>  *dmm_lisa_regs = _x15_lisa_regs;
>>  }
>> @@ -231,8 +239,8 @@ static const struct emif_regs
>> am571x_emif1_ddr3_666mhz_emif_regs =
>> { .ref_ctrl  =
>> 0x514d, .ref_ctrl_final  =
>> 0x144a, .sdram_tim1  = 0xd333887c,
>> -.sdram_tim2 = 0x40b37fe3,
>> -.sdram_tim3 = 0x409f8ada,
>> +.sdram_tim2 = 0x30b37fe3,
>> +.sdram_tim3 = 0x409f8ad8,
>>  .read_idle_ctrl = 0x0005,
>>  .zq_config  = 0x5007190b,
>>  .temp_alert_config  = 0x,
>> @@ -249,17 +257,50 @@ static const struct emif_regs
>> am571x_emif1_ddr3_666mhz_emif_regs =
>> { .emif_rd_wr_exec_thresh= 0x0305 };
>>  
>> +static const struct emif_regs am574x_emif1_ddr3_666mhz_emif_ecc_regs
>> = {
>> +.sdram_config_init  = 0x61863332,
>> +.sdram_config   = 0x61863332,
>> +.sdram_config2  = 0x0800,
>> +.ref_ctrl   = 0x514d,
>> +.ref_ctrl_final = 0x144a,
>> +.sdram_tim1 = 0xd333887c,
>> +.sdram_tim2 = 0x30b37fe3,
>> +.sdram_tim3 = 0x409f8ad8,
>> +.read_idle_ctrl = 0x0005,
>> +.zq_config  = 0x5007190b,
>> +.temp_alert_config  = 0x,
>> +.emif_ddr_phy_ctlr_1_init   = 0x0024400f,
>> +.emif_ddr_phy_ctlr_1= 0x0e24400f,
>> +.emif_ddr_ext_phy_ctrl_1= 0x10040100,
>> +.emif_ddr_ext_phy_ctrl_2= 0x00910091,
>> +.emif_ddr_ext_phy_ctrl_3= 0x00950095,
>> +.emif_ddr_ext_phy_ctrl_4= 0x009b009b,
>> +.emif_ddr_ext_phy_ctrl_5= 0x009e009e,
>> +.emif_rd_wr_lvl_rmp_win = 0x,
>> +.emif_rd_wr_lvl_rmp_ctl = 0x8000,
>> +.emif_rd_wr_lvl_ctl = 0x,
>> +.emif_rd_wr_exec_thresh = 0x0305,
>> +.emif_ecc_ctrl_reg  = 0xD001,
>> +.emif_ecc_address_range_1   = 0x3FFF,
>> +.emif_ecc_address_range_2   = 0x
>> +};
> 
> I'm wondering if it would be possible to:
> 
> Embed this memory setup (even as binary blob) to SPL FIT -> Those
> values are generated from TI supplied excel sheet (when memory details
> are provided).
> 
> 
> Pros:
> 
> 
> - Since the same EMIF controller is used, one could only adjust the
>   binary blob, when new memory (faster, slower, from other manufacturer)
>   is used in the product.
> 
> - There would be no need to add such code to the board file.

yeah, ddr is not the only thing that comes in this bucket, PMIC data as
well can be also made in similar way. I mean all the board related
information can be moved out. But then the binary size will still remain
the same. Also, we will need a new driver to parse these new binary formats.

As of now, the ddr excel sheet outputs the data in the $patch format, so
still sticking to this format.

Yeah, i agree that it would be nice if we can come up with the separate
binary for all board related info(i guess DT can be re used here).

Thanks and regards,
Lokesh

> 
>> +
>>  void emif_get_reg_dump(u32 emif_nr, const struct emif_regs **regs)
>>  {
>>  switch (emif_nr) {
>>  case 1:
>>  if (board_is_am571x_idk())
>>  *regs = _emif1_ddr3_666mhz_emif_regs;
>> +else if (board_is_am574x_idk())
>> +*regs =
>> _emif1_ddr3_666mhz_emif_ecc_regs; else
>>  *regs =
>> 

Re: [U-Boot] [PATCH 11/13] board: ti: am57xx: Enable CMD_DDR3

[Lokesh Vutla]

Hi Lukas,

On Monday 18 December 2017 04:48 PM, Lukasz Majewski wrote:
> Hi Lokesh,
> 
>> Enable CMD_DDR3 on all am57xx based platforms.
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  arch/arm/mach-omap2/omap5/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap5/Kconfig
>> b/arch/arm/mach-omap2/omap5/Kconfig index 8c1730a6be..deb9873cc5
>> 100644 --- a/arch/arm/mach-omap2/omap5/Kconfig
>> +++ b/arch/arm/mach-omap2/omap5/Kconfig
>> @@ -39,6 +39,7 @@ config TARGET_AM57XX_EVM
>>  select BOARD_LATE_INIT
>>  select DRA7XX
>>  select TI_I2C_BOARD_DETECT
>> +select CMD_DDR3
> 
> I'm just curious - what is the purpose of this command?

This command supports memory testing and ecc testing.

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

Re: [U-Boot] [PATCH 2/5] board: TI K2G: FC SoC 1GHz and DDR3 1066 MT/s support

[Lokesh Vutla]

On Monday 18 December 2017 09:16 PM, Tom Rini wrote:
> On Mon, Dec 18, 2017 at 03:10:04PM +0530, Lokesh Vutla wrote:
> 
>> From: Rex Chang 
>>
>> Added support for K2G EVM with FlipChip SoC of which
>> ARM/DDR3 runs at 1GHz/1066 MT/s. The patch is also
>> backward compatible with old revision EVM and EVM
>> with WireBond SoC. Their ARM/DDR3 run at 600MHz/800 MT/s.
>>
>> The new SoC supports 2 different speeds at 1GHz and 600MHz.
>> Modyfied the CPU Name to show which SoC is used in the EVM.
>> Modified the DDR3 configuration to reflect New SoC supports
>> 2 different CPU and DDR3 speeds, 1GHz/1066MT and 600MHz/800MT.
>>
>> Added new inline function board_it_k2g_g1() for the new FlipChip 1GHz,
>> and set the u-boot env variable board_name accordingly.
>>
>> Modified findfdt script in u-boot environment variable to include new k2g 
>> board type.
>>
>> Signed-off-by: Rex Chang 
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  arch/arm/mach-keystone/include/mach/hardware.h |  7 
>>  arch/arm/mach-keystone/init.c  | 17 +++-
>>  board/ti/ks2_evm/board.h   |  4 ++
>>  board/ti/ks2_evm/board_k2g.c   | 30 +++---
>>  board/ti/ks2_evm/ddr3_k2g.c| 57 
>> +-
>>  board/ti/ks2_evm/mux-k2g.h |  2 +-
>>  include/configs/k2g_evm.h  |  4 +-
>>  7 files changed, 109 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/mach-keystone/include/mach/hardware.h 
>> b/arch/arm/mach-keystone/include/mach/hardware.h
>> index 6629406870..e1621b27a4 100644
>> --- a/arch/arm/mach-keystone/include/mach/hardware.h
>> +++ b/arch/arm/mach-keystone/include/mach/hardware.h
>> @@ -327,6 +327,9 @@ typedef volatile unsigned int   *dv_reg_p;
>>  #define CPU_66AK2Lx 0xb9a7
>>  #define CPU_66AK2Gx 0xbb06
>>  
>> +/* Variant definitions */
>> +#define CPU_66AK2G1x0x08
>> +
>>  /* DEVSPEED register */
>>  #define DEVSPEED_DEVSPEED_SHIFT 16
>>  #define DEVSPEED_DEVSPEED_MASK  (0xfff << 16)
>> @@ -390,6 +393,10 @@ static inline u8 cpu_revision(void)
>>  int cpu_to_bus(u32 *ptr, u32 length);
>>  void sdelay(unsigned long);
>>  
>> +#ifdef CONFIG_SOC_K2G
>> +extern int arm_speeds[];
>> +#endif
> 
> Lets not ifdef around externs.

okay.

> 
> [snip]
>> @@ -241,7 +253,8 @@ int print_cpuinfo(void)
>>  puts("1.1\n");
>>  else if (rev == 0)
>>  puts("1.0\n");
>> -
>> +else if (rev == 8)
>> +puts("1.0\n");
> 
> Both values are rev "1.0" ?

Yeah, basically both are rev 1.0 but with different speed grades. This
is the naming convention recommended from marketing team.

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

Re: [U-Boot] [PATCH 04/13] arm: keystone: Move cmd_ddr3 to a common place

[Lokesh Vutla]

On Tuesday 19 December 2017 01:33 AM, Tom Rini wrote:
> On Mon, Dec 18, 2017 at 03:04:16PM +0530, Lokesh Vutla wrote:
> 
>> Move cmd_ddr3 to board/ti/common/ in order to make
>> it build for non-keystone TI platforms.
>>
>> Signed-off-by: Lokesh Vutla 
> [snip]
>> diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
>> index 7170eac81e..66025040bc 100644
>> --- a/board/ti/common/Makefile
>> +++ b/board/ti/common/Makefile
>> @@ -4,3 +4,6 @@
>>  #
>>  
>>  obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
>> +ifndef CONFIG_SPL_BUILD
>> +obj-${CONFIG_CMD_DDR3} += cmd_ddr3.o
>> +endif
> 
> We shouldn't need games like that now to have all strings be discarded,
> now that we're mandating gcc-6 or later.  Thanks!
> 

whithout guarding with !SPL_BUILD, following build erroris seen if
SPL_ENV is not enabled:

#
env/built-in.o:(.data.env_htab+0xc): undefined reference to
`env_flags_validate'
lib/built-in.o: In function `hsearch_r':
/home/lokesh/working/mainline/u-boot/lib/hashtable.c:380: undefined
reference to `env_callback_init'
/home/lokesh/working/mainline/u-boot/lib/hashtable.c:382: undefined
reference to `env_flags_init'
scripts/Makefile.spl:343: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 1
Makefile:1400: recipe for target 'spl/u-boot-spl' failed
make: *** [spl/u-boot-spl] Error 2


gcc-6 is being used. Am I missing something?

Thanks and regards,
Lokesh

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

Re: [U-Boot] [PATCH 6/7] tools: fix incorrect usage of DT node unit address

[Simon Glass]

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address in a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Correct the generated unit names when U-Boot's mkimage creates a FIT
> image.
>
> Signed-off-by: Andre Przywara 
> ---
>  tools/fit_image.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)

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

Re: [U-Boot] Please pull u-boot-mmc master

[Jaehoon Chung]

On 12/19/2017 08:36 AM, Tom Rini wrote:
> On Thu, Dec 14, 2017 at 11:16:55AM +0900, Jaehoon Chung wrote:
> 
>> Dear Tom,
>>
>> Could you pull these patches to u-boot/master?
>> Sorry for late. We want to support HS200/UHS mode at v2018.01.
>>
>> I have tested the buildman about all configs.
>> I didn't see any problem, but if i missed something, let me know, plz.
>>
>> The following changes since commit 659208da4703de50826a469cbb38bf6afb938978:
>>
>>   README: update the kernel coding style reference (2017-12-12 21:34:10 
>> -0500)
>>
>> are available in the Git repository at:
>>
>>   git://git.denx.de/u-boot-mmc.git master
>>
>> for you to fetch changes up to e40a090b46475fc9e86b125f67cc16f3b1ad6e04:
>>
>>   configs: omapl138_lcdk: decrease the loglevel to reduce the size of the 
>> SPL (2017-12-14 11:12:21 +0900)
>>
> 
> It is too late to -rc2 at this point for something that showed problems
> when testing in CI.  I do not want this to get lost / greatly delayed
> further.  As such, I'm going to put this (and the fix for sandbox) into
> u-boot/next so that people can continue to test against it more easily,
> and so that once v2018.01 is out I can merge this in.  So:
> Applied to u-boot/next, thanks!

Sorry for late..and Thanks!

> 

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

Re: [U-Boot] [PATCH 3/7] doc: fix incorrect usage of DT node unit address

[Simon Glass]

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address in a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Fix all occurences in various documentation files where this was not
> observed, to not give bad examples to the reader.
>
> Signed-off-by: Andre Przywara 
> ---
>  .../arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 16 +-
>  doc/README.uniphier| 36 
> +++---
>  doc/chromium/chromebook_jerry.its  | 16 +-
>  doc/chromium/nyan-big.its  | 16 +-
>  4 files changed, 42 insertions(+), 42 deletions(-)

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

Re: [U-Boot] [PATCH 4/7] fix incorrect usage of DT node unit address in comments

[Simon Glass]

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address in a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Fix all occurences in the tree where node names were mentioned in
> comments, to not give bad examples to the reader.
>
> Signed-off-by: Andre Przywara 
> ---
>  common/image-fit.c | 16 
>  common/image-sig.c |  2 +-
>  include/image.h| 26 +-
>  tools/image-host.c | 10 +-
>  4 files changed, 27 insertions(+), 27 deletions(-)

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

Re: [U-Boot] [PATCH 7/7] armv8: secure firmware: fix incorrect unit address in node name

[Simon Glass]

Hi Andre,

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address in a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Remove the unit address from the config node name when U-Boot deals with
> secure firmware FIT images.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv8/sec_firmware.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

After this series, what remains to be converted?

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

Re: [U-Boot] [PATCH 1/7] doc: FIT image: fix incorrect description of DT node unit address

[Simon Glass]

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address in a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Fix all occurences in the FIT image documentation files where this was not
> observed, to not give bad examples to the reader.
>
> Signed-off-by: Andre Przywara 
> ---
>  doc/uImage.FIT/beaglebone_vboot.txt  |  84 +++---
>  doc/uImage.FIT/command_syntax_extensions.txt |  42 +--
>  doc/uImage.FIT/howto.txt |  52 +++---
>  doc/uImage.FIT/overlay-fdt-boot.txt  |  78 ++---
>  doc/uImage.FIT/signature.txt | 100 
> +--
>  doc/uImage.FIT/source_file_format.txt|  26 +++
>  doc/uImage.FIT/x86-fit-boot.txt  |  10 +--
>  7 files changed, 196 insertions(+), 196 deletions(-)
>

Reviewed-by: Simon Glass 

I'm not hugely keen on the inconsistency of kernel vs. hash@1, but I
suppose it does not matter.

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

Re: [U-Boot] [PATCH 2/7] doc: FIT image: fix incorrect examples of DT node unit address

[Simon Glass]

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address of a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Fix all occurences in the FIT image example files where this was not
> observed, to not give bad examples to the reader.
>
> Signed-off-by: Andre Przywara 
> ---
>  doc/uImage.FIT/kernel.its   | 28 -
>  doc/uImage.FIT/kernel_fdt.its   | 20 ++--
>  doc/uImage.FIT/multi-with-fpga.its  | 28 -
>  doc/uImage.FIT/multi-with-loadables.its | 40 
>  doc/uImage.FIT/multi.its| 54 
> -
>  doc/uImage.FIT/multi_spl.its| 14 -
>  doc/uImage.FIT/sign-configs.its | 18 +--
>  doc/uImage.FIT/sign-images.its  | 16 +-
>  doc/uImage.FIT/update3.its  | 12 
>  doc/uImage.FIT/update_uboot.its |  4 +--
>  10 files changed, 117 insertions(+), 117 deletions(-)

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

Re: [U-Boot] [PATCH 5/7] sunxi: arm64: correct usage of DT node address in FIT generation

[Simon Glass]

Hi Andre,

On 3 December 2017 at 19:05, Andre Przywara  wrote:
> The DT spec demands a unit-address in a node name to match the "reg"
> property in that node. Newer dtc versions will throw warnings if this is
> not the case.
> Adjust the FIT build script for 64-bit Allwinner boards to remove the
> bogus addresses from the node names and avoid the warnings.
> This avoids a warning with recent versions of the dtc tool.
>
> Signed-off-by: Andre Przywara 
> ---
>  board/sunxi/mksunxi_fit_atf.sh | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh
> index b1d6e0e16a..36abe9efed 100755
> --- a/board/sunxi/mksunxi_fit_atf.sh
> +++ b/board/sunxi/mksunxi_fit_atf.sh
> @@ -21,7 +21,7 @@ cat << __HEADER_EOF
> #address-cells = <1>;
>
> images {
> -   uboot@1 {
> +   uboot {
> description = "U-Boot (64-bit)";
> data = /incbin/("u-boot-nodtb.bin");
> type = "standalone";
> @@ -29,7 +29,7 @@ cat << __HEADER_EOF
> compression = "none";
> load = <0x4a00>;
> };
> -   atf@1 {
> +   atf {
> description = "ARM Trusted Firmware";
> data = /incbin/("$BL31");
> type = "firmware";
> @@ -44,7 +44,7 @@ cnt=1
>  for dtname in $*
>  do
> cat << __FDT_IMAGE_EOF
> -   fdt@$cnt {
> +   fdt_$cnt {
> description = "$(basename $dtname .dtb)";
> data = /incbin/("$dtname");
> type = "flat_dt";
> @@ -57,7 +57,7 @@ done
>  cat << __CONF_HEADER_EOF
> };
> configurations {
> -   default = "config@1";
> +   default = "config_1";

Have you changed from hyphen to underscore here?

>
>  __CONF_HEADER_EOF
>
> @@ -65,11 +65,11 @@ cnt=1
>  for dtname in $*
>  do
> cat << __CONF_SECTION_EOF
> -   config@$cnt {
> +   config_$cnt {
> description = "$(basename $dtname .dtb)";
> -   firmware = "uboot@1";
> -   loadables = "atf@1";
> -   fdt = "fdt@$cnt";
> +   firmware = "uboot";
> +   loadables = "atf";
> +   fdt = "fdt_$cnt";
> };
>  __CONF_SECTION_EOF
> cnt=$((cnt+1))
> --
> 2.14.1
>

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

[U-Boot] [PATCH] Powerpc: T208xQDS: Modify the comment of the CONFIG_FSL_PCIE_RESET macro

[Bao Xiaowei]

Remove duplicate macro CONFIG_FSL_PCIE_RESET and update its comment.
It enables PCIe reset to fix link width 2x - 4x.

Signed-off-by: Bao Xiaowei 
---
 include/configs/T208xQDS.h |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h
index e792ec5..06a824e 100644
--- a/include/configs/T208xQDS.h
+++ b/include/configs/T208xQDS.h
@@ -540,7 +540,7 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_PCIE2   /* PCIE controller 2 */
 #define CONFIG_PCIE3   /* PCIE controller 3 */
 #define CONFIG_PCIE4   /* PCIE controller 4 */
-#define CONFIG_FSL_PCIE_RESET
+#define CONFIG_FSL_PCIE_RESET   /* pcie reset fix link width 2x-4x*/
 #define CONFIG_FSL_PCI_INIT/* Use common FSL init code */
 #define CONFIG_SYS_PCI_64BIT   /* enable 64-bit PCI resources */
 /* controller 1, direct to uli, tgtid 3, Base address 2 */
@@ -584,7 +584,6 @@ unsigned long get_board_ddr_clk(void);
 
 #ifdef CONFIG_PCI
 #define CONFIG_PCI_INDIRECT_BRIDGE
-#define CONFIG_FSL_PCIE_RESET /* need PCIe reset errata */
 #define CONFIG_PCI_SCAN_SHOW   /* show pci devices on startup */
 #endif
 
-- 
1.7.1

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

Re: [U-Boot] [PATCH] spl: atf: fix the plat_params

[Kever Yang]

Hi Philipp,


On 12/15/2017 05:07 PM, Dr. Philipp Tomsich wrote:

Kever,

If you need/want to disable this, could you make this conditional on a new
Kconfig option?  That way we can disable it for those boards that still ship
with an old ATF


That's not an "old" ATF, it's the latest upstream version and wildly 
used by all

the open source community. Many people get from upstream first, and then
other forks.

(note that passing NULL also broke the upstream ATF for
quite a number of versions…).


A NULL pointer means no parameter for plat_params, and it will not broke 
upstream ATF.


Well, what make me crazy is that every time I update a version from 
upstream U-Boot,

I have to debug for different issues on different boards:(


Alternatively, you could add a board-specific wrapper function that allows
modifying the parameters (as they are plat_params, anyway), e.g.:
atf_entry((void *)bl31_params, board_atf_plat_params(fdt_addr))

This would allow you to suppress this for boards that are known to ship
with a ATF that does not yet support this.


We should do this before previous patch, right?


Note that the ATF shipped by us has already been updated, so we can’t
just remove this as it will break functionality for people in the field...


You customer should get a complete version with all functionality work 
from your
server, right? It's not totally the same as the upstream version, just 
like Rockchip have

a version on github for evbs, which have been test by our QA.

BUT, open source community always get a BROKEN version from upstream :(
The upstream source code should have a good support for the boards 
already upstream,

but it broken very frequently.

Thanks,
- Kever


Thanks,
Philipp.


On 15 Dec 2017, at 04:27, Kever Yang  wrote:

The latest upstream ATF still not support using a fdt base as plat_params,
I get error like this:
"ERROR:   not expected type found 6410029648624618960"

The reason is the ATF source code parse the plat_param, and can not
decode the type in:
/* common header for all plat parameter type */
struct bl31_plat_param {
uint64_t type;
void *next;
};
void params_early_setup(void *plat_param_from_bl2)
plat/rockchip/common/params_setup.c

We can only use the fdt_addr as plat_params after upstream ATF able to
parse it.

BUGFIX to:
1d37909 spl: atf: introduce spl_invoke_atf and make bl31_entry private

Signed-off-by: Kever Yang 
---

common/spl/spl_atf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index 63557c0..a65d603 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -96,7 +96,7 @@ static void bl31_entry(uintptr_t bl31_entry, uintptr_t 
bl33_entry,
raw_write_daif(SPSR_EXCEPTION_MASK);
dcache_disable();

-   atf_entry((void *)bl31_params, (void *)fdt_addr);
+   atf_entry((void *)bl31_params, NULL);
}

static int spl_fit_images_find_uboot(void *blob)
--
1.9.1






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

[U-Boot] [ANN] U-Boot v2018.01-rc2 released

[Tom Rini]

Hey all,

It's release day and v2018.01-rc2 is out.  I'm mostly happy with the
size of the changes here and I did remember to sync the defconfigs prior
to tagging.

Once again, at this point, any changes that come in need to be clear fixes to a
problem or Kconfig migrations that can be shown as correct.  The
exception is that I'm expecting another spin on the imx PR to fix some
problems that are known there.

Things look on track for -rc3 on the 1st of January and release on the
8th.  Thanks all!

-- 
Tom


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

Re: [U-Boot] [PULL] Please pull u-boot-rockchip/master

[Tom Rini]

On Tue, Dec 19, 2017 at 12:25:28AM +0100, Dr. Philipp Tomsich wrote:

> Tom,
> 
> there’s a few stabilisation fixes and documentation/packaging improvements
> on u-boot-rockchip/master for you for merge/pull.
> 
> A matching Travis CI run is at
>   https://travis-ci.org/ptomsich/u-boot-rockchip/builds/318163689
> 
> Cheers,
> Philipp.
> 
> 
> The following changes since commit 15616a0aa58173bce1efe47569bf2e10d023ae9c:
> 
>   Merge git://git.denx.de/u-boot-dm (2017-12-14 15:46:07 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git master
> 
> for you to fetch changes up to cbe503793aba03c19b8d21e0a6e344afe624e2d6:
> 
>   rockchip: add a common script for generate fit its (2017-12-18 17:18:02 
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-fsl-qoriq master

[Tom Rini]

On Mon, Dec 18, 2017 at 04:26:24PM +, York Sun wrote:

> Tom,
> 
> The following changes since commit cf71338ee7a1dc16f13a4f1b89f32c624210df45:
> 
>   ata: Migrate CONFIG_MVSATA_IDE to Kconfig (2017-12-12 18:16:06 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fsl-qoriq.git
> 
> for you to fetch changes up to 1b7910a37ccc889e1b58a5f6e095a39728564bb8:
> 
>   armv8: ls1046aqds: Adjust IFC timing for NOR flash (2017-12-18
> 08:25:07 -0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [GIT PULL] Xilinx fixes for v2018.01-rc2 v2

[Tom Rini]

On Mon, Dec 18, 2017 at 01:34:03PM +0100, Michal Simek wrote:

> Hi Tom, +Stephen
> 
> This is second pull request. I have removed that AES command enabling
> which was causing compilation warning on arm64.
> 
> Thanks,
> Michal
> 
> The following changes since commit 659208da4703de50826a469cbb38bf6afb938978:
> 
>   README: update the kernel coding style reference (2017-12-12 21:34:10
> -0500)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-microblaze.git
> tags/xilinx-for-v2018.01-rc2-v2
> 
> for you to fetch changes up to 3e229a83bd4190f99731992d3a56983f29313899:
> 
>   test/py: Setup variables based on HUSH selection (2017-12-18 09:32:07
> +0100)
> 

Applied to u-boot/master, thanks!



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


-- 
Tom


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

Re: [U-Boot] [U-Boot, u-boot] ARM: arch-meson: fix writel arguments order

[Tom Rini]

On Tue, Dec 12, 2017 at 02:23:39PM +0100, Neil Armstrong wrote:

> From: Hans Verkuil 
> 
> Using writel causes a "Synchronous Abort". Invert the arguments.
> 
> Signed-off-by: Hans Verkuil 
> Signed-off-by: Neil Armstrong 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, u-boot] net: phy: meson-gxl: detect LPA corruption

[Tom Rini]

On Tue, Dec 12, 2017 at 04:03:55PM +0100, Neil Armstrong wrote:

> From: Jerome Brunet 
> 
> This patch is ported from the Linux patch posted at [1] and applied to
> net tree as commit f1e2400a80ff.
> 
> The purpose of this change is to fix the incorrect detection of the link
> partner (LP) advertised capabilities which sometimes happens with this PHY
> (roughly 1 time in a dozen)
> 
> This issue may cause the link to be negotiated at 10Mbps/Full or
> 10Mbps/Half when 100MBps/Full is actually possible. In some case, the link
> is even completely broken and no communication is possible.
> 
> To detect the corruption, we must look for a magic undocumented bit in the
> WOL bank (hint given by the SoC vendor kernel) but this is not enough to
> cover all cases. We also have to look at the LPA ack. If the LP supports
> Aneg but did not ack our base code when aneg is completed, we assume
> something went wrong.
> 
> The detection of a corrupted LPA triggers a restart of the aneg process.
> This solves the problem but may take up to 6 retries to complete.
> 
> [1] https://lkml.kernel.org/r/20171208110811.30789-1-jbru...@baylibre.com
> 
> Fixes: 8995a96d1d67 ("net: phy: Add Amlogic Meson GXL Internal PHY support")
> Signed-off-by: Jerome Brunet 
> Signed-off-by: Neil Armstrong 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] common: image.c: Fix CACHE: Misaligned operation output

[Tom Rini]

On Thu, Dec 14, 2017 at 11:19:22AM +0100, Heiko Schocher wrote:

> When booting a itb file with a Ramdisk on a imx6 based
> board, U-Boot drops the warning:
> 
> Loading Kernel Image ... OK
> Loading Ramdisk to 4ecf1000, end 4ef8b11f ... \
> CACHE: Misaligned operation at range [4ecf1000,  4ef8b11f]
> 
> Fix it!
> 
> Signed-off-by: Heiko Schocher 
> Tested-by: Ayoub Zaki 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PULL] efi patch queue 2017-12-17

[Tom Rini]

On Sun, Dec 17, 2017 at 09:33:44PM +0100, Alexander Graf wrote:

> Hi Tom,
> 
> This is my current patch queue for efi.  Please pull.
> 
> Alex
> 
> 
> The following changes since commit 15616a0aa58173bce1efe47569bf2e10d023ae9c:
> 
>   Merge git://git.denx.de/u-boot-dm (2017-12-14 15:46:07 -0500)
> 
> are available in the git repository at:
> 
>   git://github.com/agraf/u-boot.git tags/signed-efi-v2018.01
> 
> for you to fetch changes up to bde6bfe4c3234480a0eef3b5bda8cf5fc83d3c79:
> 
>   efi_loader: comments for dp_part_fill() (2017-12-16 23:07:56 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] am335x_evm: Fix DFU for eMMC

[Tom Rini]

On Tue, Dec 12, 2017 at 08:07:41PM +0200, Sam Protsenko wrote:

> Use dfu_alt_info_emmc variable from include/environment/ti/dfu.h file.
> It was probably overlooked when extracting DFU variables to mentioned
> file.
> 
> This patch fixes DFU on BeagleBone Black, so that we can use commands
> like ones below to upgrade various images on eMMC:
> 
> => setenv dfu_alt_info $dfu_alt_info_emmc
> => dfu 0 mmc 1
> 
> $ dfu-util -D MLO -a MLO.raw
> $ dfu-util -D u-boot.img -a u-boot.img.raw
> 
> Without this patch, the  user is forced to assign the value to
> dfu_alt_info_emmc manually, which contradicts with instructions [1].
> 
> [1] http://processors.wiki.ti.com/index.php/Linux_Core_U-Boot_User%27s_Guide
> 
> Signed-off-by: Sam Protsenko 
> Reviewed-by: Lokesh Vutla 
> Reviewed-by: Lukasz Majewski 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] am335x_hs_evm: Trim options in SPL to reduce binary size

[Tom Rini]

On Sat, Dec 16, 2017 at 11:04:53PM -0500, Tom Rini wrote:

> The am335x_hs_evm runs into size constraint problems at times with
> various toolchains as changes come in due to the config have a large
> number of options in SPL (to showcase what is possible) while also
> having rather constrained binary limits.  Gain some of this room back by
> lowering the loglevel, disabling HW partition support and switching over
> to the tiny FIT image support.
> 
> Cc: Andrew F. Davis 
> Signed-off-by: Tom Rini 

Applied to u-boot/next (so if there's problems, we'll re-work it), thanks!

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-mmc master

[Tom Rini]

On Thu, Dec 14, 2017 at 11:16:55AM +0900, Jaehoon Chung wrote:

> Dear Tom,
> 
> Could you pull these patches to u-boot/master?
> Sorry for late. We want to support HS200/UHS mode at v2018.01.
> 
> I have tested the buildman about all configs.
> I didn't see any problem, but if i missed something, let me know, plz.
> 
> The following changes since commit 659208da4703de50826a469cbb38bf6afb938978:
> 
>   README: update the kernel coding style reference (2017-12-12 21:34:10 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-mmc.git master
> 
> for you to fetch changes up to e40a090b46475fc9e86b125f67cc16f3b1ad6e04:
> 
>   configs: omapl138_lcdk: decrease the loglevel to reduce the size of the SPL 
> (2017-12-14 11:12:21 +0900)
> 

It is too late to -rc2 at this point for something that showed problems
when testing in CI.  I do not want this to get lost / greatly delayed
further.  As such, I'm going to put this (and the fix for sandbox) into
u-boot/next so that people can continue to test against it more easily,
and so that once v2018.01 is out I can merge this in.  So:
Applied to u-boot/next, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] dm: mmc: sandbox: Update SD card emulation

[Tom Rini]

On Thu, Dec 14, 2017 at 11:47:14AM +0100, Jean-Jacques Hiblot wrote:

> The SDcard initialization procedure does a few more things than it did 
> earlier:
> * switch the bus width even for 1-bit bus width
> * check that speed has been properly set (in resp[4] of SD_CMD_SWITCH_FUNC)
> 
> Update the SD simulator to handle those requests gracefully.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> Reviewed-by: Jaehoon Chung 

Applied to u-boot/next, thanks!

-- 
Tom


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

[U-Boot] [PULL] Please pull u-boot-rockchip/master

[Dr. Philipp Tomsich]

Tom,

there’s a few stabilisation fixes and documentation/packaging improvements
on u-boot-rockchip/master for you for merge/pull.

A matching Travis CI run is at
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/318163689

Cheers,
Philipp.


The following changes since commit 15616a0aa58173bce1efe47569bf2e10d023ae9c:

  Merge git://git.denx.de/u-boot-dm (2017-12-14 15:46:07 -0500)

are available in the git repository at:

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

for you to fetch changes up to cbe503793aba03c19b8d21e0a6e344afe624e2d6:

  rockchip: add a common script for generate fit its (2017-12-18 17:18:02 +0100)


Jakob Unterwurzacher (1):
  rockchip: rk3399-puma: set gpio4cd iodomain to 1.8V

Kever Yang (6):
  rockchip: config: update part table
  rockchip: update boot0 hook
  rockchip: update ROCKCHIP_SPL_RESERVE_IRAM to 0
  rockchip: evb-rk3399: update document for board bring up
  rockchip: firefly-rk3399: add FIT for rk3399
  rockchip: add a common script for generate fit its

Klaus Goger (1):
  rockchip: move CONFIG_ENV_SIZE and CONFIG_ENV_OFFSET to Kconfig

 arch/arm/include/asm/arch-rockchip/boot0.h|   7 +++-
 arch/arm/mach-rockchip/Kconfig|   2 +-
 arch/arm/mach-rockchip/make_fit_atf.py| 221 
+
 board/rockchip/evb_rk3399/README  |  83 
+++-
 board/theobroma-systems/puma_rk3399/Kconfig   |   6 +++
 board/theobroma-systems/puma_rk3399/puma-rk3399.c |  19 +
 configs/evb-rk3399_defconfig  |   1 +
 configs/firefly-rk3399_defconfig  |   2 +
 env/Kconfig   |  18 +
 include/configs/puma_rk3399.h |   8 
 include/configs/rockchip-common.h |  12 +-
 11 files changed, 341 insertions(+), 38 deletions(-)
 create mode 100755 arch/arm/mach-rockchip/make_fit_atf.py

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

Re: [U-Boot] [U-Boot, v3, 2/3] rockchip: firefly-rk3399: add FIT for rk3399

[Philipp Tomsich]

> Enable SPL_FIT_GENERATOR with path for it.
> With this patch you can get u-boot.itb for rk3399-firefly with:
> > make u-boot.itb
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Mark Kettenis 
> Tested-by: Mark Kettenis 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - update with new script path
> 
> Changes in v2:
> - typo fix, rk3399-evb->rk3399-firefly
> 
>  configs/firefly-rk3399_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 

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

Re: [U-Boot] [U-Boot, v3, 3/3] rockchip: evb-rk3399: update document for board bring up

[Philipp Tomsich]

> Since we support ATF in SPL and add script for it, let's make the
> document up to date.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - update addr for uboot.itb to 0x4000
> 
> Changes in v2:
> - typo fix, evb-firefly－>firefly-rk3399
> 
>  board/rockchip/evb_rk3399/README | 83 
> +++-
>  1 file changed, 65 insertions(+), 18 deletions(-)
> 

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

Re: [U-Boot] [U-Boot, v3, 1/3] rockchip: add a common script for generate fit its

[Philipp Tomsich]

> Rockchip release bl31.elf file for armv8 SoCs like rk3399, rk3328,
> the elf have more than one section, we need to decode it first and
> packed them into u-boot.itb with its file. This script is to generate
> the its script.
> Need default bl31.elf in root directory of U-Boot source and dtb
> as parameter.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - use python script
> - adapt for latest spl atf support
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/make_fit_atf.py | 221 
> +
>  1 file changed, 221 insertions(+)
>  create mode 100755 arch/arm/mach-rockchip/make_fit_atf.py
> 

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

Re: [U-Boot] [PATCH v3] drivers: core: Add translation in live tree case

[Stephen Warren]

On 12/18/2017 03:33 PM, Stephen Warren wrote:

On 12/18/2017 03:29 PM, Stephen Warren wrote:

On 12/18/2017 01:34 AM, Mario Six wrote:

The function dev_read_addr calls ofnode_get_addr_index in the live tree
case, which does not apply bus translations to the address read from the
device tree. This results in illegal addresses on boards that rely on
bus translations being applied.

Fix this situation by applying bus translations in the live tree case as
well.


Tested-by: Stephen Warren 


Uggh. Sorry, I take that back. This seems to break NVIDIA Jetson TX1 
(p2371-2180 board), even though it did solve this issue that was present 
on other boards in the previous patch version. I'll try and see what's 
up (something to do with I2C accesses early during boot)...


I guess this is something to do with:


+   if (IS_ENABLED(CONFIG_OF_TRANSLATE)) {
+   u64 paddr = of_translate_address(ofnode_to_np(node), 
);
+
+   return be32_to_cpu((fdt_addr_t)paddr);


My tests passed on a 32-bit platform but failed on a 64-bit platform. I 
expect you need be64_to_cpu() there on 64-bit platforms? Actually, it 
should really base the bit-width on #address-cells, but we only support 
32- or 64-bit at the moment so switching between the two is probably fine.

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

Re: [U-Boot] [PATCH v3] drivers: core: Add translation in live tree case

[Stephen Warren]

On 12/18/2017 03:29 PM, Stephen Warren wrote:

On 12/18/2017 01:34 AM, Mario Six wrote:

The function dev_read_addr calls ofnode_get_addr_index in the live tree
case, which does not apply bus translations to the address read from the
device tree. This results in illegal addresses on boards that rely on
bus translations being applied.

Fix this situation by applying bus translations in the live tree case as
well.


Tested-by: Stephen Warren 


Uggh. Sorry, I take that back. This seems to break NVIDIA Jetson TX1 
(p2371-2180 board), even though it did solve this issue that was present 
on other boards in the previous patch version. I'll try and see what's 
up (something to do with I2C accesses early during boot)...

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

Re: [U-Boot] [PATCH v3] drivers: core: Add translation in live tree case

[Stephen Warren]

On 12/18/2017 01:34 AM, Mario Six wrote:

The function dev_read_addr calls ofnode_get_addr_index in the live tree
case, which does not apply bus translations to the address read from the
device tree. This results in illegal addresses on boards that rely on
bus translations being applied.

Fix this situation by applying bus translations in the live tree case as
well.


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

[U-Boot] [PATCH] PCI: Drop CONFIG_TSI108_PCI

[Tuomas Tynkkynen]

Last user of this option went away in 2015 in commit:
d928664f41 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/pci/Makefile |   1 -
 drivers/pci/tsi108_pci.c | 167 ---
 2 files changed, 168 deletions(-)
 delete mode 100644 drivers/pci/tsi108_pci.c

diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 5eb12efbf5..5410897e40 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -29,7 +29,6 @@ obj-$(CONFIG_SH4_PCI) += pci_sh4.o
 obj-$(CONFIG_SH7751_PCI) +=pci_sh7751.o
 obj-$(CONFIG_SH7780_PCI) +=pci_sh7780.o
 obj-$(CONFIG_PCI_TEGRA) += pci_tegra.o
-obj-$(CONFIG_TSI108_PCI) += tsi108_pci.o
 obj-$(CONFIG_PCIE_DW_MVEBU) += pcie_dw_mvebu.o
 obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o
 obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape_fixup.o
diff --git a/drivers/pci/tsi108_pci.c b/drivers/pci/tsi108_pci.c
deleted file mode 100644
index d48e1e6fe6..00
--- a/drivers/pci/tsi108_pci.c
+++ /dev/null
@@ -1,167 +0,0 @@
-/*
- * (C) Copyright 2004 Tundra Semiconductor Corp.
- * Alex Bounine 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-/*
- * PCI initialisation for the Tsi108 EMU board.
- */
-
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#if defined(CONFIG_OF_LIBFDT)
-#include 
-#include 
-#endif
-
-struct pci_controller local_hose;
-
-void tsi108_clear_pci_error (void)
-{
-   u32 err_stat, err_addr, pci_stat;
-
-   /*
-* Quietly clear errors signalled as result of PCI/X configuration read
-* requests.
-*/
-   /* Read PB Error Log Registers */
-   err_stat = *(volatile u32 *)(CONFIG_SYS_TSI108_CSR_BASE +
-TSI108_PB_REG_OFFSET + PB_ERRCS);
-   err_addr = *(volatile u32 *)(CONFIG_SYS_TSI108_CSR_BASE +
-TSI108_PB_REG_OFFSET + PB_AERR);
-   if (err_stat & PB_ERRCS_ES) {
-   /* Clear PCI/X bus errors if applicable */
-   if ((err_addr & 0xFF00) == CONFIG_SYS_PCI_CFG_BASE) {
-   /* Clear error flag */
-   *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE +
- TSI108_PB_REG_OFFSET + PB_ERRCS) =
-   PB_ERRCS_ES;
-
-   /* Clear read error reported in PB_ISR */
-   *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE +
- TSI108_PB_REG_OFFSET + PB_ISR) =
-   PB_ISR_PBS_RD_ERR;
-
-   /* Clear errors reported by PCI CSR (Normally Master Abort) */
-   pci_stat = *(volatile u32 *)(CONFIG_SYS_TSI108_CSR_BASE 
+
-TSI108_PCI_REG_OFFSET +
-PCI_CSR);
-   *(volatile u32 *)(CONFIG_SYS_TSI108_CSR_BASE +
- TSI108_PCI_REG_OFFSET + PCI_CSR) =
-   pci_stat;
-
-   *(volatile u32 *)(CONFIG_SYS_TSI108_CSR_BASE +
- TSI108_PCI_REG_OFFSET +
- PCI_IRP_STAT) = PCI_IRP_STAT_P_CSR;
-   }
-   }
-
-   return;
-}
-
-unsigned int __get_pci_config_dword (u32 addr)
-{
-   unsigned int retval;
-
-   __asm__ __volatile__ ("   lwbrx %0,0,%1\n"
-"1: eieio\n"
-"2:\n"
-".section .fixup,\"ax\"\n"
-"3: li %0,-1\n"
-"   b 2b\n"
-".section __ex_table,\"a\"\n"
-"   .align 2\n"
-"   .long 1b,3b\n"
-".section .text.__get_pci_config_dword"
-   : "=r"(retval) : "r"(addr));
-
-   return (retval);
-}
-
-static int tsi108_read_config_dword (struct pci_controller *hose,
-   pci_dev_t dev, int offset, u32 * value)
-{
-   dev &= (CONFIG_SYS_PCI_CFG_SIZE - 1);
-   dev |= (CONFIG_SYS_PCI_CFG_BASE | (offset & 0xfc));
-   *value = __get_pci_config_dword(dev);
-   if (0x == *value)
-   tsi108_clear_pci_error ();
-   return 0;
-}
-
-static int tsi108_write_config_dword (struct pci_controller *hose,
-pci_dev_t dev, int offset, u32 value)
-{
-   dev &= (CONFIG_SYS_PCI_CFG_SIZE - 1);
-   dev |= (CONFIG_SYS_PCI_CFG_BASE | (offset & 0xfc));
-
-   out_le32 ((volatile unsigned *)dev, value);
-
-   return 0;
-}
-
-void pci_init_board (void)
-{
-   struct pci_controller *hose = (struct pci_controller *)_hose;
-
-   hose->first_busno = 0;
-   hose->last_busno = 0xff;
-
-   pci_set_region (hose->regions + 0,
-  

Re: [U-Boot] Socfpga: configure FPGA to SDRAM interface without reprogramming the FPGA

[Marek Vasut]

On 12/18/2017 09:44 PM, Jan Siegmund wrote:
> Hi all,

Hi,

> Here is another question on the FPGA to SDRAM interface of the Cyclone V SoC.
> Is is possible to configure the the interface in U-Boot or SPL,

What is "the interface" ?

If you mean DRAM, then yes, the CV/AV do _not_ configure the FPGA in SPL
at all. They just configure the IOMUX/clock rings, but that's all.

> without reprogramming the FPGA? Maybe through the usage of the generated
> header files from the Quartus synthesis?
> The SDRAM controller's registers only differ in eight entries in Linux when 
> the
> FPGA is programmed or not.
> 
> +--+-+++
> | address  |name | programmed | not programmed |
> +--+-+++
> | FFC25064 | | 00044003   | 00044FFF   |
> | FFC25068 | | 2C00   | 2C03   |
> | FFC2506c | | 00B0   | 00B3   |
> | FFC25070 | | 0076   | 0076   |
> | FFC25074 | | 0098   | 0098   |
> | FFC25078 | | 0005A003   | 0005AFFF   |
> | FFC2507c | portcfg |    | 003F   |
> | FFC25080 | fpgaportrst | 01FF   |    |
> +--+-+++
> 
> The registers 0xFFC25064-0xFFC25078 don't show up on the HPS' memory map
> [1], so are they even intended to be configured?
> 
> Thanks
> 
> 
> 
> [1]
> https://www.altera.com/hps/cyclone-v/hps.html#topic/sfo1411577380716.html#sfo1411577380716
> 


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

Re: [U-Boot] Anyone using recentish u-boot on a GuruPlug?

[Chris Packham]

Hi Martin,

On Mon, Dec 18, 2017 at 8:35 AM, Martin Husemann  wrote:
> I tested the RAM version now and indeed it does not work either.
>
> With my old u-boot I get:
>
> U-Boot 2013.10 (Oct 21 2013 - 20:54:41)
> Marvell-GuruPlug
>
> SoC:   Kirkwood 88F6281_A1
> DRAM:  512 MiB
> WARNING: Caches not enabled
> NAND:  512 MiB
> In:serial
> Out:   serial
> Err:   serial
> Net:   egiga0, egiga1
> Warning: failed to set MAC address
>
> 88E1121 Initialized on egiga0
> 88E1121 Initialized on egiga1
> Hit any key to stop autoboot:  3
>
>
> while the new one:
>
> U-Boot 2017.11 (Dec 05 2017 - 14:52:54 +0100)
> Marvell-GuruPlug
>
> SoC:   Kirkwood 88F6281_A1
> DRAM:  512 MiB
> WARNING: Caches not enabled
> NAND:  <--- hangs here
>
>
> Anyone got an idea where to look?
>

I've got a couple of out-of-tree boards using Kirkwood SoCs (or
equivalent integrated). One even uses NAND. I've just tried that board
on top of 2017.11 and it boots and detects NAND (at least when loaded
into RAM). I can't try u-boot/master because I haven't got myself a
gcc > 6 toolchain yet.

In terms of differences between configs between my board and guruplug
I don't see anything that stands out.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Socfpga: configure FPGA to SDRAM interface without reprogramming the FPGA

[Jan Siegmund]

Hi all,
Here is another question on the FPGA to SDRAM interface of the Cyclone V SoC.
Is is possible to configure the the interface in U-Boot or SPL,
without reprogramming the FPGA? Maybe through the usage of the generated
header files from the Quartus synthesis?
The SDRAM controller's registers only differ in eight entries in Linux when the
FPGA is programmed or not.

+--+-+++
| address  |name | programmed | not programmed |
+--+-+++
| FFC25064 | | 00044003   | 00044FFF   |
| FFC25068 | | 2C00   | 2C03   |
| FFC2506c | | 00B0   | 00B3   |
| FFC25070 | | 0076   | 0076   |
| FFC25074 | | 0098   | 0098   |
| FFC25078 | | 0005A003   | 0005AFFF   |
| FFC2507c | portcfg |    | 003F   |
| FFC25080 | fpgaportrst | 01FF   |    |
+--+-+++

The registers 0xFFC25064-0xFFC25078 don't show up on the HPS' memory map
[1], so are they even intended to be configured?

Thanks



[1]
https://www.altera.com/hps/cyclone-v/hps.html#topic/sfo1411577380716.html#sfo1411577380716
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] ARM: sunxi: Enable DM MMC+SATA for the PcDuino3 Nano board

[Tuomas Tynkkynen]

After the previous commit which adds support for the cd-inverted
property to the sunxi MMC driver, driver-model MMC works fine on this
board.

Signed-off-by: Tuomas Tynkkynen 
---
 configs/Linksprite_pcDuino3_Nano_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/Linksprite_pcDuino3_Nano_defconfig 
b/configs/Linksprite_pcDuino3_Nano_defconfig
index 13538fafd1..44ce8b3ead 100644
--- a/configs/Linksprite_pcDuino3_Nano_defconfig
+++ b/configs/Linksprite_pcDuino3_Nano_defconfig
@@ -17,9 +17,11 @@ CONFIG_SPL_I2C_SUPPORT=y
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_SCSI_AHCI=y
+CONFIG_DM_MMC=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_RGMII=y
 CONFIG_SUN7I_GMAC=y
 CONFIG_SCSI=y
+CONFIG_DM_SCSI=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
-- 
2.15.0

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

[U-Boot] [PATCH 1/2] mmc: sunxi: Support cd-inverted DT property

[Tuomas Tynkkynen]

Commit 8620f384098b ("dm: sunxi: Linksprite_pcDuino3: Correct polarity
of MMC card detect") claims that the Pcduino3 device tree has an
incorrect polarity for the card detect pin, but the actual problem is
that unlike the Linux MMC driver, the U-Boot driver isn't respecting the
cd-invert property (see Documentation/devicetree/bindings/mmc/mmc.txt)
which tells that the card detect signal level should be inverted.

Fix this properly by adding support for the cd-inverted property while
reverting the original commit at the same time. While at it, I noticed
the driver always enables pullups for the card detect line, which is not
right if the card detect GPIO is active-high, so fix that as well.

Signed-off-by: Tuomas Tynkkynen 
---
 arch/arm/dts/sun7i-a20-pcduino3.dts |  2 +-
 drivers/mmc/sunxi_mmc.c | 12 ++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/sun7i-a20-pcduino3.dts 
b/arch/arm/dts/sun7i-a20-pcduino3.dts
index 37b1e0ee9b..1a8b39be1d 100644
--- a/arch/arm/dts/sun7i-a20-pcduino3.dts
+++ b/arch/arm/dts/sun7i-a20-pcduino3.dts
@@ -164,7 +164,7 @@
pinctrl-0 = <_pins_a>, <_cd_pin_reference_design>;
vmmc-supply = <_vcc3v3>;
bus-width = <4>;
-   cd-gpios = < 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
+   cd-gpios = < 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
cd-inverted;
status = "okay";
 };
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 4edb4be46c..7cc7303570 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -30,6 +30,7 @@ struct sunxi_mmc_priv {
uint32_t *mclkreg;
unsigned fatal_err;
struct gpio_desc cd_gpio;   /* Change Detect GPIO */
+   int cd_inverted;
struct sunxi_mmc *reg;
struct mmc_config cfg;
 };
@@ -545,7 +546,7 @@ static int sunxi_mmc_getcd(struct udevice *dev)
struct sunxi_mmc_priv *priv = dev_get_priv(dev);
 
if (dm_gpio_is_valid(>cd_gpio))
-   return dm_gpio_get_value(>cd_gpio);
+   return dm_gpio_get_value(>cd_gpio) ^ priv->cd_inverted;
 
return 1;
 }
@@ -606,8 +607,15 @@ static int sunxi_mmc_probe(struct udevice *dev)
if (!gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
  GPIOD_IS_IN)) {
int cd_pin = gpio_get_number(>cd_gpio);
+   int cd_state = priv->cd_gpio.flags & GPIOD_ACTIVE_LOW ? 0 : 1;
 
-   sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP);
+   priv->cd_inverted = dev_read_bool(dev, "cd-inverted");
+   cd_state ^= priv->cd_inverted;
+
+   if (cd_state)
+   sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_DOWN);
+   else
+   sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP);
}
 
upriv->mmc = >mmc;
-- 
2.15.0

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

Re: [U-Boot] [PATCH v2 7/8] db410c: configs: increase max kernel size

[Jorge Ramirez]

On 12/18/2017 08:31 PM, Tom Rini wrote:

On Thu, Dec 14, 2017 at 02:26:59PM +0100, Jorge Ramirez-Ortiz wrote:


the kernel fails to boot when it goes over the limit.

Signed-off-by: Jorge Ramirez-Ortiz 
---
  include/configs/dragonboard410c.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/dragonboard410c.h 
b/include/configs/dragonboard410c.h
index d2447b2..fdfac27 100644
--- a/include/configs/dragonboard410c.h
+++ b/include/configs/dragonboard410c.h
@@ -23,7 +23,7 @@
  #define CONFIG_SYS_TEXT_BASE  0x8008
  #define CONFIG_SYS_INIT_SP_ADDR   (CONFIG_SYS_SDRAM_BASE + 
0x7fff0)
  #define CONFIG_SYS_LOAD_ADDR  (CONFIG_SYS_SDRAM_BASE + 0x8)
-#define CONFIG_SYS_BOOTM_LEN   0x100 /* 16MB max kernel size */
+#define CONFIG_SYS_BOOTM_LEN   0x140 /* 20MB max kernel size */

This small of a size tweak is just begging to be hit within a year.  Can
we raise this to something closer to the aarch64 limit for an Image?  Or
if not, 32 or 64MB?


yeah I just picked 0x140 since that is what I used in poplar as well 
but sure, I'll set it to 64MB like rockchip and other platforms.







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

Re: [U-Boot] [PATCH 12/13] ARM: dts: am574x-idk: Add initial support

[Tom Rini]

On Mon, Dec 18, 2017 at 03:04:24PM +0530, Lokesh Vutla wrote:

> Add initial dts support for am574x-idk
> 
> Signed-off-by: Lokesh Vutla 
> ---
> - DTS patch posted to kernel: https://patchwork.kernel.org/patch/10118295/
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/am572x-idk-common.dtsi   | 100 
> ++
>  arch/arm/dts/am572x-idk.dts   |  93 +--
>  arch/arm/dts/am574x-idk.dts   |  22 +++
>  arch/arm/dts/am57xx-commercial-grade.dtsi |   1 +
>  arch/arm/dts/am57xx-industrial-grade.dtsi |   1 +
>  configs/am57xx_evm_defconfig  |   2 +-
>  configs/am57xx_hs_evm_defconfig   |   2 +-
>  8 files changed, 128 insertions(+), 94 deletions(-)
>  create mode 100644 arch/arm/dts/am572x-idk-common.dtsi
>  create mode 100644 arch/arm/dts/am574x-idk.dts

What's the status of these DTS/DTSI files wrt the kernel?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 04/13] arm: keystone: Move cmd_ddr3 to a common place

[Tom Rini]

On Mon, Dec 18, 2017 at 03:04:16PM +0530, Lokesh Vutla wrote:

> Move cmd_ddr3 to board/ti/common/ in order to make
> it build for non-keystone TI platforms.
> 
> Signed-off-by: Lokesh Vutla 
[snip]
> diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
> index 7170eac81e..66025040bc 100644
> --- a/board/ti/common/Makefile
> +++ b/board/ti/common/Makefile
> @@ -4,3 +4,6 @@
>  #
>  
>  obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
> +ifndef CONFIG_SPL_BUILD
> +obj-${CONFIG_CMD_DDR3} += cmd_ddr3.o
> +endif

We shouldn't need games like that now to have all strings be discarded,
now that we're mandating gcc-6 or later.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 7/8] db410c: configs: increase max kernel size

[Tom Rini]

On Thu, Dec 14, 2017 at 02:26:59PM +0100, Jorge Ramirez-Ortiz wrote:

> the kernel fails to boot when it goes over the limit.
> 
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
>  include/configs/dragonboard410c.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/dragonboard410c.h 
> b/include/configs/dragonboard410c.h
> index d2447b2..fdfac27 100644
> --- a/include/configs/dragonboard410c.h
> +++ b/include/configs/dragonboard410c.h
> @@ -23,7 +23,7 @@
>  #define CONFIG_SYS_TEXT_BASE 0x8008
>  #define CONFIG_SYS_INIT_SP_ADDR  (CONFIG_SYS_SDRAM_BASE + 
> 0x7fff0)
>  #define CONFIG_SYS_LOAD_ADDR (CONFIG_SYS_SDRAM_BASE + 0x8)
> -#define CONFIG_SYS_BOOTM_LEN 0x100 /* 16MB max kernel size */
> +#define CONFIG_SYS_BOOTM_LEN 0x140 /* 20MB max kernel size */

This small of a size tweak is just begging to be hit within a year.  Can
we raise this to something closer to the aarch64 limit for an Image?  Or
if not, 32 or 64MB?

-- 
Tom


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

Re: [U-Boot] SPI Slave mode Device Tree

[Fabio Estevam]

Hi Amartya,

On Mon, Dec 18, 2017 at 8:25 AM, Amartya Shreyank (RBEI/ESD2)
 wrote:
> Hi,
>
> While going over device tree binding documentation I came across this:
>
> /doc/device-tree-bindins/spi/spi-bus.txt: "This binding does not describe SPI 
> controllers in slave mode."
>
> Does this mean I cannot use device tree in case I want to configure the 
> controller as SPI slave?
> If yes, please suggest how can I configure it as a SPI slave.
> I'm using a imx6solo based custom board.

Yes, we do not have SPI slave support in U-Boot.

drivers/spi/spi-imx.c from mainline kernel is capable of supporting
SPI slave though.

BTW, any chance of fixing the issue you pointed out last week about
the usage of an inconrrect function inside SPI imx U-Boot driver?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] config: Enable part command for socfpga platform

[Andrey Zhizhikin]

Hello Marek,

On Mon, Dec 18, 2017 at 12:39 PM, Marek Vasut  wrote:
> On 12/18/2017 12:10 PM, Andrey Zhizhikin wrote:
>> Enable CONFIG_CMD_PART item, as default environment requires it
>> and complains this command in unknown.
>
> Fine by me, but what about the other boards, don't they need this as well ?

I'd say this is applicable to other boards in socfpga family as well.
The only reason I didn't include them as well into this commit is I
don't have those boards on hands to perform verification. But I can
assume since a lot of people uses ENV files to overwrite defaults -
this should not affect anyone. Please let me know what you think, and
I can re-submit this patch to include part command in all socfpga
family configs.

>
> btw diffstat is missing and the tags are wrong (should be ARM:
> socfpga:). I can fix those up, but see my question above...
>

Thanks a lot for pointing this out! I quickly checked the log on those
files, and missed those points out... If you would agree on my
proposal below, then I get those resolved as well.

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

[U-Boot] [PATCH] ARM: socfpga: Enable part command for socfpga platform

[Andrey Zhizhikin]

Enable CONFIG_CMD_PART item, as default environment requires it
and complains this command in unknown.

Signed-off-by: Andrey Zhizhikin 
---
 configs/socfpga_arria10_defconfig  | 1 +
 configs/socfpga_arria5_defconfig   | 1 +
 configs/socfpga_cyclone5_defconfig | 1 +
 configs/socfpga_de0_nano_soc_defconfig | 1 +
 configs/socfpga_de10_nano_defconfig| 1 +
 configs/socfpga_de1_soc_defconfig  | 1 +
 configs/socfpga_is1_defconfig  | 1 +
 configs/socfpga_mcvevk_defconfig   | 1 +
 configs/socfpga_sockit_defconfig   | 1 +
 configs/socfpga_socrates_defconfig | 1 +
 configs/socfpga_sr1500_defconfig   | 1 +
 configs/socfpga_vining_fpga_defconfig  | 1 +
 12 files changed, 12 insertions(+)

diff --git a/configs/socfpga_arria10_defconfig 
b/configs/socfpga_arria10_defconfig
index f7bcce3..0b3ec11 100644
--- a/configs/socfpga_arria10_defconfig
+++ b/configs/socfpga_arria10_defconfig
@@ -20,6 +20,7 @@ CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 CONFIG_DOS_PARTITION=y
 # CONFIG_SPL_DOS_PARTITION is not set
diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig
index 8ed6169..2685881 100644
--- a/configs/socfpga_arria5_defconfig
+++ b/configs/socfpga_arria5_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
 CONFIG_CMD_UBI=y
diff --git a/configs/socfpga_cyclone5_defconfig 
b/configs/socfpga_cyclone5_defconfig
index 54c3495..f49d0ab 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
 CONFIG_CMD_UBI=y
diff --git a/configs/socfpga_de0_nano_soc_defconfig 
b/configs/socfpga_de0_nano_soc_defconfig
index 2787b60..59b2dcf 100644
--- a/configs/socfpga_de0_nano_soc_defconfig
+++ b/configs/socfpga_de0_nano_soc_defconfig
@@ -37,6 +37,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
 CONFIG_CMD_UBI=y
diff --git a/configs/socfpga_de10_nano_defconfig 
b/configs/socfpga_de10_nano_defconfig
index ecf6de3..17780af 100644
--- a/configs/socfpga_de10_nano_defconfig
+++ b/configs/socfpga_de10_nano_defconfig
@@ -34,6 +34,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SPL_DM=y
diff --git a/configs/socfpga_de1_soc_defconfig 
b/configs/socfpga_de1_soc_defconfig
index 97a6c5e..d4ceb92 100644
--- a/configs/socfpga_de1_soc_defconfig
+++ b/configs/socfpga_de1_soc_defconfig
@@ -36,6 +36,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SPL_DM=y
diff --git a/configs/socfpga_is1_defconfig b/configs/socfpga_is1_defconfig
index bba90d9..10f0c82 100644
--- a/configs/socfpga_is1_defconfig
+++ b/configs/socfpga_is1_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
 CONFIG_CMD_UBI=y
diff --git a/configs/socfpga_mcvevk_defconfig b/configs/socfpga_mcvevk_defconfig
index 5bae037..ed057cf 100644
--- a/configs/socfpga_mcvevk_defconfig
+++ b/configs/socfpga_mcvevk_defconfig
@@ -36,6 +36,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
 CONFIG_CMD_UBI=y
diff --git a/configs/socfpga_sockit_defconfig b/configs/socfpga_sockit_defconfig
index 079d465..857f2f7 100644
--- a/configs/socfpga_sockit_defconfig
+++ b/configs/socfpga_sockit_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
 

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Patrick Brünn]

>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Montag, 18. Dezember 2017 11:57
>On 12/18/2017 11:47 AM, Patrick Brünn wrote:
>>> From: Marek Vasut [mailto:ma...@denx.de]
>>> Sent: Montag, 18. Dezember 2017 10:17
>>> On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote:
 From: Patrick Bruenn 

 Static variables are not available during board_init_f().
>>>
>>> They are, since the board runs from RAM at that point already.
>>>
>> From reading the README and common/board_f.c I got the impression,
>> that dram_init() is called before it's save to access mx53_dram_size.
>> And as that change seemed to cure the strange behavior I described
>> in [1] and [2], I prepared a patch for my board, which ended up to be
>> requested for m53evk and mx53loco, too.
>
>Technically yes, board_init_f means it runs from FLASH and has no or
>minimal storage available. On the MX53 with SPL, it's running from RAM
>so it's safe to use static variables too.
>
Thank's for your explanation.

 'static uint32_t mx53_dram_size[2];' was used in board specific
 dram_init(), dram_init_banksize() and get_effective_memsize() to avoid
 multiple calls to get_ram_size().

 Reused dram initialization functions from arch/arm/mach-
>>> imx/mx5/mx53_dram.c

 Signed-off-by: Patrick Bruenn 

 ---

 Changes in v2: None


 Only compile tested with make m53evk_defconfig
>>>
>>> Are you sure this patch retains the original functionality ? Note the
>>> warning ...
>>
>> Effectively it changes:
>>  -  return mx53_dram_size[0];
>> +   return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
>>
>> So, yes I am convinced that get_effective_memsize() still returns only the
>size
>> of the first dram bank.
>
>I suspect that will fails on M53 due to it's split-bank configuration.
>The board has two DRAM banks with a hole between them.
>
This is how mx53_dram_size was initialized on m53 before that patch:
-   mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
-   mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, 1 << 30);

So to me that's, absolutely the same. With the only difference, that 
get_ram_size(bank0)
is called multiple times, now.
>> However, I would be fine with just keeping the changes to my board
>(cx9020).
>> And if anyone has a better idea of what might be the root cause of [1] and
>[2],
>> I would absolute appreciate any input to that.
>
>If your board also has two DRAM banks with a hole between them and you
>can test if this works fine, then I'm OK with this change.
>
Yes, cx9020 uses two 512MB banks with 1GB between PHYS_SDRAM_1/2, too.

>> Best regards and thanks in advance for any feedback,
>> Patrick
>>
>> [1] https://lists.denx.de/pipermail/u-boot/2017-November/313214.html
>> [2] https://lists.denx.de/pipermail/u-boot/2017-December/314480.html
>>
>> ---
>> Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans
>Beckhoff
>> Registered office: Verl, Germany | Register court: Guetersloh HRA 7075
>>
>>
>
>
>--
>Best regards,
>Marek Vasut
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] [PULL] efi patch queue 2017-12-17

[Emmanuel Vadot]

On Mon, 18 Dec 2017 23:29:27 +1100
Jonathan Gray  wrote:

> On Sun, Dec 17, 2017 at 09:33:44PM +0100, Alexander Graf wrote:
> > Hi Tom,
> > 
> > This is my current patch queue for efi.  Please pull.
> > 
> > Alex
> > 
> > 
> > The following changes since commit 15616a0aa58173bce1efe47569bf2e10d023ae9c:
> > 
> >   Merge git://git.denx.de/u-boot-dm (2017-12-14 15:46:07 -0500)
> > 
> > are available in the git repository at:
> > 
> >   git://github.com/agraf/u-boot.git tags/signed-efi-v2018.01
> > 
> > for you to fetch changes up to bde6bfe4c3234480a0eef3b5bda8cf5fc83d3c79:
> > 
> >   efi_loader: comments for dp_part_fill() (2017-12-16 23:07:56 +0100)
> > 
> > 
> > Patch queue for efi - 2017-12-17
> > 
> > A few fixes for 2018.01:
> > 
> >   - Compile fix with helloworld example
> >   - DP match fix (fixes FreeBSD loader and grub on block storage)
> 
> This was for the OpenBSD bootloader, FreeBSD has a different one.
> I'd test again but am away from hardware for a few days.

 This was for every bootloaders, it just fixes FreeBSD's, OpenBSD's and
Grub :)

> >   - More DP fixes for SD, block
> >   - Fix use-after-free
> > 
> > 
> > Alexander Graf (3):
> >   efi_loader: helloworld.c: Explicitly use .rodata for loaded_image_guid
> >   efi_loader: helloworld.c: Reduce file size
> >   efi_loader: Ensure efi_dp_find_obj() finds exact matches
> > 
> > Heinrich Schuchardt (7):
> >   efi_loader: return status from efi_setup_loaded_image()
> >   efi_loader: new function efi_delete_handle()
> >   efi_loader: error handling in efi_load_image()
> >   efi_loader: correctly determine if an MMC device is an SD-card
> >   efi_loader: correctly setup device paths for block devices
> >   efi_loader: correct DeviceNodeToText for media types
> >   efi_loader: comments for dp_part_fill()
> > 
> >  arch/arm/lib/elf_arm_efi.lds |  11 +-
> >  include/efi_loader.h |  10 +-
> >  lib/efi_loader/efi_boottime.c| 228 
> > +--
> >  lib/efi_loader/efi_device_path.c |  56 ++--
> >  lib/efi_loader/efi_device_path_to_text.c |  43 --
> >  lib/efi_loader/helloworld.c  |   3 +-
> >  6 files changed, 214 insertions(+), 137 deletions(-)
> > ___
> > 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


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

[U-Boot] [PATCH] config: Enable part command for socfpga platform

[Andrey Zhizhikin]

Enable CONFIG_CMD_PART item, as default environment requires it
and complains this command in unknown.

Signed-off-by: Andrey Zhizhikin 

diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig
index 8ed6169..2685881 100644
--- a/configs/socfpga_arria5_defconfig
+++ b/configs/socfpga_arria5_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
 CONFIG_CMD_UBI=y
diff --git a/configs/socfpga_cyclone5_defconfig 
b/configs/socfpga_cyclone5_defconfig
index 54c3495..f49d0ab 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
 CONFIG_CMD_UBI=y
diff --git a/configs/socfpga_sockit_defconfig b/configs/socfpga_sockit_defconfig
index 079d465..857f2f7 100644
--- a/configs/socfpga_sockit_defconfig
+++ b/configs/socfpga_sockit_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
 CONFIG_CMD_UBI=y
diff --git a/configs/socfpga_socrates_defconfig 
b/configs/socfpga_socrates_defconfig
index 35773e6..71bd8f1 100644
--- a/configs/socfpga_socrates_defconfig
+++ b/configs/socfpga_socrates_defconfig
@@ -36,6 +36,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
 CONFIG_CMD_UBI=y
-- 
2.7.4

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

Re: [U-Boot] [PATCH] arm: imx: cx9020: remove usage of mx53_dram_size

[Patrick Brünn]

Hi Lothar,
>From: Lothar Waßmann [mailto:l...@karo-electronics.de]
>Sent: Freitag, 15. Dezember 2017 15:02
>
>Hi,
>
>On Fri, 15 Dec 2017 13:56:15 +0100 linux-kernel-...@beckhoff.com wrote:
>> From: Patrick Bruenn 
>>
>> Global variables are not available during board_init_f().
>>
>s/Global/static/
>
I fixed that for v2. Unfortunately everywhere but in the cover letter :-(.

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Patrick Brünn]

>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Montag, 18. Dezember 2017 12:52
>On 12/18/2017 12:40 PM, Patrick Brünn wrote:
>>> From: Marek Vasut [mailto:ma...@denx.de]
>>> Sent: Montag, 18. Dezember 2017 11:57
>>> On 12/18/2017 11:47 AM, Patrick Brünn wrote:
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Montag, 18. Dezember 2017 10:17
> On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote:
>> From: Patrick Bruenn 
>>
>> 'static uint32_t mx53_dram_size[2];' was used in board specific
>> dram_init(), dram_init_banksize() and get_effective_memsize() to
>avoid
>> multiple calls to get_ram_size().
>>
>> Reused dram initialization functions from arch/arm/mach-
> imx/mx5/mx53_dram.c
>>
>> Signed-off-by: Patrick Bruenn 
>>
>> ---
>>
>> Changes in v2: None
>>
>>
>> Only compile tested with make m53evk_defconfig
>
> Are you sure this patch retains the original functionality ? Note the
> warning ...

 Effectively it changes:
  -  return mx53_dram_size[0];
 +   return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);

 So, yes I am convinced that get_effective_memsize() still returns only the
>>> size
 of the first dram bank.
>>>
>>> I suspect that will fails on M53 due to it's split-bank configuration.
>>> The board has two DRAM banks with a hole between them.
>>>
>> This is how mx53_dram_size was initialized on m53 before that patch:
>> -   mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
>> -   mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, 1 << 30);
>>
>> So to me that's, absolutely the same. With the only difference, that
>get_ram_size(bank0)
>> is called multiple times, now.
>
>The get_ram_size() above is called for two different bank (addresses),
>not for bank0 twice. Maybe I'm missing something.
>
>btw where's the patch adding mx53_dram.c ? I don't see it in mainline yet.
>
It's #2 of this series:
https://lists.denx.de/pipermail/u-boot/2017-December/314742.html

 However, I would be fine with just keeping the changes to my board
>>> (cx9020).
 And if anyone has a better idea of what might be the root cause of [1]
>and
>>> [2],
 I would absolute appreciate any input to that.
>>>
>>> If your board also has two DRAM banks with a hole between them and you
>>> can test if this works fine, then I'm OK with this change.
>>>
>> Yes, cx9020 uses two 512MB banks with 1GB between PHYS_SDRAM_1/2,
>too.
>
>Then that should be the same situation. Can you share "bdinfo" from that
>board of yours?
>
=> bdinfo
arch_number = 0x
boot_params = 0x7100
DRAM bank   = 0x
-> start= 0x7000
-> size = 0x2000
DRAM bank   = 0x0001
-> start= 0xB000
-> size = 0x2000
eth0name= FEC
ethaddr = 00:01:05:23:87:85
current eth = FEC
ip_addr = 
baudrate= 115200 bps
TLB addr= 0x8FFF
relocaddr   = 0x8FF8B000
reloc off   = 0x1878B000
irq_sp  = 0x8F586960
sp start= 0x8F586950
FB base = 0x8F58C7C0
Early malloc usage: 134 / 400
fdt_blob = 8f586978

>btw do you use SPL ? If not, you should ...
I will read more about SPL. Until now, I thought I will only benefit,
if my initial boot media is limited in size. As we boot from sdcard,
that wasn't a problem to store 360k u-boot.

Regards,
Patrick
---
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

[U-Boot] SPI Slave mode Device Tree

[Amartya Shreyank (RBEI/ESD2)]

Hi,

While going over device tree binding documentation I came across this:

/doc/device-tree-bindins/spi/spi-bus.txt: "This binding does not describe SPI 
controllers in slave mode."

Does this mean I cannot use device tree in case I want to configure the 
controller as SPI slave?
If yes, please suggest how can I configure it as a SPI slave.
I'm using a imx6solo based custom board.

Best regards,

Shreyank Amartya
RBEI/ESD2


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

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Patrick Brünn]

>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Montag, 18. Dezember 2017 10:17
>On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote:
>> From: Patrick Bruenn 
>>
>> Static variables are not available during board_init_f().
>
>They are, since the board runs from RAM at that point already.
>
From reading the README and common/board_f.c I got the impression,
that dram_init() is called before it's save to access mx53_dram_size.
And as that change seemed to cure the strange behavior I described
in [1] and [2], I prepared a patch for my board, which ended up to be
requested for m53evk and mx53loco, too.

>> 'static uint32_t mx53_dram_size[2];' was used in board specific
>> dram_init(), dram_init_banksize() and get_effective_memsize() to avoid
>> multiple calls to get_ram_size().
>>
>> Reused dram initialization functions from arch/arm/mach-
>imx/mx5/mx53_dram.c
>>
>> Signed-off-by: Patrick Bruenn 
>>
>> ---
>>
>> Changes in v2: None
>>
>>
>> Only compile tested with make m53evk_defconfig
>
>Are you sure this patch retains the original functionality ? Note the
>warning ...

Effectively it changes:
 -  return mx53_dram_size[0];
+   return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);

So, yes I am convinced that get_effective_memsize() still returns only the size
of the first dram bank.
However, I would be fine with just keeping the changes to my board (cx9020).
And if anyone has a better idea of what might be the root cause of [1] and [2],
I would absolute appreciate any input to that.

Best regards and thanks in advance for any feedback,
Patrick

[1] https://lists.denx.de/pipermail/u-boot/2017-November/313214.html
[2] https://lists.denx.de/pipermail/u-boot/2017-December/314480.html

---
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

[U-Boot] [PATCH] BCM283x ALT5 function for JTAG pins

[henryzhang62]

From: Henry Zhang 

BCM2835 ARM Peripherals doc shows gpio pins 4, 5, 6, 12 and 13 carry altenate
function, ALT5 for ARM JTAG

Signed-off-by: Henry Zhang 
---
 arch/arm/dts/bcm283x.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/bcm283x.dtsi b/arch/arm/dts/bcm283x.dtsi
index 05a6f48..e45ba58 100644
--- a/arch/arm/dts/bcm283x.dtsi
+++ b/arch/arm/dts/bcm283x.dtsi
@@ -246,7 +246,7 @@
 
jtag_gpio4: jtag_gpio4 {
brcm,pins = <4 5 6 12 13>;
-   brcm,function = ;
+   brcm,function = ;
};
jtag_gpio22: jtag_gpio22 {
brcm,pins = <22 23 24 25 26 27>;
-- 
1.7.9.5

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

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

[Tom Rini]

On Sun, Dec 17, 2017 at 10:50:49PM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx ("power: pmic/regulator allow dm be omitted
> by SPL" dropped), thanks !
> 
> The following changes since commit fcc8250c2f7c982f3593a8eecf737f8e2c95f222:
> 
>   Merge git://git.denx.de/u-boot-mips (2017-11-28 16:54:30 -0500)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 7efc2dbfb2fa04bd4111615a8afb0822d6b88b09:
> 
>   arm: imx: add tzic interrupt controller for imx53 (2017-12-17 22:34:01
> +0100)
> 
> 
[snip]
> Hannu Lounento (5):
>   net: e1000: add support for writing to EEPROM
>   net: e1000: split e1000_read_mac_addr
>   net: e1000: implement eth_write_hwaddr
>   board: ge: bx50v3: program MAC address to I210

This first patch adds a bunch of warnings about
e1000_update_eeprom_checksum_i210 being declared static and unused.
It's unused in the case of DM_ETH being set because we don't have
e1000_initialize and company compiled in, and thus no e1000_write_hwaddr
and thus no callers of e1000_update_eeprom_checksum_i210.  Given that I
see on my calendar a reminder that in early 2018 I need to make a lack
of DM conversion of $X a lot louder of warning, are these 4 things
imporant fixes that must come in now, or something that can be baked a
bit longer?

To see the warnings, build for say qemu-x86_64.  Thanks!

-- 
Tom


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

[U-Boot] Please pull u-boot-fsl-qoriq master

[York Sun]

Tom,

The following changes since commit cf71338ee7a1dc16f13a4f1b89f32c624210df45:

  ata: Migrate CONFIG_MVSATA_IDE to Kconfig (2017-12-12 18:16:06 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-fsl-qoriq.git

for you to fetch changes up to 1b7910a37ccc889e1b58a5f6e095a39728564bb8:

  armv8: ls1046aqds: Adjust IFC timing for NOR flash (2017-12-18
08:25:07 -0800)


Rajesh Bhagat (2):
  arm64: ls1012ardb: Add distro boot support
  arm64: ls1012afrdm: Add distro boot support

Wenbin song (2):
  armv8: ls1043a/ls2080a: check SoC by device ID
  armv8: layerscape: Discard the needless cpu nodes

Yangbo Lu (4):
  armv8: ls1088ardb: support force SDHC mode by hwconfig
  armv8: ls1012ardb: clean up definitions for I2C IO expanders
  armv8: ls1012ardb: add more board version information
  armv8: ls1012ardb: support hwconfig for eSDHC1 enabling

Yogesh Gaur (1):
  board/ls2080a, ls1088a: Add check for mc-dpl applied in fdt

York Sun (3):
  armv8: ls2080a: Increase load image len for NAND boot
  armv8: ls2085a: Update README file for NAND boot
  armv8: ls1046aqds: Adjust IFC timing for NOR flash

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  8 +-
 arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3 |  8 +-
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c| 31 +++-
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |  9 +--
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |  4 +-
 board/freescale/ls1012ardb/ls1012ardb.c| 89
+++---
 board/freescale/ls1088a/ls1088a.c  | 20 -
 board/freescale/ls1088a/ls1088a_qixis.h|  6 ++
 board/freescale/ls2080a/ls2080a.c  |  2 +-
 board/freescale/ls2080aqds/ls2080aqds.c|  2 +-
 board/freescale/ls2080ardb/ls2080ardb.c|  2 +-
 configs/ls1012afrdm_qspi_defconfig |  1 +
 configs/ls1012ardb_qspi_defconfig  |  1 +
 drivers/net/fsl-mc/dpio/qbman_private.h|  4 +-
 drivers/usb/common/fsl-errata.c|  7 +-
 include/configs/ls1012a_common.h   | 10 ++-
 include/configs/ls1012afrdm.h  | 57 +++---
 include/configs/ls1012ardb.h   | 66 ++--
 include/configs/ls1046aqds.h   |  5 +-
 include/configs/ls1088ardb.h   |  2 +
 include/configs/ls2080a_common.h   |  2 +-
 21 files changed, 264 insertions(+), 72 deletions(-)

Thanks.

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

Re: [U-Boot] [U-Boot, v3, 1/3] rockchip: add a common script for generate fit its

[Philipp Tomsich]

> Rockchip release bl31.elf file for armv8 SoCs like rk3399, rk3328,
> the elf have more than one section, we need to decode it first and
> packed them into u-boot.itb with its file. This script is to generate
> the its script.
> Need default bl31.elf in root directory of U-Boot source and dtb
> as parameter.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - use python script
> - adapt for latest spl atf support
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/make_fit_atf.py | 221 
> +
>  1 file changed, 221 insertions(+)
>  create mode 100755 arch/arm/mach-rockchip/make_fit_atf.py
> 

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

Re: [U-Boot] [U-Boot, v3, 3/3] rockchip: evb-rk3399: update document for board bring up

[Philipp Tomsich]

> Since we support ATF in SPL and add script for it, let's make the
> document up to date.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - update addr for uboot.itb to 0x4000
> 
> Changes in v2:
> - typo fix, evb-firefly－>firefly-rk3399
> 
>  board/rockchip/evb_rk3399/README | 83 
> +++-
>  1 file changed, 65 insertions(+), 18 deletions(-)
> 

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

Re: [U-Boot] [U-Boot, v3, 2/3] rockchip: firefly-rk3399: add FIT for rk3399

[Philipp Tomsich]

> Enable SPL_FIT_GENERATOR with path for it.
> With this patch you can get u-boot.itb for rk3399-firefly with:
> > make u-boot.itb
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Mark Kettenis 
> Tested-by: Mark Kettenis 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - update with new script path
> 
> Changes in v2:
> - typo fix, rk3399-evb->rk3399-firefly
> 
>  configs/firefly-rk3399_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 

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

Re: [U-Boot] [U-Boot, v3, 2/3] rockchip: firefly-rk3399: add FIT for rk3399

[Philipp Tomsich]

> Enable SPL_FIT_GENERATOR with path for it.
> With this patch you can get u-boot.itb for rk3399-firefly with:
> > make u-boot.itb
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Mark Kettenis 
> Tested-by: Mark Kettenis 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - update with new script path
> 
> Changes in v2:
> - typo fix, rk3399-evb->rk3399-firefly
> 
>  configs/firefly-rk3399_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 

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

Re: [U-Boot] [U-Boot, v3, 3/3] rockchip: evb-rk3399: update document for board bring up

[Philipp Tomsich]

> Since we support ATF in SPL and add script for it, let's make the
> document up to date.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - update addr for uboot.itb to 0x4000
> 
> Changes in v2:
> - typo fix, evb-firefly－>firefly-rk3399
> 
>  board/rockchip/evb_rk3399/README | 83 
> +++-
>  1 file changed, 65 insertions(+), 18 deletions(-)
> 

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

Re: [U-Boot] [U-Boot,v2] rockchip: update boot0 hook

[Philipp Tomsich]

> Rockchip SoCs only need boot0 hook at SPL, and the U-Boot proper do not
> need it.
> 
> The very beginning of U-Boot proper is different between armv7 and armv8:
> armv7 start with ARM_VECTORS while armv8 start with 'b reset'.
> 
> Here is the map of very beginning for all cases:
> armv7 SPL: TAG(overwrite 'b 1f')+'b reset' + ARM_VECTORS
> armv7 U-Boot: ARM_VECTORS
> armv8 SPL: TAG(overwrite 'b 1f')+'b reset' + Reserved_iram(rk3399)
> armv8 U-Boot: 'b reset'
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v2:
> - update commit message
> 
>  arch/arm/include/asm/arch-rockchip/boot0.h | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 

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

Re: [U-Boot] rockchip: config: update part table

[Philipp Tomsich]

> User do not need to access the reserved part in system, remove them
> from partition table.
> Rename atf to trust as generic name for armv7 do not use ATF.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  include/configs/rockchip-common.h | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 

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

Re: [U-Boot] [U-Boot, v3, 1/3] rockchip: add a common script for generate fit its

[Philipp Tomsich]

> Rockchip release bl31.elf file for armv8 SoCs like rk3399, rk3328,
> the elf have more than one section, we need to decode it first and
> packed them into u-boot.itb with its file. This script is to generate
> the its script.
> Need default bl31.elf in root directory of U-Boot source and dtb
> as parameter.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - use python script
> - adapt for latest spl atf support
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/make_fit_atf.py | 221 
> +
>  1 file changed, 221 insertions(+)
>  create mode 100755 arch/arm/mach-rockchip/make_fit_atf.py
> 

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

Re: [U-Boot] rockchip: rk3399-puma: set gpio4cd iodomain to 1.8V

[Philipp Tomsich]

> The PCIe reset signal is connected to GPIO4_C6 on the Puma
> module. This pin is supplied by 1.8V, but the default iodomain
> setting is 3.0V and in this situation the pin is unable to go
> high.
> 
> Linux assumes that this signal works in early boot
> as PCIe is probed before loading the iodomain driver.
> 
> Make PCIe work in Linux by setting the gpio4cd iodomain to 1.8V.
> 
> Signed-off-by: Jakob Unterwurzacher 
> 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  board/theobroma-systems/puma_rk3399/puma-rk3399.c | 20 
>  1 file changed, 20 insertions(+)
> 

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

Re: [U-Boot] [U-Boot,v3] rockchip: update boot0 hook

[Philipp Tomsich]

> Rockchip SoCs only need boot0 hook at SPL, and the U-Boot proper do not
> need it.
> 
> The very beginning of U-Boot proper is different between armv7 and armv8:
> armv7 start with ARM_VECTORS while armv8 start with 'b reset'.
> 
> Here is the map of very beginning for all cases:
> armv7 SPL: TAG(overwrite 'b 1f')+'b reset' + ARM_VECTORS
> armv7 U-Boot: ARM_VECTORS
> armv8 SPL: TAG(overwrite 'b 1f')+'b reset' + Reserved_iram(rk3399)
> armv8 U-Boot: 'b reset'
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - address comments from Philipp
> 
> Changes in v2:
> - update commit message
> 
>  arch/arm/include/asm/arch-rockchip/boot0.h | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 

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

Re: [U-Boot] rockchip: update ROCKCHIP_SPL_RESERVE_IRAM to 0

[Philipp Tomsich]

> Only rk3399 atf need ROCKCHIP_SPL_RESERVE_IRAM, so update it dtfault
> 0 so that other SoCs do not need to define it.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
>  arch/arm/mach-rockchip/Kconfig   | 2 +-
>  configs/evb-rk3399_defconfig | 1 +
>  configs/firefly-rk3399_defconfig | 1 +
>  3 files changed, 3 insertions(+), 1 deletion(-)
> 

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

Re: [U-Boot] [PATCH 2/5] board: TI K2G: FC SoC 1GHz and DDR3 1066 MT/s support

[Tom Rini]

On Mon, Dec 18, 2017 at 03:10:04PM +0530, Lokesh Vutla wrote:

> From: Rex Chang 
> 
> Added support for K2G EVM with FlipChip SoC of which
> ARM/DDR3 runs at 1GHz/1066 MT/s. The patch is also
> backward compatible with old revision EVM and EVM
> with WireBond SoC. Their ARM/DDR3 run at 600MHz/800 MT/s.
> 
> The new SoC supports 2 different speeds at 1GHz and 600MHz.
> Modyfied the CPU Name to show which SoC is used in the EVM.
> Modified the DDR3 configuration to reflect New SoC supports
> 2 different CPU and DDR3 speeds, 1GHz/1066MT and 600MHz/800MT.
> 
> Added new inline function board_it_k2g_g1() for the new FlipChip 1GHz,
> and set the u-boot env variable board_name accordingly.
> 
> Modified findfdt script in u-boot environment variable to include new k2g 
> board type.
> 
> Signed-off-by: Rex Chang 
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/mach-keystone/include/mach/hardware.h |  7 
>  arch/arm/mach-keystone/init.c  | 17 +++-
>  board/ti/ks2_evm/board.h   |  4 ++
>  board/ti/ks2_evm/board_k2g.c   | 30 +++---
>  board/ti/ks2_evm/ddr3_k2g.c| 57 
> +-
>  board/ti/ks2_evm/mux-k2g.h |  2 +-
>  include/configs/k2g_evm.h  |  4 +-
>  7 files changed, 109 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/mach-keystone/include/mach/hardware.h 
> b/arch/arm/mach-keystone/include/mach/hardware.h
> index 6629406870..e1621b27a4 100644
> --- a/arch/arm/mach-keystone/include/mach/hardware.h
> +++ b/arch/arm/mach-keystone/include/mach/hardware.h
> @@ -327,6 +327,9 @@ typedef volatile unsigned int   *dv_reg_p;
>  #define CPU_66AK2Lx  0xb9a7
>  #define CPU_66AK2Gx  0xbb06
>  
> +/* Variant definitions */
> +#define CPU_66AK2G1x 0x08
> +
>  /* DEVSPEED register */
>  #define DEVSPEED_DEVSPEED_SHIFT  16
>  #define DEVSPEED_DEVSPEED_MASK   (0xfff << 16)
> @@ -390,6 +393,10 @@ static inline u8 cpu_revision(void)
>  int cpu_to_bus(u32 *ptr, u32 length);
>  void sdelay(unsigned long);
>  
> +#ifdef CONFIG_SOC_K2G
> +extern int arm_speeds[];
> +#endif

Lets not ifdef around externs.

[snip]
> @@ -241,7 +253,8 @@ int print_cpuinfo(void)
>   puts("1.1\n");
>   else if (rev == 0)
>   puts("1.0\n");
> -
> + else if (rev == 8)
> + puts("1.0\n");

Both values are rev "1.0" ?

Thanks!

-- 
Tom


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

[U-Boot] [PATCH] power: tps65910: replace error() by pr_err()

[Felix Brack]

The patch replaces the former error() by the new pr_err().
This makes the TPS65910 driver conform to Masahiro's patch
'treewide:replace with error() with pr_err()' introduced
October 2017.

Signed-off-by: Felix Brack 
---

 drivers/power/pmic/pmic_tps65910_dm.c| 4 ++--
 drivers/power/regulator/tps65910_regulator.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/power/pmic/pmic_tps65910_dm.c 
b/drivers/power/pmic/pmic_tps65910_dm.c
index 0127ce3..c65f38f 100644
--- a/drivers/power/pmic/pmic_tps65910_dm.c
+++ b/drivers/power/pmic/pmic_tps65910_dm.c
@@ -32,7 +32,7 @@ static int pmic_tps65910_write(struct udevice *dev, uint reg, 
const u8 *buffer,
 
ret = dm_i2c_write(dev, reg, buffer, len);
if (ret)
-   error("%s write error on register %02x\n", dev->name, reg);
+   pr_err("%s write error on register %02x\n", dev->name, reg);
 
return ret;
 }
@@ -44,7 +44,7 @@ static int pmic_tps65910_read(struct udevice *dev, uint reg, 
u8 *buffer,
 
ret = dm_i2c_read(dev, reg, buffer, len);
if (ret)
-   error("%s read error on register %02x\n", dev->name, reg);
+   pr_err("%s read error on register %02x\n", dev->name, reg);
 
return ret;
 }
diff --git a/drivers/power/regulator/tps65910_regulator.c 
b/drivers/power/regulator/tps65910_regulator.c
index 5e2ec8f..ad952e5 100644
--- a/drivers/power/regulator/tps65910_regulator.c
+++ b/drivers/power/regulator/tps65910_regulator.c
@@ -340,11 +340,11 @@ static int buck_set_vdd1_vdd2_value(struct udevice *dev, 
int uV)
 
/* check setpoint is within limits */
if (uV < uc_pdata->min_uV) {
-   error("voltage %duV for %s too low\n", uV, dev->name);
+   pr_err("voltage %duV for %s too low\n", uV, dev->name);
return -EINVAL;
}
if (uV > uc_pdata->max_uV) {
-   error("voltage %duV for %s too high\n", uV, dev->name);
+   pr_err("voltage %duV for %s too high\n", uV, dev->name);
return -EINVAL;
}
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH] ARM: socfpga: Enable part command for socfpga platform

[Marek Vasut]

On 12/18/2017 02:04 PM, Andrey Zhizhikin wrote:
> Enable CONFIG_CMD_PART item, as default environment requires it
> and complains this command in unknown.
> 
> Signed-off-by: Andrey Zhizhikin 
> ---
>  configs/socfpga_arria10_defconfig  | 1 +
>  configs/socfpga_arria5_defconfig   | 1 +
>  configs/socfpga_cyclone5_defconfig | 1 +
>  configs/socfpga_de0_nano_soc_defconfig | 1 +
>  configs/socfpga_de10_nano_defconfig| 1 +
>  configs/socfpga_de1_soc_defconfig  | 1 +
>  configs/socfpga_is1_defconfig  | 1 +
>  configs/socfpga_mcvevk_defconfig   | 1 +
>  configs/socfpga_sockit_defconfig   | 1 +
>  configs/socfpga_socrates_defconfig | 1 +
>  configs/socfpga_sr1500_defconfig   | 1 +
>  configs/socfpga_vining_fpga_defconfig  | 1 +
>  12 files changed, 12 insertions(+)


Applied, thanks.

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

Re: [U-Boot] [PATCH] config: Enable part command for socfpga platform

[Marek Vasut]

On 12/18/2017 01:30 PM, Andrey Zhizhikin wrote:
> Hello Marek,

Hi,

> On Mon, Dec 18, 2017 at 12:39 PM, Marek Vasut  wrote:
>> On 12/18/2017 12:10 PM, Andrey Zhizhikin wrote:
>>> Enable CONFIG_CMD_PART item, as default environment requires it
>>> and complains this command in unknown.
>>
>> Fine by me, but what about the other boards, don't they need this as well ?
> 
> I'd say this is applicable to other boards in socfpga family as well.
> The only reason I didn't include them as well into this commit is I
> don't have those boards on hands to perform verification. But I can
> assume since a lot of people uses ENV files to overwrite defaults -
> this should not affect anyone. Please let me know what you think, and
> I can re-submit this patch to include part command in all socfpga
> family configs.

Let's keep it consistent, include all the others. Also make sure to run
make savedefconfig to place that defconfig entry at the right location
if you don't already .

>> btw diffstat is missing and the tags are wrong (should be ARM:
>> socfpga:). I can fix those up, but see my question above...
>>
> 
> Thanks a lot for pointing this out! I quickly checked the log on those
> files, and missed those points out... If you would agree on my
> proposal below, then I get those resolved as well.

Fine.

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

[U-Boot] [GIT PULL] Xilinx fixes for v2018.01-rc2 v2

[Michal Simek]

Hi Tom, +Stephen

This is second pull request. I have removed that AES command enabling
which was causing compilation warning on arm64.

Thanks,
Michal

The following changes since commit 659208da4703de50826a469cbb38bf6afb938978:

  README: update the kernel coding style reference (2017-12-12 21:34:10
-0500)

are available in the git repository at:

  git://www.denx.de/git/u-boot-microblaze.git
tags/xilinx-for-v2018.01-rc2-v2

for you to fetch changes up to 3e229a83bd4190f99731992d3a56983f29313899:

  test/py: Setup variables based on HUSH selection (2017-12-18 09:32:07
+0100)


Xilinx changes for v2018.01-rc2-v2

fpga:
- Enable loading bitstream via fit image for !xilinx platforms

zynq:
- Fix SPL SD boot mode

zynqmp:
- Not not reset in panic
- Do not use simple allocator because of fat changes
- Various dt chagnes
- modeboot variable setup
- Fix fpga loading on automotive devices
- Fix coverity issues

test:
- Fix env test for !hush case - Stephen's patch


Goldschmidt Simon (1):
  fpga: allow programming fpga from FIT image for all FPGA drivers

Javier Martinez Canillas (1):
  arm64: zynqmp: Add generic compatible string for I2C EEPROM

Michal Simek (18):
  arm: zynq: Fix SPL SD boot mode
  arm64: zynqmp: Do not perform reset in case of panic
  arm64: zynqmp: Do not use SPL_SYS_MALLOC_SIMPLE allocator
  arm64: zynqmp: Add reference to pmu firmware node
  arm64: zynqmp: Add support for generic QSPI boot
  arm64: zynqmp: Enable SPL_CLK when SPL is enabled
  arm64: zynqmp: Setup modeboot variable based on bootmode
  arm64: zynqmp: Enable phys for zcu102
  arm64: zynqmp: Enable clock command for all boards
  arm64: zynqmp: Remove undocumented dma properties
  arm64: zynqmp: Use only earlycon bootargs instead of full one
  arm64: zynqmp: Add missing zynq_board_read_rom_ethaddr() prototype
  arm64: zynqmp: Add support for zynqmp automotive silicons
  arm64: zynqmp: Enable misc devices
  arm64: zynqmp: Enable SPL ram support
  arm64: zynqmp: Enable fpga bitstream loading
  arm64: zynqmp: Enable spi flashes
  tools: zynqmpimage: Check return values from file functions

Siva Durga Prasad Paladugu (3):
  arm64: zynqmp: Read boot mode register using zynqmp_mmio_read
  arm64: zynqmp: Dont use 4K sector erase by default for spi-flashes
  arm64: zynqmp: Access timestamp_ref_ctrl register only if running
in el3

Stephen Warren (1):
  test/py: Setup variables based on HUSH selection

 arch/arm/Kconfig |  2 +-
 arch/arm/dts/zynqmp-ep108.dts|  4 ++--
 arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts |  9 -
 arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts |  9 -
 arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts |  9 -
 arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts | 11 +--
 arch/arm/dts/zynqmp-zcu102-revA.dts  | 20 +++-
 arch/arm/dts/zynqmp.dtsi |  3 ++-
 arch/arm/include/asm/arch-zynqmp/sys_proto.h |  1 +
 board/xilinx/zynqmp/zynqmp.c | 23
+++
 common/bootm.c   |  2 +-
 common/image.c   |  6 ++
 configs/syzygy_hub_defconfig |  2 ++
 configs/topic_miami_defconfig|  2 ++
 configs/topic_miamilite_defconfig|  2 ++
 configs/topic_miamiplus_defconfig|  2 ++
 configs/xilinx_zynqmp_ep_defconfig   |  7 ++-
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig |  9 -
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig |  7 ++-
 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 14 +-
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig |  7 ++-
 configs/xilinx_zynqmp_zcu102_rev1_0_defconfig|  9 -
 configs/xilinx_zynqmp_zcu102_revA_defconfig  |  9 -
 configs/xilinx_zynqmp_zcu102_revB_defconfig  |  9 -
 configs/zynq_cc108_defconfig |  2 ++
 configs/zynq_cse_qspi_defconfig  |  2 ++
 configs/zynq_microzed_defconfig  |  2 ++
 configs/zynq_picozed_defconfig   |  2 ++
 configs/zynq_z_turn_defconfig|  2 ++
 configs/zynq_zc702_defconfig |  2 ++
 configs/zynq_zc706_defconfig |  2 ++
 configs/zynq_zc770_xm010_defconfig   |  2 ++
 configs/zynq_zc770_xm011_defconfig   |  2 ++
 configs/zynq_zc770_xm012_defconfig   |  2 ++
 configs/zynq_zc770_xm013_defconfig   |  2 ++
 configs/zynq_zed_defconfig   |  2 ++
 configs/zynq_zybo_defconfig  |  2 ++
 drivers/fpga/fpga.c  |  9 +
 

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Marek Vasut]

On 12/18/2017 01:16 PM, Patrick Brünn wrote:
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Montag, 18. Dezember 2017 12:52
>> On 12/18/2017 12:40 PM, Patrick Brünn wrote:
 From: Marek Vasut [mailto:ma...@denx.de]
 Sent: Montag, 18. Dezember 2017 11:57
 On 12/18/2017 11:47 AM, Patrick Brünn wrote:
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Montag, 18. Dezember 2017 10:17
>> On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote:
>>> From: Patrick Bruenn 
>>>
>>> 'static uint32_t mx53_dram_size[2];' was used in board specific
>>> dram_init(), dram_init_banksize() and get_effective_memsize() to
>> avoid
>>> multiple calls to get_ram_size().
>>>
>>> Reused dram initialization functions from arch/arm/mach-
>> imx/mx5/mx53_dram.c
>>>
>>> Signed-off-by: Patrick Bruenn 
>>>
>>> ---
>>>
>>> Changes in v2: None
>>>
>>>
>>> Only compile tested with make m53evk_defconfig
>>
>> Are you sure this patch retains the original functionality ? Note the
>> warning ...
>
> Effectively it changes:
>  -  return mx53_dram_size[0];
> +   return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
>
> So, yes I am convinced that get_effective_memsize() still returns only the
 size
> of the first dram bank.

 I suspect that will fails on M53 due to it's split-bank configuration.
 The board has two DRAM banks with a hole between them.

>>> This is how mx53_dram_size was initialized on m53 before that patch:
>>> -   mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
>>> -   mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, 1 << 30);
>>>
>>> So to me that's, absolutely the same. With the only difference, that
>> get_ram_size(bank0)
>>> is called multiple times, now.
>>
>> The get_ram_size() above is called for two different bank (addresses),
>> not for bank0 twice. Maybe I'm missing something.
>>
>> btw where's the patch adding mx53_dram.c ? I don't see it in mainline yet.
>>
> It's #2 of this series:
> https://lists.denx.de/pipermail/u-boot/2017-December/314742.html

Ah, sorry, I missed that.

> However, I would be fine with just keeping the changes to my board
 (cx9020).
> And if anyone has a better idea of what might be the root cause of [1]
>> and
 [2],
> I would absolute appreciate any input to that.

 If your board also has two DRAM banks with a hole between them and you
 can test if this works fine, then I'm OK with this change.

>>> Yes, cx9020 uses two 512MB banks with 1GB between PHYS_SDRAM_1/2,
>> too.
>>
>> Then that should be the same situation. Can you share "bdinfo" from that
>> board of yours?
>>
> => bdinfo
> arch_number = 0x
> boot_params = 0x7100
> DRAM bank   = 0x
> -> start= 0x7000
> -> size = 0x2000
> DRAM bank   = 0x0001
> -> start= 0xB000
> -> size = 0x2000
> eth0name= FEC
> ethaddr = 00:01:05:23:87:85
> current eth = FEC
> ip_addr = 
> baudrate= 115200 bps
> TLB addr= 0x8FFF
> relocaddr   = 0x8FF8B000
> reloc off   = 0x1878B000
> irq_sp  = 0x8F586960
> sp start= 0x8F586950
> FB base = 0x8F58C7C0
> Early malloc usage: 134 / 400
> fdt_blob = 8f586978

Looks fine then.

>> btw do you use SPL ? If not, you should ...
> I will read more about SPL. Until now, I thought I will only benefit,
> if my initial boot media is limited in size. As we boot from sdcard,
> that wasn't a problem to store 360k u-boot.

The other is that you can ie. skip the whole u-boot altogether and boot
linux directly.

I wonder if it would be better to keep the static variable and avoid
calling the get_ram_size() twice, it can save some CPU cycles. Besides
that, thanks for the explanation/discussion !1

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

Re: [U-Boot] [PULL] efi patch queue 2017-12-17

[Jonathan Gray]

On Sun, Dec 17, 2017 at 09:33:44PM +0100, Alexander Graf wrote:
> Hi Tom,
> 
> This is my current patch queue for efi.  Please pull.
> 
> Alex
> 
> 
> The following changes since commit 15616a0aa58173bce1efe47569bf2e10d023ae9c:
> 
>   Merge git://git.denx.de/u-boot-dm (2017-12-14 15:46:07 -0500)
> 
> are available in the git repository at:
> 
>   git://github.com/agraf/u-boot.git tags/signed-efi-v2018.01
> 
> for you to fetch changes up to bde6bfe4c3234480a0eef3b5bda8cf5fc83d3c79:
> 
>   efi_loader: comments for dp_part_fill() (2017-12-16 23:07:56 +0100)
> 
> 
> Patch queue for efi - 2017-12-17
> 
> A few fixes for 2018.01:
> 
>   - Compile fix with helloworld example
>   - DP match fix (fixes FreeBSD loader and grub on block storage)

This was for the OpenBSD bootloader, FreeBSD has a different one.
I'd test again but am away from hardware for a few days.

>   - More DP fixes for SD, block
>   - Fix use-after-free
> 
> 
> Alexander Graf (3):
>   efi_loader: helloworld.c: Explicitly use .rodata for loaded_image_guid
>   efi_loader: helloworld.c: Reduce file size
>   efi_loader: Ensure efi_dp_find_obj() finds exact matches
> 
> Heinrich Schuchardt (7):
>   efi_loader: return status from efi_setup_loaded_image()
>   efi_loader: new function efi_delete_handle()
>   efi_loader: error handling in efi_load_image()
>   efi_loader: correctly determine if an MMC device is an SD-card
>   efi_loader: correctly setup device paths for block devices
>   efi_loader: correct DeviceNodeToText for media types
>   efi_loader: comments for dp_part_fill()
> 
>  arch/arm/lib/elf_arm_efi.lds |  11 +-
>  include/efi_loader.h |  10 +-
>  lib/efi_loader/efi_boottime.c| 228 
> +--
>  lib/efi_loader/efi_device_path.c |  56 ++--
>  lib/efi_loader/efi_device_path_to_text.c |  43 --
>  lib/efi_loader/helloworld.c  |   3 +-
>  6 files changed, 214 insertions(+), 137 deletions(-)
> ___
> 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 u-boot] net: phy: meson-gxl: detect LPA corruption

[Neil Armstrong]

On 12/12/2017 16:03, Neil Armstrong wrote:
> From: Jerome Brunet 
> 
> This patch is ported from the Linux patch posted at [1] and applied to
> net tree as commit f1e2400a80ff.
> 
> The purpose of this change is to fix the incorrect detection of the link
> partner (LP) advertised capabilities which sometimes happens with this PHY
> (roughly 1 time in a dozen)
> 
> This issue may cause the link to be negotiated at 10Mbps/Full or
> 10Mbps/Half when 100MBps/Full is actually possible. In some case, the link
> is even completely broken and no communication is possible.
> 
> To detect the corruption, we must look for a magic undocumented bit in the
> WOL bank (hint given by the SoC vendor kernel) but this is not enough to
> cover all cases. We also have to look at the LPA ack. If the LP supports
> Aneg but did not ack our base code when aneg is completed, we assume
> something went wrong.
> 
> The detection of a corrupted LPA triggers a restart of the aneg process.
> This solves the problem but may take up to 6 retries to complete.
> 
> [1] https://lkml.kernel.org/r/20171208110811.30789-1-jbru...@baylibre.com
> 
> Fixes: 8995a96d1d67 ("net: phy: Add Amlogic Meson GXL Internal PHY support")
> Signed-off-by: Jerome Brunet 
> Signed-off-by: Neil Armstrong 
> ---
> 
> This patch has been tested on LibreTech-CC and adapted to U-Boot PHY calls.
> 
> Comments from Jerome from the original patch :
> ""
> I suppose this patch probably seems a bit hacky, especially the part
> about the link partner acknowledge. I'm trying to figure out if the
> value in MII_LPA makes sense but I don't have such a deep knowledge
> of the ethernet spec.
> 
> To me, it does not makes sense for the LP to support ANEG (Bit 1 in
> MII_EXPENSION), the aneg to have successfully complete and, at the
> same time, LP does not ACK our base code word, which we should have
> sent during this aneg.
> 
> If you think this may have unintended consequences or if you have
> an idea to do this differently, feel free to let me know.
> 
> This fix has been tested on the libretech-cc and khadas VIM
> ""
> 
>  drivers/net/phy/meson-gxl.c | 88 
> -
>  1 file changed, 87 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
> index ccf70c9..5f4ecb1 100644
> --- a/drivers/net/phy/meson-gxl.c
> +++ b/drivers/net/phy/meson-gxl.c
> @@ -10,8 +10,94 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> +/* This function is provided to cope with the possible failures of this phy
> + * during aneg process. When aneg fails, the PHY reports that aneg is done
> + * but the value found in MII_LPA is wrong:
> + *  - Early failures: MII_LPA is just 0x0001. if MII_EXPANSION reports that
> + *the link partner (LP) supports aneg but the LP never acked our base
> + *code word, it is likely that we never sent it to begin with.
> + *  - Late failures: MII_LPA is filled with a value which seems to make sense
> + *but it actually is not what the LP is advertising. It seems that we
> + *can detect this using a magic bit in the WOL bank (reg 12 - bit 12).
> + *If this particular bit is not set when aneg is reported being done,
> + *it means MII_LPA is likely to be wrong.
> + *
> + * In both case, forcing a restart of the aneg process solve the problem.
> + * When this failure happens, the first retry is usually successful but,
> + * in some cases, it may take up to 6 retries to get a decent result
> + */
> +int meson_gxl_startup(struct phy_device *phydev)
> +{
> + unsigned int retries = 10;
> + int ret, wol, lpa, exp;
> +
> +restart_aneg:
> + ret = genphy_update_link(phydev);
> + if (ret)
> + return ret;
> +
> + if (phydev->autoneg == AUTONEG_ENABLE) {
> + /* Need to access WOL bank, make sure the access is open */
> + ret = phy_write(phydev, MDIO_DEVAD_NONE, 0x14, 0x);
> + if (ret)
> + return ret;
> + ret = phy_write(phydev, MDIO_DEVAD_NONE, 0x14, 0x0400);
> + if (ret)
> + return ret;
> + ret = phy_write(phydev, MDIO_DEVAD_NONE, 0x14, 0x);
> + if (ret)
> + return ret;
> + ret = phy_write(phydev, MDIO_DEVAD_NONE, 0x14, 0x0400);
> + if (ret)
> + return ret;
> +
> + /* Request LPI_STATUS WOL register */
> + ret = phy_write(phydev, MDIO_DEVAD_NONE, 0x14, 0x8D80);
> + if (ret)
> + return ret;
> +
> + /* Read LPI_STATUS value */
> + wol = phy_read(phydev, MDIO_DEVAD_NONE, 0x15);
> + if (wol < 0)
> + return wol;
> +
> + lpa = phy_read(phydev, MDIO_DEVAD_NONE, MII_LPA);
> + if (lpa < 0)
> + return lpa;
> +
> +

Re: [U-Boot] [PATCH u-boot] ARM: arch-meson: fix writel arguments order

[Neil Armstrong]

On 12/12/2017 14:23, Neil Armstrong wrote:
> From: Hans Verkuil 
> 
> Using writel causes a "Synchronous Abort". Invert the arguments.
> 
> Signed-off-by: Hans Verkuil 
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm/mach-meson/eth.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Thanks Hans for finding this stupid error !
> 
> Neil
> 
> diff --git a/arch/arm/mach-meson/eth.c b/arch/arm/mach-meson/eth.c
> index 2debe93..8c6577b 100644
> --- a/arch/arm/mach-meson/eth.c
> +++ b/arch/arm/mach-meson/eth.c
> @@ -38,8 +38,8 @@ void meson_gx_eth_init(phy_interface_t mode, unsigned int 
> flags)
>   /* Use GXL RMII Internal PHY */
>   if (IS_ENABLED(CONFIG_MESON_GXL) &&
>   (flags & MESON_GXL_USE_INTERNAL_RMII_PHY)) {
> - writel(GXBB_ETH_REG_2, 0x10110181);
> - writel(GXBB_ETH_REG_3, 0xe40908ff);
> + writel(0x10110181, GXBB_ETH_REG_2);
> + writel(0xe40908ff, GXBB_ETH_REG_3);
>   }
>  
>   break;
> 

Hi Tom,

Can this be merged ?
This error breaks boot on 3 boards.

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

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Marek Vasut]

On 12/18/2017 12:40 PM, Patrick Brünn wrote:
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Montag, 18. Dezember 2017 11:57
>> On 12/18/2017 11:47 AM, Patrick Brünn wrote:
 From: Marek Vasut [mailto:ma...@denx.de]
 Sent: Montag, 18. Dezember 2017 10:17
 On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote:
> From: Patrick Bruenn 
>
> Static variables are not available during board_init_f().

 They are, since the board runs from RAM at that point already.

>>> From reading the README and common/board_f.c I got the impression,
>>> that dram_init() is called before it's save to access mx53_dram_size.
>>> And as that change seemed to cure the strange behavior I described
>>> in [1] and [2], I prepared a patch for my board, which ended up to be
>>> requested for m53evk and mx53loco, too.
>>
>> Technically yes, board_init_f means it runs from FLASH and has no or
>> minimal storage available. On the MX53 with SPL, it's running from RAM
>> so it's safe to use static variables too.
>>
> Thank's for your explanation.

No problem, it's a bit weird.

> 'static uint32_t mx53_dram_size[2];' was used in board specific
> dram_init(), dram_init_banksize() and get_effective_memsize() to avoid
> multiple calls to get_ram_size().
>
> Reused dram initialization functions from arch/arm/mach-
 imx/mx5/mx53_dram.c
>
> Signed-off-by: Patrick Bruenn 
>
> ---
>
> Changes in v2: None
>
>
> Only compile tested with make m53evk_defconfig

 Are you sure this patch retains the original functionality ? Note the
 warning ...
>>>
>>> Effectively it changes:
>>>  -  return mx53_dram_size[0];
>>> +   return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
>>>
>>> So, yes I am convinced that get_effective_memsize() still returns only the
>> size
>>> of the first dram bank.
>>
>> I suspect that will fails on M53 due to it's split-bank configuration.
>> The board has two DRAM banks with a hole between them.
>>
> This is how mx53_dram_size was initialized on m53 before that patch:
> -   mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
> -   mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, 1 << 30);
> 
> So to me that's, absolutely the same. With the only difference, that 
> get_ram_size(bank0)
> is called multiple times, now.

The get_ram_size() above is called for two different bank (addresses),
not for bank0 twice. Maybe I'm missing something.

btw where's the patch adding mx53_dram.c ? I don't see it in mainline yet.

>>> However, I would be fine with just keeping the changes to my board
>> (cx9020).
>>> And if anyone has a better idea of what might be the root cause of [1] and
>> [2],
>>> I would absolute appreciate any input to that.
>>
>> If your board also has two DRAM banks with a hole between them and you
>> can test if this works fine, then I'm OK with this change.
>>
> Yes, cx9020 uses two 512MB banks with 1GB between PHYS_SDRAM_1/2, too.

Then that should be the same situation. Can you share "bdinfo" from that
board of yours?

btw do you use SPL ? If not, you should ...

[...]

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

Re: [U-Boot] [PATCH] config: Enable part command for socfpga platform

[Marek Vasut]

On 12/18/2017 12:10 PM, Andrey Zhizhikin wrote:
> Enable CONFIG_CMD_PART item, as default environment requires it
> and complains this command in unknown.

Fine by me, but what about the other boards, don't they need this as well ?

> Signed-off-by: Andrey Zhizhikin 

btw diffstat is missing and the tags are wrong (should be ARM:
socfpga:). I can fix those up, but see my question above...

> diff --git a/configs/socfpga_arria5_defconfig 
> b/configs/socfpga_arria5_defconfig
> index 8ed6169..2685881 100644
> --- a/configs/socfpga_arria5_defconfig
> +++ b/configs/socfpga_arria5_defconfig
> @@ -35,6 +35,7 @@ CONFIG_CMD_EXT4=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
> +CONFIG_CMD_PART=y
>  CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
>  
> CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
>  CONFIG_CMD_UBI=y
> diff --git a/configs/socfpga_cyclone5_defconfig 
> b/configs/socfpga_cyclone5_defconfig
> index 54c3495..f49d0ab 100644
> --- a/configs/socfpga_cyclone5_defconfig
> +++ b/configs/socfpga_cyclone5_defconfig
> @@ -35,6 +35,7 @@ CONFIG_CMD_EXT4=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
> +CONFIG_CMD_PART=y
>  CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
>  
> CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
>  CONFIG_CMD_UBI=y
> diff --git a/configs/socfpga_sockit_defconfig 
> b/configs/socfpga_sockit_defconfig
> index 079d465..857f2f7 100644
> --- a/configs/socfpga_sockit_defconfig
> +++ b/configs/socfpga_sockit_defconfig
> @@ -35,6 +35,7 @@ CONFIG_CMD_EXT4=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
> +CONFIG_CMD_PART=y
>  CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
>  
> CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
>  CONFIG_CMD_UBI=y
> diff --git a/configs/socfpga_socrates_defconfig 
> b/configs/socfpga_socrates_defconfig
> index 35773e6..71bd8f1 100644
> --- a/configs/socfpga_socrates_defconfig
> +++ b/configs/socfpga_socrates_defconfig
> @@ -36,6 +36,7 @@ CONFIG_CMD_EXT4=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
> +CONFIG_CMD_PART=y
>  CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
>  
> CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)0"
>  CONFIG_CMD_UBI=y
> 


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

Re: [U-Boot] [PATCH 11/13] board: ti: am57xx: Enable CMD_DDR3

[Lukasz Majewski]

Hi Lokesh,

> Enable CMD_DDR3 on all am57xx based platforms.
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/mach-omap2/omap5/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-omap2/omap5/Kconfig
> b/arch/arm/mach-omap2/omap5/Kconfig index 8c1730a6be..deb9873cc5
> 100644 --- a/arch/arm/mach-omap2/omap5/Kconfig
> +++ b/arch/arm/mach-omap2/omap5/Kconfig
> @@ -39,6 +39,7 @@ config TARGET_AM57XX_EVM
>   select BOARD_LATE_INIT
>   select DRA7XX
>   select TI_I2C_BOARD_DETECT
> + select CMD_DDR3

I'm just curious - what is the purpose of this command?

>   imply SCSI
>   imply SPL_THERMAL
>   imply DM_THERMAL



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


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

Re: [U-Boot] [PATCH 09/13] board: ti: am574x-idk: Add ddr data support

[Lukasz Majewski]

Hi Lokesh,

> AM574x-idk has the following DDR parts attached:
> EMIF1: MT41K256M16HA (1GB with ECC)
> EMIF2: MT41K256M16HA (1GB without ECC)
> 
> Enabling 2GB DDR without interleaving between EMIFs. And
> enabling ECC on EMIF1.
> 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Krunal Bhargav 
> ---
>  board/ti/am57xx/board.c | 47
> --- 1 file changed, 44
> insertions(+), 3 deletions(-)
> 
> diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
> index 2d14ae54fe..1377c7b1fe 100644
> --- a/board/ti/am57xx/board.c
> +++ b/board/ti/am57xx/board.c
> @@ -89,10 +89,18 @@ static const struct dmm_lisa_map_regs
> am571x_idk_lisa_regs = { .is_ma_present  = 0x1
>  };
>  
> +static const struct dmm_lisa_map_regs am574x_idk_lisa_regs = {
> + .dmm_lisa_map_2 = 0xc0600200,
> + .dmm_lisa_map_3 = 0x80600100,
> + .is_ma_present  = 0x1
> +};
> +
>  void emif_get_dmm_regs(const struct dmm_lisa_map_regs
> **dmm_lisa_regs) {
>   if (board_is_am571x_idk())
>   *dmm_lisa_regs = _idk_lisa_regs;
> + else if (board_is_am574x_idk())
> + *dmm_lisa_regs = _idk_lisa_regs;
>   else
>   *dmm_lisa_regs = _x15_lisa_regs;
>  }
> @@ -231,8 +239,8 @@ static const struct emif_regs
> am571x_emif1_ddr3_666mhz_emif_regs =
> { .ref_ctrl   =
> 0x514d, .ref_ctrl_final   =
> 0x144a, .sdram_tim1   = 0xd333887c,
> - .sdram_tim2 = 0x40b37fe3,
> - .sdram_tim3 = 0x409f8ada,
> + .sdram_tim2 = 0x30b37fe3,
> + .sdram_tim3 = 0x409f8ad8,
>   .read_idle_ctrl = 0x0005,
>   .zq_config  = 0x5007190b,
>   .temp_alert_config  = 0x,
> @@ -249,17 +257,50 @@ static const struct emif_regs
> am571x_emif1_ddr3_666mhz_emif_regs =
> { .emif_rd_wr_exec_thresh = 0x0305 };
>  
> +static const struct emif_regs am574x_emif1_ddr3_666mhz_emif_ecc_regs
> = {
> + .sdram_config_init  = 0x61863332,
> + .sdram_config   = 0x61863332,
> + .sdram_config2  = 0x0800,
> + .ref_ctrl   = 0x514d,
> + .ref_ctrl_final = 0x144a,
> + .sdram_tim1 = 0xd333887c,
> + .sdram_tim2 = 0x30b37fe3,
> + .sdram_tim3 = 0x409f8ad8,
> + .read_idle_ctrl = 0x0005,
> + .zq_config  = 0x5007190b,
> + .temp_alert_config  = 0x,
> + .emif_ddr_phy_ctlr_1_init   = 0x0024400f,
> + .emif_ddr_phy_ctlr_1= 0x0e24400f,
> + .emif_ddr_ext_phy_ctrl_1= 0x10040100,
> + .emif_ddr_ext_phy_ctrl_2= 0x00910091,
> + .emif_ddr_ext_phy_ctrl_3= 0x00950095,
> + .emif_ddr_ext_phy_ctrl_4= 0x009b009b,
> + .emif_ddr_ext_phy_ctrl_5= 0x009e009e,
> + .emif_rd_wr_lvl_rmp_win = 0x,
> + .emif_rd_wr_lvl_rmp_ctl = 0x8000,
> + .emif_rd_wr_lvl_ctl = 0x,
> + .emif_rd_wr_exec_thresh = 0x0305,
> + .emif_ecc_ctrl_reg  = 0xD001,
> + .emif_ecc_address_range_1   = 0x3FFF,
> + .emif_ecc_address_range_2   = 0x
> +};

I'm wondering if it would be possible to:

Embed this memory setup (even as binary blob) to SPL FIT -> Those
values are generated from TI supplied excel sheet (when memory details
are provided).


Pros:


- Since the same EMIF controller is used, one could only adjust the
  binary blob, when new memory (faster, slower, from other manufacturer)
  is used in the product.

- There would be no need to add such code to the board file.

> +
>  void emif_get_reg_dump(u32 emif_nr, const struct emif_regs **regs)
>  {
>   switch (emif_nr) {
>   case 1:
>   if (board_is_am571x_idk())
>   *regs = _emif1_ddr3_666mhz_emif_regs;
> + else if (board_is_am574x_idk())
> + *regs =
> _emif1_ddr3_666mhz_emif_ecc_regs; else
>   *regs =
> _x15_emif1_ddr3_532mhz_emif_regs; break;
>   case 2:
> - *regs = _x15_emif2_ddr3_532mhz_emif_regs;
> + if (board_is_am574x_idk())
> + *regs = _emif1_ddr3_666mhz_emif_regs;
> + else
> + *regs =
> _x15_emif2_ddr3_532mhz_emif_regs; break;
>   }
>  }



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


pgpvfcIJHel_s.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Marek Vasut]

On 12/18/2017 11:47 AM, Patrick Brünn wrote:
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Montag, 18. Dezember 2017 10:17
>> On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote:
>>> From: Patrick Bruenn 
>>>
>>> Static variables are not available during board_init_f().
>>
>> They are, since the board runs from RAM at that point already.
>>
> From reading the README and common/board_f.c I got the impression,
> that dram_init() is called before it's save to access mx53_dram_size.
> And as that change seemed to cure the strange behavior I described
> in [1] and [2], I prepared a patch for my board, which ended up to be
> requested for m53evk and mx53loco, too.

Technically yes, board_init_f means it runs from FLASH and has no or
minimal storage available. On the MX53 with SPL, it's running from RAM
so it's safe to use static variables too.

>>> 'static uint32_t mx53_dram_size[2];' was used in board specific
>>> dram_init(), dram_init_banksize() and get_effective_memsize() to avoid
>>> multiple calls to get_ram_size().
>>>
>>> Reused dram initialization functions from arch/arm/mach-
>> imx/mx5/mx53_dram.c
>>>
>>> Signed-off-by: Patrick Bruenn 
>>>
>>> ---
>>>
>>> Changes in v2: None
>>>
>>>
>>> Only compile tested with make m53evk_defconfig
>>
>> Are you sure this patch retains the original functionality ? Note the
>> warning ...
> 
> Effectively it changes:
>  -  return mx53_dram_size[0];
> +   return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
> 
> So, yes I am convinced that get_effective_memsize() still returns only the 
> size
> of the first dram bank.

I suspect that will fails on M53 due to it's split-bank configuration.
The board has two DRAM banks with a hole between them.

> However, I would be fine with just keeping the changes to my board (cx9020).
> And if anyone has a better idea of what might be the root cause of [1] and 
> [2],
> I would absolute appreciate any input to that.

If your board also has two DRAM banks with a hole between them and you
can test if this works fine, then I'm OK with this change.

> Best regards and thanks in advance for any feedback,
> Patrick
> 
> [1] https://lists.denx.de/pipermail/u-boot/2017-November/313214.html
> [2] https://lists.denx.de/pipermail/u-boot/2017-December/314480.html
> 
> ---
> Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans 
> Beckhoff
> Registered office: Verl, Germany | Register court: Guetersloh HRA 7075
> 
> 


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

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Marek Vasut]

On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote:
> From: Patrick Bruenn 
> 
> Static variables are not available during board_init_f().

They are, since the board runs from RAM at that point already.

> 'static uint32_t mx53_dram_size[2];' was used in board specific
> dram_init(), dram_init_banksize() and get_effective_memsize() to avoid
> multiple calls to get_ram_size().
> 
> Reused dram initialization functions from arch/arm/mach-imx/mx5/mx53_dram.c
> 
> Signed-off-by: Patrick Bruenn 
> 
> ---
> 
> Changes in v2: None
> 
> 
> Only compile tested with make m53evk_defconfig

Are you sure this patch retains the original functionality ? Note the
warning ...

> ---
>  arch/arm/mach-imx/mx5/Makefile |  1 +
>  board/aries/m53evk/m53evk.c| 39 ---
>  2 files changed, 1 insertion(+), 39 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/mx5/Makefile b/arch/arm/mach-imx/mx5/Makefile
> index 368cfde98b..2cc2cbc07a 100644
> --- a/arch/arm/mach-imx/mx5/Makefile
> +++ b/arch/arm/mach-imx/mx5/Makefile
> @@ -11,4 +11,5 @@ obj-y := soc.o clock.o
>  obj-y += lowlevel_init.o
>  
>  # common files for mx53 dram initialization
> +obj-$(CONFIG_TARGET_M53EVK) += mx53_dram.o
>  obj-$(CONFIG_TARGET_MX53CX9020) += mx53_dram.o
> diff --git a/board/aries/m53evk/m53evk.c b/board/aries/m53evk/m53evk.c
> index ece8957aaf..a798d83376 100644
> --- a/board/aries/m53evk/m53evk.c
> +++ b/board/aries/m53evk/m53evk.c
> @@ -31,45 +31,6 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> -static uint32_t mx53_dram_size[2];
> -
> -phys_size_t get_effective_memsize(void)
> -{
> - /*
> -  * WARNING: We must override get_effective_memsize() function here
> -  * to report only the size of the first DRAM bank. This is to make
> -  * U-Boot relocator place U-Boot into valid memory, that is, at the
> -  * end of the first DRAM bank. If we did not override this function
> -  * like so, U-Boot would be placed at the address of the first DRAM
> -  * bank + total DRAM size - sizeof(uboot), which in the setup where
> -  * each DRAM bank contains 512MiB of DRAM would result in placing
> -  * U-Boot into invalid memory area close to the end of the first
> -  * DRAM bank.
> -  */
> - return mx53_dram_size[0];
> -}
> -
> -int dram_init(void)
> -{
> - mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
> - mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, 1 << 30);
> -
> - gd->ram_size = mx53_dram_size[0] + mx53_dram_size[1];
> -
> - return 0;
> -}
> -
> -int dram_init_banksize(void)
> -{
> - gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> - gd->bd->bi_dram[0].size = mx53_dram_size[0];
> -
> - gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
> - gd->bd->bi_dram[1].size = mx53_dram_size[1];
> -
> - return 0;
> -}
> -
>  static void setup_iomux_uart(void)
>  {
>   static const iomux_v3_cfg_t uart_pads[] = {
> 


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

Re: [U-Boot] rockchip: update ROCKCHIP_SPL_RESERVE_IRAM to 0

[Philipp Tomsich]

> Only rk3399 atf need ROCKCHIP_SPL_RESERVE_IRAM, so update it dtfault
> 0 so that other SoCs do not need to define it.
> 
> Signed-off-by: Kever Yang 
> ---
> 
>  arch/arm/mach-rockchip/Kconfig   | 2 +-
>  configs/evb-rk3399_defconfig | 1 +
>  configs/firefly-rk3399_defconfig | 1 +
>  3 files changed, 3 insertions(+), 1 deletion(-)
> 

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

Re: [U-Boot] [U-Boot, v4, 1/2] drivers/reset: support rockchip reset drivers

[Philipp Tomsich]

> From: Elaine Zhang 
> 
> Create driver to support all Rockchip SoCs soft reset.
> Example of usage:
> i2c driver:
>   ret = reset_get_by_name(dev, "i2c", _ctl);
>   if (ret) {
>   error("reset_get_by_name() failed: %d\n", ret);
>   }
> 
>   reset_assert(_ctl);
>   udelay(50);
>   reset_deassert(_ctl);
> 
> i2c dts node:
> resets = < SRST_P_I2C1>, < SRST_I2C1>;
> reset-names = "p_i2c", "i2c";
> 
> Signed-off-by: Elaine Zhang 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - fix Kconfig more than 80 length
> - use MACRO for reset bits in one reg
> - use rkclr/set_reg for reg access
> - add rockchip_reset_bind()
> - use dev_read_addr_size() instead of fdtdec_
> 
>  drivers/reset/Kconfig  |   9 +++
>  drivers/reset/Makefile |   1 +
>  drivers/reset/reset-rockchip.c | 133 
> +
>  3 files changed, 143 insertions(+)
>  create mode 100644 drivers/reset/reset-rockchip.c
> 

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

Re: [U-Boot] [U-Boot,v3] rockchip: update boot0 hook

[Philipp Tomsich]

> Rockchip SoCs only need boot0 hook at SPL, and the U-Boot proper do not
> need it.
> 
> The very beginning of U-Boot proper is different between armv7 and armv8:
> armv7 start with ARM_VECTORS while armv8 start with 'b reset'.
> 
> Here is the map of very beginning for all cases:
> armv7 SPL: TAG(overwrite 'b 1f')+'b reset' + ARM_VECTORS
> armv7 U-Boot: ARM_VECTORS
> armv8 SPL: TAG(overwrite 'b 1f')+'b reset' + Reserved_iram(rk3399)
> armv8 U-Boot: 'b reset'
> 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v3:
> - address comments from Philipp
> 
> Changes in v2:
> - update commit message
> 
>  arch/arm/include/asm/arch-rockchip/boot0.h | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 

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

Re: [U-Boot] [U-Boot,v4,2/2] rockchip: clk: bind reset driver

[Philipp Tomsich]

> From: Elaine Zhang 
> 
> Bind rockchip reset to clock-controller with rockchip_reset_bind().
> 
> Signed-off-by: Elaine Zhang 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v4:
> - fix compile error if CONFIG_RESET_ROCKCHIP not defined
> 
> Changes in v3:
> - add missing offset for rk3399 pmuclk bind
> 
> Changes in v2:
> - use rockchip_reset_bind() to bind reset driver.
> 
>  arch/arm/include/asm/arch-rockchip/clock.h | 10 ++
>  drivers/clk/rockchip/clk_rk3036.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3188.c  |  7 +++
>  drivers/clk/rockchip/clk_rk322x.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3288.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3328.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3368.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3399.c  | 21 +
>  drivers/clk/rockchip/clk_rv1108.c  |  7 +++
>  9 files changed, 80 insertions(+)
> 

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

[U-Boot] [PATCH 0/5] arm: ti: misc updates and bug fixes

[Lokesh Vutla]

This series consolidates few bug fixes on TI platforms.

Lokesh Vutla (3):
  configs: k2g_evm: Allocate more space for u-boot
  tools: omapimage: Fix mismatch of image size in header
  arm: am33xx: Avoid writing into reserved DPLL divider

Rex Chang (1):
  board: TI K2G: FC SoC 1GHz and DDR3 1066 MT/s support

Tomi Valkeinen (1):
  board: ti: dra76: mux wakeup2 as gpio1_2

 arch/arm/mach-keystone/include/mach/hardware.h |  7 
 arch/arm/mach-keystone/init.c  | 17 +++-
 arch/arm/mach-omap2/am33xx/clock_am33xx.c  | 12 +++---
 board/ti/dra7xx/mux_data.h |  2 +-
 board/ti/ks2_evm/board.h   |  4 ++
 board/ti/ks2_evm/board_k2g.c   | 30 +++---
 board/ti/ks2_evm/ddr3_k2g.c| 57 +-
 board/ti/ks2_evm/mux-k2g.h |  2 +-
 include/configs/k2g_evm.h  |  6 ++-
 tools/omapimage.c  |  2 +-
 10 files changed, 118 insertions(+), 21 deletions(-)

-- 
2.15.1

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

[U-Boot] [PATCH 4/5] arm: am33xx: Avoid writing into reserved DPLL divider

[Lokesh Vutla]

DPLL DRR doesn't have an M4 divider. But the clock driver is trying
to configure M4 divider as 4(writing into a reserved register).
Fixing it by making M4 divider as -1.

Reported-by: Steve Kipisz 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/am33xx/clock_am33xx.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/am33xx/clock_am33xx.c 
b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
index 1780bbdb6f..2352c37822 100644
--- a/arch/arm/mach-omap2/am33xx/clock_am33xx.c
+++ b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
@@ -109,22 +109,22 @@ const struct dpll_params 
dpll_per_192MHz[NUM_CRYSTAL_FREQ] = {
 const struct dpll_params dpll_ddr3_303MHz[NUM_CRYSTAL_FREQ] = {
{505, 15, 2, -1, -1, -1, -1}, /*19.2*/
{101, 3, 2, -1, -1, -1, -1}, /* 24 MHz */
-   {303, 24, 1, -1, 4, -1, -1}, /* 25 MHz */
-   {303, 12, 2, -1, 4, -1, -1}  /* 26 MHz */
+   {303, 24, 1, -1, -1, -1, -1}, /* 25 MHz */
+   {303, 12, 2, -1, -1, -1, -1}  /* 26 MHz */
 };
 
 const struct dpll_params dpll_ddr3_400MHz[NUM_CRYSTAL_FREQ] = {
{125, 5, 1, -1, -1, -1, -1}, /*19.2*/
{50, 2, 1, -1, -1, -1, -1}, /* 24 MHz */
-   {16, 0, 1, -1, 4, -1, -1}, /* 25 MHz */
-   {200, 12, 1, -1, 4, -1, -1}  /* 26 MHz */
+   {16, 0, 1, -1, -1, -1, -1}, /* 25 MHz */
+   {200, 12, 1, -1, -1, -1, -1}  /* 26 MHz */
 };
 
 const struct dpll_params dpll_ddr2_266MHz[NUM_CRYSTAL_FREQ] = {
{665, 47, 1, -1, -1, -1, -1}, /*19.2*/
{133, 11, 1, -1, -1, -1, -1}, /* 24 MHz */
-   {266, 24, 1, -1, 4, -1, -1}, /* 25 MHz */
-   {133, 12, 1, -1, 4, -1, -1}  /* 26 MHz */
+   {266, 24, 1, -1, -1, -1, -1}, /* 25 MHz */
+   {133, 12, 1, -1, -1, -1, -1}  /* 26 MHz */
 };
 
 __weak const struct dpll_params *get_dpll_mpu_params(void)
-- 
2.15.1

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

[U-Boot] [PATCH 2/5] board: TI K2G: FC SoC 1GHz and DDR3 1066 MT/s support

[Lokesh Vutla]

From: Rex Chang 

Added support for K2G EVM with FlipChip SoC of which
ARM/DDR3 runs at 1GHz/1066 MT/s. The patch is also
backward compatible with old revision EVM and EVM
with WireBond SoC. Their ARM/DDR3 run at 600MHz/800 MT/s.

The new SoC supports 2 different speeds at 1GHz and 600MHz.
Modyfied the CPU Name to show which SoC is used in the EVM.
Modified the DDR3 configuration to reflect New SoC supports
2 different CPU and DDR3 speeds, 1GHz/1066MT and 600MHz/800MT.

Added new inline function board_it_k2g_g1() for the new FlipChip 1GHz,
and set the u-boot env variable board_name accordingly.

Modified findfdt script in u-boot environment variable to include new k2g board 
type.

Signed-off-by: Rex Chang 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-keystone/include/mach/hardware.h |  7 
 arch/arm/mach-keystone/init.c  | 17 +++-
 board/ti/ks2_evm/board.h   |  4 ++
 board/ti/ks2_evm/board_k2g.c   | 30 +++---
 board/ti/ks2_evm/ddr3_k2g.c| 57 +-
 board/ti/ks2_evm/mux-k2g.h |  2 +-
 include/configs/k2g_evm.h  |  4 +-
 7 files changed, 109 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-keystone/include/mach/hardware.h 
b/arch/arm/mach-keystone/include/mach/hardware.h
index 6629406870..e1621b27a4 100644
--- a/arch/arm/mach-keystone/include/mach/hardware.h
+++ b/arch/arm/mach-keystone/include/mach/hardware.h
@@ -327,6 +327,9 @@ typedef volatile unsigned int   *dv_reg_p;
 #define CPU_66AK2Lx0xb9a7
 #define CPU_66AK2Gx0xbb06
 
+/* Variant definitions */
+#define CPU_66AK2G1x   0x08
+
 /* DEVSPEED register */
 #define DEVSPEED_DEVSPEED_SHIFT16
 #define DEVSPEED_DEVSPEED_MASK (0xfff << 16)
@@ -390,6 +393,10 @@ static inline u8 cpu_revision(void)
 int cpu_to_bus(u32 *ptr, u32 length);
 void sdelay(unsigned long);
 
+#ifdef CONFIG_SOC_K2G
+extern int arm_speeds[];
+#endif
+
 #endif
 
 #endif /* __ASM_ARCH_HARDWARE_H */
diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
index 6e5a1e1af1..520765be83 100644
--- a/arch/arm/mach-keystone/init.c
+++ b/arch/arm/mach-keystone/init.c
@@ -229,7 +229,19 @@ int print_cpuinfo(void)
puts("66AK2Ex SR");
break;
case CPU_66AK2Gx:
-   puts("66AK2Gx SR");
+   puts("66AK2Gx");
+#ifdef CONFIG_SOC_K2G
+   {
+   int speed = get_max_arm_speed(arm_speeds);
+   if (speed == SPD1000)
+   puts("-100 ");
+   else if (speed == SPD600)
+   puts("-60 ");
+   else
+   puts("-xx ");
+   }
+#endif
+   puts("SR");
break;
default:
puts("Unknown\n");
@@ -241,7 +253,8 @@ int print_cpuinfo(void)
puts("1.1\n");
else if (rev == 0)
puts("1.0\n");
-
+   else if (rev == 8)
+   puts("1.0\n");
return 0;
 }
 #endif
diff --git a/board/ti/ks2_evm/board.h b/board/ti/ks2_evm/board.h
index b3ad1881fa..48d60a1c74 100644
--- a/board/ti/ks2_evm/board.h
+++ b/board/ti/ks2_evm/board.h
@@ -20,6 +20,10 @@ static inline int board_is_k2g_gp(void)
 {
return board_ti_is("66AK2GGP");
 }
+static inline int board_is_k2g_g1(void)
+{
+   return board_ti_is("66AK2GG1");
+}
 static inline int board_is_k2g_ice(void)
 {
return board_ti_is("66AK2GIC");
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 01328f1955..fab3764742 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -55,7 +55,7 @@ unsigned int get_external_clk(u32 clk)
return clk_freq;
 }
 
-static int arm_speeds[DEVSPEED_NUMSPDS] = {
+int arm_speeds[DEVSPEED_NUMSPDS] = {
SPD400,
SPD600,
SPD800,
@@ -159,13 +159,20 @@ static struct pll_init_data nss_pll_config[MAX_SYSCLK] = {
[SYSCLK_26MHz] = {NSS_PLL, 1000, 13, 2},
 };
 
-static struct pll_init_data ddr3_pll_config[MAX_SYSCLK] = {
+static struct pll_init_data ddr3_pll_config_800[MAX_SYSCLK] = {
[SYSCLK_19MHz] = {DDR3A_PLL, 167, 1, 16},
[SYSCLK_24MHz] = {DDR3A_PLL, 133, 1, 16},
[SYSCLK_25MHz] = {DDR3A_PLL, 128, 1, 16},
[SYSCLK_26MHz] = {DDR3A_PLL, 123, 1, 16},
 };
 
+static struct pll_init_data ddr3_pll_config_1066[MAX_SYSCLK] = {
+   [SYSCLK_19MHz] = {DDR3A_PLL, 194, 1, 14},
+   [SYSCLK_24MHz] = {DDR3A_PLL, 156, 1, 14},
+   [SYSCLK_25MHz] = {DDR3A_PLL, 149, 1, 14},
+   [SYSCLK_26MHz] = {DDR3A_PLL, 144, 1, 14},
+};
+
 struct pll_init_data *get_pll_init_data(int pll)
 {
int speed;
@@ -188,7 +195,15 @@ struct pll_init_data *get_pll_init_data(int pll)
data = _pll_config[sysclk_index];
break;
case DDR3_PLL:
- 

[U-Boot] [PATCH 1/5] configs: k2g_evm: Allocate more space for u-boot

[Lokesh Vutla]

Now that we have multi dtb enabled in u-boot allocate
128K more space for u-boot.

Signed-off-by: Lokesh Vutla 
---
 include/configs/k2g_evm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
index df81c09d86..9282a22739 100644
--- a/include/configs/k2g_evm.h
+++ b/include/configs/k2g_evm.h
@@ -74,7 +74,7 @@
 #endif
 
 /* SPL SPI Loader Configuration */
-#define CONFIG_SPL_TEXT_BASE   0x0c08
+#define CONFIG_SPL_TEXT_BASE   0x0c0a
 
 /* NAND Configuration */
 #define CONFIG_SYS_NAND_PAGE_2K
-- 
2.15.1

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

Re: [U-Boot] questions on SPL

[Lukasz Majewski]

On Wed, 13 Dec 2017 22:20:57 +0800
herbert  wrote:

> Hi
> 
> I am very sorry to ask this simple question. I read a lot of document 
> and googled online, but I still feel puzzled by the SPL of U-Boot.
> 
> 
> I has an ancient SoC s3c2440 which is armv4t architecture. s3c2440
> will copy the first 4K code on NAND to static SRAM. It is obvious
> that u-boot bin is bigger than 4K. so Here is my question:
> 

It is very unlikely that the 4K that you load is the SPL.

It may be a bl1 image, which is crafted by SoC vendor and needs to be
signed.

I can only recommend looking on the old u-boot from the board BSP and
check what is going on.

IIRC the s3c2440 is not supported by u-boot anymore.

> 1. In this condition, do I must compile a SPL bin？ and flash it to
> the first page of NAND flash. if it's, I think the SPL should be less
> than 4K, or it's meaningless, It still need to copy remain content,
> and has no difference with a single u-boot.
> 
> 2. can I only compile a regular u-boot and do copy work and relocate 
> work at this single u-boot. namely, merge SPL and regular u-boot,
> does u-boot support this framework?
> 
> 
> thanks very much!
> 
>  From 袁建鹏 (Yuan Jianpeng)
> 
> 
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



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


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

[U-Boot] [PATCH 3/5] tools: omapimage: Fix mismatch of image size in header

[Lokesh Vutla]

The size field in GP header that is expected by ROM is size of the
image + size of the header. But omapimage tool is updating size
as image size + 2 * header size. Remove this extra header size bytes.

Reported-by: Denys Dmytriyenko 
Debugged-by: Madan Srinivas 
Signed-off-by: Lokesh Vutla 
---
 tools/omapimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/omapimage.c b/tools/omapimage.c
index e7c46388f4..01e02649e1 100644
--- a/tools/omapimage.c
+++ b/tools/omapimage.c
@@ -145,7 +145,7 @@ static void omapimage_set_header(void *ptr, struct stat 
*sbuf, int ifd,
toc++;
memset(toc, 0xff, sizeof(*toc));
 
-   gph_set_header(gph, sbuf->st_size - OMAP_CH_HDR_SIZE + GPIMAGE_HDR_SIZE,
+   gph_set_header(gph, sbuf->st_size - OMAP_CH_HDR_SIZE,
   params->addr, 0);
 
if (strncmp(params->imagename, "byteswap", 8) == 0) {
-- 
2.15.1

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

[U-Boot] [PATCH 5/5] board: ti: dra76: mux wakeup2 as gpio1_2

[Lokesh Vutla]

From: Tomi Valkeinen 

gpio1_2 is used for HPD interrupt with DRA76's DVI add-on board, so mux
the pin as gpio and PIN_INPUT.

Signed-off-by: Tomi Valkeinen 
---
 board/ti/dra7xx/mux_data.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 3c3a19a0e1..b5dcaa584a 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -882,7 +882,7 @@ const struct pad_conf_entry dra76x_core_padconf_array[] = {
{I2C2_SCL, (M1 | PIN_INPUT_PULLUP)},/* i2c2_scl.hdmi1_ddc_sda */
{WAKEUP0, (M14 | PIN_OUTPUT)},  /* N/A.gpio1_0 */
{WAKEUP1, (M14 | PIN_OUTPUT)},  /* N/A.gpio1_1 */
-   {WAKEUP2, (M1 | PIN_OUTPUT)},   /* N/A.sys_nirq2 */
+   {WAKEUP2, (M14 | PIN_INPUT)},   /* N/A.gpio1_2 */
{WAKEUP3, (M1 | PIN_OUTPUT)},   /* N/A.sys_nirq1 */
 };
 
-- 
2.15.1

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

[U-Boot] [PATCH 07/13] board: ti: am574x-idk: Add epprom support

[Lokesh Vutla]

am574x-idk is a board based on TI's am574 processor
Add eeprom support.

Signed-off-by: Lokesh Vutla 
---
 board/ti/am57xx/board.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index f79aefd400..082346d2b1 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -43,6 +43,7 @@
 #define board_is_am572x_evm_reva3()\
(board_ti_is("AM572PM_") && \
 !strncmp("A.30", board_ti_get_rev(), 3))
+#define board_is_am574x_idk()  board_ti_is("AM574IDK")
 #define board_is_am572x_idk()  board_ti_is("AM572IDK")
 #define board_is_am571x_idk()  board_ti_is("AM571IDK")
 
@@ -481,6 +482,8 @@ void do_board_detect(void)
bname = "BeagleBoard X15";
else if (board_is_am572x_evm())
bname = "AM572x EVM";
+   else if (board_is_am574x_idk())
+   bname = "AM574x IDK";
else if (board_is_am572x_idk())
bname = "AM572x IDK";
else if (board_is_am571x_idk())
@@ -513,6 +516,8 @@ static void setup_board_eeprom_env(void)
name = "am57xx_evm_reva3";
else
name = "am57xx_evm";
+   } else if (board_is_am574x_idk()) {
+   name = "am574x_idk";
} else if (board_is_am572x_idk()) {
name = "am572x_idk";
} else if (board_is_am571x_idk()) {
-- 
2.15.1

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

[U-Boot] [PATCH 13/13] env: ti: Select dtb name for dra76x and am574

[Lokesh Vutla]

Select dtb name for am574x-idk and dra76x evm with acd package.

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

diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h
index 799d9840aa..0a2342061c 100644
--- a/include/environment/ti/boot.h
+++ b/include/environment/ti/boot.h
@@ -67,7 +67,7 @@
"setenv fdtfile dra72-evm.dtb; fi;" \
"if test $board_name = dra71x; then " \
"setenv fdtfile dra71-evm.dtb; fi;" \
-   "if test $board_name = dra76x; then " \
+   "if test $board_name = dra76x_acd; then " \
"setenv fdtfile dra76-evm.dtb; fi;" \
"if test $board_name = beagle_x15; then " \
"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
@@ -77,6 +77,8 @@
"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 = am574x_idk; then " \
+   "setenv fdtfile am574x-idk.dtb; fi;" \
"if test $board_name = am57xx_evm; then " \
"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
"if test $board_name = am57xx_evm_reva3; then " \
-- 
2.15.1

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

[U-Boot] [PATCH 11/13] board: ti: am57xx: Enable CMD_DDR3

[Lokesh Vutla]

Enable CMD_DDR3 on all am57xx based platforms.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/omap5/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/omap5/Kconfig 
b/arch/arm/mach-omap2/omap5/Kconfig
index 8c1730a6be..deb9873cc5 100644
--- a/arch/arm/mach-omap2/omap5/Kconfig
+++ b/arch/arm/mach-omap2/omap5/Kconfig
@@ -39,6 +39,7 @@ config TARGET_AM57XX_EVM
select BOARD_LATE_INIT
select DRA7XX
select TI_I2C_BOARD_DETECT
+   select CMD_DDR3
imply SCSI
imply SPL_THERMAL
imply DM_THERMAL
-- 
2.15.1

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