[U-Boot] [PATCH] rockchip: update boot0 hook

[Kever Yang]

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 
---

 arch/arm/include/asm/arch-rockchip/boot0.h | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/boot0.h 
b/arch/arm/include/asm/arch-rockchip/boot0.h
index af3a733..65b4213 100644
--- a/arch/arm/include/asm/arch-rockchip/boot0.h
+++ b/arch/arm/include/asm/arch-rockchip/boot0.h
@@ -26,7 +26,6 @@
 */
b 1f /* if overwritten, entry-address is at the next word */
 1:
-#endif
 #if CONFIG_IS_ENABLED(ROCKCHIP_EARLYRETURN_TO_BROM)
adr r3, entry_counter
ldr r0, [r3]
@@ -40,6 +39,15 @@ entry_counter:
.word   0
 #endif
b reset
+
+#if defined(CONFIG_ROCKCHIP_RK3399)
+   .space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM /* space for the ATF data */
+#endif
+
+#elif defined(CONFIG_ARM64) /* U-Boot for arm64 */
+   b reset
+#endif
+
 #if !defined(CONFIG_ARM64)
/*
 * For armv7, the addr '_start' will used as vector start address
@@ -49,7 +57,3 @@ entry_counter:
 _start:
ARM_VECTORS
 #endif
-
-#if defined(CONFIG_ROCKCHIP_RK3399) && defined(CONFIG_SPL_BUILD)
-   .space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM /* space for the ATF data */
-#endif
-- 
1.9.1

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

Re: [U-Boot] [U-Boot, 2/3] rockchip: doc: update U-Boot location info

[Goldschmidt Simon]

>> Update rockchip U-Boot location to 0x4000/16384.
>> 
>> Signed-off-by: Kever Yang 
>> Acked-by: Philipp Tomsich 
>> Reviewed-by: Philipp Tomsich 
>> ---
>> 
>>  doc/README.rockchip | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> 
> 
> Applied to u-boot-rockchip, thanks!

I just found this commit has calculated the size wrong. 16384 blocks should be 
8MB, not 4MB.


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

Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode

[Jagan Teki]

On Fri, Nov 10, 2017 at 12:11 PM, Goldschmidt Simon
 wrote:
> On Mon, Oct 30, 2017 at 7:26 AM, Jagan Teki  wrote:
>> I've similar change on my patchwork, since no-one tested Will CC you by 
>> re-basing it please have test?
>
> Yes, of course I'd like to test this. Where do I find your patch?

Will rebase and send to ML soon.

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

Re: [U-Boot] [PATCH 7/9] net: sun8i_emac: Fix build for non-H3/H5 SoCs

[Jagan Teki]

On Fri, Nov 10, 2017 at 11:34 AM, Chen-Yu Tsai  wrote:
> On Fri, Nov 10, 2017 at 2:01 PM, Jagan Teki  wrote:
>> On Fri, Nov 10, 2017 at 9:52 AM, Chen-Yu Tsai  wrote:
>>> On Wed, Sep 27, 2017 at 11:46 PM, Joe Hershberger
>>>  wrote:
 On Fri, Sep 22, 2017 at 2:26 AM, Chen-Yu Tsai  wrote:
> Only the H3/H5 SoCs have an internal PHY and its related clock and
> reset controls.
>
> Use an #ifdef to guard the internal PHY control code block so it
> can be built for other SoCs, such as the A83T or A64.
>
> Signed-off-by: Chen-Yu Tsai 

 Reviewed-by: Joe Hershberger 
>>>
>>> This hasn't been applied yet. Can someone apply this? Jagan?
>>
>> Few emac patches on this series still under review, was this independent fix?
>
> I would consider it an independent fix. Nothing prevents people from
> manually enabling the EMAC driver on other SoCs. They will then get
> a build fail that this patch fixes.
>
> As for the other patches, I respin them soon enough.

Applied to u-boot-sunxi/master

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

Re: [U-Boot] [PATCH v4 1/7] armv8: lsch3: Add serdes and DDR voltage setup

[Rajesh Bhagat]

> -Original Message-
> From: York Sun
> Sent: Thursday, November 09, 2017 2:02 AM
> To: Rajesh Bhagat ; u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha ; Priyanka Jain
> ; Ashish Kumar 
> Subject: Re: [PATCH v4 1/7] armv8: lsch3: Add serdes and DDR voltage setup
> 
> On 11/07/2017 02:37 AM, Rajesh Bhagat wrote:
> > Adds SERDES voltage and reset SERDES lanes API and makes
> > enable/disable DDR controller support 0.9V API common.
> >
> > Signed-off-by: Ashish Kumar 
> > Signed-off-by: Rajesh Bhagat 
> > ---
> > Changes in v4:
> >   - Added local macros instead of magical numbers
> >   - Created macros to remove duplicate code
> >
> > Changes in v3:
> >  Restructured LS1088A VID support to use common VID driver  Cosmetic
> > review comments fixed  Added __iomem for accessing registers
> >
> > Changes in v2:
> >  Checkpatch errors fixed
> >
> >  .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c| 263
> +
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c|  34 +--
> >  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   2 +-
> >  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  34 +++
> >  arch/arm/include/asm/arch-fsl-layerscape/soc.h |   1 +
> >  5 files changed, 316 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> > index 179cac6..6fbfbed 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> > @@ -158,6 +158,269 @@ void serdes_init(u32 sd, u32 sd_addr, u32 rcwsr, u32
> sd_prctl_mask,
> > serdes_prtcl_map[NONE] = 1;
> >  }
> >
> > +__weak int get_serdes_volt(void)
> > +{
> > +   return -1;
> > +}
> > +
> > +__weak int set_serdes_volt(int svdd)
> > +{
> > +   return -1;
> > +}
> > +
> > +#define LNAGCR0_RESET_MASK 0xFF9F
> > +#define LNAGCR0_RT_RSTB0x0060
> > +#define RSTCTL_RESET_MASK_10xFFBF
> > +#define RSTCTL_RESET_MASK_20xFF1F
> > +#define RSTCTL_RESET_MASK_30xFFEF
> > +#define RSTCTL_RSTREQ  0x8000
> > +#define RSTCTL_RSTERR  0x2000
> > +#define RSTCTL_SDEN0x0020
> > +#define RSTCTL_SDRST_B 0x0040
> > +#define RSTCTL_PLLRST_B0x0080
> > +#define RSTCTL_RST_DONE0x4000
> > +#define TCALCR_RESET_MASK  0xF7FF
> > +#define TCALCR_CALRST_B0x0800
> > +
> > +#define CAT2(x, y) CAT2_(x, y)
> > +#define CAT2_(x, y) x ## y
> > +
> > +#define CAT3(x, y, z) CAT3_(x, y, z)
> > +#define CAT3_(x, y, z) x ## y ## z
> > +
> > +#define DO_ENABLED_LANES_RESET(x) do { 
> > \
> > +   cfg_tmp = CAT2(cfg_rcwsrds, x) &\
> > +   CAT3(FSL_CHASSIS3_SRDS, x, _PRTCL_MASK);\
> > +   cfg_tmp >>= CAT3(FSL_CHASSIS3_SRDS, x, _PRTCL_SHIFT);   \
> > +   \
> > +   for (i = 0; i < 4 && cfg_tmp & (0xf << (3 - i)); i++) { \
> > +   reg = in_le32((serdes, x, _base)->lane[i].gcr0);   \
> > +   reg &= LNAGCR0_RESET_MASK;  \
> > +   out_le32((serdes, x, _base)->lane[i].gcr0, reg);   \
> > +   }   \
> > +} while (0)
> > +
> 
> I don't like these macros. They break grep-ability. I understand you are 
> trying to
> simply the code and reuse. There are other technique to do the same. I 
> personally
> would use local functions with pointers to deal with serdes base, and use 
> array to
> handle things like FSL_CHASSIS3_SRDS1_PRTCL_SHIFT and masks.
> 

Will take care in v5

- Rajesh

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

Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode

[Goldschmidt Simon]

On Mon, Oct 30, 2017 at 7:26 AM, Jagan Teki  wrote:
> I've similar change on my patchwork, since no-one tested Will CC you by 
> re-basing it please have test?

Yes, of course I'd like to test this. Where do I find your patch?

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

Re: [U-Boot] [PATCH] spi: kirkwood: avoid divide by zero crash

[Jagan Teki]

On Thu, Nov 9, 2017 at 5:09 PM, Baruch Siach  wrote:
> Calling .set_speed with zero speed is definitely a bug. Return an error value
> to handle that gracefully instead of crashing.
>
> Signed-off-by: Baruch Siach 
> ---
>  drivers/spi/kirkwood_spi.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
> index 0c6bd295cde9..9a27ac36822e 100644
> --- a/drivers/spi/kirkwood_spi.c
> +++ b/drivers/spi/kirkwood_spi.c
> @@ -257,6 +257,8 @@ static int mvebu_spi_set_speed(struct udevice *bus, uint 
> hz)
> struct kwspi_registers *reg = plat->spireg;
> u32 data;
>
> +   if (hz == 0)
> +   return -EINVAL;

This isn't true, if hz 0 we should go with minimum divizer, usually
tclk we can get it from dts as plat->frequency and check the same with
speed to get the final speed.

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

Re: [U-Boot] [PATCH 7/9] net: sun8i_emac: Fix build for non-H3/H5 SoCs

[Chen-Yu Tsai]

On Fri, Nov 10, 2017 at 2:01 PM, Jagan Teki  wrote:
> On Fri, Nov 10, 2017 at 9:52 AM, Chen-Yu Tsai  wrote:
>> On Wed, Sep 27, 2017 at 11:46 PM, Joe Hershberger
>>  wrote:
>>> On Fri, Sep 22, 2017 at 2:26 AM, Chen-Yu Tsai  wrote:
 Only the H3/H5 SoCs have an internal PHY and its related clock and
 reset controls.

 Use an #ifdef to guard the internal PHY control code block so it
 can be built for other SoCs, such as the A83T or A64.

 Signed-off-by: Chen-Yu Tsai 
>>>
>>> Reviewed-by: Joe Hershberger 
>>
>> This hasn't been applied yet. Can someone apply this? Jagan?
>
> Few emac patches on this series still under review, was this independent fix?

I would consider it an independent fix. Nothing prevents people from
manually enabling the EMAC driver on other SoCs. They will then get
a build fail that this patch fixes.

As for the other patches, I respin them soon enough.

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

[U-Boot] [PATCH][v2] armv8: fsl-layerscape: Add support of disabling core prefetch

[Prabhakar Kushwaha]

Instruction prefetch feature is by default enabled during core
release.

This patch add support of disabling instruction prefetch by setting
core mask in PPA. Here each core mask bit represents a core and
prefetch is disabled at the time of core release.

Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2:  Updated README

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 38 ++
 .../armv8/fsl-layerscape/doc/README.core_prefetch  | 20 
 2 files changed, 58 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index ab5d76e..d082629 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -29,6 +29,7 @@
 #include 
 #endif
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -494,6 +495,41 @@ static inline int check_psci(void)
return 0;
 }
 
+static void config_core_prefetch(void)
+{
+   char *buf = NULL;
+   char buffer[HWCONFIG_BUFFER_SIZE];
+   const char *prefetch_arg = NULL;
+   size_t arglen;
+   unsigned int mask;
+   struct pt_regs regs;
+
+   if (env_get_f("hwconfig", buffer, sizeof(buffer)) > 0)
+   buf = buffer;
+
+   prefetch_arg = hwconfig_subarg_f("core_prefetch", "disable",
+, buf);
+
+   if (prefetch_arg) {
+   mask = simple_strtoul(prefetch_arg, NULL, 0) & 0xff;
+   if (mask & 0x1) {
+   printf("Core0 prefetch can't be disabled\n");
+   return;
+   }
+
+#define SIP_PREFETCH_DISABLE_64 0xC200FF13
+   regs.regs[0] = SIP_PREFETCH_DISABLE_64;
+   regs.regs[1] = mask;
+   smc_call();
+
+   if (regs.regs[0])
+   printf("Prefetch disable config failed for mask ");
+   else
+   printf("Prefetch disable config passed for mask ");
+   printf("0x%x\n", mask);
+   }
+}
+
 int arch_early_init_r(void)
 {
 #ifdef CONFIG_SYS_FSL_ERRATUM_A009635
@@ -521,6 +557,8 @@ int arch_early_init_r(void)
fsl_rgmii_init();
 #endif
 
+   config_core_prefetch();
+
 #ifdef CONFIG_SYS_HAS_SERDES
fsl_serdes_init();
 #endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch 
b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
new file mode 100644
index 000..85cf6ab
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
@@ -0,0 +1,20 @@
+Core instruction prefetch disable
+-
+To disable instruction prefetch of core; hwconfig needs to be updated.
+for e.g.
+setenv hwconfig 'fsl_ddr:bank_intlv=auto;core_prefetch:disable=0x02'
+
+Here 0x02 can be replaced with any valid value except Mask[0] bit. It
+represents 64 bit mask. The 64-bit Mask has one bit for each core.
+Mask[0] = core0
+Mask[1] = core1
+Mask[2] = core2
+etc
+If the bit is set ('b1) in the mask, then prefetch is disabled for
+that core when it is released from reset.
+
+core0 prefetch should not be disabled i.e. Mask[0] should never be set.
+Setting Mask[0] may lead to undefined behavior.
+
+Once disabled, prefetch remains disabled until the next reset.
+There is no function to re-enable prefetch.
-- 
2.7.4

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

Re: [U-Boot] [PATCH 7/9] net: sun8i_emac: Fix build for non-H3/H5 SoCs

[Jagan Teki]

On Fri, Nov 10, 2017 at 9:52 AM, Chen-Yu Tsai  wrote:
> On Wed, Sep 27, 2017 at 11:46 PM, Joe Hershberger
>  wrote:
>> On Fri, Sep 22, 2017 at 2:26 AM, Chen-Yu Tsai  wrote:
>>> Only the H3/H5 SoCs have an internal PHY and its related clock and
>>> reset controls.
>>>
>>> Use an #ifdef to guard the internal PHY control code block so it
>>> can be built for other SoCs, such as the A83T or A64.
>>>
>>> Signed-off-by: Chen-Yu Tsai 
>>
>> Reviewed-by: Joe Hershberger 
>
> This hasn't been applied yet. Can someone apply this? Jagan?

Few emac patches on this series still under review, was this independent fix?

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

Re: [U-Boot] [PATCH] scsi: ceva: Start port in probe

[Simon Glass]

On 2 November 2017 at 08:53, Michal Simek  wrote:
> The patch:
> "dm: ahci: Unwind the confusing init code"
> (sha1: 7cf1afce7fa3fe64189020fe14b93f7326dd0758)
> introduce bug for ceva sata because port didn't start.
> On the other hand the dwc_ahci.c was fixed correctly.
> Do the same change for ceva too.
>
> Signed-off-by: Michal Simek 
> ---
>
>  drivers/ata/sata_ceva.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH] clk: clk_stm32f7: fix PLL clock division factor

[Simon Glass]

On 26 October 2017 at 05:23,   wrote:
> From: Patrice Chotard 
>
> Fix clock division factor initialization for RCC_PLLCFGR
> registers.
>
> PLLR bits (bit 31-28) in RCC_PLLCFGR must not be cleared,
> it's a forbidden value. So update RCC_PLLCFGR using
> clrsetbits_le32() to set only necessary bits fields.
>
> Signed-off-by: Patrice Chotard 
> ---
>  drivers/clk/clk_stm32f7.c | 16 +---
>  1 file changed, 9 insertions(+), 7 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] ata: Fix ahci wording

[Simon Glass]

On 2 November 2017 at 08:55, Michal Simek  wrote:
> s/achi_/ahci_/g
>
> Signed-off-by: Michal Simek 
> ---
>
>  drivers/ata/ahci.c  | 4 ++--
>  drivers/ata/dwc_ahci.c  | 2 +-
>  drivers/ata/sata_ceva.c | 4 ++--
>  include/ahci.h  | 8 
>  4 files changed, 9 insertions(+), 9 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 RFC] Makefile: Extend PYTHONPATH rather than overriding it

[Simon Glass]

On 7 November 2017 at 09:18, Tuomas Tynkkynen  wrote:
> Currently, if the user has compiled the libfdt Python module from dtc
> upstream to a non-default location, it cannot be used because the
> 'PYTHONPATH=tools' assignment wipes out the user's PYTHONPATH.
> Instead, extend PYTHONPATH in the main Makefile instead of overriding it.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  Makefile | 10 --
>  scripts/Makefile.spl |  6 ++
>  2 files changed, 10 insertions(+), 6 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] dm: core: fix member name in ofnode_union documentation

[Simon Glass]

On 9 November 2017 at 04:44, Baruch Siach  wrote:
> Fixes: 4984de2baaa ("dm: core: Add ofnode to represent device tree nodes")
> Cc: Simon Glass 
> Signed-off-by: Baruch Siach 
> ---
>  include/dm/ofnode.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH] mmc-uclass: spl: upriv->mmc override by host descriptor address

[Simon Glass]

Hi Jagan,

On 3 November 2017 at 06:05, Jagan Teki  wrote:
> This specific issue observed with SPL_DM_MMC in falcon mode on
> rk3288 which used dw_mmc.c driver.
>
> Bug details:
> ---
> based on the falcon configuration, SPL trying to read the kernel from
> specified sectors, while mmc sending multi-block command(CMD18) the
> host descriptor address here next_addr(from dw_mmc.c, on below Bug log at 
> blk_cnt = 938)
> is trying to override upriv(which further corrupting upriv->mmc) since after
> mmc pointing to wrong address which is causing next commands(CMD12)
> is unable to get the host pointer since it's reading wrong address which
> eventually block the booting at mmc stage.
>
> Bug log:
> ---
> For blk_cnt = 946
> Before: mmc_get_mmc_dev: dev = 0xff716088, upriv = 0x7e088, mmc = 0xff7160fc
> dwmci_set_idma_desc: addr = 0x274dfc0, next_addr = 0x7e080
> After: mmc_get_mmc_dev: dev = 0xff716088, upriv = 0x7e088, mmc = 0xff7160fc
> For blk_cnt = 938
> Before: mmc_get_mmc_dev: dev = 0xff716088, upriv = 0x7e088, mmc = 0xff7160fc
> dwmci_set_idma_desc: addr = 0x274efc0, next_addr = 0x7e0c0
> After: mmc_get_mmc_dev: dev = 0xff716088, upriv = 0x7e088, mmc = 0x274efc0
>
> Based on the above information, this patch is trying to allocate 
> mmc_uclass_priv
> using .priv_auto_alloc_size so if it is zero, the respective uclass driver is
> responsible for allocating any data required. So in this scenario memory is 
> not
> override between upriv->mmc and host description.
>
> mmc_uclass_priv with ..priv_auto_alloc_size:
> 
> For blk_cnt = 938
> Before: mmc_get_mmc_dev: dev = 0xff71608c, upriv = 0x0, mmc = 0xff716100
> dwmci_set_idma_desc: addr = 0x274efc0, next_addr = 0x7e0c0
> After: mmc_get_mmc_dev: dev = 0xff71608c, upriv = 0x0, mmc = 0xff716100
>
> Signed-off-by: Jagan Teki 
> ---
> Note:
> - debug code:
>   https://paste.ubuntu.com/25879159/
> - Bug log:
>   https://paste.ubuntu.com/25879138/
> - Fix log:
>   https://paste.ubuntu.com/25879139/
>
>  drivers/mmc/mmc-uclass.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 5dda20c..cdb0d28 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -299,5 +299,9 @@ UCLASS_DRIVER(mmc) = {
> .id = UCLASS_MMC,
> .name   = "mmc",
> .flags  = DM_UC_FLAG_SEQ_ALIAS,
> +#ifdef CONFIG_SPL_BUILD
> +   .priv_auto_alloc_size = sizeof(struct mmc_uclass_priv),
> +#else
> .per_device_auto_alloc_size = sizeof(struct mmc_uclass_priv),
> +#endif
>  };
> --
> 2.7.4
>

This is so strange, I don't really understand it.

But priv_auto_alloc_size should be used with dev_get_uclass_priv()
which is what the code is using.

priv_auto_alloc_size is used for the uclass' priv-> pointer. We don't
need the uclass to store anything as far as I can tell.

So I am not sure why your fix works, but it seems wrong to me.

But as I say, it is strange, and perhaps there is something else wrong.

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

Re: [U-Boot] [PATCH] arm: config: fix default console only to specify the device

[Simon Glass]

On 27 October 2017 at 22:22,   wrote:
> From: Dongjin Kim 
>
> Since CONFIG_DEFAULT_CONSOLE is already started with "console=",
> the console argument in CONFIG_EXTRA_ENV_SETTINGS is expanded to
> "console=console=ttySAC1,115200n8" and this causes the wrong
> console device.
>
>   #define CONFIG_DEFAULT_CONSOLE "console=ttySAC1,115200n8\0"
>   ...
>   #define CONFIG_EXTRA_ENV_SETTINGS \
> "console=" CONFIG_DEFAULT_CONSOLE
>
> Signed-off-by: Dongjin Kim 
> ---
>  include/configs/odroid.h| 4 ++--
>  include/configs/odroid_xu3.h| 4 ++--
>  include/configs/s5p_goni.h  | 4 ++--
>  include/configs/s5pc210_universal.h | 4 ++--
>  include/configs/trats.h | 4 ++--
>  include/configs/trats2.h| 4 ++--
>  6 files 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] Rockchip GRF/PMUGRF/CRU reg access in U-Boot

[Simon Glass]

Hi,

