Re: [U-Boot] [PATCH] mmc: implement SDHCI card detect
Hi Michal,
> -Original Message-
> From: Michal Simek
> Sent: 27 May 2019 06:53
> To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] mmc: implement SDHCI card detect
>
> On 23. 05. 19 15:54, Ibai Erkiaga wrote:
> > Card detect function implemented for SDHCI framework.
> >
> > Signed-off-by: Ibai Erkiaga
> > ---
> >
> > drivers/mmc/sdhci.c | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
> > e2bb90a..cb4db8d 100644
> > --- a/drivers/mmc/sdhci.c
> > +++ b/drivers/mmc/sdhci.c
> > @@ -390,6 +390,21 @@ static int sdhci_send_command(struct mmc *mmc,
> struct mmc_cmd *cmd,
> > return -ECOMM;
> > }
> >
> > +#if IS_ENABLED(CONFIG_DM_MMC)
> > +static int sdhci_get_cd(struct udevice *dev) {
> > + struct mmc *mmc = mmc_get_mmc_dev(dev); #else static int
> > +sdhci_get_cd(struct mmc *mmc) { #endif
> > + u32 state;
> > + struct sdhci_host *host = mmc->priv;
> > +
> > + state = sdhci_readl(host, SDHCI_PRESENT_STATE);
> > + return (state & SDHCI_CARD_PRESENT);
>
> This should be much more robust. It should at least handle cases where you
> have broken-cd, cd-gpios, cd-inverted cases.
> This code will likely work with boards which have CD connected properly but
> it is enabled for all which will cause a lot of issues.
>
You are right, this implementation is quite basic and the idea was just to get
rid-off the polling message for the golden use case (properly connected CD).
> If you want to add this functionality one by one then new Kconfig should be
> used but I am not big fan of that.
>
The broken-cd Kconfig is already in the MMC framework so I would say that you
can use this implementation if your CD is properly connected and just stay as
current implementation using CONFIG_MMC_BROKEN_CD.
> > +}
> > +
> > #if defined(CONFIG_DM_MMC) && defined(MMC_SUPPORTS_TUNING)
> static
> > int sdhci_execute_tuning(struct udevice *dev, uint opcode) { @@
> > -627,6 +642,7 @@ int sdhci_probe(struct udevice *dev) const struct
> > dm_mmc_ops sdhci_ops = {
> > .send_cmd = sdhci_send_command,
> > .set_ios= sdhci_set_ios,
> > + .get_cd = sdhci_get_cd,
> > #ifdef MMC_SUPPORTS_TUNING
> > .execute_tuning = sdhci_execute_tuning,
> > #endif
> > @@ -635,6 +651,7 @@ const struct dm_mmc_ops sdhci_ops = { static
> > const struct mmc_ops sdhci_ops = {
> > .send_cmd = sdhci_send_command,
> > .set_ios= sdhci_set_ios,
> > + .get_cd = sdhci_get_cd,
> > .init = sdhci_init,
> > };
> > #endif
> >
>
> Thanks,
> Michal
Thanks,
Ibai
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Kconfig: fix FIT offset prompt text
> -Original Message- > From: Marek Vasut > Sent: 15 May 2019 15:09 > To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de > Cc: Michal Simek ; Simon Glass ; > Masahiro Yamada ; Peng Fan > ; Chris Packham ; Jagan Teki > ; Stefan Roese > Subject: Re: [U-Boot][PATCH] Kconfig: fix FIT offset prompt text > > On 5/15/19 3:57 PM, Ibai Erkiaga wrote: > > The current prompt text for FIT external offset is identical to > > SYS_TEXT_BASE which might confuse the users. Provided more accurate > > description for the prompt text. > > > > Signed-off-by: Ibai Erkiaga > > --- > > > > Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Kconfig b/Kconfig > > index 91c1082..f490ee4 100644 > > --- a/Kconfig > > +++ b/Kconfig > > @@ -278,7 +278,7 @@ config FIT > > if FIT > > > > config FIT_EXTERNAL_OFFSET > > - hex "Text Base" > > + hex "FIT External Offset" > > "FIT external data offset" then ? > Fair enough, let me send an updated patch > > default 0x0 > > help > > This specifies a data offset in fit image. > > > > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: fix hvc call
Hi Tom > -Original Message- > From: Tom Rini > Sent: 15 March 2019 16:08 > To: Ibai Erkiaga Elorza > Cc: Alexander Graf ; u-boot@lists.denx.de; Sumit Garg > ; Heinrich Schuchardt ; Albert > Aribaud > Subject: Re: [U-Boot][PATCH v2] arm: fix hvc call > > On Fri, Mar 15, 2019 at 12:13:11PM +, Ibai Erkiaga Elorza wrote: > > Hi Alex, > > > > > -Original Message- > > > From: Alexander Graf > > > Sent: 25 February 2019 13:09 > > > To: Ibai Erkiaga Elorza > > > Cc: u-boot@lists.denx.de; Sumit Garg ; > > > Heinrich Schuchardt ; Tom Rini > > > ; Albert Aribaud > > > Subject: Re: [U-Boot][PATCH v2] arm: fix hvc call > > > > > > > > > > > > > Am 25.02.2019 um 02:11 schrieb Ibai Erkiaga > > elo...@xilinx.com>: > > > > > > > > HVC call makes use of 6 mandatory arguments rather than 7 in the > > > > same way as SMC calls. The 7th argument is optional (Client ID) > > > > for both HVC and SMC but is implemented as 16-bit parameter and > > > > register R7 or W7. The aim of this patch is just fix compilation > > > > error due to an invalid asm code in the HVC call so that's why the 7th > argument is removed. > > > > > > > > The issue does not report any error in a normal build as hvc_call > > > > is not used at all and is optimized by the compiler. Using -O0 > > > > triggers the error so the patch is intended to fix issues on a > > > > ongoing effor to build U-Boot with -O0. > > > > > > > > Signed-off-by: Ibai Erkiaga > > > > > > Reviewed-by: Alexander Graf > > > > Thanks for the review. Do I need to CC somebody else to the patch be > accepted? > > No, but I'm inclined currently to take for for the next release rather than > right > now, unless there's an important argument I'm missing? Which happens more > than I'd care to admit ;) > No rush, I'm pretty new contributor and just wondering if something else was missing after Alexander's Review. > -- > Tom Ibai ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: fix hvc call
Hi Alex, > -Original Message- > From: Alexander Graf > Sent: 25 February 2019 13:09 > To: Ibai Erkiaga Elorza > Cc: u-boot@lists.denx.de; Sumit Garg ; Heinrich > Schuchardt ; Tom Rini ; Albert > Aribaud > Subject: Re: [U-Boot][PATCH v2] arm: fix hvc call > > > > > Am 25.02.2019 um 02:11 schrieb Ibai Erkiaga elo...@xilinx.com>: > > > > HVC call makes use of 6 mandatory arguments rather than 7 in the same > > way as SMC calls. The 7th argument is optional (Client ID) for both > > HVC and SMC but is implemented as 16-bit parameter and register R7 or > > W7. The aim of this patch is just fix compilation error due to an > > invalid asm code in the HVC call so that's why the 7th argument is removed. > > > > The issue does not report any error in a normal build as hvc_call is > > not used at all and is optimized by the compiler. Using -O0 triggers > > the error so the patch is intended to fix issues on a ongoing effor to > > build U-Boot with -O0. > > > > Signed-off-by: Ibai Erkiaga > > Reviewed-by: Alexander Graf > Thanks for the review. Do I need to CC somebody else to the patch be accepted? > Alex > > > --- > > > > Changes in v2: > > - More comprehensive commit message > > > > arch/arm/cpu/armv8/fwcall.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c > > index 9957c29..b0aca1b 100644 > > --- a/arch/arm/cpu/armv8/fwcall.c > > +++ b/arch/arm/cpu/armv8/fwcall.c > > @@ -28,7 +28,6 @@ static void hvc_call(struct pt_regs *args) > >"ldr x4, %4\n" > >"ldr x5, %5\n" > >"ldr x6, %6\n" > > -"ldr x7, %7\n" > >"hvc#0\n" > >"str x0, %0\n" > >"str x1, %1\n" > > @@ -37,7 +36,7 @@ static void hvc_call(struct pt_regs *args) > >: "+m" (args->regs[0]), "+m" (args->regs[1]), > > "+m" (args->regs[2]), "+m" (args->regs[3]) > >: "m" (args->regs[4]), "m" (args->regs[5]), > > - "m" (args->regs[6]), "m" (args->regs[7]) > > + "m" (args->regs[6]) > >: "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7", > > "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15", > > "x16", "x17"); > > -- > > 1.8.3.1 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: check OF_LIVE is enabled
Hi Simon, > -Original Message- > From: Simon Glass > Sent: 10 March 2019 21:51 > To: Ibai Erkiaga Elorza > Cc: U-Boot Mailing List ; Patrick Delaunay > ; Andy Shevchenko > ; Bin Meng ; > Patrice Chotard > Subject: Re: [U-Boot][PATCH] dm: check OF_LIVE is enabled > > Hi Ibai, > > On Tue, 26 Feb 2019 at 02:26, Ibai Erkiaga > wrote: > > > > Livetree implemented functions does not have conditional compilation > > so check if CONFIG_IS_ENABLED prior using those functions. > > > > The issue does not report any error in a normal build as the toolchain > > optimize the code. Using -O0 triggers the error so the patch is > > intended to fix issues on a ongoing effor to build U-Boot with -O0. > > > > Signed-off-by: Ibai Erkiaga > > --- > > > > drivers/core/ofnode.c | 60 > > +- > > drivers/serial/serial-uclass.c | 2 +- > > 2 files changed, 31 insertions(+), 31 deletions(-) > > > > This is supposed to work by using of_live_active(), which is called from > ofnode_is_np(). Instead of changing all this code, is it possible to update > of_live_active() somehow? > I've been trying to figure out it but I think there is no way just changing of_live_active as the compiler does not discard branch statements with nested fixed return values. I was able to make it work just changing ofnode_is_np using pre-processor macro to set as false when OF_LIVE is not enabled, but not sure if it the right approach. I will take a deeper look to the entire OF code and maybe suggest a code refactoring. > Regards, > Simon Regards Ibai ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: arm64 32bit address relocation
Hi Udit > -Original Message- > From: Udit Kumar > Sent: 28 February 2019 09:07 > To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de > Cc: Tom Rini ; Albert Aribaud > ; Meenakshi Aggarwal > ; Stefan Roese ; Prabhakar > Kushwaha > Subject: RE: [U-Boot][PATCH] arm: arm64 32bit address relocation > > Hi Ibai > > > -Original Message- > > From: Ibai Erkiaga > > Sent: Wednesday, February 27, 2019 8:18 PM > > To: u-boot@lists.denx.de > > Cc: Ibai Erkiaga ; Udit Kumar > > ; Tom Rini ; Albert Aribaud > > ; Meenakshi Aggarwal > > ; Stefan Roese ; Prabhakar > > Kushwaha > > Subject: [U-Boot][PATCH] arm: arm64 32bit address relocation > > > > Current relocation code is limited to 21bit PC-relative addressing > > which might not be enough for bigger code sizes. The following patch > > increases the addressing to 32bit PC-relative. This feature is > > specially interesting if U-Boot is build without optimiation (-O0) as > > the text section is increased significativelly. > > > > Signed-off-by: Ibai Erkiaga > > --- > > > > arch/arm/lib/relocate_64.S | 19 --- > > 1 file changed, 12 insertions(+), 7 deletions(-) > > > > diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S > > index 7603f52..6e9658b 100644 > > --- a/arch/arm/lib/relocate_64.S > > +++ b/arch/arm/lib/relocate_64.S > > @@ -26,9 +26,10 @@ ENTRY(relocate_code) > > /* > > * Copy u-boot from flash to RAM > > */ > > - adr x1, __image_copy_start /* x1 <- Run > > &__image_copy_start */ > > - subsx9, x0, x1 /* x8 <- Run to copy offset */ > > - b.eqrelocate_done /* skip relocation */ > > + adrpx1, __image_copy_start /* x1 <- address bits > > [31:12] */ > > + add x1, x1, :lo12:__image_copy_start/* x1 <- address bits [11:00] > > */ > > + subsx9, x0, x1 /* x8 <- Run to copy offset */ > > Should be x9 in comments > The original comment was x8 so did not realize about it. Does take sense to change within my patch? Or should it be done in a different one? > > + b.eqrelocate_done /* skip relocation */ > > /* > > * Don't ldr x1, __image_copy_start here, since if the code is already > > * running at an address other than it was linked to, that > > instruction @@ -42,8 +43,10 @@ ENTRY(relocate_code) > > ldr x1, _TEXT_BASE /* x1 <- Linked > > &__image_copy_start */ > > subsx9, x0, x1 /* x9 <- Link to copy offset */ > > > > - adr x1, __image_copy_start /* x1 <- Run > > &__image_copy_start */ > > - adr x2, __image_copy_end/* x2 <- Run &__image_copy_end */ > > + adrpx1, __image_copy_start /* x1 <- address bits > > [31:12] */ > > + add x1, x1, :lo12:__image_copy_start/* x1 <- address bits [11:00] > > */ > > + adrpx2, __image_copy_end/* x2 <- address bits [31:12] > > */ > > + add x2, x2, :lo12:__image_copy_end /* x2 <- address bits > > [11:00] */ > > copy_loop: > > ldp x10, x11, [x1], #16 /* copy from source address [x1] */ > > stp x10, x11, [x0], #16 /* copy to target address [x0] */ > > @@ -54,8 +57,10 @@ copy_loop: > > /* > > * Fix .rela.dyn relocations > > */ > > - adr x2, __rel_dyn_start /* x2 <- Run &__rel_dyn_start */ > > - adr x3, __rel_dyn_end /* x3 <- Run &__rel_dyn_end */ > > + adrpx2, __rel_dyn_start /* x2 <- address bits [31:12] > > */ > > + add x2, x2, :lo12:__rel_dyn_start /* x2 <- address bits [11:00] > > */ > > + adrpx3, __rel_dyn_end /* x3 <- address bits [31:12] > > */ > > + add x3, x3, :lo12:__rel_dyn_end /* x3 <- address bits [11:00] > > */ > > fixloop: > > ldp x0, x1, [x2], #16 /* (x0,x1) <- (SRC location, fixup) */ > > ldr x4, [x2], #8/* x4 <- addend */ > > -- > > 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: fix hvc call
> -Original Message- > From: Alexander Graf > Sent: 19 February 2019 12:41 > To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de > Cc: Sumit Garg ; Heinrich Schuchardt > ; Tom Rini ; Albert Aribaud > > Subject: Re: [PATCH] arm: fix hvc call > > On 02/19/2019 08:38 AM, Ibai Erkiaga Elorza wrote: > > Hi Alexander, > > > >> -Original Message- > >> From: Alexander Graf > >> Sent: 18 February 2019 13:50 > >> To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de > >> Cc: Sumit Garg ; Heinrich Schuchardt > >> ; Tom Rini ; Albert Aribaud > >> > >> Subject: Re: [PATCH] arm: fix hvc call > >> > >> > >> > >> On 18.02.19 14:10, Ibai Erkiaga wrote: > >>> HVC call makes use of 6 arguments rather than 7 in the same way as > >>> SMC calls. The 7th argument is optional for both HVC and SMC but is > >>> implemented as 16-bit parameter and register R7 or W7. > >> The patch description is lacking a bit more context. Why not change > >> SMC to also include x7? > >> > > Definitively both approaches might be valid. The aim of the patch is just > avoid compilation error due to an invalid asm code in the HVC call so that's > why I'm removing the 7th argument. The Client ID (7th argument) could be > used either for SMC or HVC but I don't have a testcase for it and seems that > nobody is using up to date. > > All of the above should be mentioned in the commit message, so that > someone stumbling over the patch in 2 years will understand its rationale. > Ok , let me send v2 with a more comprehensive commit message. > > Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: fix hvc call
Hi Alexander, > -Original Message- > From: Alexander Graf > Sent: 18 February 2019 13:50 > To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de > Cc: Sumit Garg ; Heinrich Schuchardt > ; Tom Rini ; Albert Aribaud > > Subject: Re: [PATCH] arm: fix hvc call > > > > On 18.02.19 14:10, Ibai Erkiaga wrote: > > HVC call makes use of 6 arguments rather than 7 in the same way as SMC > > calls. The 7th argument is optional for both HVC and SMC but is > > implemented as 16-bit parameter and register R7 or W7. > > The patch description is lacking a bit more context. Why not change SMC to > also > include x7? > Definitively both approaches might be valid. The aim of the patch is just avoid compilation error due to an invalid asm code in the HVC call so that's why I'm removing the 7th argument. The Client ID (7th argument) could be used either for SMC or HVC but I don't have a testcase for it and seems that nobody is using up to date. > > > > Signed-off-by: Ibai Erkiaga > > --- > > The issue does not report any error in a normal build as hvc_call is > > not used at all and is optimized by the compiler. Using -O0 triggers > > the error so the patch is intended to fix issues on a ongoing effor to > > build U-Boot with -O0. > > This should definitely not go below the --- line as it's critical information > for > anyone who later on reads the commit message in the log. > > > Alex > > > > > arch/arm/cpu/armv8/fwcall.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c > > index 9957c29..b0aca1b 100644 > > --- a/arch/arm/cpu/armv8/fwcall.c > > +++ b/arch/arm/cpu/armv8/fwcall.c > > @@ -28,7 +28,6 @@ static void hvc_call(struct pt_regs *args) > > "ldr x4, %4\n" > > "ldr x5, %5\n" > > "ldr x6, %6\n" > > - "ldr x7, %7\n" > > "hvc#0\n" > > "str x0, %0\n" > > "str x1, %1\n" > > @@ -37,7 +36,7 @@ static void hvc_call(struct pt_regs *args) > > : "+m" (args->regs[0]), "+m" (args->regs[1]), > > "+m" (args->regs[2]), "+m" (args->regs[3]) > > : "m" (args->regs[4]), "m" (args->regs[5]), > > - "m" (args->regs[6]), "m" (args->regs[7]) > > + "m" (args->regs[6]) > > : "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7", > > "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15", > > "x16", "x17"); > > -- > > 1.8.3.1 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: Kconfig: SPL_LOAD_FIT_ADDRESS to Kconfig
> -Original Message-
> From: Michal Simek [mailto:mon...@monstr.eu]
> Sent: 08 June 2018 06:45
> To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] spl: Kconfig: SPL_LOAD_FIT_ADDRESS to
> Kconfig
>
> On 7.6.2018 14:29, Ibai Erkiaga wrote:
> > Create a new KConfig entry to define FIT image position for SPL RAM
> > mode.
> >
> > Signed-off-by: Ibai Erkiaga
> > ---
> >
> > Kconfig | 7 +++
> > common/spl/spl_ram.c | 4
> > scripts/config_whitelist.txt | 1 -
> > 3 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/Kconfig b/Kconfig
> > index 5a82c95..b619ccc 100644
> > --- a/Kconfig
> > +++ b/Kconfig
> > @@ -328,6 +328,13 @@ config SPL_LOAD_FIT
> > particular it can handle selecting from multiple device tree
> > and passing the correct one to U-Boot.
> >
> > +config SPL_LOAD_FIT_ADDRESS
> > + hex "SPL FIT Load Address"
> > + default 0x0
> > + depends on SPL_LOAD_FIT
> > + help
> > + Base address from where U-Boot FIT image will be loaded on
> > +SPL boot
> > +
> > config SPL_LOAD_FIT_FULL
> > bool "Enable SPL loading U-Boot as a FIT"
> > select SPL_FIT
> > diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c index
> > e870193..561d1c0 100644
> > --- a/common/spl/spl_ram.c
> > +++ b/common/spl/spl_ram.c
> > @@ -15,10 +15,6 @@
> > #include
> > #include
> >
> > -#ifndef CONFIG_SPL_LOAD_FIT_ADDRESS
> > -# define CONFIG_SPL_LOAD_FIT_ADDRESS 0
> > -#endif
> > -
> > static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
> >ulong count, void *buf) { diff --git
> > a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index
> > e99ba6b..037f038 100644
> > --- a/scripts/config_whitelist.txt
> > +++ b/scripts/config_whitelist.txt
> > @@ -1926,7 +1926,6 @@
> CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER
> > CONFIG_SPL_INIT_MINIMAL
> > CONFIG_SPL_JR0_LIODN_NS
> > CONFIG_SPL_JR0_LIODN_S
> > -CONFIG_SPL_LOAD_FIT_ADDRESS
>
> Tom is syncing this file time to time that's why you don't need to do it but
> of
> course you can.
>
Ok, I will keep it as it will reflect more accurately until Tom clean-ups it.
> Also please convert zynqmp and dra7xx_evm defconfigs.
>
I guess that means to add this define on each single defconfig that is
currently using the header, isn't it?
> > CONFIG_SPL_MAX_FOOTPRINT
> > CONFIG_SPL_MAX_PEB_SIZE
> > CONFIG_SPL_MAX_SIZE
> > --
> > 1.8.3.1
> >
> > This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
> recipient, do not read, copy, or forward this email message or any
> attachments. Delete this email message and any attachments immediately.
>
> you really need to get rid of this.
>
I was not even aware that I was adding it (I guess email provider does it
automatically), let see if I can remove it.
> Thanks,
> Michal
>
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel -
> Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx
> Microblaze/Zynq/ZynqMP SoCs
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: zynq: Add initial support for Avnet MiniZed
Hi Michal,
> -Original Message-
> From: Michal Simek [mailto:michal.si...@xilinx.com]
> Sent: 10 May 2018 09:21
> To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de
> Cc: michal.si...@xilinx.com
> Subject: Re: [PATCH v2] arm: zynq: Add initial support for Avnet MiniZed
>
> On 9.5.2018 17:56, Ibai Erkiaga wrote:
> > Initial support for Avnet MiniZed board. Tested UART1 (serial
> > console), QSPI(Flash), SDHCI1 (eMMC), USB.
> >
> > Signed-off-by: Ibai Erkiaga
> > ---
> > Changes for v2:
> > -board model changed to use Avent prefix
> > -usb phy driver changed usb-no-xceiv
> > -removed gpio and intc binding
> > -fixed-partitions usage
> > ---
> > U-Boot 2018.05-00023-gdf332c1-dirty (May 09 2018 - 14:50:51 +0100)
> >
> > Model: Avnet Zynq MiniZed Development Board
> > Board: Xilinx Zynq
> > Silicon: v3.1
> > DRAM: ECC disabled 512 MiB
> > MMC: sdhci@e0101000: 0
> > Loading Environment from SPI Flash... SF: Detected n25q128 with page
> > size 256 Bytes, erase size 64 KiB, total 16 MiB OK
> > In:serial@e0001000
> > Out: serial@e0001000
> > Err: serial@e0001000
> > Net: No ethernet found.
> > Hit any key to stop autoboot: 0
> > Zynq> fatls mmc 0
> > 16783864 image.ub
> > 183 wpa_supplicant.conf
> > 1391116 smallboot.bin
> >
> > 3 file(s), 0 dir(s)
> >
> > Zynq> sf probe 0 0 0
> > SF: Detected n25q128 with page size 256 Bytes, erase size 64 KiB,
> > total 16 MiB
> > Zynq> usb start
> > starting USB...
> > USB0: USB EHCI 1.00
> > scanning bus 0 for devices... 2 USB Device(s) found
> >scanning usb for storage devices... 1 Storage Device(s) found
> > Zynq> fatls usb 0
> >12 test.txt
> >
> > 1 file(s), 0 dir(s)
> >
> > Zynq>
> > ---
> > arch/arm/dts/Makefile |1 +
> > arch/arm/dts/zynq-minized.dts | 104
>
> > configs/zynq_minized_defconfig | 68 ++
> > 3 files changed, 173 insertions(+), 0 deletions(-) create mode
> > 100644 arch/arm/dts/zynq-minized.dts create mode 100644
> > configs/zynq_minized_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> > 6fe93a8..5c5f8a8 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -129,6 +129,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
> > zynq-cc108.dtb \
> > zynq-cse-qspi-single.dtb \
> > zynq-microzed.dtb \
> > + zynq-minized.dtb \
> > zynq-picozed.dtb \
> > zynq-syzygy-hub.dtb \
> > zynq-topic-miami.dtb \
> > diff --git a/arch/arm/dts/zynq-minized.dts
> > b/arch/arm/dts/zynq-minized.dts new file mode 100644 index
> > 000..68fe09a
> > --- /dev/null
> > +++ b/arch/arm/dts/zynq-minized.dts
> > @@ -0,0 +1,104 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * dts file for Avnet MiniZed board
> > + *
> > + * (C) Copyright 2017 - 2018, Xilinx, Inc.
> > + *
> > + * Ibai Erkiaga */
> > +
> > +/dts-v1/;
> > +#include "zynq-7000.dtsi"
> > +
> > +/ {
> > + model = "Avnet Zynq MiniZed Development Board";
> > + compatible = "avnet,minized", "xlnx,zynq-7000";
> > +
> > + aliases {
> > + serial0 = &uart1;
> > + serial1 = &uart0;
> > + spi0 = &qspi;
> > + mmc0 = &sdhci0;
> > + };
> > +
> > + memory@0 {
> > + device_type = "memory";
> > + reg = <0x0 0x2000>;
> > + };
> > +
> > + chosen {
> > + bootargs = "";
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + usb_phy0: phy0 {
> > + compatible = "usb-nop-xceiv";
> > + #phy-cells = <0>;
> > + };
> > +};
> > +
> > +&qspi {
> > + status = "okay";
> > + is-dual = <0>;
> > + num-cs = <1>;
> > + flash@0 {
> > + compatible = "micron,m25p128";
> > + reg = <0x0>;
> > + spi-tx-bus-width = <4>;
> > + spi-rx-bus-width = <4>;
> > + spi-max-frequency = <5000>;
> > + partitions {
> > + compatible = "fixed-partitions";
> > + #address-cells
