Re: [U-Boot] [PATCH] arm: socfpga: fix bootcounter by reserving SRAM
Simon Goldschmidt schrieb am Mo., 29.
Okt. 2018, 21:47:
> Commit 768f23dc8ae3 ("ARM: socfpga: Put stack at the end of SRAM")
> broke those socfpga boards that keep the bootcounter at the
> end of the internal SRAM as the bootcounter needs 8 bytes
> by default and thus the very first SPL call to
> board_init_f_alloc_reserve overwrites the bootcounter.
>
> This patch allows to move the initial stack pointer down a
> bit to allow boards to reserve some of the internal SRAM for
> other features (like the bootcounter).
>
> Signed-off-by: Simon Goldschmidt
>
Ok, it seems I have forgotten that I had sent this already:
https://patchwork.ozlabs.org/patch/913230/
However, I can't find that mail so I'll respond to Marek here.
Moving this to common memory reservation code does not work as the very
first call to board_init_f_alloc_reserve() already overwrites the boot
counter. This in that function it is too late. By changing the initial
stack pointer define, it is ensured that no code writes to that memory.
Simon
---
>
> include/configs/socfpga_common.h | 6 +-
> include/configs/socfpga_is1.h| 9 +
> include/configs/socfpga_sr1500.h | 3 ++-
> 3 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/include/configs/socfpga_common.h
> b/include/configs/socfpga_common.h
> index 2330143cf1..1e26630330 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -31,8 +31,12 @@
> #define CONFIG_SYS_INIT_RAM_ADDR 0xFFE0
> #define CONFIG_SYS_INIT_RAM_SIZE 0x4 /* 256KB */
> #endif
> +#ifndef SOCFPGA_INIT_RAM_END_RESERVE
> +#define SOCFPGA_INIT_RAM_END_RESERVE 0
> +#endif
> #define CONFIG_SYS_INIT_SP_ADDR\
> - (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)
> + (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE - \
> +SOCFPGA_INIT_RAM_END_RESERVE)
>
> #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
>
> diff --git a/include/configs/socfpga_is1.h b/include/configs/socfpga_is1.h
> index c233c208a5..3c80c0f45c 100644
> --- a/include/configs/socfpga_is1.h
> +++ b/include/configs/socfpga_is1.h
> @@ -23,12 +23,13 @@
> /* PHY */
> #endif
>
> -/* The rest of the configuration is shared */
> -#include
> -
> /*
> - * Bootcounter
> + * Bootcounter (8 bytes at the end of internal SRAM)
> */
> #define CONFIG_SYS_BOOTCOUNT_BE
> +#define SOCFPGA_INIT_RAM_END_RESERVE 8
> +
> +/* The rest of the configuration is shared */
> +#include
>
> #endif /* __CONFIG_SOCFPGA_IS1_H__ */
> diff --git a/include/configs/socfpga_sr1500.h
> b/include/configs/socfpga_sr1500.h
> index 984f1183fd..b7b43fc6af 100644
> --- a/include/configs/socfpga_sr1500.h
> +++ b/include/configs/socfpga_sr1500.h
> @@ -25,9 +25,10 @@
> #define CONFIG_SPI_N25Q256A_RESET
>
> /*
> - * Bootcounter
> + * Bootcounter (8 bytes at the end of internal SRAM)
> */
> #define CONFIG_SYS_BOOTCOUNT_BE
> +#define SOCFPGA_INIT_RAM_END_RESERVE 8
>
> /* Environment setting for SPI flash */
> #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
> --
> 2.17.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] riscv: cache: Implement i/dcache [status, enable, disable]
Auer, Lukas 於 2018年10月29日 週一 下午8:13寫道：
>
> Hi Rick,
>
> On Mon, 2018-10-29 at 11:16 +0800, Rick Chen wrote:
> > Auer, Lukas 於 2018年10月27日 週六
> > 上午12:32寫道：
> > >
> > > Hi Rick,
> > >
> > > On Mon, 2018-10-22 at 16:16 +0800, Andes wrote:
> > > > From: Rick Chen
> > > >
> > > > AndeStar V5 provide mcache_ctl register which can configure
> > > > I/D cache as enabled or disabled.
> > > >
> > > > This CSR will be encapsulated by CONFIG_NDS_V5.
> > > > If you want to configure cache on AndeStar V5
> > > > AE350 platform. YOu can enable [*] AndeStar V5 ISA support
> > > > by make menuconfig.
> > > >
> > > > Signed-off-by: Rick Chen
> > > > Cc: Greentime Hu
> > > > ---
> > > > arch/riscv/Kconfig | 8 +++
> > > > arch/riscv/cpu/ax25/cpu.c | 4 ++
> > > > arch/riscv/cpu/start.S | 19 ++
> > > > arch/riscv/include/asm/cache.h | 9 +++
> > > > arch/riscv/lib/cache.c | 131
> > > > ++---
> > > > 5 files changed, 163 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > > index 168ca3d..de7fd9e 100644
> > > > --- a/arch/riscv/Kconfig
> > > > +++ b/arch/riscv/Kconfig
> > > > @@ -43,4 +43,12 @@ config 32BIT
> > > > config 64BIT
> > > > bool
> > > >
> > > > +config NDS_V5
> > > > + bool "AndeStar V5 ISA support"
> > > > + def_bool n
> > >
> > > You can use just "default n" instead of "def_bool n" here, since
> > > you
> > > already have a "bool" above it.
> > >
> >
> > I will reword it.
> >
> > > > + help
> > > > + Say Y here if you plan to run U-Boot on AndeStar v5
> > > > + platforms and use some specific features which are
> > > > + provided by Andes Technology AndeStar V5 Families.
> > > > +
> > > > endmenu
> > > > diff --git a/arch/riscv/cpu/ax25/cpu.c
> > > > b/arch/riscv/cpu/ax25/cpu.c
> > > > index fddcc15..76689b2 100644
> > > > --- a/arch/riscv/cpu/ax25/cpu.c
> > > > +++ b/arch/riscv/cpu/ax25/cpu.c
> > > > @@ -6,6 +6,7 @@
> > > >
> > > > /* CPU specific code */
> > > > #include
> > > > +#include
> > > >
> > > > /*
> > > > * cleanup_before_linux() is called just before we call linux
> > > > @@ -18,6 +19,9 @@ int cleanup_before_linux(void)
> > > > disable_interrupts();
> > > >
> > > > /* turn off I/D-cache */
> > > > + cache_flush();
> > >
> > > I don't think you need to flush the data cache here. This should be
> > > handled by bootm_load_os() in common/bootm.c.
> > >
> >
> > Do you mean
> > flush_cache(flush_start, ALIGN(flush_len, ARCH_DMA_MINALIGN)); ?
> > Ii is different cache API and implement.
> >
>
> Yes I did mean flush_cache(), however I did not check if it is
> implemented. Perhaps it's best to implement it and rely on it to flush
> the cache?
>
> > If flush_cache is implemented, why you still add
> > invalidate_icache_all(); in boot_jump_linux 0f bootm.c
> > Do it have special reason ?
> >
>
> RISC-V does not guarantee that stores to instruction memory are visible
> to instruction fetches (i.e. incoherent instruction caches). You are
> right, we do not need to flush the instruction cache explicitly to make
> the kernel visible to instruction fetches. We need it for a separate
> reason. Simplified, we do the following to start Linux.
>
> kernel = kernel_address;
> kernel();
>
> Without a fence.i in between, we can not guarantee that kernel() will
> jump to the address specified in kernel_address. This is because the
> instruction cache is incoherent with the rest of the memory system, it
> must therefore be synchronized first.
> This is the reason, why I added the instruction cache invalidation to
> the bootm code.
>
Yes
I do agree with that i-cache invalidate is necessary before kernel() .
But U-Boot offer two cache hook function
the first one is as you said
flush_cache(flush_start, ALIGN(flush_len, ARCH_DMA_MINALIGN));
in common/bootm.c
the second one is
cache_flush() which will be call in cleanup_before_linux()
and this two function can will be implemented as below in cache.c
The both two also will be executed before kernel()
void cache_flush(void)
{
invalidate_icache_all();
flush_dcache_all();
}
void flush_cache(unsigned long addr, unsigned long size)
{
invalidate_icache_all();
flush_dcache_all();
}
But no mater what, I think separate them is a good idea.
> >
> > > > + icache_disable();
> > > > + dcache_disable();
> > > >
> > > > return 0;
> > > > }
> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > index 7cd7755..a8764df 100644
> > > > --- a/arch/riscv/cpu/start.S
> > > > +++ b/arch/riscv/cpu/start.S
> > > > @@ -51,6 +51,23 @@ handle_reset:
> > > > csrwi mstatus, 0
> > > > csrwi mie, 0
> > > >
> > > > +/* Enable cache */
> > > > +#ifndef CONFIG_SYS_ICACHE_OFF
> > > > +#ifdef CONFIG_NDS_V5
> > > > + csrr t1, mcache_ctl
> > > > + ori t0, t1, 0x1
> > > > + csrw mcache_ctl, t0
> > > > +#endif
> > > >
Re: [U-Boot] [PATCH 22/30] riscv: remove unused labels in start.S
Auer, Lukas 於 2018年10月30日 週二 上午12:43寫道：
>
> Hi Rick,
>
> On Thu, 2018-10-25 at 15:56 +, Auer, Lukas wrote:
> > Hi Rick,
> >
> > On Thu, 2018-10-25 at 09:16 +0800, Rick Chen wrote:
> > > Auer, Lukas 於 2018年10月24日 週三
> > > 下午10:14寫道：
> > > >
> > > > Hi Rick,
> > > >
> > > > On Wed, 2018-10-24 at 13:47 +0800, Rick Chen wrote:
> > > > > Rick Chen 於 2018年10月24日 週三 下午1:20寫道：
> > > > > >
> > > > > > Bin Meng 於 2018年10月24日 週三 上午11:34寫道：
> > > > > > >
> > > > > > > Hi Rich,
> > > > > > >
> > > > > > > On Wed, Oct 24, 2018 at 10:37 AM Rick Chen <
> > > > > > > rickche...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > > > The labels nmi_vector, trap_vector and handle_reset
> > > > > > > > > > > in
> > > > > > > > > > > start.S are not
> > > > > > > > > > > used for RISC-V. Remove them.
> > > > > > > > > > >
> > > > > > > >
> > > > > > > > Hi Lukas
> > > > > > > >
> > > > > > > > Agree with the above part.
> > > > > > > >
> > > > > > > > > > > While we are here, also remove the code from the
> > > > > > > > > > > beginning of start.S,
> > > > > > > > > > > which stores the contents of a2 to memory. Only
> > > > > > > > > > > registers
> > > > > > > > > > > a0 and a1
> > > > > > > > > > > contain information from the previous boot stage.
> > > > > > > > > > > There
> > > > > > > > > > > is therefore
> > > > > > > > > > > no reason for saving a2.
> > > > > > > >
> > > > > > > > NOT agree with this part.
> > > > > > > > Saving a2 is trying to support dynamically dtb pass at
> > > > > > > > runtime.
> > > > > > > >
> > > > > > >
> > > > > > > Could you please describe in more details on what the use
> > > > > > > case is
> > > > > > > here?
> > > > > > >
> > > > > >
> > > > > > Hi Bin and Lukas
> > > > > >
> > > > > > After I study [PATCH 24/30] riscv: save hart ID and device
> > > > > > tree
> > > > > > passed
> > > > > > by prior boot stage.
> > > > > > I found it is the same thing.
> > > > > > I will accepted this patch.
> > > > > > So this patch is
> > > > > >
> > > > > > Reviewed-by: Rick Chen
> > > > > >
> > > > > > But I shall send a patch to fix ax25-ae350 to work as well
> > > > > > later.
> > > > > > And it will be as below :
> > > > > >
> > > > > > ax5-ae350.c
> > > > > > void *board_fdt_blob_setup(void)
> > > > > > {
> > > > > > void **ptr = (void *)_stage_fdt_address;
> > > > > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > > > return (void *)*ptr;
> > > > > >
> > > > > > return (void *)CONFIG_SYS_FDT_BASE;
> > > > > > }
> > > > > >
> > > > >
> > > > > Sorry!
> > > > >
> > > > > I shall send a fixed patch as below:
> > > > > riscv: ax25-ae350: use device tree passed by prior boot stage
> > > > >
> > > > > --- a/configs/ax25-ae350_defconfig
> > > > > +++ b/configs/ax25-ae350_defconfig
> > > > > @@ -15,7 +15,7 @@ CONFIG_CMD_SF_TEST=y
> > > > > # CONFIG_CMD_SETEXPR is not set
> > > > > CONFIG_BOOTP_PREFER_SERVERIP=y
> > > > > CONFIG_CMD_CACHE=y
> > > > > -CONFIG_OF_BOARD=y
> > > > > +CONFIG_OF_PRIOR_STAGE=y
> > > > >
> > > > > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > @@ -64,15 +64,6 @@ ulong board_flash_get_legacy(ulong base, int
> > > > > banknum, flash_info_t *info)
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -void *board_fdt_blob_setup(void)
> > > > > -{
> > > > > - void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > - if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > > - return (void *)*ptr;
> > > > > -
> > > > > - return (void *)CONFIG_SYS_FDT_BASE;
> > > > > -}
> > > > > -
> > > > >
> > > > > Rick
> > > > >
> > > >
> > > > Sorry, I have missed your commit. Just to clarify, does the ax25
> > > > pass
> > > > the device tree in a2 instead of a1? In that case, my patch must
> > > > be
> > > > changed since it assumes the device tree to be in a1.
> > > > Related to this, can I assume that a0 stores the hart ID?
> > > >
> > > > If you want, I can add this patch to my series.
> > > >
> > >
> > > Hi Lukas
> > >
> > > Your patch is correct.
> > > I will send out a patch to fix the mismatch in ax25-ae350 later.
> > > And maybe you can put this patch into your v2 series.
> > >
> > > Thanks
> > >
> > > Rick
> > >
> >
> > Ok. Yes, I will pick up your patch in my v2.
> >
>
> Do you want me to wait with my patch series until it is clear how ax25-
> ae350 handles the device tree? Otherwise, I will drop the part of this
> patch that removes the code storing a2 to avoid breaking your board and
> send v2 of my series.
>
Hi Likas
It is ok to keep this patch into v2
[PATCH 22/30] riscv: remove unused labels in start.S
I will send a patch to fix it after your series.
Rick
> Thanks,
> Lukas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Kbuild: add LDFLAGS_STANDALONE
> > > > Introduce a new Makefile variable for passing LDFLAGS to standalone > > > > programs. Currently the variable CONFIG_STANDALONE_LOAD_ADDR is > > > > misued on some archs to pass a specific linker script. > > > > > > are there any objections or can I apply this to u-boot-mips/next? Thanks. > > > > Go ahead: > > > > Reviewed-by: Tom Rini > > Reviewed-by: Rick Chen > > -- > > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] am33xx board with no external RTC crystal issue
Hi,
I'm working on custome am33xx based HW which have no external 32KHz
crystal. Anyway I want to use bootcount feature. I was trying to use
internal PRCM CLK_32KHZ clock as source for RTCSS but still when want
to read RTC registers I get data abort.
I adapted this method :
static void rtc32k_enable(void)
{
struct davinci_rtc *rtc = (struct davinci_rtc *)RTC_BASE;
/*
* Unlock the RTC's registers. For more details please see the
* RTC_SS section of the TRM. In order to unlock we need to
@@ -287,9 +288,8 @@ static void rtc32k_enable(void)
writel(RTC_KICK1R_WE, >kick1r);
/* Enable the RTC 32K OSC by setting bits 3 and 6. */
- writel((1 << 3) | (1 << 6), >osc);
+ writel((1 << 6), >osc);
}
to not use external crystal 32KHz clock but internal. Anyway when
doing that board just hangs and thats it. Any ideas or suggestions? It
is even possible to have something like that? I just seen that
include/configs/siemens-am33x-common.h (using also am335x cpu without
external 32KHz crystal) storing bootcount to env. Thanks a lot for any
pointers.
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] Aquantia: Print information about system interface and firmaware version
Print information about Aquantia firmware loaded on the phy
Signed-off-by: Valentin Catalin Neacsu
---
drivers/net/phy/aquantia.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia.c
index 57eede14ce..f4060499c3 100644
--- a/drivers/net/phy/aquantia.c
+++ b/drivers/net/phy/aquantia.c
@@ -22,6 +22,11 @@
#define AQUANTIA_SYSTEM_INTERFACE_SR 0xe812
#define AQUANTIA_VENDOR_PROVISIONING_REG 0xC441
+#define AQUANTIA_FIRMWARE_ID0x20
+#define AQUANTIA_RESERVED_STATUS0xc885
+#define AQUANTIA_FIRMWARE_MAJOR_MASK0xff00
+#define AQUANTIA_FIRMWARE_MINOR_MASK0xff
+#define AQUANTIA_FIRMWARE_BUILD_MASK0xf0
#define AQUANTIA_USX_AUTONEG_CONTROL_ENA 0x0008
#define AQUANTIA_SI_IN_USE_MASK 0x0078
@@ -30,6 +35,7 @@
int aquantia_config(struct phy_device *phydev)
{
u32 val = phy_read(phydev, MDIO_MMD_PMAPMD, MII_BMCR);
+ u32 reg_val1 = 0;
if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
/* 1000BASE-T mode */
@@ -56,6 +62,11 @@ int aquantia_config(struct phy_device *phydev)
phy_write(phydev, MDIO_MMD_PHYXS,
AQUANTIA_VENDOR_PROVISIONING_REG,
AQUANTIA_USX_AUTONEG_CONTROL_ENA);
+ printf("%s: system interface USXGMII\n",
+ phydev->dev->name);
+ } else {
+ printf("%s: system interface XFI\n",
+ phydev->dev->name);
}
} else if (phydev->interface == PHY_INTERFACE_MODE_SGMII_2500) {
@@ -73,6 +84,16 @@ int aquantia_config(struct phy_device *phydev)
val = (val & ~AQUNTIA_SPEED_MSB_MASK) | AQUNTIA_SPEED_LSB_MASK;
phy_write(phydev, MDIO_MMD_PMAPMD, MII_BMCR, val);
}
+
+ val = phy_read(phydev, MDIO_MMD_VEND1, AQUANTIA_RESERVED_STATUS);
+ reg_val1 = phy_read(phydev, MDIO_MMD_VEND1, AQUANTIA_FIRMWARE_ID);
+
+ printf("%s: %s Firmware Version %x.%x.%x\n", phydev->dev->name,
+ phydev->drv->name,
+ (reg_val1 & AQUANTIA_FIRMWARE_MAJOR_MASK) >> 8,
+ reg_val1 & AQUANTIA_FIRMWARE_MINOR_MASK,
+ (val & AQUANTIA_FIRMWARE_BUILD_MASK) >> 4);
+
return 0;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] AQUANTIA USXGMII autoneg enable
If System interface protocol is USXGMII then enable USXGMII autoneg
Signed-off-by: Valentin Catalin Neacsu
---
drivers/net/phy/aquantia.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia.c
index 6678147545..57eede14ce 100644
--- a/drivers/net/phy/aquantia.c
+++ b/drivers/net/phy/aquantia.c
@@ -20,6 +20,13 @@
#define AQUNTIA_SPEED_LSB_MASK 0x2000
#define AQUNTIA_SPEED_MSB_MASK 0x40
+#define AQUANTIA_SYSTEM_INTERFACE_SR 0xe812
+#define AQUANTIA_VENDOR_PROVISIONING_REG 0xC441
+
+#define AQUANTIA_USX_AUTONEG_CONTROL_ENA 0x0008
+#define AQUANTIA_SI_IN_USE_MASK 0x0078
+#define AQUANTIA_SI_USXGMII 0x0018
+
int aquantia_config(struct phy_device *phydev)
{
u32 val = phy_read(phydev, MDIO_MMD_PMAPMD, MII_BMCR);
@@ -41,6 +48,16 @@ int aquantia_config(struct phy_device *phydev)
phy_write(phydev, MDIO_MMD_PMAPMD, MII_BMCR,
AQUNTIA_SPEED_LSB_MASK |
AQUNTIA_SPEED_MSB_MASK);
+
+ val = phy_read(phydev, MDIO_MMD_PHYXS,
+ AQUANTIA_SYSTEM_INTERFACE_SR);
+ /* If SI is USXGMII then start USXGMII autoneg*/
+ if ((val & AQUANTIA_SI_IN_USE_MASK) == AQUANTIA_SI_USXGMII) {
+ phy_write(phydev, MDIO_MMD_PHYXS,
+ AQUANTIA_VENDOR_PROVISIONING_REG,
+ AQUANTIA_USX_AUTONEG_CONTROL_ENA);
+ }
+
} else if (phydev->interface == PHY_INTERFACE_MODE_SGMII_2500) {
/* 2.5GBASE-T mode */
phydev->advertising = SUPPORTED_1000baseT_Full;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum
On Mon, Oct 29, 2018 at 08:13:37PM +, Joe Hershberger wrote: > On Mon, Oct 22, 2018 at 2:40 PM Simon Goldschmidt > wrote: > > > > On 22.10.2018 20:53, Joe Hershberger wrote: > > > Hi Christian, > > > > > > On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner > > > wrote: > > >> Hi Wolfgang > > >> > > >>> In message <20181001094646.11539-1-christian.gmei...@gmail.com> you > > >>> wrote: > > From: Thomas RIENOESSL > > > > Prep. work to support nfs v1. > > >>> Hm... as you are putting efforts into NFS support... > > >>> > > >>> Here comes a more general question: > > >>> > > >>> I wonder if it's worth the work on NFS at all, or if we should > > >>> remove NFS support from U-Boot alltogether? > > >>> > > >>> 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux > > >>> distros support only v4 in their default configurations. > > >>> > > >> Linux is not the only operating system used in the world. My NFSv1 > > >> server runs on a vxWorks 5 device which > > >> I need to support - sadly. > > >> > > >>> 2) We support only UDP, but most standard Linux distros support only > > >>> TCP in their default configurations (see [1]) > > >>> > > >>> [1] > > >>> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6 > > >>> > > >>> Try a NFS download from any recent Linux distro (i. e. one including > > >>> nfs-utils 2.3.1 or later)... > > >>> > > >> That is true. > > >> > > >>> I feel a half-way solution is unsatisfactory, but the way for the > > >>> Real Thing (TM) is a pretty long one... > > >>> > > >>> The fact that nobody compained yet that NFS stopped working fo him > > >>> suggests that there are only very, very few users of NFS at all. > > >>> If one of these is willing to step up and fix this for real, he is > > >>> of course more than welcome. But if not - should we not remove the > > >>> more or less obsolete code? > > >>> > > >> As u-boot is lacking TCP support this is quite a challenging task. I > > >> have seen some work in progress > > >> patches, which I have reviewed and hoped that it helps to get them > > >> further. > > > I'm trying to get those patches into a state that they are acceptable, > > > but currently they are pretty brittle. I've not actually seen them > > > work, though the contributor says they do in some case. I had to do > > > some work to have the series just not break UDP functionality, so we > > > have more work to do there. > > > > > >> I am also > > >> interested in using ftp directly in u-boot. At the moment we are using > > >> uip as tcp stack and hacked > > >> together a ftp client. > > > I was contemplating if using something like that or lwip would be > > > better than rolling our own, but my concern is both how configurable > > > those stacks are to make them lean as well as adding an external > > > dependency / forking their code into our repo. Not excited about > > > either. > > > > As the maintainer of lwIP, I already have thought about this more than > > once. My main concern however was the license (lwIP is BSD style) and > > Yes, the license is a concern. I'm not a lawyer, but maybe someone can > comment on what our options are here. Wolfgang? Tom? We have BSD-2 and BSD-3 clause code today in the tree, usually because we've had need to bring in existing code under such license. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: fix bootcounter by reserving SRAM
Commit 768f23dc8ae3 ("ARM: socfpga: Put stack at the end of SRAM")
broke those socfpga boards that keep the bootcounter at the
end of the internal SRAM as the bootcounter needs 8 bytes
by default and thus the very first SPL call to
board_init_f_alloc_reserve overwrites the bootcounter.
This patch allows to move the initial stack pointer down a
bit to allow boards to reserve some of the internal SRAM for
other features (like the bootcounter).
Signed-off-by: Simon Goldschmidt
---
include/configs/socfpga_common.h | 6 +-
include/configs/socfpga_is1.h| 9 +
include/configs/socfpga_sr1500.h | 3 ++-
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 2330143cf1..1e26630330 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -31,8 +31,12 @@
#define CONFIG_SYS_INIT_RAM_ADDR 0xFFE0
#define CONFIG_SYS_INIT_RAM_SIZE 0x4 /* 256KB */
#endif
+#ifndef SOCFPGA_INIT_RAM_END_RESERVE
+#define SOCFPGA_INIT_RAM_END_RESERVE 0
+#endif
#define CONFIG_SYS_INIT_SP_ADDR\
- (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)
+ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE - \
+SOCFPGA_INIT_RAM_END_RESERVE)
#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
diff --git a/include/configs/socfpga_is1.h b/include/configs/socfpga_is1.h
index c233c208a5..3c80c0f45c 100644
--- a/include/configs/socfpga_is1.h
+++ b/include/configs/socfpga_is1.h
@@ -23,12 +23,13 @@
/* PHY */
#endif
-/* The rest of the configuration is shared */
-#include
-
/*
- * Bootcounter
+ * Bootcounter (8 bytes at the end of internal SRAM)
*/
#define CONFIG_SYS_BOOTCOUNT_BE
+#define SOCFPGA_INIT_RAM_END_RESERVE 8
+
+/* The rest of the configuration is shared */
+#include
#endif /* __CONFIG_SOCFPGA_IS1_H__ */
diff --git a/include/configs/socfpga_sr1500.h b/include/configs/socfpga_sr1500.h
index 984f1183fd..b7b43fc6af 100644
--- a/include/configs/socfpga_sr1500.h
+++ b/include/configs/socfpga_sr1500.h
@@ -25,9 +25,10 @@
#define CONFIG_SPI_N25Q256A_RESET
/*
- * Bootcounter
+ * Bootcounter (8 bytes at the end of internal SRAM)
*/
#define CONFIG_SYS_BOOTCOUNT_BE
+#define SOCFPGA_INIT_RAM_END_RESERVE 8
/* Environment setting for SPI flash */
#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum
On Mon, Oct 22, 2018 at 2:40 PM Simon Goldschmidt wrote: > > On 22.10.2018 20:53, Joe Hershberger wrote: > > Hi Christian, > > > > On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner > > wrote: > >> Hi Wolfgang > >> > >>> In message <20181001094646.11539-1-christian.gmei...@gmail.com> you wrote: > From: Thomas RIENOESSL > > Prep. work to support nfs v1. > >>> Hm... as you are putting efforts into NFS support... > >>> > >>> Here comes a more general question: > >>> > >>> I wonder if it's worth the work on NFS at all, or if we should > >>> remove NFS support from U-Boot alltogether? > >>> > >>> 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux > >>> distros support only v4 in their default configurations. > >>> > >> Linux is not the only operating system used in the world. My NFSv1 > >> server runs on a vxWorks 5 device which > >> I need to support - sadly. > >> > >>> 2) We support only UDP, but most standard Linux distros support only > >>> TCP in their default configurations (see [1]) > >>> > >>> [1] > >>> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6 > >>> > >>> Try a NFS download from any recent Linux distro (i. e. one including > >>> nfs-utils 2.3.1 or later)... > >>> > >> That is true. > >> > >>> I feel a half-way solution is unsatisfactory, but the way for the > >>> Real Thing (TM) is a pretty long one... > >>> > >>> The fact that nobody compained yet that NFS stopped working fo him > >>> suggests that there are only very, very few users of NFS at all. > >>> If one of these is willing to step up and fix this for real, he is > >>> of course more than welcome. But if not - should we not remove the > >>> more or less obsolete code? > >>> > >> As u-boot is lacking TCP support this is quite a challenging task. I > >> have seen some work in progress > >> patches, which I have reviewed and hoped that it helps to get them > >> further. > > I'm trying to get those patches into a state that they are acceptable, > > but currently they are pretty brittle. I've not actually seen them > > work, though the contributor says they do in some case. I had to do > > some work to have the series just not break UDP functionality, so we > > have more work to do there. > > > >> I am also > >> interested in using ftp directly in u-boot. At the moment we are using > >> uip as tcp stack and hacked > >> together a ftp client. > > I was contemplating if using something like that or lwip would be > > better than rolling our own, but my concern is both how configurable > > those stacks are to make them lean as well as adding an external > > dependency / forking their code into our repo. Not excited about > > either. > > As the maintainer of lwIP, I already have thought about this more than > once. My main concern however was the license (lwIP is BSD style) and Yes, the license is a concern. I'm not a lawyer, but maybe someone can comment on what our options are here. Wolfgang? Tom? > the fact that it expects to always run (I don't know the U-Boot network > stack that well, but it only runs when called, doesn't it?). Yes, it currently works that way... it is pretty aggressive about going away. That is something that I've wanted to rework for a while, but haven't gotten to it. It certainly has no threads so nothing persists. Only if you are calling into a command that uses the network stack do you have the ability to do networking. > > Forking is never a good idea with open source projects. We try to > integrate as much back into the mainline code as possible. Although we > of course depend on the people using the stack to contribute things back. Yes, though due to the low-level nature of U-Boot, it seems that forking while changing as little as reasonable is the approach we've taken in all cases I've seen in the past. Much like the bits of Linux that are included, the forks strongly encourage changes to first be sent to the main project, so as to support the mainline project and to make upgrades from the mainline project much easier. > > Of course I don't want to push anyone (and I don't want to load myself > with more work), but I could offer some help in getting it to run if > anyone had a real interest. Configuration shouldn't be too much of an issue. That's good to hear. > > Given the systems U-Boot runs on, lwIP would definitively be a better > choice than uIP if you have performance improvements of tcp in mind. That was my instinct... glad to hear from you. > > [BTW: a http client (a.k.a. 'wget') is already included in lwIP and with > help of a 3rd party TLS library, it even provides HTTPS support] Excellent. > > > Simon > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2018.11-rc3 released
Hey all, It's two weeks until v2018.11 release and today I've put out rc3. The delta is pretty reasonable and at this point I can really hold things to either obviously correct fixes or bugfixes/regression fixes/Kconfig migrations that can be proven out. Thanks all! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request v2: u-boot-sunix/master
On Mon, Oct 29, 2018 at 08:50:24PM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR. > > Changes for v2: > - Fix "sunxi: disable Pine A64 model detection code on other boards" > changes. > > thanks, > Jagan. > > The following changes since commit 1ed3c0954bd160dafcad8847a51c3ddd5f992f51: > > Merge branch 'master' of git://git.denx.de/u-boot-samsung (2018-10-23 > 21:13:32 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sunxi.git master > > for you to fetch changes up to 5776610e9ef022e2d8a15793d4b9955c3f8076ed: > > sunxi: store DRAM size in SPL header (2018-10-29 20:41:15 +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] [PATCH 7/7] driver: net: ti: keystone_net: switch to use common mdio lib
On Thu, Oct 25, 2018 at 10:41 PM Grygorii Strashko wrote: > > Update TI Keystone 2 driver to re-use common mdio lib. > > Signed-off-by: Grygorii Strashko Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] driver: net: ti: cpsw: switch to use common mdio lib
On Thu, Oct 25, 2018 at 10:38 PM Grygorii Strashko wrote: > > Update TI CPSW driver to re-use common mdio lib > > Signed-off-by: Grygorii Strashko Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] driver: net: ti: introduce common mdio support library
On Thu, Oct 25, 2018 at 10:39 PM Grygorii Strashko
wrote:
>
> All existing TI SoCs network HW have similar MDIO implementation, so
> introduce common mdio support library which can be reused by TI networking
> drivers.
>
> Signed-off-by: Grygorii Strashko
> ---
> drivers/net/ti/Makefile| 2 +-
> drivers/net/ti/cpsw_mdio.c | 205
> +
> drivers/net/ti/cpsw_mdio.h | 18
> 3 files changed, 224 insertions(+), 1 deletion(-)
> create mode 100644 drivers/net/ti/cpsw_mdio.c
> create mode 100644 drivers/net/ti/cpsw_mdio.h
>
> diff --git a/drivers/net/ti/Makefile b/drivers/net/ti/Makefile
> index 4ab4a27..d2b6f20 100644
> --- a/drivers/net/ti/Makefile
> +++ b/drivers/net/ti/Makefile
> @@ -2,6 +2,6 @@
> #
> # Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
>
> -obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o
> +obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o cpsw_mdio.o
> obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
> obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o
> diff --git a/drivers/net/ti/cpsw_mdio.c b/drivers/net/ti/cpsw_mdio.c
> new file mode 100644
> index 000..ed9dd27
> --- /dev/null
> +++ b/drivers/net/ti/cpsw_mdio.c
> @@ -0,0 +1,205 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * CPSW MDIO generic driver for TI AMxx/K2x/EMAC devices.
> + *
> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
> + */
> +
> +#include
> +#include
> +#include
> +
> +struct cpsw_mdio_regs {
> + u32 version;
> + u32 control;
> +#define CONTROL_IDLE BIT(31)
> +#define CONTROL_ENABLE BIT(30)
> +#define CONTROL_FAULT BIT(19)
> +#define CONTROL_FAULT_ENABLE BIT(18)
> +#define CONTROL_DIV_MASK GENMASK(15, 0)
> +
> + u32 alive;
> + u32 link;
> + u32 linkintraw;
> + u32 linkintmasked;
> + u32 __reserved_0[2];
> + u32 userintraw;
> + u32 userintmasked;
> + u32 userintmaskset;
> + u32 userintmaskclr;
> + u32 __reserved_1[20];
> +
> + struct {
> + u32 access;
> + u32 physel;
> +#define USERACCESS_GO BIT(31)
> +#define USERACCESS_WRITE BIT(30)
> +#define USERACCESS_ACK BIT(29)
> +#define USERACCESS_READ(0)
> +#define USERACCESS_PHY_REG_SHIFT (21)
> +#define USERACCESS_PHY_ADDR_SHIFT (16)
> +#define USERACCESS_DATAGENMASK(15, 0)
> + } user[0];
> +};
> +
> +#define CPSW_MDIO_DIV_DEF 0xff
> +#define PHY_REG_MASK 0x1f
> +#define PHY_ID_MASK0x1f
> +
> +/*
> + * This timeout definition is a worst-case ultra defensive measure against
> + * unexpected controller lock ups. Ideally, we should never ever hit this
> + * scenario in practice.
> + */
> +#define CPSW_MDIO_TIMEOUT100 /* msecs */
> +
> +struct cpsw_mdio {
> + struct cpsw_mdio_regs *regs;
> + struct mii_dev *bus;
> + int div;
> +};
> +
> +/* wait until hardware is ready for another user access */
> +static inline u32 cpsw_mdio_wait_for_user_access(struct cpsw_mdio *mdio)
> +{
> + u32 reg = 0;
> + int timeout = CPSW_MDIO_TIMEOUT;
> +
> + while (timeout-- && ((reg = readl(>regs->user[0].access))
> + & USERACCESS_GO))
> + udelay(10);
Seems we should be using wait_for_bit instead of this function.
> +
> + if (timeout == -1) {
> + printf("wait_for_user_access Timeout\n");
> + return -ETIMEDOUT;
> + }
> +
> + return reg;
> +}
> +
> +static int cpsw_mdio_read(struct mii_dev *bus, int phy_id,
> + int dev_addr, int phy_reg)
> +{
> + struct cpsw_mdio *mdio = bus->priv;
> + int data;
> + u32 reg;
> +
> + if (phy_reg & ~PHY_REG_MASK || phy_id & ~PHY_ID_MASK)
> + return -EINVAL;
> +
> + cpsw_mdio_wait_for_user_access(mdio);
> + reg = (USERACCESS_GO | USERACCESS_READ |
> + (phy_reg << USERACCESS_PHY_REG_SHIFT) |
> + (phy_id << USERACCESS_PHY_ADDR_SHIFT));
> + writel(reg, >regs->user[0].access);
> + reg = cpsw_mdio_wait_for_user_access(mdio);
> +
> + data = (reg & USERACCESS_ACK) ? (reg & USERACCESS_DATA) : -1;
> + return data;
> +}
> +
> +static int cpsw_mdio_write(struct mii_dev *bus, int phy_id, int dev_addr,
> + int phy_reg, u16 data)
> +{
> + struct cpsw_mdio *mdio = bus->priv;
> + u32 reg;
> +
> + if (phy_reg & ~PHY_REG_MASK || phy_id & ~PHY_ID_MASK)
> + return -EINVAL;
> +
> + cpsw_mdio_wait_for_user_access(mdio);
> + reg = (USERACCESS_GO | USERACCESS_WRITE |
> + (phy_reg << USERACCESS_PHY_REG_SHIFT) |
> + (phy_id << USERACCESS_PHY_ADDR_SHIFT) |
> + (data & USERACCESS_DATA));
> + writel(reg,
Re: [U-Boot] [PATCH 5/7] driver: net: ti: introduce common mdio support library
On Mon, Oct 29, 2018 at 8:04 AM Hannes Schmelzer wrote: > > > On 10/26/18 5:38 AM, Grygorii Strashko wrote: > > All existing TI SoCs network HW have similar MDIO implementation, so > > introduce common mdio support library which can be reused by TI networking > > drivers. > > > > Signed-off-by: Grygorii Strashko > > --- > > drivers/net/ti/Makefile| 2 +- > > drivers/net/ti/cpsw_mdio.c | 205 > > + > > drivers/net/ti/cpsw_mdio.h | 18 > > 3 files changed, 224 insertions(+), 1 deletion(-) > > create mode 100644 drivers/net/ti/cpsw_mdio.c > > create mode 100644 drivers/net/ti/cpsw_mdio.h > > > Hi, > why we don't combine this with: > http://patchwork.ozlabs.org/patch/939726/ ? looks much more elegant to me. I agree we should be moving that direction, but consolidating TI MDIO implementation is fairly orthogonal. Also haven't heard back from Ken on feedback to that patch. > cheers, > Hannes > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] driver: net: ti: cpsw: update to use SPDX identifier
On Thu, Oct 25, 2018 at 10:43 PM Grygorii Strashko wrote: > > Update to use SPDX license identifier. > > Signed-off-by: Grygorii Strashko Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] drivers: net: keystone_net: drop non dm code
On Thu, Oct 25, 2018 at 10:42 PM Grygorii Strashko wrote: > > Networking support for all TI K2 boards converted to use DM model and > CONFIG_DM_ETH enabled in all corresponding defconfig files, hence drop > unused non DM K2 networking code. > > Signed-off-by: Grygorii Strashko Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] configs: net: convert DRIVER_TI_KEYSTONE_NET kconfig
On Thu, Oct 25, 2018 at 10:41 PM Grygorii Strashko wrote: > > Convert DRIVER_TI_KEYSTONE_NET to Kconfig. > > Signed-off-by: Grygorii Strashko Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] driver: net: consolidate ti's code in separate folder
On Thu, Oct 25, 2018 at 10:40 PM Grygorii Strashko wrote: > > Add drivers/net/ti/ folder and move all TI's code in this folder for better > maintenance. > > Signed-off-by: Grygorii Strashko Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/13] net: ftgmac100: handle timeouts when transmitting
On Mon, Oct 29, 2018 at 1:04 AM Cédric Le Goater wrote:
>
> Hello Joe,
>
> On 10/22/18 9:55 PM, Joe Hershberger wrote:
> > Hi Cedric,
> >
> > On Tue, Oct 16, 2018 at 4:32 AM Cédric Le Goater wrote:
> >>
> >> Signed-off-by: Cédric Le Goater
> >> Reviewed-by: Joel Stanley
> >> ---
> >>
> >> Changes since v3 :
> >>
> >> - introduced a ftgmac100_wait_for_txdone() function similar to the
> >>wait_for_bit_*() macros.
> >>
> >> drivers/net/ftgmac100.c | 44 +
> >> 1 file changed, 44 insertions(+)
> >>
> >> diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
> >> index bf8600814690..9adfe109ebc2 100644
> >> --- a/drivers/net/ftgmac100.c
> >> +++ b/drivers/net/ftgmac100.c
> >> @@ -14,6 +14,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >>
> >> @@ -28,6 +29,9 @@
> >> /* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
> >> #define PKTBUFSTX 4 /* must be power of 2 */
> >>
> >> +/* Timeout for transmit */
> >> +#define FTGMAC100_TX_TIMEOUT_MS1000
> >> +
> >> /* Timeout for a mdio read/write operation */
> >> #define FTGMAC100_MDIO_TIMEOUT_USEC1
> >>
> >> @@ -401,6 +405,41 @@ static int ftgmac100_recv(struct udevice *dev, int
> >> flags, uchar **packetp)
> >> return rxlen;
> >> }
> >>
> >> +/*
> >> + * The wait_for_bit_*() macros require a register value. This define a
> >> + * similar routine which loops on the in-memory transmit descriptor to
> >> + * wait for the MAC to clear the DMA_OWN bit.
> >> + */
> >> +static int ftgmac100_wait_for_txdone(struct ftgmac100_txdes *txdes,
> >> +const unsigned int timeout_ms,
> >> +const bool breakable)
> >> +{
> >
> > I was hoping to see something like this instead:
> >
> > static u32 ftgmac100_read_txdesc(void *desc)
> > {
> > struct ftgmac100_txdes *txdes = desc;
> > ulong des_start = (ulong)txdes;
> > ulong des_end = des_start + roundup(sizeof(*txdes),
> > ARCH_DMA_MINALIGN);
> >
> > invalidate_dcache_range(des_start, des_end);
> >
> > return txdes->txdes0;
> > }
> >
> > BUILD_WAIT_FOR_BIT(ftgmac100_txdone, u32, ftgmac100_read_txdesc)
> >
> > [ ... ]
> >
> > ftgmac100_send( ... )
> > {
> > [ ... ]
> >
> > rc = wait_for_bit_ftgmac100_txdone(curr_des,
> > FTGMAC100_TXDES0_TXDMA_OWN, false, FTGMAC100_TX_TIMEOUT_MS, true);
> > if (rc)
> > return rc;
> >
> > [ ... ]
> > }
>
>
> Yes, this is much better. A few other drivers could make use of a similar
> macro.
I agree... spread the word to people with hardware who can make the
change and test. :)
> Sending a v5 with the proposed change.
Looks great, thanks!
>
> Thanks,
>
> C.
>
>
> >> + ulong des_start = (ulong)txdes;
> >> + ulong des_end = des_start + roundup(sizeof(*txdes),
> >> ARCH_DMA_MINALIGN);
> >> + ulong start = get_timer(0);
> >> +
> >> + while (1) {
> >> + invalidate_dcache_range(des_start, des_end);
> >> +
> >> + if (!(txdes->txdes0 & FTGMAC100_TXDES0_TXDMA_OWN))
> >> + return 0;
> >> +
> >> + if (get_timer(start) > timeout_ms)
> >> + break;
> >> +
> >> + if (breakable && ctrlc()) {
> >> + puts("Abort\n");
> >> + return -EINTR;
> >> + }
> >> +
> >> + udelay(1);
> >> + WATCHDOG_RESET();
> >> + }
> >> +
> >> + dev_err(dev, "transmit timeout\n");
> >> + return -ETIMEDOUT;
> >> +}
> >> +
> >> /*
> >> * Send a data block via Ethernet
> >> */
> >> @@ -414,6 +453,7 @@ static int ftgmac100_send(struct udevice *dev, void
> >> *packet, int length)
> >> roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN);
> >> ulong data_start;
> >> ulong data_end;
> >> + int rc;
> >>
> >> invalidate_dcache_range(des_start, des_end);
> >>
> >> @@ -446,6 +486,10 @@ static int ftgmac100_send(struct udevice *dev, void
> >> *packet, int length)
> >> /* Start transmit */
> >> writel(1, >txpd);
> >>
> >> + rc = ftgmac100_wait_for_txdone(curr_des, FTGMAC100_TX_TIMEOUT_MS,
> >> true);
> >> + if (rc)
> >> + return rc;
> >> +
> >> debug("%s(): packet sent\n", __func__);
> >>
> >> /* Move to next descriptor */
> >> --
> >> 2.17.2
> >>
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/3] gpio: dwapb_gpio: fix binding without bank-name property
As a preparation for merging the socfpga gen5 devicetree files
from Linux, this patch makes the dwapb gpio driver work correctly
without the 'bank-name' property on the gpio-controller nodes.
This property is not present in the Linux drivers and thus is not
present in the Linux devicetrees. It is only used to access pins
via bank name.
This fallback is necessary since without it, the driver will
return an error code which will lead to an error in U-Boot
startup.
The bank names will still be added to the default board device
trees in follow-up patch, but other boards using this driver and
not including the bank name should also work with the socfpga.dtsi
without adding the bank-name property.
Signed-off-by: Simon Goldschmidt
---
drivers/gpio/dwapb_gpio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index 68836a7902..e55fb4ac73 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -180,6 +180,13 @@ static int gpio_dwapb_bind(struct udevice *dev)
plat->pins = fdtdec_get_int(blob, node, "snps,nr-gpios", 0);
plat->name = fdt_stringlist_get(blob, node, "bank-name", 0,
NULL);
+ if (!plat->name) {
+ /*
+* Fall back to node name. This means accessing pins
+* via bank name won't work.
+*/
+ plat->name = fdt_get_name(blob, node, NULL);
+ }
ret = device_bind(dev, dev->driver, plat->name,
plat, -1, );
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/3] dts: arm: socfpga: merge gen5 devicetrees from linux
Add -u-boot.dtsi files to keep the current U-Boot behaviour:
- add u-boot,dm-pre-reloc where required
- disable watchdog
- set uart clock frequency
- add gpio bank-name properties
where appropriate:
- make qspi work (add alias for spi0, fix compatible for flash)
- enable usb (status okay, add alias for udc0)
Adapt board dts files that are not in Linux to keep their old
behaviour.
Change licenses to SPDX.
(Patman warnings/errors are in 1:1 copied files from Linux)
Signed-off-by: Simon Goldschmidt
---
arch/arm/dts/socfpga.dtsi | 404 --
arch/arm/dts/socfpga_arria5.dtsi | 11 +-
arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi | 56 +++
arch/arm/dts/socfpga_arria5_socdk.dts | 97 +++--
arch/arm/dts/socfpga_cyclone5.dtsi| 9 +-
arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts| 17 +-
.../socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 46 ++
.../arm/dts/socfpga_cyclone5_de0_nano_soc.dts | 69 +--
arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 16 +
arch/arm/dts/socfpga_cyclone5_de1_soc.dts | 16 +
arch/arm/dts/socfpga_cyclone5_is1.dts | 8 +
.../dts/socfpga_cyclone5_socdk-u-boot.dtsi| 72
arch/arm/dts/socfpga_cyclone5_socdk.dts | 88 +++-
.../dts/socfpga_cyclone5_sockit-u-boot.dtsi | 56 +++
arch/arm/dts/socfpga_cyclone5_sockit.dts | 149 +--
.../dts/socfpga_cyclone5_socrates-u-boot.dtsi | 60 +++
arch/arm/dts/socfpga_cyclone5_socrates.dts| 85 ++--
arch/arm/dts/socfpga_cyclone5_sr1500.dts | 12 +
.../socfpga_cyclone5_vining_fpga-u-boot.dtsi | 60 +++
arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 222 --
20 files changed, 1223 insertions(+), 330 deletions(-)
create mode 100644 arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
create mode 100644 arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi
create mode 100644 arch/arm/dts/socfpga_cyclone5_socdk-u-boot.dtsi
create mode 100644 arch/arm/dts/socfpga_cyclone5_sockit-u-boot.dtsi
create mode 100644 arch/arm/dts/socfpga_cyclone5_socrates-u-boot.dtsi
create mode 100644 arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi
diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index 314449478d..2458d6707d 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright (C) 2012 Altera
+ * Copyright (C) 2012 Altera
*/
-#include "skeleton.dtsi"
#include
/ {
@@ -11,34 +10,26 @@
#size-cells = <1>;
aliases {
- ethernet0 =
- ethernet1 =
- i2c0 =
- i2c1 =
- i2c2 =
- i2c3 =
serial0 =
serial1 =
timer0 =
timer1 =
timer2 =
timer3 =
- spi0 =
- spi1 =
- spi2 =
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "altr,socfpga-smp";
- cpu@0 {
+ cpu0: cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
next-level-cache = <>;
};
- cpu@1 {
+ cpu1: cpu@1 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <1>;
@@ -46,6 +37,15 @@
};
};
+ pmu: pmu@ff111000 {
+ compatible = "arm,cortex-a9-pmu";
+ interrupt-parent = <>;
+ interrupts = <0 176 4>, <0 177 4>;
+ interrupt-affinity = <>, <>;
+ reg = <0xff111000 0x1000>,
+ <0xff113000 0x1000>;
+ };
+
intc: intc@fffed000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
@@ -63,7 +63,7 @@
ranges;
amba {
- compatible = "arm,amba-bus";
+ compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
@@ -87,6 +87,14 @@
};
};
+ base_fpga_region {
+ compatible = "fpga-region";
+ fpga-mgr = <>;
+
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ };
+
can0: can@ffc0 {
compatible = "bosch,d_can";
reg = <0xffc0 0x1000>;
@@ -131,7 +139,7 @@
compatible = "fixed-clock";
};
- main_pll: main_pll {
+
[U-Boot] [PATCH v1 2/3] spi: cadence_qspi: use "cdns, qspi-nor" as compatible
Linux uses "cdns,qspi-nor" as compatible string for the cadence
qspi driver. To support Linux device trees, add this compatible
to the U-Boot driver while keeping the old "cadence,qspi" for
backwards compatibility for U-Boot device trees until all are
fixed.
Also update the binding docs accordingly.
Signed-off-by: Simon Goldschmidt
---
doc/device-tree-bindings/spi/spi-cadence.txt | 3 ++-
drivers/spi/cadence_qspi.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/doc/device-tree-bindings/spi/spi-cadence.txt
b/doc/device-tree-bindings/spi/spi-cadence.txt
index 74c82080fc..d7b30d5cff 100644
--- a/doc/device-tree-bindings/spi/spi-cadence.txt
+++ b/doc/device-tree-bindings/spi/spi-cadence.txt
@@ -2,7 +2,8 @@ Cadence QSPI controller device tree bindings
Required properties:
-- compatible : should be "cadence,qspi".
+- compatible : should be "cdns,qspi-nor" ("cadence,qspi" is supported
+ for compatibility to older U-Boot devicetrees only)
- reg : 1.Physical base address and size of SPI registers map.
2. Physical base address & size of NOR Flash.
- clocks : Clock phandles (see clock bindings for details).
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 29db6fa368..fef740beaa 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -329,7 +329,8 @@ static const struct dm_spi_ops cadence_spi_ops = {
};
static const struct udevice_id cadence_spi_ids[] = {
- { .compatible = "cadence,qspi" },
+ { .compatible = "cdns,qspi-nor" },
+ { .compatible = "cadence,qspi" }, /* U-Boot specific */
{ }
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/3] dts: arm: socfpga: merge gen5 devicetrees from linux
This series merges socfpga gen5 dts and dtsi files from linux while keeping U-Boot behaviour. Changes in those files that need fixing (mostly in -u-boot.dtsi board files) are: - watchdog is now enabled - ethernet, spi and i2c aliases removed from socfpga.dtsi - gpio bank names not available - mmc disabled - qspi compatible string different - 'clock-frequency' removed from uarts These changes are mostly handled in changed dts files or U-Boot specific dtsi files except for: - added compatible "cdns,qspi-nor" to cadence_qspi.c - allow binding dwapb_gpio driver without "bank-name" property (gpios still work, only access via bank name fails) Simon Goldschmidt (3): gpio: dwapb_gpio: fix binding without bank-name property spi: cadence_qspi: use "cdns,qspi-nor" as compatible dts: arm: socfpga: merge gen5 devicetrees from linux arch/arm/dts/socfpga.dtsi | 404 -- arch/arm/dts/socfpga_arria5.dtsi | 11 +- arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi | 56 +++ arch/arm/dts/socfpga_arria5_socdk.dts | 97 +++-- arch/arm/dts/socfpga_cyclone5.dtsi| 9 +- arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts| 17 +- .../socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 46 ++ .../arm/dts/socfpga_cyclone5_de0_nano_soc.dts | 69 +-- arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 16 + arch/arm/dts/socfpga_cyclone5_de1_soc.dts | 16 + arch/arm/dts/socfpga_cyclone5_is1.dts | 8 + .../dts/socfpga_cyclone5_socdk-u-boot.dtsi| 72 arch/arm/dts/socfpga_cyclone5_socdk.dts | 88 +++- .../dts/socfpga_cyclone5_sockit-u-boot.dtsi | 56 +++ arch/arm/dts/socfpga_cyclone5_sockit.dts | 149 +-- .../dts/socfpga_cyclone5_socrates-u-boot.dtsi | 60 +++ arch/arm/dts/socfpga_cyclone5_socrates.dts| 85 ++-- arch/arm/dts/socfpga_cyclone5_sr1500.dts | 12 + .../socfpga_cyclone5_vining_fpga-u-boot.dtsi | 60 +++ arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 222 -- doc/device-tree-bindings/spi/spi-cadence.txt | 3 +- drivers/gpio/dwapb_gpio.c | 7 + drivers/spi/cadence_qspi.c| 3 +- 23 files changed, 1234 insertions(+), 332 deletions(-) create mode 100644 arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_cyclone5_socdk-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_cyclone5_sockit-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_cyclone5_socrates-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 07/13] net: ftgmac100: handle timeouts when transmitting
On Mon, Oct 29, 2018 at 1:17 AM Cédric Le Goater wrote: > > Signed-off-by: Cédric Le Goater Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] configs: mx23_olinuxino_defconfig: fix status led definition
While migrating individual status led usages to Kconfig stuff,
a (random) value was introduced for this board which does not
work but produces the following error message during boot:
__led_init: failed requesting GPIO59!
Since Kconfig does not seem to accept a define as this point,
but the mxs gpio driver requires not only a simple integer value,
we need to use the plain value of MX23_PAD_SSP1_DETECT__GPIO_2_1.
Signed-off-by: Michael Heimpold
Fixes: 2d8d190c8394 ("status_led: Kconfig migration")
---
configs/mx23_olinuxino_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/mx23_olinuxino_defconfig b/configs/mx23_olinuxino_defconfig
index 6597dc3870..598547a5f5 100644
--- a/configs/mx23_olinuxino_defconfig
+++ b/configs/mx23_olinuxino_defconfig
@@ -26,7 +26,7 @@ CONFIG_ENV_IS_IN_MMC=y
CONFIG_LED_STATUS=y
CONFIG_LED_STATUS_GPIO=y
CONFIG_LED_STATUS0=y
-CONFIG_LED_STATUS_BIT=59
+CONFIG_LED_STATUS_BIT=778
CONFIG_LED_STATUS_STATE=2
CONFIG_LED_STATUS_BOOT_ENABLE=y
CONFIG_LED_STATUS_BOOT=0
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] configs: mx23_olinuxino_defconfig: disable bootefi command
CONFIG_CMD_BOOTEFI is enabled by Kconfig default, but rarely used on this board/platform. So let's disable it for the boards default config. This also saves around 16 KiB in the final u-boot.sb. Signed-off-by: Michael Heimpold --- configs/mx23_olinuxino_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/mx23_olinuxino_defconfig b/configs/mx23_olinuxino_defconfig index 598547a5f5..1bf76e2e11 100644 --- a/configs/mx23_olinuxino_defconfig +++ b/configs/mx23_olinuxino_defconfig @@ -14,6 +14,7 @@ CONFIG_VERSION_VARIABLE=y CONFIG_ARCH_MISC_INIT=y # CONFIG_SPL_FRAMEWORK is not set CONFIG_HUSH_PARSER=y +# CONFIG_CMD_BOOTEFI is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] configs: drop CMD_CACHE from mx23_olinuxino_defconfig
This prevents the warning message "No arch specific invalidate_icache_all available!" during boot. Signed-off-by: Michael Heimpold --- configs/mx23_olinuxino_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/mx23_olinuxino_defconfig b/configs/mx23_olinuxino_defconfig index 2eee19dab5..6597dc3870 100644 --- a/configs/mx23_olinuxino_defconfig +++ b/configs/mx23_olinuxino_defconfig @@ -20,7 +20,6 @@ CONFIG_CMD_MMC=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y -CONFIG_CMD_CACHE=y CONFIG_CMD_EXT2=y CONFIG_CMD_FAT=y CONFIG_ENV_IS_IN_MMC=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] Small fixes for Olimex MX23 based Olinuxino boards
Testing of v2018.11-rc2 on this board uncovered three small "issues" I would like to see fixed. See individual patch descriptions for details. Michael Heimpold (3): configs: drop CMD_CACHE from mx23_olinuxino_defconfig configs: mx23_olinuxino_defconfig: fix status led definition configs: mx23_olinuxino_defconfig: disable bootefi command configs/mx23_olinuxino_defconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6] net: Add MT7628 ethernet driver
On Fri, Oct 26, 2018 at 7:53 AM Stefan Roese wrote: > > This patch adds ethernet support for the MIPS based Mediatek MT76xx SoCs > (e.g. MT7628 and MT7688), including a minimum setup of the integrated > switch. This driver is loosly based on the driver version included in > this MediaTek github repository: > > https://github.com/MediaTek-Labs/linkit-smart-uboot.git > > Tested on the MT7688 LinkIt smart-gateway and on the > Gardena-smart-gateway. > > Signed-off-by: Stefan Roese > Reviewed-by: Daniel Schwierzeck > Cc: Joe Hershberger > Cc: Frank Wunderlich > Cc: Weijie Gao Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net: e1000: support 'write_hwaddr' in DM
On Thu, Oct 25, 2018 at 2:34 PM Hannes Schmelzer wrote: > > > On 10/25/2018 08:41 PM, Joe Hershberger wrote: > > On Thu, Oct 25, 2018 at 9:26 AM Hannes Schmelzer > > wrote: > Hi Joe, > > > >> +* reading the current address failed > >> +*/ > >> + if (!ret_val && memcmp(current_mac, mac, 6) == 0) > >> + return 0; > >> + > >> + for (i = 0; i < 3; ++i) > >> + data[i] = mac[i * 2 + 1] << 8 | mac[i * 2]; > >> + > >> + ret_val = e1000_write_eeprom_srwr(hw, 0x0, 3, data); > > This is a pretty uncommon implementation of this driver operation. > > Does the i120 in this case read the MAC directly from the EEPROM? > > > > Usually this function is used to write the hwaddr into the registers > > of the MAC. The .read_rom_hwaddr is used to fetch the hwaddr from the > > EEPROM and that address is used in the case that the U-Boot env has > > not set one. > This implementation is not new, just moved a bit upward in the file to > avoid forward declaration for non-DM build. Yes, I understand... I just brought it up since I was looking at it and maybe you had some insight. > I will double check it, but i guess there will be no change until we've > no fail behavior of the existing code. What do you mean here? > > I didn't imagine that this little change would become so big ;-) :) Sorry, wasn't meaning for it to be big... my comment about the current implementation is not meant to block this change. > I will provide some v3 within next days with the cosmetic cleanup and > other requested changes. Thanks! > > cheers, > Hannes > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/13] gpio: Remove DM_FLAG_PRE_RELOC flag in various drivers
> From: U-Boot On Behalf Of Bin Meng
> Sent: mercredi 24 octobre 2018 15:37
> Subject: [U-Boot] [PATCH 03/13] gpio: Remove DM_FLAG_PRE_RELOC flag in
> various drivers
>
> When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before
> relocation. However due to a bug in the DM core, the flag only takes effect
> when devices are statically declared via U_BOOT_DEVICE(). This bug has been
> fixed recently by commit
> "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
> lists_bind_fdt()", but with the fix, it has a side effect that all existing
> drivers that
> declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This
> may expose potential boot failure on some boards due to insufficient memory
> during the pre-relocation stage.
>
> To mitigate this potential impact, the following changes are
> implemented:
>
> - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
> only supports configuration from device tree (OF_CONTROL)
> - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
> is statically declared via U_BOOT_DEVICE()
> - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
> drivers that support both statically declared devices and
> configuration from device tree
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/gpio/omap_gpio.c | 2 ++
> drivers/gpio/stm32f7_gpio.c | 2 +-
> drivers/gpio/tegra186_gpio.c | 1 -
> drivers/gpio/tegra_gpio.c| 1 -
> 4 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c index
> 555eba2..0031415 100644
> --- a/drivers/gpio/omap_gpio.c
> +++ b/drivers/gpio/omap_gpio.c
> @@ -372,7 +372,9 @@ U_BOOT_DRIVER(gpio_omap) = {
> .ops= _omap_ops,
> .probe = omap_gpio_probe,
> .priv_auto_alloc_size = sizeof(struct gpio_bank),
> +#if !CONFIG_IS_ENABLED(OF_CONTROL)
> .flags = DM_FLAG_PRE_RELOC,
> +#endif
> };
>
> #endif /* CONFIG_DM_GPIO */
> diff --git a/drivers/gpio/stm32f7_gpio.c b/drivers/gpio/stm32f7_gpio.c index
> 4c0786f..b903dc4 100644
> --- a/drivers/gpio/stm32f7_gpio.c
> +++ b/drivers/gpio/stm32f7_gpio.c
> @@ -123,6 +123,6 @@ U_BOOT_DRIVER(gpio_stm32) = {
> .of_match = stm32_gpio_ids,
> .probe = gpio_stm32_probe,
> .ops= _stm32_ops,
> - .flags = DM_FLAG_PRE_RELOC | DM_UC_FLAG_SEQ_ALIAS,
> + .flags = DM_UC_FLAG_SEQ_ALIAS,
> .priv_auto_alloc_size = sizeof(struct stm32_gpio_priv),
> };
> diff --git a/drivers/gpio/tegra186_gpio.c b/drivers/gpio/tegra186_gpio.c index
> 1f0e8d5..6626b54 100644
> --- a/drivers/gpio/tegra186_gpio.c
> +++ b/drivers/gpio/tegra186_gpio.c
> @@ -281,5 +281,4 @@ U_BOOT_DRIVER(tegra186_gpio) = {
> .bind = tegra186_gpio_bind,
> .probe = tegra186_gpio_probe,
> .ops = _gpio_ops,
> - .flags = DM_FLAG_PRE_RELOC,
> };
> diff --git a/drivers/gpio/tegra_gpio.c b/drivers/gpio/tegra_gpio.c index
> 302efdd..a730f5c 100644
> --- a/drivers/gpio/tegra_gpio.c
> +++ b/drivers/gpio/tegra_gpio.c
> @@ -378,5 +378,4 @@ U_BOOT_DRIVER(gpio_tegra) = {
> .probe = gpio_tegra_probe,
> .priv_auto_alloc_size = sizeof(struct tegra_port_info),
> .ops= _tegra_ops,
> - .flags = DM_FLAG_PRE_RELOC,
> };
> --
> 2.7.4
>
Reviewed-by: Patrick Delaunay
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] arm: stm32mp: Remove DM_FLAG_PRE_RELOC flag
> From: U-Boot On Behalf Of Bin Meng
> Sent: mercredi 24 octobre 2018 15:36
>
> When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before
> relocation. However due to a bug in the DM core, the flag only takes effect
> when devices are statically declared via U_BOOT_DEVICE(). This bug has been
> fixed recently by commit
> "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
> lists_bind_fdt()", but with the fix, it has a side effect that all existing
> drivers that
> declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This
> may expose potential boot failure on some boards due to insufficient memory
> during the pre-relocation stage.
>
> To mitigate this potential impact, the following changes are
> implemented:
>
> - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
> only supports configuration from device tree (OF_CONTROL)
> - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
> is statically declared via U_BOOT_DEVICE()
> - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
> drivers that support both statically declared devices and
> configuration from device tree
>
> Signed-off-by: Bin Meng
> ---
>
> arch/arm/mach-stm32mp/bsec.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
> index 0e152ef..d087a31 100644
> --- a/arch/arm/mach-stm32mp/bsec.c
> +++ b/arch/arm/mach-stm32mp/bsec.c
> @@ -417,7 +417,6 @@ U_BOOT_DRIVER(stm32mp_bsec) = {
> .ofdata_to_platdata = stm32mp_bsec_ofdata_to_platdata,
> .platdata_auto_alloc_size = sizeof(struct stm32mp_bsec_platdata),
> .ops = _bsec_ops,
> - .flags = DM_FLAG_PRE_RELOC,
> };
>
> /* bsec IP is not present in device tee, manage IP address by platdata */
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
Reviewed-by: Patrick Delaunay
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: lpc32xx slc: disable DMA support in SPL builds
Hi Miquel, thank you for review. On 10/29/2018 11:34 AM, Miquel Raynal wrote: > Hi Vladimir, > > Vladimir Zapolskiy wrote on Fri, 19 Oct 2018 03:21:18 > +0300: > >> Testing and analysis shows that at the moment LPC32xx NAND SLC driver >> can not get PL080 DMA backbone support in SPL build, because SPL NAND >> loaders operate with subpage (ECC step to be precisely) reads, and >> this is not supported in the NAND SLC + DMA + hardware ECC calculation >> bundle. >> >> The change removes a cautious build time warning and explicitly >> disables DMA flavour of the driver for SPL builds, to reduce the >> amound of #ifdef sections the code blocks are minimally reorganized. >> >> Signed-off-by: Vladimir Zapolskiy > > Could you please split this patch? > > The copyright change should be a patch on its own. Why? The copyright update is associated with the change. Just a copyright change is meaningless in my humble opinion... > The changes in the coding style without functional changes also. This is accepted, my position was to lessen the burden on reviewers and maintainers side. If you don't care about it, I'll drop the cleanup change and send v2, but my comprehension that the meaning is pretty low. > Then you can do your changes about removing DMA support for SPL. > > However, on this topic, I'm not sure this is a wise idea. Maybe the SPL > should be fixed so that it can work with DMA? Not at the moment. Generally the problem is related to SPL NAND base code, which assumes that subpage reads (ECC block size) are always possible, but that's not the case for this particular NAND controller working in DMA mode. So, if/when this is fixed in drivers/mtd/nand/raw/nand_spl_simple.c, only then I can consider to remove the guard in my driver. -- Best wishes, Vladimir ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/5] sunxi: DT: add support for Pinebook
On Mon, 29 Oct 2018 16:29:43 +0100
Loic Devulder wrote:
> Hi!
>
> On 10/28/18 10:19 PM, Vasily Khoruzhick wrote:
> > Pinebook is a laptop produced by Pine64, with USB-connected
> > keyboard, USB-connected touchpad and an eDP LCD panel connected via
> > a RGB-eDP bridge from Analogix.
> >
> > Signed-off-by: Vasily Khoruzhick
> > Acked-by: Maxime Ripard
> > Tested-by: Maxime Ripard
> > Cc: Vagrant Cascadian
> > ---
> > arch/arm/dts/Makefile| 1 +
> > arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi | 15 +
> > arch/arm/dts/sun50i-a64-pinebook.dts | 294
> > +++ configs/pinebook_defconfig |
> > 22 ++ 4 files changed, 332 insertions(+)
> > create mode 100644 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
> > create mode 100644 arch/arm/dts/sun50i-a64-pinebook.dts
> > create mode 100644 configs/pinebook_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 0de6234eec..94ec15a8ac 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -405,6 +405,7 @@ dtb-$(CONFIG_MACH_SUN50I) += \
> > sun50i-a64-orangepi-win.dtb \
> > sun50i-a64-pine64-plus.dtb \
> > sun50i-a64-pine64.dtb \
> > + sun50i-a64-pinebook.dtb \
> > sun50i-a64-sopine-baseboard.dtb
> > dtb-$(CONFIG_MACH_SUN9I) += \
> > sun9i-a80-optimus.dtb \
> > diff --git a/arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
> > b/arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi new file mode 100644
> > index 00..a99b7171d0
> > --- /dev/null
> > +++ b/arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
> > @@ -0,0 +1,15 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright (C) 2018 Vasily Khoruzhick
> > + *
> > + */
> > +
> > +/* The ANX6345 eDP-bridge is on r_i2c */
> > +_i2c {
> > + anx6345: edp-bridge@38 {
> > + compatible = "analogix,anx6345";
> > + reg = <0x38>;
> > + reset-gpios = < 3 24 GPIO_ACTIVE_LOW>; /* PD24
> > */
> > + status = "okay";
> > + };
> > +};
>
> Maybe I missed something but I don't see when this dtsi file is used
> or included.
Yeah, that's some non-obvious U-Boot build magic:
Whenever there is a file which has "-u-boot.dtsi" appended to
certain .dts filename stubs, U-Boot includes this file when building
the .dtb. This is supposed to be used to add U-Boot specific DT nodes
or properties to some otherwise unchanged (read: Linux mainline) DTs.
Check scripts/Makefile.lib and search for u-boot.dtsi for the source.
Cheers,
Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: lpc32xx mlc: predefine number of NAND chips to support
Hi Miquel,
On 10/29/2018 11:29 AM, Miquel Raynal wrote:
> Hi Vladimir,
>
> Vladimir Zapolskiy wrote on Fri, 19 Oct 2018 03:21:05
> +0300:
>
>> Build option CONFIG_SYS_MAX_NAND_CHIPS is used by NXP LPC32xx NAND MLC
>> driver only, as a preparation for potential removal or replacement of
>> the option the change predefines CONFIG_SYS_MAX_NAND_CHIPS to 1, same
>> value is used by the single user Work Microwave Work 92105 board, thus
>> it will be safe now to remove the option as a board specific one.
>>
>> Signed-off-by: Vladimir Zapolskiy
>> ---
>> drivers/mtd/nand/raw/lpc32xx_nand_mlc.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/raw/lpc32xx_nand_mlc.c
>> b/drivers/mtd/nand/raw/lpc32xx_nand_mlc.c
>> index 5d4ffea608d9..79d1489dc72c 100644
>> --- a/drivers/mtd/nand/raw/lpc32xx_nand_mlc.c
>> +++ b/drivers/mtd/nand/raw/lpc32xx_nand_mlc.c
>> @@ -82,6 +82,10 @@ struct lpc32xx_nand_mlc_registers {
>> static struct lpc32xx_nand_mlc_registers __iomem *lpc32xx_nand_mlc_registers
>> = (struct lpc32xx_nand_mlc_registers __iomem *)MLC_NAND_BASE;
>>
>> +#if !defined(CONFIG_SYS_MAX_NAND_CHIPS)
>> +#define CONFIG_SYS_MAX_NAND_CHIPS 1
>> +#endif
>> +
>> #define clkdiv(v, w, o) (((1+(clk/v)) & w) << o)
>>
>> /**
>
>
> If it is safe now, can you also remote the CONFIG_ option now?
At the moment I plan to remove the CONFIG_SYS_MAX_NAND_CHIPS option
from include/configs/work_92105.h as a side activity (concentrate all
LPC32xx raw NAND options in arch/arm/include/asm/arch-lpc32xx/config.h,
the change is in my queue), and regarding total removal of the option,
it shall be considered separately.
For instance you can find it is mentioned in doc/README.nand :
if (nand_scan_ident(mtd, CONFIG_SYS_MAX_NAND_CHIPS, NULL))
error out
and commonly it would be expected to provide it as an argument to
nand_scan_ident(), however it is easy to notice that none drivers
but LPC32xx NAND MLC does it. Also note that sometimes NAND *chips*
number is substituted by a number of NAND *controllers* on SoC...
Generally it sounds like a proper change should be a tree-wide one.
So, while I clearly understand the rationale, I would prefer to shift
the task to the MTD maintainers ;)
>
> Reviewed-by: Miquel Raynal
Thank you for review!
--
Best wishes,
Vladimir
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 22/30] riscv: remove unused labels in start.S
Hi Rick,
On Thu, 2018-10-25 at 15:56 +, Auer, Lukas wrote:
> Hi Rick,
>
> On Thu, 2018-10-25 at 09:16 +0800, Rick Chen wrote:
> > Auer, Lukas 於 2018年10月24日 週三
> > 下午10:14寫道：
> > >
> > > Hi Rick,
> > >
> > > On Wed, 2018-10-24 at 13:47 +0800, Rick Chen wrote:
> > > > Rick Chen 於 2018年10月24日 週三 下午1:20寫道：
> > > > >
> > > > > Bin Meng 於 2018年10月24日 週三 上午11:34寫道：
> > > > > >
> > > > > > Hi Rich,
> > > > > >
> > > > > > On Wed, Oct 24, 2018 at 10:37 AM Rick Chen <
> > > > > > rickche...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > > > The labels nmi_vector, trap_vector and handle_reset
> > > > > > > > > > in
> > > > > > > > > > start.S are not
> > > > > > > > > > used for RISC-V. Remove them.
> > > > > > > > > >
> > > > > > >
> > > > > > > Hi Lukas
> > > > > > >
> > > > > > > Agree with the above part.
> > > > > > >
> > > > > > > > > > While we are here, also remove the code from the
> > > > > > > > > > beginning of start.S,
> > > > > > > > > > which stores the contents of a2 to memory. Only
> > > > > > > > > > registers
> > > > > > > > > > a0 and a1
> > > > > > > > > > contain information from the previous boot stage.
> > > > > > > > > > There
> > > > > > > > > > is therefore
> > > > > > > > > > no reason for saving a2.
> > > > > > >
> > > > > > > NOT agree with this part.
> > > > > > > Saving a2 is trying to support dynamically dtb pass at
> > > > > > > runtime.
> > > > > > >
> > > > > >
> > > > > > Could you please describe in more details on what the use
> > > > > > case is
> > > > > > here?
> > > > > >
> > > > >
> > > > > Hi Bin and Lukas
> > > > >
> > > > > After I study [PATCH 24/30] riscv: save hart ID and device
> > > > > tree
> > > > > passed
> > > > > by prior boot stage.
> > > > > I found it is the same thing.
> > > > > I will accepted this patch.
> > > > > So this patch is
> > > > >
> > > > > Reviewed-by: Rick Chen
> > > > >
> > > > > But I shall send a patch to fix ax25-ae350 to work as well
> > > > > later.
> > > > > And it will be as below :
> > > > >
> > > > > ax5-ae350.c
> > > > > void *board_fdt_blob_setup(void)
> > > > > {
> > > > > void **ptr = (void *)_stage_fdt_address;
> > > > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > > return (void *)*ptr;
> > > > >
> > > > > return (void *)CONFIG_SYS_FDT_BASE;
> > > > > }
> > > > >
> > > >
> > > > Sorry!
> > > >
> > > > I shall send a fixed patch as below:
> > > > riscv: ax25-ae350: use device tree passed by prior boot stage
> > > >
> > > > --- a/configs/ax25-ae350_defconfig
> > > > +++ b/configs/ax25-ae350_defconfig
> > > > @@ -15,7 +15,7 @@ CONFIG_CMD_SF_TEST=y
> > > > # CONFIG_CMD_SETEXPR is not set
> > > > CONFIG_BOOTP_PREFER_SERVERIP=y
> > > > CONFIG_CMD_CACHE=y
> > > > -CONFIG_OF_BOARD=y
> > > > +CONFIG_OF_PRIOR_STAGE=y
> > > >
> > > > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > @@ -64,15 +64,6 @@ ulong board_flash_get_legacy(ulong base, int
> > > > banknum, flash_info_t *info)
> > > > return 0;
> > > > }
> > > >
> > > > -void *board_fdt_blob_setup(void)
> > > > -{
> > > > - void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > - if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > - return (void *)*ptr;
> > > > -
> > > > - return (void *)CONFIG_SYS_FDT_BASE;
> > > > -}
> > > > -
> > > >
> > > > Rick
> > > >
> > >
> > > Sorry, I have missed your commit. Just to clarify, does the ax25
> > > pass
> > > the device tree in a2 instead of a1? In that case, my patch must
> > > be
> > > changed since it assumes the device tree to be in a1.
> > > Related to this, can I assume that a0 stores the hart ID?
> > >
> > > If you want, I can add this patch to my series.
> > >
> >
> > Hi Lukas
> >
> > Your patch is correct.
> > I will send out a patch to fix the mismatch in ax25-ae350 later.
> > And maybe you can put this patch into your v2 series.
> >
> > Thanks
> >
> > Rick
> >
>
> Ok. Yes, I will pick up your patch in my v2.
>
Do you want me to wait with my patch series until it is clear how ax25-
ae350 handles the device tree? Otherwise, I will drop the part of this
patch that removes the code storing a2 to avoid breaking your board and
send v2 of my series.
Thanks,
Lukas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/5] sunxi: DT: add support for Pinebook
Hi!
On 10/28/18 10:19 PM, Vasily Khoruzhick wrote:
> Pinebook is a laptop produced by Pine64, with USB-connected keyboard,
> USB-connected touchpad and an eDP LCD panel connected via a RGB-eDP
> bridge from Analogix.
>
> Signed-off-by: Vasily Khoruzhick
> Acked-by: Maxime Ripard
> Tested-by: Maxime Ripard
> Cc: Vagrant Cascadian
> ---
> arch/arm/dts/Makefile| 1 +
> arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi | 15 +
> arch/arm/dts/sun50i-a64-pinebook.dts | 294 +++
> configs/pinebook_defconfig | 22 ++
> 4 files changed, 332 insertions(+)
> create mode 100644 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
> create mode 100644 arch/arm/dts/sun50i-a64-pinebook.dts
> create mode 100644 configs/pinebook_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 0de6234eec..94ec15a8ac 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -405,6 +405,7 @@ dtb-$(CONFIG_MACH_SUN50I) += \
> sun50i-a64-orangepi-win.dtb \
> sun50i-a64-pine64-plus.dtb \
> sun50i-a64-pine64.dtb \
> + sun50i-a64-pinebook.dtb \
> sun50i-a64-sopine-baseboard.dtb
> dtb-$(CONFIG_MACH_SUN9I) += \
> sun9i-a80-optimus.dtb \
> diff --git a/arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
> b/arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
> new file mode 100644
> index 00..a99b7171d0
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2018 Vasily Khoruzhick
> + *
> + */
> +
> +/* The ANX6345 eDP-bridge is on r_i2c */
> +_i2c {
> + anx6345: edp-bridge@38 {
> + compatible = "analogix,anx6345";
> + reg = <0x38>;
> + reset-gpios = < 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
> + status = "okay";
> + };
> +};
Maybe I missed something but I don't see when this dtsi file is used or
included.
> diff --git a/arch/arm/dts/sun50i-a64-pinebook.dts
> b/arch/arm/dts/sun50i-a64-pinebook.dts
> new file mode 100644
> index 00..ec537c5297
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-a64-pinebook.dts
> @@ -0,0 +1,294 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2017 Icenowy Zheng
> + * Copyright (C) 2018 Vasily Khoruzhick
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64.dtsi"
> +
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "Pinebook";
> + compatible = "pine64,pinebook", "allwinner,sun50i-a64";
> +
> + aliases {
> + serial0 =
> + ethernet0 =
> + };
> +
> + vdd_bl: regulator@0 {
> + compatible = "regulator-fixed";
> + regulator-name = "bl-3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
> + enable-active-high;
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 5 0>;
> + brightness-levels = <0 5 10 15 20 30 40 55 70 85 100>;
> + default-brightness-level = <2>;
> + enable-gpios = < 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
> + power-supply = <_bl>;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> +
> + framebuffer-lcd {
> + panel-supply = <_dc1sw>;
> + dvdd25-supply = <_dldo2>;
> + dvdd12-supply = <_fldo1>;
> + };
> + };
> +
> + gpio_keys {
> + compatible = "gpio-keys";
> +
> + lid_switch {
> + label = "Lid Switch";
> + gpios = <_pio 0 12 GPIO_ACTIVE_LOW>; /* PL12 */
> + linux,input-type = ;
> + linux,code = ;
> + linux,can-disable;
> + wakeup-source;
> + };
> + };
> +
> + reg_vcc3v3: vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> + };
> +};
> +
> + {
> + phys = < 0>;
> + phy-names = "usb";
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_dcdc1>;
> + cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
> + disable-wp;
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_dldo4>;
> + vqmmc-supply = <_eldo1>;
> + mmc-pwrseq = <_pwrseq>;
> +
[U-Boot] Pull request v2: u-boot-sunix/master
Hi Tom, Please pull this PR. Changes for v2: - Fix "sunxi: disable Pine A64 model detection code on other boards" changes. thanks, Jagan. The following changes since commit 1ed3c0954bd160dafcad8847a51c3ddd5f992f51: Merge branch 'master' of git://git.denx.de/u-boot-samsung (2018-10-23 21:13:32 -0400) are available in the Git repository at: git://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to 5776610e9ef022e2d8a15793d4b9955c3f8076ed: sunxi: store DRAM size in SPL header (2018-10-29 20:41:15 +0530) Andre Przywara (3): sunxi: Extend SPL header versioning sunxi: board.c: refactor SPL header checks sunxi: store DRAM size in SPL header Icenowy Zheng (3): sunxi: disable Pine A64 model detection code on other boards sunxi: map DRAM part with 3G size sunxi: add Kconfig option for the maximum accessible DRAM Priit Laes (3): sunxi: Fix typos of spelling Allwinner sunxi: docs: Mention CONFIG_NAND requirement sunxi: display: Mark sunxi_rgb2yuv_coef array as const Vasily Khoruzhick (3): pwm: sunxi: fix off-by-one that prevented PWM to use prescaler bypass pwm: sunxi: use new prescaler when configuring PWM pwm: sunxi: choose best prescaler to improve PWM resolution arch/arm/include/asm/arch-sunxi/spl.h | 22 --- arch/arm/mach-sunxi/Kconfig | 16 arch/arm/mach-sunxi/board.c | 2 +- arch/arm/mach-sunxi/dram_sun4i.c | 2 +- arch/arm/mach-sunxi/p2wi.c| 2 +- board/sunxi/README.nand | 6 +-- board/sunxi/README.sunxi64| 2 +- board/sunxi/board.c | 72 +-- configs/pine64_plus_defconfig | 1 + drivers/pwm/sunxi_pwm.c | 32 +--- drivers/video/sunxi/sunxi_display.c | 2 +- 11 files changed, 120 insertions(+), 39 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] sunxi: fix build error on non-ARM64 boards
On Sat, Oct 27, 2018 at 10:39 AM Icenowy Zheng wrote: > > The previous commit which disables Pine64 detection logic on non-Pine64 > board has an error and prevents non-ARM64 boards from building. > > Fix the build error on non-ARM64 boards by adjusting the position of a > '}'. I would have run buildman, it my bad. anyway I squashed it, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc: t1040: Correct RCW MAC2_GMII_SEL value
On 10/28/18 06:01, Bin Meng wrote: > On Thu, Oct 25, 2018 at 2:46 PM Poonam Aggrwal wrote: > > Thanks Poonam! > > York, I believe these 2 patches need be included in the v2018.11 release. > They are in my queue. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] efi-x86_app_defconfig does not build with gcc 8.2
Hi Andy, On Fri, Oct 26, 2018 at 8:41 PM Andy Shevchenko wrote: > > On Fri, Oct 26, 2018 at 3:23 PM Bin Meng wrote: > > On Thu, Oct 25, 2018 at 10:55 PM Bin Meng wrote: > > > On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko > > > wrote: > > > > > That's what I was suspecting after looking how EFI applications are > > > > being built. > > > > > > > > So, someone familiar with compilers probably needs to check the > > > > following and act accordingly: > > > > - either new compiler provides new switches to change behaviour as it > > > > was in GCC < 8, or > > > > - create a small verifiable example with this linked list sections and > > > > submit a bug report to GCC, or > > > > - U-Boot code (for linked lists) should be reconsidered from new > > > > requirements of the compiler, or > > > > - EFI U-Boot application should have it's own relocation code (like > > > > normal U-Boot does), or > > > > - ...anything I missed... > > > > > > > > The issue from my limited knowledge looks like this: > > > > EFI loader relies on the sections that are natural for dynamically > > > > linked > > > > libraries (AKA .so), while U-Boot (when runs on bare metal) has another > > > > approach, i.e. specific code that does a relocation based only on .reloc > > > > information. The linked list sections in U-Boot are meant to be > > > > statically > > > > compiled, which is not the case for EFI by some reason. > > > > > > > > OTOH, it's clearly a compiler behaviour change, since with -fPIC -g it > > > > generates DWARF that can't be translated by its own assembler! > > > > (See option 2 in above list) > > > > Thank you for these useful suggestions! I will see if I can create a > > > small test program to trigger this issue. > > > I created a small test case to trigger this issue. A workaround is to > > disable '-Os' so that the test case pass. Of course disabling '-fpic' > > also works. To me this looks like a bug when compiling pic codes with > > optimization on. I will submit a bug report go GCC. > > Cool! Please, share the bug link whenever it will be filled, thanks! > Sure, though waited for some time to get my GCC Bugzilla created by the admin .. Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793 Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] i2c: stm32f7: change setup struct to const
Change static array to const when it is useful to save memory
(move stm32f7_setup=0x18 from .data to .rodata section)
Signed-off-by: Patrick Delaunay
---
drivers/i2c/stm32f7_i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 7ed04d9..3872364 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -197,7 +197,7 @@ struct stm32_i2c_priv {
int speed;
};
-static struct stm32_i2c_spec i2c_specs[] = {
+static const struct stm32_i2c_spec i2c_specs[] = {
[STM32_I2C_SPEED_STANDARD] = {
.rate = STANDARD_RATE,
.rate_min = 8000,
@@ -236,7 +236,7 @@ static struct stm32_i2c_spec i2c_specs[] = {
},
};
-static struct stm32_i2c_setup stm32f7_setup = {
+static const struct stm32_i2c_setup stm32f7_setup = {
.rise_time = STM32_I2C_RISE_TIME_DEFAULT,
.fall_time = STM32_I2C_FALL_TIME_DEFAULT,
.dnf = STM32_I2C_DNF_DEFAULT,
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] i2c: stm32f7: cosmetic: clean the driver
Solve alignments issues in the driver to avoid
checkpatch error.
Signed-off-by: Patrick Delaunay
---
drivers/i2c/stm32f7_i2c.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 36ec610..7ed04d9 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -58,7 +58,7 @@ struct stm32_i2c_regs {
#define STM32_I2C_CR2_ADD10BIT(11)
#define STM32_I2C_CR2_RD_WRN BIT(10)
#define STM32_I2C_CR2_SADD10_MASK GENMASK(9, 0)
-#define STM32_I2C_CR2_SADD10(n)((n &
STM32_I2C_CR2_SADD10_MASK))
+#define STM32_I2C_CR2_SADD10(n)(n &
STM32_I2C_CR2_SADD10_MASK)
#define STM32_I2C_CR2_SADD7_MASK GENMASK(7, 1)
#define STM32_I2C_CR2_SADD7(n) ((n & 0x7f) << 1)
#define STM32_I2C_CR2_RESET_MASK (STM32_I2C_CR2_HEAD10R \
@@ -255,7 +255,7 @@ static int stm32_i2c_check_device_busy(struct
stm32_i2c_priv *i2c_priv)
}
static void stm32_i2c_message_start(struct stm32_i2c_priv *i2c_priv,
- struct i2c_msg *msg, bool stop)
+ struct i2c_msg *msg, bool stop)
{
struct stm32_i2c_regs *regs = i2c_priv->regs;
u32 cr2 = readl(>cr2);
@@ -299,7 +299,7 @@ static void stm32_i2c_message_start(struct stm32_i2c_priv
*i2c_priv,
*/
static void stm32_i2c_handle_reload(struct stm32_i2c_priv *i2c_priv,
- struct i2c_msg *msg, bool stop)
+ struct i2c_msg *msg, bool stop)
{
struct stm32_i2c_regs *regs = i2c_priv->regs;
u32 cr2 = readl(>cr2);
@@ -317,7 +317,7 @@ static void stm32_i2c_handle_reload(struct stm32_i2c_priv
*i2c_priv,
}
static int stm32_i2c_wait_flags(struct stm32_i2c_priv *i2c_priv,
- u32 flags, u32 *status)
+ u32 flags, u32 *status)
{
struct stm32_i2c_regs *regs = i2c_priv->regs;
u32 time_start = get_timer(0);
@@ -392,7 +392,7 @@ static int stm32_i2c_check_end_of_message(struct
stm32_i2c_priv *i2c_priv)
}
static int stm32_i2c_message_xfer(struct stm32_i2c_priv *i2c_priv,
- struct i2c_msg *msg, bool stop)
+ struct i2c_msg *msg, bool stop)
{
struct stm32_i2c_regs *regs = i2c_priv->regs;
u32 status;
@@ -465,7 +465,7 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv
*i2c_priv,
}
static int stm32_i2c_xfer(struct udevice *bus, struct i2c_msg *msg,
- int nmsgs)
+ int nmsgs)
{
struct stm32_i2c_priv *i2c_priv = dev_get_priv(bus);
int ret;
@@ -594,6 +594,7 @@ static int stm32_i2c_choose_solution(struct stm32_i2c_setup
*setup,
for (l = 0; l < STM32_SCLL_MAX; l++) {
u32 tscl_l = (l + 1) * prescaler + tsync;
+
if ((tscl_l < i2c_specs[setup->speed].l_min) ||
(i2cclk >=
((tscl_l - af_delay_min - dnf_delay) / 4))) {
@@ -634,8 +635,8 @@ static int stm32_i2c_choose_solution(struct stm32_i2c_setup
*setup,
}
static int stm32_i2c_compute_timing(struct stm32_i2c_priv *i2c_priv,
- struct stm32_i2c_setup *setup,
- struct stm32_i2c_timings *output)
+ struct stm32_i2c_setup *setup,
+ struct stm32_i2c_timings *output)
{
struct stm32_i2c_timings *v, *_v;
struct list_head solutions;
@@ -643,28 +644,28 @@ static int stm32_i2c_compute_timing(struct stm32_i2c_priv
*i2c_priv,
if (setup->speed >= STM32_I2C_SPEED_END) {
pr_err("%s: speed out of bound {%d/%d}\n", __func__,
- setup->speed, STM32_I2C_SPEED_END - 1);
+ setup->speed, STM32_I2C_SPEED_END - 1);
return -EINVAL;
}
if ((setup->rise_time > i2c_specs[setup->speed].rise_max) ||
(setup->fall_time > i2c_specs[setup->speed].fall_max)) {
pr_err("%s :timings out of bound Rise{%d>%d}/Fall{%d>%d}\n",
- __func__,
- setup->rise_time, i2c_specs[setup->speed].rise_max,
- setup->fall_time, i2c_specs[setup->speed].fall_max);
+ __func__,
+ setup->rise_time, i2c_specs[setup->speed].rise_max,
+ setup->fall_time, i2c_specs[setup->speed].fall_max);
return -EINVAL;
}
if (setup->dnf > STM32_I2C_DNF_MAX) {
pr_err("%s: DNF out of bound %d/%d\n", __func__,
- setup->dnf, STM32_I2C_DNF_MAX);
+ setup->dnf, STM32_I2C_DNF_MAX);
Re: [U-Boot] [PATCH 2/3] Kbuild: standalone: do not ignore platform-specific OBJCOPYFLAGS
On Sun, Oct 28, 2018 at 09:13:04PM +0100, Daniel Schwierzeck wrote: > > > Am 23.09.18 um 19:15 schrieb Daniel Schwierzeck: > > Currently the OBJCOPYFLAGS are cleared when assigning "-O srec" > > or "-O binary" for standalone programs. All flags set by arch-specific > > Makefiles are lost. This is bad if an arch demands arch-specific > > flags for the objcopy step. > > are there any objections or can I apply this to u-boot-mips/next? Thanks. Go ahead: Reviewed-by: Tom Rini -- 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 1/3] Kbuild: add LDFLAGS_STANDALONE
On Sun, Oct 28, 2018 at 09:12:22PM +0100, Daniel Schwierzeck wrote: > > > Am 23.09.18 um 19:15 schrieb Daniel Schwierzeck: > > Introduce a new Makefile variable for passing LDFLAGS to standalone > > programs. Currently the variable CONFIG_STANDALONE_LOAD_ADDR is > > misued on some archs to pass a specific linker script. > > are there any objections or can I apply this to u-boot-mips/next? Thanks. Go ahead: Reviewed-by: Tom Rini -- 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 5/7] driver: net: ti: introduce common mdio support library
On 10/26/18 5:38 AM, Grygorii Strashko wrote: All existing TI SoCs network HW have similar MDIO implementation, so introduce common mdio support library which can be reused by TI networking drivers. Signed-off-by: Grygorii Strashko --- drivers/net/ti/Makefile| 2 +- drivers/net/ti/cpsw_mdio.c | 205 + drivers/net/ti/cpsw_mdio.h | 18 3 files changed, 224 insertions(+), 1 deletion(-) create mode 100644 drivers/net/ti/cpsw_mdio.c create mode 100644 drivers/net/ti/cpsw_mdio.h Hi, why we don't combine this with: http://patchwork.ozlabs.org/patch/939726/ ? looks much more elegant to me. cheers, Hannes ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] armv8: lx2160ardb : Add support for LX2160ARDB platform
> -Original Message- > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Priyanka > Jain > Sent: Monday, October 29, 2018 3:01 PM > To: u-boot@lists.denx.de; York Sun > Cc: Priyanka Jain ; Pankit Garg > ; Wasim Khan ; Sriram Dash > > Subject: [U-Boot] [PATCH][v2] armv8: lx2160ardb : Add support for LX2160ARDB > platform > > LX2160ARDB is an evaluation board that supports LX2160A family SoCs. This > patch add base support for this board. You may like to change evaluation to Reference Development Platform > > Signed-off-by: Wasim Khan > Signed-off-by: Yogesh Gaur > Signed-off-by: Meenakshi Aggarwal > Signed-off-by: Vabhav Sharma > Signed-off-by: Sriram Dash > Signed-off-by: Rajesh Bhagat > Signed-off-by: Pankit Garg > Signed-off-by: Priyanka Jain > --- > Changes for v2: > Rebased on top of test_qoriq branch of u-boot-fsl-qoriq.git > > Corrected line > seria01.clock = get_serial_clock -> serial1.clock = get_serial_clock(); > > Corrected CONFIG_ENV_OFFSET to 0x50 [Thanks to Ashish K for pointing > this] > > Depends on below patches[sequence in increasing order] > > 1)https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > hwork.ozlabs.org%2Fpatch%2F982258%2Fdata=02%7C01%7Cpoonam.ag > grwal%40nxp.com%7C9a7856644931426b286108d63d8146d8%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636764022790690712sdata=7Jb > bI2lU7aoStZjmuKKtKpfxtKyzkDxCaHhxM3Jy2jQ%3Dreserved=0 > > 2)https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > hwork.ozlabs.org%2Fpatch%2F975541%2Fdata=02%7C01%7Cpoonam.ag > grwal%40nxp.com%7C9a7856644931426b286108d63d8146d8%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636764022790690712sdata=nH2 > xVXciHEbEZ1HePucpedytQL%2BqgBUc7gQGRCb0p%2F0%3Dreserved=0 > > 3)https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > hwork.ozlabs.org%2Fpatch%2F962408%2Fdata=02%7C01%7Cpoonam.ag > grwal%40nxp.com%7C9a7856644931426b286108d63d8146d8%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636764022790690712sdata=EeU > TkyBjO0j9kjnHGkc0Abk4xGUWpWXQ0KB4IXGup%2BU%3Dreserved=0 > > 4)https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > hwork.ozlabs.org%2Fpatch%2F982259%2Fdata=02%7C01%7Cpoonam.ag > grwal%40nxp.com%7C9a7856644931426b286108d63d8146d8%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636764022790690712sdata=IvXB > X%2FR%2B2sAr4aVGtbPWRV%2FZ381FDx%2BrXTXgDIByE98%3Dreserved > =0 > > 5)https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > hwork.ozlabs.org%2Fpatch%2F982237%2Fdata=02%7C01%7Cpoonam.ag > grwal%40nxp.com%7C9a7856644931426b286108d63d8146d8%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636764022790690712sdata=6sB > UducF4LFkBChRoD9ZUoPYfK6Yacfj99JbDJrcesg%3Dreserved=0 > > 6)https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > hwork.ozlabs.org%2Fpatch%2F990088%2Fdata=02%7C01%7Cpoonam.ag > grwal%40nxp.com%7C9a7856644931426b286108d63d8146d8%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636764022790690712sdata=amh > IN7Dar2gvo5BrpTammgx5qdTrdH6%2FzVussfllahY%3Dreserved=0 > > 7)https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > hwork.ozlabs.org%2Fpatch%2F990093%2Fdata=02%7C01%7Cpoonam.ag > grwal%40nxp.com%7C9a7856644931426b286108d63d8146d8%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636764022790690712sdata=tx0S > 8Siu6CTOfH%2B1VYpSAlS39g6NB2RgV75JVoqpF1I%3Dreserved=0 > > arch/arm/Kconfig | 14 ++ > arch/arm/cpu/armv8/Kconfig | 2 +- > arch/arm/dts/Makefile| 3 +- > arch/arm/dts/fsl-lx2160a-rdb.dts | 20 +++ > board/freescale/common/qixis.c | 4 + > board/freescale/lx2160a/Kconfig | 16 ++ > board/freescale/lx2160a/MAINTAINERS | 8 + > board/freescale/lx2160a/Makefile | 9 + > board/freescale/lx2160a/README | 79 + > board/freescale/lx2160a/ddr.c| 20 +++ > board/freescale/lx2160a/eth_lx2160ardb.c | 210 +++ > board/freescale/lx2160a/lx2160a.c| 279 > +++ > configs/lx2160ardb_tfa_defconfig | 74 > include/configs/lx2160a_common.h | 214 > include/configs/lx2160ardb.h | 102 +++ > 15 files changed, 1052 insertions(+), 2 deletions(-) create mode 100644 > arch/arm/dts/fsl-lx2160a-rdb.dts create mode 100644 > board/freescale/lx2160a/Kconfig create mode 100644 > board/freescale/lx2160a/MAINTAINERS > create mode 100644 board/freescale/lx2160a/Makefile create mode 100644 > board/freescale/lx2160a/README create mode 100644 > board/freescale/lx2160a/ddr.c create mode 100644 > board/freescale/lx2160a/eth_lx2160ardb.c > create mode 100644 board/freescale/lx2160a/lx2160a.c create mode 100644 > configs/lx2160ardb_tfa_defconfig create mode 100644 > include/configs/lx2160a_common.h create mode 100644 > include/configs/lx2160ardb.h > >
Re: [U-Boot] [PATCH] riscv: cache: Implement i/dcache [status, enable, disable]
Hi Rick, On Mon, 2018-10-29 at 11:16 +0800, Rick Chen wrote: > Auer, Lukas 於 2018年10月27日 週六 > 上午12:32寫道： > > > > Hi Rick, > > > > On Mon, 2018-10-22 at 16:16 +0800, Andes wrote: > > > From: Rick Chen > > > > > > AndeStar V5 provide mcache_ctl register which can configure > > > I/D cache as enabled or disabled. > > > > > > This CSR will be encapsulated by CONFIG_NDS_V5. > > > If you want to configure cache on AndeStar V5 > > > AE350 platform. YOu can enable [*] AndeStar V5 ISA support > > > by make menuconfig. > > > > > > Signed-off-by: Rick Chen > > > Cc: Greentime Hu > > > --- > > > arch/riscv/Kconfig | 8 +++ > > > arch/riscv/cpu/ax25/cpu.c | 4 ++ > > > arch/riscv/cpu/start.S | 19 ++ > > > arch/riscv/include/asm/cache.h | 9 +++ > > > arch/riscv/lib/cache.c | 131 > > > ++--- > > > 5 files changed, 163 insertions(+), 8 deletions(-) > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > > index 168ca3d..de7fd9e 100644 > > > --- a/arch/riscv/Kconfig > > > +++ b/arch/riscv/Kconfig > > > @@ -43,4 +43,12 @@ config 32BIT > > > config 64BIT > > > bool > > > > > > +config NDS_V5 > > > + bool "AndeStar V5 ISA support" > > > + def_bool n > > > > You can use just "default n" instead of "def_bool n" here, since > > you > > already have a "bool" above it. > > > > I will reword it. > > > > + help > > > + Say Y here if you plan to run U-Boot on AndeStar v5 > > > + platforms and use some specific features which are > > > + provided by Andes Technology AndeStar V5 Families. > > > + > > > endmenu > > > diff --git a/arch/riscv/cpu/ax25/cpu.c > > > b/arch/riscv/cpu/ax25/cpu.c > > > index fddcc15..76689b2 100644 > > > --- a/arch/riscv/cpu/ax25/cpu.c > > > +++ b/arch/riscv/cpu/ax25/cpu.c > > > @@ -6,6 +6,7 @@ > > > > > > /* CPU specific code */ > > > #include > > > +#include > > > > > > /* > > > * cleanup_before_linux() is called just before we call linux > > > @@ -18,6 +19,9 @@ int cleanup_before_linux(void) > > > disable_interrupts(); > > > > > > /* turn off I/D-cache */ > > > + cache_flush(); > > > > I don't think you need to flush the data cache here. This should be > > handled by bootm_load_os() in common/bootm.c. > > > > Do you mean > flush_cache(flush_start, ALIGN(flush_len, ARCH_DMA_MINALIGN)); ? > Ii is different cache API and implement. > Yes I did mean flush_cache(), however I did not check if it is implemented. Perhaps it's best to implement it and rely on it to flush the cache? > If flush_cache is implemented, why you still add > invalidate_icache_all(); in boot_jump_linux 0f bootm.c > Do it have special reason ? > RISC-V does not guarantee that stores to instruction memory are visible to instruction fetches (i.e. incoherent instruction caches). You are right, we do not need to flush the instruction cache explicitly to make the kernel visible to instruction fetches. We need it for a separate reason. Simplified, we do the following to start Linux. kernel = kernel_address; kernel(); Without a fence.i in between, we can not guarantee that kernel() will jump to the address specified in kernel_address. This is because the instruction cache is incoherent with the rest of the memory system, it must therefore be synchronized first. This is the reason, why I added the instruction cache invalidation to the bootm code. > > > > + icache_disable(); > > > + dcache_disable(); > > > > > > return 0; > > > } > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S > > > index 7cd7755..a8764df 100644 > > > --- a/arch/riscv/cpu/start.S > > > +++ b/arch/riscv/cpu/start.S > > > @@ -51,6 +51,23 @@ handle_reset: > > > csrwi mstatus, 0 > > > csrwi mie, 0 > > > > > > +/* Enable cache */ > > > +#ifndef CONFIG_SYS_ICACHE_OFF > > > +#ifdef CONFIG_NDS_V5 > > > + csrr t1, mcache_ctl > > > + ori t0, t1, 0x1 > > > + csrw mcache_ctl, t0 > > > +#endif > > > +#endif > > > + > > > +#ifndef CONFIG_SYS_DCACHE_OFF > > > +#ifdef CONFIG_NDS_V5 > > > + csrr t1, mcache_ctl > > > + ori t0, t1, 0x2 > > > + csrw mcache_ctl, t0 > > > +#endif > > > +#endif > > > + > > > /* > > > * Do CPU critical regs init only at reboot, > > > * not when booting from ram > > > @@ -191,6 +208,8 @@ clbss_l: > > > * initialization, now running from RAM. > > > */ > > > call_board_init_r: > > > + jal invalidate_icache_all > > > + jal flush_dcache_all > > > la t0, board_init_r > > > mv t4, t0 /* offset of board_init_r() > > > */ > > > add t4, t4, t6 /* real address of > > > board_init_r() */ > > > diff --git a/arch/riscv/include/asm/cache.h > > > b/arch/riscv/include/asm/cache.h > > > index ca83dd6..e76ca13 100644 > > > --- a/arch/riscv/include/asm/cache.h > > > +++ b/arch/riscv/include/asm/cache.h > > > @@ -7,6 +7,15 @@ > > > #ifndef
[U-Boot] [PATCH v2] armv8: lx2160aqds : Add support for LX2160AQDS platform
LX2160AQDS is a development board that supports LX2160A
family SoCs. This patch add base support for this board.
Signed-off-by: Wasim Khan
Signed-off-by: Sriram Dash
Signed-off-by: Pankaj Bansal
---
Notes:
This patch depends on following patches:
[1] https://patchwork.ozlabs.org/patch/970926/
[2] https://patchwork.ozlabs.org/patch/970927/
[3] https://patchwork.ozlabs.org/patch/983917/
V2:
- removed checkpatch warnings about line over 80 chars
- Added CONFIG_FSL_MC_ENET macro in eth_lx2160aqds.c file
to avoid compilation errors if this macro is not defined
V1:
The checkpatch script reported 28 warnings about line over 80
characters, that i have not corrected. as IMO doing so, makes
the code less legible.
arch/arm/Kconfig | 13 +
arch/arm/cpu/armv8/Kconfig | 1 +
arch/arm/dts/Makefile| 3 +-
arch/arm/dts/fsl-lx2160a-qds.dts | 126 +++
.../asm/arch-fsl-layerscape/immap_lsch3.h| 8 +
board/freescale/lx2160a/Kconfig | 17 +
board/freescale/lx2160a/MAINTAINERS | 9 +
board/freescale/lx2160a/Makefile | 1 +
board/freescale/lx2160a/README | 83 ++
board/freescale/lx2160a/eth_lx2160aqds.c | 787 +
board/freescale/lx2160a/lx2160a.c| 280 +-
configs/lx2160aqds_tfa_defconfig | 74 ++
include/configs/lx2160aqds.h | 111 +++
13 files changed, 1511 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a76678d5d8..a8e274e88c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1032,6 +1032,19 @@ config TARGET_LX2160ARDB
is a high-performance development platform that supports the
QorIQ LX2160A/LX2120A/LX2080A Layerscape Architecture processor.
+config TARGET_LX2160AQDS
+ bool "Support lx2160aqds"
+ select ARCH_LX2160A
+ select ARCH_MISC_INIT
+ select ARM64
+ select ARMV8_MULTIENTRY
+ select BOARD_LATE_INIT
+ help
+ Support for NXP LX2160AQDS platform.
+ The lx2160aqds (LX2160A QorIQ Development System (QDS)
+ is a high-performance development platform that supports the
+ QorIQ LX2160A/LX2120A/LX2080A Layerscape Architecture processor.
+
config TARGET_HIKEY
bool "Support HiKey 96boards Consumer Edition Platform"
select ARM64
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index aac3aebb44..7dff2f8910 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -106,6 +106,7 @@ config PSCI_RESET
!TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
!TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
!TARGET_LS2081ARDB && !TARGET_LX2160ARDB && \
+ !TARGET_LX2160AQDS && \
!ARCH_UNIPHIER && !TARGET_S32V234EVB
help
Most armv8 systems have PSCI support enabled in EL3, either through
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 167397c8d9..a8aeec4a10 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -227,7 +227,8 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-ls2088a-rdb-qspi.dtb \
fsl-ls1088a-rdb.dtb \
fsl-ls1088a-qds.dtb \
- fsl-lx2160a-rdb.dtb
+ fsl-lx2160a-rdb.dtb \
+ fsl-lx2160a-qds.dtb
dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-qds-lpuart.dtb \
fsl-ls1043a-rdb.dtb \
diff --git a/arch/arm/dts/fsl-lx2160a-qds.dts b/arch/arm/dts/fsl-lx2160a-qds.dts
new file mode 100644
index 00..1a355d4616
--- /dev/null
+++ b/arch/arm/dts/fsl-lx2160a-qds.dts
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * NXP LX2160ARDB device tree source
+ *
+ * Author: Priyanka Jain
+ * Sriram Dash
+ *
+ * Copyright 2018 NXP
+ *
+ */
+
+/dts-v1/;
+
+#include "fsl-lx2160a.dtsi"
+
+/ {
+ model = "NXP Layerscape LX2160AQDS Board";
+ compatible = "fsl,lx2160aqds", "fsl,lx2160a";
+
+ aliases {
+ spi0 =
+ spi1 =
+ spi2 =
+ };
+
+};
+
+ {
+ bus-num = <0>;
+ status = "okay";
+
+ dflash0: n25q128a {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spi-flash";
+ spi-max-frequency = <300>;
+ spi-cpol;
+ spi-cpha;
+ reg = <0>;
+ };
+ dflash1: sst25wf040b {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spi-flash";
+ spi-max-frequency = <300>;
+ spi-cpol;
+ spi-cpha;
+ reg = <1>;
+ };
+ dflash2: en25s64 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
[U-Boot] [PATCH v2] armv8: fsl-layerscape: reorder rgmii dpmacs' enablement
some dpmacs in armv8a based freescale layerscape SOCs can be
configured via both serdes(sgmii, xfi, xlaui etc) bits and via
EC*_PMUX(rgmii) bits in RCW.
e.g. dpmac 17 and 18 in LX2160A can be configured as SGMII from
serdes bits and as RGMII via EC1_PMUX/EC2_PMUX bits
Now if a dpmac is enabled by serdes bits then it takes precedence
over EC*_PMUX bits. i.e. in LX2160A if we select serdes protocol
that configures dpmac17 as SGMII and set the EC1_PMUX as RGMII,
then the dpmac is SGMII and not RGMII.
Therefore, move the fsl_rgmii_init after fsl_serdes_init. in
fsl_rgmii_init function of SOC, we will check if the dpmac is enabled
or not? if it is (fsl_serdes_init has already enabled the dpmac), then
don't enable it.
Signed-off-by: Pankaj Bansal
---
Notes:
V2:
- as per review comments, add commit message as inline comments.
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 052e0708d4..3fe7f885e8 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -553,15 +553,29 @@ int arch_early_init_r(void)
printf("Did not wake secondary cores\n");
}
-#ifdef CONFIG_SYS_FSL_HAS_RGMII
- fsl_rgmii_init();
-#endif
-
config_core_prefetch();
#ifdef CONFIG_SYS_HAS_SERDES
fsl_serdes_init();
#endif
+#ifdef CONFIG_SYS_FSL_HAS_RGMII
+ /* some dpmacs in armv8a based freescale layerscape SOCs can be
+* configured via both serdes(sgmii, xfi, xlaui etc) bits and via
+* EC*_PMUX(rgmii) bits in RCW.
+* e.g. dpmac 17 and 18 in LX2160A can be configured as SGMII from
+* serdes bits and as RGMII via EC1_PMUX/EC2_PMUX bits
+* Now if a dpmac is enabled by serdes bits then it takes precedence
+* over EC*_PMUX bits. i.e. in LX2160A if we select serdes protocol
+* that configures dpmac17 as SGMII and set the EC1_PMUX as RGMII,
+* then the dpmac is SGMII and not RGMII.
+*
+* Therefore, move the fsl_rgmii_init after fsl_serdes_init. in
+* fsl_rgmii_init function of SOC, we will check if the dpmac is enabled
+* or not? if it is (fsl_serdes_init has already enabled the dpmac),
+* then don't enable it.
+*/
+ fsl_rgmii_init();
+#endif
#ifdef CONFIG_FMAN_ENET
fman_enet_init();
#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] dm: video: correctly set the cursor position
The terminal escape sequence ESC [ ; H is used to set the cursor position. According to the ECMA 48 standard the upper left corner in the escape sequences is [1, 1]. The video uclass uses [0, 0] as upper left corner. Signed-off-by: Heinrich Schuchardt --- drivers/video/vidconsole-uclass.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/video/vidconsole-uclass.c b/drivers/video/vidconsole-uclass.c index 1874887f2f3..5564cfe9930 100644 --- a/drivers/video/vidconsole-uclass.c +++ b/drivers/video/vidconsole-uclass.c @@ -271,6 +271,14 @@ static void vidconsole_escape_char(struct udevice *dev, char ch) s = parsenum(s, ); s++;/* ; */ s = parsenum(s, ); + + /* +* Video origin is [0, 0], terminal origin is [1, 1]. +*/ + if (row) + --row; + if (col) + --col; set_cursor_position(priv, row, col); -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] test: tee: fix resource leak in dm_test_tee()
Fixes possible resource leak in dm_test_tee() reported by Coverity.
Reported-by: Coverity (CID: 184175)
Signed-off-by: Jens Wiklander
---
test/dm/tee.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/test/dm/tee.c b/test/dm/tee.c
index 13e3f4003a7d..22f05a421978 100644
--- a/test/dm/tee.c
+++ b/test/dm/tee.c
@@ -49,7 +49,12 @@ static int match(struct tee_version_data *vers, const void
*data)
return vers->gen_caps & TEE_GEN_CAP_GP;
}
-static int dm_test_tee(struct unit_test_state *uts)
+struct test_tee_vars {
+ struct tee_shm *reg_shm;
+ struct tee_shm *alloc_shm;
+};
+
+static int test_tee(struct unit_test_state *uts, struct test_tee_vars *vars)
{
struct tee_version_data vers;
struct udevice *dev;
@@ -57,8 +62,6 @@ static int dm_test_tee(struct unit_test_state *uts)
u32 session = 0;
int rc;
u8 data[128];
- struct tee_shm *reg_shm;
- struct tee_shm *alloc_shm;
dev = tee_find_device(NULL, match, NULL, );
ut_assert(dev);
@@ -77,22 +80,36 @@ static int dm_test_tee(struct unit_test_state *uts)
ut_assert(!state->session);
ut_assert(!state->num_shms);
- rc = tee_shm_register(dev, data, sizeof(data), 0, _shm);
+ rc = tee_shm_register(dev, data, sizeof(data), 0, >reg_shm);
ut_assert(!rc);
ut_assert(state->num_shms == 1);
- rc = tee_shm_alloc(dev, 256, 0, _shm);
+ rc = tee_shm_alloc(dev, 256, 0, >alloc_shm);
ut_assert(!rc);
ut_assert(state->num_shms == 2);
- ut_assert(tee_shm_is_registered(reg_shm, dev));
- ut_assert(tee_shm_is_registered(alloc_shm, dev));
+ ut_assert(tee_shm_is_registered(vars->reg_shm, dev));
+ ut_assert(tee_shm_is_registered(vars->alloc_shm, dev));
- tee_shm_free(reg_shm);
- tee_shm_free(alloc_shm);
+ tee_shm_free(vars->reg_shm);
+ vars->reg_shm = NULL;
+ tee_shm_free(vars->alloc_shm);
+ vars->alloc_shm = NULL;
ut_assert(!state->num_shms);
return 0;
}
+static int dm_test_tee(struct unit_test_state *uts)
+{
+ struct test_tee_vars vars = { NULL, NULL };
+ int rc = test_tee(uts, );
+
+ /* In case test_tee() asserts these may still remain allocated */
+ tee_shm_free(vars.reg_shm);
+ tee_shm_free(vars.alloc_shm);
+
+ return rc;
+}
+
DM_TEST(dm_test_tee, DM_TESTF_SCAN_FDT);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] drivers/ddr/fsl: Update fsl_ddr_board_options as weak function
fsl_ddr_board_options is generally defined in board
board's ddr.c, but some boards like lx2160ardb board
does not need this function.
Defining fsl_ddr_board_options as weak function to
resolve compilation errors for such boards.
Signed-off-by: Priyanka Jain
---
drivers/ddr/fsl/options.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/ddr/fsl/options.c b/drivers/ddr/fsl/options.c
index 7639a8b..e406d17 100644
--- a/drivers/ddr/fsl/options.c
+++ b/drivers/ddr/fsl/options.c
@@ -22,9 +22,12 @@
*/
/* Board-specific functions defined in each board's ddr.c */
-extern void fsl_ddr_board_options(memctl_options_t *popts,
+void __weak fsl_ddr_board_options(memctl_options_t *popts,
dimm_params_t *pdimm,
- unsigned int ctrl_num);
+ unsigned int ctrl_num)
+{
+ return;
+}
struct dynamic_odt {
unsigned int odt_rd_cfg;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: lpc32xx slc: disable DMA support in SPL builds
Hi Vladimir, Vladimir Zapolskiy wrote on Fri, 19 Oct 2018 03:21:18 +0300: > Testing and analysis shows that at the moment LPC32xx NAND SLC driver > can not get PL080 DMA backbone support in SPL build, because SPL NAND > loaders operate with subpage (ECC step to be precisely) reads, and > this is not supported in the NAND SLC + DMA + hardware ECC calculation > bundle. > > The change removes a cautious build time warning and explicitly > disables DMA flavour of the driver for SPL builds, to reduce the > amound of #ifdef sections the code blocks are minimally reorganized. > > Signed-off-by: Vladimir Zapolskiy Could you please split this patch? The copyright change should be a patch on its own. The changes in the coding style without functional changes also. Then you can do your changes about removing DMA support for SPL. However, on this topic, I'm not sure this is a wise idea. Maybe the SPL should be fixed so that it can work with DMA? Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH][v2] armv8: lx2160ardb : Add support for LX2160ARDB platform
LX2160ARDB is an evaluation board that supports LX2160A family SoCs. This patch add base support for this board. Signed-off-by: Wasim Khan Signed-off-by: Yogesh Gaur Signed-off-by: Meenakshi Aggarwal Signed-off-by: Vabhav Sharma Signed-off-by: Sriram Dash Signed-off-by: Rajesh Bhagat Signed-off-by: Pankit Garg Signed-off-by: Priyanka Jain --- Changes for v2: Rebased on top of test_qoriq branch of u-boot-fsl-qoriq.git Corrected line seria01.clock = get_serial_clock -> serial1.clock = get_serial_clock(); Corrected CONFIG_ENV_OFFSET to 0x50 [Thanks to Ashish K for pointing this] Depends on below patches[sequence in increasing order] 1)https://patchwork.ozlabs.org/patch/982258/ 2)https://patchwork.ozlabs.org/patch/975541/ 3)https://patchwork.ozlabs.org/patch/962408/ 4)https://patchwork.ozlabs.org/patch/982259/ 5)https://patchwork.ozlabs.org/patch/982237/ 6)https://patchwork.ozlabs.org/patch/990088/ 7)https://patchwork.ozlabs.org/patch/990093/ arch/arm/Kconfig | 14 ++ arch/arm/cpu/armv8/Kconfig | 2 +- arch/arm/dts/Makefile| 3 +- arch/arm/dts/fsl-lx2160a-rdb.dts | 20 +++ board/freescale/common/qixis.c | 4 + board/freescale/lx2160a/Kconfig | 16 ++ board/freescale/lx2160a/MAINTAINERS | 8 + board/freescale/lx2160a/Makefile | 9 + board/freescale/lx2160a/README | 79 + board/freescale/lx2160a/ddr.c| 20 +++ board/freescale/lx2160a/eth_lx2160ardb.c | 210 +++ board/freescale/lx2160a/lx2160a.c| 279 +++ configs/lx2160ardb_tfa_defconfig | 74 include/configs/lx2160a_common.h | 214 include/configs/lx2160ardb.h | 102 +++ 15 files changed, 1052 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/fsl-lx2160a-rdb.dts create mode 100644 board/freescale/lx2160a/Kconfig create mode 100644 board/freescale/lx2160a/MAINTAINERS create mode 100644 board/freescale/lx2160a/Makefile create mode 100644 board/freescale/lx2160a/README create mode 100644 board/freescale/lx2160a/ddr.c create mode 100644 board/freescale/lx2160a/eth_lx2160ardb.c create mode 100644 board/freescale/lx2160a/lx2160a.c create mode 100644 configs/lx2160ardb_tfa_defconfig create mode 100644 include/configs/lx2160a_common.h create mode 100644 include/configs/lx2160ardb.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ccf2a84..28a81e7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1027,6 +1027,19 @@ config TARGET_LS2081ARDB development platform that supports the QorIQ LS2081A/LS2041A Layerscape Architecture processor. +config TARGET_LX2160ARDB + bool "Support lx2160ardb" + select ARCH_LX2160A + select ARCH_MISC_INIT + select ARM64 + select ARMV8_MULTIENTRY + select BOARD_LATE_INIT + help + Support for NXP LX2160ARDB platform. + The lx2160ardb (LX2160A Reference design board (RDB) + is a high-performance development platform that supports the + QorIQ LX2160A/LX2120A/LX2080A Layerscape Architecture processor. + config TARGET_HIKEY bool "Support HiKey 96boards Consumer Edition Platform" select ARM64 @@ -1488,6 +1501,7 @@ source "board/freescale/ls1046ardb/Kconfig" source "board/freescale/ls1012aqds/Kconfig" source "board/freescale/ls1012ardb/Kconfig" source "board/freescale/ls1012afrdm/Kconfig" +source "board/freescale/lx2160a/Kconfig" source "board/freescale/mx35pdk/Kconfig" source "board/freescale/s32v234evb/Kconfig" source "board/grinn/chiliboard/Kconfig" diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig index c8bebab..aac3aeb 100644 --- a/arch/arm/cpu/armv8/Kconfig +++ b/arch/arm/cpu/armv8/Kconfig @@ -105,7 +105,7 @@ config PSCI_RESET !TARGET_LS1012AFRWY && \ !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \ !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \ - !TARGET_LS2081ARDB && \ + !TARGET_LS2081ARDB && !TARGET_LX2160ARDB && \ !ARCH_UNIPHIER && !TARGET_S32V234EVB help Most armv8 systems have PSCI support enabled in EL3, either through diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 44ebc50..25cd773 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -226,7 +226,8 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \ fsl-ls2081a-rdb.dtb \ fsl-ls2088a-rdb-qspi.dtb \ fsl-ls1088a-rdb.dtb \ - fsl-ls1088a-qds.dtb + fsl-ls1088a-qds.dtb \ + fsl-lx2160a-rdb.dtb dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \ fsl-ls1043a-qds-lpuart.dtb \ fsl-ls1043a-rdb.dtb \ diff --git a/arch/arm/dts/fsl-lx2160a-rdb.dts b/arch/arm/dts/fsl-lx2160a-rdb.dts new file mode 100644 index
Re: [U-Boot] [PATCH] mtd: nand: lpc32xx mlc: predefine number of NAND chips to support
Hi Vladimir,
Vladimir Zapolskiy wrote on Fri, 19 Oct 2018 03:21:05
+0300:
> Build option CONFIG_SYS_MAX_NAND_CHIPS is used by NXP LPC32xx NAND MLC
> driver only, as a preparation for potential removal or replacement of
> the option the change predefines CONFIG_SYS_MAX_NAND_CHIPS to 1, same
> value is used by the single user Work Microwave Work 92105 board, thus
> it will be safe now to remove the option as a board specific one.
>
> Signed-off-by: Vladimir Zapolskiy
> ---
> drivers/mtd/nand/raw/lpc32xx_nand_mlc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/lpc32xx_nand_mlc.c
> b/drivers/mtd/nand/raw/lpc32xx_nand_mlc.c
> index 5d4ffea608d9..79d1489dc72c 100644
> --- a/drivers/mtd/nand/raw/lpc32xx_nand_mlc.c
> +++ b/drivers/mtd/nand/raw/lpc32xx_nand_mlc.c
> @@ -82,6 +82,10 @@ struct lpc32xx_nand_mlc_registers {
> static struct lpc32xx_nand_mlc_registers __iomem *lpc32xx_nand_mlc_registers
> = (struct lpc32xx_nand_mlc_registers __iomem *)MLC_NAND_BASE;
>
> +#if !defined(CONFIG_SYS_MAX_NAND_CHIPS)
> +#define CONFIG_SYS_MAX_NAND_CHIPS1
> +#endif
> +
> #define clkdiv(v, w, o) (((1+(clk/v)) & w) << o)
>
> /**
If it is safe now, can you also remote the CONFIG_ option now?
Reviewed-by: Miquel Raynal
Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH][v2] armv8: lx2160ardb : Add support for LX2160ARDB platform
LX2160ARDB is an evaluation board that supports LX2160A family SoCs. This patch add base support for this board. Signed-off-by: Wasim Khan Signed-off-by: Yogesh Gaur Signed-off-by: Meenakshi Aggarwal Signed-off-by: Vabhav Sharma Signed-off-by: Sriram Dash Signed-off-by: Rajesh Bhagat Signed-off-by: Pankit Garg Signed-off-by: Priyanka Jain --- Changes for v2: Rebased on top of test_qoriq branch of u-boot-fsl-qoriq.git Corrected line seria01.clock = get_serial_clock -> serial1.clock = get_serial_clock(); Corrected CONFIG_ENV_OFFSET to 0x50 [Thanks to Ashish K for pointing this] Depends on below patches[sequence in increasing order] 1)https://patchwork.ozlabs.org/patch/982258/ 2)https://patchwork.ozlabs.org/patch/975541/ 3)https://patchwork.ozlabs.org/patch/962408/ 4)https://patchwork.ozlabs.org/patch/982259/ 5)https://patchwork.ozlabs.org/patch/982237/ 6)https://patchwork.ozlabs.org/patch/990088/ 7)https://patchwork.ozlabs.org/patch/990093/ arch/arm/Kconfig | 14 ++ arch/arm/cpu/armv8/Kconfig | 2 +- arch/arm/dts/Makefile| 3 +- arch/arm/dts/fsl-lx2160a-rdb.dts | 20 +++ board/freescale/common/qixis.c | 4 + board/freescale/lx2160a/Kconfig | 16 ++ board/freescale/lx2160a/MAINTAINERS | 8 + board/freescale/lx2160a/Makefile | 9 + board/freescale/lx2160a/README | 79 + board/freescale/lx2160a/ddr.c| 20 +++ board/freescale/lx2160a/eth_lx2160ardb.c | 210 +++ board/freescale/lx2160a/lx2160a.c| 279 +++ configs/lx2160ardb_tfa_defconfig | 74 include/configs/lx2160a_common.h | 214 include/configs/lx2160ardb.h | 102 +++ 15 files changed, 1052 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/fsl-lx2160a-rdb.dts create mode 100644 board/freescale/lx2160a/Kconfig create mode 100644 board/freescale/lx2160a/MAINTAINERS create mode 100644 board/freescale/lx2160a/Makefile create mode 100644 board/freescale/lx2160a/README create mode 100644 board/freescale/lx2160a/ddr.c create mode 100644 board/freescale/lx2160a/eth_lx2160ardb.c create mode 100644 board/freescale/lx2160a/lx2160a.c create mode 100644 configs/lx2160ardb_tfa_defconfig create mode 100644 include/configs/lx2160a_common.h create mode 100644 include/configs/lx2160ardb.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ccf2a84..28a81e7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1027,6 +1027,19 @@ config TARGET_LS2081ARDB development platform that supports the QorIQ LS2081A/LS2041A Layerscape Architecture processor. +config TARGET_LX2160ARDB + bool "Support lx2160ardb" + select ARCH_LX2160A + select ARCH_MISC_INIT + select ARM64 + select ARMV8_MULTIENTRY + select BOARD_LATE_INIT + help + Support for NXP LX2160ARDB platform. + The lx2160ardb (LX2160A Reference design board (RDB) + is a high-performance development platform that supports the + QorIQ LX2160A/LX2120A/LX2080A Layerscape Architecture processor. + config TARGET_HIKEY bool "Support HiKey 96boards Consumer Edition Platform" select ARM64 @@ -1488,6 +1501,7 @@ source "board/freescale/ls1046ardb/Kconfig" source "board/freescale/ls1012aqds/Kconfig" source "board/freescale/ls1012ardb/Kconfig" source "board/freescale/ls1012afrdm/Kconfig" +source "board/freescale/lx2160a/Kconfig" source "board/freescale/mx35pdk/Kconfig" source "board/freescale/s32v234evb/Kconfig" source "board/grinn/chiliboard/Kconfig" diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig index c8bebab..aac3aeb 100644 --- a/arch/arm/cpu/armv8/Kconfig +++ b/arch/arm/cpu/armv8/Kconfig @@ -105,7 +105,7 @@ config PSCI_RESET !TARGET_LS1012AFRWY && \ !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \ !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \ - !TARGET_LS2081ARDB && \ + !TARGET_LS2081ARDB && !TARGET_LX2160ARDB && \ !ARCH_UNIPHIER && !TARGET_S32V234EVB help Most armv8 systems have PSCI support enabled in EL3, either through diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 44ebc50..25cd773 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -226,7 +226,8 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \ fsl-ls2081a-rdb.dtb \ fsl-ls2088a-rdb-qspi.dtb \ fsl-ls1088a-rdb.dtb \ - fsl-ls1088a-qds.dtb + fsl-ls1088a-qds.dtb \ + fsl-lx2160a-rdb.dtb dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \ fsl-ls1043a-qds-lpuart.dtb \ fsl-ls1043a-rdb.dtb \ diff --git a/arch/arm/dts/fsl-lx2160a-rdb.dts b/arch/arm/dts/fsl-lx2160a-rdb.dts new file mode 100644 index
[U-Boot] [PATCH][v3] armv8: lx2160a: Add LX2160A SoC Support
LX2160A Soc is based on Layerscape Chassis Generation 3.2 Architecture. Features: 16 ARM v8 Cortex-A72 cores in 8 cluster, CCN508, SEC, two 64-bit DDR4 memory controller, RGMII, 8 I2C controllers, 3 serdes modules, USB 3.0, SATA, 4 PL011 SBSA UARTs, 4 TZASC instances, etc. SoC personalites: LX2120A is SoC with Twelve 64-bit ARM v8 Cortex-A72 CPUs LX2080A is SoC with Eight 64-bit ARM v8 Cortex-A72 CPUs Signed-off-by: Bao Xiaowei Signed-off-by: Hou Zhiqiang Signed-off-by: Meenakshi Aggarwal Signed-off-by: Vabhav Sharma Signed-off-by: Sriram Dash Signed-off-by: Priyanka Jain --- Changes for v3: Add CONFIG_SYS_FSL_RST_ADDR define Changes for v2: Add CCN508 define Rebased on TF-A Boot support for NXP Chassis 2 platforms Removed eSDHC nodes from dts, will be send in separate patch. Add reset related changes arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 52 +++- arch/arm/cpu/armv8/fsl-layerscape/Makefile | 6 +- arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 15 ++- arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc | 57 + .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c| 36 ++ arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 2 +- arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c | 132 + arch/arm/dts/fsl-lx2160a.dtsi | 118 ++ arch/arm/include/asm/arch-fsl-layerscape/config.h | 56 + .../include/asm/arch-fsl-layerscape/fsl_serdes.h | 28 + .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 26 arch/arm/include/asm/arch-fsl-layerscape/soc.h | 6 + .../asm/arch-fsl-layerscape/stream_id_lsch3.h | 9 +- drivers/ddr/fsl/Kconfig| 1 + drivers/net/ldpaa_eth/Makefile | 3 +- drivers/net/ldpaa_eth/lx2160a.c| 107 + 16 files changed, 644 insertions(+), 10 deletions(-) create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c create mode 100644 arch/arm/dts/fsl-lx2160a.dtsi create mode 100644 drivers/net/ldpaa_eth/lx2160a.c diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig index 650ac94..2b086da 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig @@ -170,6 +170,42 @@ config ARCH_LS2080A imply DISTRO_DEFAULTS imply PANIC_HANG +config ARCH_LX2160A + bool + select ARMV8_SET_SMPEN + select FSL_LSCH3 + select NXP_LSCH3_2 + select SYS_HAS_SERDES + select SYS_FSL_SRDS_1 + select SYS_FSL_SRDS_2 + select SYS_NXP_SRDS_3 + select SYS_FSL_DDR + select SYS_FSL_DDR_LE + select SYS_FSL_DDR_VER_50 + select SYS_FSL_EC1 + select SYS_FSL_EC2 + select SYS_FSL_HAS_RGMII + select SYS_FSL_HAS_SEC + select SYS_FSL_HAS_CCN508 + select SYS_FSL_HAS_DDR4 + select SYS_FSL_SEC_COMPAT_5 + select SYS_FSL_SEC_LE + select ARCH_EARLY_INIT_R + select BOARD_EARLY_INIT_F + select SYS_I2C_MXC + select SYS_I2C_MXC_I2C1 + select SYS_I2C_MXC_I2C2 + select SYS_I2C_MXC_I2C3 + select SYS_I2C_MXC_I2C4 + select SYS_I2C_MXC_I2C5 + select SYS_I2C_MXC_I2C6 + select SYS_I2C_MXC_I2C7 + select SYS_I2C_MXC_I2C8 + imply DISTRO_DEFAULTS + imply PANIC_HANG + imply SCSI + imply SCSI_AHCI + config FSL_LSCH2 bool select SYS_FSL_HAS_CCI400 @@ -185,7 +221,7 @@ config NXP_LSCH3_2 config FSL_MC_ENET bool "Management Complex network" - depends on ARCH_LS2080A || ARCH_LS1088A + depends on ARCH_LS2080A || ARCH_LS1088A || ARCH_LX2160A default y select RESV_RAM help @@ -202,6 +238,7 @@ config FSL_PCIE_COMPAT default "fsl,ls1046a-pcie" if ARCH_LS1046A default "fsl,ls2080a-pcie" if ARCH_LS2080A default "fsl,ls1088a-pcie" if ARCH_LS1088A + default "fsl,lx2160a-pcie" if ARCH_LX2160A help This compatible is used to find pci controller node in Kernel DT to complete fixup. @@ -300,6 +337,7 @@ config MAX_CPUS default 4 if ARCH_LS1046A default 16 if ARCH_LS2080A default 8 if ARCH_LS1088A + default 16 if ARCH_LX2160A default 1 help Set this number to the maximum number of possible CPUs in the SoC. @@ -342,6 +380,9 @@ config SYS_FSL_HAS_CCI400 config SYS_FSL_HAS_CCN504 bool +config SYS_FSL_HAS_CCN508 + bool + config SYS_FSL_HAS_DP_DDR bool @@ -404,6 +445,7 @@ config SYS_FSL_DSPI_CLK_DIV config SYS_FSL_DUART_CLK_DIV int "DUART clock divider" default 1 if ARCH_LS1043A + default 4 if ARCH_LX2160A default 2 help This is the divider that is used to derive DUART clock from Platform @@ -464,13 +506,15 @@ config RESV_RAM config SYS_FSL_EC1 bool help -
[U-Boot] [PATCH][v2] armv8:fsl-layerscape: Add support for Chassis 3.2
NXP layerscape architecture Chassis 3.2 builds upon chassis3
architecture with changes like DDR Memory map change,
removal of IFC and support of upto 8 I2C controller.
Patch add README.lsch3_2 and the above changes under
macro CONFIG_NXP_LSCH3_2.
Signed-off-by: Sriram Dash
Signed-off-by: Priyanka Jain
---
Changes for v2:
Rebased on top of test_qoriq branch of u-boot-fsl-qoriq.git
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 3 +++
arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 18 +--
.../cpu/armv8/fsl-layerscape/doc/README.lsch3_2| 27 ++
arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 13 ++-
.../include/asm/arch-fsl-layerscape/immap_lsch3.h | 12 --
5 files changed, 68 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3_2
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 2d1946c..650ac94 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -180,6 +180,9 @@ config FSL_LSCH2
config FSL_LSCH3
bool
+config NXP_LSCH3_2
+ bool
+
config FSL_MC_ENET
bool "Management Complex network"
depends on ARCH_LS2080A || ARCH_LS1088A
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index f2ac1a1..60b0575 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -120,6 +120,13 @@ static struct mm_region early_map[] = {
PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | PTE_BLOCK_PXN | PTE_BLOCK_UXN |
PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS
},
+#ifdef CONFIG_SYS_FSL_DRAM_BASE3
+ { CONFIG_SYS_FSL_DRAM_BASE3, CONFIG_SYS_FSL_DRAM_BASE3,
+ CONFIG_SYS_FSL_DRAM_SIZE3,
+ PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | PTE_BLOCK_PXN | PTE_BLOCK_UXN |
+ PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS
+ },
+#endif
#elif defined(CONFIG_FSL_LSCH2)
{ CONFIG_SYS_FSL_CCSR_BASE, CONFIG_SYS_FSL_CCSR_BASE,
CONFIG_SYS_FSL_CCSR_SIZE,
@@ -266,6 +273,13 @@ static struct mm_region final_map[] = {
PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS
},
+#ifdef CONFIG_SYS_FSL_DRAM_BASE3
+ { CONFIG_SYS_FSL_DRAM_BASE3, CONFIG_SYS_FSL_DRAM_BASE3,
+ CONFIG_SYS_FSL_DRAM_SIZE3,
+ PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+ PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS
+ },
+#endif
#elif defined(CONFIG_FSL_LSCH2)
{ CONFIG_SYS_FSL_BOOTROM_BASE, CONFIG_SYS_FSL_BOOTROM_BASE,
CONFIG_SYS_FSL_BOOTROM_SIZE,
@@ -595,13 +609,13 @@ enum boot_src __get_boot_src(u32 porsr1)
{
enum boot_src src = BOOT_SOURCE_RESERVED;
uint32_t rcw_src = (porsr1 & RCW_SRC_MASK) >> RCW_SRC_BIT;
-#if !defined(CONFIG_FSL_LSCH3_2)
+#if !defined(CONFIG_NXP_LSCH3_2)
uint32_t val;
#endif
debug("%s: rcw_src 0x%x\n", __func__, rcw_src);
#if defined(CONFIG_FSL_LSCH3)
-#if defined(CONFIG_FSL_LSCH3_2)
+#if defined(CONFIG_NXP_LSCH3_2)
switch (rcw_src) {
case RCW_SRC_SDHC1_VAL:
src = BOOT_SOURCE_SD_MMC;
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3_2
b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3_2
new file mode 100644
index 000..6d4bd0b
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3_2
@@ -0,0 +1,27 @@
+#
+# Copyright 2018 NXP
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+NXP LayerScape with Chassis Generation 3.2
+
+This architecture supports NXP ARMv8 SoCs with Chassis generation 3.2
+for example LX2160A.
+
+This architecture is enhancement over Chassis Generation 3 with
+few differences mentioned below
+
+1)DDR Layout
+
+Entire DDR region splits into three regions.
+ - Region 1 is at address 0x8000_ to 0x_.
+ - Region 2 is at address 0x20_8000_ to 0x3f__,
+ - Region 3 is at address 0x60__ to the top of memory,
+ for example 140GB, 0x63_7fff_.
+
+All DDR memory is marked as cache-enabled.
+
+2)IFC is removed
+
+3)Number of I2C controllers increased to 8
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
index 3926aa3..eaa9ed2 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Copyright 2017 NXP
+ * Copyright 2017-2018 NXP
* Copyright 2014-2015, Freescale Semiconductor
*/
@@ -12,15 +12,19 @@
#define CONFIG_SYS_FSL_CCSR_SIZE 0x1000
#define CONFIG_SYS_FSL_QSPI_BASE1 0x2000
#define CONFIG_SYS_FSL_QSPI_SIZE1 0x1000
+#ifndef CONFIG_NXP_LSCH3_2
#define CONFIG_SYS_FSL_IFC_BASE1 0x3000
#define CONFIG_SYS_FSL_IFC_SIZE1 0x1000
#define CONFIG_SYS_FSL_IFC_SIZE1_1 0x40
+#endif
#define
Re: [U-Boot] [PATCH] mtd: nand: let the raw NAND devices be compiled upon selection
Hi Jagan, Jagan Teki wrote on Tue, 23 Oct 2018 16:40:05 +0530: > On Thu, Oct 11, 2018 at 3:05 PM Miquel Raynal > wrote: > > > > Today way is to rely on CMD_NAND to be selected and from the root > > Makefile compile what is in drivers/mtd/nand/raw. > > > > While this will work most of the time with decent configurations, it > > is better to also compile this subsystem upon simple request in the > > configuration. Otherwise, a user not selecting CMD_NAND but selecting > > NAND and any of the controller drivers will not see their build. Fix > > this weird situation by adding a single line in the nand/ directory > > Kconfig file. > > > > Signed-off-by: Miquel Raynal > > --- > > drivers/mtd/nand/Makefile | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > > index a358bc680e..2c33447995 100644 > > --- a/drivers/mtd/nand/Makefile > > +++ b/drivers/mtd/nand/Makefile > > @@ -2,4 +2,5 @@ > > > > nandcore-objs := core.o bbt.o > > obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o > > +obj-$(CONFIG_NAND) += raw/ > > But we even source raw Kconfig path, isn't it? and also how about > remove this from root Makefile? What do you mean by "we even source raw Kconfig path"? It was not sourced before this modification unless CMD_NAND was selected. I agree we should also remove this link between a path being compiled and a CMD_* symbol in the root Makefile. It will probably produce a lot of errors though. I'll try when I'll have some time. Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] sunxi: A64/H3/H5 DT updates
On Mon, Oct 29, 2018 at 12:56:46AM +, Andre Przywara wrote: > This updates the .dts and .dtsi files used in U-Boot to what will become > the new DTs in Linux 4.20 (anytime soon). > Those updates are not too useful for U-Boot itself, but keep the DTs > consistent and allow to directly pass U-Boot's copy to any kernel, by using > $fdtcontroladdr. > There is a small change in the A64 .dtsi, which breaks compatibility with > older kernels (stable releases and those found on distro installer images), > so the second patch fixes this by re-adding the missing compatible > string to the system controller node. > The updates include the H5 and also H3, as they are very close and need to > be updated together. > > I ran into issues with the H6, so will post an update for that later. > > I see that this somewhat overlaps with Vasily's Pinebook series, I am > happy to arrange something here. Originally I wanted to wait for the files > to hit Linus' tree (to get stable commit IDs), but I sending this now > to not block Vasily. Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.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] sunxi: use 6MHz PLL_VIDEO step for DE2 for higher resolution LCD
On Sun, Oct 28, 2018 at 02:26:12PM -0700, Vasily Khoruzhick wrote: > From: Icenowy Zheng > > DE2 SoCs can support LCDs up to 1080p (e.g. A64), and 3MHz step won't > let PLL_VIDEO be high enough for them. > > Use 6MHz step for PLL_VIDEO when using DE2, to satisfy 1080p LCD. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Vasily Khoruzhick > Tested-by: Vasily Khoruzhick I wonder if this will cause any issues with panels and lower resolutions that will have a smaller tolerancy. Let's try it, Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.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] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
Hi Rick,
On Mon, Oct 29, 2018 at 11:22 AM Rick Chen wrote:
>
> Bin Meng 於 2018年10月25日 週四 下午9:36寫道：
> >
> > Hi Rick,
> >
> > On Thu, Oct 25, 2018 at 11:27 AM Rick Chen wrote:
> > >
> > > Bin Meng 於 2018年10月25日 週四 上午11:16寫道：
> > > >
> > > > Hi Rick,
> > > >
> > > > On Thu, Oct 25, 2018 at 11:11 AM Rick Chen wrote:
> > > > >
> > > > > Bin Meng 於 2018年10月25日 週四 上午10:33寫道：
> > > > > >
> > > > > > Hi Rick,
> > > > > >
> > > > > > On Thu, Oct 25, 2018 at 9:20 AM Andes wrote:
> > > > > > >
> > > > > > > From: Rick Chen
> > > > > > >
> > > > > > > ax25-ae350 use CONFIG_OF_BOARD which allow the board to
> > > > > > > override the fdt address. And prior_stage_fdt_address offer
> > > > > > > a temporary memory address to keep the dtb address which was
> > > > > > > passed from loader(gdb) to u-boot with a1.
> > > > > >
> > > > > > nits: U-Boot
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Rick Chen
> > > > > > > Cc: Greentime Hu
> > > > > > > ---
> > > > > > > board/AndesTech/ax25-ae350/ax25-ae350.c | 3 ++-
> > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > index 5f4ca0f..d343453 100644
> > > > > > > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > @@ -14,6 +14,7 @@
> > > > > > >
> > > > > > > DECLARE_GLOBAL_DATA_PTR;
> > > > > > >
> > > > > > > +extern phys_addr_t prior_stage_fdt_address;
> > > > > > > /*
> > > > > > > * Miscellaneous platform dependent initializations
> > > > > > > */
> > > > > > > @@ -66,7 +67,7 @@ ulong board_flash_get_legacy(ulong base, int
> > > > > > > banknum, flash_info_t *info)
> > > > > > >
> > > > > > > void *board_fdt_blob_setup(void)
> > > > > > > {
> > > > > > > - void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > > + void **ptr = (void *)_stage_fdt_address;
> > > > > > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > > > > return (void *)*ptr;
> > > > > > >
> > > > > > > --
> > > > > >
> > > > > > board_fdt_blob_setup() should be completely removed. Instead the
> > > > > > simple fix should be add CONFIG_OF_PRIOR_STAGE to your board
> > > > > > defconfig
> > > > > > files.
> > > > > >
> > > > >
> > > > > Hi Bin
> > > > >
> > > > > I have tried to switch from CONFIG_OF_BOARD to CONFIG_OF_PRIOR_STAGE.
> > > > >
> > > > > But it will lost the function
> > > > > that dtb will be pre-burned into designated flash location,
> > > > > when U-Boot was booting from flash.
> > > > >
> > > >
> > > > I don't get it. Do you mean on ae350 board, the DTB is pre-flashed on
> > > > the flash?
> > > >
> > >
> > > Yes
> > > On ae350 board, the DTB is pre-flashed on the flash in booting from rom
> > > case.
> > >
> > > u-boot boot from ram case:
> > > CONFIG_OF_PRIOR_STAGE can achieve u-boot boot from ram and dtb was
> > > passed by loader with a1(0xf).
> > >
> > > u-boot boot from rom case:
> > > If DTB is pre-flashed on the flash 0x800f (This address can be
> > > dynamically changed)
> > > But no one assign a1=0x800f000, how can be gd->fdt_blob changed to
> > > 0x800f000.
> > > I am wondering about that ?
> > >
> >
> > In the ROM case, U-Boot does not boot from reset vector, right? So the
> > first stage bootloader can pass DTB to U-Boot via a1 register, no?
> >
>
> In the ROM case, u-Boot will boot itself without first stage
> bootloader from reset vector.
> So there is no bootloader can pass pass DTB to U-Boot via a1.
>
In this case, we need support OF_CONTROL like other arch, eg:
CONFIG_OF_EMBED and CONFIG_OF_SEPARATE.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: lower the DDR frequency of Orange Pi Prime
On Sun, Oct 28, 2018 at 12:26:18AM +0800, Icenowy Zheng wrote: > 在 2017-10-31二的 09:09 +0100，Maxime Ripard写道： > > On Tue, Oct 31, 2017 at 03:56:08PM +0800, Icenowy Zheng wrote: > > > When I use Orange Pi Prime to do some heavy compliation tasks, the > > > gcc > > > compiler sometimes mysteriously segfaults, and memtester catches > > > memory > > > error. As the lima-memtester cannot support H5 (Mali-450 GPU > > > equipped), > > > there's no really reliable way to detect DRAM stability except try > > > and > > > error. > > > > > > Lower the DDR frequency to 624MHz seems to solved the issue. > > > > > > Set the default frequency to 624MHz in the defconfig, as 672MHz is > > > observed to be unstable at least on my board. > > > > > > Signed-off-by: Icenowy Zheng > > > > What is the value used in the fex file? > > When testing with BSP images made by Orange Pi, I found that in newer > images they secretly tweaked the DDR freq of Orange Pi PC2 and Prime to > 624MHz. > > This is found by checking pll-dram frequency after booting. Ok then. Can you resend that patch? Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.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 v4] sunxi: add support for Banana Pi M2 Zero board
On Sat, Oct 27, 2018 at 01:11:00PM +0800, Icenowy Zheng wrote: > From: Jun Nie > > Banana Pi M2 Zero is a board by Sinovoip with Allwinner H2+ SoC, 16-bit > 512MiB DDR3 memory, a MicroSD slot, two MicroUSB ports (one OTG and one > powering-only) and a miniHDMI port. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Jun Nie Ideally, your SoB should be the second one. Otherwise, Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.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] sunxi: fix build error on non-ARM64 boards
On Sat, Oct 27, 2018 at 01:08:56PM +0800, Icenowy Zheng wrote:
> The previous commit which disables Pine64 detection logic on non-Pine64
> board has an error and prevents non-ARM64 boards from building.
>
> Fix the build error on non-ARM64 boards by adjusting the position of a
> '}'.
>
> Fixes: 6b92e01dca4b ("sunxi: disable Pine A64 model detection code on other
> boards")
> Signed-off-by: Icenowy Zheng
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.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 0/7] Exynos4412 SPL support
Hi Simon
On Fri, 14 Sep 2018 at 19:18, Simon Shields wrote:
>
> Hi Anand,
>
> On Fri, Sep 14, 2018 at 05:31:38PM +0530, Anand Moon wrote:
> > Hi Simon,
> > On Fri, 14 Sep 2018 at 08:00, Simon Shields wrote:
> > >
> > > Hi Anand,
> > >
> > > On Thu, Sep 13, 2018 at 08:39:52PM +0530, Anand Moon wrote:
> > > > Hi Simon,
> > > >
> > > > On Wed, 12 Sep 2018 at 17:25, Simon Shields wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > This patch series adds support for using U-Boot's SPL as the second
> > > > > stage bootloader ("BL2") on Exynos4412 SoCs.
> > > > >
> > > > > - Patch #1 adds support for the EMMC/SD OM pin configuration, which
> > > > > is used
> > > > > by the boards I tested on.
> > > > > - Patch #2 configures the magic values used to indicate system suspend
> > > > > state (which are identical to exynos5).
> > > > > - Patch #3 renames the existing exynos4 clock/dmc initialisation code
> > > > > to reflect the fact that it only supports exynos4210.
> > > > > - Patches #4 and #5 add/fill in structs reflecting the PMU and TZASC
> > > > > register layouts on exynos4412, respectively.
> > > > > - Patch #6 adds the exynos4412 DMC and clock initialisation code and
> > > > > enables building the SPL on exynos4412 platforms.
> > > > > - Patch #7 enables building the "mkexynosspl" utility for exynos4
> > > > > SoCs.
> > > > >
> > > > > The majority of the logic in patch #6 comes from a vendor u-boot dump
> > > > > (2010.12!), however, small portions (mostly code used for 2GB RAM
> > > > > initialisation) were reverse engineered from the vendor
> > > > > bootloader found on a GT-N7100.
> > > > >
> > > > > This patch series has been tested on a GT-I9300 (exynos4412, 1GB RAM)
> > > > > and a GT-N7100 (exynos4412 prime, 2GB RAM), with a few additional
> > > > > patchsets applied for board/HW support (which I intend to upstream in
> > > > > the future).
> > > > >
> > > > > Cheers,
> > > > > Simon
> > > > >
> > > >
> > > > Could you elaborate more on how to generate stage bootloader (BL2)
> > > > image,
> > > > I am not aware of such process and what are next step to create SPL
> > > > for Exynos platform.
> > > >
> > > > I have build these patches for Odroid-U3 boards, with no SPL enable.
> > >
> > > Of course!
> > >
> > > You need to add "select SUPPORT_SPL" to the relevant TARGET_ kconfig
> > > entry (e.g. [0]). Then, you need to configure the SPL suitably in
> > > include/configs/.h - see [1], these values should not need
> > > changing between boards. Finally, you need to enable some SPL
> > > stuff in the defconfig (see [2]). That should allow u-boot to generate
> > > a SPL binary, which should go in spl/-spl.bin.
> > >
> > > After that, you need to assemble an image suitable for flashing to an
> > > sdcard/eMMC. I use these two scripts [3], [4] combined with this BL1 [5]
> > > (originally from the ODROID-X u-boot sources, which no longer appear
> > > to be available) for eMMC and sdcard respectively.
> > >
> > > The usage of the script is:
> > >
> > > ./create_4412__image.sh
> > >
> > >
> > > can then be dd'd directly to an SD card or to the eMMC boot0
> > > partition.
> > >
> > > Hope that gets things working for you!
> > >
> > > Cheers,
> > > Simon
> > >
> > > >
> > > > Best Regards
> > > > -Anand
> > >
> > > [0]:
> > > https://github.com/fourkbomb/u-boot/blob/4be16a7/arch/arm/mach-exynos/Kconfig#L77
> > > [1]:
> > > https://github.com/fourkbomb/u-boot/blob/4be16a7/include/configs/midas.h#L31-L53
> > > [2]:
> > > https://github.com/fourkbomb/u-boot/blob/4be16a7/configs/midas_defconfig#L6-L10
> > > [3]:
> > > https://github.com/fourkbomb/buildroot-external-midas/blob/master/board/midas/create_4412_emmc_image.sh
> > > [4]:
> > > https://github.com/fourkbomb/buildroot-external-midas/blob/master/board/midas/create_4412_sd_image.sh
> > > [5]:
> > > https://github.com/fourkbomb/buildroot-external-midas/blob/master/board/midas/p4412_s_fwbl1.bin
> >
> > Thank you very much for this inside on building SPL image. I will give
> > this a try on Odroid U3.
> >
> > Do you have plan to add some low-level code to control clk memory cpu.
> >
> > [0]
> > https://github.com/SamsungARTIK/u-boot-artik/tree/artik-exynos/v2012.07/board/samsung/smdk4x12
> >
> > Actually I failed to understand how the communication between the
> > kernel binary and u-boot with out this code.
>
> That code is not actually board-specific. It's added in patch #6.
> All the BL2 does is initialise clocks and memory (DMC), then load U-Boot from
> the appropriate
> boot medium.
>
> >
> > Also what about trusted zone, and do we need to get this spl image
> > signed by Samsung/Hardkernel to make this work.
>
> As with other Exynos SoCs in U-Boot, this doesn't support loading
> trustzone. As a result, you need to remove the "secure-firmware" node
> from the Linux kernel (you can also do it with CONFIG_OF_BOARD_SETUP[0]).
> Adding support for the TZSW could probably be done, but the goal here
> was to remove blobs from the
[U-Boot] [PATCH v5 13/13] aspeed: ast2500: fix D2-PLL clock setting in RGMII mode
The algorithm in the ast2500_calc_clock_config() routine suffers from
integer rounding and the requested rate does not get the appropriate
set of Numerator, Denumerator, Post Divider parameters.
This is the case for the D2-PLL clock used by the MAC controllers in
RGMII mode. The requested rated is 250MHz but a 251MHz is assigned.
The easiest way to fix this problem is to introduce an array of clock
settings defining the N, M, P parameters for well known frequencies
used by the Aspeed SoC.
Signed-off-by: Cédric Le Goater
Reviewed-by: Simon Glass
Reviewed-by: Joel Stanley
Acked-by: Joe Hershberger
---
drivers/clk/aspeed/clk_ast2500.c | 38
1 file changed, 38 insertions(+)
diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c
index 2182320f607f..dbee13a18297 100644
--- a/drivers/clk/aspeed/clk_ast2500.c
+++ b/drivers/clk/aspeed/clk_ast2500.c
@@ -165,6 +165,35 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
return rate;
}
+struct ast2500_clock_config {
+ ulong input_rate;
+ ulong rate;
+ struct ast2500_div_config cfg;
+};
+
+static const struct ast2500_clock_config ast2500_clock_config_defaults[] = {
+ { 2400, 25000, { .num = 124, .denum = 1, .post_div = 5 } },
+};
+
+static bool ast2500_get_clock_config_default(ulong input_rate,
+ulong requested_rate,
+struct ast2500_div_config *cfg)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(ast2500_clock_config_defaults); i++) {
+ const struct ast2500_clock_config *default_cfg =
+ _clock_config_defaults[i];
+ if (default_cfg->input_rate == input_rate &&
+ default_cfg->rate == requested_rate) {
+ *cfg = default_cfg->cfg;
+ return true;
+ }
+ }
+
+ return false;
+}
+
/*
* @input_rate - the rate of input clock in Hz
* @requested_rate - desired output rate in Hz
@@ -189,6 +218,12 @@ static ulong ast2500_calc_clock_config(ulong input_rate,
ulong requested_rate,
ulong delta = rate_khz;
ulong new_rate_khz = 0;
+ /*
+* Look for a well known frequency first.
+*/
+ if (ast2500_get_clock_config_default(input_rate, requested_rate, cfg))
+ return requested_rate;
+
for (; it.denum <= max_vals.denum; ++it.denum) {
for (it.post_div = 0; it.post_div <= max_vals.post_div;
++it.post_div) {
@@ -318,6 +353,9 @@ static ulong ast2500_configure_d2pll(struct ast2500_scu
*scu, ulong rate)
/*
* The values and the meaning of the next three
* parameters are undocumented. Taken from Aspeed SDK.
+*
+* TODO(c...@kaod.org): the SIP and SIC values depend on the
+* Numerator value
*/
const u32 d2_pll_ext_param = 0x2c;
const u32 d2_pll_sip = 0x11;
--
2.17.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 12/13] aspeed: Activate ethernet devices on the ast2500 Eval Board
Signed-off-by: Cédric Le Goater
Reviewed-by: Simon Glass
Reviewed-by: Joel Stanley
Acked-by: Joe Hershberger
---
arch/arm/dts/ast2500-evb.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/dts/ast2500-evb.dts b/arch/arm/dts/ast2500-evb.dts
index 723941ac0bee..ebf44fd707f9 100644
--- a/arch/arm/dts/ast2500-evb.dts
+++ b/arch/arm/dts/ast2500-evb.dts
@@ -11,6 +11,11 @@
chosen {
stdout-path =
};
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ };
};
{
@@ -36,3 +41,21 @@
u-boot,dm-pre-reloc;
status = "okay";
};
+
+ {
+ status = "okay";
+
+ phy-mode = "rgmii";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_mac1link_default _mdio1_default>;
+};
+
+ {
+ status = "okay";
+
+ phy-mode = "rgmii";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_mac2link_default _mdio2_default>;
+};
--
2.17.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 07/13] net: ftgmac100: handle timeouts when transmitting
Signed-off-by: Cédric Le Goater
---
Changes since v4 :
- defined a custom wait_for_bit_*() macro
drivers/net/ftgmac100.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index bf8600814690..ec46add1d35c 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,6 +29,9 @@
/* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
#define PKTBUFSTX 4 /* must be power of 2 */
+/* Timeout for transmit */
+#define FTGMAC100_TX_TIMEOUT_MS1000
+
/* Timeout for a mdio read/write operation */
#define FTGMAC100_MDIO_TIMEOUT_USEC1
@@ -401,6 +405,19 @@ static int ftgmac100_recv(struct udevice *dev, int flags,
uchar **packetp)
return rxlen;
}
+static u32 ftgmac100_read_txdesc(const void *desc)
+{
+ const struct ftgmac100_txdes *txdes = desc;
+ ulong des_start = (ulong)txdes;
+ ulong des_end = des_start + roundup(sizeof(*txdes), ARCH_DMA_MINALIGN);
+
+ invalidate_dcache_range(des_start, des_end);
+
+ return txdes->txdes0;
+}
+
+BUILD_WAIT_FOR_BIT(ftgmac100_txdone, u32, ftgmac100_read_txdesc)
+
/*
* Send a data block via Ethernet
*/
@@ -414,6 +431,7 @@ static int ftgmac100_send(struct udevice *dev, void
*packet, int length)
roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN);
ulong data_start;
ulong data_end;
+ int rc;
invalidate_dcache_range(des_start, des_end);
@@ -446,6 +464,12 @@ static int ftgmac100_send(struct udevice *dev, void
*packet, int length)
/* Start transmit */
writel(1, >txpd);
+ rc = wait_for_bit_ftgmac100_txdone(curr_des,
+ FTGMAC100_TXDES0_TXDMA_OWN, false,
+ FTGMAC100_TX_TIMEOUT_MS, true);
+ if (rc)
+ return rc;
+
debug("%s(): packet sent\n", __func__);
/* Move to next descriptor */
--
2.17.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 11/13] aspeed: Update ast2500 SoC DTS file to Linux v4.17-rc6 level
This is a large update of the AST2500 SoC DTS file bringing it to the
level of commit 927c2fc2db19 :
Author: Joel Stanley
Date:Sat Jun 2 01:18:53 2018 -0700
ARM: dts: aspeed: Fix hwrng register address
There are some differences on the compatibility property names. scu,
reset and clock drivers are also different.
Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
Reviewed-by: Simon Glass
Acked-by: Joe Hershberger
---
arch/arm/dts/ast2500.dtsi | 1949 ++---
1 file changed, 1153 insertions(+), 796 deletions(-)
diff --git a/arch/arm/dts/ast2500.dtsi b/arch/arm/dts/ast2500.dtsi
index 7e0ad3a41ac5..98359bf92425 100644
--- a/arch/arm/dts/ast2500.dtsi
+++ b/arch/arm/dts/ast2500.dtsi
@@ -11,6 +11,29 @@
#size-cells = <1>;
interrupt-parent = <>;
+ aliases {
+ i2c0 =
+ i2c1 =
+ i2c2 =
+ i2c3 =
+ i2c4 =
+ i2c5 =
+ i2c6 =
+ i2c7 =
+ i2c8 =
+ i2c9 =
+ i2c10 =
+ i2c11 =
+ i2c12 =
+ i2c13 =
+ serial0 =
+ serial1 =
+ serial2 =
+ serial3 =
+ serial4 =
+ serial5 =
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -22,12 +45,80 @@
};
};
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x8000 0>;
+ };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ fmc: flash-controller@1e62 {
+ reg = < 0x1e62 0xc4
+ 0x2000 0x1000 >;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "aspeed,ast2500-fmc";
+ status = "disabled";
+ interrupts = <19>;
+ flash@0 {
+ reg = < 0 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
+ flash@1 {
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
+ flash@2 {
+ reg = < 2 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
+ };
+
+ spi1: flash-controller@1e63 {
+ reg = < 0x1e63 0xc4
+ 0x3000 0x0800 >;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "aspeed,ast2500-spi";
+ status = "disabled";
+ flash@0 {
+ reg = < 0 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
+ flash@1 {
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
+ };
+
+ spi2: flash-controller@1e631000 {
+ reg = < 0x1e631000 0xc4
+ 0x3800 0x0800 >;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "aspeed,ast2500-spi";
+ status = "disabled";
+ flash@0 {
+ reg = < 0 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
+ flash@1 {
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
+ };
+
vic: interrupt-controller@1e6c0080 {
compatible = "aspeed,ast2400-vic";
interrupt-controller;
@@ -37,18 +128,38 @@
};
mac0: ethernet@1e66 {
- compatible = "faraday,ftgmac100";
+ compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
reg = <0x1e66 0x180>;
interrupts = <2>;
- no-hw-checksum;
[U-Boot] [PATCH v5 08/13] net: ftgmac100: add clock support
Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
Acked-by: Joe Hershberger
---
drivers/net/ftgmac100.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index ec46add1d35c..798977616756 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -11,6 +11,7 @@
* Copyright (C) 2018, IBM Corporation.
*/
+#include
#include
#include
#include
@@ -55,6 +56,7 @@
* @bus: The mdio bus
* @phy_mode: The mode of the PHY interface (rgmii, rmii, ...)
* @max_speed: Maximum speed of Ethernet connection supported by MAC
+ * @clks: The bulk of clocks assigned to the device in the DT
*/
struct ftgmac100_data {
struct ftgmac100 *iobase;
@@ -69,6 +71,8 @@ struct ftgmac100_data {
struct mii_dev *bus;
u32 phy_mode;
u32 max_speed;
+
+ struct clk_bulk clks;
};
/*
@@ -489,6 +493,7 @@ static int ftgmac100_write_hwaddr(struct udevice *dev)
static int ftgmac100_ofdata_to_platdata(struct udevice *dev)
{
struct eth_pdata *pdata = dev_get_platdata(dev);
+ struct ftgmac100_data *priv = dev_get_priv(dev);
const char *phy_mode;
pdata->iobase = devfdt_get_addr(dev);
@@ -503,7 +508,7 @@ static int ftgmac100_ofdata_to_platdata(struct udevice *dev)
pdata->max_speed = dev_read_u32_default(dev, "max-speed", 0);
- return 0;
+ return clk_get_bulk(dev, >clks);
}
static int ftgmac100_probe(struct udevice *dev)
@@ -517,6 +522,10 @@ static int ftgmac100_probe(struct udevice *dev)
priv->max_speed = pdata->max_speed;
priv->phy_addr = 0;
+ ret = clk_enable_bulk(>clks);
+ if (ret)
+ goto out;
+
ret = ftgmac100_mdio_init(dev);
if (ret) {
dev_err(dev, "Failed to initialize mdiobus: %d\n", ret);
@@ -530,6 +539,9 @@ static int ftgmac100_probe(struct udevice *dev)
}
out:
+ if (ret)
+ clk_release_bulk(>clks);
+
return ret;
}
@@ -540,6 +552,7 @@ static int ftgmac100_remove(struct udevice *dev)
free(priv->phydev);
mdio_unregister(priv->bus);
mdio_free(priv->bus);
+ clk_release_bulk(>clks);
return 0;
}
--
2.17.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 05/13] net: ftgmac100: add MDIO bus and phylib support
Implement the MDIO bus read/write functions using the readl_poll_timeout()
routine, initialize the bus and scan for the PHY. RGMII and RMII mode
are supported.
Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
Acked-by: Joe Hershberger
---
drivers/net/ftgmac100.c | 380 +---
1 file changed, 160 insertions(+), 220 deletions(-)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 78cd9df62986..b6e6f6e5ec02 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "ftgmac100.h"
@@ -29,6 +30,16 @@
/* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
#define PKTBUFSTX 4 /* must be power of 2 */
+/* Timeout for a mdio read/write operation */
+#define FTGMAC100_MDIO_TIMEOUT_USEC1
+
+/*
+ * MDC clock cycle threshold
+ *
+ * 20us * 100 = 2ms > (1 / 2.5Mhz) * 0x34
+ */
+#define MDC_CYCTHR 0x34
+
/**
* struct ftgmac100_data - private data for the FTGMAC100 driver
*
@@ -38,6 +49,10 @@
* @tx_index: Transmit descriptor index in @txdes
* @rx_index: Receive descriptor index in @rxdes
* @phy_addr: The PHY interface address to use
+ * @phydev: The PHY device backing the MAC
+ * @bus: The mdio bus
+ * @phy_mode: The mode of the PHY interface (rgmii, rmii, ...)
+ * @max_speed: Maximum speed of Ethernet connection supported by MAC
*/
struct ftgmac100_data {
struct ftgmac100 *iobase;
@@ -48,234 +63,110 @@ struct ftgmac100_data {
struct ftgmac100_rxdes *rxdes;
int tx_index;
int rx_index;
- int phy_addr;
+
+ u32 phy_addr;
+ struct phy_device *phydev;
+ struct mii_dev *bus;
+ u32 phy_mode;
+ u32 max_speed;
};
/*
* struct mii_bus functions
*/
-static int ftgmac100_mdiobus_read(struct ftgmac100_data *priv, int phy_addr,
- int regnum)
+static int ftgmac100_mdio_read(struct mii_dev *bus, int phy_addr, int dev_addr,
+ int reg_addr)
{
+ struct ftgmac100_data *priv = bus->priv;
struct ftgmac100 *ftgmac100 = priv->iobase;
int phycr;
- int i;
-
- phycr = readl(>phycr);
-
- /* preserve MDC cycle threshold */
- phycr &= FTGMAC100_PHYCR_MDC_CYCTHR_MASK;
-
- phycr |= FTGMAC100_PHYCR_PHYAD(phy_addr)
- | FTGMAC100_PHYCR_REGAD(regnum)
- | FTGMAC100_PHYCR_MIIRD;
+ int data;
+ int ret;
+ phycr = FTGMAC100_PHYCR_MDC_CYCTHR(MDC_CYCTHR) |
+ FTGMAC100_PHYCR_PHYAD(phy_addr) |
+ FTGMAC100_PHYCR_REGAD(reg_addr) |
+ FTGMAC100_PHYCR_MIIRD;
writel(phycr, >phycr);
- for (i = 0; i < 10; i++) {
- phycr = readl(>phycr);
-
- if ((phycr & FTGMAC100_PHYCR_MIIRD) == 0) {
- int data;
-
- data = readl(>phydata);
- return FTGMAC100_PHYDATA_MIIRDATA(data);
- }
-
- mdelay(10);
+ ret = readl_poll_timeout(>phycr, phycr,
+!(phycr & FTGMAC100_PHYCR_MIIRD),
+FTGMAC100_MDIO_TIMEOUT_USEC);
+ if (ret) {
+ pr_err("%s: mdio read failed (phy:%d reg:%x)\n",
+ priv->phydev->dev->name, phy_addr, reg_addr);
+ return ret;
}
- debug("mdio read timed out\n");
- return -1;
+ data = readl(>phydata);
+
+ return FTGMAC100_PHYDATA_MIIRDATA(data);
}
-static int ftgmac100_mdiobus_write(struct ftgmac100_data *priv, int phy_addr,
- int regnum, u16 value)
+static int ftgmac100_mdio_write(struct mii_dev *bus, int phy_addr, int
dev_addr,
+ int reg_addr, u16 value)
{
+ struct ftgmac100_data *priv = bus->priv;
struct ftgmac100 *ftgmac100 = priv->iobase;
int phycr;
int data;
- int i;
-
- phycr = readl(>phycr);
-
- /* preserve MDC cycle threshold */
- phycr &= FTGMAC100_PHYCR_MDC_CYCTHR_MASK;
-
- phycr |= FTGMAC100_PHYCR_PHYAD(phy_addr)
- | FTGMAC100_PHYCR_REGAD(regnum)
- | FTGMAC100_PHYCR_MIIWR;
+ int ret;
+ phycr = FTGMAC100_PHYCR_MDC_CYCTHR(MDC_CYCTHR) |
+ FTGMAC100_PHYCR_PHYAD(phy_addr) |
+ FTGMAC100_PHYCR_REGAD(reg_addr) |
+ FTGMAC100_PHYCR_MIIWR;
data = FTGMAC100_PHYDATA_MIIWDATA(value);
writel(data, >phydata);
writel(phycr, >phycr);
- for (i = 0; i < 10; i++) {
- phycr = readl(>phycr);
-
- if ((phycr & FTGMAC100_PHYCR_MIIWR) == 0) {
- debug("(phycr & FTGMAC100_PHYCR_MIIWR) == 0: " \
- "phy_addr: %x\n", phy_addr);
- return 0;
- }
-
- mdelay(1);
+ ret =
[U-Boot] [PATCH v5 09/13] aspeed: ast2500: fix missing break in D2PLL clock enablement
Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley Reviewed-by: Simon Glass Acked-by: Joe Hershberger --- drivers/clk/aspeed/clk_ast2500.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c index 526470051c5d..2182320f607f 100644 --- a/drivers/clk/aspeed/clk_ast2500.c +++ b/drivers/clk/aspeed/clk_ast2500.c @@ -411,6 +411,7 @@ static int ast2500_clk_enable(struct clk *clk) break; case PLL_D2PLL: ast2500_configure_d2pll(priv->scu, D2PLL_DEFAULT_RATE); + break; default: return -ENOENT; } -- 2.17.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 10/13] net: ftgmac100: Add support for the Aspeed SoC
The Faraday ftgmac100 MAC controllers as found on the Aspeed SoCs have
some slight differences in the HW interface (End-Of-Rx/Tx-Ring bits).
Signed-off-by: Cédric Le Goater
Reviewed-by: Simon Glass
Reviewed-by: Joel Stanley
Acked-by: Joe Hershberger
---
drivers/net/ftgmac100.c | 31 +++
configs/evb-ast2500_defconfig | 8
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 798977616756..92c38a81bd35 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -43,6 +43,14 @@
*/
#define MDC_CYCTHR 0x34
+/*
+ * ftgmac100 model variants
+ */
+enum ftgmac100_model {
+ FTGMAC100_MODEL_FARADAY,
+ FTGMAC100_MODEL_ASPEED,
+};
+
/**
* struct ftgmac100_data - private data for the FTGMAC100 driver
*
@@ -57,6 +65,8 @@
* @phy_mode: The mode of the PHY interface (rgmii, rmii, ...)
* @max_speed: Maximum speed of Ethernet connection supported by MAC
* @clks: The bulk of clocks assigned to the device in the DT
+ * @rxdes0_edorr_mask: The bit number identifying the end of the RX ring buffer
+ * @txdes0_edotr_mask: The bit number identifying the end of the TX ring buffer
*/
struct ftgmac100_data {
struct ftgmac100 *iobase;
@@ -73,6 +83,10 @@ struct ftgmac100_data {
u32 max_speed;
struct clk_bulk clks;
+
+ /* End of RX/TX ring buffer bits. Depend on model */
+ u32 rxdes0_edorr_mask;
+ u32 txdes0_edotr_mask;
};
/*
@@ -293,7 +307,7 @@ static int ftgmac100_start(struct udevice *dev)
priv->txdes[i].txdes3 = 0;
priv->txdes[i].txdes0 = 0;
}
- priv->txdes[PKTBUFSTX - 1].txdes0 = FTGMAC100_TXDES0_EDOTR;
+ priv->txdes[PKTBUFSTX - 1].txdes0 = priv->txdes0_edotr_mask;
start = (ulong)>txdes[0];
end = start + roundup(sizeof(priv->txdes), ARCH_DMA_MINALIGN);
@@ -303,7 +317,7 @@ static int ftgmac100_start(struct udevice *dev)
priv->rxdes[i].rxdes3 = (unsigned int)net_rx_packets[i];
priv->rxdes[i].rxdes0 = 0;
}
- priv->rxdes[PKTBUFSRX - 1].rxdes0 = FTGMAC100_RXDES0_EDORR;
+ priv->rxdes[PKTBUFSRX - 1].rxdes0 = priv->rxdes0_edorr_mask;
start = (ulong)>rxdes[0];
end = start + roundup(sizeof(priv->rxdes), ARCH_DMA_MINALIGN);
@@ -456,7 +470,7 @@ static int ftgmac100_send(struct udevice *dev, void
*packet, int length)
flush_dcache_range(data_start, data_end);
/* Only one segment on TXBUF */
- curr_des->txdes0 &= FTGMAC100_TXDES0_EDOTR;
+ curr_des->txdes0 &= priv->txdes0_edotr_mask;
curr_des->txdes0 |= FTGMAC100_TXDES0_FTS |
FTGMAC100_TXDES0_LTS |
FTGMAC100_TXDES0_TXBUF_SIZE(length) |
@@ -508,6 +522,14 @@ static int ftgmac100_ofdata_to_platdata(struct udevice
*dev)
pdata->max_speed = dev_read_u32_default(dev, "max-speed", 0);
+ if (dev_get_driver_data(dev) == FTGMAC100_MODEL_ASPEED) {
+ priv->rxdes0_edorr_mask = BIT(30);
+ priv->txdes0_edotr_mask = BIT(30);
+ } else {
+ priv->rxdes0_edorr_mask = BIT(15);
+ priv->txdes0_edotr_mask = BIT(15);
+ }
+
return clk_get_bulk(dev, >clks);
}
@@ -567,7 +589,8 @@ static const struct eth_ops ftgmac100_ops = {
};
static const struct udevice_id ftgmac100_ids[] = {
- { .compatible = "faraday,ftgmac100" },
+ { .compatible = "faraday,ftgmac100", .data = FTGMAC100_MODEL_FARADAY },
+ { .compatible = "aspeed,ast2500-mac", .data = FTGMAC100_MODEL_ASPEED },
{ }
};
diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig
index 88230f4a12db..32581f5ada54 100644
--- a/configs/evb-ast2500_defconfig
+++ b/configs/evb-ast2500_defconfig
@@ -25,3 +25,11 @@ CONFIG_SYS_NS16550=y
CONFIG_SYSRESET=y
CONFIG_TIMER=y
CONFIG_WDT=y
+CONFIG_NETDEVICES=y
+CONFIG_PHY=y
+CONFIG_DM_ETH=y
+CONFIG_FTGMAC100=y
+CONFIG_PHY_REALTEK=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
--
2.17.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 04/13] net: ftgmac100: use setbits_le32() in the reset method
Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
Acked-by: Joe Hershberger
---
drivers/net/ftgmac100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 67a7c73503c5..78cd9df62986 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -331,7 +331,7 @@ static void ftgmac100_reset(struct ftgmac100_data *priv)
debug("%s()\n", __func__);
- writel(FTGMAC100_MACCR_SW_RST, >maccr);
+ setbits_le32(>maccr, FTGMAC100_MACCR_SW_RST);
while (readl(>maccr) & FTGMAC100_MACCR_SW_RST)
;
--
2.17.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 06/13] net: ftgmac100: convert the RX/TX descriptor arrays
Use simple arrays under the device priv structure to hold the RX and
TX descriptors and handle memory coherency by invalidating or flushing
the d-cache when required.
Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
Acked-by: Joe Hershberger
---
drivers/net/ftgmac100.c | 141 ++--
1 file changed, 64 insertions(+), 77 deletions(-)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index b6e6f6e5ec02..bf8600814690 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -13,19 +13,17 @@
#include
#include
-#include
#include
#include
-#include
#include
#include "ftgmac100.h"
-#define ETH_ZLEN 60
-#define CFG_XBUF_SIZE 1536
+/* Min frame ethernet frame size without FCS */
+#define ETH_ZLEN 60
-/* RBSR - hw default init value is also 0x640 */
-#define RBSR_DEFAULT_VALUE 0x640
+/* Receive Buffer Size Register - HW default is 0x640 */
+#define FTGMAC100_RBSR_DEFAULT 0x640
/* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
#define PKTBUFSTX 4 /* must be power of 2 */
@@ -57,10 +55,8 @@
struct ftgmac100_data {
struct ftgmac100 *iobase;
- ulong txdes_dma;
- struct ftgmac100_txdes *txdes;
- ulong rxdes_dma;
- struct ftgmac100_rxdes *rxdes;
+ struct ftgmac100_txdes txdes[PKTBUFSTX];
+ struct ftgmac100_rxdes rxdes[PKTBUFSRX];
int tx_index;
int rx_index;
@@ -266,10 +262,8 @@ static int ftgmac100_start(struct udevice *dev)
struct ftgmac100_data *priv = dev_get_priv(dev);
struct ftgmac100 *ftgmac100 = priv->iobase;
struct phy_device *phydev = priv->phydev;
- struct ftgmac100_txdes *txdes;
- struct ftgmac100_rxdes *rxdes;
unsigned int maccr;
- void *buf;
+ ulong start, end;
int ret;
int i;
@@ -277,26 +271,6 @@ static int ftgmac100_start(struct udevice *dev)
ftgmac100_reset(priv);
- if (!priv->txdes) {
- txdes = dma_alloc_coherent(
- sizeof(*txdes) * PKTBUFSTX, >txdes_dma);
- if (!txdes)
- panic("ftgmac100: out of memory\n");
- memset(txdes, 0, sizeof(*txdes) * PKTBUFSTX);
- priv->txdes = txdes;
- }
- txdes = priv->txdes;
-
- if (!priv->rxdes) {
- rxdes = dma_alloc_coherent(
- sizeof(*rxdes) * PKTBUFSRX, >rxdes_dma);
- if (!rxdes)
- panic("ftgmac100: out of memory\n");
- memset(rxdes, 0, sizeof(*rxdes) * PKTBUFSRX);
- priv->rxdes = rxdes;
- }
- rxdes = priv->rxdes;
-
/* set the ethernet address */
ftgmac100_set_mac(priv, plat->enetaddr);
@@ -307,42 +281,37 @@ static int ftgmac100_start(struct udevice *dev)
priv->tx_index = 0;
priv->rx_index = 0;
- txdes[PKTBUFSTX - 1].txdes0 = FTGMAC100_TXDES0_EDOTR;
- rxdes[PKTBUFSRX - 1].rxdes0 = FTGMAC100_RXDES0_EDORR;
-
for (i = 0; i < PKTBUFSTX; i++) {
- /* TXBUF_BADR */
- if (!txdes[i].txdes2) {
- buf = memalign(ARCH_DMA_MINALIGN, CFG_XBUF_SIZE);
- if (!buf)
- panic("ftgmac100: out of memory\n");
- txdes[i].txdes3 = virt_to_phys(buf);
- txdes[i].txdes2 = (uint)buf;
- }
- txdes[i].txdes1 = 0;
+ priv->txdes[i].txdes3 = 0;
+ priv->txdes[i].txdes0 = 0;
}
+ priv->txdes[PKTBUFSTX - 1].txdes0 = FTGMAC100_TXDES0_EDOTR;
+
+ start = (ulong)>txdes[0];
+ end = start + roundup(sizeof(priv->txdes), ARCH_DMA_MINALIGN);
+ flush_dcache_range(start, end);
for (i = 0; i < PKTBUFSRX; i++) {
- /* RXBUF_BADR */
- if (!rxdes[i].rxdes2) {
- buf = net_rx_packets[i];
- rxdes[i].rxdes3 = virt_to_phys(buf);
- rxdes[i].rxdes2 = (uint)buf;
- }
- rxdes[i].rxdes0 &= ~FTGMAC100_RXDES0_RXPKT_RDY;
+ priv->rxdes[i].rxdes3 = (unsigned int)net_rx_packets[i];
+ priv->rxdes[i].rxdes0 = 0;
}
+ priv->rxdes[PKTBUFSRX - 1].rxdes0 = FTGMAC100_RXDES0_EDORR;
+
+ start = (ulong)>rxdes[0];
+ end = start + roundup(sizeof(priv->rxdes), ARCH_DMA_MINALIGN);
+ flush_dcache_range(start, end);
/* transmit ring */
- writel(priv->txdes_dma, >txr_badr);
+ writel((u32)priv->txdes, >txr_badr);
/* receive ring */
- writel(priv->rxdes_dma, >rxr_badr);
+ writel((u32)priv->rxdes, >rxr_badr);
/* poll receive descriptor automatically */
writel(FTGMAC100_APTC_RXPOLL_CNT(1), >aptc);
/* config receive buffer size register */
-
[U-Boot] [PATCH v5 03/13] net: ftgmac100: convert to driver model
The driver is based on the previous one and the code is only adapted
to fit the driver model. The support for the Faraday ftgmac100
controller is the same with MAC and MDIO bus support for RGMII/RMII
modes.
Configuration is updated to enable compile again. At this stage, the
driver compiles but is not yet functional.
Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
Acked-by: Joe Hershberger
---
include/netdev.h| 1 -
drivers/net/ftgmac100.c | 223 +++-
drivers/net/Kconfig | 26 +
3 files changed, 157 insertions(+), 93 deletions(-)
diff --git a/include/netdev.h b/include/netdev.h
index 55001625fb92..0a1a3a2d8da2 100644
--- a/include/netdev.h
+++ b/include/netdev.h
@@ -43,7 +43,6 @@ int ethoc_initialize(u8 dev_num, int base_addr);
int fec_initialize (bd_t *bis);
int fecmxc_initialize(bd_t *bis);
int fecmxc_initialize_multi(bd_t *bis, int dev_id, int phy_id, uint32_t addr);
-int ftgmac100_initialize(bd_t *bits);
int ftmac100_initialize(bd_t *bits);
int ftmac110_initialize(bd_t *bits);
void gt6426x_eth_initialize(bd_t *bis);
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index c996f5f4a167..67a7c73503c5 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -7,15 +7,16 @@
*
* (C) Copyright 2010 Andes Technology
* Macpaul Lin
+ *
+ * Copyright (C) 2018, IBM Corporation.
*/
-#include
-#include
+#include
+#include
#include
#include
-#include
+#include
#include
-#include
#include "ftgmac100.h"
@@ -28,7 +29,19 @@
/* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
#define PKTBUFSTX 4 /* must be power of 2 */
+/**
+ * struct ftgmac100_data - private data for the FTGMAC100 driver
+ *
+ * @iobase: The base address of the hardware registers
+ * @txdes: The array of transmit descriptors
+ * @rxdes: The array of receive descriptors
+ * @tx_index: Transmit descriptor index in @txdes
+ * @rx_index: Receive descriptor index in @rxdes
+ * @phy_addr: The PHY interface address to use
+ */
struct ftgmac100_data {
+ struct ftgmac100 *iobase;
+
ulong txdes_dma;
struct ftgmac100_txdes *txdes;
ulong rxdes_dma;
@@ -41,10 +54,10 @@ struct ftgmac100_data {
/*
* struct mii_bus functions
*/
-static int ftgmac100_mdiobus_read(struct eth_device *dev, int phy_addr,
- int regnum)
+static int ftgmac100_mdiobus_read(struct ftgmac100_data *priv, int phy_addr,
+ int regnum)
{
- struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)dev->iobase;
+ struct ftgmac100 *ftgmac100 = priv->iobase;
int phycr;
int i;
@@ -76,10 +89,10 @@ static int ftgmac100_mdiobus_read(struct eth_device *dev,
int phy_addr,
return -1;
}
-static int ftgmac100_mdiobus_write(struct eth_device *dev, int phy_addr,
- int regnum, u16 value)
+static int ftgmac100_mdiobus_write(struct ftgmac100_data *priv, int phy_addr,
+ int regnum, u16 value)
{
- struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)dev->iobase;
+ struct ftgmac100 *ftgmac100 = priv->iobase;
int phycr;
int data;
int i;
@@ -114,9 +127,10 @@ static int ftgmac100_mdiobus_write(struct eth_device *dev,
int phy_addr,
return -1;
}
-int ftgmac100_phy_read(struct eth_device *dev, int addr, int reg, u16 *value)
+int ftgmac100_phy_read(struct ftgmac100_data *priv, int addr, int reg,
+ u16 *value)
{
- *value = ftgmac100_mdiobus_read(dev , addr, reg);
+ *value = ftgmac100_mdiobus_read(priv, addr, reg);
if (*value == -1)
return -1;
@@ -124,31 +138,31 @@ int ftgmac100_phy_read(struct eth_device *dev, int addr,
int reg, u16 *value)
return 0;
}
-int ftgmac100_phy_write(struct eth_device *dev, int addr, int reg, u16 value)
+int ftgmac100_phy_write(struct ftgmac100_data *priv, int addr, int reg,
+ u16 value)
{
- if (ftgmac100_mdiobus_write(dev, addr, reg, value) == -1)
+ if (ftgmac100_mdiobus_write(priv, addr, reg, value) == -1)
return -1;
return 0;
}
-static int ftgmac100_phy_reset(struct eth_device *dev)
+static int ftgmac100_phy_reset(struct ftgmac100_data *priv, struct udevice
*dev)
{
- struct ftgmac100_data *priv = dev->priv;
int i;
u16 status, adv;
adv = ADVERTISE_CSMA | ADVERTISE_ALL;
- ftgmac100_phy_write(dev, priv->phy_addr, MII_ADVERTISE, adv);
+ ftgmac100_phy_write(priv, priv->phy_addr, MII_ADVERTISE, adv);
printf("%s: Starting autonegotiation...\n", dev->name);
- ftgmac100_phy_write(dev, priv->phy_addr,
- MII_BMCR, (BMCR_ANENABLE | BMCR_ANRESTART));
+ ftgmac100_phy_write(priv, priv->phy_addr,
+ MII_BMCR, (BMCR_ANENABLE | BMCR_ANRESTART));
for (i = 0; i < 10 / 100; i++) {
- ftgmac100_phy_read(dev,
[U-Boot] [PATCH v5 02/13] net: ftgmac100: use the aligned() macro
Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
Acked-by: Joe Hershberger
---
drivers/net/ftgmac100.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ftgmac100.h b/drivers/net/ftgmac100.h
index 439b14d71e4b..9a789e4d5bee 100644
--- a/drivers/net/ftgmac100.h
+++ b/drivers/net/ftgmac100.h
@@ -182,7 +182,7 @@ struct ftgmac100_txdes {
unsigned inttxdes1;
unsigned inttxdes2; /* not used by HW */
unsigned inttxdes3; /* TXBUF_BADR */
-} __attribute__ ((aligned(16)));
+} __aligned(16);
#define FTGMAC100_TXDES0_TXBUF_SIZE(x) ((x) & 0x3fff)
#define FTGMAC100_TXDES0_EDOTR BIT(15)
@@ -208,7 +208,7 @@ struct ftgmac100_rxdes {
unsigned intrxdes1;
unsigned intrxdes2; /* not used by HW */
unsigned intrxdes3; /* RXBUF_BADR */
-} __attribute__ ((aligned(16)));
+} __aligned(16);
#define FTGMAC100_RXDES0_VDBC(x) ((x) & 0x3fff)
#define FTGMAC100_RXDES0_EDORR BIT(15)
--
2.17.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 01/13] net: ftgmac100: use the BIT() macro
Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
Acked-by: Joe Hershberger
---
drivers/net/ftgmac100.h | 154
1 file changed, 77 insertions(+), 77 deletions(-)
diff --git a/drivers/net/ftgmac100.h b/drivers/net/ftgmac100.h
index ffbe1f3e3fa7..439b14d71e4b 100644
--- a/drivers/net/ftgmac100.h
+++ b/drivers/net/ftgmac100.h
@@ -70,48 +70,48 @@ struct ftgmac100 {
/*
* Interrupt status register & interrupt enable register
*/
-#define FTGMAC100_INT_RPKT_BUF (1 << 0)
-#define FTGMAC100_INT_RPKT_FIFO(1 << 1)
-#define FTGMAC100_INT_NO_RXBUF (1 << 2)
-#define FTGMAC100_INT_RPKT_LOST(1 << 3)
-#define FTGMAC100_INT_XPKT_ETH (1 << 4)
-#define FTGMAC100_INT_XPKT_FIFO(1 << 5)
-#define FTGMAC100_INT_NO_NPTXBUF (1 << 6)
-#define FTGMAC100_INT_XPKT_LOST(1 << 7)
-#define FTGMAC100_INT_AHB_ERR (1 << 8)
-#define FTGMAC100_INT_PHYSTS_CHG (1 << 9)
-#define FTGMAC100_INT_NO_HPTXBUF (1 << 10)
+#define FTGMAC100_INT_RPKT_BUF BIT(0)
+#define FTGMAC100_INT_RPKT_FIFOBIT(1)
+#define FTGMAC100_INT_NO_RXBUF BIT(2)
+#define FTGMAC100_INT_RPKT_LOSTBIT(3)
+#define FTGMAC100_INT_XPKT_ETH BIT(4)
+#define FTGMAC100_INT_XPKT_FIFOBIT(5)
+#define FTGMAC100_INT_NO_NPTXBUF BIT(6)
+#define FTGMAC100_INT_XPKT_LOSTBIT(7)
+#define FTGMAC100_INT_AHB_ERR BIT(8)
+#define FTGMAC100_INT_PHYSTS_CHG BIT(9)
+#define FTGMAC100_INT_NO_HPTXBUF BIT(10)
/*
* Interrupt timer control register
*/
#define FTGMAC100_ITC_RXINT_CNT(x) (((x) & 0xf) << 0)
#define FTGMAC100_ITC_RXINT_THR(x) (((x) & 0x7) << 4)
-#define FTGMAC100_ITC_RXINT_TIME_SEL (1 << 7)
+#define FTGMAC100_ITC_RXINT_TIME_SEL BIT(7)
#define FTGMAC100_ITC_TXINT_CNT(x) (((x) & 0xf) << 8)
#define FTGMAC100_ITC_TXINT_THR(x) (((x) & 0x7) << 12)
-#define FTGMAC100_ITC_TXINT_TIME_SEL (1 << 15)
+#define FTGMAC100_ITC_TXINT_TIME_SEL BIT(15)
/*
* Automatic polling timer control register
*/
#define FTGMAC100_APTC_RXPOLL_CNT(x) (((x) & 0xf) << 0)
-#define FTGMAC100_APTC_RXPOLL_TIME_SEL (1 << 4)
+#define FTGMAC100_APTC_RXPOLL_TIME_SEL BIT(4)
#define FTGMAC100_APTC_TXPOLL_CNT(x) (((x) & 0xf) << 8)
-#define FTGMAC100_APTC_TXPOLL_TIME_SEL (1 << 12)
+#define FTGMAC100_APTC_TXPOLL_TIME_SEL BIT(12)
/*
* DMA burst length and arbitration control register
*/
#define FTGMAC100_DBLAC_RXFIFO_LTHR(x) (((x) & 0x7) << 0)
#define FTGMAC100_DBLAC_RXFIFO_HTHR(x) (((x) & 0x7) << 3)
-#define FTGMAC100_DBLAC_RX_THR_EN (1 << 6)
+#define FTGMAC100_DBLAC_RX_THR_EN BIT(6)
#define FTGMAC100_DBLAC_RXBURST_SIZE(x)(((x) & 0x3) << 8)
#define FTGMAC100_DBLAC_TXBURST_SIZE(x)(((x) & 0x3) << 10)
#define FTGMAC100_DBLAC_RXDES_SIZE(x) (((x) & 0xf) << 12)
#define FTGMAC100_DBLAC_TXDES_SIZE(x) (((x) & 0xf) << 16)
#define FTGMAC100_DBLAC_IFG_CNT(x) (((x) & 0x7) << 20)
-#define FTGMAC100_DBLAC_IFG_INC(1 << 23)
+#define FTGMAC100_DBLAC_IFG_INCBIT(23)
/*
* DMA FIFO status register
@@ -122,12 +122,12 @@ struct ftgmac100 {
#define FTGMAC100_DMAFIFOS_TXDMA1_SM(dmafifos) (((dmafifos) >> 12) & 0xf)
#define FTGMAC100_DMAFIFOS_TXDMA2_SM(dmafifos) (((dmafifos) >> 16) & 0x3)
#define FTGMAC100_DMAFIFOS_TXDMA3_SM(dmafifos) (((dmafifos) >> 18) & 0xf)
-#define FTGMAC100_DMAFIFOS_RXFIFO_EMPTY(1 << 26)
-#define FTGMAC100_DMAFIFOS_TXFIFO_EMPTY(1 << 27)
-#define FTGMAC100_DMAFIFOS_RXDMA_GRANT (1 << 28)
-#define FTGMAC100_DMAFIFOS_TXDMA_GRANT (1 << 29)
-#define FTGMAC100_DMAFIFOS_RXDMA_REQ (1 << 30)
-#define FTGMAC100_DMAFIFOS_TXDMA_REQ (1 << 31)
+#define FTGMAC100_DMAFIFOS_RXFIFO_EMPTYBIT(26)
+#define FTGMAC100_DMAFIFOS_TXFIFO_EMPTYBIT(27)
+#define FTGMAC100_DMAFIFOS_RXDMA_GRANT BIT(28)
+#define FTGMAC100_DMAFIFOS_TXDMA_GRANT BIT(29)
+#define FTGMAC100_DMAFIFOS_RXDMA_REQ BIT(30)
+#define FTGMAC100_DMAFIFOS_TXDMA_REQ BIT(31)
/*
* Receive buffer size register
@@ -137,26 +137,26 @@ struct ftgmac100 {
/*
* MAC control register
*/
-#define FTGMAC100_MACCR_TXDMA_EN (1 << 0)
-#define FTGMAC100_MACCR_RXDMA_EN (1 << 1)
-#define FTGMAC100_MACCR_TXMAC_EN (1 << 2)
-#define FTGMAC100_MACCR_RXMAC_EN (1 << 3)
-#define FTGMAC100_MACCR_RM_VLAN(1 << 4)
-#define FTGMAC100_MACCR_HPTXR_EN (1 << 5)
-#define FTGMAC100_MACCR_LOOP_EN(1 << 6)
-#define FTGMAC100_MACCR_ENRX_IN_HALFTX (1 << 7)
-#define FTGMAC100_MACCR_FULLDUP(1 << 8)
-#define FTGMAC100_MACCR_GIGA_MODE (1 << 9)
-#define FTGMAC100_MACCR_CRC_APD(1 << 10)
-#define FTGMAC100_MACCR_RX_RUNT(1 << 12)
-#define FTGMAC100_MACCR_JUMBO_LF (1 << 13)
-#define
[U-Boot] [PATCH v5 00/13] Support for the Faraday ftgmac100 controller
Hello, This series re-enables the Faraday ftgmac100 controller driver and its Aspeed variant as as one can find on the OpenPOWER platforms. The driver is largely reworked to support the driver model and also adds the MDIO bus and phylib support. It was tested on the AST2500 evb. Git tree available here: https://github.com/legoater/u-boot/commits/aspeed Thanks, C. Changes since v4 : - introduced a wait_for_bit macro to handle timeouts when transmitting Changes since v3 : It didn't seem necessary to remove the 'dev' argument from the ftgmac100_phy_init() and ftgmac100_phy_reset() function prototypes as the code is completely reworked in patch 5. - improved ftgmac100_mdio_init() and ftgmac100_phy_init() prototypes - introduced a ftgmac100_wait_for_txdone() function similar to the wait_for_bit_*() macros. Changes since v2 : - split changes in multiple patches to preserve git history, but the code has not changed since the reviewed v2 patchset. - included a couple more changes to sync the DTS file with Linux. Changes since v1 : - improved comments in the code - changed the type of 'iobase' to 'struct ftgmac100 *' to remove the casts in other routines. - replaced the loop in the mdio methods by a call to readl_poll_timeout() and fixed the returned value. - added a flush cache on the arrays of TX and RX descriptors in ftgmac100_start() - fixed returned value of - added a timer loop to catch transmit timeouts - introduced a clk_bulk - improved Kconfig description - introduced a udevice_id .data model - dropped is_aspeed bool - dropped MDIO interface setting for Aspeed SoC. The default is correct. - removed the clcoks which are now handled automatically in the ftgmac100 driver - introduced a fix for the D2-PLL clock setting Cédric Le Goater (13): net: ftgmac100: use the BIT() macro net: ftgmac100: use the aligned() macro net: ftgmac100: convert to driver model net: ftgmac100: use setbits_le32() in the reset method net: ftgmac100: add MDIO bus and phylib support net: ftgmac100: convert the RX/TX descriptor arrays net: ftgmac100: handle timeouts when transmitting net: ftgmac100: add clock support aspeed: ast2500: fix missing break in D2PLL clock enablement net: ftgmac100: Add support for the Aspeed SoC aspeed: Update ast2500 SoC DTS file to Linux v4.17-rc6 level aspeed: Activate ethernet devices on the ast2500 Eval Board aspeed: ast2500: fix D2-PLL clock setting in RGMII mode drivers/net/ftgmac100.h | 158 +-- include/netdev.h |1 - drivers/clk/aspeed/clk_ast2500.c | 39 + drivers/net/ftgmac100.c | 732 +-- arch/arm/dts/ast2500-evb.dts | 23 + arch/arm/dts/ast2500.dtsi| 1949 ++ configs/evb-ast2500_defconfig|8 + drivers/net/Kconfig | 26 + 8 files changed, 1707 insertions(+), 1229 deletions(-) -- 2.17.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/13] net: ftgmac100: handle timeouts when transmitting
Hello Joe,
On 10/22/18 9:55 PM, Joe Hershberger wrote:
> Hi Cedric,
>
> On Tue, Oct 16, 2018 at 4:32 AM Cédric Le Goater wrote:
>>
>> Signed-off-by: Cédric Le Goater
>> Reviewed-by: Joel Stanley
>> ---
>>
>> Changes since v3 :
>>
>> - introduced a ftgmac100_wait_for_txdone() function similar to the
>>wait_for_bit_*() macros.
>>
>> drivers/net/ftgmac100.c | 44 +
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
>> index bf8600814690..9adfe109ebc2 100644
>> --- a/drivers/net/ftgmac100.c
>> +++ b/drivers/net/ftgmac100.c
>> @@ -14,6 +14,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -28,6 +29,9 @@
>> /* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
>> #define PKTBUFSTX 4 /* must be power of 2 */
>>
>> +/* Timeout for transmit */
>> +#define FTGMAC100_TX_TIMEOUT_MS1000
>> +
>> /* Timeout for a mdio read/write operation */
>> #define FTGMAC100_MDIO_TIMEOUT_USEC1
>>
>> @@ -401,6 +405,41 @@ static int ftgmac100_recv(struct udevice *dev, int
>> flags, uchar **packetp)
>> return rxlen;
>> }
>>
>> +/*
>> + * The wait_for_bit_*() macros require a register value. This define a
>> + * similar routine which loops on the in-memory transmit descriptor to
>> + * wait for the MAC to clear the DMA_OWN bit.
>> + */
>> +static int ftgmac100_wait_for_txdone(struct ftgmac100_txdes *txdes,
>> +const unsigned int timeout_ms,
>> +const bool breakable)
>> +{
>
> I was hoping to see something like this instead:
>
> static u32 ftgmac100_read_txdesc(void *desc)
> {
> struct ftgmac100_txdes *txdes = desc;
> ulong des_start = (ulong)txdes;
> ulong des_end = des_start + roundup(sizeof(*txdes),
> ARCH_DMA_MINALIGN);
>
> invalidate_dcache_range(des_start, des_end);
>
> return txdes->txdes0;
> }
>
> BUILD_WAIT_FOR_BIT(ftgmac100_txdone, u32, ftgmac100_read_txdesc)
>
> [ ... ]
>
> ftgmac100_send( ... )
> {
> [ ... ]
>
> rc = wait_for_bit_ftgmac100_txdone(curr_des,
> FTGMAC100_TXDES0_TXDMA_OWN, false, FTGMAC100_TX_TIMEOUT_MS, true);
> if (rc)
> return rc;
>
> [ ... ]
> }
Yes, this is much better. A few other drivers could make use of a similar
macro.
Sending a v5 with the proposed change.
Thanks,
C.
>> + ulong des_start = (ulong)txdes;
>> + ulong des_end = des_start + roundup(sizeof(*txdes),
>> ARCH_DMA_MINALIGN);
>> + ulong start = get_timer(0);
>> +
>> + while (1) {
>> + invalidate_dcache_range(des_start, des_end);
>> +
>> + if (!(txdes->txdes0 & FTGMAC100_TXDES0_TXDMA_OWN))
>> + return 0;
>> +
>> + if (get_timer(start) > timeout_ms)
>> + break;
>> +
>> + if (breakable && ctrlc()) {
>> + puts("Abort\n");
>> + return -EINTR;
>> + }
>> +
>> + udelay(1);
>> + WATCHDOG_RESET();
>> + }
>> +
>> + dev_err(dev, "transmit timeout\n");
>> + return -ETIMEDOUT;
>> +}
>> +
>> /*
>> * Send a data block via Ethernet
>> */
>> @@ -414,6 +453,7 @@ static int ftgmac100_send(struct udevice *dev, void
>> *packet, int length)
>> roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN);
>> ulong data_start;
>> ulong data_end;
>> + int rc;
>>
>> invalidate_dcache_range(des_start, des_end);
>>
>> @@ -446,6 +486,10 @@ static int ftgmac100_send(struct udevice *dev, void
>> *packet, int length)
>> /* Start transmit */
>> writel(1, >txpd);
>>
>> + rc = ftgmac100_wait_for_txdone(curr_des, FTGMAC100_TX_TIMEOUT_MS,
>> true);
>> + if (rc)
>> + return rc;
>> +
>> debug("%s(): packet sent\n", __func__);
>>
>> /* Move to next descriptor */
>> --
>> 2.17.2
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