On 23 October 2017 at 01:35, Kever Yang  wrote:
> Philipp,
>
>
> On 10/20/2017 05:00 PM, Dr. Philipp Tomsich wrote:
>>
>> Kever,
>>
>>> On 20 Oct 2017, at 03:59, Kever Yang  wrote:
>>>
>>> Hi Simon and Philipp.
>>>
>>>  I would like to include Heiko who is maintainer of upstream kernel
>>> Rockchip SoC for this topic.
>>>
>>> For the driver related to grf, which including pinctrl, usb phy, gmac and
>>> many other modules, we would like to sync with kernel, so that we can re-use
>>> the dtsi from kernel. The use of grf register have many discuss on upstream
>>> kernel already, and all modules use grf with a  reference and offset in
>>> dts.
>>>
>>> U-Boot coding style says "Use structures for I/O access", in my opinion,
>>> this is good for most case, but not for registers like Rockchip grf, because
>>> it's related for many modules, and it's different in different SoC, use
>>> "base addr + offset" for grf reg in dtsi and decode it in driver is much
>>> more reasonable for grf related driver setting. Just like the line size 80
>>> is max, we follow the rule in most case, but in some case, more than 80
>>> characters is better for read, then we use more than 80 characters. We can
>>> merge pinctrl driver into one file like kernel if we can use this feature,
>>> and the same with sysreset, soft reset...We are not going to follow the dead
>>> rules for all cases, we have to use the one which is better for us.
>>>
>>> To make it more clear, here is an example:
>>>
>>> Looking at drivers/sysreset/sysreset_rk3xxx.c(there are 8 files and more
>>> to come), the source code are almost the same, the only difference is the
>>> reg address of glb_srst_snd_value and glb_srst_fst_value in cru,  we can
>>> very easy to decode this from dts in one common driver if we use 'base +
>>> offset'. If we insist on using structure for this kind of reg access, to
>>> merge them into one common driver we have to including all different SoC cru
>>> definition and use different variable for different SoC, there would be many
>>> '#ifdef ... #else' in the file like this
>>>
>> In the sysreset-case there shouldn’t be a change to the DTSI necessary.
>> The sysreset-drivers are always instantiated from the clock-drivers, as in
>> the following example:
>> static int rk3399_clk_bind(struct udevice *dev)
>> {
>> int ret;
>>
>> /* The reset driver does not have a device node, so bind
>> it here */
>> ret = device_bind_driver(gd->dm_root, "rk3399_sysreset",
>> "reset", );
>> if (ret)
>> printf("Warning: No RK3399 reset driver:
>> ret=%d\n", ret);
>>
>> return 0;
>> }
>>
>> Given this, the offset of the sysreset register in the GRF can be easily
>> passed in during binding the driver by changing this code (the following is
>> just pseudocode w/o error handling) to:
>> struct driver *drv = lists_driver_lookup_name(“rk3399_sysreset”);
>> ulong drv_data = offsetof(grf_struct, sysreset_reg);
>> device_bind_with_driver_data(parent, drv, dev_name, drv_data,
>> gd->dm_root, );
>
>
> Yes, this can be resolved by the API you mentioned, but this is one of a
> typical case if grf reg if there we have to add one dts node for sysreset
> driver.
>
>>
>>
>> And: thank you for getting around to look at the sysreset situation and
>> starting work on deduplicating this.
>>
>>> #ifdef CONFIG_ROCKCHIP_RK3036
>>>
>>> #include 
>>>
>>> #else ifdef CONFIG_ROCKCHIP_RK3188
>>>
>>> #include 
>>>
>>> #else ifdef CONFIG_ROCKCHIP_RK322x
>>>
>>> #include 
>>>
>>> #else ifdef CONFIG_ROCKCHIP_RK3288
>>>
>>> #include 
>>>
>>> #else ifdef CONFIG_ROCKCHIP_RK3328
>>>
>>> #include 
>>>
>>> #else ifdef CONFIG_ROCKCHIP_RK3368
>>>
>>> #include 
>>>
>>> ...
>>> #endif
>>>
>>> and also this is need when we define and use the cru variant.
>>>
>>>
>>> I would like to use two dts decode instead like this for all SoCs:
>>> rphy->grf_base = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
>>> ofnode_read_u32(dev_ofnode(dev), "reg", )
>>> sysreset_reg = rphy->grf_base + reg;
>>>
>>> and dts for different SoC like this:
>>>  rockchip,grf = <>;
>>>  reg = <0x017c>;
>>>
>> The proper coding style in U-Boot would be to use the syscon-functions to
>> perform a read/write to an offset.
>> In other words
>> regmap_read(grf, reg, )
>> should be used to read the location for the above example.
>>
>> Note that his works only, if the layout within these registers is the same
>> across devices.
>
>
> Well, great, that means we can re-use the driver and dts definition from
> kernel for grf regs.
>>
>>
>>> We wish upstream U-Boot can accept this kind of coding, I believe when
>>> the coding style was made, it does not met the controller reg like Rockchip
>>> GRF.
>>
>> In fact the regmap and syscon device classes have always been intended to
>> work exactly for such cases.

Re: [U-Boot] U-Boot SPL/TPL build system

[Simon Glass]

Hi Kever,

On 25 October 2017 at 19:37, Kever Yang  wrote:
>
> Hi Simon,Philipp,
>
> I still confuse about how the SPL/TPL build system works, including what 
> Kconfig will be used,
> and how to write the Makefile suppose to be correct.
>
> I'm trying to enable the SPL/TPL for rk3328, I want to remove all the 
> unnecessary module because the
> ram size is very limited, but the instruction size in aarch64 is lager.
> For example,
> - for debug output, I only want to enable the DEBUG_UART, but not SERIAL_DM 
> and SERAIL_SUPPORT.
> If disable the SPL_SERIAL_DM and SERIAL_SUPPORT, it can not pass the 
> build.

At least one board does this - can you please share the tree and I can look?

> - I don't need interrupt, which vector table need a lot size in aarch64,

Can you leave it out?

> - I don't need panic, this realy dose not help me much, I don't want to 
> enable sysreset in TPL;
>
>
> For the rk3368, I get overflow when I use aarch64 compile tool from ubuntu 
> 14.04:
> aarch64-linux-gnu-ld.bfd: u-boot-tpl section `.u_boot_list' will not fit in 
> region `.sram'
> aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 224 bytes
> If I use the gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu, it won't 
> overflow.

The newer compiler might be better, or might fix a bug.

>
> Thanks,
> - Kever
>

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

Re: [U-Boot] about fdt-control

[Simon Glass]

Hi,

On 25 October 2017 at 09:02, albert008.xu  wrote:
> Dear Simon
>I'm reading doc/README.fdt-control written by U in u-boot source. you
> said CONFIG_OF_EMBED is  defined ,dtb will be built into u-boot image.This
> is suitable for debugging and is not recommended for producton.
> Why CONFIG_OF_EMBED is suitable for debugging? I think CONFIG_OF_EMBED is
> same to CONFIG_OF_SEPARATE.When should
> CONFIG_OF_SEPARATE be used?
> Thankyou
> albert
>

Can you please send this to the mailing list and cc me?

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

Re: [U-Boot] [PATCH 7/9] net: sun8i_emac: Fix build for non-H3/H5 SoCs

[Chen-Yu Tsai]

On Wed, Sep 27, 2017 at 11:46 PM, Joe Hershberger
 wrote:
> On Fri, Sep 22, 2017 at 2:26 AM, Chen-Yu Tsai  wrote:
>> Only the H3/H5 SoCs have an internal PHY and its related clock and
>> reset controls.
>>
>> Use an #ifdef to guard the internal PHY control code block so it
>> can be built for other SoCs, such as the A83T or A64.
>>
>> Signed-off-by: Chen-Yu Tsai 
>
> Reviewed-by: Joe Hershberger 

This hasn't been applied yet. Can someone apply this? Jagan?

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

Re: [U-Boot] [PATCH v5 02/18] rockchip: boot0: align to 0x20 for armv7 '_start'

[Kever Yang]

Andy,


On 11/09/2017 05:03 AM, Dr. Philipp Tomsich wrote:

Andy,

On 9 Nov 2017, at 13:59, Andy Yan  wrote:

Hi Phipipp, Kever:


On 2017年10月10日 22:21, Philipp Tomsich wrote:

From: Kever Yang 

The '_start' is using as vector table base address, and will write
to VBAR register, so it needs to be aligned to 0x20 for armv7.

Signed-off-by: Kever Yang 
[Updated to current code base:]
Signed-off-by: Philipp Tomsich 

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  arch/arm/include/asm/arch-rockchip/boot0.h | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/boot0.h 
b/arch/arm/include/asm/arch-rockchip/boot0.h
index 455d842..f7c6146 100644
--- a/arch/arm/include/asm/arch-rockchip/boot0.h
+++ b/arch/arm/include/asm/arch-rockchip/boot0.h
@@ -6,12 +6,13 @@
/*
   * Execution starts on the instruction following this 4-byte header
- * (containing the magic 'RK33').
+ * (containing the magic 'RK30', 'RK31', 'RK32' or 'RK33').  This
+ * magic constant will be written into the final image by the rkimage
+ * tool, but we need to reserve space for it here.
   *
   * To make life easier for everyone, we build the SPL binary with
   * space for this 4-byte header already included in the binary.
   */
-
  #ifdef CONFIG_SPL_BUILD
/*
 * We need to add 4 bytes of space for the 'RK33' at the
@@ -26,6 +27,15 @@
b reset  /* may be overwritten --- should be 'nop' or a 'b reset' */
  #endif
b reset

 Do we really need the "b reset" here? the macro ARM_VECTORS already has a 
b reset.
Besides Joseph found  that the irq function will not work with this "b reset”

The quoted code was from an older version of the series, but the ‘b reset’ is 
still there
in the newer version.

What IRQ function does not work?
Shouldn't the IRQ be jumping into the ARM_VECTORS and never see the ‘b reset’?


We need the 'b reset' here,  this is not present at the same time with 
ARM_VECTORS,

I think what we need to handle is that we don't need boot0_hook in U-Boot,
let me send a patch to fix this.

Thanks,
- Kever



+#if !defined(CONFIG_ARM64)
+   /*
+* For armv7, the addr '_start' will used as vector start address
+* and write to VBAR register, which needs to aligned to 0x20.
+*/
+   .align(5)
+_start:
+   ARM_VECTORS
+#endif
#if defined(CONFIG_ROCKCHIP_RK3399) && defined(CONFIG_SPL_BUILD)
.space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM /* space for the ATF data */







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

Re: [U-Boot] Pull request: u-boot-sunxi/master

[Tom Rini]

On Thu, Nov 09, 2017 at 05:15:53PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Few fixes for v2017.11, Please pull the same.
> 
> thanks!
> Jagan.
> 
> The following changes since commit 43ede0bca7fc1590b623832b743213b818257a27:
> 
>   Kconfig: Migrate MTDIDS_DEFAULT / MTDPARTS_DEFAULT (2017-11-05 11:21:35 
> -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to 6270a3f035d0bdb5d2283dff4bb568d36ab4c0e3:
> 
>   sunxi: restore PHYLIB for CONFIG_SUN4I_EMAC users (2017-11-09 14:39:30 
> +0530)
> 

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] Please pull u-boot-imx

[Tom Rini]

On Thu, Nov 09, 2017 at 11:35:56AM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> some fixes for 2017.11. Please pull from u-boot-imx, thanks !
> 
> 
> The following changes since commit 7a69604bce9a9a9476753af64e5a1870880c1333:
> 
>   Prepare v2017.11-rc4 (2017-11-06 18:25:37 -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 9c8979cdb76dd65bb0983eb4cb1a895be0f0b1dc:
> 
>   imx7: Add include guards for include/asm/arch-mx7/sys_proto.h file
> (2017-11-09 11:32:49 +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] [PATCH] armv8: fsl-layerscape: Add support of disabling core prefetch

[Prabhakar Kushwaha]

> -Original Message-
> From: York Sun
> Sent: Thursday, November 09, 2017 11:22 PM
> To: Prabhakar Kushwaha ; u-
> b...@lists.denx.de
> Subject: Re: [PATCH] armv8: fsl-layerscape: Add support of disabling core
> prefetch
> 
> On 11/08/2017 06:48 PM, Prabhakar Kushwaha wrote:
> > Instruction prefetch feature is by default enabled during core
> > release.
> >
> > This patch add support of disabling instruction prefetch by setting
> > core mask in PPA. Here each core mask bit represents a core and
> > prefetch is disabled at the time of core release.
> >
> > Signed-off-by: Prabhakar Kushwaha 
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 38
> ++
> >  .../armv8/fsl-layerscape/doc/README.core_prefetch  | 18 ++
> >  2 files changed, 56 insertions(+)
> >  create mode 100644 arch/arm/cpu/armv8/fsl-
> layerscape/doc/README.core_prefetch
> 
> 
> 
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
> > new file mode 100644
> > index 000..f605a4c
> > --- /dev/null
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
> > @@ -0,0 +1,18 @@
> > +Core instruction prefetch disable
> > +-
> > +To disable instruction prefetch of core; hwconfig needs to be updated.
> > +for e.g.
> > +setenv hwconfig 'fsl_ddr:bank_intlv=auto;core_prefetch:disable=0x02'
> > +
> 
> Why would one want to disable prefetch? 

There are scenario where data flow happening from device memory. 
So one want to avoid prefetching of instruction as prefetch information may be 
wrong.  
Prefetching instruction and then throwing causes performance drop. 

Hemant can you please help with more details here. 

> And environmental variables are not available for some SPL boot (eg. SD) last 
> time I check.
This feature is only required for non-boot core. Hence prefetch will never be 
disabled for core0.

--prabhakar


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

Re: [U-Boot] Universal Flash Storage - controllers

[Tom Rini]

On Thu, Nov 09, 2017 at 10:42:26AM +0100, Jorge Ramirez wrote:

> Hi all,
> 
> Is there any work in progress - maybe a topic branch?  to bring in Universal
> Flash Storage support into u-boot?

As far as I know, no, no one has done any work there just yet.  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] gpt: add part-uuid and part-num subcommands

[Lukasz Majewski]

On Thu, 9 Nov 2017 07:34:44 -0800
Andrey Yurovsky  wrote:

> On Thu, Nov 9, 2017 at 1:55 AM, Lukasz Majewski
>  wrote:
> > Hi Andrey,
> >  
> >> Hi Otavio,
> >>
> >> On Wed, Nov 8, 2017 at 2:47 AM, Otavio Salvador
> >>  wrote:  
> >> > On Tue, Nov 7, 2017 at 10:43 PM, your name 
> >> > wrote:  
> >> >> From: Andrey Yurovsky 
> >> >>
> >> >> It is useful to be able to retrieve a partition UUID or number
> >> >> given the partition label, for instance some systems use the
> >> >> partition label to indicate the purpose of the partition (such
> >> >> as "rootfs0" being the 0th root file system in an A/B image
> >> >> scheme).
> >> >>
> >> >> Add "gpt part-uuid" to retrieve the partition UUID for a given
> >> >> label and "gpt part-num" to retrieve the partition number for a
> >> >> given label along with some documentation.
> >> >>
> >> >> Signed-off-by: Andrey Yurovsky   
> >> >
> >> > Why not use the 'part' cmd? it provides it.  
> >>
> >> Sorry, I missed the part cmd, it doesn't seem to be documented in
> >> doc/ and it's unclear what  means there.  
> >
> > If I may ask - Andrey, if you are now on this "topic" - would you
> > dare to add some ./doc entry for 'part' command?  
> 
> Yes, I will do that.

Thanks :-)

-- 
Best regards,

Łukasz Majewski


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

[U-Boot] [PATCH] ARM: rmobile: Fix eMMC signal voltage on Salvator-X/XS

[Marek Vasut]

The eMMC is 1V8 device only and the signaling is always 1V8,
fix the DT for Salvator-X/XS to describe the hardware correctly.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 arch/arm/dts/salvator-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/salvator-common.dtsi 
b/arch/arm/dts/salvator-common.dtsi
index ce06a7cbd5..74bb21e841 100644
--- a/arch/arm/dts/salvator-common.dtsi
+++ b/arch/arm/dts/salvator-common.dtsi
@@ -438,7 +438,7 @@
sdhi2_pins: sd2 {
groups = "sdhi2_data8", "sdhi2_ctrl";
function = "sdhi2";
-   power-source = <3300>;
+   power-source = <1800>;
};
 
sdhi2_pins_uhs: sd2_uhs {
-- 
2.11.0

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

Re: [U-Boot] [PATCH] armv8: fsl-layerscape: Add support of disabling core prefetch

[York Sun]

On 11/08/2017 06:48 PM, Prabhakar Kushwaha wrote:
> Instruction prefetch feature is by default enabled during core
> release.
> 
> This patch add support of disabling instruction prefetch by setting
> core mask in PPA. Here each core mask bit represents a core and
> prefetch is disabled at the time of core release.
> 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 38 
> ++
>  .../armv8/fsl-layerscape/doc/README.core_prefetch  | 18 ++
>  2 files changed, 56 insertions(+)
>  create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch



> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch 
> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
> new file mode 100644
> index 000..f605a4c
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
> @@ -0,0 +1,18 @@
> +Core instruction prefetch disable
> +-
> +To disable instruction prefetch of core; hwconfig needs to be updated.
> +for e.g.
> +setenv hwconfig 'fsl_ddr:bank_intlv=auto;core_prefetch:disable=0x02'
> +

Why would one want to disable prefetch? And environmental variables are
not available for some SPL boot (eg. SD) last time I check.

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

Re: [U-Boot] [PATCH] driver: net: ldpaa_eth: Add PHY-less SGMII support

[York Sun]

On 11/08/2017 09:16 PM, Ashish Kumar wrote:
> -Original Message-
> From: York Sun 
> Sent: Thursday, November 09, 2017 2:07 AM
> To: Ashish Kumar ; u-boot@lists.denx.de
> Cc: joe.hershber...@ni.com; Prabhakar Kushwaha 
> Subject: Re: [PATCH] driver: net: ldpaa_eth: Add PHY-less SGMII support
> 
> On 11/06/2017 01:09 AM, Ashish Kumar wrote:
>> In case of PHY-less mode, there is no interaction with PHY so auto-neg 
>> etc is not required and link will have fixed attributes
>>
>> Signed-off-by: Ashish Kumar 
>> Signed-off-by: Prabhakar Kushwaha 
>> ---
>>  drivers/net/ldpaa_eth/ldpaa_eth.c | 9 +++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c 
>> b/drivers/net/ldpaa_eth/ldpaa_eth.c
>> index 21be79a..85e7faa 100644
>> --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
>> +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
>> @@ -440,12 +440,17 @@ static int ldpaa_eth_open(struct eth_device *net_dev, 
>> bd_t *bd)
>>  bus = wriop_get_mdio(priv->dpmac_id);
>>  enet_if = wriop_get_enet_if(priv->dpmac_id);
>>  if ((bus == NULL) &&
>> -(enet_if == PHY_INTERFACE_MODE_XGMII)) {
>> +   ((enet_if == PHY_INTERFACE_MODE_XGMII) ||
>> +   (enet_if == PHY_INTERFACE_MODE_SGMII))) {
>>  priv->phydev = (struct phy_device *)
>>  malloc(sizeof(struct phy_device));
>>  memset(priv->phydev, 0, sizeof(struct phy_device));
>>  
>> -priv->phydev->speed = SPEED_1;
>> +if (enet_if == PHY_INTERFACE_MODE_XGMII)
>> +priv->phydev->speed = SPEED_1;
>> +else
>> +priv->phydev->speed = SPEED_1000;
>> +
>>  priv->phydev->link = 1;
>>  priv->phydev->duplex = DUPLEX_FULL;
>>  }
>>
> 
> How was this patch tested?
> 
>> It can be tested with PHY-less SGMII riser cards after adding patches 
>> attached. 
>> With the existing Riser card, which are PHY enabled, the test is that PHYs 
>> are not configured by adding these to patches.
> 
>> Do you suggest to add these patches in upstream?
> 

Ashish,

This patch seems OK. But it is only effective with the other two patches
you mentioned, isn't it? Please find a proper way to enable SGMII_PHYLIB
using Kconfig.

York


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

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Andre Przywara]

Hi,

On 09/11/17 15:23, Jagan Teki wrote:
> Hi Andre,
> 
> On Thu, Nov 9, 2017 at 5:48 PM, Andre Przywara  wrote:
>> Hi,
>>
>> On 09/11/17 12:11, Maxime Ripard wrote:
>>> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
 Hi,

 I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
 able to fit new features like falcon. I knew the limit about 32K but
 page[1] stating that we can use approximately 192 KiB of contiguous
 SRAM.

 eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
 because I've tried with 64K SPL size with existing SPL code and was
 able to boot, but with increasing SPL by enabling falcon seems like
 BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>>
>>> I've been able to use the falcon mode without this change on an A33,
>>> what's so different about the A64?
>>
>> That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
>> exceed 32KB (we are quite close already)
>>
>> Jagan: you could try this branch of mine [1], this enables a 32-bit SPL,
>> which is smaller than the AArch64 version.
>> You might be able to include Falcon there, but I am afraid you have to
>> work out how to boot a 64-bit kernel from there and how to enable SMP.
>>
>> Hence my question about the pain you want to endure and if those 500ms
>> are really worth it.
>>
>> Cheers,
>> Andre
>>
>> [1] https://github.com/apritzel/u-boot/commits/a64-fel32-wip
> 
> Looking at the "32-bit SPL" patch [2], commit message "so a 32-bit SPL
> can be combined with a 64-bit U-Boot" Does this means we need to build
> U-Boot proper for 64-bit compiler with pine64_plus_defconfig and SPL
> for 32-bit compiler with sun50i_spl32_defconfig?

Well, yes. One thing is the issue you mention below, which should be
easy to fix (was just too lazy to look at it).
But more importantly a 32-bit U-Boot proper only allows you to boot
32-bit kernels, which is interesting, but not my goal.
Also AFAIK you can't build a 32-bit mainline kernel for an A64 out of
the box.

I just build the SPL from this tree and use it for FEL booting.
Another use case is your's, when you want more features and this exceeds
the maximum SPL size on AArch64.

Those patches were part of my original A64 SPL series, so I also keep
them around just in case.

So: Yes, I build this tree with an ARM cross-compiler, copy
spl/sunxi-spl.bin somewhere, then build again (after make clean) with an
Aarch64 cross compiler and combine the pieces manually, for instance:

$ sunxi-fel -v -p spl /tmp/sunxi-spl32.bin write 0x44000 bl31.bin write
0x4a00 u-boot.bin reset64 0x44000

or:

$ cat /tmp/sunxi-spl32.bin u-boot.itb > u-boot-sunxi-with-spl.bin

(which would be your use case).

This nastiness is one of the reasons I haven't tried to upstream this yet.

Cheers,
Andre.

> because I've tried of
> sun50i_spl32 with 32-bit compiler ended with build issue.
> 
> Build log:
> --
>   MKIMAGE u-boot.img
>   BINMAN  u-boot-sunxi-with-spl.bin
> binman: Device tree 'u-boot.dtb' does not have a 'binman' node
> Makefile:1157: recipe for target 'u-boot-sunxi-with-spl.bin' failed
> make: *** [u-boot-sunxi-with-spl.bin] Error 1
> 
> Look like it is not taking CONFIG_SPL_FIT_GENERATOR script.
> 
> [2] 
> https://github.com/apritzel/u-boot/commit/5f1fe133aabfd0c3c5867c453cb405d9624e52ce
> 
> thanks!
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/3] net: xilinx_axi_emac: Add support for non processor mode

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Add support for non processor mode, this mode doesn't have
access to some of the registers and hence this patch
bypasses it and also length has to be calculated from
status instead of app4 in this mode.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 drivers/net/xilinx_axi_emac.c | 41 +
 1 file changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/net/xilinx_axi_emac.c b/drivers/net/xilinx_axi_emac.c
index 4f2cef8a38d0..7761cd5d4e41 100644
--- a/drivers/net/xilinx_axi_emac.c
+++ b/drivers/net/xilinx_axi_emac.c
@@ -51,6 +51,8 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define XAE_MDIO_DIV_DFT   29  /* Default MDIO clock divisor */
 
+#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007F /* Actual len */
+
 /* DMA macros */
 /* Bitmasks of XAXIDMA_CR_OFFSET register */
 #define XAXIDMA_CR_RUNSTOP_MASK0x0001 /* Start/stop DMA channel */
@@ -90,6 +92,7 @@ struct axidma_priv {
phy_interface_t interface;
struct phy_device *phydev;
struct mii_dev *bus;
+   u8 eth_hasnobuf;
 };
 
 /* BD descriptors */
@@ -359,17 +362,23 @@ static int axi_ethernet_init(struct axidma_priv *priv)
 * for the Sgmii and 1000BaseX PHY interfaces. No other register reads
 * will be valid until this bit is valid.
 * The bit is always a 1 for all other PHY interfaces.
+* Interrupt status and enable registers are not available in non
+* processor mode and hence bypass in this mode
 */
-   err = wait_for_bit(__func__, (const u32 *)>is,
-  XAE_INT_MGTRDY_MASK, true, 200, false);
-   if (err) {
-   printf("%s: Timeout\n", __func__);
-   return 1;
-   }
+   if (!priv->eth_hasnobuf) {
+   err = wait_for_bit(__func__, (const u32 *)>is,
+  XAE_INT_MGTRDY_MASK, true, 200, false);
+   if (err) {
+   printf("%s: Timeout\n", __func__);
+   return 1;
+   }
 
-   /* Stop the device and reset HW */
-   /* Disable interrupts */
-   out_be32(>ie, 0);
+   /*
+* Stop the device and reset HW
+* Disable interrupts
+*/
+   out_be32(>ie, 0);
+   }
 
/* Disable the receiver */
out_be32(>rcw1, in_be32(>rcw1) & ~XAE_RCW1_RX_MASK);
@@ -378,8 +387,10 @@ static int axi_ethernet_init(struct axidma_priv *priv)
 * Stopping the receiver in mid-packet causes a dropped packet
 * indication from HW. Clear it.
 */
-   /* Set the interrupt status register to clear the interrupt */
-   out_be32(>is, XAE_INT_RXRJECT_MASK);
+   if (!priv->eth_hasnobuf) {
+   /* Set the interrupt status register to clear the interrupt */
+   out_be32(>is, XAE_INT_RXRJECT_MASK);
+   }
 
/* Setup HW */
/* Set default MDIO divisor */
@@ -579,8 +590,11 @@ static int axiemac_recv(struct udevice *dev, int flags, 
uchar **packetp)
temp = in_be32(>dmarx->control);
temp &= ~XAXIDMA_IRQ_ALL_MASK;
out_be32(>dmarx->control, temp);
+   if (!priv->eth_hasnobuf)
+   length = rx_bd.app4 & 0x; /* max length mask */
+   else
+   length = rx_bd.status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
 
-   length = rx_bd.app4 & 0x; /* max length mask */
 #ifdef DEBUG
print_buffer(, [0], 1, length, 16);
 #endif
@@ -718,6 +732,9 @@ static int axi_emac_ofdata_to_platdata(struct udevice *dev)
}
priv->interface = pdata->phy_interface;
 
+   priv->eth_hasnobuf = fdtdec_get_bool(gd->fdt_blob, dev->of_offset,
+"xlnx,eth-hasnobuf");
+
printf("AXI EMAC: %lx, phyaddr %d, interface %s\n", (ulong)priv->iobase,
   priv->phyaddr, phy_string_for_interface(priv->interface));
 
-- 
1.9.1

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

[U-Boot] [PATCH 2/3] net: xilinx_axi_emac: Read dma address using fdtdec_get_addr

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Read dma address using fdtdec_get_addr as it checks for
address cells and size cells and reads the address
properly. fdtdec_get_int always assume address is of int
size which goes wrong if using it on 64-bit architecture.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

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

diff --git a/drivers/net/xilinx_axi_emac.c b/drivers/net/xilinx_axi_emac.c
index ea79b7420ab9..4f2cef8a38d0 100644
--- a/drivers/net/xilinx_axi_emac.c
+++ b/drivers/net/xilinx_axi_emac.c
@@ -694,8 +694,8 @@ static int axi_emac_ofdata_to_platdata(struct udevice *dev)
printf("%s: axistream is not found\n", __func__);
return -EINVAL;
}
-   priv->dmatx = (struct axidma_reg *)fdtdec_get_int(gd->fdt_blob,
- offset, "reg", 0);
+   priv->dmatx = (struct axidma_reg *)fdtdec_get_addr(gd->fdt_blob,
+ offset, "reg");
if (!priv->dmatx) {
printf("%s: axi_dma register space not found\n", __func__);
return -EINVAL;
-- 
1.9.1

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

[U-Boot] [PATCH 1/3] net: xilinx_axi_emac: Use wait_for_bit instead of while loop

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Use wait_for_bit instead while loop during init

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 drivers/net/xilinx_axi_emac.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/net/xilinx_axi_emac.c b/drivers/net/xilinx_axi_emac.c
index 25c66c6098b9..ea79b7420ab9 100644
--- a/drivers/net/xilinx_axi_emac.c
+++ b/drivers/net/xilinx_axi_emac.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -350,7 +351,7 @@ static void axiemac_stop(struct udevice *dev)
 static int axi_ethernet_init(struct axidma_priv *priv)
 {
struct axi_regs *regs = priv->iobase;
-   u32 timeout = 200;
+   int err;
 
/*
 * Check the status of the MgtRdy bit in the interrupt status
@@ -359,11 +360,9 @@ static int axi_ethernet_init(struct axidma_priv *priv)
 * will be valid until this bit is valid.
 * The bit is always a 1 for all other PHY interfaces.
 */
-   while (timeout && (!(in_be32(>is) & XAE_INT_MGTRDY_MASK))) {
-   timeout--;
-   udelay(1);
-   }
-   if (!timeout) {
+   err = wait_for_bit(__func__, (const u32 *)>is,
+  XAE_INT_MGTRDY_MASK, true, 200, false);
+   if (err) {
printf("%s: Timeout\n", __func__);
return 1;
}
-- 
1.9.1

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

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Jagan Teki]

Hi Andre,

On Thu, Nov 9, 2017 at 5:48 PM, Andre Przywara  wrote:
> Hi,
>
> On 09/11/17 12:11, Maxime Ripard wrote:
>> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
>>> Hi,
>>>
>>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>>> able to fit new features like falcon. I knew the limit about 32K but
>>> page[1] stating that we can use approximately 192 KiB of contiguous
>>> SRAM.
>>>
>>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>> because I've tried with 64K SPL size with existing SPL code and was
>>> able to boot, but with increasing SPL by enabling falcon seems like
>>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>
>> I've been able to use the falcon mode without this change on an A33,
>> what's so different about the A64?
>
> That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
> exceed 32KB (we are quite close already)
>
> Jagan: you could try this branch of mine [1], this enables a 32-bit SPL,
> which is smaller than the AArch64 version.
> You might be able to include Falcon there, but I am afraid you have to
> work out how to boot a 64-bit kernel from there and how to enable SMP.
>
> Hence my question about the pain you want to endure and if those 500ms
> are really worth it.
>
> Cheers,
> Andre
>
> [1] https://github.com/apritzel/u-boot/commits/a64-fel32-wip

Looking at the "32-bit SPL" patch [2], commit message "so a 32-bit SPL
can be combined with a 64-bit U-Boot" Does this means we need to build
U-Boot proper for 64-bit compiler with pine64_plus_defconfig and SPL
for 32-bit compiler with sun50i_spl32_defconfig? because I've tried of
sun50i_spl32 with 32-bit compiler ended with build issue.

Build log:
--
  MKIMAGE u-boot.img
  BINMAN  u-boot-sunxi-with-spl.bin
binman: Device tree 'u-boot.dtb' does not have a 'binman' node
Makefile:1157: recipe for target 'u-boot-sunxi-with-spl.bin' failed
make: *** [u-boot-sunxi-with-spl.bin] Error 1

Look like it is not taking CONFIG_SPL_FIT_GENERATOR script.

[2] 
https://github.com/apritzel/u-boot/commit/5f1fe133aabfd0c3c5867c453cb405d9624e52ce

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

Re: [U-Boot] Broadwell-DE porting code review

[Stefano Babic]

On 09/11/2017 15:57, vnktux wrote:
> Hi guys,
> 
> For my graduation project I need to port Broadwell-DE in u-boot, and use it 
> as bare-metal bootloader on our platform.
> Our platform currently run Coreboot + U-Boot but of course they want to get 
> rid of the first one. The final 16Mb rom file is created using a tool from 
> Intel that basically combine descriptor + Intel ME, and on the address 
> 0x0080 the 8Mb BIOS region .
> So my u-boot should contain the FSP firmware and vga blob. I started porting 
> some files from the coreboot sourcode (src/soc/intel/fsp_broadwell_de), but 
> my board doesn't boot.
> I am quite stuck right now and I don't know what to do anymore, specially 
> because there are some addressed that I don't know what to get, and also the 
> fsp_conf.c specifications.
> Can any of you guys please do the review of what I have done so far? Nobody 
> in my company has knowledge with x86 platforms and if I don't get feedback I 
> can't continue working on it. The repository is public and available on this 
> link:https://git.drk.sc/WarOfDevil/u-boot.x86_64-broadwell-de


You should apply U-Boot rules. Generate your patches with git-format, or
better, using Simon's patman tool, and post the series to this ML.

> My custom code has been added in the following files/directory:
> - config/poseidon_defconfig
> - board/prodrive/poseidon
> - arch/cpu/broadwell-de
> - arch/include/asm/arch-broadwell-de
> - arch/x86/dts/poseidon.dts
> -arch/x86/dts/microcode/broadwell_de_microcode
> 
> Thanks a lot!
> 

Best regards,
Stefano Babic


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

[U-Boot] Broadwell-DE porting code review

[vnktux]

Hi guys,

For my graduation project I need to port Broadwell-DE in u-boot, and use it as 
bare-metal bootloader on our platform.
Our platform currently run Coreboot + U-Boot but of course they want to get rid 
of the first one. The final 16Mb rom file is created using a tool from Intel 
that basically combine descriptor + Intel ME, and on the address 0x0080 the 
8Mb BIOS region .
So my u-boot should contain the FSP firmware and vga blob. I started porting 
some files from the coreboot sourcode (src/soc/intel/fsp_broadwell_de), but my 
board doesn't boot.
I am quite stuck right now and I don't know what to do anymore, specially 
because there are some addressed that I don't know what to get, and also the 
fsp_conf.c specifications.
Can any of you guys please do the review of what I have done so far? Nobody in 
my company has knowledge with x86 platforms and if I don't get feedback I can't 
continue working on it. The repository is public and available on this 
link:https://git.drk.sc/WarOfDevil/u-boot.x86_64-broadwell-de
My custom code has been added in the following files/directory:
- config/poseidon_defconfig
- board/prodrive/poseidon
- arch/cpu/broadwell-de
- arch/include/asm/arch-broadwell-de
- arch/x86/dts/poseidon.dts
-arch/x86/dts/microcode/broadwell_de_microcode

Thanks a lot!

Best regards,
Vincenzo Bove

Sent with [ProtonMail](https://protonmail.com) Secure Email.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd: zynq: nand: Move board_nand_init() function to board.c

[Michal Simek]

On 8.11.2017 10:24, Wilson Lee wrote:
> Hi Michal,
> 
> On Wed, 2017-11-08 at 08:54 +0100, Michal Simek wrote:
>> On 8.11.2017 03:44, Wilson Lee wrote:
>>>
>>> Putting board_nand_init() function inside NAND driver was not
>>> appropriate
>>> due to it doesn't allow board vendor to customise their NAND
>>> initialization code such as adding NAND lock/unlock code.
>>>
>>> This commit was to move the board_nand_init() function from NAND
>>> driver
>>> to board.c file. This allow customization of board_nand_init()
>>> function.
>>>
>>> Signed-off-by: Wilson Lee 
>>> Cc: Joe Hershberger 
>>> Cc: Keng Soon Cheah 
>>> Cc: Chen Yee Chew 
>>> Cc: Albert Aribaud 
>>> Cc: Michal Simek 
>>> Cc: Siva Durga Prasad Paladugu 
>>> Cc: Scott Wood 
>>> ---
>>>  arch/arm/mach-zynq/include/mach/nand.h |  9 +
>>>  board/xilinx/zynq/board.c  | 10 ++
>>>  drivers/mtd/nand/zynq_nand.c   | 12 +---
>>>  3 files changed, 20 insertions(+), 11 deletions(-)
>>>  create mode 100644 arch/arm/mach-zynq/include/mach/nand.h
>>>
>>> diff --git a/arch/arm/mach-zynq/include/mach/nand.h
>>> b/arch/arm/mach-zynq/include/mach/nand.h
>>> new file mode 100644
>>> index 000..61ef45f
>>> --- /dev/null
>>> +++ b/arch/arm/mach-zynq/include/mach/nand.h
>>> @@ -0,0 +1,9 @@
>>> +/*
>>> + * Copyright (C) 2017 National Instruments Corp.
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +
>>> +void zynq_nand_init(void);
>>> diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
>>> index 90ef542..8bcb830 100644
>>> --- a/board/xilinx/zynq/board.c
>>> +++ b/board/xilinx/zynq/board.c
>>> @@ -9,6 +9,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  
>>> @@ -156,3 +157,12 @@ int dram_init(void)
>>>     return 0;
>>>  }
>>>  #endif
>>> +
>>> +static struct nand_chip nand_chip[CONFIG_SYS_MAX_NAND_DEVICE];
>>> +void board_nand_init(void)
>>> +{
>>> +   struct nand_chip *nand = _chip[0];
>>> +
>>> +   if (zynq_nand_init(nand, 0))
>>> +   puts("ZYNQ NAND init failed\n");
>>> +}
>> This is probably not enough for platforms which don't enable NAND.
>>
>>>
>>> diff --git a/drivers/mtd/nand/zynq_nand.c
>>> b/drivers/mtd/nand/zynq_nand.c
>>> index dec2c41..9be6856 100644
>>> --- a/drivers/mtd/nand/zynq_nand.c
>>> +++ b/drivers/mtd/nand/zynq_nand.c
>>> @@ -1006,7 +1006,7 @@ static int zynq_nand_device_ready(struct
>>> mtd_info *mtd)
>>>     return 0;
>>>  }
>>>  
>>> -static int zynq_nand_init(struct nand_chip *nand_chip, int devnum)
>>> +int zynq_nand_init(struct nand_chip *nand_chip, int devnum)
>>>  {
>>>     struct zynq_nand_info *xnand;
>>>     struct mtd_info *mtd;
>>> @@ -1191,13 +1191,3 @@ fail:
>>>     free(xnand);
>>>     return err;
>>>  }
>>> -
>>> -static struct nand_chip nand_chip[CONFIG_SYS_MAX_NAND_DEVICE];
>>> -
>>> -void board_nand_init(void)
>>> -{
>>> -   struct nand_chip *nand = _chip[0];
>>> -
>>> -   if (zynq_nand_init(nand, 0))
>>> -   puts("ZYNQ NAND init failed\n");
>>> -}
>>>
>> What's the sequence which you want to add?
> 
> Actually we wish to perform a NAND unlock right after the NAND was
> begin initialized. So that, we can do some write operation (ubifs table
> R/W) when we mount it as ubifs.
> 
>> Isn't it better just to include this there or create a hook here?
> 
> I was thinking for adding a hook here before. But, it will be more make
> sense to me if we correct the NAND driver by moving board_nand to
> board.c file.

ok. It means please put there some ifdefs around and can you also please
mark board_nand_init as weak in board.c that boards which include full
board.c file can overwrite it by own function? At least I hope that we
reduce number of duplications.

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

Re: [U-Boot] [PATCH v5 02/18] rockchip: boot0: align to 0x20 for armv7 '_start'

[Dr. Philipp Tomsich]

Andy,

On 9 Nov 2017, at 13:59, Andy Yan  wrote:
> 
> Hi Phipipp, Kever:
> 
> 
> On 2017年10月10日 22:21, Philipp Tomsich wrote:
>> From: Kever Yang 
>> 
>> The '_start' is using as vector table base address, and will write
>> to VBAR register, so it needs to be aligned to 0x20 for armv7.
>> 
>> Signed-off-by: Kever Yang 
>> [Updated to current code base:]
>> Signed-off-by: Philipp Tomsich 
>> 
>> ---
>> 
>> Changes in v5: None
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2: None
>> 
>>  arch/arm/include/asm/arch-rockchip/boot0.h | 14 --
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>> 
>> diff --git a/arch/arm/include/asm/arch-rockchip/boot0.h 
>> b/arch/arm/include/asm/arch-rockchip/boot0.h
>> index 455d842..f7c6146 100644
>> --- a/arch/arm/include/asm/arch-rockchip/boot0.h
>> +++ b/arch/arm/include/asm/arch-rockchip/boot0.h
>> @@ -6,12 +6,13 @@
>>/*
>>   * Execution starts on the instruction following this 4-byte header
>> - * (containing the magic 'RK33').
>> + * (containing the magic 'RK30', 'RK31', 'RK32' or 'RK33').  This
>> + * magic constant will be written into the final image by the rkimage
>> + * tool, but we need to reserve space for it here.
>>   *
>>   * To make life easier for everyone, we build the SPL binary with
>>   * space for this 4-byte header already included in the binary.
>>   */
>> -
>>  #ifdef CONFIG_SPL_BUILD
>>  /*
>>   * We need to add 4 bytes of space for the 'RK33' at the
>> @@ -26,6 +27,15 @@
>>  b reset  /* may be overwritten --- should be 'nop' or a 'b reset' */
>>  #endif
>>  b reset
> 
> Do we really need the "b reset" here? the macro ARM_VECTORS already has a 
> b reset.
> Besides Joseph found  that the irq function will not work with this "b reset”

The quoted code was from an older version of the series, but the ‘b reset’ is 
still there
in the newer version.

What IRQ function does not work?
Shouldn't the IRQ be jumping into the ARM_VECTORS and never see the ‘b reset’?

>> +#if !defined(CONFIG_ARM64)
>> +/*
>> + * For armv7, the addr '_start' will used as vector start address
>> + * and write to VBAR register, which needs to aligned to 0x20.
>> + */
>> +.align(5)
>> +_start:
>> +ARM_VECTORS
>> +#endif
>>#if defined(CONFIG_ROCKCHIP_RK3399) && defined(CONFIG_SPL_BUILD)
>>  .space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM /* space for the ATF data */
> 
> 

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

Re: [U-Boot] [PATCH v5 02/18] rockchip: boot0: align to 0x20 for armv7 '_start'

[Andy Yan]

Hi Phipipp, Kever:


On 2017年10月10日 22:21, Philipp Tomsich wrote:

From: Kever Yang 

The '_start' is using as vector table base address, and will write
to VBAR register, so it needs to be aligned to 0x20 for armv7.

Signed-off-by: Kever Yang 
[Updated to current code base:]
Signed-off-by: Philipp Tomsich 

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  arch/arm/include/asm/arch-rockchip/boot0.h | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/boot0.h 
b/arch/arm/include/asm/arch-rockchip/boot0.h
index 455d842..f7c6146 100644
--- a/arch/arm/include/asm/arch-rockchip/boot0.h
+++ b/arch/arm/include/asm/arch-rockchip/boot0.h
@@ -6,12 +6,13 @@
  
  /*

   * Execution starts on the instruction following this 4-byte header
- * (containing the magic 'RK33').
+ * (containing the magic 'RK30', 'RK31', 'RK32' or 'RK33').  This
+ * magic constant will be written into the final image by the rkimage
+ * tool, but we need to reserve space for it here.
   *
   * To make life easier for everyone, we build the SPL binary with
   * space for this 4-byte header already included in the binary.
   */
-
  #ifdef CONFIG_SPL_BUILD
/*
 * We need to add 4 bytes of space for the 'RK33' at the
@@ -26,6 +27,15 @@
b reset  /* may be overwritten --- should be 'nop' or a 'b reset' */
  #endif
b reset


    Do we really need the "b reset" here? the macro ARM_VECTORS already 
has a b reset.
Besides Joseph found  that the irq function will not work with this "b 
reset"

+#if !defined(CONFIG_ARM64)
+   /*
+* For armv7, the addr '_start' will used as vector start address
+* and write to VBAR register, which needs to aligned to 0x20.
+*/
+   .align(5)
+_start:
+   ARM_VECTORS
+#endif
  
  #if defined(CONFIG_ROCKCHIP_RK3399) && defined(CONFIG_SPL_BUILD)

.space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM /* space for the ATF data */



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

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Maxime Ripard]

On Thu, Nov 09, 2017 at 06:11:58PM +0530, Jagan Teki wrote:
> On Thu, Nov 9, 2017 at 5:48 PM, Andre Przywara  wrote:
> > Hi,
> >
> > On 09/11/17 12:11, Maxime Ripard wrote:
> >> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
> >>> Hi,
> >>>
> >>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
> >>> able to fit new features like falcon. I knew the limit about 32K but
> >>> page[1] stating that we can use approximately 192 KiB of contiguous
> >>> SRAM.
> >>>
> >>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
> >>> because I've tried with 64K SPL size with existing SPL code and was
> >>> able to boot, but with increasing SPL by enabling falcon seems like
> >>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
> >>
> >> I've been able to use the falcon mode without this change on an A33,
> >> what's so different about the A64?
> >
> > That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
> > exceed 32KB (we are quite close already)
> 
> Yes, but with arm32 I didn't see increasing size with SPL_OS_BOOT on
> H3 spl/sunxi-spl.bin size become 24576(24KB) even with falcon-enabled.
> of-course Linux failed to boot. Maxime did you find similar behaviour?
> is falcon worked on A33?

I didn't look at that back then because I wasn't aware that was an
issue, but it worked flawlessly for me, so I'm guessing it didn't add
that much.

But then, like Andre was suggesting, I wasn't using the PSCI stuff
either, which we would also need to compile.

Maxime

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


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

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Andre Przywara]

Hi,

On 09/11/17 12:41, Jagan Teki wrote:
> On Thu, Nov 9, 2017 at 5:48 PM, Andre Przywara  wrote:
>> Hi,
>>
>> On 09/11/17 12:11, Maxime Ripard wrote:
>>> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
 Hi,

 I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
 able to fit new features like falcon. I knew the limit about 32K but
 page[1] stating that we can use approximately 192 KiB of contiguous
 SRAM.

 eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
 because I've tried with 64K SPL size with existing SPL code and was
 able to boot, but with increasing SPL by enabling falcon seems like
 BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>>
>>> I've been able to use the falcon mode without this change on an A33,
>>> what's so different about the A64?
>>
>> That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
>> exceed 32KB (we are quite close already)
> 
> Yes, but with arm32 I didn't see increasing size with SPL_OS_BOOT on
> H3 spl/sunxi-spl.bin size become 24576(24KB) even with falcon-enabled.

That's due to padding when creating the eGON wrapped file. It's rounded
up to multiple of 8KB.
Use "size" on spl/u-boot-spl, that gives you the real information:
$ aarch64-linux-size spl/u-boot-spl
   textdata bss dec hex filename
  31231 376 440   320477d2f spl/u-boot-spl

Cheers,
Andre.

> of-course Linux failed to boot. Maxime did you find similar behaviour?
> is falcon worked on A33?
> 
>>
>> Jagan: you could try this branch of mine [1], this enables a 32-bit SPL,
>> which is smaller than the AArch64 version.
>> You might be able to include Falcon there, but I am afraid you have to
>> work out how to boot a 64-bit kernel from there and how to enable SMP.
> 
> Thanks, let me try this.
> 
> thanks!
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Jagan Teki]

On Thu, Nov 9, 2017 at 5:48 PM, Andre Przywara  wrote:
> Hi,
>
> On 09/11/17 12:11, Maxime Ripard wrote:
>> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
>>> Hi,
>>>
>>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>>> able to fit new features like falcon. I knew the limit about 32K but
>>> page[1] stating that we can use approximately 192 KiB of contiguous
>>> SRAM.
>>>
>>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>> because I've tried with 64K SPL size with existing SPL code and was
>>> able to boot, but with increasing SPL by enabling falcon seems like
>>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>
>> I've been able to use the falcon mode without this change on an A33,
>> what's so different about the A64?
>
> That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
> exceed 32KB (we are quite close already)

Yes, but with arm32 I didn't see increasing size with SPL_OS_BOOT on
H3 spl/sunxi-spl.bin size become 24576(24KB) even with falcon-enabled.
of-course Linux failed to boot. Maxime did you find similar behaviour?
is falcon worked on A33?

>
> Jagan: you could try this branch of mine [1], this enables a 32-bit SPL,
> which is smaller than the AArch64 version.
> You might be able to include Falcon there, but I am afraid you have to
> work out how to boot a 64-bit kernel from there and how to enable SMP.

Thanks, let me try this.

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

Re: [U-Boot] [PATCH] gpt: add part-uuid and part-num subcommands

[Lukasz Majewski]

Hi Andrey,

> Hi Otavio,
> 
> On Wed, Nov 8, 2017 at 2:47 AM, Otavio Salvador
>  wrote:
> > On Tue, Nov 7, 2017 at 10:43 PM, your name 
> > wrote:  
> >> From: Andrey Yurovsky 
> >>
> >> It is useful to be able to retrieve a partition UUID or number
> >> given the partition label, for instance some systems use the
> >> partition label to indicate the purpose of the partition (such as
> >> "rootfs0" being the 0th root file system in an A/B image scheme).
> >>
> >> Add "gpt part-uuid" to retrieve the partition UUID for a given
> >> label and "gpt part-num" to retrieve the partition number for a
> >> given label along with some documentation.
> >>
> >> Signed-off-by: Andrey Yurovsky   
> >
> > Why not use the 'part' cmd? it provides it.  
> 
> Sorry, I missed the part cmd, it doesn't seem to be documented in doc/
> and it's unclear what  means there.

If I may ask - Andrey, if you are now on this "topic" - would you dare
to add some ./doc entry for 'part' command?

> I'll investigate and see if I
> can use it for what I'm trying to do, it looks like it should work.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
Best regards,

Łukasz Majewski


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

[U-Boot] [PATCH 2/2] arm: mvebu: clearfog: update SPI flash DT description

[Baruch Siach]

All current ClearFog SOMs have the SPI flash populated. Enable SPI flash in
the device tree.

Add an alias to the SPI bus so that the 'sf' command can probe the flash on
bus 1.

Add the "spi-flash" compatible string to make the standard SPI flash driver
probe the device.

Signed-off-by: Baruch Siach 
---
 arch/arm/dts/armada-388-clearfog.dts | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/armada-388-clearfog.dts 
b/arch/arm/dts/armada-388-clearfog.dts
index b2dfd5643521..bc52bc0167d3 100644
--- a/arch/arm/dts/armada-388-clearfog.dts
+++ b/arch/arm/dts/armada-388-clearfog.dts
@@ -61,6 +61,7 @@
ethernet1 = 
ethernet2 = 
ethernet3 = 
+   spi1 = 
};
 
chosen {
@@ -330,11 +331,9 @@
status = "okay";
};
 
-   spi@10680 {
+   spi1: spi@10680 {
/*
-* We don't seem to have the W25Q32 on the
-* A1 Rev 2.0 boards, so disable SPI.
-* CS0: W25Q32 (doesn't appear to be present)
+* CS0: W25Q32
 * CS1:
 * CS2: mikrobus
 */
@@ -345,10 +344,9 @@
spi-flash@0 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "w25q32", "jedec,spi-nor";
+   compatible = "w25q32", "jedec,spi-nor", 
"spi-flash";
reg = <0>; /* Chip select 0 */
spi-max-frequency = <300>;
-   status = "disabled";
};
};
 
-- 
2.14.2

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

[U-Boot] [PATCH 1/2] arm: mvebu: clearfog: Fix SPI-NOR flash access

[Baruch Siach]

From: Jon Nettleton 

The production variant of the SPI flash used by the clearfog
devices are based on winbond chips.  Additionally enable
SPI_FLASH_BAR since some variants will have 16MB of flash
that requires this to be enabled.

Remove the default speed and mode; these values are taken from the
device tree when CONFIG_DM_SPI_FLASH is enabled.

Add default bus, so that 'sf' detects the SPI flash by default.

Signed-off-by: Jon Nettleton 
[baruch: remove speed/mode; add bus]
Signed-off-by: Baruch Siach 
---
 configs/clearfog_defconfig | 2 ++
 include/configs/clearfog.h | 5 ++---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 3de204346d88..726c444f6042 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -46,3 +46,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_MVEBU=y
 CONFIG_USB_STORAGE=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MTD=y
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h
index 5061f6c6fd16..f6b442b9461f 100644
--- a/include/configs/clearfog.h
+++ b/include/configs/clearfog.h
@@ -33,9 +33,8 @@
 #define CONFIG_SYS_I2C_SPEED   10
 
 /* SPI NOR flash default params, used by sf commands */
-#define CONFIG_SF_DEFAULT_SPEED100
-#define CONFIG_SF_DEFAULT_MODE SPI_MODE_3
-#define CONFIG_SPI_FLASH_STMICRO
+#define CONFIG_SF_DEFAULT_BUS  1
+#define CONFIG_SPI_FLASH_WINBOND
 
 /*
  * SDIO/MMC Card Configuration
-- 
2.14.2

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

Re: [U-Boot] sunxi: SATA link timeout fix

[Jagan Teki]

On Thu, Nov 9, 2017 at 5:36 PM, Maxime Ripard
 wrote:
> On Thu, Nov 09, 2017 at 05:12:08PM +0530, Jagan Teki wrote:
>> On Thu, Nov 9, 2017 at 3:06 PM, Maxime Ripard
>>  wrote:
>> > On Thu, Nov 09, 2017 at 02:48:18PM +0530, Jagan Teki wrote:
>> >> On Wed, Nov 8, 2017 at 5:35 PM, Peter Robinson  
>> >> wrote:
>> >> > On Wed, Nov 8, 2017 at 11:32 AM, Jagan Teki  
>> >> > wrote:
>> >> >> On Tue, Nov 7, 2017 at 5:43 PM, Jagan Teki  
>> >> >> wrote:
>> >> >>> On Sun, Nov 5, 2017 at 7:11 PM, Werner Böllmann
>> >> >>>  wrote:
>> >>  After updating u-boot from v2016.01 to 2017.09 i got a "SATA link 0 
>> >>  timeout." on my Cubietruck board.
>> >>  I tracked this down to this patch.
>> >> 
>> >>  http://git.denx.de/?p=u-boot.git;a=commitdiff_plain;h=9fbb0c3aa49f4604b0342cb527a6bd099f92eaeb.
>> >> >>>
>> >> >>> Look like mdelay missing while moving to board file.
>> >> >>
>> >> >> Can someone test this?
>> >> >
>> >> > I boot my Cubietruck off a SATA drive without issues with any of those
>> >> > intervening releases but it's a SSD so there would be no spin up time
>> >> > compared to spinning rust, I don't have a spare spinning disk to test
>> >> > it with though.
>> >>
>> >> So w/o the mdelay work for you?
>> >
>> > I guess the point of this patch was that you need to have the delay,
>> > but the time between the two function calls might cover it, and
>> > apparently in some case doesn't.
>> >
>> > So whether it works in one particular case is entirely moot.
>>
>> Then, better some more debugging needed in this case.
>
> I'm not sure why that is needed, if we need the delay, we should add
> it explicitly, just like this patch does.

Since it works on particular case, can't we verify non-working area?
adding delay is hard for me but look like this patch needed.

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

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Andre Przywara]

Hi,

On 09/11/17 12:11, Maxime Ripard wrote:
> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
>> Hi,
>>
>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>> able to fit new features like falcon. I knew the limit about 32K but
>> page[1] stating that we can use approximately 192 KiB of contiguous
>> SRAM.
>>
>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>> because I've tried with 64K SPL size with existing SPL code and was
>> able to boot, but with increasing SPL by enabling falcon seems like
>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
> 
> I've been able to use the falcon mode without this change on an A33,
> what's so different about the A64?

That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
exceed 32KB (we are quite close already)

Jagan: you could try this branch of mine [1], this enables a 32-bit SPL,
which is smaller than the AArch64 version.
You might be able to include Falcon there, but I am afraid you have to
work out how to boot a 64-bit kernel from there and how to enable SMP.

Hence my question about the pain you want to endure and if those 500ms
are really worth it.

Cheers,
Andre

[1] https://github.com/apritzel/u-boot/commits/a64-fel32-wip
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Maxime Ripard]

On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
> Hi,
> 
> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
> able to fit new features like falcon. I knew the limit about 32K but
> page[1] stating that we can use approximately 192 KiB of contiguous
> SRAM.
> 
> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
> because I've tried with 64K SPL size with existing SPL code and was
> able to boot, but with increasing SPL by enabling falcon seems like
> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?

I've been able to use the falcon mode without this change on an A33,
what's so different about the A64?

Maxime

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


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

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Maxime Ripard]

On Thu, Nov 09, 2017 at 11:53:48AM +, Andre Przywara wrote:
> >>> because I've tried with 64K SPL size with existing SPL code and was
> >>> able to boot, but with increasing SPL by enabling falcon seems like
> >>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
> >>
> >> So why do you need falcon, desperately? You can put the kernel into the
> >> SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
> >> booti (no further loading). That works from SPI flash, also. If you are
> >> really want to, you can disable USB, Ethernet and the timeout and save
> >> some time here. But those are .config options and shouldn't require code
> >> changes.
> > 
> > Falcon make direct Linux boot, from SPL. we can skip U-Boot, (even
> > ATF). I'm not using USB, ethernet on SPL so current code look fit with
> > what SPL wants.
> 
> I understand that, my question was: What does Falcon give you to justify
> all the hacking and the pain you go through? Why can't you just go the
> normal way and trim U-Boot proper to not waste time?

Even a trimmed U-Boot will take easily around 500ms. If your plan is
to boot in less that one or two seconds, it's already a significant
part of your boot time that you are wasting without any particular
reason.

Maxime

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


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

Re: [U-Boot] sunxi: SATA link timeout fix

[Maxime Ripard]

On Thu, Nov 09, 2017 at 05:12:08PM +0530, Jagan Teki wrote:
> On Thu, Nov 9, 2017 at 3:06 PM, Maxime Ripard
>  wrote:
> > On Thu, Nov 09, 2017 at 02:48:18PM +0530, Jagan Teki wrote:
> >> On Wed, Nov 8, 2017 at 5:35 PM, Peter Robinson  
> >> wrote:
> >> > On Wed, Nov 8, 2017 at 11:32 AM, Jagan Teki  
> >> > wrote:
> >> >> On Tue, Nov 7, 2017 at 5:43 PM, Jagan Teki  
> >> >> wrote:
> >> >>> On Sun, Nov 5, 2017 at 7:11 PM, Werner Böllmann
> >> >>>  wrote:
> >>  After updating u-boot from v2016.01 to 2017.09 i got a "SATA link 0 
> >>  timeout." on my Cubietruck board.
> >>  I tracked this down to this patch.
> >> 
> >>  http://git.denx.de/?p=u-boot.git;a=commitdiff_plain;h=9fbb0c3aa49f4604b0342cb527a6bd099f92eaeb.
> >> >>>
> >> >>> Look like mdelay missing while moving to board file.
> >> >>
> >> >> Can someone test this?
> >> >
> >> > I boot my Cubietruck off a SATA drive without issues with any of those
> >> > intervening releases but it's a SSD so there would be no spin up time
> >> > compared to spinning rust, I don't have a spare spinning disk to test
> >> > it with though.
> >>
> >> So w/o the mdelay work for you?
> >
> > I guess the point of this patch was that you need to have the delay,
> > but the time between the two function calls might cover it, and
> > apparently in some case doesn't.
> >
> > So whether it works in one particular case is entirely moot.
> 
> Then, better some more debugging needed in this case.

I'm not sure why that is needed, if we need the delay, we should add
it explicitly, just like this patch does.

Maxime

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


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

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Jagan Teki]

On Thu, Nov 9, 2017 at 5:23 PM, Andre Przywara  wrote:
> Hi,
>
> On 09/11/17 11:38, Jagan Teki wrote:
>> Hi Andre,
>>
>> On Thu, Nov 9, 2017 at 3:36 AM, André Przywara  
>> wrote:
>>> On 08/11/17 19:59, Jagan Teki wrote:
 Hi,

 I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
 able to fit new features like falcon. I knew the limit about 32K but
 page[1] stating that we can use approximately 192 KiB of contiguous
 SRAM.
>>>
>>> We are not really sure about this. The memory following SRAM A1 is
>>> called SRAM C (not A2, that is secure memory at 0x44000). And this is
>>> actually meant for use by the DisplayEngine, AFAIK. We found it unstable
>>> to use from the ARM cores. With the default config is it not even
>>> covering the whole region as described in the manual.
>>
 eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>>
>>> Well, how? As far as I know the *BROM* does not load more than 32KB, at
>>> least not with the ("un-encrypted") eGON.BT0 format. Or could you
>>> actually load more code?
>>
>> Yes, I've 40K SPL start from sector 16 of SD Since BROM load 32KB to
>> A1 and I had an impression of using SRAM C for > 32KB. So BROM only
>> have an access to A1 (not any other SRAM's like SRAM C) we can't
>> increase the SPL size > 32KB..this is strict. correct?
>
> It's not so much about BROM not having access to SRAM C, it's just not
> doing it. That's a design decision made by Allwinner, and since it's
> ROM, we can't do anything about it.
>
>>>
>>> I *think* we can load more with the "secure" payload, which requires the
>>> "secure boot" fuse to be burned (with no return), which in turn will let
>>> the BROM refuse to load a standard eGON.BT0 Boot0/SPL, but only the
>>> secure packaged version (TOC0): http://linux-sunxi.org/TOC0
>>
>> Did you try this? if yes please point the same.
>
> I tried TOC0 on a Pine64 where I burnt the fuse. But I didn't try to
> load more than 32KB. Anyway I don't believe it's an option for you,
> since it's an revocable change to the SoC (it's a one-time fuse).
> I guess you don't want to force that on your customer's boards.

I've few dev boards, may be I can try > 32KB can you point me the link
or source about this?

 because I've tried with 64K SPL size with existing SPL code and was
 able to boot, but with increasing SPL by enabling falcon seems like
 BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>>
>>> So why do you need falcon, desperately? You can put the kernel into the
>>> SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
>>> booti (no further loading). That works from SPI flash, also. If you are
>>> really want to, you can disable USB, Ethernet and the timeout and save
>>> some time here. But those are .config options and shouldn't require code
>>> changes.
>>
>> Falcon make direct Linux boot, from SPL. we can skip U-Boot, (even
>> ATF). I'm not using USB, ethernet on SPL so current code look fit with
>> what SPL wants.
>
> I understand that, my question was: What does Falcon give you to justify
> all the hacking and the pain you go through? Why can't you just go the
> normal way and trim U-Boot proper to not waste time?

Yes, we can trim the U-Boot proper but my idea is to skip it so-that
we can achieve better boot-time. I've seen better boot-time numbers
with other SOC.

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

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Andre Przywara]

Hi,

On 09/11/17 11:38, Jagan Teki wrote:
> Hi Andre,
> 
> On Thu, Nov 9, 2017 at 3:36 AM, André Przywara  wrote:
>> On 08/11/17 19:59, Jagan Teki wrote:
>>> Hi,
>>>
>>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>>> able to fit new features like falcon. I knew the limit about 32K but
>>> page[1] stating that we can use approximately 192 KiB of contiguous
>>> SRAM.
>>
>> We are not really sure about this. The memory following SRAM A1 is
>> called SRAM C (not A2, that is secure memory at 0x44000). And this is
>> actually meant for use by the DisplayEngine, AFAIK. We found it unstable
>> to use from the ARM cores. With the default config is it not even
>> covering the whole region as described in the manual.
> 
>>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>
>> Well, how? As far as I know the *BROM* does not load more than 32KB, at
>> least not with the ("un-encrypted") eGON.BT0 format. Or could you
>> actually load more code?
> 
> Yes, I've 40K SPL start from sector 16 of SD Since BROM load 32KB to
> A1 and I had an impression of using SRAM C for > 32KB. So BROM only
> have an access to A1 (not any other SRAM's like SRAM C) we can't
> increase the SPL size > 32KB..this is strict. correct?

It's not so much about BROM not having access to SRAM C, it's just not
doing it. That's a design decision made by Allwinner, and since it's
ROM, we can't do anything about it.

>>
>> I *think* we can load more with the "secure" payload, which requires the
>> "secure boot" fuse to be burned (with no return), which in turn will let
>> the BROM refuse to load a standard eGON.BT0 Boot0/SPL, but only the
>> secure packaged version (TOC0): http://linux-sunxi.org/TOC0
> 
> Did you try this? if yes please point the same.

I tried TOC0 on a Pine64 where I burnt the fuse. But I didn't try to
load more than 32KB. Anyway I don't believe it's an option for you,
since it's an revocable change to the SoC (it's a one-time fuse).
I guess you don't want to force that on your customer's boards.

>>> because I've tried with 64K SPL size with existing SPL code and was
>>> able to boot, but with increasing SPL by enabling falcon seems like
>>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>
>> So why do you need falcon, desperately? You can put the kernel into the
>> SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
>> booti (no further loading). That works from SPI flash, also. If you are
>> really want to, you can disable USB, Ethernet and the timeout and save
>> some time here. But those are .config options and shouldn't require code
>> changes.
> 
> Falcon make direct Linux boot, from SPL. we can skip U-Boot, (even
> ATF). I'm not using USB, ethernet on SPL so current code look fit with
> what SPL wants.

I understand that, my question was: What does Falcon give you to justify
all the hacking and the pain you go through? Why can't you just go the
normal way and trim U-Boot proper to not waste time?

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

Re: [U-Boot] [PATCH v5 0/8] Add support for GE PPD

[Martyn Welch]

On Thu, 2017-11-09 at 11:19 +0100, Lukasz Majewski wrote:
> Hi Martyn,
> 
> > *** Resend due to previous use of unsubscribed email address ***
> 
> Just a small remark.
> 
> You may consider using patman to get the list of u-boot community peers
> to be CC'ed for your patch. Or at least look for a custodian (in
> MAINTAINERS) responsible to IMX (NXP) SoC part of u-boot (in this case
> Stefano Babic or Fabio Estevam).
> 

Ah, OK, I ran get_maintainers and CCed anyone specifically flagged as a
maintainer (which is what I understood to be good practice from the
U-Boot wiki).

I'll bear this in mind and CC those that have made significant
contributions next time.

> The problem with sending code only to u-boot ML is that it may be
> overlooked by people, who are the best candidates to review it.
> 
> > 
> > This series adds support for the GE PPD. The initial patches in this
> > series resolve issues found during development and testing, extend
> > existing support and add new support for devices in the PPD. The final
> > patch in the series adds the board support for the PPD.
> > 
> > Ian Ray (2):
> >   ext4: recover from filesystem corruption when reading
> >   bootcount: add support for bootcounter on EXT filesystem
> > 
> > Martyn Welch (3):
> >   pwm: imx: Enable PWM support on i.MX53
> >   arm: mx5: Add more register definitions
> >   board: ge: make VPD code common
> > 
> > Nandor Han (2):
> >   imx: mxc_i2c: tweak the i2c transfer method
> >   rtc: add support for s35392a
> > 
> > Peter Senna Tschudin (1):
> >   mx53: Add Board support for GE PPD
> > 
> >  README   |   7 +
> >  arch/arm/include/asm/arch-mx5/crm_regs.h |   8 +
> >  arch/arm/include/asm/arch-mx5/imx-regs.h |  50 
> >  arch/arm/mach-imx/mx5/Kconfig|   7 +
> >  board/ge/bx50v3/Makefile |   2 +-
> >  board/ge/bx50v3/bx50v3.c |   2 +-
> >  board/ge/bx50v3/vpd_reader.c | 228 ---
> >  board/ge/bx50v3/vpd_reader.h |  25 --
> >  board/ge/common/Makefile |   7 +
> >  board/ge/common/vpd_reader.c | 197 +
> >  board/ge/common/vpd_reader.h |  17 ++
> >  board/ge/mx53ppd/Kconfig |  17 ++
> >  board/ge/mx53ppd/MAINTAINERS |   7 +
> >  board/ge/mx53ppd/Makefile|  12 +
> >  board/ge/mx53ppd/imximage.cfg|  87 ++
> >  board/ge/mx53ppd/mx53ppd.c   | 457
> > +++
> > board/ge/mx53ppd/mx53ppd_video.c | 135 +
> > board/ge/mx53ppd/ppd_gpio.h  |  96 +++
> > configs/mx53ppd_defconfig|  39 +++
> > drivers/Kconfig  |   2 +
> > drivers/bootcount/Kconfig|  58 
> > drivers/bootcount/Makefile   |   1 +
> > drivers/bootcount/bootcount_ext.c|  62 +
> > drivers/i2c/mxc_i2c.c|  25 +-
> > drivers/pwm/pwm-imx-util.c   |   2 +
> > drivers/rtc/Kconfig  |   6 +
> > drivers/rtc/Makefile |   1 +
> > drivers/rtc/s35392a.c| 365
> >  fs/ext4/ext4_common.c|
> > 10 + fs/ext4/ext4fs.c |  10 +-
> > include/configs/mx53ppd.h| 248 +
> > lib/Kconfig  |   3 + 32 files changed,
> > 1927 insertions(+), 266 deletions(-) delete mode 100644
> > board/ge/bx50v3/vpd_reader.c delete mode 100644
> > board/ge/bx50v3/vpd_reader.h create mode 100644
> > board/ge/common/Makefile create mode 100644
> > board/ge/common/vpd_reader.c create mode 100644
> > board/ge/common/vpd_reader.h create mode 100644
> > board/ge/mx53ppd/Kconfig create mode 100644
> > board/ge/mx53ppd/MAINTAINERS create mode 100644
> > board/ge/mx53ppd/Makefile create mode 100644
> > board/ge/mx53ppd/imximage.cfg create mode 100644
> > board/ge/mx53ppd/mx53ppd.c create mode 100644
> > board/ge/mx53ppd/mx53ppd_video.c create mode 100644
> > board/ge/mx53ppd/ppd_gpio.h create mode 100644
> > configs/mx53ppd_defconfig create mode 100644 drivers/bootcount/Kconfig
> >  create mode 100644 drivers/bootcount/bootcount_ext.c
> >  create mode 100644 drivers/rtc/s35392a.c
> >  create mode 100644 include/configs/mx53ppd.h
> > 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


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

[U-Boot] [PATCH] cmd: sf: remove useless pointer assignment

[Baruch Siach]

The 'flash' pointer is assigned unconditionally a few lines below, and is not
used before that.

Signed-off-by: Baruch Siach 
---
 cmd/sf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cmd/sf.c b/cmd/sf.c
index f971eec781cc..9be8a89bc84c 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -126,7 +126,6 @@ static int do_spi_flash_probe(int argc, char * const argv[])
if (!ret) {
device_remove(new, DM_REMOVE_NORMAL);
}
-   flash = NULL;
ret = spi_flash_probe_bus_cs(bus, cs, speed, mode, );
if (ret) {
printf("Failed to initialize SPI flash at %u:%u (error %d)\n",
-- 
2.14.2

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

[U-Boot] booting bare metal application in secure mode on cubieboard2

[cicerog]

Hi everyone,
can someone help me on how to boot a bare metal application in svc secure
mode on the Cubieboard 2?
Thanks a lot in advance



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

Re: [U-Boot] [RFC PATCH 1/2] board: laird: add WB45N CPU module

[Ben Whitten]

On 02 August 2017 15:49, Tom Rini wrote:
> On Wed, Aug 02, 2017 at 11:58:42AM +0200, Stefano Babic wrote:
> > On 07/07/2017 12:40, Ben Whitten wrote:
> > > This board is based on the Atmel 9x5 eval board.
> > > Supporting the following features:
> > >  - Boot from NAND Flash
> > >  - Ethernet
> > >  - FIT
> > >  - SPL
> > >
> >
> > Patch is assigned to me. However, this is Atmel, now orphaned. I
> > haven't work with AT-91 since a very long time, so I cannot say more
> > about patches, but it is a pity if the patches will be lost. Tom,
> > should I merge them even if they are not i.MX related ? Or do you pick
> > them yourself ?
> 
> Ah, sorry, I saw laird, had the WiFi modules they do for i.MX series platforms
> in mind and went "oh, must be an i.MX system".  Please toss them back to
> me, thanks!

Hi Tom,
Any comments on these boards? Whilst I was at ELCE I bumped into Marek and
had a talk about adding new boards, he had mentioned new boards should be
using DM.
As this is the direction things are moving let me know and I can convert them.

Thanks,
Ben
 


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

[U-Boot] Pull request: u-boot-sunxi/master

[Jagan Teki]

Hi Tom,

Few fixes for v2017.11, Please pull the same.

thanks!
Jagan.

The following changes since commit 43ede0bca7fc1590b623832b743213b818257a27:

  Kconfig: Migrate MTDIDS_DEFAULT / MTDPARTS_DEFAULT (2017-11-05 11:21:35 -0500)

are available in the git repository at:

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

for you to fetch changes up to 6270a3f035d0bdb5d2283dff4bb568d36ab4c0e3:

  sunxi: restore PHYLIB for CONFIG_SUN4I_EMAC users (2017-11-09 14:39:30 +0530)


Artturi Alm (2):
  sunxi: fix CONFIG_SUNXI_EMAC references
  sunxi: restore PHYLIB for CONFIG_SUN4I_EMAC users

Icenowy Zheng (1):
  video: sunxi: de2: fix SimpleFB node creation when HDMI not initialized

 drivers/net/Kconfig |  1 +
 drivers/net/Makefile|  2 +-
 drivers/video/sunxi/sunxi_de2.c | 16 +++-
 include/configs/sunxi-common.h  |  2 +-
 4 files changed, 14 insertions(+), 7 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] dm: core: fix member name in ofnode_union documentation

[Baruch Siach]

Fixes: 4984de2baaa ("dm: core: Add ofnode to represent device tree nodes")
Cc: Simon Glass 
Signed-off-by: Baruch Siach 
---
 include/dm/ofnode.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 79374b8f91aa..8b9932a569ce 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -45,7 +45,7 @@ struct resource;
  * the DT.
  *
  * @np: Pointer to device node, used for live tree
- * @flat_ptr: Pointer into flat device tree, used for flat tree. Note that this
+ * @of_offset: Pointer into flat device tree, used for flat tree. Note that 
this
  * is not a really a pointer to a node: it is an offset value. See above.
  */
 typedef union ofnode_union {
-- 
2.14.2

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

[U-Boot] [PATCH] spi: kirkwood: avoid divide by zero crash

[Baruch Siach]

Calling .set_speed with zero speed is definitely a bug. Return an error value
to handle that gracefully instead of crashing.

Signed-off-by: Baruch Siach 
---
 drivers/spi/kirkwood_spi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index 0c6bd295cde9..9a27ac36822e 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -257,6 +257,8 @@ static int mvebu_spi_set_speed(struct udevice *bus, uint hz)
struct kwspi_registers *reg = plat->spireg;
u32 data;
 
+   if (hz == 0)
+   return -EINVAL;
/* calculate spi clock prescaller using max_hz */
data = ((CONFIG_SYS_TCLK / 2) / hz) + 0x10;
data = data < KWSPI_CLKPRESCL_MIN ? KWSPI_CLKPRESCL_MIN : data;
-- 
2.14.2

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

Re: [U-Boot] sunxi: SATA link timeout fix

[Jagan Teki]

On Thu, Nov 9, 2017 at 3:06 PM, Maxime Ripard
 wrote:
> On Thu, Nov 09, 2017 at 02:48:18PM +0530, Jagan Teki wrote:
>> On Wed, Nov 8, 2017 at 5:35 PM, Peter Robinson  wrote:
>> > On Wed, Nov 8, 2017 at 11:32 AM, Jagan Teki  
>> > wrote:
>> >> On Tue, Nov 7, 2017 at 5:43 PM, Jagan Teki  
>> >> wrote:
>> >>> On Sun, Nov 5, 2017 at 7:11 PM, Werner Böllmann
>> >>>  wrote:
>>  After updating u-boot from v2016.01 to 2017.09 i got a "SATA link 0 
>>  timeout." on my Cubietruck board.
>>  I tracked this down to this patch.
>> 
>>  http://git.denx.de/?p=u-boot.git;a=commitdiff_plain;h=9fbb0c3aa49f4604b0342cb527a6bd099f92eaeb.
>> >>>
>> >>> Look like mdelay missing while moving to board file.
>> >>
>> >> Can someone test this?
>> >
>> > I boot my Cubietruck off a SATA drive without issues with any of those
>> > intervening releases but it's a SSD so there would be no spin up time
>> > compared to spinning rust, I don't have a spare spinning disk to test
>> > it with though.
>>
>> So w/o the mdelay work for you?
>
> I guess the point of this patch was that you need to have the delay,
> but the time between the two function calls might cover it, and
> apparently in some case doesn't.
>
> So whether it works in one particular case is entirely moot.

Then, better some more debugging needed in this case.

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

Re: [U-Boot] SUNXI: A64: Increase SPL size

[Jagan Teki]

Hi Andre,

On Thu, Nov 9, 2017 at 3:36 AM, André Przywara  wrote:
> On 08/11/17 19:59, Jagan Teki wrote:
>> Hi,
>>
>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>> able to fit new features like falcon. I knew the limit about 32K but
>> page[1] stating that we can use approximately 192 KiB of contiguous
>> SRAM.
>
> We are not really sure about this. The memory following SRAM A1 is
> called SRAM C (not A2, that is secure memory at 0x44000). And this is
> actually meant for use by the DisplayEngine, AFAIK. We found it unstable
> to use from the ARM cores. With the default config is it not even
> covering the whole region as described in the manual.

>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>
> Well, how? As far as I know the *BROM* does not load more than 32KB, at
> least not with the ("un-encrypted") eGON.BT0 format. Or could you
> actually load more code?

Yes, I've 40K SPL start from sector 16 of SD Since BROM load 32KB to
A1 and I had an impression of using SRAM C for > 32KB. So BROM only
have an access to A1 (not any other SRAM's like SRAM C) we can't
increase the SPL size > 32KB..this is strict. correct?

>
> I *think* we can load more with the "secure" payload, which requires the
> "secure boot" fuse to be burned (with no return), which in turn will let
> the BROM refuse to load a standard eGON.BT0 Boot0/SPL, but only the
> secure packaged version (TOC0): http://linux-sunxi.org/TOC0

Did you try this? if yes please point the same.

>
>> because I've tried with 64K SPL size with existing SPL code and was
>> able to boot, but with increasing SPL by enabling falcon seems like
>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>
> So why do you need falcon, desperately? You can put the kernel into the
> SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
> booti (no further loading). That works from SPI flash, also. If you are
> really want to, you can disable USB, Ethernet and the timeout and save
> some time here. But those are .config options and shouldn't require code
> changes.

Falcon make direct Linux boot, from SPL. we can skip U-Boot, (even
ATF). I'm not using USB, ethernet on SPL so current code look fit with
what SPL wants.

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

[U-Boot] Running out of memory after setting invalid ethaddr

[Thomas Schaefer]

Hi Joe et. al.

After setting MAC address to invalid value 00:00:00:00:00:00 and resetting to a 
valid one, u-boot will run into a recursive endless loop until no memory is 
left to allocate a new MAC address:

=> print eth1addr
eth1addr=00:a0:a5:10:20:31
=> setenv eth1addr 00:00:00:00:00:00
=> setenv eth1addr 00:a0:a5:10:20:31
## Can't malloc 18 bytes
=>

I have tested this with current v2017.11-rc4 on a Freescale T1024RDB eval 
system, but also see this on our custom i.MX7 and T1042 boards which are based 
on v2017.03.

After some investigation, I found that the recursive loop is entered in 
eth_write_hwaddr in net/eth_legacy.c when 'eth_env_set_enetaddr_by_index' is 
called:

~snip
} else if (is_valid_ethaddr(dev->enetaddr)) {
eth_env_set_enetaddr_by_index(base_name, eth_number,
  dev->enetaddr);
~snip

The patch shown below would prevent u-boot from setting ethaddr to an invalid 
value like 00:00:00:00:00:00 and avoids running into a situation as shown above:

diff --git a/net/eth_legacy.c b/net/eth_legacy.c
index be0cf64a3d..8d0a573551 100644
--- a/net/eth_legacy.c
+++ b/net/eth_legacy.c
@@ -104,9 +104,11 @@ static int on_ethaddr(const char *name, const char *value, 
enum env_op op,
 {
int index;
struct eth_device *dev;
+   int ret = 0;
+   unsigned char tmp_enetaddr[ARP_HLEN];

if (!eth_devices)
-   return 0;
+   return ret;

/* look for an index after "eth" */
index = simple_strtoul(name + 3, NULL, 10);
@@ -117,8 +119,17 @@ static int on_ethaddr(const char *name, const char *value, 
enum env_op op,
switch (op) {
case env_op_create:
case env_op_overwrite:
-   eth_parse_enetaddr(value, dev->enetaddr);
-   eth_write_hwaddr(dev, "eth", dev->index);
+   if (is_valid_ethaddr(tmp_enetaddr)) {
+   eth_parse_enetaddr(value,
+  dev->enetaddr);
+   eth_write_hwaddr(dev, "eth",
+dev->index);
+   } else {
+   printf("\nMAC address %pM is not "
+  "valid\n",
+  tmp_enetaddr);
+   ret = 1;
+   }
break;
case env_op_delete:
memset(dev->enetaddr, 0, ARP_HLEN);
@@ -127,7 +138,7 @@ static int on_ethaddr(const char *name, const char *value, 
enum env_op op,
dev = dev->next;
} while (dev != eth_devices);

-   return 0;
+   return ret;
 }
 U_BOOT_ENV_CALLBACK(ethaddr, on_ethaddr);


What do you think?

Best regards,
Thomas


Thomas Schäfer
SW Design Engineer

Kontron - An S Company
Heinrich-Barth-Straße 1-1a | 66115 Saarbrücken | Germany
P: +49 681 95916 203
thomas.schae...@kontron.com

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

[U-Boot] [PATCH] ARM: imx6: Adjust DDR DRAM settings on DHCOM i.MX6 PDK

[Marek Vasut]

The board uses T-topology for the four x16 DRAM chips, so remove
the write-leveling from the SPL as that is only usefly on fly-by
topology and can be harmful on T-topology. Also update the DRAM
timing with values from calibration on multiple boards.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
 board/dhelectronics/dh_imx6/dh_imx6_spl.c | 40 +++
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c 
b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
index e22ff5c8c6..bb98f39f02 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
@@ -140,40 +140,39 @@ static const struct mx6sdl_iomux_grp_regs 
dhcom6sdl_grp_ioregs = {
 };
 
 static const struct mx6_mmdc_calibration dhcom_mmdc_calib = {
-   .p0_mpwldectrl0 = 0x001F001F,
-   .p0_mpwldectrl1 = 0x001F001F,
-   .p1_mpwldectrl0 = 0x00440044,
-   .p1_mpwldectrl1 = 0x00440044,
-   .p0_mpdgctrl0   = 0x434B0350,
-   .p0_mpdgctrl1   = 0x034C0359,
-   .p1_mpdgctrl0   = 0x434B0350,
-   .p1_mpdgctrl1   = 0x03650348,
-   .p0_mprddlctl   = 0x4436383B,
-   .p1_mprddlctl   = 0x39393341,
-   .p0_mpwrdlctl   = 0x35373933,
-   .p1_mpwrdlctl   = 0x48254A36,
+   .p0_mpwldectrl0 = 0x0011000E,
+   .p0_mpwldectrl1 = 0x000E001B,
+   .p1_mpwldectrl0 = 0x00190015,
+   .p1_mpwldectrl1 = 0x00070018,
+   .p0_mpdgctrl0   = 0x42720306,
+   .p0_mpdgctrl1   = 0x026F0266,
+   .p1_mpdgctrl0   = 0x4273030A,
+   .p1_mpdgctrl1   = 0x02740240,
+   .p0_mprddlctl   = 0x45393B3E,
+   .p1_mprddlctl   = 0x403A3747,
+   .p0_mpwrdlctl   = 0x40434541,
+   .p1_mpwrdlctl   = 0x473E4A3B,
 };
 
 static const struct mx6_ddr3_cfg dhcom_mem_ddr = {
.mem_speed  = 1600,
-   .density= 4,
+   .density= 2,
.width  = 64,
.banks  = 8,
.rowaddr= 14,
.coladdr= 10,
.pagesz = 2,
-   .trcd   = 1375,
-   .trcmin = 4875,
-   .trasmin= 3500,
+   .trcd   = 1312,
+   .trcmin = 5863,
+   .trasmin= 3750,
 };
 
 static const struct mx6_ddr_sysinfo dhcom_ddr_info = {
/* width of data bus:0=16,1=32,2=64 */
.dsize  = 2,
-   /* config for full 4GB range so that get_mem_size() works */
-   .cs_density = 32,   /* 32Gb per CS */
+   .cs_density = 16,
.ncs= 1,/* single chip select */
-   .cs1_mirror = 0,
+   .cs1_mirror = 1,
.rtt_wr = 1,/* DDR3_RTT_60_OHM, RTT_Wr = RZQ/4 */
.rtt_nom= 1,/* DDR3_RTT_60_OHM, RTT_Nom = RZQ/4 */
.walat  = 1,/* Write additional latency */
@@ -182,6 +181,8 @@ static const struct mx6_ddr_sysinfo dhcom_ddr_info = {
.bi_on  = 1,/* Bank interleaving enabled */
.sde_to_rst = 0x10, /* 14 cycles, 200us (JEDEC default) */
.rst_to_cke = 0x23, /* 33 cycles, 500us (JEDEC default) */
+   .refsel = 1,/* Refresh cycles at 32KHz */
+   .refr   = 3,/* 4 refresh commands per refresh cycle */
 };
 
 static void ccgr_init(void)
@@ -388,7 +389,6 @@ void board_init_f(ulong dummy)
 
/* Perform DDR DRAM calibration */
udelay(100);
-   mmdc_do_write_level_calibration(_ddr_info);
mmdc_do_dqs_calibration(_ddr_info);
 
/* Clear the BSS. */
-- 
2.11.0

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

Re: [U-Boot] [PATCH 1/2] common: Generic file system firmware loader

[Marek Vasut]

On 11/09/2017 11:00 AM, Lukasz Majewski wrote:
> On Thu, 9 Nov 2017 08:05:18 +0100
> Marek Vasut  wrote:
> 
>> On 11/09/2017 07:04 AM, Chee, Tien Fong wrote:
>>> On Sel, 2017-11-07 at 10:34 +0100, Marek Vasut wrote:  
 On 11/07/2017 10:03 AM, Chee, Tien Fong wrote:  
>
> On Isn, 2017-11-06 at 11:56 +0100, Marek Vasut wrote:  
>>
>> On 11/06/2017 05:15 AM, Chee, Tien Fong wrote:  
>>>
>>>
>>> On Ahd, 2017-11-05 at 17:43 +0100, Marek Vasut wrote:  


 On 11/02/2017 09:20 AM, Chee, Tien Fong wrote:  
>
>
>
> On Rab, 2017-11-01 at 10:26 +0100, Marek Vasut wrote:  
>>
>>
>>
>> On 11/01/2017 10:18 AM, tien.fong.c...@intel.com wrote:  
>>>
>>>
>>>
>>>
>>> From: Tien Fong Chee 
>>>
>>> Generic firmware loader framework contains some common
>>> functionality
>>> which is factored out from splash loader. It is
>>> reusable by
>>> any
>>> specific driver file system firmware loader. Specific
>>> driver
>>> file
>>> system
>>> firmware loader handling can be defined with both weak
>>> function
>>> fsloader_preprocess and fs_loading.
>>>
>>> Signed-off-by: Tien Fong Chee >> ---
>>>  common/Makefile   |   1 +
>>>  common/load_fs.c  | 217
>>> ++
>>>  include/load_fs.h |  38 ++
>>>  3 files changed, 256 insertions(+)
>>>  create mode 100644 common/load_fs.c
>>>  create mode 100644 include/load_fs.h  
>> [...]
>>  
>>>
>>>
>>>
>>>
>>> +int flash_select_fs_dev(struct flash_location
>>> *location)  
>> Why does everything have flash_ prefix ?
>>  
> I can remove the flash_ prefix, this generic FS loader
> should
> support
> for all filesystem instead of flash.
>  
>>
>>
>>
>> I also mentioned the API should copy the linux firmware
>> loader
>> API.
>>  
> If i'm not mistaken, you are referring firmware loader API
> in
> this
> link https://github.com/torvalds/linux/blob/f007cad159e99fa
> 2acd
> 3b2e
> 9364
> fbb32ad28b971/drivers/base/firmware_class.c#L1264.
>  
>>> I would like to confirm with you whether we are talking to the
>>> same
>>> API
>>> above?  
>> https://www.kernel.org/doc/html/v4.13/driver-api/firmware/index.h
>> tml
>>
>> first link on google btw . You might be able to avoid the
>> firmware
>> structure.
>>  
> After assessment, i found that Linux loader is not suitable for
> fpga
> loader as fpga loader need
> 1) Able to program FPGA image in SPL chunk bu chunk with small
> memory
> allocatted.
> 2) Name of FPGA image defined in DTS, and path of FPGA image in
> FAT and
> UBI partition.
>
> Linux loader is strongly designed based on Linux environment,
> always
> assume having RFF, env support(which SPL don't have), sysfs and
> udev
> feature.  
 Sigh, you can just have some additional function call to fetch
 smaller
 chunks from a file, I don't think it's that hard of a problem ...
  
>>> We already have that function to support smaller chunks, and it also
>>> work for single large image when enough memory is available in ver 1
>>> series of fpga loadfs.
>>>
>>> Since the Linux loader API is totally not suitable for fpga loadfs,
>>> and also nothing i can leverage from there for fpga loadfs, could
>>> you please consider to accept implementation for this series
>>> patches or implementation for fpga loadfs series ver1?  
>>
>> You mean going back to completely custom non-generic altera-only
>> ad-hoc interface ? I'd like to hear opinion of the others on CC ...
>>
> 
> I must admit that I don't know the exact Altera API for loading their
> bitstream.

That's irrelevant for a generic loader. The loader should provide a file
or ability to read chunks of file if needed, that's all. The consumer
driver would then use that API to program whatever, ie. the FPGA.

> What I would like to have though is a some kind of generic code, which
> would allow me to reuse it on other ARM + DSP SoCs.

... on other platforms in general.

> If we cannot re-use Linux stuff, then when we add something different
> (more customer/industry aligned), please make it reusable for other
> solutions (Xilinx, ADI, etc) - that would require a good documentation.
And what is the problem with the Linux API ? I am not saying to reuse
the Linux code, but the API is quite well fleshed out.

-- 
Best 

[U-Boot] [PATCH] cmd: mac: Update description of help

[Prabhakar Kushwaha]

mac help does not reflect correct descriptions and parameter.

So update mac help command.

Signed-off-by: Prabhakar Kushwaha 
---
 cmd/mac.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/cmd/mac.c b/cmd/mac.c
index 52d3ba0..4d0dd2b 100644
--- a/cmd/mac.c
+++ b/cmd/mac.c
@@ -13,21 +13,21 @@ extern int do_mac(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[]);
 U_BOOT_CMD(
mac, 3, 1,  do_mac,
"display and program the system ID and MAC addresses in EEPROM",
-   "[read|save|id|num|errata|date|ports|0|1|2|3|4|5|6|7]\n"
+   "[read|save|id|num|errata|date|ports|port_number]\n"
"mac read\n"
-   "- read EEPROM content into memory\n"
+   "- read EEPROM content into memory data structure\n"
"mac save\n"
-   "- save to the EEPROM\n"
+   "- save memory data structure to the EEPROM\n"
"mac id\n"
-   "- program system id\n"
-   "mac num\n"
-   "- program system serial number\n"
-   "mac errata\n"
-   "- program errata data\n"
-   "mac date\n"
-   "- program date\n"
-   "mac ports\n"
-   "- program the number of ports\n"
-   "mac X\n"
-   "- program the MAC address for port X [X=0...7]"
+   "- program system id per hard coded value\n"
+   "mac num string\n"
+   "- program system serial number to value string\n"
+   "mac errata string\n"
+   "- program errata data to value string\n"
+   "mac date YYMMDDhhmmss\n"
+   "- program date to string value YYMMDDhhmmss\n"
+   "mac ports N\n"
+   "- program the number of network ports to integer N\n"
+   "mac X string\n"
+   "- program MAC addr for port X [X=0,1..] to colon separated string"
 );
-- 
2.7.4

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

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

[Stefano Babic]

Hi Tom,

some fixes for 2017.11. Please pull from u-boot-imx, thanks !


The following changes since commit 7a69604bce9a9a9476753af64e5a1870880c1333:

  Prepare v2017.11-rc4 (2017-11-06 18:25:37 -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 9c8979cdb76dd65bb0983eb4cb1a895be0f0b1dc:

  imx7: Add include guards for include/asm/arch-mx7/sys_proto.h file
(2017-11-09 11:32:49 +0100)


Benoît Thébaudeau (1):
  mmc: fsl_esdhc: Fix PIO timeout
Fabio Estevam (3):
  mx25: Move MX25 selection to Kconfig
  mx25: Select the ESDHC_A001 erratum
  mx51: Select the ESDHC_A001 erratum

Jagan Teki (1):
  i.MX6: engicam: Fix MAINTAINERS/README

Lukasz Majewski (6):
  board: imx6: marsboard: Remove doubled #include 
  imx6: iomux: Add generic function to set RGMII IO voltage on IMX6 SoCs
  imx:display5: Add support for LWN's DISPLAY5 board
  imx6: Add include guards for include/asm/arch-mx6/sys_proto.h file
  imx5: Add include guards for include/asm/arch-mx5/sys_proto.h file
  imx7: Add include guards for include/asm/arch-mx7/sys_proto.h file

 arch/arm/Kconfig  |  19 ++--
 arch/arm/dts/imx6q-display5.dts   |  18 
 arch/arm/include/asm/arch-mx5/sys_proto.h |   4 +
 arch/arm/include/asm/arch-mx6/iomux.h |  13 +++
 arch/arm/include/asm/arch-mx6/sys_proto.h |  16 
 arch/arm/include/asm/arch-mx7/sys_proto.h |   4 +
 arch/arm/mach-imx/mx2/Kconfig |  30 ++
 arch/arm/mach-imx/mx5/Kconfig |   2 +-
 arch/arm/mach-imx/mx6/Kconfig |   7 ++
 board/embest/mx6boards/mx6boards.c|   2 +-
 board/engicam/geam6ul/MAINTAINERS |   2 +-
 board/engicam/icorem6/MAINTAINERS |   2 +-
 board/engicam/icorem6/README  |   7 +-
 board/engicam/icorem6_rqs/MAINTAINERS |   2 +-
 board/engicam/icorem6_rqs/README  |   7 +-
 board/engicam/isiotmx6ul/MAINTAINERS  |   2 +-
 board/liebherr/display5/Kconfig   |  18 
 board/liebherr/display5/MAINTAINERS   |   7 ++
 board/liebherr/display5/Makefile  |  11 +++
 board/liebherr/display5/common.c  | 111 ++
 board/liebherr/display5/common.h  |  42 +
 board/liebherr/display5/display5.c| 384

 board/liebherr/display5/spl.c | 247
+
 configs/display5_defconfig|  62 +
 configs/display5_factory_defconfig|  76 +++
 configs/mx25pdk_defconfig |   1 +
 configs/zmx25_defconfig   |   1 +
 drivers/mmc/fsl_esdhc.c   |  26 +++---
 include/configs/display5.h| 408
+
 include/configs/mx25pdk.h |   1 -
 include/configs/zmx25.h   |   1 -
 include/fsl_esdhc.h   |   2 +-
 32 files changed, 1490 insertions(+), 45 deletions(-)
 create mode 100644 arch/arm/dts/imx6q-display5.dts
 create mode 100644 arch/arm/mach-imx/mx2/Kconfig
 create mode 100644 board/liebherr/display5/Kconfig
 create mode 100644 board/liebherr/display5/MAINTAINERS
 create mode 100644 board/liebherr/display5/Makefile
 create mode 100644 board/liebherr/display5/common.c
 create mode 100644 board/liebherr/display5/common.h
 create mode 100644 board/liebherr/display5/display5.c
 create mode 100644 board/liebherr/display5/spl.c
 create mode 100644 configs/display5_defconfig
 create mode 100644 configs/display5_factory_defconfig
 create mode 100644 include/configs/display5.h

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

Re: [U-Boot] [PATCH v5 0/8] Add support for GE PPD

[Lukasz Majewski]

Hi Martyn,

> *** Resend due to previous use of unsubscribed email address ***

Just a small remark.

You may consider using patman to get the list of u-boot community peers
to be CC'ed for your patch. Or at least look for a custodian (in
MAINTAINERS) responsible to IMX (NXP) SoC part of u-boot (in this case
Stefano Babic or Fabio Estevam).

The problem with sending code only to u-boot ML is that it may be
overlooked by people, who are the best candidates to review it.

> 
> This series adds support for the GE PPD. The initial patches in this
> series resolve issues found during development and testing, extend
> existing support and add new support for devices in the PPD. The final
> patch in the series adds the board support for the PPD.
> 
> Ian Ray (2):
>   ext4: recover from filesystem corruption when reading
>   bootcount: add support for bootcounter on EXT filesystem
> 
> Martyn Welch (3):
>   pwm: imx: Enable PWM support on i.MX53
>   arm: mx5: Add more register definitions
>   board: ge: make VPD code common
> 
> Nandor Han (2):
>   imx: mxc_i2c: tweak the i2c transfer method
>   rtc: add support for s35392a
> 
> Peter Senna Tschudin (1):
>   mx53: Add Board support for GE PPD
> 
>  README   |   7 +
>  arch/arm/include/asm/arch-mx5/crm_regs.h |   8 +
>  arch/arm/include/asm/arch-mx5/imx-regs.h |  50 
>  arch/arm/mach-imx/mx5/Kconfig|   7 +
>  board/ge/bx50v3/Makefile |   2 +-
>  board/ge/bx50v3/bx50v3.c |   2 +-
>  board/ge/bx50v3/vpd_reader.c | 228 ---
>  board/ge/bx50v3/vpd_reader.h |  25 --
>  board/ge/common/Makefile |   7 +
>  board/ge/common/vpd_reader.c | 197 +
>  board/ge/common/vpd_reader.h |  17 ++
>  board/ge/mx53ppd/Kconfig |  17 ++
>  board/ge/mx53ppd/MAINTAINERS |   7 +
>  board/ge/mx53ppd/Makefile|  12 +
>  board/ge/mx53ppd/imximage.cfg|  87 ++
>  board/ge/mx53ppd/mx53ppd.c   | 457
> +++
> board/ge/mx53ppd/mx53ppd_video.c | 135 +
> board/ge/mx53ppd/ppd_gpio.h  |  96 +++
> configs/mx53ppd_defconfig|  39 +++
> drivers/Kconfig  |   2 +
> drivers/bootcount/Kconfig|  58 
> drivers/bootcount/Makefile   |   1 +
> drivers/bootcount/bootcount_ext.c|  62 +
> drivers/i2c/mxc_i2c.c|  25 +-
> drivers/pwm/pwm-imx-util.c   |   2 +
> drivers/rtc/Kconfig  |   6 +
> drivers/rtc/Makefile |   1 +
> drivers/rtc/s35392a.c| 365
>  fs/ext4/ext4_common.c|
> 10 + fs/ext4/ext4fs.c |  10 +-
> include/configs/mx53ppd.h| 248 +
> lib/Kconfig  |   3 + 32 files changed,
> 1927 insertions(+), 266 deletions(-) delete mode 100644
> board/ge/bx50v3/vpd_reader.c delete mode 100644
> board/ge/bx50v3/vpd_reader.h create mode 100644
> board/ge/common/Makefile create mode 100644
> board/ge/common/vpd_reader.c create mode 100644
> board/ge/common/vpd_reader.h create mode 100644
> board/ge/mx53ppd/Kconfig create mode 100644
> board/ge/mx53ppd/MAINTAINERS create mode 100644
> board/ge/mx53ppd/Makefile create mode 100644
> board/ge/mx53ppd/imximage.cfg create mode 100644
> board/ge/mx53ppd/mx53ppd.c create mode 100644
> board/ge/mx53ppd/mx53ppd_video.c create mode 100644
> board/ge/mx53ppd/ppd_gpio.h create mode 100644
> configs/mx53ppd_defconfig create mode 100644 drivers/bootcount/Kconfig
>  create mode 100644 drivers/bootcount/bootcount_ext.c
>  create mode 100644 drivers/rtc/s35392a.c
>  create mode 100644 include/configs/mx53ppd.h
> 



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


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

[U-Boot] [PATCH 4/4] ls2080ardb: Add sd_bootcmd for distro fallback in case of sdboot

[Shengzhou Liu]

Signed-off-by: Shengzhou Liu 
---
 include/configs/ls2080ardb.h | 39 ---
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index 48c3a5397f..650db2f594 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -349,6 +349,17 @@ unsigned long get_board_sys_clk(void);
"esbc_validate 0x2070 && "  \
"esbc_validate 0x2074;" \
"fsl_mc start mc 0x20a0 0x20e0 \0"
+#elif defined(CONFIG_SD_BOOT)
+#define MC_INIT_CMD \
+   "mcinitcmd=mmcinfo;mmc read 0x8000 0x5000 0x800;" \
+   "mmc read 0x8010 0x7000 0x800;" \
+   "env exists secureboot && " \
+   "mmc read 0x8070 0x3800 0x10 && "   \
+   "mmc read 0x8074 0x3A00 0x10 && "   \
+   "esbc_validate 0x8070 && "  \
+   "esbc_validate 0x8074 ;"\
+   "fsl_mc start mc 0x8000 0x8010\0" \
+   "mcmemsize=0x7000\0"
 #else
 #define MC_INIT_CMD\
"mcinitcmd=env exists secureboot && "   \
@@ -379,8 +390,14 @@ unsigned long get_board_sys_clk(void);
"fdt_addr_r=0x9000\0"   \
"load_addr=0xa000\0"\
"kernel_size=0x280\0"   \
+   "kernel_addr_sd=0x8000\0"   \
+   "kernel_size_sd=0x14000\0"  \
"console=ttyAMA0,38400n8\0" \
"mcmemsize=0x7000\0"\
+   "sd_bootcmd=echo Trying load from SD ..;" \
+   "mmcinfo; mmc read $load_addr " \
+   "$kernel_addr_sd $kernel_size_sd && "   \
+   "bootm $load_addr#$board\0" \
MC_INIT_CMD \
BOOTENV \
"boot_scripts=ls2088ardb_boot.scr\0"\
@@ -409,9 +426,6 @@ unsigned long get_board_sys_clk(void);
"${scripthdraddr} ${prefix}${boot_script_hdr} " \
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0"\
-   "installer=load mmc 0:2 $load_addr "\
-   "/flex_installer_arm64.itb; "   \
-   "bootm $load_addr#ls2088ardb\0" \
"qspi_bootcmd=echo Trying load from qspi..;"\
"sf probe && sf read $load_addr "   \
"$kernel_start $kernel_size ; env exists secureboot &&" \
@@ -433,16 +447,27 @@ unsigned long get_board_sys_clk(void);
"&& esbc_validate 0x2078; " \
"env exists mcinitcmd && "  \
"fsl_mc lazyapply dpl 0x20d0; " \
-   "run distro_bootcmd;run qspi_bootcmd; " \
-   "env exists secureboot && esbc_halt; "
+   "run distro_bootcmd;env exists secureboot " \
+   " && esbc_halt;run qspi_bootcmd; "
+#elif defined(CONFIG_SD_BOOT)
+/* Try to boot an on-SD kernel first, then do normal distro boot */
+#define CONFIG_BOOTCOMMAND \
+   "env exists mcinitcmd && env exists secureboot "\
+   "&& mmcinfo && mmc read $load_addr 0x3c00 0x800 " \
+   "&& esbc_validate $load_addr; " \
+   "env exists mcinitcmd && run mcinitcmd "\
+   "&& mmc read 0x8800 0x6800 0x800 "  \
+   "&& fsl_mc lazyapply dpl 0x8800; "  \
+   "run distro_bootcmd;env exists secureboot " \
+   "&& esbc_halt;run sd_bootcmd;"
 #else
 /* Try to boot an on-NOR kernel first, then do normal distro boot */
 #define CONFIG_BOOTCOMMAND \
"env exists mcinitcmd && env exists secureboot "\
"&& esbc_validate 0x58078; env exists mcinitcmd "\
"&& fsl_mc lazyapply dpl 0x580d0;"  \
-   "run distro_bootcmd;run nor_bootcmd; "  \
-   "env exists secureboot && esbc_halt; "
+   "run distro_bootcmd; env exists secureboot "\
+   "&& esbc_halt; run nor_bootcmd;"
 #endif
 
 /* MAC/PHY configuration */
-- 
2.14.1

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

[U-Boot] [PATCH 1/4] ls1043ardb: Add sd_bootcmd for distro fallback in case of sdboot

[Shengzhou Liu]

Signed-off-by: Shengzhou Liu 
---
 include/configs/ls1043a_common.h | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index a24d0062d2..140ea23902 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -278,6 +278,8 @@
"fdt_addr_r=0x9000\0"   \
"load_addr=0xa000\0"\
"kernel_size=0x280\0"   \
+   "kernel_addr_sd=0x8000\0"   \
+   "kernel_size_sd=0x14000\0"  \
"console=ttyS0,115200\0"\
"boot_os=y\0"   \
"mtdparts=" MTDPARTS_DEFAULT "\0"   \
@@ -308,20 +310,25 @@
"${scripthdraddr} ${prefix}${boot_script_hdr} " \
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0"\
-   "installer=load mmc 0:2 $load_addr "\
-   "/flex_installer_arm64.itb; "   \
-   "bootm $load_addr#ls1043ardb\0" \
"qspi_bootcmd=echo Trying load from qspi..;"\
"sf probe && sf read $load_addr "   \
"$kernel_addr $kernel_size && bootm $load_addr#$board\0" \
"nor_bootcmd=echo Trying load from nor..;"  \
"cp.b $kernel_addr $load_addr " \
-   "$kernel_size && bootm $load_addr#$board\0"
+   "$kernel_size && bootm $load_addr#$board\0" \
+   "sd_bootcmd=echo Trying load from SD ..;"   \
+   "mmcinfo; mmc read $load_addr " \
+   "$kernel_addr_sd $kernel_size_sd && " \
+   "bootm $load_addr#$board\0"
+
 
 #undef CONFIG_BOOTCOMMAND
 #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
 #define CONFIG_BOOTCOMMAND "run distro_bootcmd; env exists secureboot" \
   "&& esbc_halt; run qspi_bootcmd;"
+#elif defined(CONFIG_SD_BOOT)
+#define CONFIG_BOOTCOMMAND "run distro_bootcmd; env exists secureboot"  \
+  "&& esbc_halt; run sd_bootcmd;"
 #else
 #define CONFIG_BOOTCOMMAND "run distro_bootcmd; env exists secureboot" \
   "&& esbc_halt; run nor_bootcmd;"
-- 
2.14.1

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

[U-Boot] [PATCH 2/4] arm64: ls1046ardb: Add sd_bootcmd for distro fallback in case of sdboot

[Shengzhou Liu]

Signed-off-by: Shengzhou Liu 
---
 include/configs/ls1046a_common.h | 11 +++
 include/configs/ls1046ardb.h |  6 ++
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h
index 6d501b9c54..e7b1425c15 100644
--- a/include/configs/ls1046a_common.h
+++ b/include/configs/ls1046a_common.h
@@ -227,6 +227,8 @@
"kernel_start=0x100\0"  \
"kernel_load=0xa000\0"  \
"kernel_size=0x280\0"   \
+   "kernel_addr_sd=0x8000\0"   \
+   "kernel_size_sd=0x14000\0"  \
"console=ttyS0,115200\0"\
MTDPARTS_DEFAULT "\0"   \
BOOTENV \
@@ -257,12 +259,13 @@
"${scripthdraddr} ${prefix}${boot_script_hdr} " \
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0"  \
-   "installer=load mmc 0:2 $load_addr "  \
-   "/flex_installer_arm64.itb; "  \
-   "bootm $load_addr#ls1046ardb\0"  \
"qspi_bootcmd=echo Trying load from qspi..;"  \
"sf probe && sf read $load_addr " \
-   "$kernel_start $kernel_size && bootm $load_addr#$board\0"
+   "$kernel_start $kernel_size && bootm $load_addr#$board\0" \
+   "sd_bootcmd=echo Trying load from SD ..;"   \
+   "mmcinfo; mmc read $load_addr " \
+   "$kernel_addr_sd $kernel_size_sd && "   \
+   "bootm $load_addr#$board\0"
 
 #endif
 
diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h
index bb27dd058a..d28af34d19 100644
--- a/include/configs/ls1046ardb.h
+++ b/include/configs/ls1046ardb.h
@@ -225,8 +225,14 @@
 
 #ifndef SPL_NO_MISC
 #undef CONFIG_BOOTCOMMAND
+#if defined(CONFIG_QSPI_BOOT)
 #define CONFIG_BOOTCOMMAND "run distro_bootcmd; env exists secureboot" \
   "&& esbc_halt; run qspi_bootcmd;"
+#elif defined(CONFIG_SD_BOOT)
+#define CONFIG_BOOTCOMMAND "run distro_bootcmd; env exists secureboot"  \
+  "&& esbc_halt; run sd_bootcmd;"
+#endif
+
 #define MTDPARTS_DEFAULT "mtdparts=155.quadspi:1m(rcw)," \
"15m(u-boot),48m(kernel.itb);" \
"7e80.flash:16m(nand_uboot)," \
-- 
2.14.1

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

Re: [U-Boot] ethernet: ROM MAC address vs env variable MAC address

[Lukasz Majewski]

Hi Prabhakar,

> Hi All, 
> 
> I am seeing following type of code for MAC address write for a
> network device.
> 
> net/eth-uclass.c  eth_post_probe()   or net/eth_legacy.c
> eth_write_hwaddr()
> 
>   eth_env_get_enetaddr_by_index("eth", dev->seq, env_enetaddr);
>   if (!is_zero_ethaddr(env_enetaddr)) {
>   if (!is_zero_ethaddr(pdata->enetaddr) &&
>   memcmp(pdata->enetaddr, env_enetaddr, ARP_HLEN)) {
>   printf("\nWarning: %s MAC addresses don't
> match:\n", dev->name);
>   printf("Address in ROM is  %pM\n",
>  pdata->enetaddr);
>   printf("Address in environment is  %pM\n",
>  env_enetaddr);
>   }
> 
>   /* Override the ROM MAC address */
>   memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
> 
> Why ROM MAC address getting overwritten by environment env MAC
> address. MAC address is something unique and assigned to a particular
> device. So one should never change its MAC address.
> 

It may happen that company which uses NXP processor wants to use their
own set of MAC addresses.

> Please suggest. 
> 
> Regards,
> Prabhakar
> 
> ___
> 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


pgpYDzGVQ3mvH.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] board: imx6: marsboard: Remove doubled #include

[Stefano Babic]

On 09/11/2017 10:49, Lukasz Majewski wrote:
> Hi Stefano,
> 
>> Hi Lukasz,
>>
>> On 07/11/2017 11:10, Lukasz Majewski wrote:
>>> The sys_proto.h file has been included earlier in this file.
>>>
>>> Signed-off-by: Lukasz Majewski 
>>>
>>> ---
>>>
>>>  board/embest/mx6boards/mx6boards.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/board/embest/mx6boards/mx6boards.c
>>> b/board/embest/mx6boards/mx6boards.c index ae04f68445..965e4f1ec8
>>> 100644 --- a/board/embest/mx6boards/mx6boards.c
>>> +++ b/board/embest/mx6boards/mx6boards.c
>>> @@ -36,7 +36,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> -#include 
>>> +
>>>  DECLARE_GLOBAL_DATA_PTR;
>>>  
>>>  #define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP
>>> |   \ 
>>
>> Thanks for fix - applied to u-boot-imx, -master !
> 
> You are welcome :-)
> 
> I've also sent a commit, which adds #ifdef guards to sys_proto.h.
> 

They are applied, too

Regards,
Stefano

>>
>> I have reapplied support for display5, and I am testing the build
>> again. If it is ok, I'll send as my last PR to Tom for 2017.11.
> 
> Great, thanks :)
> 
>>
>> Best regards,
>> Stefano
>>
> 
> 
> 
> 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
> 


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

Re: [U-Boot] [PATCH] Kconfig: Introduce USE_BOOTCOMMAND and migrate BOOTCOMMAND

[Lukasz Majewski]

On Mon,  6 Nov 2017 18:15:11 -0500
Tom Rini  wrote:

> We first introduce CONFIG_USE_BOOTCOMMAND, similar to
> CONFIG_USE_BOOTARGS.  We then migrate CONFIG_BOOTCOMMAND for most
> CONFIG_DISTRO_DEFAULT users.  In some cases platforms have a complex
> scheme around this usage, and these have been defered for the moment
> so that platform maintainers can work on a migration plan.
> 
> Signed-off-by: Tom Rini 
> ---
>  Kconfig   |  1 +
>  common/Kconfig| 17 +
>  configs/am335x_evm_defconfig  |  1 +
>  configs/am335x_evm_nor_defconfig  |  1 +
>  configs/am335x_evm_norboot_defconfig  |  1 +
>  configs/am335x_evm_spiboot_defconfig  |  1 +
>  configs/am335x_evm_usbspl_defconfig   |  1 +
>  configs/apalis-tk1_defconfig  |  1 +
>  configs/duovero_defconfig |  1 +
>  configs/evb-rv1108_defconfig  |  1 +
>  configs/igep0032_defconfig|  1 +
>  configs/igep00x0_defconfig|  1 +
>  configs/ls2080a_emu_defconfig |  1 +
>  configs/ls2080a_simu_defconfig|  1 +
>  configs/ls2080aqds_SECURE_BOOT_defconfig  |  1 +
>  configs/ls2080aqds_defconfig  |  1 +
>  configs/ls2080aqds_nand_defconfig |  1 +
>  configs/ls2080aqds_qspi_defconfig |  1 +
>  configs/ls2080aqds_sdcard_defconfig   |  1 +
>  configs/ls2080ardb_SECURE_BOOT_defconfig  |  1 +
>  configs/ls2080ardb_defconfig  |  1 +
>  configs/ls2080ardb_nand_defconfig |  1 +
>  configs/ls2081ardb_defconfig  |  1 +
>  configs/ls2088ardb_qspi_SECURE_BOOT_defconfig |  1 +
>  configs/ls2088ardb_qspi_defconfig |  1 +
>  configs/lsxhl_defconfig   |  1 +
>  configs/marsboard_defconfig   |  1 +
>  configs/mx6cuboxi_defconfig   |  1 +
>  configs/novena_defconfig  |  1 +
>  configs/omap3_beagle_defconfig|  1 +
>  configs/omap3_evm_defconfig   |  1 +
>  configs/omap3_pandora_defconfig   |  1 +
>  configs/omap4_panda_defconfig |  1 +
>  configs/omap4_sdp4430_defconfig   |  1 +
>  configs/riotboard_defconfig   |  1 +
>  configs/ti816x_evm_defconfig  |  1 +
>  configs/udoo_neo_defconfig|  1 +
>  configs/usbarmory_defconfig   |  1 +
>  configs/vexpress_aemv8a_dram_defconfig|  1 +
>  configs/vexpress_aemv8a_juno_defconfig|  1 +
>  configs/vexpress_aemv8a_semi_defconfig|  1 +
>  configs/vexpress_ca15_tc2_defconfig   |  1 +
>  configs/vexpress_ca5x2_defconfig  |  1 +
>  configs/vexpress_ca9x4_defconfig  |  1 +
>  configs/wandboard_defconfig   |  1 +
>  configs/zc5202_defconfig  |  1 +
>  configs/zc5601_defconfig  |  1 +
>  include/configs/am335x_evm.h  |  9 -
>  include/configs/apalis-tk1.h  |  4 
>  include/configs/el6x_common.h |  4 
>  include/configs/embestmx6boards.h |  4 
>  include/configs/lsxl.h|  1 -
>  include/configs/mx6cuboxi.h   |  5 -
>  include/configs/novena.h  |  1 -
>  include/configs/omap3_igep00x0.h  |  4 
>  include/configs/sandbox.h |  2 --
>  include/configs/ti_omap4_common.h |  8 
>  include/configs/udoo_neo.h|  4 
>  include/configs/vexpress_common.h |  4 
>  include/configs/wandboard.h   |  5 -
>  60 files changed, 63 insertions(+), 55 deletions(-)
> 
> diff --git a/Kconfig b/Kconfig
> index e57fad45922b..9b8a8077993a 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -66,6 +66,7 @@ config DISTRO_DEFAULTS
>   default y if ARCH_MESON
>   default y if ARCH_ROCKCHIP
>   default n
> + imply USE_BOOTCOMMAND
>   select CMD_BOOTZ if ARM && !ARM64
>   select CMD_BOOTI if ARM64
>   select CMD_DHCP
> diff --git a/common/Kconfig b/common/Kconfig
> index f96a25f582ba..c50d6ebb2adf 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -200,6 +200,23 @@ config BOOTARGS
> CONFIG_BOOTARGS goes into the environment value
> "bootargs". Note that this value will also override the "chosen" node
> in FDT blob. 
> +config USE_BOOTCOMMAND
> + bool "Enable a default value for bootcmd"
> + help
> +   Provide a default value for the bootcmd entry in the
> environment.  If
> +   autoboot is enabled this is what will be run
> automatically.  Enable
> +   this option to be able to specify CONFIG_BOOTCOMMAND as a
> string.  If
> +   this option is disabled, 

Re: [U-Boot] [PATCH 1/2] common: Generic file system firmware loader

[Lukasz Majewski]

On Thu, 9 Nov 2017 08:05:18 +0100
Marek Vasut  wrote:

> On 11/09/2017 07:04 AM, Chee, Tien Fong wrote:
> > On Sel, 2017-11-07 at 10:34 +0100, Marek Vasut wrote:  
> >> On 11/07/2017 10:03 AM, Chee, Tien Fong wrote:  
> >>>
> >>> On Isn, 2017-11-06 at 11:56 +0100, Marek Vasut wrote:  
> 
>  On 11/06/2017 05:15 AM, Chee, Tien Fong wrote:  
> >
> >
> > On Ahd, 2017-11-05 at 17:43 +0100, Marek Vasut wrote:  
> >>
> >>
> >> On 11/02/2017 09:20 AM, Chee, Tien Fong wrote:  
> >>>
> >>>
> >>>
> >>> On Rab, 2017-11-01 at 10:26 +0100, Marek Vasut wrote:  
> 
> 
> 
>  On 11/01/2017 10:18 AM, tien.fong.c...@intel.com wrote:  
> >
> >
> >
> >
> > From: Tien Fong Chee 
> >
> > Generic firmware loader framework contains some common
> > functionality
> > which is factored out from splash loader. It is
> > reusable by
> > any
> > specific driver file system firmware loader. Specific
> > driver
> > file
> > system
> > firmware loader handling can be defined with both weak
> > function
> > fsloader_preprocess and fs_loading.
> >
> > Signed-off-by: Tien Fong Chee  >>  
> > ---
> >  common/Makefile   |   1 +
> >  common/load_fs.c  | 217
> > ++
> >  include/load_fs.h |  38 ++
> >  3 files changed, 256 insertions(+)
> >  create mode 100644 common/load_fs.c
> >  create mode 100644 include/load_fs.h  
>  [...]
>   
> >
> >
> >
> >
> > +int flash_select_fs_dev(struct flash_location
> > *location)  
>  Why does everything have flash_ prefix ?
>   
> >>> I can remove the flash_ prefix, this generic FS loader
> >>> should
> >>> support
> >>> for all filesystem instead of flash.
> >>>  
> 
> 
> 
>  I also mentioned the API should copy the linux firmware
>  loader
>  API.
>   
> >>> If i'm not mistaken, you are referring firmware loader API
> >>> in
> >>> this
> >>> link https://github.com/torvalds/linux/blob/f007cad159e99fa
> >>> 2acd
> >>> 3b2e
> >>> 9364
> >>> fbb32ad28b971/drivers/base/firmware_class.c#L1264.
> >>>  
> > I would like to confirm with you whether we are talking to the
> > same
> > API
> > above?  
>  https://www.kernel.org/doc/html/v4.13/driver-api/firmware/index.h
>  tml
> 
>  first link on google btw . You might be able to avoid the
>  firmware
>  structure.
>   
> >>> After assessment, i found that Linux loader is not suitable for
> >>> fpga
> >>> loader as fpga loader need
> >>> 1) Able to program FPGA image in SPL chunk bu chunk with small
> >>> memory
> >>> allocatted.
> >>> 2) Name of FPGA image defined in DTS, and path of FPGA image in
> >>> FAT and
> >>> UBI partition.
> >>>
> >>> Linux loader is strongly designed based on Linux environment,
> >>> always
> >>> assume having RFF, env support(which SPL don't have), sysfs and
> >>> udev
> >>> feature.  
> >> Sigh, you can just have some additional function call to fetch
> >> smaller
> >> chunks from a file, I don't think it's that hard of a problem ...
> >>  
> > We already have that function to support smaller chunks, and it also
> > work for single large image when enough memory is available in ver 1
> > series of fpga loadfs.
> > 
> > Since the Linux loader API is totally not suitable for fpga loadfs,
> > and also nothing i can leverage from there for fpga loadfs, could
> > you please consider to accept implementation for this series
> > patches or implementation for fpga loadfs series ver1?  
> 
> You mean going back to completely custom non-generic altera-only
> ad-hoc interface ? I'd like to hear opinion of the others on CC ...
> 

I must admit that I don't know the exact Altera API for loading their
bitstream.

What I would like to have though is a some kind of generic code, which
would allow me to reuse it on other ARM + DSP SoCs.

If we cannot re-use Linux stuff, then when we add something different
(more customer/industry aligned), please make it reusable for other
solutions (Xilinx, ADI, etc) - that would require a good documentation.

Those are my 2 cents.

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


pgpd0XD3M1Blk.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH] board: imx6: marsboard: Remove doubled #include

[Lukasz Majewski]

Hi Stefano,

> Hi Lukasz,
> 
> On 07/11/2017 11:10, Lukasz Majewski wrote:
> > The sys_proto.h file has been included earlier in this file.
> > 
> > Signed-off-by: Lukasz Majewski 
> > 
> > ---
> > 
> >  board/embest/mx6boards/mx6boards.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/board/embest/mx6boards/mx6boards.c
> > b/board/embest/mx6boards/mx6boards.c index ae04f68445..965e4f1ec8
> > 100644 --- a/board/embest/mx6boards/mx6boards.c
> > +++ b/board/embest/mx6boards/mx6boards.c
> > @@ -36,7 +36,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +
> >  DECLARE_GLOBAL_DATA_PTR;
> >  
> >  #define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP
> > |   \ 
> 
> Thanks for fix - applied to u-boot-imx, -master !

You are welcome :-)

I've also sent a commit, which adds #ifdef guards to sys_proto.h.

> 
> I have reapplied support for display5, and I am testing the build
> again. If it is ok, I'll send as my last PR to Tom for 2017.11.

Great, thanks :)

> 
> Best regards,
> Stefano
> 



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


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

[U-Boot] Universal Flash Storage - controllers

[Jorge Ramirez]

Hi all,

Is there any work in progress - maybe a topic branch?  to bring in 
Universal Flash Storage support into u-boot?


thanks
Jorge

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

Re: [U-Boot] sunxi: SATA link timeout fix

[Maxime Ripard]

On Thu, Nov 09, 2017 at 02:48:18PM +0530, Jagan Teki wrote:
> On Wed, Nov 8, 2017 at 5:35 PM, Peter Robinson  wrote:
> > On Wed, Nov 8, 2017 at 11:32 AM, Jagan Teki  
> > wrote:
> >> On Tue, Nov 7, 2017 at 5:43 PM, Jagan Teki  
> >> wrote:
> >>> On Sun, Nov 5, 2017 at 7:11 PM, Werner Böllmann
> >>>  wrote:
>  After updating u-boot from v2016.01 to 2017.09 i got a "SATA link 0 
>  timeout." on my Cubietruck board.
>  I tracked this down to this patch.
> 
>  http://git.denx.de/?p=u-boot.git;a=commitdiff_plain;h=9fbb0c3aa49f4604b0342cb527a6bd099f92eaeb.
> >>>
> >>> Look like mdelay missing while moving to board file.
> >>
> >> Can someone test this?
> >
> > I boot my Cubietruck off a SATA drive without issues with any of those
> > intervening releases but it's a SSD so there would be no spin up time
> > compared to spinning rust, I don't have a spare spinning disk to test
> > it with though.
> 
> So w/o the mdelay work for you?

I guess the point of this patch was that you need to have the delay,
but the time between the two function calls might cover it, and
apparently in some case doesn't.

So whether it works in one particular case is entirely moot.

Maxime

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


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 v5 8/8] mx53: Add Board support for GE PPD

[Stefano Babic]

On 06/11/2017 20:14, Martyn Welch wrote:
> From: Peter Senna Tschudin 
> 
> Create board support for GE PPD, based on mx53loco.
> 
> Use mx53ppd_defconfig make target to configure for this board.
> 
> Signed-off-by: Peter Senna Tschudin 
> Signed-off-by: Ian Ray 
> Signed-off-by: Nandor Han 
> Signed-off-by: Martyn Welch 
> Cc: Stefano Babic 
> ---
> Changes in v4:
>- Remove mach-type.h entry.
>- Move to ge board directory (to be able to use ge common code).
>- Remove now common VPD code.
>- Move do_lcd_enable() to mx53ppd_video.c.
> 
> Changes in v5:
>- Reduced checkpatch warnings.
>- Simplified get_board_rev().
>- Propagated errors from clock_1GHz().
>- Simplified process_vpd().
>- Made check_time() and lcd_enable() static.
> 
>  arch/arm/mach-imx/mx5/Kconfig|   7 +
>  board/ge/mx53ppd/Kconfig |  17 ++
>  board/ge/mx53ppd/MAINTAINERS |   7 +
>  board/ge/mx53ppd/Makefile|  12 +
>  board/ge/mx53ppd/imximage.cfg|  87 
>  board/ge/mx53ppd/mx53ppd.c   | 457 
> +++
>  board/ge/mx53ppd/mx53ppd_video.c | 135 
>  board/ge/mx53ppd/ppd_gpio.h  |  96 
>  configs/mx53ppd_defconfig|  39 
>  include/configs/mx53ppd.h| 248 +
>  10 files changed, 1105 insertions(+)
>  create mode 100644 board/ge/mx53ppd/Kconfig
>  create mode 100644 board/ge/mx53ppd/MAINTAINERS
>  create mode 100644 board/ge/mx53ppd/Makefile
>  create mode 100644 board/ge/mx53ppd/imximage.cfg
>  create mode 100644 board/ge/mx53ppd/mx53ppd.c
>  create mode 100644 board/ge/mx53ppd/mx53ppd_video.c
>  create mode 100644 board/ge/mx53ppd/ppd_gpio.h
>  create mode 100644 configs/mx53ppd_defconfig
>  create mode 100644 include/configs/mx53ppd.h
> 
> diff --git a/arch/arm/mach-imx/mx5/Kconfig b/arch/arm/mach-imx/mx5/Kconfig
> index ef37c35..02adace 100644
> --- a/arch/arm/mach-imx/mx5/Kconfig
> +++ b/arch/arm/mach-imx/mx5/Kconfig
> @@ -45,6 +45,12 @@ config TARGET_MX53LOCO
>   select BOARD_LATE_INIT
>   select MX53
>  
> +config TARGET_MX53PPD
> + bool "Support mx53ppd"
> + select MX53
> + help
> +   Enable support for the GE Healthcare PPD.
> +
>  config TARGET_MX53SMD
>   bool "Support mx53smd"
>   select MX53
> @@ -70,6 +76,7 @@ source "board/freescale/mx53ard/Kconfig"
>  source "board/freescale/mx53evk/Kconfig"
>  source "board/freescale/mx53loco/Kconfig"
>  source "board/freescale/mx53smd/Kconfig"
> +source "board/ge/mx53ppd/Kconfig"
>  source "board/inversepath/usbarmory/Kconfig"
>  source "board/technologic/ts4800/Kconfig"
>  
> diff --git a/board/ge/mx53ppd/Kconfig b/board/ge/mx53ppd/Kconfig
> new file mode 100644
> index 000..781c1cf
> --- /dev/null
> +++ b/board/ge/mx53ppd/Kconfig
> @@ -0,0 +1,17 @@
> +# SPDX-License-Identifier:   GPL-2.0+
> +
> +if TARGET_MX53PPD
> +
> +config SYS_BOARD
> + default "mx53ppd"
> +
> +config SYS_VENDOR
> + default "ge"
> +
> +config SYS_SOC
> + default "mx5"
> +
> +config SYS_CONFIG_NAME
> + default "mx53ppd"
> +
> +endif
> diff --git a/board/ge/mx53ppd/MAINTAINERS b/board/ge/mx53ppd/MAINTAINERS
> new file mode 100644
> index 000..9b64b5d
> --- /dev/null
> +++ b/board/ge/mx53ppd/MAINTAINERS
> @@ -0,0 +1,7 @@
> +MX53PPD BOARD
> +M:   Antti Mäentausta 
> +M:   Martyn Welch 
> +S:   Maintained
> +F:   board/freescale/mx53ppd/
> +F:   include/configs/mx53ppd.h
> +F:   configs/mx53ppd_defconfig
> diff --git a/board/ge/mx53ppd/Makefile b/board/ge/mx53ppd/Makefile
> new file mode 100644
> index 000..928edfb
> --- /dev/null
> +++ b/board/ge/mx53ppd/Makefile
> @@ -0,0 +1,12 @@
> +# Copyright 2017 General Electric Company
> +#
> +# Based on board/freescale/mx53loco/Makefile:
> +#
> +# (C) Copyright 2011 Freescale Semiconductor, Inc.
> +# Jason Liu 
> +#
> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +obj-y+= mx53ppd.o
> +obj-$(CONFIG_VIDEO)  += mx53ppd_video.o
> diff --git a/board/ge/mx53ppd/imximage.cfg b/board/ge/mx53ppd/imximage.cfg
> new file mode 100644
> index 000..83ff4b8
> --- /dev/null
> +++ b/board/ge/mx53ppd/imximage.cfg
> @@ -0,0 +1,87 @@
> +/*
> + * Copyright 2017 General Electric Company
> + *
> + * Based on board/freescale/mx53loco/imximage.cfg:
> + *
> + * Copyright (C) 2011 Freescale Semiconductor, Inc.
> + * Jason Liu 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + *
> + * Refer doc/README.imximage for more details about how-to configure
> + * and create imximage boot image
> + *
> + * The syntax is taken as close as possible with the kwbimage
> + */
> +
> +/* image version */
> +IMAGE_VERSION 2
> +
> +/*
> + * Boot Device : one of
> + * spi, sd (the board has no nand neither onenand)
> + */
> +BOOT_FROMsd
> +

Re: [U-Boot] [PATCH v5 4/8] arm: mx5: Add more register definitions

[Stefano Babic]

On 08/11/2017 16:35, Martyn Welch wrote:
> Add register definitions require for video configuration.
> 
> Signed-off-by: Nandor Han 
> Signed-off-by: Martyn Welch 
> Reviewed-by: Stefano Babic 
> Cc: Stefano Babic 
> ---
> Changes in v5:
>   - Reduced checkpatch warnings.
> 
>  arch/arm/include/asm/arch-mx5/crm_regs.h |  8 
>  arch/arm/include/asm/arch-mx5/imx-regs.h | 33 
> 
>  2 files changed, 41 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-mx5/crm_regs.h 
> b/arch/arm/include/asm/arch-mx5/crm_regs.h
> index b61c7b9..7fea569 100644
> --- a/arch/arm/include/asm/arch-mx5/crm_regs.h
> +++ b/arch/arm/include/asm/arch-mx5/crm_regs.h
> @@ -210,6 +210,14 @@ struct mxc_ccm_reg {
>  #define MXC_CCM_CSCMR1_SSI_EXT2_COM_CLK_SEL  (0x1 << 1)
>  #define MXC_CCM_CSCMR1_SSI_EXT1_COM_CLK_SEL  0x1
>  
> +/* Define the bits in register CSCMR2 */
> +#define MXC_CCM_CSCMR2_DI0_CLK_SEL_OFFSET26
> +#define MXC_CCM_CSCMR2_DI0_CLK_SEL_MASK  (0x7 << 26)
> +#define MXC_CCM_CSCMR2_DI0_CLK_SEL(v)(((v) & 0x7) << 26)
> +#define MXC_CCM_CSCMR2_DI0_CLK_SEL_RD(r) (((r) >> 26) & 0x7)
> +
> +#define MXC_CCM_CSCMR2_DI0_CLK_SEL_LDB_DI0_CLK 5
> +
>  /* Define the bits in register CSCDR2 */
>  #define MXC_CCM_CSCDR2_CSPI_CLK_PRED_OFFSET  25
>  #define MXC_CCM_CSCDR2_CSPI_CLK_PRED_MASK(0x7 << 25)
> diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h 
> b/arch/arm/include/asm/arch-mx5/imx-regs.h
> index 2b0dc1e..61c8d44 100644
> --- a/arch/arm/include/asm/arch-mx5/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
> @@ -416,6 +416,39 @@ struct iomuxc {
>  };
>  #endif
>  
> +#define IOMUXC_GPR2_BITMAP_SPWG  0
> +#define IOMUXC_GPR2_BITMAP_JEIDA 1
> +
> +#define IOMUXC_GPR2_BIT_MAPPING_CH0_OFFSET   6
> +#define IOMUXC_GPR2_BIT_MAPPING_CH0_MASK (1 << 
> IOMUXC_GPR2_BIT_MAPPING_CH0_OFFSET)
> +#define IOMUXC_GPR2_BIT_MAPPING_CH0_JEIDA(IOMUXC_GPR2_BITMAP_JEIDA << \
> +  
> IOMUXC_GPR2_BIT_MAPPING_CH0_OFFSET)
> +#define IOMUXC_GPR2_BIT_MAPPING_CH0_SPWG (IOMUXC_GPR2_BITMAP_SPWG << \
> +  
> IOMUXC_GPR2_BIT_MAPPING_CH0_OFFSET)
> +
> +#define IOMUXC_GPR2_DATA_WIDTH_180
> +#define IOMUXC_GPR2_DATA_WIDTH_241
> +
> +#define IOMUXC_GPR2_DATA_WIDTH_CH0_OFFSET5
> +#define IOMUXC_GPR2_DATA_WIDTH_CH0_MASK  (1 << 
> IOMUXC_GPR2_DATA_WIDTH_CH0_OFFSET)
> +#define IOMUXC_GPR2_DATA_WIDTH_CH0_18BIT (IOMUXC_GPR2_DATA_WIDTH_18 << \
> +  
> IOMUXC_GPR2_DATA_WIDTH_CH0_OFFSET)
> +#define IOMUXC_GPR2_DATA_WIDTH_CH0_24BIT (IOMUXC_GPR2_DATA_WIDTH_24 << \
> +  
> IOMUXC_GPR2_DATA_WIDTH_CH0_OFFSET)
> +
> +#define IOMUXC_GPR2_MODE_DISABLED0
> +#define IOMUXC_GPR2_MODE_ENABLED_DI0 1
> +#define IOMUXC_GPR2_MODE_ENABLED_DI1 3
> +
> +#define IOMUXC_GPR2_LVDS_CH0_MODE_OFFSET 0
> +#define IOMUXC_GPR2_LVDS_CH0_MODE_MASK   (3 << 
> IOMUXC_GPR2_LVDS_CH0_MODE_OFFSET)
> +#define IOMUXC_GPR2_LVDS_CH0_MODE_DISABLED   (IOMUXC_GPR2_MODE_DISABLED << \
> +  
> IOMUXC_GPR2_LVDS_CH0_MODE_OFFSET)
> +#define IOMUXC_GPR2_LVDS_CH0_MODE_ENABLED_DI0
> (IOMUXC_GPR2_MODE_ENABLED_DI0 << \
> +  
> IOMUXC_GPR2_LVDS_CH0_MODE_OFFSET)
> +#define IOMUXC_GPR2_LVDS_CH0_MODE_ENABLED_DI1
> (IOMUXC_GPR2_MODE_ENABLED_DI1 << \
> +  
> IOMUXC_GPR2_LVDS_CH0_MODE_OFFSET)
> +
>  /* System Reset Controller (SRC) */
>  struct src {
>   u32 scr;
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

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

[U-Boot] [PATCH v2 16/18] clk: rockchip: Add rk322x gamc clock support

[David Wu]

Assuming mac_clk is fed by an external clock, set clk_rmii_src
clock select control register from IO for rgmii interface.

Signed-off-by: David Wu 
---

Changes in v2:
- New patch

 drivers/clk/rockchip/clk_rk322x.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk322x.c 
b/drivers/clk/rockchip/clk_rk322x.c
index e87267d..5fd27cd 100644
--- a/drivers/clk/rockchip/clk_rk322x.c
+++ b/drivers/clk/rockchip/clk_rk322x.c
@@ -239,6 +239,16 @@ static ulong rockchip_mmc_get_clk(struct rk322x_cru *cru, 
uint clk_general_rate,
return DIV_TO_RATE(src_rate, div) / 2;
 }
 
+static int rk322x_mac_set_clk(struct rk322x_cru *cru,
+ int periph, uint freq)
+{
+   /* Assuming mac_clk is fed by an external clock */
+   rk_clrsetreg(>cru_clksel_con[5], BIT(5),
+BIT(5));
+
+   return 0;
+}
+
 static ulong rockchip_mmc_set_clk(struct rk322x_cru *cru, uint 
clk_general_rate,
  int periph, uint freq)
 {
@@ -352,6 +362,9 @@ static ulong rk322x_clk_set_rate(struct clk *clk, ulong 
rate)
case CLK_DDR:
new_rate = rk322x_ddr_set_clk(priv->cru, rate);
break;
+   case SCLK_MAC:
+   new_rate = rk322x_mac_set_clk(priv->cru, clk->id, rate);
+   break;
default:
return -ENOENT;
}
-- 
2.7.4


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

Re: [U-Boot] [PATCH v5 3/8] pwm: imx: Enable PWM support on i.MX53

[Stefano Babic]

On 08/11/2017 16:35, Martyn Welch wrote:
> Add missing parts for i.MX53 PWM support
> 
> Acked-by: Nandor Han 
> Signed-off-by: Martyn Welch 
> Cc: Stefano Babic 
> ---
> Changes for v4:
>- Removed ifdef.
> 
>  arch/arm/include/asm/arch-mx5/imx-regs.h | 17 +
>  drivers/pwm/pwm-imx-util.c   |  2 ++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h 
> b/arch/arm/include/asm/arch-mx5/imx-regs.h
> index 3e79fa3..2b0dc1e 100644
> --- a/arch/arm/include/asm/arch-mx5/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
> @@ -508,6 +508,23 @@ struct fuse_bank4_regs {
>  };
>  #endif
>  
> +#define PWMCR_PRESCALER(x)   (((x - 1) & 0xFFF) << 4)
> +#define PWMCR_DOZEEN (1 << 24)
> +#define PWMCR_WAITEN (1 << 23)
> +#define PWMCR_DBGEN  (1 << 22)
> +#define PWMCR_CLKSRC_IPG_HIGH(2 << 16)
> +#define PWMCR_CLKSRC_IPG (1 << 16)
> +#define PWMCR_EN (1 << 0)
> +
> +struct pwm_regs {
> + u32 cr;
> + u32 sr;
> + u32 ir;
> + u32 sar;
> + u32 pr;
> + u32 cnr;
> +};
> +
>  #endif /* __ASSEMBLER__*/
>  
>  #endif   /* __ASM_ARCH_MX5_IMX_REGS_H__ */
> diff --git a/drivers/pwm/pwm-imx-util.c b/drivers/pwm/pwm-imx-util.c
> index 534dd8e..97ac0c8 100644
> --- a/drivers/pwm/pwm-imx-util.c
> +++ b/drivers/pwm/pwm-imx-util.c
> @@ -23,10 +23,12 @@ struct pwm_regs *pwm_id_to_reg(int pwm_id)
>   return (struct pwm_regs *)PWM1_BASE_ADDR;
>   case 1:
>   return (struct pwm_regs *)PWM2_BASE_ADDR;
> +#ifdef CONFIG_MX6
>   case 2:
>   return (struct pwm_regs *)PWM3_BASE_ADDR;
>   case 3:
>   return (struct pwm_regs *)PWM4_BASE_ADDR;
> +#endif
>  #ifdef CONFIG_MX6SX
>   case 4:
>   return (struct pwm_regs *)PWM5_BASE_ADDR;
> 

Acked-by: Stefano Babic 

Best regards,
Stefano

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

Re: [U-Boot] [PATCH v5 7/8] board: ge: make VPD code common

[Stefano Babic]

On 08/11/2017 16:35, Martyn Welch wrote:
> The VPD data is used on a number of GE products. Move the parsing code to
> a common location so that we can share this code.
> 
> Signed-off-by: Martyn Welch 
> ---
> Changes in v4:
>- New patch.
> 
> Changes in v5:
>- Fixed checkpatch issues.
> 
> board/ge/bx50v3/Makefile |   2 +-
>  board/ge/bx50v3/bx50v3.c |   2 +-
>  board/ge/bx50v3/vpd_reader.c | 228 
> ---
>  board/ge/bx50v3/vpd_reader.h |  25 -
>  board/ge/common/Makefile |   7 ++
>  board/ge/common/vpd_reader.c | 197 +
>  board/ge/common/vpd_reader.h |  17 
>  7 files changed, 223 insertions(+), 255 deletions(-)
>  delete mode 100644 board/ge/bx50v3/vpd_reader.c
>  delete mode 100644 board/ge/bx50v3/vpd_reader.h
>  create mode 100644 board/ge/common/Makefile
>  create mode 100644 board/ge/common/vpd_reader.c
>  create mode 100644 board/ge/common/vpd_reader.h
> 
> diff --git a/board/ge/bx50v3/Makefile b/board/ge/bx50v3/Makefile
> index 2fff27b..bcd149f 100644
> --- a/board/ge/bx50v3/Makefile
> +++ b/board/ge/bx50v3/Makefile
> @@ -5,4 +5,4 @@
>  # SPDX-License-Identifier:   GPL-2.0+
>  #
>  
> -obj-y  := bx50v3.o vpd_reader.o
> +obj-y  := bx50v3.o
> diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
> index 2e8f394..37de990 100644
> --- a/board/ge/bx50v3/bx50v3.c
> +++ b/board/ge/bx50v3/bx50v3.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include "vpd_reader.h"
> +#include "../common/vpd_reader.h"
>  DECLARE_GLOBAL_DATA_PTR;
>  
>  #ifndef CONFIG_SYS_I2C_EEPROM_ADDR
> diff --git a/board/ge/bx50v3/vpd_reader.c b/board/ge/bx50v3/vpd_reader.c
> deleted file mode 100644
> index 98da893..000
> --- a/board/ge/bx50v3/vpd_reader.c
> +++ /dev/null
> @@ -1,228 +0,0 @@
> -/*
> - * Copyright 2016 General Electric Company
> - *
> - * SPDX-License-Identifier:  GPL-2.0+
> - */
> -
> -#include "vpd_reader.h"
> -
> -#include 
> -#include 
> -
> -
> -/* BCH configuration */
> -
> -const struct {
> - int header_ecc_capability_bits;
> - int data_ecc_capability_bits;
> - unsigned int prim_poly;
> - struct {
> - int min;
> - int max;
> - } galois_field_order;
> -} bch_configuration = {
> - .header_ecc_capability_bits = 4,
> - .data_ecc_capability_bits = 16,
> - .prim_poly = 0,
> - .galois_field_order = {
> - .min = 5,
> - .max = 15,
> - },
> -};
> -
> -static int calculate_galois_field_order(size_t source_length)
> -{
> - int gfo = bch_configuration.galois_field_order.min;
> -
> - for (; gfo < bch_configuration.galois_field_order.max &&
> -  1 << gfo) - 1) - ((int)source_length * 8)) < 0);
> -  gfo++) {
> - }
> -
> - if (gfo == bch_configuration.galois_field_order.max) {
> - return -1;
> - }
> -
> - return gfo + 1;
> -}
> -
> -static int verify_bch(int ecc_bits, unsigned int prim_poly,
> - uint8_t * data, size_t data_length,
> - const uint8_t * ecc, size_t ecc_length)
> -{
> - int gfo = calculate_galois_field_order(data_length);
> - if (gfo < 0) {
> - return -1;
> - }
> -
> - struct bch_control * bch = init_bch(gfo, ecc_bits, prim_poly);
> - if (!bch) {
> - return -1;
> - }
> -
> - if (bch->ecc_bytes != ecc_length) {
> - free_bch(bch);
> - return -1;
> - }
> -
> - unsigned * errloc = (unsigned *)calloc(data_length, sizeof(unsigned));
> - int errors = decode_bch(
> - bch, data, data_length, ecc, NULL, NULL, errloc);
> - free_bch(bch);
> - if (errors < 0) {
> - free(errloc);
> - return -1;
> - }
> -
> - if (errors > 0) {
> - for (int n = 0; n < errors; n++) {
> - if (errloc[n] >= 8 * data_length) {
> - /* n-th error located in ecc (no need for data 
> correction) */
> - } else {
> - /* n-th error located in data */
> - data[errloc[n] / 8] ^= 1 << (errloc[n] % 8);
> - }
> - }
> - }
> -
> - free(errloc);
> - return 0;
> -}
> -
> -
> -static const int ID = 0;
> -static const int LEN = 1;
> -static const int VER = 2;
> -static const int TYP = 3;
> -static const int BLOCK_SIZE = 4;
> -
> -static const uint8_t HEADER_BLOCK_ID = 0x00;
> -static const uint8_t HEADER_BLOCK_LEN = 18;
> -static const uint32_t HEADER_BLOCK_MAGIC = 0xca53ca53;
> -static const size_t HEADER_BLOCK_VERIFY_LEN = 14;
> -static const size_t HEADER_BLOCK_ECC_OFF = 14;
> -static const size_t HEADER_BLOCK_ECC_LEN = 4;
> -
> -static const uint8_t ECC_BLOCK_ID = 0xFF;
> -
> -int vpd_reader(
> - size_t size,
> - uint8_t * data,
> - void * userdata,
> - int (*fn)(
> - void * userdata,
> - uint8_t id,
> 

[U-Boot] [PATCH v2 15/18] rockchip: pinctrl: Add rk322x gmac pinctrl support

[David Wu]

Set gmac pins iomux and rgmii tx pins to 12ma drive-strength,
clean others to 2ma.

Signed-off-by: David Wu 
---

Changes in v2:
- New patch

 drivers/pinctrl/rockchip/pinctrl_rk322x.c | 138 ++
 1 file changed, 138 insertions(+)

diff --git a/drivers/pinctrl/rockchip/pinctrl_rk322x.c 
b/drivers/pinctrl/rockchip/pinctrl_rk322x.c
index 28d9996..956e02f 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk322x.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk322x.c
@@ -470,6 +470,48 @@ enum {
CON_IOMUX_PWM0SEL_MASK  = 1 << CON_IOMUX_PWM0SEL_SHIFT,
 };
 
+/* GRF_GPIO2B_E */
+enum {
+   GRF_GPIO2B0_E_SHIFT = 0,
+   GRF_GPIO2B0_E_MASK = GENMASK(1, 0),
+   GRF_GPIO2B1_E_SHIFT = 2,
+   GRF_GPIO2B1_E_MASK = GENMASK(3, 2),
+   GRF_GPIO2B3_E_SHIFT = 6,
+   GRF_GPIO2B3_E_MASK = GENMASK(7, 6),
+   GRF_GPIO2B4_E_SHIFT = 8,
+   GRF_GPIO2B4_E_MASK = GENMASK(9, 8),
+   GRF_GPIO2B5_E_SHIFT = 10,
+   GRF_GPIO2B5_E_MASK = GENMASK(11, 10),
+   GRF_GPIO2B6_E_SHIFT = 12,
+   GRF_GPIO2B6_E_MASK = GENMASK(13, 12),
+};
+
+/* GRF_GPIO2C_E */
+enum {
+   GRF_GPIO2C0_E_SHIFT = 0,
+   GRF_GPIO2C0_E_MASK = GENMASK(1, 0),
+   GRF_GPIO2C1_E_SHIFT = 2,
+   GRF_GPIO2C1_E_MASK = GENMASK(3, 2),
+   GRF_GPIO2C2_E_SHIFT = 4,
+   GRF_GPIO2C2_E_MASK = GENMASK(5, 4),
+   GRF_GPIO2C3_E_SHIFT = 6,
+   GRF_GPIO2C3_E_MASK = GENMASK(7, 6),
+   GRF_GPIO2C4_E_SHIFT = 8,
+   GRF_GPIO2C4_E_MASK = GENMASK(9, 8),
+   GRF_GPIO2C5_E_SHIFT = 10,
+   GRF_GPIO2C5_E_MASK = GENMASK(11, 10),
+   GRF_GPIO2C6_E_SHIFT = 12,
+   GRF_GPIO2C6_E_MASK = GENMASK(13, 12),
+   GRF_GPIO2C7_E_SHIFT = 14,
+   GRF_GPIO2C7_E_MASK = GENMASK(15, 14),
+};
+
+/* GRF_GPIO2D_E */
+enum {
+   GRF_GPIO2D1_E_SHIFT = 2,
+   GRF_GPIO2D1_E_MASK = GENMASK(3, 2),
+};
+
 struct rk322x_pinctrl_priv {
struct rk322x_grf *grf;
 };
@@ -633,6 +675,95 @@ static void pinctrl_rk322x_sdmmc_config(struct rk322x_grf 
*grf, int mmc_id)
}
 }
 
+#if CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
+static void pinctrl_rk322x_gmac_config(struct rk322x_grf *grf, int gmac_id)
+{
+   switch (gmac_id) {
+   case PERIPH_ID_GMAC:
+   /* set rgmii pins mux */
+   rk_clrsetreg(>gpio2b_iomux,
+GPIO2B0_MASK |
+GPIO2B1_MASK |
+GPIO2B3_MASK |
+GPIO2B4_MASK |
+GPIO2B5_MASK |
+GPIO2B6_MASK,
+GPIO2B0_GMAC_RXDV << GPIO2B0_SHIFT |
+GPIO2B1_GMAC_TXCLK << GPIO2B1_SHIFT |
+GPIO2B3_GMAC_RXCLK << GPIO2B3_SHIFT |
+GPIO2B4_GMAC_MDIO << GPIO2B4_SHIFT |
+GPIO2B5_GMAC_TXEN << GPIO2B5_SHIFT |
+GPIO2B6_GMAC_CLK << GPIO2B6_SHIFT);
+
+   rk_clrsetreg(>gpio2c_iomux,
+GPIO2C0_MASK |
+GPIO2C1_MASK |
+GPIO2C2_MASK |
+GPIO2C3_MASK |
+GPIO2C4_MASK |
+GPIO2C5_MASK |
+GPIO2C6_MASK |
+GPIO2C7_MASK,
+GPIO2C0_GMAC_RXD1 << GPIO2C0_SHIFT |
+GPIO2C1_GMAC_RXD0 << GPIO2C1_SHIFT |
+GPIO2C2_GMAC_TXD1 << GPIO2C2_SHIFT |
+GPIO2C3_GMAC_TXD0 << GPIO2C3_SHIFT |
+GPIO2C4_GMAC_RXD3 << GPIO2C4_SHIFT |
+GPIO2C5_GMAC_RXD2 << GPIO2C5_SHIFT |
+GPIO2C6_GMAC_TXD2 << GPIO2C6_SHIFT |
+GPIO2C7_GMAC_TXD3 << GPIO2C7_SHIFT);
+
+   rk_clrsetreg(>gpio2d_iomux,
+GPIO2D1_MASK,
+GPIO2D1_GMAC_MDC << GPIO2D1_SHIFT);
+
+   /*
+* set rgmii tx pins to 12ma drive-strength,
+* clean others with 2ma.
+*/
+   rk_clrsetreg(>gpio2_e[1],
+GRF_GPIO2B0_E_MASK |
+GRF_GPIO2B1_E_MASK |
+GRF_GPIO2B3_E_MASK |
+GRF_GPIO2B4_E_MASK |
+GRF_GPIO2B5_E_MASK |
+GRF_GPIO2B6_E_MASK,
+0x0 << GRF_GPIO2B0_E_SHIFT |
+0x3 << GRF_GPIO2B1_E_SHIFT |
+0x0 << GRF_GPIO2B3_E_SHIFT |
+0x0 << GRF_GPIO2B4_E_SHIFT |
+0x3 << GRF_GPIO2B5_E_SHIFT |
+0x0 << GRF_GPIO2B6_E_SHIFT);
+
+   rk_clrsetreg(>gpio2_e[2],
+GRF_GPIO2C0_E_MASK |
+   

[U-Boot] [PATCH] driver: net: fsl-mc: Use base 16 in simple_strtoul

[Prabhakar Kushwaha]

Value provided in MC_MEM_SIZE_ENV_VAR is in hex.

So provide 16 as base in simple_strtoul.

Signed-off-by: Prabhakar Kushwaha 
---
 arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3 | 2 +-
 drivers/net/fsl-mc/mc.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3 
b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
index 7867c37..c5e3acf 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
@@ -118,7 +118,7 @@ Environment Variables
 mcboottimeout: MC boot timeout in milliseconds. If this variable is not defined
the value CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS will be assumed.
 
-mcmemsize: MC DRAM block size. If this variable is not defined, the value
+mcmemsize: MC DRAM block size in hex. If this variable is not defined, the 
value
CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE will be assumed.
 
 mcinitcmd: This environment variable is defined to initiate MC and DPL 
deployment
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index be2b611..c76f582 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -826,7 +826,7 @@ unsigned long mc_get_dram_block_size(void)
 
if (dram_block_size_env_var) {
dram_block_size = simple_strtoul(dram_block_size_env_var, NULL,
-10);
+16);
 
if (dram_block_size < CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE) {
printf("fsl-mc: WARNING: Invalid value for \'"
-- 
2.7.4

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

[U-Boot] [PATCH v2 14/18] rockchip: pinctrl: rk322x: Move the iomux definitions into pinctrl-driver

[David Wu]

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Clean the iomux definitions at grf_rk322x.h, and move them
   into pinctrl-driver for resolving the compiling error of redefinition. After
   that, define the uart2 iomux at rk322x-board file. Signed-off-by: David Wu
    --- [...] 

Content analysis details:   (6.5 points, 5.0 required)

 pts rule name  description
 -- --
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 2.7 RCVD_IN_PSBL   RBL: Received via a relay in PSBL
[211.157.147.133 listed in psbl.surriel.com]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.133 listed in bl.mailspike.net]
 0.8 UPPERCASE_50_75message body is 50-75% uppercase
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---
Clean the iomux definitions at grf_rk322x.h, and move them into
pinctrl-driver for resolving the compiling error of redefinition.
After that, define the uart2 iomux at rk322x-board file.

Signed-off-by: David Wu 
---

Changes in v2:
- New patch

 arch/arm/include/asm/arch-rockchip/grf_rk322x.h | 455 
 arch/arm/mach-rockchip/rk322x-board-spl.c   |  20 +-
 arch/arm/mach-rockchip/rk322x-board.c   |  16 +
 drivers/pinctrl/rockchip/pinctrl_rk322x.c   | 453 +++
 4 files changed, 488 insertions(+), 456 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk322x.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk322x.h
index c0c0d84..52e5a0a 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk322x.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk322x.h
@@ -88,461 +88,6 @@ struct rk322x_sgrf {
unsigned int busdmac_con[4];
 };
 
-/* GRF_GPIO0A_IOMUX */
-enum {
-   GPIO0A7_SHIFT   = 14,
-   GPIO0A7_MASK= 3 << GPIO0A7_SHIFT,
-   GPIO0A7_GPIO= 0,
-   GPIO0A7_I2C3_SDA,
-   GPIO0A7_HDMI_DDCSDA,
-
-   GPIO0A6_SHIFT   = 12,
-   GPIO0A6_MASK= 3 << GPIO0A6_SHIFT,
-   GPIO0A6_GPIO= 0,
-   GPIO0A6_I2C3_SCL,
-   GPIO0A6_HDMI_DDCSCL,
-
-   GPIO0A3_SHIFT   = 6,
-   GPIO0A3_MASK= 3 << GPIO0A3_SHIFT,
-   GPIO0A3_GPIO= 0,
-   GPIO0A3_I2C1_SDA,
-   GPIO0A3_SDIO_CMD,
-
-   GPIO0A2_SHIFT   = 4,
-   GPIO0A2_MASK= 3 << GPIO0A2_SHIFT,
-   GPIO0A2_GPIO= 0,
-   GPIO0A2_I2C1_SCL,
-
-   GPIO0A1_SHIFT   = 2,
-   GPIO0A1_MASK= 3 << GPIO0A1_SHIFT,
-   GPIO0A1_GPIO= 0,
-   GPIO0A1_I2C0_SDA,
-
-   GPIO0A0_SHIFT   = 0,
-   GPIO0A0_MASK= 3 << GPIO0A0_SHIFT,
-   GPIO0A0_GPIO= 0,
-   GPIO0A0_I2C0_SCL,
-};
-
-/* GRF_GPIO0B_IOMUX */
-enum {
-   GPIO0B7_SHIFT   = 14,
-   GPIO0B7_MASK= 3 << GPIO0B7_SHIFT,
-   GPIO0B7_GPIO= 0,
-   GPIO0B7_HDMI_HDP,
-
-   GPIO0B6_SHIFT   = 12,
-   GPIO0B6_MASK= 3 << GPIO0B6_SHIFT,
-   GPIO0B6_GPIO= 0,
-   GPIO0B6_I2S_SDI,
-   GPIO0B6_SPI_CSN0,
-
-   GPIO0B5_SHIFT   = 10,
-   GPIO0B5_MASK= 3 << GPIO0B5_SHIFT,
-   GPIO0B5_GPIO= 0,
-   GPIO0B5_I2S_SDO,
-   GPIO0B5_SPI_RXD,
-
-   GPIO0B3_SHIFT   = 6,
-   GPIO0B3_MASK= 3 << GPIO0B3_SHIFT,
-   GPIO0B3_GPIO= 0,
-   GPIO0B3_I2S1_LRCKRX,
-   GPIO0B3_SPI_TXD,
-
-   GPIO0B1_SHIFT   = 2,
-   GPIO0B1_MASK= 3 << GPIO0B1_SHIFT,
-   GPIO0B1_GPIO= 0,
-   GPIO0B1_I2S_SCLK,
-   GPIO0B1_SPI_CLK,
-
-   GPIO0B0_SHIFT   = 0,
-   GPIO0B0_MASK= 3,
-   GPIO0B0_GPIO= 0,
-   GPIO0B0_I2S_MCLK,
-};
-
-/* GRF_GPIO0C_IOMUX */
-enum {
-   GPIO0C4_SHIFT   = 8,
-   GPIO0C4_MASK= 3 << GPIO0C4_SHIFT,
-   GPIO0C4_GPIO= 0,
-   GPIO0C4_HDMI_CECSDA,
-
-   GPIO0C1_SHIFT   = 2,
-   GPIO0C1_MASK= 3 << GPIO0C1_SHIFT,
-   GPIO0C1_GPIO= 0,
-   GPIO0C1_UART0_RSTN,
-   GPIO0C1_CLK_OUT1,
-};
-
-/* GRF_GPIO0D_IOMUX */
-enum {
-   GPIO0D6_SHIFT   = 12,
-   GPIO0D6_MASK= 3 << GPIO0D6_SHIFT,
-   GPIO0D6_GPIO= 0,
-   GPIO0D6_SDIO_PWREN,
-   GPIO0D6_PWM11,
-
-
-   GPIO0D4_SHIFT   = 8,
-   GPIO0D4_MASK= 3 << 

Re: [U-Boot] [PATCH v5 2/8] ext4: recover from filesystem corruption when reading

[Stefano Babic]

On 08/11/2017 16:35, Martyn Welch wrote:
> From: Ian Ray 
> 
> Some fixes when reading EXT files and directory entries were identified
> after using e2fuzz to corrupt an EXT3 filesystem:
> 
>  - Stop reading directory entries if the offset becomes badly aligned.
> 
>  - Avoid overwriting memory by clamping the length used to zero the buffer
>in ext4fs_read_file.  Also sanity check blocksize.
> 
> Signed-off-by: Ian Ray 
> Signed-off-by: Martyn Welch 
> ---
>  fs/ext4/ext4_common.c | 10 ++
>  fs/ext4/ext4fs.c  | 10 +-
>  2 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
> index 31952f4..dac9545 100644
> --- a/fs/ext4/ext4_common.c
> +++ b/fs/ext4/ext4_common.c
> @@ -660,6 +660,11 @@ static int search_dir(struct ext2_inode *parent_inode, 
> char *dirname)
>  
>   offset = 0;
>   do {
> + if (offset & 3) {
> + printf("Badly aligned ext2_dirent\n");
> + break;
> + }
> +
>   dir = (struct ext2_dirent *)(block_buffer + offset);
>   direntname = (char*)(dir) + sizeof(struct ext2_dirent);
>  
> @@ -880,6 +885,11 @@ static int unlink_filename(char *filename, unsigned int 
> blknr)
>  
>   offset = 0;
>   do {
> + if (offset & 3) {
> + printf("Badly aligned ext2_dirent\n");
> + break;
> + }
> +
>   previous_dir = dir;
>   dir = (struct ext2_dirent *)(block_buffer + offset);
>   direntname = (char *)(dir) + sizeof(struct ext2_dirent);
> diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
> index b0c7303..9ee2caf 100644
> --- a/fs/ext4/ext4fs.c
> +++ b/fs/ext4/ext4fs.c
> @@ -64,6 +64,9 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
>   char *delayed_buf = NULL;
>   short status;
>  
> + if (blocksize <= 0)
> + return -1;
> +
>   /* Adjust len so it we can't read past the end of the file. */
>   if (len + pos > filesize)
>   len = (filesize - pos);
> @@ -127,6 +130,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
>   (blockend >> log2blksz);
>   }
>   } else {
> + int n;
>   if (previous_block_number != -1) {
>   /* spill */
>   status = ext4fs_devread(delayed_start,
> @@ -137,7 +141,11 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t 
> pos,
>   return -1;
>   previous_block_number = -1;
>   }
> - memset(buf, 0, blocksize - skipfirst);
> + /* Zero no more than `len' bytes. */
> + n = blocksize - skipfirst;
> + if (n > len)
> + n = len;
> + memset(buf, 0, n);
>   }
>   buf += blocksize - skipfirst;
>   }
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

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

[U-Boot] [PATCH v2 13/18] rockchip: dts: rk3328-evb: Enable gmac2io for rk3328-evb

[David Wu]

Add rk3328-evb gmac support.

Signed-off-by: David Wu 
---

Changes in v2:
- New patch

 arch/arm/dts/rk3328-evb.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index 3dd9d81..336c2d5 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -15,6 +15,13 @@
stdout-path = 
};
 
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
vcc3v3_sdmmc: sdmmc-pwren {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -40,6 +47,13 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
 };
 
  {
@@ -74,6 +88,22 @@
status = "okay";
 };
 
+ {
+   phy-supply = <_phy>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 5>;
+   assigned-clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_EXT>;
+   assigned-clock-parents = <_clkin>, <_clkin>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   tx_delay = <0x26>;
+   rx_delay = <0x11>;
+   status = "okay";
+};
+
 _host0_ehci {
status = "okay";
 };
-- 
2.7.4


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

[U-Boot] [PATCH v2 12/18] rockchip: dts: rk3328: Add gmac2io support

[David Wu]

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Add basic dts configuration for rk3328 gmac2io. Signed-off-by:
   David Wu  --- Changes in v2: - New patch [...] 

Content analysis details:   (5.7 points, 5.0 required)

 pts rule name  description
 -- --
 2.7 RCVD_IN_PSBL   RBL: Received via a relay in PSBL
[211.157.147.130 listed in psbl.surriel.com]
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.130 listed in bl.mailspike.net]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---
Add basic dts configuration for rk3328 gmac2io.

Signed-off-by: David Wu 
---

Changes in v2:
- New patch

 arch/arm/dts/rk3328.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi
index 0bab1e3..5de1059 100644
--- a/arch/arm/dts/rk3328.dtsi
+++ b/arch/arm/dts/rk3328.dtsi
@@ -456,6 +456,25 @@
status = "disabled";
};
 
+   gmac2io: ethernet@ff54 {
+   compatible = "rockchip,rk3328-gmac";
+   reg = <0x0 0xff54 0x0 0x1>;
+   rockchip,grf = <>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_RX>,
+< SCLK_MAC2IO_TX>, < SCLK_MAC2IO_REF>,
+< SCLK_MAC2IO_REFOUT>, < ACLK_MAC2IO>,
+< PCLK_MAC2IO>;
+   clock-names = "stmmaceth", "mac_clk_rx",
+ "mac_clk_tx", "clk_mac_ref",
+ "clk_mac_refout", "aclk_mac",
+ "pclk_mac";
+   resets = < SRST_GMAC2IO_A>;
+   reset-names = "stmmaceth";
+   status = "disabled";
+   };
+
usb_host0_ehci: usb@ff5c {
compatible = "generic-ehci";
reg = <0x0 0xff5c 0x0 0x1>;
-- 
2.7.4


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

[U-Boot] [PATCH v2 11/18] rockchip: configs: Enable GMAC configs for evb-rk3328

[David Wu]

Enable GMAC configs for evb-rk3328

Signed-off-by: David Wu 
---

Changes in v2:
- New patch

 configs/evb-rk3328_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 3b8b104..3d8c04d 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -17,6 +17,7 @@ CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_TIME=y
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_CLK=y
@@ -24,6 +25,10 @@ CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PHY=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_ROCKCHIP_RK3328=y
 CONFIG_DM_PMIC=y
-- 
2.7.4


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

[U-Boot] [PATCH v2 10/18] net: gmac_rockchip: Add rk3328 gmac support

[David Wu]

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  The GMAC2IO in the RK3328 once again is identical to the 
incarnation
   in the RK3288 and the RK3399, except for where some of the configuration
  and control registers are located in the GRF. This adds the RK3328-specific
   logic necessary to reuse this driver. [...] 

Content analysis details:   (5.7 points, 5.0 required)

 pts rule name  description
 -- --
 2.7 RCVD_IN_PSBL   RBL: Received via a relay in PSBL
[211.157.147.134 listed in psbl.surriel.com]
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.134 listed in bl.mailspike.net]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---
The GMAC2IO in the RK3328 once again is identical to the incarnation in
the RK3288 and the RK3399, except for where some of the configuration
and control registers are located in the GRF.

This adds the RK3328-specific logic necessary to reuse this driver.

Signed-off-by: David Wu 
---

Changes in v2:
- New patch

 drivers/net/gmac_rockchip.c | 85 +
 1 file changed, 85 insertions(+)

diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
index 22e3941..f24c347 100644
--- a/drivers/net/gmac_rockchip.c
+++ b/drivers/net/gmac_rockchip.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -86,6 +87,39 @@ static int rk3288_gmac_fix_mac_speed(struct dw_eth_dev *priv)
return 0;
 }
 
+static int rk3328_gmac_fix_mac_speed(struct dw_eth_dev *priv)
+{
+   struct rk3328_grf_regs *grf;
+   int clk;
+   enum {
+   RK3328_GMAC_CLK_SEL_SHIFT = 11,
+   RK3328_GMAC_CLK_SEL_MASK  = GENMASK(12, 11),
+   RK3328_GMAC_CLK_SEL_125M  = 0 << 11,
+   RK3328_GMAC_CLK_SEL_25M   = 3 << 11,
+   RK3328_GMAC_CLK_SEL_2_5M  = 2 << 11,
+   };
+
+   switch (priv->phydev->speed) {
+   case 10:
+   clk = RK3328_GMAC_CLK_SEL_2_5M;
+   break;
+   case 100:
+   clk = RK3328_GMAC_CLK_SEL_25M;
+   break;
+   case 1000:
+   clk = RK3328_GMAC_CLK_SEL_125M;
+   break;
+   default:
+   debug("Unknown phy speed: %d\n", priv->phydev->speed);
+   return -EINVAL;
+   }
+
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   rk_clrsetreg(>mac_con[1], RK3328_GMAC_CLK_SEL_MASK, clk);
+
+   return 0;
+}
+
 static int rk3368_gmac_fix_mac_speed(struct dw_eth_dev *priv)
 {
struct rk3368_grf *grf;
@@ -199,6 +233,50 @@ static void rk3288_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 pdata->tx_delay << RK3288_CLK_TX_DL_CFG_GMAC_SHIFT);
 }
 
+static void rk3328_gmac_set_to_rgmii(struct gmac_rockchip_platdata *pdata)
+{
+   struct rk3328_grf_regs *grf;
+   enum {
+   RK3328_RMII_MODE_SHIFT = 9,
+   RK3328_RMII_MODE_MASK  = BIT(9),
+
+   RK3328_GMAC_PHY_INTF_SEL_SHIFT = 4,
+   RK3328_GMAC_PHY_INTF_SEL_MASK  = GENMASK(6, 4),
+   RK3328_GMAC_PHY_INTF_SEL_RGMII = BIT(4),
+
+   RK3328_RXCLK_DLY_ENA_GMAC_MASK = BIT(1),
+   RK3328_RXCLK_DLY_ENA_GMAC_DISABLE = 0,
+   RK3328_RXCLK_DLY_ENA_GMAC_ENABLE = BIT(1),
+
+   RK3328_TXCLK_DLY_ENA_GMAC_MASK = BIT(0),
+   RK3328_TXCLK_DLY_ENA_GMAC_DISABLE = 0,
+   RK3328_TXCLK_DLY_ENA_GMAC_ENABLE = BIT(0),
+   };
+   enum {
+   RK3328_CLK_RX_DL_CFG_GMAC_SHIFT = 0x7,
+   RK3328_CLK_RX_DL_CFG_GMAC_MASK = GENMASK(13, 7),
+
+   RK3328_CLK_TX_DL_CFG_GMAC_SHIFT = 0x0,
+   RK3328_CLK_TX_DL_CFG_GMAC_MASK = GENMASK(6, 0),
+   };
+
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   rk_clrsetreg(>mac_con[1],
+RK3328_RMII_MODE_MASK |
+RK3328_GMAC_PHY_INTF_SEL_MASK |
+RK3328_RXCLK_DLY_ENA_GMAC_MASK |
+RK3328_TXCLK_DLY_ENA_GMAC_MASK,
+RK3328_GMAC_PHY_INTF_SEL_RGMII |
+RK3328_RXCLK_DLY_ENA_GMAC_MASK |
+RK3328_TXCLK_DLY_ENA_GMAC_ENABLE);
+
+   rk_clrsetreg(>mac_con[0],
+RK3328_CLK_RX_DL_CFG_GMAC_MASK |
+RK3328_CLK_TX_DL_CFG_GMAC_MASK,
+pdata->rx_delay << 

[U-Boot] [PATCH v2 09/18] clk: rockchip: Add rk3328 gamc clock support

[David Wu]

The rk3328 soc has two gmac controllers, one is gmac2io,
the other is gmac2phy. We use the gmac2io rgmii interface
for 1000M phy here.

Signed-off-by: David Wu 
---

Changes in v2:
- New patch

 drivers/clk/rockchip/clk_rk3328.c  | 20 
 include/dt-bindings/clock/rk3328-cru.h |  6 +++---
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3328.c 
b/drivers/clk/rockchip/clk_rk3328.c
index 540d910..0940474 100644
--- a/drivers/clk/rockchip/clk_rk3328.c
+++ b/drivers/clk/rockchip/clk_rk3328.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -393,6 +394,22 @@ static ulong rk3328_i2c_set_clk(struct rk3328_cru *cru, 
ulong clk_id, uint hz)
return DIV_TO_RATE(GPLL_HZ, src_clk_div);
 }
 
+static int rockchip_mac_set_clk(struct rk3328_cru *cru,
+   int periph, uint freq)
+{
+   struct rk3328_grf_regs *grf;
+
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   /* Assuming mac_clk is fed by an external clock */
+   rk_clrsetreg(>soc_con[4], BIT(14),
+BIT(14));
+
+   rk_clrsetreg(>mac_con[1], BIT(10),
+BIT(10));
+
+   return 0;
+}
+
 static ulong rk3328_mmc_get_clk(struct rk3328_cru *cru, uint clk_id)
 {
u32 div, con, con_id;
@@ -558,6 +575,9 @@ static ulong rk3328_clk_set_rate(struct clk *clk, ulong 
rate)
case SCLK_I2C3:
ret = rk3328_i2c_set_clk(priv->cru, clk->id, rate);
break;
+   case SCLK_MAC2IO:
+   ret = rockchip_mac_set_clk(priv->cru, clk->id, rate);
+   break;
case SCLK_PWM:
ret = rk3328_pwm_set_clk(priv->cru, rate);
break;
diff --git a/include/dt-bindings/clock/rk3328-cru.h 
b/include/dt-bindings/clock/rk3328-cru.h
index 6d8bf13..cdc0b33 100644
--- a/include/dt-bindings/clock/rk3328-cru.h
+++ b/include/dt-bindings/clock/rk3328-cru.h
@@ -86,6 +86,9 @@
 #define SCLK_USB3OTG_SUSPEND   97
 #define SCLK_REF_USB3OTG_SRC   98
 #define SCLK_MAC2IO_SRC99
+#define SCLK_MAC2IO100
+#define SCLK_MAC2PHY   101
+#define SCLK_MAC2IO_EXT102
 
 /* dclk gates */
 #define DCLK_LCDC  180
@@ -199,9 +202,6 @@
 
 #define CLK_NR_CLKS(HCLK_HDCP + 1)
 
-#define SCLK_MAC2IO0
-#define SCLK_MAC2PHY   1
-
 #define CLKGRF_NR_CLKS (SCLK_MAC2PHY + 1)
 
 /* soft-reset indices */
-- 
2.7.4


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

Re: [U-Boot] [PATCH] board: imx6: marsboard: Remove doubled #include

[Stefano Babic]

Hi Lukasz,

On 07/11/2017 11:10, Lukasz Majewski wrote:
> The sys_proto.h file has been included earlier in this file.
> 
> Signed-off-by: Lukasz Majewski 
> 
> ---
> 
>  board/embest/mx6boards/mx6boards.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/embest/mx6boards/mx6boards.c 
> b/board/embest/mx6boards/mx6boards.c
> index ae04f68445..965e4f1ec8 100644
> --- a/board/embest/mx6boards/mx6boards.c
> +++ b/board/embest/mx6boards/mx6boards.c
> @@ -36,7 +36,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +
>  DECLARE_GLOBAL_DATA_PTR;
>  
>  #define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP |\
> 

Thanks for fix - applied to u-boot-imx, -master !

I have reapplied support for display5, and I am testing the build again.
If it is ok, I'll send as my last PR to Tom for 2017.11.

Best regards,
Stefano

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

Re: [U-Boot] u-boot <=> kernel compatibility?

[daggs]

Greetings Chris,

> Sent: Wednesday, November 08, 2017 at 12:21 PM
> From: "Chris Moore" 
> To: daggs , "Tom Rini" 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] u-boot <=> kernel compatibility?
>
> Hi,
> 
> Le 08/11/2017 à 09:11, daggs a écrit :
> >> Greetings Tom,
> >>
> >>> Sent: Saturday, November 04, 2017 at 8:37 PM
> >>> From: "Tom Rini" 
> >>> To: daggs 
> >>> Cc: u-boot@lists.denx.de
> >>> Subject: Re: [U-Boot] u-boot <=> kernel compatibility?
> >>>
> >>> On Sat, Nov 04, 2017 at 07:22:06AM +0100, daggs wrote:
> >>>
>  Greetings,
> 
>  is there a minimum kernel version limitation on the latest release of
>  u-boot?  the reason I'm asking is that I'm unable to boot a arm board
>  with latest u-boot and the vendor's kernel which is based on kernel
>  3.14.x
> 
> >>> There is generally not, but what is your actual error?  Thanks!
> >>>
> >> the last print I see is Starting kernel ...
> >> using prints I was able to trace the call to armv8_switch_to_el2, if I'm 
> >> not mistaken, this is a asm code in the kernel I'm trying to boot, am I 
> >> wrong?
> >>
> >> Thanks,
> >>
> >> Dagg.
> > Tom, am I right in the assumption above?
> >
> > Dagg.
> 
> I am neither Tom nor a U-Boot expert but *think* "Starting kernel ..." 
> comes from U-Boot, not the kernel.
> 
> Cheers,
> Chris
> 

that is correct, the actual print comes from u-boot but after the print u-boot 
preforms additional code that ends up in calling armv8_switch_to_el2.
I assume that armv8_switch_to_el2 is defined in kernel, am I correct?

Thanks,

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

Re: [U-Boot] sunxi: SATA link timeout fix

[Jagan Teki]

On Wed, Nov 8, 2017 at 5:35 PM, Peter Robinson  wrote:
> On Wed, Nov 8, 2017 at 11:32 AM, Jagan Teki  wrote:
>> On Tue, Nov 7, 2017 at 5:43 PM, Jagan Teki  wrote:
>>> On Sun, Nov 5, 2017 at 7:11 PM, Werner Böllmann
>>>  wrote:
 After updating u-boot from v2016.01 to 2017.09 i got a "SATA link 0 
 timeout." on my Cubietruck board.
 I tracked this down to this patch.

 http://git.denx.de/?p=u-boot.git;a=commitdiff_plain;h=9fbb0c3aa49f4604b0342cb527a6bd099f92eaeb.
>>>
>>> Look like mdelay missing while moving to board file.
>>
>> Can someone test this?
>
> I boot my Cubietruck off a SATA drive without issues with any of those
> intervening releases but it's a SSD so there would be no spin up time
> compared to spinning rust, I don't have a spare spinning disk to test
> it with though.

So w/o the mdelay work for you?

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

Re: [U-Boot] [PATCH 2/2] sunxi: restore PHYLIB for CONFIG_SUN4I_EMAC users

[Jagan Teki]

On Wed, Nov 8, 2017 at 5:17 PM, Jagan Teki  wrote:
> On Wed, Nov 8, 2017 at 8:38 AM, Artturi Alm  wrote:
>> due misnaming of CONFIG_SUN4I_EMAC in include/configs/sunxi-common.h,
>> likely missed in:
>> commit 3146f0c017df ("Move PHYLIB to Kconfig")
>>
>> Signed-off-by: Artturi Alm 
>
> Reviewed-by: Jagan Teki 

Applied to u-boot-sunxi/master

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

Re: [U-Boot] [PATCH 1/2] sunxi: fix CONFIG_SUNXI_EMAC references

[Jagan Teki]

On Wed, Nov 8, 2017 at 5:17 PM, Jagan Teki  wrote:
> On Wed, Nov 8, 2017 at 8:38 AM, Artturi Alm  wrote:
>> fixes CONFIG_SUNXI_EMAC references from drivers/net/Makefile and
>> include/configs/sunxi-common.h likely forgotten in:
>> commit abc3e4df59f5 ("sunxi: Convert SUNXI_EMAC to Kconfig")
>>
>> Signed-off-by: Artturi Alm 
>
> Reviewed-by: Jagan Teki 

Applied to u-boot-sunxi/master


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

[U-Boot] [PATCH v2 08/18] rockchip: pinctrl: Add rk3328 gmac pinctrl support

[David Wu]

Need to set gmac m1 pins iomux, gmac m0 tx pins, select bit2
and bit10 at com iomux register. After that, set rgmii m1 tx
pins to 12ma drive-strength, and clean others to 2ma.

Signed-off-by: David Wu 
---

Changes in v2:
- New patch

 drivers/pinctrl/rockchip/pinctrl_rk3328.c | 236 ++
 1 file changed, 236 insertions(+)

diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3328.c 
b/drivers/pinctrl/rockchip/pinctrl_rk3328.c
index 0042025..c155027 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3328.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3328.c
@@ -72,6 +72,69 @@ enum {
GPIO1A0_SEL_MASK= 0x3fff << GPIO1A0_SEL_SHIFT,
GPIO1A0_CARD_DATA_CLK_CMD_DETN  = 0x1555,
 
+   /* GPIO1B_IOMUX */
+   GPIO1B0_SEL_SHIFT   = 0,
+   GPIO1B0_SEL_MASK= GENMASK(1, 0),
+   GPIO1B0_GMAC_TXD1M1 = 2,
+
+   GPIO1B1_SEL_SHIFT   = 2,
+   GPIO1B1_SEL_MASK= GENMASK(3, 2),
+   GPIO1B1_GMAC_TXD0M1 = 2,
+
+   GPIO1B2_SEL_SHIFT   = 4,
+   GPIO1B2_SEL_MASK= GENMASK(5, 4),
+   GPIO1B2_GMAC_RXD1M1 = 2,
+
+   GPIO1B3_SEL_SHIFT   = 6,
+   GPIO1B3_SEL_MASK= GENMASK(7, 6),
+   GPIO1B3_GMAC_RXD0M1 = 2,
+
+   GPIO1B4_SEL_SHIFT   = 8,
+   GPIO1B4_SEL_MASK= GENMASK(9, 8),
+   GPIO1B4_GMAC_TXCLKM1= 2,
+
+   GPIO1B5_SEL_SHIFT   = 10,
+   GPIO1B5_SEL_MASK= GENMASK(11, 10),
+   GPIO1B5_GMAC_RXCLKM1= 2,
+
+   GPIO1B6_SEL_SHIFT   = 12,
+   GPIO1B6_SEL_MASK= GENMASK(13, 12),
+   GPIO1B6_GMAC_RXD3M1 = 2,
+
+   GPIO1B7_SEL_SHIFT   = 14,
+   GPIO1B7_SEL_MASK= GENMASK(15, 14),
+   GPIO1B7_GMAC_RXD2M1 = 2,
+
+   /* GPIO1C_IOMUX */
+   GPIO1C0_SEL_SHIFT   = 0,
+   GPIO1C0_SEL_MASK= GENMASK(1, 0),
+   GPIO1C0_GMAC_TXD3M1 = 2,
+
+   GPIO1C1_SEL_SHIFT   = 2,
+   GPIO1C1_SEL_MASK= GENMASK(3, 2),
+   GPIO1C1_GMAC_TXD2M1 = 2,
+
+   GPIO1C3_SEL_SHIFT   = 6,
+   GPIO1C3_SEL_MASK= GENMASK(7, 6),
+   GPIO1C3_GMAC_MDIOM1 = 2,
+
+   GPIO1C5_SEL_SHIFT   = 10,
+   GPIO1C5_SEL_MASK= GENMASK(11, 10),
+   GPIO1C5_GMAC_CLKM1  = 2,
+
+   GPIO1C6_SEL_SHIFT   = 12,
+   GPIO1C6_SEL_MASK= GENMASK(13, 12),
+   GPIO1C6_GMAC_RXDVM1 = 2,
+
+   GPIO1C7_SEL_SHIFT   = 14,
+   GPIO1C7_SEL_MASK= GENMASK(15, 14),
+   GPIO1C7_GMAC_MDCM1  = 2,
+
+   /* GPIO1D_IOMUX */
+   GPIO1D1_SEL_SHIFT   = 2,
+   GPIO1D1_SEL_MASK= GENMASK(3, 2),
+   GPIO1D1_GMAC_TXENM1 = 2,
+
/* GPIO2A_IOMUX */
GPIO2A0_SEL_SHIFT   = 0,
GPIO2A0_SEL_MASK= 3 << GPIO2A0_SEL_SHIFT,
@@ -149,6 +212,11 @@ enum {
IOMUX_SEL_UART2_M0  = 0,
IOMUX_SEL_UART2_M1,
 
+   IOMUX_SEL_GMAC_SHIFT= 2,
+   IOMUX_SEL_GMAC_MASK = BIT(2),
+   IOMUX_SEL_GMAC_M0   = 0,
+   IOMUX_SEL_GMAC_M1,
+
IOMUX_SEL_SPI_SHIFT = 4,
IOMUX_SEL_SPI_MASK  = 3 << IOMUX_SEL_SPI_SHIFT,
IOMUX_SEL_SPI_M0= 0,
@@ -159,6 +227,47 @@ enum {
IOMUX_SEL_SDMMC_MASK= 1 << IOMUX_SEL_SDMMC_SHIFT,
IOMUX_SEL_SDMMC_M0  = 0,
IOMUX_SEL_SDMMC_M1,
+
+   IOMUX_SEL_GMACM1_OPTIMIZATION_SHIFT = 10,
+   IOMUX_SEL_GMACM1_OPTIMIZATION_MASK  = BIT(10),
+   IOMUX_SEL_GMACM1_OPTIMIZATION_BEFORE= 0,
+   IOMUX_SEL_GMACM1_OPTIMIZATION_AFTER,
+
+   /* GRF_GPIO1B_E */
+   GRF_GPIO1B0_E_SHIFT = 0,
+   GRF_GPIO1B0_E_MASK = GENMASK(1, 0),
+   GRF_GPIO1B1_E_SHIFT = 2,
+   GRF_GPIO1B1_E_MASK = GENMASK(3, 2),
+   GRF_GPIO1B2_E_SHIFT = 4,
+   GRF_GPIO1B2_E_MASK = GENMASK(5, 4),
+   GRF_GPIO1B3_E_SHIFT = 6,
+   GRF_GPIO1B3_E_MASK = GENMASK(7, 6),
+   GRF_GPIO1B4_E_SHIFT = 8,
+   GRF_GPIO1B4_E_MASK = GENMASK(9, 8),
+   GRF_GPIO1B5_E_SHIFT = 10,
+   GRF_GPIO1B5_E_MASK = GENMASK(11, 10),
+   GRF_GPIO1B6_E_SHIFT = 12,
+   GRF_GPIO1B6_E_MASK = GENMASK(13, 12),
+   GRF_GPIO1B7_E_SHIFT = 14,
+   GRF_GPIO1B7_E_MASK = GENMASK(15, 14),
+
+   /*  GRF_GPIO1C_E */
+   GRF_GPIO1C0_E_SHIFT = 0,
+   GRF_GPIO1C0_E_MASK = GENMASK(1, 0),
+   GRF_GPIO1C1_E_SHIFT = 2,
+   GRF_GPIO1C1_E_MASK = GENMASK(3, 2),
+   GRF_GPIO1C3_E_SHIFT = 6,
+   GRF_GPIO1C3_E_MASK = GENMASK(7, 6),
+   GRF_GPIO1C5_E_SHIFT = 10,
+   GRF_GPIO1C5_E_MASK = GENMASK(11, 10),
+   GRF_GPIO1C6_E_SHIFT = 12,
+   GRF_GPIO1C6_E_MASK = GENMASK(13, 12),
+   GRF_GPIO1C7_E_SHIFT = 14,
+   GRF_GPIO1C7_E_MASK = GENMASK(15, 14),
+
+   /*  GRF_GPIO1D_E */
+   GRF_GPIO1D1_E_SHIFT = 2,
+   GRF_GPIO1D1_E_MASK = GENMASK(3, 2),
 };
 
 struct rk3328_pinctrl_priv {
@@ -344,6 +453,124 @@ static void pinctrl_rk3328_sdmmc_config(struct 
rk3328_grf_regs *grf,
}
 }
 
+#if 

[U-Boot] [PATCH v2 07/18] rockchip: pinctrl: rk3328: Move the iomux definitions into pinctrl-driver

[David Wu]

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Clean the iomux definitions at grf_rk3328.h, and move them
   into pinctrl-driver for resolving the compiling error of redefinition. 
Signed-off-by:
   David Wu  --- Changes in v2: - New patch [...] 

Content analysis details:   (6.5 points, 5.0 required)

 pts rule name  description
 -- --
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 2.7 RCVD_IN_PSBL   RBL: Received via a relay in PSBL
[211.157.147.134 listed in psbl.surriel.com]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.134 listed in bl.mailspike.net]
 0.8 UPPERCASE_50_75message body is 50-75% uppercase
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---
Clean the iomux definitions at grf_rk3328.h, and move them into
pinctrl-driver for resolving the compiling error of redefinition.

Signed-off-by: David Wu 
---

Changes in v2:
- New patch

 arch/arm/include/asm/arch-rockchip/grf_rk3328.h | 113 ---
 drivers/pinctrl/rockchip/pinctrl_rk3328.c   | 144 
 2 files changed, 144 insertions(+), 113 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3328.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3328.h
index f0a0781..0c37f2a 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3328.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3328.h
@@ -131,118 +131,5 @@ struct rk3328_sgrf_regs {
 };
 check_member(rk3328_sgrf_regs, hdcp_key_access_mask, 0x2a0);
 
-enum {
-   /* GPIO0A_IOMUX */
-   GPIO0A5_SEL_SHIFT   = 10,
-   GPIO0A5_SEL_MASK= 3 << GPIO0A5_SEL_SHIFT,
-   GPIO0A5_I2C3_SCL= 2,
-
-   GPIO0A6_SEL_SHIFT   = 12,
-   GPIO0A6_SEL_MASK= 3 << GPIO0A6_SEL_SHIFT,
-   GPIO0A6_I2C3_SDA= 2,
-
-   GPIO0A7_SEL_SHIFT   = 14,
-   GPIO0A7_SEL_MASK= 3 << GPIO0A7_SEL_SHIFT,
-   GPIO0A7_EMMC_DATA0  = 2,
-
-   /* GPIO0D_IOMUX*/
-   GPIO0D6_SEL_SHIFT   = 12,
-   GPIO0D6_SEL_MASK= 3 << GPIO0D6_SEL_SHIFT,
-   GPIO0D6_GPIO= 0,
-   GPIO0D6_SDMMC0_PWRENM1  = 3,
-
-   /* GPIO1A_IOMUX */
-   GPIO1A0_SEL_SHIFT   = 0,
-   GPIO1A0_SEL_MASK= 0x3fff << GPIO1A0_SEL_SHIFT,
-   GPIO1A0_CARD_DATA_CLK_CMD_DETN  = 0x1555,
-
-   /* GPIO2A_IOMUX */
-   GPIO2A0_SEL_SHIFT   = 0,
-   GPIO2A0_SEL_MASK= 3 << GPIO2A0_SEL_SHIFT,
-   GPIO2A0_UART2_TX_M1 = 1,
-
-   GPIO2A1_SEL_SHIFT   = 2,
-   GPIO2A1_SEL_MASK= 3 << GPIO2A1_SEL_SHIFT,
-   GPIO2A1_UART2_RX_M1 = 1,
-
-   GPIO2A2_SEL_SHIFT   = 4,
-   GPIO2A2_SEL_MASK= 3 << GPIO2A2_SEL_SHIFT,
-   GPIO2A2_PWM_IR  = 1,
-
-   GPIO2A4_SEL_SHIFT   = 8,
-   GPIO2A4_SEL_MASK= 3 << GPIO2A4_SEL_SHIFT,
-   GPIO2A4_PWM_0   = 1,
-   GPIO2A4_I2C1_SDA,
-
-   GPIO2A5_SEL_SHIFT   = 10,
-   GPIO2A5_SEL_MASK= 3 << GPIO2A5_SEL_SHIFT,
-   GPIO2A5_PWM_1   = 1,
-   GPIO2A5_I2C1_SCL,
-
-   GPIO2A6_SEL_SHIFT   = 12,
-   GPIO2A6_SEL_MASK= 3 << GPIO2A6_SEL_SHIFT,
-   GPIO2A6_PWM_2   = 1,
-
-   GPIO2A7_SEL_SHIFT   = 14,
-   GPIO2A7_SEL_MASK= 3 << GPIO2A7_SEL_SHIFT,
-   GPIO2A7_GPIO= 0,
-   GPIO2A7_SDMMC0_PWRENM0,
-
-   /* GPIO2BL_IOMUX */
-   GPIO2BL0_SEL_SHIFT  = 0,
-   GPIO2BL0_SEL_MASK   = 0x3f << GPIO2BL0_SEL_SHIFT,
-   GPIO2BL0_SPI_CLK_TX_RX_M0   = 0x15,
-
-   GPIO2BL3_SEL_SHIFT  = 6,
-   GPIO2BL3_SEL_MASK   = 3 << GPIO2BL3_SEL_SHIFT,
-   GPIO2BL3_SPI_CSN0_M0= 1,
-
-   GPIO2BL4_SEL_SHIFT  = 8,
-   GPIO2BL4_SEL_MASK   = 3 << GPIO2BL4_SEL_SHIFT,
-   GPIO2BL4_SPI_CSN1_M0= 1,
-
-   GPIO2BL5_SEL_SHIFT  = 10,
-   GPIO2BL5_SEL_MASK   = 3 << GPIO2BL5_SEL_SHIFT,
-   GPIO2BL5_I2C2_SDA   = 1,
-
-   GPIO2BL6_SEL_SHIFT  = 12,
-   GPIO2BL6_SEL_MASK   = 3 << GPIO2BL6_SEL_SHIFT,
-   GPIO2BL6_I2C2_SCL   = 1,
-
-   /* GPIO2D_IOMUX */
-   GPIO2D0_SEL_SHIFT   = 0,
-   GPIO2D0_SEL_MASK= 3 << GPIO2D0_SEL_SHIFT,
-   GPIO2D0_I2C0_SCL= 1,
-
-   GPIO2D1_SEL_SHIFT   = 2,
-   GPIO2D1_SEL_MASK= 3 << GPIO2D1_SEL_SHIFT,
-   GPIO2D1_I2C0_SDA= 1,
-
-   GPIO2D4_SEL_SHIFT   = 8,
-   GPIO2D4_SEL_MASK= 0xff << 

[U-Boot] [PATCH v2 06/18] net: gmac_rockchip: Add support for the RV1108 GMAC

[David Wu]

The rv1108 GMAC only support rmii interface, so need to add the
set_rmii() ops. Use the phy current interface to set rmii or
rgmii ops. At the same time, need to set the mac clock rate of
rmii with 50M, the clock rate of rgmii with 125M.

Signed-off-by: David Wu 
---

Changes in v2:
- Add check whether the set rgmii/rmii function is a valid function pointer
- Use current phy interface to set mac clock rate
- Clean the grf offset at gmac_rockchip.c

 drivers/net/gmac_rockchip.c | 89 +
 1 file changed, 82 insertions(+), 7 deletions(-)

diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
index 586ccbf..22e3941 100644
--- a/drivers/net/gmac_rockchip.c
+++ b/drivers/net/gmac_rockchip.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "designware.h"
@@ -37,6 +38,7 @@ struct gmac_rockchip_platdata {
 
 struct rk_gmac_ops {
int (*fix_mac_speed)(struct dw_eth_dev *priv);
+   void (*set_to_rmii)(struct gmac_rockchip_platdata *pdata);
void (*set_to_rgmii)(struct gmac_rockchip_platdata *pdata);
 };
 
@@ -142,6 +144,41 @@ static int rk3399_gmac_fix_mac_speed(struct dw_eth_dev 
*priv)
return 0;
 }
 
+static int rv1108_set_rmii_speed(struct dw_eth_dev *priv)
+{
+   struct rv1108_grf *grf;
+   int clk, speed;
+   enum {
+   RV1108_GMAC_SPEED_MASK  = BIT(2),
+   RV1108_GMAC_SPEED_10M   = 0 << 2,
+   RV1108_GMAC_SPEED_100M  = 1 << 2,
+   RV1108_GMAC_CLK_SEL_MASK= BIT(7),
+   RV1108_GMAC_CLK_SEL_2_5M= 0 << 7,
+   RV1108_GMAC_CLK_SEL_25M = 1 << 7,
+   };
+
+   switch (priv->phydev->speed) {
+   case 10:
+   clk = RV1108_GMAC_CLK_SEL_2_5M;
+   speed = RV1108_GMAC_SPEED_10M;
+   break;
+   case 100:
+   clk = RV1108_GMAC_CLK_SEL_25M;
+   speed = RV1108_GMAC_SPEED_100M;
+   break;
+   default:
+   debug("Unknown phy speed: %d\n", priv->phydev->speed);
+   return -EINVAL;
+   }
+
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   rk_clrsetreg(>gmac_con0,
+RV1108_GMAC_CLK_SEL_MASK | RV1108_GMAC_SPEED_MASK,
+clk | speed);
+
+   return 0;
+}
+
 static void rk3288_gmac_set_to_rgmii(struct gmac_rockchip_platdata *pdata)
 {
struct rk3288_grf *grf;
@@ -221,11 +258,28 @@ static void rk3399_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 pdata->tx_delay << RK3399_CLK_TX_DL_CFG_GMAC_SHIFT);
 }
 
+static void rv1108_gmac_set_to_rmii(struct gmac_rockchip_platdata *pdata)
+{
+   struct rv1108_grf *grf;
+
+   enum {
+   RV1108_GMAC_PHY_INTF_SEL_MASK  = GENMASK(6, 4),
+   RV1108_GMAC_PHY_INTF_SEL_RMII  = 4 << 4,
+   };
+
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   rk_clrsetreg(>gmac_con0,
+RV1108_GMAC_PHY_INTF_SEL_MASK,
+RV1108_GMAC_PHY_INTF_SEL_RMII);
+}
+
 static int gmac_rockchip_probe(struct udevice *dev)
 {
struct gmac_rockchip_platdata *pdata = dev_get_platdata(dev);
struct rk_gmac_ops *ops =
(struct rk_gmac_ops *)dev_get_driver_data(dev);
+   struct dw_eth_pdata *dw_pdata = dev_get_platdata(dev);
+   struct eth_pdata *eth_pdata = _pdata->eth_pdata;
struct clk clk;
int ret;
 
@@ -233,13 +287,27 @@ static int gmac_rockchip_probe(struct udevice *dev)
if (ret)
return ret;
 
-   /* Since mac_clk is fed by an external clock we can use 0 here */
-   ret = clk_set_rate(, 0);
-   if (ret)
-   return ret;
-
-   /* Set to RGMII mode */
-   ops->set_to_rgmii(pdata);
+   switch (eth_pdata->phy_interface) {
+   case PHY_INTERFACE_MODE_RGMII:
+   ret = clk_set_rate(, 12500);
+   if (IS_ERR_VALUE(ret))
+   return ret;
+   /* Set to RGMII mode */
+   if (ops->set_to_rgmii)
+   ops->set_to_rgmii(pdata);
+   break;
+   case PHY_INTERFACE_MODE_RMII:
+   ret = clk_set_rate(, 5000);
+   if (IS_ERR_VALUE(ret))
+   return ret;
+   /* Set to RMII mode */
+   if (ops->set_to_rmii)
+   ops->set_to_rmii(pdata);
+   break;
+   default:
+   debug("NO interface defined!\n");
+   return -ENXIO;
+   }
 
return designware_eth_probe(dev);
 }
@@ -289,6 +357,11 @@ const struct rk_gmac_ops rk3399_gmac_ops = {
.set_to_rgmii = rk3399_gmac_set_to_rgmii,
 };
 
+const struct rk_gmac_ops rv1108_gmac_ops = {
+   .fix_mac_speed = rv1108_set_rmii_speed,
+   .set_to_rmii = rv1108_gmac_set_to_rmii,
+};
+