Re: [U-Boot] sdhci - review?

[Jaehoon Chung]

On 11/20/2017 09:52 PM, Jorge Ramirez wrote:
> On 11/10/2017 01:29 PM, Jorge Ramirez wrote:
>> On 11/07/2017 11:48 PM, Tom Rini wrote:
>>> On Tue, Nov 07, 2017 at 08:13:02AM +0100, Jorge Ramirez wrote:
 On 11/07/2017 12:28 AM, Tom Rini wrote:
> Hey all,
>
> It's release day and v2017.11-rc4 is out.  It's a week until release
> day.  Please let me know if you know of any regressions, thanks!
 Hi Tom,

 emmc accesses are broken for dragonboard410c
 I posted the fix [1] last week. will you merge it?
>>
>> just changed the email subject
>>
>>> [1] is: https://patchwork.ozlabs.org/patch/833376/
>>>
>>> Jaehoon, are you OK with this patch?  Thanks!
>>>
>>
> 
> a ping on this matter - as the db410c maintainer a quick reminder that the 
> emmc support remains broken until this (above [1]) (or an alternative fix) is 
> merged.

I sent the email to Tom about 1 weeks ago..if it doesn't apply yet, i will pick 
it..
Maybe i had replied with the my gmail account, something missed.

Sorry.

> 
> 
> 

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

Re: [U-Boot] [PATCH 2/5] mmc: dm: support "mmc-ddr-1_2v" and "mmc-hs200-1_2v" boolean properties

[Lukasz Majewski]

On Tue, 21 Nov 2017 16:13:05 +0100
Jean-Jacques Hiblot  wrote:

> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc-uclass.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 48fafce..9723129 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -161,8 +161,12 @@ int mmc_of_parse(const void *fdt, int node,
> struct mmc_config *cfg) cfg->host_caps |= MMC_CAP(UHS_DDR50);
>   if (fdtdec_get_bool(fdt, node, "mmc-ddr-1_8v"))
>   cfg->host_caps |= MMC_CAP(MMC_DDR_52);
> + if (fdtdec_get_bool(fdt, node, "mmc-ddr-1_2v"))
> + cfg->host_caps |= MMC_CAP(MMC_DDR_52);
>   if (fdtdec_get_bool(fdt, node, "mmc-hs200-1_8v"))
>   cfg->host_caps |= MMC_CAP(MMC_HS_200);
> + if (fdtdec_get_bool(fdt, node, "mmc-hs200-1_2v"))
> + cfg->host_caps |= MMC_CAP(MMC_HS_200);
>  
>   return 0;
>  }

Reviewed-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


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

Re: [U-Boot] [PATCH 3/5] mmc: dump card and host capabilities if debug is enabled

[Lukasz Majewski]

On Tue, 21 Nov 2017 16:13:06 +0100
Jean-Jacques Hiblot  wrote:

> This is a useful information while debugging the initialization
> process or performance issues.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index a5a521e..a30b6a2 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1502,6 +1502,10 @@ void mmc_dump_capabilities(const char *text,
> uint caps) printf("%s, ", mmc_mode_name(mode));
>   printf("\b\b]\n");
>  }
> +#else
> +void mmc_dump_capabilities(const char *text, uint caps)
> +{
> +}
>  #endif
>  
>  struct mode_width_tuning {
> @@ -1582,6 +1586,8 @@ static int sd_select_mode_and_width(struct mmc
> *mmc, uint card_caps) bool uhs_en = (mmc->ocr & OCR_S18R) ? true :
> false; uint caps;
>  
> + mmc_dump_capabilities("sd card", card_caps);
> + mmc_dump_capabilities("host", mmc->host_caps |
> MMC_MODE_1BIT); 
>   /* Restrict card's capabilities by what the host can do */
>   caps = card_caps & (mmc->host_caps | MMC_MODE_1BIT);
> @@ -1764,6 +1770,9 @@ static int mmc_select_mode_and_width(struct mmc
> *mmc, uint card_caps) const struct mode_width_tuning *mwt;
>   const struct ext_csd_bus_width *ecbw;
>  
> + mmc_dump_capabilities("mmc", card_caps);
> + mmc_dump_capabilities("host", mmc->host_caps |
> MMC_MODE_1BIT); +
>   /* Restrict card's capabilities by what the host can do */
>   card_caps &= (mmc->host_caps | MMC_MODE_1BIT);
>  

Reviewed-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


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

Re: [U-Boot] [PATCH 5/5] mmc: all hosts support 1-bit bus width and legacy timings

[Lukasz Majewski]

On Tue, 21 Nov 2017 16:13:08 +0100
Jean-Jacques Hiblot  wrote:

> Make sure that those basic capabilities are advertised by the host.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 67f21ff..ec1dc49 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1587,10 +1587,10 @@ static int sd_select_mode_and_width(struct
> mmc *mmc, uint card_caps) uint caps;
>  
>   mmc_dump_capabilities("sd card", card_caps);
> - mmc_dump_capabilities("host", mmc->host_caps |
> MMC_MODE_1BIT);
> + mmc_dump_capabilities("host", mmc->host_caps);
>  
>   /* Restrict card's capabilities by what the host can do */
> - caps = card_caps & (mmc->host_caps | MMC_MODE_1BIT);
> + caps = card_caps & mmc->host_caps;
>  
>   if (!uhs_en)
>   caps &= ~UHS_CAPS;
> @@ -1771,10 +1771,10 @@ static int mmc_select_mode_and_width(struct
> mmc *mmc, uint card_caps) const struct ext_csd_bus_width *ecbw;
>  
>   mmc_dump_capabilities("mmc", card_caps);
> - mmc_dump_capabilities("host", mmc->host_caps |
> MMC_MODE_1BIT);
> + mmc_dump_capabilities("host", mmc->host_caps);
>  
>   /* Restrict card's capabilities by what the host can do */
> - card_caps &= (mmc->host_caps | MMC_MODE_1BIT);
> + card_caps &= mmc->host_caps;
>  
>   /* Only version 4 of MMC supports wider bus widths */
>   if (mmc->version < MMC_VERSION_4)
> @@ -2389,7 +2389,12 @@ int mmc_start_init(struct mmc *mmc)
>   bool uhs_en = supports_uhs(mmc->cfg->host_caps);
>   int err;
>  
> - mmc->host_caps = mmc->cfg->host_caps;
> + /*
> +  * all hosts are capable of 1 bit bus-width and able to use
> the legacy
> +  * timings.
> +  */
> + mmc->host_caps = mmc->cfg->host_caps | MMC_CAP(SD_LEGACY) |
> +  MMC_CAP(MMC_LEGACY) | MMC_MODE_1BIT;
>  
>   /* we pretend there's no card when init is NULL */
>   no_card = mmc_getcd(mmc) == 0;

Reviewed-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


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

Re: [U-Boot] [PATCH 4/5] mmc: Fixed a problem with old sd or mmc that do not support High speed

[Lukasz Majewski]

On Tue, 21 Nov 2017 16:13:07 +0100
Jean-Jacques Hiblot  wrote:

> As the legacy modes were not added to the list of supported modes, old
> cards that do not support other modes could not be used.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index a30b6a2..67f21ff 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -818,7 +818,7 @@ static int mmc_get_capabilities(struct mmc *mmc)
>   u8 *ext_csd = mmc->ext_csd;
>   char cardtype;
>  
> - mmc->card_caps = MMC_MODE_1BIT;
> + mmc->card_caps = MMC_MODE_1BIT | MMC_CAP(MMC_LEGACY);
>  
>   if (mmc_host_is_spi(mmc))
>   return 0;
> @@ -1171,7 +1171,7 @@ static int sd_get_capabilities(struct mmc *mmc)
>   int timeout;
>   u32 sd3_bus_mode;
>  
> - mmc->card_caps = MMC_MODE_1BIT;
> + mmc->card_caps = MMC_MODE_1BIT | MMC_CAP(SD_LEGACY);
>  
>   if (mmc_host_is_spi(mmc))
>   return 0;

Reviewed-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


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

Re: [U-Boot] [PATCH 1/1] ubifs: avoid possible NULL dereference

[Ladislav Michl]

On Wed, Nov 22, 2017 at 09:09:36AM +0100, Wolfgang Denk wrote:
> Dear Ladislav,
> 
> In message <2017112121.ryicwv6tyh5rye2e@lenoch> you wrote:
> > > > 
> > > > diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
> > > > index 4465523d5f..313dee0579 100644
> > > > --- a/fs/ubifs/ubifs.c
> > > > +++ b/fs/ubifs/ubifs.c
> > > > @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, 
> > > > char *dirname,
> > > > dir = kzalloc(sizeof(struct inode), 0);
> > > > if (!file || !dentry || !dir) {
> > > > printf("%s: Error, no memory for malloc!\n", __func__);
> > > > -   err = -ENOMEM;
> > > > -   goto out;
> > > > +   goto out_nomem;
> > > > }
> ...
> > > Should you not keep the "err = -ENOMEM;" setting?  Otherwise there
> > > is no indivcation that an error happened.
> > 
> > It is not obvious from the patch, but value of err is later discarded.
> > It serves sole purpose of printing debug notice.
> 
> So apparently we have a number of places in U-Boot where fatal
> errors (running out of memory) are just ignored and we continue as
> if nothing happened?

While I have to admit this code is not an example of clean coding,
it prints notice when trying to manipulate with file.

fs/ubifs/ubifs.c as whole needs to be revisited, above patch just
caused shit hitting the fan.

> THis is short-sighted at best. One day Pump Six will fail.
> 
> This is giving me the creepes. 

I was just pointing to the fact, that above mentioned patch does not
make it any worse. Btw, initial commit is even more amazing:

+   if (file)
+   free(file);
+   if (dentry)
+   free(dentry);
+   if (dir)
+   free(dir);
+
+   if (file->private_data)
+   kfree(file->private_data);
+   file->private_data = NULL;
+   file->f_pos = 2;
+   return 0;

.oO(I guess it is safe not pointing where above snippet is comming from,
but will review whole file as I'm going to use it for new board I have to
suport)

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

Re: [U-Boot] U-Boot proper(not SPL) relocate option

[Lukasz Majewski]

Hi Kever,

> Hi Lukasz,
> 
> 
>  Thanks for your quick comments on this topic.
> On 11/21/2017 06:29 PM, Lukasz Majewski wrote:
> > Hi Kever,
> >  
> >> Hi Guys,
> >>
> >>   I try to understand why we need to do the relocate in U-Boot.
> >>   From the document README/crt0.S, I think the relocation feature
> >> comes from some SoC have limited SRAM whose size is enough to load
> >> the whole U-Boot, but not enough to run all the drivers.
> >>
> >>   I don't know how many SoCs/Archs still must use this feature,
> >> but I'm sure all
> >> Rockchip SoCs do not need this feature in both SPL and proper
> >> U-Boot, because rockchip using SPL always running in SRAM to init
> >> DDR SDRAM, and after DRAM available always running U-Boot in
> >> DRAM.  
> > I always thought that u-boot needs relocation to place itself in the
> > "known" area of SDRAM (which ends in its very end).  
> 
> I can understand this feature, we always do dram_init_banks() first,
> then we relocate to 'known' area, then will be no risk to access
> memory. I believe there must be some historical reason for some kind
> of device, the relocate feature is a wonderful idea for it.
> 
> In another case, we can also have a choice for not relocate because:
> - we still can have similar 'bdinfo' but without relocate, we can
> init dram info
>  first, and then init SP, malloc area and so on, and then other 
> driver init.
> - All solution for Rockchip SoCs at least have 512MByte DRAM,

As I've written in the other mail - in some scenarios we don't want to
have fragmented memory (e.g. rootfs flashing).

Would this "fragmented" 512 MiB enough to flash all your binaries?

>  which should be enough for U-Boot and could consider to be
> 'known' area,
>  many other SoCs should be similar.
> - Without relocate we can save many step, some of our customer really
>  care much about the boot time duration.
>  * no need to relocate everything
>  * no need to copy all the code
>  * no need init the driver more than once

I do find your arguments perfectly valid (as in the end customer
decides what features are in u-boot).

Please prepare patches and send them for review.

> 
> Thanks,
> - Kever
> >
> > In this way we can upload u-boot proper via SPL to any SDRAM
> > location and then (after relocation) it puts itself to "known"
> > location.
> >
> > (Please check bdinfo command for details).
> >
> > Having u-boot at known location helps with:
> >
> > - Using the non fragmented SDRAM to download updates
> >
> > - Booting u-boot on many different devices (with different amount of
> >RAM) -> you always download u-boot in the near of SDRAM
> > beginning and then it relocates itself appropriately.
> >
> >
> > However, I'm not sure if we would need relocation in SPL (which
> > runs in SRAM). It seems to me that SPL binary is so board specific,
> > that we shouldn't need such generic feature there.
> >  
> >> There is a CONFIG_SPL_SKIP_RELOCATE for SPL to skip the relocate,
> >> can we have another CONFIG_SKIP_RELOCATE for U-Boot proper?
> >>
> >>
> >> Here is the document from README:
> >>
> >> board_init_f():
> >>   - purpose: set up the machine ready for running
> >> board_init_r(): i.e. SDRAM and serial UART
> >>   - global_data is available
> >>   - stack is in SRAM
> >>   - BSS is not available, so you cannot use global/static
> >> variables, only stack variables and global_data
> >>
> >>   Non-SPL-specific notes:
> >>   - dram_init() is called to set up DRAM. If already done
> >> in SPL this
> >>   can do nothing
> >>
> >>   SPL-specific notes:
> >>   - you can override the entire board_init_f() function
> >> with your own version as needed.
> >>   - preloader_console_init() can be called here in extremis
> >>   - should set up SDRAM, and anything needed to make the
> >> UART work
> >>   - these is no need to clear BSS, it will be done by
> >> crt0.S
> >>   - must return normally from this function (don't call
> >> board_init_r()
> >>   directly)
> >>
> >> board_init_r():
> >>   - purpose: main execution, common code
> >>   - global_data is available
> >>   - SDRAM is available
> >>   - BSS is available, all static/global variables can be
> >> used
> >>   - execution eventually continues to main_loop()
> >>
> >>   Non-SPL-specific notes:
> >>   - U-Boot is relocated to the top of memory and is now
> >> running from there.
> >>
> >>   SPL-specific notes:
> >>   - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is
> >> defined and
> >>   CONFIG_SPL_STACK_R_ADDR points into SDRAM
> >>   - preloader_console_init() can be called here - typically
> >> this is done by selecting CONFIG_SPL_BOARD_INIT and then
> >> supplying a
> >>   spl_board_init() function containing this call
> >>  

Re: [U-Boot] [PATCH] spl: make CONFIG_OF_EMBED pass dts through fdtgrep

[Lukasz Majewski]

Hi Simon,

> Hi Lukasz
> 
> > > Building spl with CONFIG_OF_EMBED enabled results in an error
> > > message  
> > ^^^ - is the CONFIG_OF_EMBED a
> > standard feature for SPL?  
> 
> Well, it's not really a standard feature I want to use in my final
> product. But if I want to debug SPL or U-Boot on my socfpga (using
> ARM's DS-5 for Altera), I need the device tree to be included in the
> binary that the debugger downloads to the target.
> 
> That's what CONFIG_OF_EMBED is for, right? I even need this to debug
> U-Boot, as the standard procedure for my target is to first start SPL
> via the debugger, halt at a specific hardware breakpoint and the load
> U-Boot which I want to debug.
> 
> > > on my board: "SPL image too big". This is because the fdtgrep
> > > build step is only executed for CONFIG_OF_SEPARATE.  
> > 
> > So the problem is with not enough runs of dtb stripping?  
> 
> No, the problem that the dtb is not stripped at all for
> CONFIG_OF_EMBED. The only thing that is stripped is
> 'spl/u-boot-spl.dtb' which is only created for CONFIG_OF_SEPARATE.

Thanks for detailed explanation.

> 
> >   
> > >
> > > Fix this by moving the fdtgrep build step ('cmd_fdtgreo') from
> > > scripts/Makefile.spl to dts/Makefile so that the reduced dtb is
> > > available for all kinds of spl builds.  
> > 
> > Ok.
> >   
> > >
> > > The resulting variable name for the embedded device tree blob
> > > changes, too, which is why common.h and fdtdec.c have tiny
> > > changes.
> > >
> > > Signed-off-by: Simon Goldschmidt
> > >  ---
> > >  dts/Makefile | 35 +++
> > >  include/common.h |  1 +
> > >  lib/fdtdec.c |  4 
> > >  scripts/Makefile.spl | 20 ++--
> > >  4 files changed, 38 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/dts/Makefile b/dts/Makefile index
> > > 3a93dafb51..c9b2a89441 100644
> > > --- a/dts/Makefile
> > > +++ b/dts/Makefile
> > > @@ -22,10 +22,29 @@ DTB := $(ARCH_PATH)/$(DEVICE_TREE).dtb
> > > dtb_depends += $(DTB:.dtb=.dts)  endif
> > >
> > > +# Pass the original device tree file through fdtgrep twice. The
> > > first pass +# removes any unwanted nodes (i.e. those which don't
> > > have the +# 'u-boot,dm-pre-reloc' property and thus are not
> > > needed by SPL. The second +# pass removes various unused
> > > properties from the remaining nodes. +# The output is typically a
> > > much smaller device tree file. +ifeq ($(CONFIG_TPL_BUILD),y)
> > > +fdtgrep_props := -b u-boot,dm-pre-reloc -b u-boot,dm-tpl else
> > > +fdtgrep_props := -b u-boot,dm-pre-reloc -b u-boot,dm-spl endif
> > > +quiet_cmd_fdtgrep = FDTGREP $@
> > > +  cmd_fdtgrep = $(objtree)/tools/fdtgrep $(fdtgrep_props)
> > > -RT $< \
> > > + -n /chosen -n /config -O dtb | \
> > > + $(objtree)/tools/fdtgrep -r -O dtb - -o $@ \
> > > + $(addprefix -P ,$(subst
> > > $\",,$(CONFIG_OF_SPL_REMOVE_PROPS))) +
> > > +$(obj)/dt-spl.dtb: $(DTB) $(objtree)/tools/fdtgrep FORCE
> > > + $(call if_changed,fdtgrep)
> > > +
> > >  $(obj)/dt.dtb: $(DTB) FORCE
> > >   $(call if_changed,shipped)
> > >
> > > -targets += dt.dtb
> > > +targets += dt.dtb dt-spl.dtb
> > >
> > >  $(DTB): $(dtb_depends)
> > >  ifeq ($(EXT_DTB),)
> > > @@ -42,14 +61,22 @@ endif
> > >  arch-dtbs:
> > >   $(Q)$(MAKE) $(build)=$(ARCH_PATH) dtbs
> > >
> > > -.SECONDARY: $(obj)/dt.dtb.S
> > > +.SECONDARY: $(obj)/dt.dtb.S $(obj)/dt-spl.dtb.S
> > >
> > > +
> > > +ifeq ($(CONFIG_SPL_BUILD),y)
> > > +obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o # support "out-of-tree"
> > > build +for dtb-spl
> > > +$(obj)/dt-spl.dtb.o: $(obj)/dt-spl.dtb.S FORCE
> > > + $(call if_changed_dep,as_o_S)
> > > +else
> > >  obj-$(CONFIG_OF_EMBED) := dt.dtb.o
> > > +endif
> > >
> > > -dtbs: $(obj)/dt.dtb
> > > +dtbs: $(obj)/dt.dtb $(obj)/dt-spl.dtb
> > >   @:
> > >
> > > -clean-files := dt.dtb.S
> > > +clean-files := dt.dtb.S dt-spl.dtb.S
> > >
> > >  # Let clean descend into dts directories
> > >  subdir-
> > > += ../arch/arm/dts ../arch/microblaze/dts ../arch/mips/dts
> > > +../arch/sandbox/dts ../arch/x86/dts
> > > diff --git a/include/common.h b/include/common.h index
> > > e14e1daa88..6e24545178 100644 --- a/include/common.h
> > > +++ b/include/common.h
> > > @@ -201,6 +201,7 @@ int last_stage_init(void);  extern ulong
> > > monitor_flash_len;  int mac_read_from_eeprom(void);
> > >  extern u8 __dtb_dt_begin[];  /* embedded device tree blob
> > > */ +extern u8 __dtb_dt_spl_begin[];   /* embedded device
> > > tree blob for SPL/TPL */ int set_cpu_clk_info(void);  int
> > > mdm_init(void);  int print_cpuinfo(void); diff --git
> > > a/lib/fdtdec.c b/lib/fdtdec.c index 45f3fe7baf..0eb0b92261 100644
> > > --- a/lib/fdtdec.c
> > > +++ b/lib/fdtdec.c
> > > @@ -1266,7 +1266,11 @@ int fdtdec_setup(void)  # endif  # ifdef
> > > CONFIG_OF_EMBED
> > >   /* Get a pointer to the FDT */
> > > +#  ifdef CONFIG_SPL_BUILD
> > > + gd->fdt_blob = __dtb_dt_spl_begin;
> > > +#  

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

[Dr. Philipp Tomsich]

Tom,

Please pull from u-boot-rockchip/master. 
The associated Travis run (prior to a final rebase) is at 
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/305523168.

Thanks,
Philipp.


The following changes since commit 16fa2eb95172e63820ee5f3d4052f3362a6de84e:

  ARM: dra7: Kconfig: Add thermal configs for dra7xx and am57xx (2017-11-21 
08:03:39 -0500)

are available in the git repository at:

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

for you to fetch changes up to 08790230fe80d46ff6368e0dc1e1be500ca3c4bf:

  rockchip: remove duplicate CONFIG_ENV_SIZE definitions (2017-11-21 23:57:24 
+0100)


Andy Yan (3):
  rockchip: make boot_mode related codes reused across all platforms
  rockchip: add support for enter to bootrom download mode
  rockchip: check download key before bootup

Heinrich Schuchardt (1):
  rockchip: spi: the symbol for Hertz is Hz

Kever Yang (5):
  rockchip: boot0: align to 0x20 for armv7 '_start'
  rockchip: mkimage: use spl_boot0 for all Rockchip SoCs
  rockchip: rk3288: use aligned address for SPL_TEXT_BASE
  rockchip: sysreset: merge into one common driver
  rockchip: clock: update sysreset driver binding

Philipp Tomsich (17):
  arm: boot0 hook: move boot0 hook before '_start'
  rockchip: enable boot0-hook for all Rockchip SoCs
  rockchip: rk3036: use aligned address for SPL_TEXT_BASE
  socfpga: boot0 hook: adjust to unified boot0 semantics
  bcm235xx: boot0 hook: adjust to unified boot0 semantics
  bcm281xx: boot0 hook: adjust to unified boot0 semantics
  rockchip: boot0 hook: support early return for RK3188/RK3066-style BROM
  arm: make save_boot_params_ret prototype visible for AArch64
  arm: mark save_boot_params_ret as a function
  arm: provide a PCS-compliant setjmp implementation
  rockchip: back-to-bootrom: replace assembly-implementation with C-code
  rockchip: rk3188: use boot0 hook to load up SPL in 2 steps
  rockchip: back-to-bootrom: allow passing a cmd to the bootrom
  rockchip: rk3188: move CONFIG_SPL_* entries from rk3188_common.h to 
Kconfig
  rockchip: mkimage: remove unused code-paths (spl_boot0 is now implied)
  rockchip: sysreset: update Makefile to work with merged sysreset driver
  rockchip: remove duplicate CONFIG_ENV_SIZE definitions

 arch/arm/Kconfig   |  1 +
 arch/arm/cpu/armv7/start.S |  1 +
 arch/arm/include/asm/arch-bcm235xx/boot0.h |  2 ++
 arch/arm/include/asm/arch-bcm281xx/boot0.h |  2 ++
 arch/arm/include/asm/arch-rockchip/boot0.h | 38 
++
 arch/arm/include/asm/arch-rockchip/boot_mode.h |  6 ++
 arch/arm/include/asm/arch-rockchip/bootrom.h   | 30 
+++---
 arch/arm/include/asm/arch-rockchip/clock.h |  5 +
 arch/arm/include/asm/setjmp.h  | 94 
+-
 arch/arm/include/asm/system.h  | 62 
+++---
 arch/arm/lib/Makefile  |  6 ++
 arch/arm/lib/setjmp.S  | 37 
+
 arch/arm/lib/setjmp_aarch64.S  | 42 
++
 arch/arm/lib/vectors.S | 54 
+++---
 arch/arm/mach-rockchip/Kconfig | 55 
+++
 arch/arm/mach-rockchip/Makefile| 11 ---
 arch/arm/mach-rockchip/boot_mode.c | 76 

 arch/arm/mach-rockchip/bootrom.c   | 97 
+++--
 arch/arm/mach-rockchip/rk3036-board-spl.c  |  2 +-
 arch/arm/mach-rockchip/rk3036-board.c  | 24 
 arch/arm/mach-rockchip/rk3188-board-spl.c  | 14 ++
 arch/arm/mach-rockchip/rk3188-board-tpl.c  | 86 
--
 arch/arm/mach-rockchip/rk3188-board.c  |  1 +
 arch/arm/mach-rockchip/rk322x-board-spl.c  |  2 +-
 arch/arm/mach-rockchip/rk322x-board.c  | 24 
 arch/arm/mach-rockchip/rk3288-board-spl.c  |  4 ++--
 arch/arm/mach-rockchip/rk3288-board-tpl.c  |  2 +-
 arch/arm/mach-rockchip/rk3288-board.c  | 25 -
 arch/arm/mach-rockchip/rk3368-board-tpl.c  |  2 +-
 arch/arm/mach-rockchip/rk3399-board-spl.c  |  2 +-
 arch/arm/mach-rockchip/rk3399-board.c  | 14 ++
 arch/arm/mach-rockchip/save_boot_param.S   | 69 

Re: [U-Boot] [PATCH 3/8] pci: xilinx: Initialise the root bridge during probe

[Michal Simek]

Hi

On 21.11.2017 22:31, Daniel Schwierzeck wrote:
> +cc Michal for Xilinx stuff
> 
> On 21.11.2017 21:33, Paul Burton wrote:
>> Whilst the pcie_xilinx driver was sufficient to run under QEMU, it was
>> failing on FPGA because it wasn't configuring the root bridge, and
>> access from the PCI auto-configuration code to subordinate busses would
>> lead to data bus errors. Fix this by configuring the root bridge to
>> allow access to all possible subordinate busses based upon the size of
>> the ECAM region, and disable interrupts since U-Boot isn't using them.
>>
>> Signed-off-by: Paul Burton 
>> Cc: Daniel Schwierzeck 
>> Cc: u-boot@lists.denx.de
>> Signed-off-by: Paul Burton 
>> ---
>>
>>  drivers/pci/pcie_xilinx.c | 36 ++--
>>  1 file changed, 34 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/pcie_xilinx.c b/drivers/pci/pcie_xilinx.c
>> index 57112f5333..877087d4f1 100644
>> --- a/drivers/pci/pcie_xilinx.c
>> +++ b/drivers/pci/pcie_xilinx.c
>> @@ -21,8 +21,14 @@ struct xilinx_pcie {
>>  };
>>  
>>  /* Register definitions */
>> -#define XILINX_PCIE_REG_PSCR0x144
>> -#define XILINX_PCIE_REG_PSCR_LNKUP  BIT(11)
>> +#define XILINX_PCIE_REG_BRIDGE_INFO 0x130
>> +#define  XILINX_PCIE_REG_BRIDGE_INFO_ECAMSZ_SHIFT   16
>> +#define  XILINX_PCIE_REG_BRIDGE_INFO_ECAMSZ_MASK(0x7 << 16)
>> +#define XILINX_PCIE_REG_INT_MASK0x13c
>> +#define XILINX_PCIE_REG_PSCR0x144
>> +#define  XILINX_PCIE_REG_PSCR_LNKUP BIT(11)
>> +#define XILINX_PCIE_REG_RPSC0x148
>> +#define  XILINX_PCIE_REG_RPSC_BRIDGEEN  BIT(0)
>>  
>>  /**
>>   * pcie_xilinx_link_up() - Check whether the PCIe link is up
>> @@ -159,6 +165,31 @@ static int pcie_xilinx_ofdata_to_platdata(struct 
>> udevice *dev)
>>  return 0;
>>  }
>>  
>> +static int pcie_xilinx_probe(struct udevice *dev)
>> +{
>> +struct xilinx_pcie *pcie = dev_get_priv(dev);
>> +u32 bridge_info, ecam_sz, rpsc;
>> +
>> +/* Disable all interrupts */
>> +writel(0, pcie->cfg_base + XILINX_PCIE_REG_INT_MASK);
>> +
>> +/* Enable the bridge */
>> +rpsc = readl(pcie->cfg_base + XILINX_PCIE_REG_RPSC);
>> +rpsc |= XILINX_PCIE_REG_RPSC_BRIDGEEN;
>> +writel(rpsc, pcie->cfg_base + XILINX_PCIE_REG_RPSC);
>> +
>> +/* Discover the size of the ECAM region */
>> +bridge_info = readl(pcie->cfg_base + XILINX_PCIE_REG_BRIDGE_INFO);
>> +ecam_sz = bridge_info & XILINX_PCIE_REG_BRIDGE_INFO_ECAMSZ_MASK;
>> +ecam_sz >>= XILINX_PCIE_REG_BRIDGE_INFO_ECAMSZ_SHIFT;
>> +
>> +/* Enable access to all possible subordinate buses */
>> +writel((0 << 0) | (1 << 8) | (GENMASK(ecam_sz - 1, 0) << 16),
>> +   pcie->cfg_base + PCI_PRIMARY_BUS);
>> +
>> +return 0;
>> +}
>> +
>>  static const struct dm_pci_ops pcie_xilinx_ops = {
>>  .read_config= pcie_xilinx_read_config,
>>  .write_config   = pcie_xilinx_write_config,
>> @@ -175,5 +206,6 @@ U_BOOT_DRIVER(pcie_xilinx) = {
>>  .of_match   = pcie_xilinx_ids,
>>  .ops= _xilinx_ops,
>>  .ofdata_to_platdata = pcie_xilinx_ofdata_to_platdata,
>> +.probe  = pcie_xilinx_probe,
>>  .priv_auto_alloc_size   = sizeof(struct xilinx_pcie),
>>  };
>>

Sorry I am not running this configuration and we have never tried to use
this driver in connection to xilinx arm/microblaze socs. That's why I
simply don't know.

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

Re: [U-Boot] [PATCH 1/1] ubifs: avoid possible NULL dereference

[Wolfgang Denk]

Dear Ladislav,

In message <2017112121.ryicwv6tyh5rye2e@lenoch> you wrote:
> > > 
> > > diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
> > > index 4465523d5f..313dee0579 100644
> > > --- a/fs/ubifs/ubifs.c
> > > +++ b/fs/ubifs/ubifs.c
> > > @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char 
> > > *dirname,
> > >   dir = kzalloc(sizeof(struct inode), 0);
> > >   if (!file || !dentry || !dir) {
> > >   printf("%s: Error, no memory for malloc!\n", __func__);
> > > - err = -ENOMEM;
> > > - goto out;
> > > + goto out_nomem;
> > >   }
...
> > Should you not keep the "err = -ENOMEM;" setting?  Otherwise there
> > is no indivcation that an error happened.
> 
> It is not obvious from the patch, but value of err is later discarded.
> It serves sole purpose of printing debug notice.

So apparently we have a number of places in U-Boot where fatal
errors (running out of memory) are just ignored and we continue as
if nothing happened?

THis is short-sighted at best. One day Pump Six will fail.

This is giving me the creepes. 

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Why don't you have a Linux partition installed so you can be  working
in  a  programmer-friendly environment instead of a keep-gates'-bank-
account-happy one? :-)-- Tom Christiansen
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] dm: mmc: updated mmc_of_parse() to not fail because of an invalid bus-width

[Lukasz Majewski]

On Tue, 21 Nov 2017 16:13:04 +0100
Jean-Jacques Hiblot  wrote:

> Instead of failing, the driver uses the default: 1-bit bus width.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc-uclass.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index e30cde7..48fafce 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -137,9 +137,10 @@ int mmc_of_parse(const void *fdt, int node,
> struct mmc_config *cfg) cfg->host_caps |= MMC_MODE_1BIT;
>   break;
>   default:
> - printf("error: %s invalid bus-width property %d\n",
> -fdt_get_name(fdt, node, NULL), val);
> - return -ENOENT;
> + debug("warning: %s invalid bus-width property. using
> 1-bit\n",
> +   fdt_get_name(fdt, node, NULL));
> + cfg->host_caps |= MMC_MODE_1BIT;
> + break;
>   }
>  
>   cfg->f_max = fdtdec_get_int(fdt, node, "max-frequency",
> 5200);

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


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

Re: [U-Boot] U-Boot proper(not SPL) relocate option

[Lokesh Vutla]

+ Simon,

On Wednesday 22 November 2017 07:29 AM, Kever Yang wrote:
> Hi Lukasz,
> 
> 
>     Thanks for your quick comments on this topic.
> On 11/21/2017 06:29 PM, Lukasz Majewski wrote:
>> Hi Kever,
>>
>>> Hi Guys,
>>>
>>>   I try to understand why we need to do the relocate in U-Boot.
>>>   From the document README/crt0.S, I think the relocation feature comes
>>> from some SoC have limited SRAM whose size is enough to load the whole
>>> U-Boot, but not enough to run all the drivers.
>>>
>>>   I don't know how many SoCs/Archs still must use this feature,
>>> but I'm sure all
>>> Rockchip SoCs do not need this feature in both SPL and proper U-Boot,
>>> because rockchip using SPL always running in SRAM to init DDR SDRAM,
>>> and after DRAM available always running U-Boot in DRAM.
>> I always thought that u-boot needs relocation to place itself in the
>> "known" area of SDRAM (which ends in its very end).
> 
> I can understand this feature, we always do dram_init_banks() first,
> then we relocate to 'known' area, then will be no risk to access memory.
> I believe there must be some historical reason for some kind of device,
> the relocate feature is a wonderful idea for it.
> 
> In another case, we can also have a choice for not relocate because:
> - we still can have similar 'bdinfo' but without relocate, we can init
> dram info
>     first, and then init SP, malloc area and so on, and then other
> driver init.
> - All solution for Rockchip SoCs at least have 512MByte DRAM,
>     which should be enough for U-Boot and could consider to be 'known'
> area,
>     many other SoCs should be similar.
> - Without relocate we can save many step, some of our customer really
>     care much about the boot time duration.
>     * no need to relocate everything
>     * no need to copy all the code
>     * no need init the driver more than once

I agree that there should be an option for avoiding relocation. There is
a flag "GD_FLG_SKIP_RELOC" which when enabled on gd->flags tries to skip
relocation for u-boot proper.  I am sure that this must be working for
x86 but it can be ported for other architectures as well?

Thanks and regards,
Lokesh

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

Re: [U-Boot] U-Boot proper(not SPL) relocate option

[Wolfgang Denk]

Dear Kever Yang,

In message  you wrote:
> 
> I can understand this feature, we always do dram_init_banks() first,
> then we relocate to 'known' area, then will be no risk to access memory.
> I believe there must be some historical reason for some kind of device,
> the relocate feature is a wonderful idea for it.

This is actuallyu not so much a feature needed to support some
specific device (in this case much simpler approahces would be
possible), but to support a whole set of features.  Unfortunately
these appear to get forgotten / ignored over time.

>  many other SoCs should be similar.
> - Without relocate we can save many step, some of our customer really
>  care much about the boot time duration.
>  * no need to relocate everything
>  * no need to copy all the code
>  * no need init the driver more than once

Please have a look at the README, section "Memory Management".
The reloaction is not done to any _fixed_ address, but the address
is actually computed at runtime, depending on a number features
enabled (at least this is how it used to be - appearently little of
this is tested on a regular base, so I would not be surprised if
things are broken today).

The basic idea was to reserve areas of memory at the top of RAM,
that would not be initialized / modified by U-Boot and Linux, not
even across a reset / warm boot.

This was used for exaple for:

- pRAM (Protected RAM) which could be used to store all kind of data
  (for example, using a pramfs [Protected and Persistent RAM
  Filesystem]) that could be kept across reboots of the OS.

- shared frame buffer / video memory. U-Boot and Linux would be able
  to initialize the video memory just once (in U-Boot) and then
  share it, maybe even across reboots.  especially, this would allow
  for a very early splash screen that gets passed (flicker free) to
  Linux until some Linux GUI takes over (much more difficult today).

- shared log buffer: U-Boot and Linux used to use the same syslog
  buffer mechanism, so you could share it between U-Boot and Linux.
  this allows for example to 
  * read the Linux kernel panic messages after reset in U-Boot; this
is very useful when you bring up a new system and Linux crashes
before it can display the log buffer on the console
  * pass U-Boot POST results on to Linux, so the application code
can read and process these
  * process the system log of the previous run (especially after a
panic) in Lunux after it rebootet.

etc.

There are a number of such features which require to reserve room at
the top of RAM, the size of which is calculatedat runtime, often
depending on user settable environment data.

All this cannot be done without relocation to a (dynmaically
computed) target address.


Yes, the code could be simpler and faster without that - but then,
you cut off a number of features.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The flow chart is a most thoroughly oversold piece of  program  docu-
mentation.  -- Frederick Brooks, "The Mythical Man Month"
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] U-Boot proper(not SPL) relocate option

[Lukasz Majewski]

Hi Chris,

> On Wed, Nov 22, 2017 at 2:59 PM, Kever Yang
>  wrote:
> > Hi Lukasz,
> >
> >
> > Thanks for your quick comments on this topic.
> > On 11/21/2017 06:29 PM, Lukasz Majewski wrote:  
> >>
> >> Hi Kever,
> >>  
> >>> Hi Guys,
> >>>
> >>>   I try to understand why we need to do the relocate in
> >>> U-Boot. From the document README/crt0.S, I think the relocation
> >>> feature comes from some SoC have limited SRAM whose size is
> >>> enough to load the whole U-Boot, but not enough to run all the
> >>> drivers.
> >>>
> >>>   I don't know how many SoCs/Archs still must use this
> >>> feature, but I'm sure all
> >>> Rockchip SoCs do not need this feature in both SPL and proper
> >>> U-Boot, because rockchip using SPL always running in SRAM to init
> >>> DDR SDRAM, and after DRAM available always running U-Boot in
> >>> DRAM.  
> >>
> >> I always thought that u-boot needs relocation to place itself in
> >> the "known" area of SDRAM (which ends in its very end).  
> >
> >
> > I can understand this feature, we always do dram_init_banks() first,
> > then we relocate to 'known' area, then will be no risk to access
> > memory. I believe there must be some historical reason for some
> > kind of device, the relocate feature is a wonderful idea for it.  
> 
> (I can't really speak for u-boot but in general I think this applies).
> 
> In the old days there was no SPL. 

As fair as I remember there was CONFIG_PRELOAD something before SPL
(u-boot delivered two binaries).

> It was just the same bootloader
> image. This image was written (or "burned") to a memory mapped
> ROM/flash which could be executed directly in place. Then after the
> RAM was initialised the image could be relocated and execution could
> continue from the new address.
> 
> These days with SoCs that can boot from non-memory-mapped devices the
> same tricks can't work which is where the SPL comes in.
> 
> The other thing with relocation is that u-boot likes to be at the very
> top of RAM. This means we have all this nice contiguous space at the
> bottom for the kernel/initrd/whatever .
> 
> We can't know at compile time where the top is as some boards may have
> DIMMs an others may just have board variants with more or less memory
> fitted. Which is why we need to set CONFIG_TEXTBASE to something that
> is suitable for the lowest common denominator and relocate once we
> know how much RAM we have.

As I mentioned before - the continous space from RAM start till end -
u-boot size is crucial for updating - i.e when rootfs needs to be
flashed.

But, I do agree with above arguments.

> 
> > In another case, we can also have a choice for not relocate because:
> > - we still can have similar 'bdinfo' but without relocate, we can
> > init dram info
> > first, and then init SP, malloc area and so on, and then other
> > driver init.
> > - All solution for Rockchip SoCs at least have 512MByte DRAM,
> > which should be enough for U-Boot and could consider to be
> > 'known' area, many other SoCs should be similar.
> > - Without relocate we can save many step, some of our customer
> > really care much about the boot time duration.
> > * no need to relocate everything
> > * no need to copy all the code
> > * no need init the driver more than once
> >
> > Thanks,
> > - Kever
> >  
> >>
> >> In this way we can upload u-boot proper via SPL to any SDRAM
> >> location and then (after relocation) it puts itself to "known"
> >> location.
> >>
> >> (Please check bdinfo command for details).
> >>
> >> Having u-boot at known location helps with:
> >>
> >> - Using the non fragmented SDRAM to download updates
> >>
> >> - Booting u-boot on many different devices (with different amount
> >> of RAM) -> you always download u-boot in the near of SDRAM
> >> beginning and then it relocates itself appropriately.
> >>
> >>
> >> However, I'm not sure if we would need relocation in SPL (which
> >> runs in SRAM). It seems to me that SPL binary is so board
> >> specific, that we shouldn't need such generic feature there.
> >>  
> >>> There is a CONFIG_SPL_SKIP_RELOCATE for SPL to skip the relocate,
> >>> can we have another CONFIG_SKIP_RELOCATE for U-Boot proper?
> >>>
> >>>
> >>> Here is the document from README:
> >>>
> >>> board_init_f():
> >>>   - purpose: set up the machine ready for running
> >>> board_init_r(): i.e. SDRAM and serial UART
> >>>   - global_data is available
> >>>   - stack is in SRAM
> >>>   - BSS is not available, so you cannot use global/static
> >>> variables, only stack variables and global_data
> >>>
> >>>   Non-SPL-specific notes:
> >>>   - dram_init() is called to set up DRAM. If already done
> >>> in SPL this
> >>>   can do nothing
> >>>
> >>>   SPL-specific notes:
> >>>   - you can override the entire board_init_f() function
> >>> with your own version as needed.
> >>>   - preloader_console_init() can be 

Re: [U-Boot] [PATCH] spl: make CONFIG_OF_EMBED pass dts through fdtgrep

[Lukasz Majewski]

Hi Simon,

> Building spl with CONFIG_OF_EMBED enabled results in an error message
^^^ - is the CONFIG_OF_EMBED a standard
feature for SPL? 


> on my board: "SPL image too big". This is because the fdtgrep build
> step is only executed for CONFIG_OF_SEPARATE.

So the problem is with not enough runs of dtb stripping?

> 
> Fix this by moving the fdtgrep build step ('cmd_fdtgreo') from
> scripts/Makefile.spl to dts/Makefile so that the reduced dtb is
> available for all kinds of spl builds.

Ok.

> 
> The resulting variable name for the embedded device tree blob changes,
> too, which is why common.h and fdtdec.c have tiny changes.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
>  dts/Makefile | 35 +++
>  include/common.h |  1 +
>  lib/fdtdec.c |  4 
>  scripts/Makefile.spl | 20 ++--
>  4 files changed, 38 insertions(+), 22 deletions(-)
> 
> diff --git a/dts/Makefile b/dts/Makefile
> index 3a93dafb51..c9b2a89441 100644
> --- a/dts/Makefile
> +++ b/dts/Makefile
> @@ -22,10 +22,29 @@ DTB := $(ARCH_PATH)/$(DEVICE_TREE).dtb
>  dtb_depends += $(DTB:.dtb=.dts)
>  endif
>  
> +# Pass the original device tree file through fdtgrep twice. The
> first pass +# removes any unwanted nodes (i.e. those which don't have
> the +# 'u-boot,dm-pre-reloc' property and thus are not needed by SPL.
> The second +# pass removes various unused properties from the
> remaining nodes. +# The output is typically a much smaller device
> tree file. +ifeq ($(CONFIG_TPL_BUILD),y)
> +fdtgrep_props := -b u-boot,dm-pre-reloc -b u-boot,dm-tpl
> +else
> +fdtgrep_props := -b u-boot,dm-pre-reloc -b u-boot,dm-spl
> +endif
> +quiet_cmd_fdtgrep = FDTGREP $@
> +  cmd_fdtgrep = $(objtree)/tools/fdtgrep $(fdtgrep_props) -RT $<
> \
> + -n /chosen -n /config -O dtb | \
> + $(objtree)/tools/fdtgrep -r -O dtb - -o $@ \
> + $(addprefix -P ,$(subst
> $\",,$(CONFIG_OF_SPL_REMOVE_PROPS))) +
> +$(obj)/dt-spl.dtb: $(DTB) $(objtree)/tools/fdtgrep FORCE
> + $(call if_changed,fdtgrep)
> +
>  $(obj)/dt.dtb: $(DTB) FORCE
>   $(call if_changed,shipped)
>  
> -targets += dt.dtb
> +targets += dt.dtb dt-spl.dtb
>  
>  $(DTB): $(dtb_depends)
>  ifeq ($(EXT_DTB),)
> @@ -42,14 +61,22 @@ endif
>  arch-dtbs:
>   $(Q)$(MAKE) $(build)=$(ARCH_PATH) dtbs
>  
> -.SECONDARY: $(obj)/dt.dtb.S
> +.SECONDARY: $(obj)/dt.dtb.S $(obj)/dt-spl.dtb.S
>  
> +
> +ifeq ($(CONFIG_SPL_BUILD),y)
> +obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o
> +# support "out-of-tree" build for dtb-spl
> +$(obj)/dt-spl.dtb.o: $(obj)/dt-spl.dtb.S FORCE
> + $(call if_changed_dep,as_o_S)
> +else
>  obj-$(CONFIG_OF_EMBED) := dt.dtb.o
> +endif
>  
> -dtbs: $(obj)/dt.dtb
> +dtbs: $(obj)/dt.dtb $(obj)/dt-spl.dtb
>   @:
>  
> -clean-files := dt.dtb.S
> +clean-files := dt.dtb.S dt-spl.dtb.S
>  
>  # Let clean descend into dts directories
>  subdir-
> += ../arch/arm/dts ../arch/microblaze/dts ../arch/mips/dts 
> ../arch/sandbox/dts ../arch/x86/dts
> diff --git a/include/common.h b/include/common.h index
> e14e1daa88..6e24545178 100644 --- a/include/common.h
> +++ b/include/common.h
> @@ -201,6 +201,7 @@ int last_stage_init(void);
>  extern ulong monitor_flash_len;
>  int mac_read_from_eeprom(void);
>  extern u8 __dtb_dt_begin[];  /* embedded device tree blob */
> +extern u8 __dtb_dt_spl_begin[];  /* embedded device tree blob
> for SPL/TPL */ int set_cpu_clk_info(void);
>  int mdm_init(void);
>  int print_cpuinfo(void);
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 45f3fe7baf..0eb0b92261 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -1266,7 +1266,11 @@ int fdtdec_setup(void)
>  # endif
>  # ifdef CONFIG_OF_EMBED
>   /* Get a pointer to the FDT */
> +#  ifdef CONFIG_SPL_BUILD
> + gd->fdt_blob = __dtb_dt_spl_begin;
> +#  else
>   gd->fdt_blob = __dtb_dt_begin;
> +#  endif
>  # elif defined CONFIG_OF_SEPARATE
>  #  ifdef CONFIG_SPL_BUILD
>   /* FDT is at end of BSS unless it is in a different memory
> region */ diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index 49b27ac926..d3c176d775 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -238,24 +238,8 @@ $(obj)/$(SPL_BIN)-pad.bin: $(obj)/$(SPL_BIN)
>   @bss_size_str=$(shell $(NM) $< | awk 'BEGIN {size =
> 0} /__bss_size/ {size = $$1} END {print "ibase=16; " toupper(size)}'
> | bc); \ dd if=/dev/zero of=$@ bs=1 count=$${bss_size_str}
> 2>/dev/null; -# Pass the original device tree file through fdtgrep
> 2>twice. The first pass
> -# removes any unwanted nodes (i.e. those which don't have the
> -# 'u-boot,dm-pre-reloc' property and thus are not needed by SPL. The
> second -# pass removes various unused properties from the remaining
> nodes. -# The output is typically a much smaller device tree file.
> -ifeq ($(CONFIG_TPL_BUILD),y)
> -fdtgrep_props := -b u-boot,dm-pre-reloc -b u-boot,dm-tpl
> -else
> -fdtgrep_props := 

Re: [U-Boot] [PATCH] spl: make CONFIG_OF_EMBED pass dts through fdtgrep

[Goldschmidt Simon]

Hi Lukasz

> > Building spl with CONFIG_OF_EMBED enabled results in an error message
>   ^^^ - is the CONFIG_OF_EMBED a standard
>   feature for SPL?

Well, it's not really a standard feature I want to use in my final
product. But if I want to debug SPL or U-Boot on my socfpga (using
ARM's DS-5 for Altera), I need the device tree to be included in the
binary that the debugger downloads to the target.

That's what CONFIG_OF_EMBED is for, right? I even need this to debug
U-Boot, as the standard procedure for my target is to first start SPL
via the debugger, halt at a specific hardware breakpoint and the load
U-Boot which I want to debug.

> > on my board: "SPL image too big". This is because the fdtgrep build
> > step is only executed for CONFIG_OF_SEPARATE.
> 
> So the problem is with not enough runs of dtb stripping?

No, the problem that the dtb is not stripped at all for CONFIG_OF_EMBED.
The only thing that is stripped is 'spl/u-boot-spl.dtb' which is only
created for CONFIG_OF_SEPARATE.

> 
> >
> > Fix this by moving the fdtgrep build step ('cmd_fdtgreo') from
> > scripts/Makefile.spl to dts/Makefile so that the reduced dtb is
> > available for all kinds of spl builds.
> 
> Ok.
> 
> >
> > The resulting variable name for the embedded device tree blob changes,
> > too, which is why common.h and fdtdec.c have tiny changes.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >  dts/Makefile | 35 +++
> >  include/common.h |  1 +
> >  lib/fdtdec.c |  4 
> >  scripts/Makefile.spl | 20 ++--
> >  4 files changed, 38 insertions(+), 22 deletions(-)
> >
> > diff --git a/dts/Makefile b/dts/Makefile index 3a93dafb51..c9b2a89441
> > 100644
> > --- a/dts/Makefile
> > +++ b/dts/Makefile
> > @@ -22,10 +22,29 @@ DTB := $(ARCH_PATH)/$(DEVICE_TREE).dtb
> > dtb_depends += $(DTB:.dtb=.dts)  endif
> >
> > +# Pass the original device tree file through fdtgrep twice. The
> > first pass +# removes any unwanted nodes (i.e. those which don't have
> > the +# 'u-boot,dm-pre-reloc' property and thus are not needed by SPL.
> > The second +# pass removes various unused properties from the
> > remaining nodes. +# The output is typically a much smaller device tree
> > file. +ifeq ($(CONFIG_TPL_BUILD),y)
> > +fdtgrep_props := -b u-boot,dm-pre-reloc -b u-boot,dm-tpl else
> > +fdtgrep_props := -b u-boot,dm-pre-reloc -b u-boot,dm-spl endif
> > +quiet_cmd_fdtgrep = FDTGREP $@
> > +  cmd_fdtgrep = $(objtree)/tools/fdtgrep $(fdtgrep_props) -RT $<
> > \
> > +   -n /chosen -n /config -O dtb | \
> > +   $(objtree)/tools/fdtgrep -r -O dtb - -o $@ \
> > +   $(addprefix -P ,$(subst
> > $\",,$(CONFIG_OF_SPL_REMOVE_PROPS))) +
> > +$(obj)/dt-spl.dtb: $(DTB) $(objtree)/tools/fdtgrep FORCE
> > +   $(call if_changed,fdtgrep)
> > +
> >  $(obj)/dt.dtb: $(DTB) FORCE
> > $(call if_changed,shipped)
> >
> > -targets += dt.dtb
> > +targets += dt.dtb dt-spl.dtb
> >
> >  $(DTB): $(dtb_depends)
> >  ifeq ($(EXT_DTB),)
> > @@ -42,14 +61,22 @@ endif
> >  arch-dtbs:
> > $(Q)$(MAKE) $(build)=$(ARCH_PATH) dtbs
> >
> > -.SECONDARY: $(obj)/dt.dtb.S
> > +.SECONDARY: $(obj)/dt.dtb.S $(obj)/dt-spl.dtb.S
> >
> > +
> > +ifeq ($(CONFIG_SPL_BUILD),y)
> > +obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o # support "out-of-tree" build
> > +for dtb-spl
> > +$(obj)/dt-spl.dtb.o: $(obj)/dt-spl.dtb.S FORCE
> > +   $(call if_changed_dep,as_o_S)
> > +else
> >  obj-$(CONFIG_OF_EMBED) := dt.dtb.o
> > +endif
> >
> > -dtbs: $(obj)/dt.dtb
> > +dtbs: $(obj)/dt.dtb $(obj)/dt-spl.dtb
> > @:
> >
> > -clean-files := dt.dtb.S
> > +clean-files := dt.dtb.S dt-spl.dtb.S
> >
> >  # Let clean descend into dts directories
> >  subdir-
> > += ../arch/arm/dts ../arch/microblaze/dts ../arch/mips/dts
> > +../arch/sandbox/dts ../arch/x86/dts
> > diff --git a/include/common.h b/include/common.h index
> > e14e1daa88..6e24545178 100644 --- a/include/common.h
> > +++ b/include/common.h
> > @@ -201,6 +201,7 @@ int last_stage_init(void);  extern ulong
> > monitor_flash_len;  int mac_read_from_eeprom(void);
> >  extern u8 __dtb_dt_begin[];/* embedded device tree blob */
> > +extern u8 __dtb_dt_spl_begin[];/* embedded device tree blob
> > for SPL/TPL */ int set_cpu_clk_info(void);  int mdm_init(void);  int
> > print_cpuinfo(void); diff --git a/lib/fdtdec.c b/lib/fdtdec.c index
> > 45f3fe7baf..0eb0b92261 100644
> > --- a/lib/fdtdec.c
> > +++ b/lib/fdtdec.c
> > @@ -1266,7 +1266,11 @@ int fdtdec_setup(void)  # endif  # ifdef
> > CONFIG_OF_EMBED
> > /* Get a pointer to the FDT */
> > +#  ifdef CONFIG_SPL_BUILD
> > +   gd->fdt_blob = __dtb_dt_spl_begin;
> > +#  else
> > gd->fdt_blob = __dtb_dt_begin;
> > +#  endif
> >  # elif defined CONFIG_OF_SEPARATE
> >  #  ifdef CONFIG_SPL_BUILD
> > /* FDT is at end of BSS unless it is in a different memory region */
> > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index
> > 

Re: [U-Boot] [PATCH] ni: Add NIZYNQ platform

[Wilson Lee]

Hi Michal,

On Wed, 2017-11-22 at 08:11 +0100, Michal Simek wrote:
> Hi,
> 
> On 22.11.2017 04:06, Wilson Lee wrote:
> > 
> > Hi Michal,
> > 
> > On Wed, 2017-11-08 at 07:27 +0100, Michal Simek wrote:
> > > 
> > > On 8.11.2017 03:54, Wilson Lee wrote:
> > > > 
> > > > 
> > > > Initial platform creation for NIZYNQ.
> > > > 
> > > > Signed-off-by: Joe Hershberger 
> > > > Signed-off-by: Keng Soon Cheah 
> > > > Signed-off-by: Wilson Lee 
> > > > Cc: Chen Yee Chew 
> > > > Cc: Albert Aribaud 
> > > > ---
> > > >  arch/arm/Kconfig  | 15 +++
> > > >  arch/arm/Makefile |  4 +++-
> > > >  board/ni/Kconfig  | 13 +
> > > >  3 files changed, 31 insertions(+), 1 deletion(-)
> > > >  create mode 100644 board/ni/Kconfig
> > > > 
> > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > > index 83b7aa5..ae34821 100644
> > > > --- a/arch/arm/Kconfig
> > > > +++ b/arch/arm/Kconfig
> > > > @@ -767,6 +767,20 @@ config ARCH_ZYNQMP
> > > >     select DM_USB if USB
> > > >     imply FAT_WRITE
> > > >  
> > > > +config NIZYNQ
> > > > +   bool "National Instruments zynq Platform"
> > > > +   select CPU_V7
> > > > +   select SUPPORT_SPL
> > > > +   select OF_CONTROL
> > > > +   select SPL_OF_CONTROL if SPL
> > > > +   select DM
> > > > +   select DM_ETH
> > > > +   select DM_GPIO
> > > > +   select SPL_DM if SPL
> > > > +   select DM_MMC
> > > > +   select DM_SERIAL
> > > > +   select SPL_SEPARATE_BSS if SPL
> > > > +
> > > What's the reason for this? You should reuse current ZYNQ
> > > fragment
> > > and
> > > if this selects something what you don't want then we should
> > > changethat. Look at syzygy or topic boards which are using
> > > existing
> > > zynq
> > > infrastructure.
> > > 
> > > Thanks,
> > > Michal
> > > 
> > > 
> > The reason for adding NIZYNQ instead of reuse ARCH_ZYNQ. That is
> > because we need NIZYNQ at the same level with ARCH_ZYNQ in
> > menuconfig.
> > We are thinking that it would be missleading, if our customer need
> > to
> > select Xilinx Zynq Platform before they can select NI product. 
> > 
> > Hence, what we wish to get the menuconfig that look like below,
> > 
> > + Target select +
> > > 
> > >   Use the arrow keys to navigate this window or press
> > > the  |  
> > >  hotkey of the item you wish to select followed by the  > >   BAR>. Press  for additional information about
> > > this|  
> > > +^(-)---+ |  
> > > > 
> > > > ( ) Support pcm-052|
> > > > |  
> > > > ( ) Support BK4r1  |
> > > > |  
> > >  |( ) Xilinx Zynq Platform   |
> > > |  
> > > > 
> > > > ( ) Support Xilinx ZynqMP Platform |
> > > > |  
> > > > (X) National Instruments zynq Platform |
> > > > |  
> > > > ( ) NVIDIA Tegra   |
> > > > |  
> > > ++(+)---+ |  
> > +---+  
> > > 
> > >   < Help
> > > > |  
> > +---+
> > 
> I understand that you want to put there a little bit of marketing but
> moving to DM should avoid doing this and really I want to make xilinx
> ports generic as much as possible.
> 
> What we can do is to change description to be more understandable
> like
> "Xilinx Zynq based platform".

After some discussion, we think that changing the description to be
more understandable as you suggested above is make sense to us and it
is a good approache also. May I know, do you will submit a commit to
change the description or we might need to submit ourself on changing
the description?

> 
> Is there something what will use NIZYNQ symbol in the code? Does that
> mean that there is something what is not handle now that you have to
> use
> this symbol?

I think that is alright. Because, we are not using NIZYNQ symbol in the
code.

Furthermore, we are using our own header file (something like zynq-
common.h) due to it will provide more flexibility on defining stuff
(such as undefine something that defined in zynq-common, define
CONFIG_EXTRA_ENV_SETTINGS, CONFIG_PREBOOT and etc..). I think we can
easily change the default header file from zynq-common.h to our own one
by redefine "SYS_CONFIG_NAME" again in defconfig. By the way, may I
know is it have a better way for not keep on redefining the
"SYS_CONFIG_NAME" in every board defconfig if we have 20+ boards.


Thanks, Michal.

Best Regards,
Wilson Lee
___
U-Boot mailing list
U-Boot@lists.denx.de

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

[Tom Rini]

On Wed, Nov 22, 2017 at 10:30:05AM +0100, Dr. Philipp Tomsich wrote:

> Tom,
> 
> Please pull from u-boot-rockchip/master. 
> The associated Travis run (prior to a final rebase) is at 
> https://travis-ci.org/ptomsich/u-boot-rockchip/builds/305523168.
> 
> Thanks,
> Philipp.
> 
> 
> The following changes since commit 16fa2eb95172e63820ee5f3d4052f3362a6de84e:
> 
>   ARM: dra7: Kconfig: Add thermal configs for dra7xx and am57xx (2017-11-21 
> 08:03:39 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git master
> 
> for you to fetch changes up to 08790230fe80d46ff6368e0dc1e1be500ca3c4bf:
> 
>   rockchip: remove duplicate CONFIG_ENV_SIZE definitions (2017-11-21 23:57:24 
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] mx6ull evk reboots automatically

[Fabio Estevam]

Hi Ye Li,

On Thu, Nov 23, 2017 at 12:05 AM, Ye Li  wrote:

>  The wdog3 is not disabled for i.mx6ull on mainline U-boot. Please fix it in 
> imx_set_wdog_powerdown.
>
>if (is_mx6sx() || is_mx6ul() || is_mx6ull() || is_mx7())
> writew(enable, >wmcr);

Thanks for your suggestion.

I tried the following change:

--- a/arch/arm/mach-imx/init.c
+++ b/arch/arm/mach-imx/init.c
@@ -78,7 +78,7 @@ void imx_set_wdog_powerdown(bool enable)
writew(enable, >wmcr);
writew(enable, >wmcr);

-   if (is_mx6sx() || is_mx6ul() || is_mx7())
+   if (is_mx6sx() || is_mx6ul() || is_mx6ull() || is_mx7())
writew(enable, >wmcr);
 #ifdef CONFIG_MX7D
writew(enable, >wmcr);


but still got the kernel reboot.

Any ideas?

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

Re: [U-Boot] [PATCH 0/3] ls1012a: fix tftp failure

[Calvin Johnson]

Hi York,

> -Original Message-
> From: York Sun
> Sent: Thursday, November 23, 2017 12:00 AM
> To: Calvin Johnson ; u-boot@lists.denx.de
> Cc: Anji Jagarlmudi ; Joe Hershberger
> ; Prabhakar Kushwaha
> 
> Subject: Re: [PATCH 0/3] ls1012a: fix tftp failure
> 
> On 11/21/2017 10:26 PM, Calvin Johnson wrote:
> > This patch series fixes bug which fails tftp sometimes
> > while using the pfe interfaces and also has some code clean up.
> >
> >
> > Calvin Johnson (3):
> >   drivers: net: pfe_eth: add pfe_rx_done to clear bd after packet
> > processing
> >   drivers: net: pfe_eth: use writel/readl to access hw bds
> >   drivers: net: pfe_eth: cleanup typos and indent
> >
> >  drivers/net/pfe_eth/pfe_driver.c | 126 +++-
> ---
> >  drivers/net/pfe_eth/pfe_eth.c|  13 ++--
> >  include/pfe_eth/pfe_driver.h |   1 +
> >  3 files changed, 82 insertions(+), 58 deletions(-)
> >
> 
> Your PFE patch set is not fully reviewed or accepted. If I were you, I
> would probably send v2 version to include all the changes.
> 
> It is up to Joe to decide to take a new version, or patches on top of
> patches.

I can squash all these follow up patches to v2 of the base pfe patch series.
Yes, it will be better than having these patches on top of it as the base is 
not yet merged.

Thanks
Calvin


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

Re: [U-Boot] [PATCH 00/10] rockchip: add tpl and OPTEE support for rk3229

[Heiko Stuebner]

Am Mittwoch, 22. November 2017, 17:10:19 CET schrieb Joseph Chen:
> 
> 在 2017/11/21 23:43, Andrew F. Davis 写道:
> > On 11/20/2017 03:25 PM, Heiko Stübner wrote:
> >> Hi Kever,
> >>
> >> Am Mittwoch, 6. September 2017, 10:14:27 CET schrieb Kever Yang:
> >>> Add some generic options for TPL support for arm 32bit, and then
> >>> and TPL support for rk3229(cortex-A7), and then add OPTEE support
> >>> in SPL.
> >> I was now finally able to test this series and I'm getting mixed results.
> >> I was following the instructions in the evb-rk3229 README file.
> >>
> >>
> >> On the uboot side it seems to work nicely when applied against 2017.09.
> >>
> >> But when I try to rebase it on top of the next branch of u-boot-rockchip
> >> I end up with the TPL claiming a "Missing DTB", so it looks like it needs
> >> a respin to follow the recent changes.
> >>
> >> On the optee-side I also seem to do something wrong or so.
> >> When using the binaries from the rkbin github repository I end up with
> >> [0] and [1].
> >> When compiling the most-recent optee it fails with [2].
> >>
> >> With some intermediate optee or the one from Tony Xie's repository
> >> it compiles and uboot seems to start, but then fails when the kernel tries
> >> to bring up the secondary cpus [3]. And interestingly while it seems to go
> >> through optee, I don't see any optee-messages.
> >>
> >> If you could point me into the right direction, I would be very grateful 
> >> :-)
> >>
> >>
> >> Thanks
> >> Heiko
> >>
> >>
> >> [0]
> >> TPL Inittimer init done
> >> Returning to boot ROM...
> >>
> >> U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
> >> Trying to boot from MMC1
> >> INF TEE-CORE:init_primary_helper:319: Initializing (1.0.1-65-gf1567d3-dev 
> >> #22 Fri Mar 24 06:16:54 UTC 2017 arm)
> >> INF TEE-CORE:init_primary_helper:320: Release version: 1.9
> >> INF TEE-CORE:init_teecore:79: teecore inits done
> >> [hangs here]
> >>
> >> [1]
> >> TPL Inittimer init done
> >> Returning to boot ROM...
> >>
> >> U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
> >> Trying to boot from MMC1
> >> INF [0x0] TEE-CORE:init_primary_helper:366: Initializing 
> >> (1.1.0-120-gb4aded8-dev #3 Wed Dec 28 01:56:52 UTC 2016 arm)
> >> INF [0x0] TEE-CORE:init_primary_helper:367: Release version: 1.6
> >> INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
> >> [hangs here]
> >>
> >> [2]
> >> make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x
> >>   CHK out/arm-plat-rockchip/conf.mk
> >>   UPD out/arm-plat-rockchip/conf.mk
> >>   CHK out/arm-plat-rockchip/include/generated/conf.h
> >>   UPD out/arm-plat-rockchip/include/generated/conf.h
> >>   CHK out/arm-plat-rockchip/core/include/generated/asm-defines.h
> >> make: *** No rule, to create „core/include/tee/tee_cryp_provider.h“,  
> >> needed by
> >>   „out/arm-plat-rockchip/core/arch/arm/kernel/user_ta.o“.
> >>
> > make clean; git clean -fx..; then try again
> >
> >> [3]
> >> TPL Inittimer init done
> >> Returning to boot ROM...
> >>
> >> U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
> >> Trying to boot from MMC1
> >>
> >>
> >> U-Boot 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 21:29:43 +0100)
> >>
> >> Model: Nexbox A95X R1
> >> DRAM:  1022 MiB
> >> [...]
> >> Starting kernel ...
> >>
> >> [0.00] Booting Linux on physical CPU 0xf00
> >> [0.00] Linux version 4.14.0-13997-g55102e6ed32a-dirty 
> >> (hstuebner@phil) (gcc version 7.2.0 (Debian 7.2.0-11)) #437 SMP Mon Nov 20 
> >> 11:33:35 CET 2017
> >> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), 
> >> cr=10c5387d
> >> [0.00] CPU: div instructions available: patching division code
> >> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> >> instruction cache
> >> [0.00] OF: fdt: Machine model: Nexbox A95X R1
> >> [0.00] earlycon: uart8250 at MMIO32 0x1103 (options '')
> >> [0.00] bootconsole [uart8250] enabled
> >> [0.00] Memory policy: Data cache writealloc
> >> [0.00] efi: Getting EFI parameters from FDT:
> >> [0.00] efi: UEFI not found.
> >> [0.00] cma: Reserved 64 MiB at 0x9c00
> >> [0.00] psci: probing for conduit method from DT.
> >> [0.00] psci: PSCIv1.0 detected in firmware.
> >> [0.00] psci: Using standard PSCI v0.2 function IDs
> >> [0.00] psci: MIGRATE_INFO_TYPE not supported.
> >> [0.00] random: fast init done
> >> [0.00] percpu: Embedded 17 pages/cpu @ef7a4000 s39116 r8192 d22324 
> >> u69632
> >> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 
> >> 260096
> >> [...]
> >> [0.00] CPU0: thread -1, cpu 0, socket 15, mpidr 8f00
> >> [0.00] Setting up static identity map for 0x6030 - 0x603000a0
> >> [0.00] Hierarchical SRCU implementation.
> >> [0.00] EFI services will not be available.
> >> [0.00] smp: 

Re: [U-Boot] [PATCH v2 1/1] ubifs: avoid possible NULL dereference

[Heinrich Schuchardt]

On 11/21/2017 11:40 PM, Ladislav Michl wrote:

On Tue, Nov 21, 2017 at 11:06:35PM +0100, Heinrich Schuchardt wrote:

If 'file' cannot be allocated due to an out of memory
situation, NULL is dereferenced.

Variables file and dentry are not needed at all.
So let's eliminate them.

When debugging this patch also avoids a misleading message
"cannot find next direntry, error %d" in case of an out of
memory situation. It is sufficent to write
"%s: Error, no memory for malloc!\n" in this case.

Reported-by: Ladislav Michl 
Reported-by: Alex Sadovsky 
Signed-off-by: Heinrich Schuchardt 
---
  fs/ubifs/ubifs.c | 25 ++---
  1 file changed, 2 insertions(+), 23 deletions(-)

diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 4465523d5f..f3d190c763 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -393,29 +393,18 @@ static int ubifs_finddir(struct super_block *sb, char 
*dirname,
union ubifs_key key;
struct ubifs_dent_node *dent;
struct ubifs_info *c;
-   struct file *file;
-   struct dentry *dentry;
struct inode *dir;
int ret = 0;
  
-	file = kzalloc(sizeof(struct file), 0);

-   dentry = kzalloc(sizeof(struct dentry), 0);
dir = kzalloc(sizeof(struct inode), 0);
-   if (!file || !dentry || !dir) {
+   if (!dir) {
printf("%s: Error, no memory for malloc!\n", __func__);
-   err = -ENOMEM;
-   goto out;
+   goto out_free;
}
  
  	dir->i_sb = sb;

-   file->f_path.dentry = dentry;
-   file->f_path.dentry->d_parent = dentry;
-   file->f_path.dentry->d_inode = dir;
-   file->f_path.dentry->d_inode->i_ino = root_inum;
c = sb->s_fs_info;
  
-	dbg_gen("dir ino %lu, f_pos %#llx", dir->i_ino, file->f_pos);

-
/* Find the first entry in TNC and save it */
lowest_dent_key(c, , dir->i_ino);
nm.name = NULL;
@@ -425,9 +414,6 @@ static int ubifs_finddir(struct super_block *sb, char 
*dirname,
goto out;
}
  
-	file->f_pos = key_hash_flash(c, >key);

-   file->private_data = dent;
-
while (1) {
dbg_gen("feed '%s', ino %llu, new f_pos %#x",
dent->name, (unsigned long long)le64_to_cpu(dent->inum),
@@ -450,10 +436,6 @@ static int ubifs_finddir(struct super_block *sb, char 
*dirname,
err = PTR_ERR(dent);
goto out;
}
-
-   kfree(file->private_data);


We still need to kfree allocated 'dent' as it was previously allocated:
dent = kmalloc(zbr->len, GFP_NOFS);
in ubifs_tnc_next_ent.


I agree that there is a memory leak. But we should put fixing that into 
a separate patch so that we can test both modifications separately.


It is not enough to kfree(dent).
ubifs_tnc_next_ent may return ERR_PTR(err) and we do not want to pass 
this value to kfree.


As Wolfgang wrote we should pass error codes to the calling chain of 
ubifs_finddir(), i.e. ubifs_findfile(), ubifs_size(), ubifs_read, 
ubifs_exists(), ubifs_ls(), ...


The code also lacks support for the driver model.

So a lot of other patches needed.


If you think this patch fixes what it promises to fix, please, add your 
review comment.


Best regards

Heinrich




-   file->f_pos = key_hash_flash(c, >key);
-   file->private_data = dent;
cond_resched();
}
  
@@ -462,9 +444,6 @@ out:

dbg_gen("cannot find next direntry, error %d", err);
  
  out_free:

-   kfree(file->private_data);


Same as above.


-   free(file);
-   free(dentry);
free(dir);
  
  	return ret;

--
2.11.0



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

Re: [U-Boot] [PATCH u-boot 1/2] arm: Add LibreTech CC support based on Meson GXL family

[Neil Armstrong]

Hi Simon,

On 21/11/2017 05:08, Simon Glass wrote:
> Hi Neil,
> 
> On 20 November 2017 at 08:04, Neil Armstrong  wrote:
>> This adds platform code for the Libre Computer CC "Le Potato" board based on 
>> a
>> Meson GXL (S905X) SoC with the Meson GXL configuration.
>>
>> This initial submission supports UART, MMC/SDCard and Ethernet with the
>> Internal RMII PHY.
>>
>> The meson-gxl-s905x-libretech-cc.dts is synchronised from the linux 4.13
>> stable tree as of 4.13.8.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  arch/arm/dts/Makefile |   3 +-
>>  arch/arm/dts/meson-gxl-s905x-libretech-cc.dts | 171 
>> ++
>>  arch/arm/mach-meson/Kconfig   |   9 ++
>>  board/amlogic/libretech-cc/Kconfig|  12 ++
>>  board/amlogic/libretech-cc/MAINTAINERS|   6 +
>>  board/amlogic/libretech-cc/Makefile   |   8 ++
>>  board/amlogic/libretech-cc/README |  96 +++
>>  board/amlogic/libretech-cc/libretech-cc.c |  58 +
>>  configs/libretech-cc_defconfig|  35 ++
>>  include/configs/libretech-cc.h|  24 
>>  10 files changed, 421 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/arm/dts/meson-gxl-s905x-libretech-cc.dts
>>  create mode 100644 board/amlogic/libretech-cc/Kconfig
>>  create mode 100644 board/amlogic/libretech-cc/MAINTAINERS
>>  create mode 100644 board/amlogic/libretech-cc/Makefile
>>  create mode 100644 board/amlogic/libretech-cc/README
>>  create mode 100644 board/amlogic/libretech-cc/libretech-cc.c
>>  create mode 100644 configs/libretech-cc_defconfig
>>  create mode 100644 include/configs/libretech-cc.h
> 
> Reviewed-by: Simon Glass 
> 
> Please see below.
> 
>>
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index cd540e9..1845552 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -55,7 +55,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>> rv1108-evb.dtb
>>  dtb-$(CONFIG_ARCH_MESON) += \
>> meson-gxbb-odroidc2.dtb \
>> -   meson-gxl-s905x-p212.dtb
>> +   meson-gxl-s905x-p212.dtb \
>> +   meson-gxl-s905x-libretech-cc.dtb
>>  dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
>> tegra20-medcom-wide.dtb \
>> tegra20-paz00.dtb \
>> diff --git a/arch/arm/dts/meson-gxl-s905x-libretech-cc.dts 
>> b/arch/arm/dts/meson-gxl-s905x-libretech-cc.dts
>> new file mode 100644
>> index 000..266fbcf
>> --- /dev/null
>> +++ b/arch/arm/dts/meson-gxl-s905x-libretech-cc.dts
>> @@ -0,0 +1,171 @@
>> +/*
>> + * Copyright (c) 2017 BayLibre, SAS.
>> + * Author: Neil Armstrong 
>> + * Author: Jerome Brunet 
>> + *
>> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include 
>> +
>> +#include "meson-gxl-s905x.dtsi"
>> +
>> +/ {
>> +   compatible = "libretech,cc", "amlogic,s905x", "amlogic,meson-gxl";
>> +   model = "Libre Technology CC";
>> +
>> +   aliases {
>> +   serial0 = _AO;
>> +   };
>> +
>> +   chosen {
>> +   stdout-path = "serial0:115200n8";
>> +   };
>> +
>> +   cvbs-connector {
>> +   compatible = "composite-video-connector";
>> +
>> +   port {
>> +   cvbs_connector_in: endpoint {
>> +   remote-endpoint = <_vdac_out>;
>> +   };
>> +   };
>> +   };
>> +
>> +   emmc_pwrseq: emmc-pwrseq {
>> +   compatible = "mmc-pwrseq-emmc";
>> +   reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
>> +   };
>> +
>> +   hdmi-connector {
>> +   compatible = "hdmi-connector";
>> +   type = "a";
>> +
>> +   port {
>> +   hdmi_connector_in: endpoint {
>> +   remote-endpoint = <_tx_tmds_out>;
>> +   };
>> +   };
>> +   };
>> +
>> +   leds {
>> +   compatible = "gpio-leds";
>> +
>> +   system {
>> +   label = "librecomputer:system-status";
>> +   gpios = < GPIODV_24 GPIO_ACTIVE_HIGH>;
>> +   default-state = "on";
>> +   panic-indicator;
>> +   };
>> +
>> +   blue {
>> +   label = "librecomputer:blue";
>> +   gpios = <_ao GPIOAO_2 GPIO_ACTIVE_HIGH>;
>> +   linux,default-trigger = "heartbeat";
>> +   };
>> +   };
>> +
>> +   memory@0 {
>> +   device_type = "memory";
>> +   reg = <0x0 0x0 0x0 0x8000>;
>> +   };
>> +
>> +   vcc_3v3: regulator-vcc_3v3 {
>> +   compatible = "regulator-fixed";
>> +   regulator-name = "VCC_3V3";
>> +   regulator-min-microvolt = <330>;
>> +   

[U-Boot] [PATCH 1/3] imx: Add a common way for detecting NXP boards revision

[Fabio Estevam]

From: Fabio Estevam 

NXP development boards based on i.MX6/i.MX7 contain the board
revision information stored in the fuses.

Introduce a common function that can be shared by different boards and
convert mx6sabreauto to use this new mechanism.

Signed-off-by: Fabio Estevam 
---
 arch/arm/include/asm/mach-imx/sys_proto.h   |  3 ++
 arch/arm/mach-imx/Kconfig   |  8 +
 arch/arm/mach-imx/cpu.c | 27 +
 board/freescale/mx6sabreauto/mx6sabreauto.c | 47 ++---
 configs/mx6sabreauto_defconfig  |  1 +
 5 files changed, 41 insertions(+), 45 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index 7036343..d5e3eec 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -109,6 +109,9 @@ void imx_set_wdog_powerdown(bool enable);
 
 int board_mmc_get_env_dev(int devno);
 
+int nxp_board_rev(void);
+const char *nxp_board_rev_string(void);
+
 /*
  * Initializes on-chip ethernet controllers.
  * to override, implement board_eth_init()
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index cd8b8d2..81ab125 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -61,3 +61,11 @@ config CMD_HDMIDETECT
help
  This enables the 'hdmidet' command which detects if an HDMI monitor
  is connected.
+
+config NXP_BOARD_REVISION
+   bool "Read NXP board revision from fuses"
+   depends on ARCH_MX6 || ARCH_MX7
+   help
+ NXP boards based on i.MX6/7 contain the board revision information
+ stored in the fuses. Select this option if you want to be able to
+ retrieve the board revision information.
diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
index 18205dc..84e829e 100644
--- a/arch/arm/mach-imx/cpu.c
+++ b/arch/arm/mach-imx/cpu.c
@@ -323,3 +323,30 @@ void set_chipselect_size(int const cs_size)
 
writel(reg, _regs->gpr[1]);
 }
+
+#ifdef CONFIG_NXP_BOARD_REVISION
+int nxp_board_rev(void)
+{
+   /*
+* Get Board ID information from OCOTP_GP1[15:8]
+* RevA: 0x1
+* RevB: 0x2
+* RevC: 0x3
+*/
+   struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+   struct fuse_bank *bank = >bank[4];
+   struct fuse_bank4_regs *fuse =
+   (struct fuse_bank4_regs *)bank->fuse_regs;
+
+   return (readl(>gp1) >> 8 & 0x0F);
+}
+
+const char *nxp_board_rev_string(void)
+{
+   char *rev = "A" - 1;
+
+   rev += nxp_board_rev();
+
+   return rev;
+}
+#endif
diff --git a/board/freescale/mx6sabreauto/mx6sabreauto.c 
b/board/freescale/mx6sabreauto/mx6sabreauto.c
index bdeb5f7..ced254a 100644
--- a/board/freescale/mx6sabreauto/mx6sabreauto.c
+++ b/board/freescale/mx6sabreauto/mx6sabreauto.c
@@ -397,39 +397,9 @@ int board_eth_init(bd_t *bis)
return cpu_eth_init(bis);
 }
 
-#define BOARD_REV_B  0x200
-#define BOARD_REV_A  0x100
-
-static int mx6sabre_rev(void)
-{
-   /*
-* Get Board ID information from OCOTP_GP1[15:8]
-* i.MX6Q ARD RevA: 0x01
-* i.MX6Q ARD RevB: 0x02
-*/
-   struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
-   struct fuse_bank *bank = >bank[4];
-   struct fuse_bank4_regs *fuse =
-   (struct fuse_bank4_regs *)bank->fuse_regs;
-   int reg = readl(>gp1);
-   int ret;
-
-   switch (reg >> 8 & 0x0F) {
-   case 0x02:
-   ret = BOARD_REV_B;
-   break;
-   case 0x01:
-   default:
-   ret = BOARD_REV_A;
-   break;
-   }
-
-   return ret;
-}
-
 u32 get_board_rev(void)
 {
-   int rev = mx6sabre_rev();
+   int rev = nxp_board_rev();
 
return (get_cpu_rev() & ~(0xF << 8)) | rev;
 }
@@ -703,20 +673,7 @@ int board_late_init(void)
 
 int checkboard(void)
 {
-   int rev = mx6sabre_rev();
-   char *revname;
-
-   switch (rev) {
-   case BOARD_REV_B:
-   revname = "B";
-   break;
-   case BOARD_REV_A:
-   default:
-   revname = "A";
-   break;
-   }
-
-   printf("Board: MX6Q-Sabreauto rev%s\n", revname);
+   printf("Board: MX6Q-Sabreauto rev%s\n", nxp_board_rev_string());
 
return 0;
 }
diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
index 418a836..215700b 100644
--- a/configs/mx6sabreauto_defconfig
+++ b/configs/mx6sabreauto_defconfig
@@ -8,6 +8,7 @@ CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_NXP_BOARD_REVISION=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 # CONFIG_CONSOLE_MUX is not set
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
-- 
2.7.4

___
U-Boot mailing list

[U-Boot] [PATCH 3/3] mx6sxsabresd: Use PARTUUID to specify the rootfs location

[Fabio Estevam]

From: Fabio Estevam 

mx6sxsabresd can run different kernel versions, such as NXP 4.1 or mainline.

Currently the rootfs location is passed via mmcblk number and the
problem with this approach is that the mmcblk number for the SD
card changes depending on the kernel version.

In order to avoid such issue, use the UUID method to specify the
rootfs location.

Signed-off-by: Fabio Estevam 
---
 configs/mx6sxsabresd_defconfig | 1 +
 include/configs/mx6sxsabresd.h | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/configs/mx6sxsabresd_defconfig b/configs/mx6sxsabresd_defconfig
index ac36a18..b707322 100644
--- a/configs/mx6sxsabresd_defconfig
+++ b/configs/mx6sxsabresd_defconfig
@@ -12,6 +12,7 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
index 85b8601..906e677 100644
--- a/include/configs/mx6sxsabresd.h
+++ b/include/configs/mx6sxsabresd.h
@@ -58,9 +58,9 @@

"videomode=video=ctfb:x:800,y:480,depth:24,pclk:29850,le:89,ri:164,up:23,lo:10,hs:10,vs:10,sync:0,vmode:0\0"
 \
"mmcdev=2\0" \
"mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
+   "finduuid=part uuid mmc 2:2 uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
+   "root=PARTUUID=${uuid} rootwait rw\0" \
"loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
@@ -68,6 +68,7 @@
"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
"loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
"mmcboot=echo Booting from mmc ...; " \
+   "run finduuid; " \
"run mmcargs; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
"if run loadfdt; then " \
-- 
2.7.4

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

[U-Boot] [PATCH 2/3] mx6sxsabresd: Load the correct dtb for revA board

[Fabio Estevam]

From: Fabio Estevam 

Currently only imx6sx-sdb.dtb is loaded, but if revA board is used the
correct dtb is imx6sx-sdb-reva.dtb, so make this possible.

While at it, remove an extra 'mmc dev'.

Signed-off-by: Fabio Estevam 
---
 arch/arm/mach-imx/mx6/Kconfig   |  1 +
 board/freescale/mx6sxsabresd/mx6sxsabresd.c | 16 +++-
 configs/mx6sxsabresd_defconfig  |  1 +
 include/configs/mx6sxsabresd.h  |  8 ++--
 4 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 6f5a92a..52d9984 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -266,6 +266,7 @@ config TARGET_MX6SLLEVK
 
 config TARGET_MX6SXSABRESD
bool "mx6sxsabresd"
+   select BOARD_LATE_INIT
select MX6SX
select SUPPORT_SPL
select DM
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c 
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 2aeef61..8a918a5 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -540,9 +540,23 @@ int board_init(void)
return 0;
 }
 
+static bool is_reva(void)
+{
+   return (nxp_board_rev() == 1);
+}
+
+int board_late_init(void)
+{
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+   if (is_reva())
+   env_set("board_rev", "REVA");
+#endif
+   return 0;
+}
+
 int checkboard(void)
 {
-   puts("Board: MX6SX SABRE SDB\n");
+   printf("Board: MX6SX SABRE SDB rev%s\n", nxp_board_rev_string());
 
return 0;
 }
diff --git a/configs/mx6sxsabresd_defconfig b/configs/mx6sxsabresd_defconfig
index c4eb7ca..ac36a18 100644
--- a/configs/mx6sxsabresd_defconfig
+++ b/configs/mx6sxsabresd_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_MX6SXSABRESD=y
 # CONFIG_CMD_BMODE is not set
+CONFIG_NXP_BOARD_REVISION=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6sxsabresd/imximage.cfg"
 # CONFIG_CONSOLE_MUX is not set
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
index 5ef78a7..85b8601 100644
--- a/include/configs/mx6sxsabresd.h
+++ b/include/configs/mx6sxsabresd.h
@@ -43,6 +43,7 @@
 #define UPDATE_M4_ENV ""
 #endif
 
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
 #define CONFIG_EXTRA_ENV_SETTINGS \
UPDATE_M4_ENV \
"script=boot.scr\0" \
@@ -104,10 +105,13 @@
"fi; " \
"else " \
"bootz; " \
-   "fi;\0"
+   "fi;\0" \
+   "findfdt="\
+   "if test test $board_rev = REVA ; then " \
+   "setenv fdt_file imx6sx-sdb-reva.dtb; fi; " \
 
 #define CONFIG_BOOTCOMMAND \
-  "mmc dev ${mmcdev};" \
+  "run findfdt; " \
   "mmc dev ${mmcdev}; if mmc rescan; then " \
   "if run loadbootscript; then " \
   "run bootscript; " \
-- 
2.7.4

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

[U-Boot] [PATCH v2 0/5] Add support for Amlogic GXL Based SBCs

[Neil Armstrong]

This patchset aimed to add minimal support for the following Amlogic GXL SoC
based board:
- LibreTech-CC
- Khadas VIM

The initial support is composed of :
- Minimal boot support with serial, MMC, Ethernet and SDCard
- Updated DTS from Linux 4.13.8

Commands to generate a valid binary are provided in the board README.

A common Ethernet init function is introduced to avoid duplicating
the same hardware init code.

The P212 and Odroid-C2 board are also converted to this common function
by this patchset.

The following work will be pushed later on :
- Support for dynamic reading of DDR memory size from registers
- USB DWC3 Host Support with PHY support

Changes since v1:
- Add common ethernet init function
- Switch P212 and Odroid-C2 to use this ethernet init function
- Fix typos in READMEs
- Drop #define CONFIG_CONS_INDEX

Neil Armstrong (5):
  ARM: arch-meson: add ethernet common init function
  board: odroid-c2: use common ethernet init function
  board: p212: use common ethernet init function
  arm: Add LibreTech CC support based on Meson GXL family
  arm: Add Khadas VIM support based on Meson GXL family

 arch/arm/dts/Makefile |   4 +-
 arch/arm/dts/meson-gxl-s905x-khadas-vim.dts   | 137 +
 arch/arm/dts/meson-gxl-s905x-libretech-cc.dts | 171 ++
 arch/arm/include/asm/arch-meson/eth.h |  15 +++
 arch/arm/mach-meson/Kconfig   |  18 +++
 arch/arm/mach-meson/Makefile  |   2 +-
 arch/arm/mach-meson/eth.c |  53 
 board/amlogic/khadas-vim/Kconfig  |  12 ++
 board/amlogic/khadas-vim/MAINTAINERS  |   6 +
 board/amlogic/khadas-vim/Makefile |   8 ++
 board/amlogic/khadas-vim/README   |  96 +++
 board/amlogic/khadas-vim/khadas-vim.c |  48 
 board/amlogic/libretech-cc/Kconfig|  12 ++
 board/amlogic/libretech-cc/MAINTAINERS|   6 +
 board/amlogic/libretech-cc/Makefile   |   8 ++
 board/amlogic/libretech-cc/README |  96 +++
 board/amlogic/libretech-cc/libretech-cc.c |  52 
 board/amlogic/odroid-c2/odroid-c2.c   |  11 +-
 board/amlogic/p212/p212.c |  14 +--
 configs/khadas-vim_defconfig  |  35 ++
 configs/libretech-cc_defconfig|  35 ++
 include/configs/khadas-vim.h  |  21 
 include/configs/libretech-cc.h|  21 
 23 files changed, 858 insertions(+), 23 deletions(-)
 create mode 100644 arch/arm/dts/meson-gxl-s905x-khadas-vim.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905x-libretech-cc.dts
 create mode 100644 arch/arm/include/asm/arch-meson/eth.h
 create mode 100644 arch/arm/mach-meson/eth.c
 create mode 100644 board/amlogic/khadas-vim/Kconfig
 create mode 100644 board/amlogic/khadas-vim/MAINTAINERS
 create mode 100644 board/amlogic/khadas-vim/Makefile
 create mode 100644 board/amlogic/khadas-vim/README
 create mode 100644 board/amlogic/khadas-vim/khadas-vim.c
 create mode 100644 board/amlogic/libretech-cc/Kconfig
 create mode 100644 board/amlogic/libretech-cc/MAINTAINERS
 create mode 100644 board/amlogic/libretech-cc/Makefile
 create mode 100644 board/amlogic/libretech-cc/README
 create mode 100644 board/amlogic/libretech-cc/libretech-cc.c
 create mode 100644 configs/khadas-vim_defconfig
 create mode 100644 configs/libretech-cc_defconfig
 create mode 100644 include/configs/khadas-vim.h
 create mode 100644 include/configs/libretech-cc.h

-- 
2.7.4

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

Re: [U-Boot] [PATCH u-boot 2/2] arm: Add Khadas VIM support based on Meson GXL family

[Neil Armstrong]

On 21/11/2017 05:09, Simon Glass wrote:
> Hi Neil,
> 
> On 20 November 2017 at 08:04, Neil Armstrong  wrote:
>> This adds platform code for the Khadas VIM board based on a
>> Meson GXL (S905X) SoC with the Meson GXL configuration.
>>
>> This initial submission supports UART, MMC/SDCard and Ethernet with the
>> Internal RMII PHY.
>>
>> The meson-gxl-s905x-khadas-vim.dts is synchronised from the linux 4.13
>> stable tree as of 4.13.8.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  arch/arm/dts/Makefile   |   3 +-
>>  arch/arm/dts/meson-gxl-s905x-khadas-vim.dts | 137 
>> 
>>  arch/arm/mach-meson/Kconfig |   9 ++
>>  board/amlogic/khadas-vim/Kconfig|  12 +++
>>  board/amlogic/khadas-vim/MAINTAINERS|   6 ++
>>  board/amlogic/khadas-vim/Makefile   |   8 ++
>>  board/amlogic/khadas-vim/README |  96 +++
>>  board/amlogic/khadas-vim/khadas-vim.c   |  58 
>>  configs/khadas-vim_defconfig|  35 +++
>>  include/configs/khadas-vim.h|  24 +
>>  10 files changed, 387 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/arm/dts/meson-gxl-s905x-khadas-vim.dts
>>  create mode 100644 board/amlogic/khadas-vim/Kconfig
>>  create mode 100644 board/amlogic/khadas-vim/MAINTAINERS
>>  create mode 100644 board/amlogic/khadas-vim/Makefile
>>  create mode 100644 board/amlogic/khadas-vim/README
>>  create mode 100644 board/amlogic/khadas-vim/khadas-vim.c
>>  create mode 100644 configs/khadas-vim_defconfig
>>  create mode 100644 include/configs/khadas-vim.h
> 
> Sees like quite a bit of duplication with the previous patch,
> including the README. Can you fix this please?

For the README part, no, because they are quite different boards and
the instructions looks similar but uses quite different vendor
source to generate the ATF blobs.

For the board.c file, yes, I can definitely add a common ethernet
setup function to avoid duplication.

> 
> - Simon
> 

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

Re: [U-Boot] [PATCH] power: pmic/regulator: Add basic support for TPS65910

[Felix Brack]

Hello Simon,

Many thanks for taking the time to review my patch.

On 20.11.2017 16:38, Simon Glass wrote:
> Hi Felix,
> 
> On 8 November 2017 at 04:04, Felix Brack  wrote:
>> Texas Instrument's TPS65910 PMIC contains 3 buck DC-DC converts, one
>> boost DC-DC converter and 8 LDOs. This patch implements driver model
>> support for the TPS65910 PMIC and its regulators making the get/set
>> API for regulator value/enable available.
>> This patch depends on the patch "am33xx: Add a function to query MPU
>> voltage in uV" to build correctly. For boards relying on the DT
>> include file tps65910.dtsi the v2 patch "power: extend prefix match
>> to regulator-name property" and an appropriate regulator naming is
>> also required.
>>
>> Signed-off-by: Felix Brack 
>> ---
>>
>>  drivers/power/pmic/Kconfig   |   8 +
>>  drivers/power/pmic/Makefile  |   1 +
>>  drivers/power/pmic/pmic_tps65910_dm.c| 138 
>>  drivers/power/regulator/Kconfig  |   7 +
>>  drivers/power/regulator/Makefile |   1 +
>>  drivers/power/regulator/tps65910_regulator.c | 493 
>> +++
>>  include/power/tps65910_pmic.h| 130 +++
>>  7 files changed, 778 insertions(+)
>>  create mode 100644 drivers/power/pmic/pmic_tps65910_dm.c
>>  create mode 100644 drivers/power/regulator/tps65910_regulator.c
>>  create mode 100644 include/power/tps65910_pmic.h
>>
>> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
>> index e3f9e4d..5d49c93 100644
>> --- a/drivers/power/pmic/Kconfig
>> +++ b/drivers/power/pmic/Kconfig
>> @@ -201,3 +201,11 @@ config POWER_MC34VR500
>> The MC34VR500 is used in conjunction with the FSL T1 and LS1 series
>> SoC. It provides 4 buck DC-DC convertors and 5 LDOs, and it is 
>> accessed
>> via an I2C interface.
>> +
>> +config DM_PMIC_TPS65910
>> +   bool "Enable driver for Texas Instruments TPS65910 PMIC"
>> +   depends on DM_PMIC
>> +   ---help---
>> +   The TPS65910 is a PMIC containing 3 buck DC-DC converters, one boost
>> +   DC-DC converter, 8 LDOs and a RTC. This driver binds the SMPS and LDO
>> +   pmic children.
> 
> Great!
> 
>> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
>> index f7bdfa5..7d6c583 100644
>> --- a/drivers/power/pmic/Makefile
>> +++ b/drivers/power/pmic/Makefile
>> @@ -19,6 +19,7 @@ obj-$(CONFIG_PMIC_RK8XX) += rk8xx.o
>>  obj-$(CONFIG_PMIC_RN5T567) += rn5t567.o
>>  obj-$(CONFIG_PMIC_TPS65090) += tps65090.o
>>  obj-$(CONFIG_PMIC_S5M8767) += s5m8767.o
>> +obj-$(CONFIG_DM_PMIC_TPS65910) += pmic_tps65910_dm.o
>>  obj-$(CONFIG_$(SPL_)PMIC_PALMAS) += palmas.o
>>  obj-$(CONFIG_$(SPL_)PMIC_LP873X) += lp873x.o
>>  obj-$(CONFIG_$(SPL_)PMIC_LP87565) += lp87565.o
>> diff --git a/drivers/power/pmic/pmic_tps65910_dm.c 
>> b/drivers/power/pmic/pmic_tps65910_dm.c
>> new file mode 100644
>> index 000..1410657
>> --- /dev/null
>> +++ b/drivers/power/pmic/pmic_tps65910_dm.c
>> @@ -0,0 +1,138 @@
>> +/*
>> + * Copyright (C) EETS GmbH, 2017, Felix Brack 
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +static const struct pmic_child_info pmic_children_info[] = {
>> +   { .prefix = "ldo_", .driver = TPS65910_LDO_DRIVER },
>> +   { .prefix = "buck_", .driver = TPS65910_BUCK_DRIVER },
>> +   { .prefix = "boost_", .driver = TPS65910_BOOST_DRIVER },
>> +   { },
>> +};
>> +
>> +static const char * const supply_names[] = {
>> +   "vccio-supply",
>> +   "vcc1-supply",
>> +   "vcc2-supply",
>> +   "vcc3-supply",
>> +   "vcc4-supply",
>> +   "vcc5-supply",
>> +   "vcc6-supply",
>> +   "vcc7-supply",
>> +};
>> +
>> +static int pmic_tps65910_reg_count(struct udevice *dev)
>> +{
>> +   return TPS65910_NUM_REGS;
>> +}
>> +
>> +static int pmic_tps65910_write(struct udevice *dev, uint reg, const u8 
>> *buffer,
>> +  int len)
>> +{
>> +   if (dm_i2c_write(dev, reg, buffer, len)) {
>> +   error("%s write error on register %02x\n", dev->name, reg);
>> +   return -EIO;
> 
> Can you return ret here instead (and in cases below)? I does not seem
> necessary to obscure the original error.
> 
> [...]
>
Yes for the calls to dm_i2c_write() and dm_i2c_read(). How about the
call to ofnode_valid()? Is it okay to return -ENXIO instead of NULL in
case of failure?

>> diff --git a/drivers/power/regulator/Kconfig 
>> b/drivers/power/regulator/Kconfig
>> index c82a936..2d6a150 100644
>> --- a/drivers/power/regulator/Kconfig
>> +++ b/drivers/power/regulator/Kconfig
>> @@ -168,3 +168,10 @@ config DM_REGULATOR_LP87565
>> LP87565 series of PMICs have 4 single phase BUCKs that can also
>> be configured in multi phase modes. The driver implements
>> 

Re: [U-Boot] [PATCH 0/5] mmc: fixes for HS200/UHS core support

[Jaehoon Chung]

On 11/22/2017 12:13 AM, Jean-Jacques Hiblot wrote:
> This series applies on top of "[PATCH v2 00/26] mmc: Add support for HS200
> and UHS modes"
> 
> It fixes a bug with old SD and MMC cards that support only the legacy mode.
> It also addresses the comments made on the mailing list:
> * dump card and host capabilities in debug mode
> * use 1-bit if the DTS property 'bus-width' is not present.
> * recognize the "mmc-ddr-1_2v" and "mmc-hs200-1_2v" DTS properties
> 
> Tested on DRA7, DRA72 and AM335x

Thanks for sending patches. After testing with my boards, will update.
For your patches, i made the testing-uhs-supporting branch on u-boot-mmc.

At least, i will share the result about testing with my boards.

Best Regards,
Jaehoon Chung

> 
> Jean-Jacques Hiblot (5):
>   dm: mmc: updated mmc_of_parse() to not fail because of an invalid
> bus-width
>   mmc: dm: support "mmc-ddr-1_2v" and "mmc-hs200-1_2v" boolean
> properties
>   mmc: dump card and host capabilities if debug is enabled
>   mmc: Fixed a problem with old sd or mmc that do not support High speed
>   mmc: all hosts support 1-bit bus width and legacy timings
> 
>  drivers/mmc/mmc-uclass.c | 11 ---
>  drivers/mmc/mmc.c| 24 +++-
>  2 files changed, 27 insertions(+), 8 deletions(-)
> 

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

[U-Boot] [PATCH] fix: nand: pxa3xx: fix defined but not used warnings

[Sean Nyekjaer]

bbt_mirror_descr and bbt_main_descr is defined but not used
when compiling without CONFIG_SYS_NAND_USE_FLASH_BBT set.

Signed-off-by: Sean Nyekjaer 
---
 drivers/mtd/nand/pxa3xx_nand.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 6ab3c8a25a..cedbb239b6 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -233,6 +233,7 @@ static struct pxa3xx_nand_flash builtin_flash_types[] = {
{ 0xba20, 16, 16, [3] },
 };
 
+#ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
 static u8 bbt_pattern[] = {'M', 'V', 'B', 'b', 't', '0' };
 static u8 bbt_mirror_pattern[] = {'1', 't', 'b', 'B', 'V', 'M' };
 
@@ -255,6 +256,7 @@ static struct nand_bbt_descr bbt_mirror_descr = {
.maxblocks = 8, /* Last 8 blocks in each chip */
.pattern = bbt_mirror_pattern
 };
+#endif
 
 static struct nand_ecclayout ecc_layout_2KB_bch4bit = {
.eccbytes = 32,
-- 
2.15.0

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

Re: [U-Boot] sdhci - review?

[Jaehoon Chung]

On 11/22/2017 09:27 PM, Tom Rini wrote:
> On Wed, Nov 22, 2017 at 05:25:02PM +0900, Jaehoon Chung wrote:
>> On 11/20/2017 09:52 PM, Jorge Ramirez wrote:
>>> On 11/10/2017 01:29 PM, Jorge Ramirez wrote:
 On 11/07/2017 11:48 PM, Tom Rini wrote:
> On Tue, Nov 07, 2017 at 08:13:02AM +0100, Jorge Ramirez wrote:
>> On 11/07/2017 12:28 AM, Tom Rini wrote:
>>> Hey all,
>>>
>>> It's release day and v2017.11-rc4 is out.  It's a week until release
>>> day.  Please let me know if you know of any regressions, thanks!
>> Hi Tom,
>>
>> emmc accesses are broken for dragonboard410c
>> I posted the fix [1] last week. will you merge it?

 just changed the email subject

> [1] is: https://patchwork.ozlabs.org/patch/833376/
>
> Jaehoon, are you OK with this patch?  Thanks!
>

>>>
>>> a ping on this matter - as the db410c maintainer a quick reminder that the 
>>> emmc support remains broken until this (above [1]) (or an alternative fix) 
>>> is merged.
>>
>> I sent the email to Tom about 1 weeks ago..if it doesn't apply yet, i will 
>> pick it..
>> Maybe i had replied with the my gmail account, something missed.
> 
> Yeah, I missed that, sorry.  Please put together a pull request of all
> the various outstanding MMC changes ASAP, thanks!

Thanks for checking! I will send PR with all.!

Best Regards,
Jaehoon Chung

> 

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

Re: [U-Boot] [PATCH 1/3] common: Fix-up MAC addr in dts by fetching env variable serially

[Prabhakar Kushwaha]

> -Original Message-
> From: York Sun
> Sent: Tuesday, November 21, 2017 10:52 PM
> To: Prabhakar Kushwaha ; u-
> b...@lists.denx.de
> Subject: Re: [PATCH 1/3] common: Fix-up MAC addr in dts by fetching env
> variable serially
> 
> On 11/21/2017 08:26 AM, Prabhakar Kushwaha wrote:
> > Current implementation of MAC address fix-up of device tree uses
> > tailing number behind "ethernet" found in "/aliases".  It is not
> > necessary for trailing number of "ethernet" to be sequential. There
> > can be hole in between or any node disabled.
> >
> > So provide support device tree fix-up of "ethernent" node with MAC
> > addresses fetched sequentially from environment variables.
> 
> My understanding is current implementation matches the trailing number
> behind "ethernet" found in "/aliases" with environmental variables
> ethNaddr (where N is 1, 2, 3, ... or absent). This doesn't require
> "ethernet" nodes or ethNaddr variables to be consecutive.
> 
> From your change, I understand you are trying to apply consecutive
> ethNaddr variables to "ethernet" nodes in the order they appear in
> device tree.
> 
> You didn't explain what benefit you get from this new scheme, or what
> problem you are trying to solve.
> 
> My understanding is you have device tree with some "ethernet" nodes
> disabled (or with gap in the numbering). You also have a pool of MAC
> addresses in the form of consecutive ethNaddr variables. You goal is to
> assign these ethNaddr to "ethernet" nodes in the order they appear in
> the device tree. Do I understand you correctly?

Yes this understanding is correct. 
I am parsing "ethernet" node from device tree and fixing up ethNaddr 
sequentially.


> 
> Is it possible to address this issue from another angle? How about
> setting ethNaddr variables in U-Boot according to the SerDes protocol?
> You may have explored this path already. Let me know why this doesn't work.

Yes, analyzed this path and figured out following 2 changes in u-boot

A) I2C EEPROM:  Here MAC number has to be read sequentially from EEPROM and 
they have to save as ethNaddr. here N is MAC number as per SerDes
  MAC number will be saved in ethaddr, eth1addr, eth2addr, eth3addr,  
eth10addr depending upon SerDes protocol
  
B) net/eth_legacy.c: eth_initialize()  --> eth_write_hwaddr
here each Ethernet driver read ethNaddr.  Here N represents eth_device-> index.
Please note eth_device->index in under control of Ethernet subsystem and  
incremented automatically per Ethernet device.

for a Ethernet device which require eth9addr (updated as part of A). It must 
have 10 ethernet device before it to get correct eth9addr. 
Hence a mapping required from eth_device->index to MAC number.  I wanted to 
avoid "B" to make sure Ethernet device initialization path remain unchanged. 

Hence chosen to update fdt_support.c  

-pk









> 
> >
> > Signed-off-by: Prabhakar Kushwaha 
> > ---
> >  README   | 10 ++
> >  common/fdt_support.c | 25 +
> >  2 files changed, 31 insertions(+), 4 deletions(-)
> >
> > diff --git a/README b/README
> > index 7a4f342..640b310 100644
> > --- a/README
> > +++ b/README
> > @@ -1603,6 +1603,16 @@ The following options need to be configured:
> >
> > See doc/README.link-local for more information.
> >
> > + - MAC address from environment variables
> > +
> > +   FDT_SEQ_MACADDR_FROM_ENV
> 
> Why not create a Kconfig option?
> 
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/5] board: odroid-c2: use common ethernet init function

[Neil Armstrong]

Switch Odroid-C2 Ethernet init to the common Ethernet init function.

Signed-off-by: Neil Armstrong 
---
 board/amlogic/odroid-c2/odroid-c2.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/board/amlogic/odroid-c2/odroid-c2.c 
b/board/amlogic/odroid-c2/odroid-c2.c
index a5ea8dc..62a2180 100644
--- a/board/amlogic/odroid-c2/odroid-c2.c
+++ b/board/amlogic/odroid-c2/odroid-c2.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #define EFUSE_SN_OFFSET20
 #define EFUSE_SN_SIZE  16
@@ -27,17 +27,10 @@ int misc_init_r(void)
char serial[EFUSE_SN_SIZE];
ssize_t len;
 
-   /* Set RGMII mode */
-   setbits_le32(GXBB_ETH_REG_0, GXBB_ETH_REG_0_PHY_INTF |
-GXBB_ETH_REG_0_TX_PHASE(1) |
-GXBB_ETH_REG_0_TX_RATIO(4) |
-GXBB_ETH_REG_0_PHY_CLK_EN |
-GXBB_ETH_REG_0_CLK_EN);
+   meson_gx_eth_init(PHY_INTERFACE_MODE_RGMII, false);
 
/* Enable power and clock gate */
setbits_le32(GXBB_GCLK_MPEG_0, GXBB_GCLK_MPEG_0_I2C);
-   setbits_le32(GXBB_GCLK_MPEG_1, GXBB_GCLK_MPEG_1_ETH);
-   clrbits_le32(GXBB_MEM_PD_REG_0, GXBB_MEM_PD_REG_0_ETH_MASK);
 
/* Reset PHY on GPIOZ_14 */
clrbits_le32(GXBB_GPIO_EN(3), BIT(14));
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 1/1] ubifs: avoid possible NULL dereference

[Ladislav Michl]

On Wed, Nov 22, 2017 at 01:37:54PM +0100, Heinrich Schuchardt wrote:
> On 11/21/2017 11:40 PM, Ladislav Michl wrote:
> > On Tue, Nov 21, 2017 at 11:06:35PM +0100, Heinrich Schuchardt wrote:
> > > If 'file' cannot be allocated due to an out of memory
> > > situation, NULL is dereferenced.
> > > 
> > > Variables file and dentry are not needed at all.
> > > So let's eliminate them.
> > > 
> > > When debugging this patch also avoids a misleading message
> > > "cannot find next direntry, error %d" in case of an out of
> > > memory situation. It is sufficent to write
> > > "%s: Error, no memory for malloc!\n" in this case.
> > > 
> > > Reported-by: Ladislav Michl 
> > > Reported-by: Alex Sadovsky 
> > > Signed-off-by: Heinrich Schuchardt 
> > > ---
> > >   fs/ubifs/ubifs.c | 25 ++---
> > >   1 file changed, 2 insertions(+), 23 deletions(-)
> > > 
> > > diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
> > > index 4465523d5f..f3d190c763 100644
> > > --- a/fs/ubifs/ubifs.c
> > > +++ b/fs/ubifs/ubifs.c
> > > @@ -393,29 +393,18 @@ static int ubifs_finddir(struct super_block *sb, 
> > > char *dirname,
> > >   union ubifs_key key;
> > >   struct ubifs_dent_node *dent;
> > >   struct ubifs_info *c;
> > > - struct file *file;
> > > - struct dentry *dentry;
> > >   struct inode *dir;
> > >   int ret = 0;
> > > - file = kzalloc(sizeof(struct file), 0);
> > > - dentry = kzalloc(sizeof(struct dentry), 0);
> > >   dir = kzalloc(sizeof(struct inode), 0);
> > > - if (!file || !dentry || !dir) {
> > > + if (!dir) {
> > >   printf("%s: Error, no memory for malloc!\n", __func__);
> > > - err = -ENOMEM;
> > > - goto out;
> > > + goto out_free;
> > >   }
> > >   dir->i_sb = sb;
> > > - file->f_path.dentry = dentry;
> > > - file->f_path.dentry->d_parent = dentry;
> > > - file->f_path.dentry->d_inode = dir;
> > > - file->f_path.dentry->d_inode->i_ino = root_inum;
> > >   c = sb->s_fs_info;
> > > - dbg_gen("dir ino %lu, f_pos %#llx", dir->i_ino, file->f_pos);
> > > -
> > >   /* Find the first entry in TNC and save it */
> > >   lowest_dent_key(c, , dir->i_ino);
> > >   nm.name = NULL;
> > > @@ -425,9 +414,6 @@ static int ubifs_finddir(struct super_block *sb, char 
> > > *dirname,
> > >   goto out;
> > >   }
> > > - file->f_pos = key_hash_flash(c, >key);
> > > - file->private_data = dent;
> > > -
> > >   while (1) {
> > >   dbg_gen("feed '%s', ino %llu, new f_pos %#x",
> > >   dent->name, (unsigned long 
> > > long)le64_to_cpu(dent->inum),
> > > @@ -450,10 +436,6 @@ static int ubifs_finddir(struct super_block *sb, 
> > > char *dirname,
> > >   err = PTR_ERR(dent);
> > >   goto out;
> > >   }
> > > -
> > > - kfree(file->private_data);
> > 
> > We still need to kfree allocated 'dent' as it was previously allocated:
> > dent = kmalloc(zbr->len, GFP_NOFS);
> > in ubifs_tnc_next_ent.
> 
> I agree that there is a memory leak. But we should put fixing that into a
> separate patch so that we can test both modifications separately.

There was no such memory leak before above patch.

> It is not enough to kfree(dent).
> ubifs_tnc_next_ent may return ERR_PTR(err) and we do not want to pass this
> value to kfree.

Nobody is claiming otherwise.

> As Wolfgang wrote we should pass error codes to the calling chain of
> ubifs_finddir(), i.e. ubifs_findfile(), ubifs_size(), ubifs_read,
> ubifs_exists(), ubifs_ls(), ...
> 
> The code also lacks support for the driver model.
> 
> So a lot of other patches needed.

Yes, but fix should not add another bug.

> If you think this patch fixes what it promises to fix, please, add your
> review comment.

What about (untested)?

diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 4465523d5f..64188d9f2d 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -388,47 +388,33 @@ out:
 static int ubifs_finddir(struct super_block *sb, char *dirname,
 unsigned long root_inum, unsigned long *inum)
 {
-   int err;
+   int err = 0;
struct qstr nm;
union ubifs_key key;
struct ubifs_dent_node *dent;
struct ubifs_info *c;
-   struct file *file;
-   struct dentry *dentry;
struct inode *dir;
-   int ret = 0;
 
-   file = kzalloc(sizeof(struct file), 0);
-   dentry = kzalloc(sizeof(struct dentry), 0);
dir = kzalloc(sizeof(struct inode), 0);
-   if (!file || !dentry || !dir) {
+   if (!dir) {
printf("%s: Error, no memory for malloc!\n", __func__);
-   err = -ENOMEM;
-   goto out;
+   return -ENOMEM;
}
 
dir->i_sb = sb;
-   file->f_path.dentry = dentry;
-   

Re: [U-Boot] [PATCH 00/10] rockchip: add tpl and OPTEE support for rk3229

[Joseph Chen]

在 2017/11/21 23:43, Andrew F. Davis 写道:

On 11/20/2017 03:25 PM, Heiko Stübner wrote:

Hi Kever,

Am Mittwoch, 6. September 2017, 10:14:27 CET schrieb Kever Yang:

Add some generic options for TPL support for arm 32bit, and then
and TPL support for rk3229(cortex-A7), and then add OPTEE support
in SPL.

I was now finally able to test this series and I'm getting mixed results.
I was following the instructions in the evb-rk3229 README file.


On the uboot side it seems to work nicely when applied against 2017.09.

But when I try to rebase it on top of the next branch of u-boot-rockchip
I end up with the TPL claiming a "Missing DTB", so it looks like it needs
a respin to follow the recent changes.

On the optee-side I also seem to do something wrong or so.
When using the binaries from the rkbin github repository I end up with
[0] and [1].
When compiling the most-recent optee it fails with [2].

With some intermediate optee or the one from Tony Xie's repository
it compiles and uboot seems to start, but then fails when the kernel tries
to bring up the secondary cpus [3]. And interestingly while it seems to go
through optee, I don't see any optee-messages.

If you could point me into the right direction, I would be very grateful :-)


Thanks
Heiko


[0]
TPL Inittimer init done
Returning to boot ROM...

U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
Trying to boot from MMC1
INF TEE-CORE:init_primary_helper:319: Initializing (1.0.1-65-gf1567d3-dev #22 
Fri Mar 24 06:16:54 UTC 2017 arm)
INF TEE-CORE:init_primary_helper:320: Release version: 1.9
INF TEE-CORE:init_teecore:79: teecore inits done
[hangs here]

[1]
TPL Inittimer init done
Returning to boot ROM...

U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
Trying to boot from MMC1
INF [0x0] TEE-CORE:init_primary_helper:366: Initializing 
(1.1.0-120-gb4aded8-dev #3 Wed Dec 28 01:56:52 UTC 2016 arm)
INF [0x0] TEE-CORE:init_primary_helper:367: Release version: 1.6
INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
[hangs here]

[2]
make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x
  CHK out/arm-plat-rockchip/conf.mk
  UPD out/arm-plat-rockchip/conf.mk
  CHK out/arm-plat-rockchip/include/generated/conf.h
  UPD out/arm-plat-rockchip/include/generated/conf.h
  CHK out/arm-plat-rockchip/core/include/generated/asm-defines.h
make: *** No rule, to create „core/include/tee/tee_cryp_provider.h“,  needed by
  „out/arm-plat-rockchip/core/arch/arm/kernel/user_ta.o“.


make clean; git clean -fx..; then try again


[3]
TPL Inittimer init done
Returning to boot ROM...

U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
Trying to boot from MMC1


U-Boot 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 21:29:43 +0100)

Model: Nexbox A95X R1
DRAM:  1022 MiB
[...]
Starting kernel ...

[0.00] Booting Linux on physical CPU 0xf00
[0.00] Linux version 4.14.0-13997-g55102e6ed32a-dirty (hstuebner@phil) 
(gcc version 7.2.0 (Debian 7.2.0-11)) #437 SMP Mon Nov 20 11:33:35 CET 2017
[0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt: Machine model: Nexbox A95X R1
[0.00] earlycon: uart8250 at MMIO32 0x1103 (options '')
[0.00] bootconsole [uart8250] enabled
[0.00] Memory policy: Data cache writealloc
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 64 MiB at 0x9c00
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.0 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: MIGRATE_INFO_TYPE not supported.
[0.00] random: fast init done
[0.00] percpu: Embedded 17 pages/cpu @ef7a4000 s39116 r8192 d22324 
u69632
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
[...]
[0.00] CPU0: thread -1, cpu 0, socket 15, mpidr 8f00
[0.00] Setting up static identity map for 0x6030 - 0x603000a0
[0.00] Hierarchical SRCU implementation.
[0.00] EFI services will not be available.
[0.00] smp: Bringing up secondary CPUs ...
[hangs here]


I've been here plenty of times when brining up OP-TEE on TI platforms,
for me it's OP-TEE parking the secondary CPUs in a bad way. I'm not sure
about the Rockchip arch, are the extra cores brought up with PSCI?
Anyway can you get JTAG on this device, see where the other cores are stuck.



If your OP-TEE is from Tony Xie's repository, I think the reason maybe 
that cntfrq register is not been initialized. core0 stucks at udelay() 
in the OP-TEE when it tries to bring up core1. So can you try to 
initialize cntfrq as 2400 in the SPL/TPL ? maybe it helps.


--
Best Regards

Re: [U-Boot] [PATCH 00/10] rockchip: add tpl and OPTEE support for rk3229

[Heiko Stuebner]

Am Dienstag, 21. November 2017, 09:43:57 CET schrieb Andrew F. Davis:
> On 11/20/2017 03:25 PM, Heiko Stübner wrote:
> > Hi Kever,
> > 
> > Am Mittwoch, 6. September 2017, 10:14:27 CET schrieb Kever Yang:
> >> Add some generic options for TPL support for arm 32bit, and then
> >> and TPL support for rk3229(cortex-A7), and then add OPTEE support
> >> in SPL.
> > 
> > I was now finally able to test this series and I'm getting mixed results.
> > I was following the instructions in the evb-rk3229 README file.
> > 
> > 
> > On the uboot side it seems to work nicely when applied against 2017.09.
> > 
> > But when I try to rebase it on top of the next branch of u-boot-rockchip
> > I end up with the TPL claiming a "Missing DTB", so it looks like it needs
> > a respin to follow the recent changes.
> > 
> > On the optee-side I also seem to do something wrong or so.
> > When using the binaries from the rkbin github repository I end up with
> > [0] and [1].
> > When compiling the most-recent optee it fails with [2].
> > 
> > With some intermediate optee or the one from Tony Xie's repository
> > it compiles and uboot seems to start, but then fails when the kernel tries
> > to bring up the secondary cpus [3]. And interestingly while it seems to go
> > through optee, I don't see any optee-messages.
> > 
> > If you could point me into the right direction, I would be very grateful :-)
> > 
> > 
> > Thanks
> > Heiko
> > 
> > 
> > [0]
> > TPL Inittimer init done
> > Returning to boot ROM...
> > 
> > U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
> > Trying to boot from MMC1
> > INF TEE-CORE:init_primary_helper:319: Initializing (1.0.1-65-gf1567d3-dev 
> > #22 Fri Mar 24 06:16:54 UTC 2017 arm)
> > INF TEE-CORE:init_primary_helper:320: Release version: 1.9
> > INF TEE-CORE:init_teecore:79: teecore inits done
> > [hangs here]
> > 
> > [1]
> > TPL Inittimer init done
> > Returning to boot ROM...
> > 
> > U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
> > Trying to boot from MMC1
> > INF [0x0] TEE-CORE:init_primary_helper:366: Initializing 
> > (1.1.0-120-gb4aded8-dev #3 Wed Dec 28 01:56:52 UTC 2016 arm)
> > INF [0x0] TEE-CORE:init_primary_helper:367: Release version: 1.6
> > INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
> > [hangs here]
> > 
> > [2]
> > make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x
> >  CHK out/arm-plat-rockchip/conf.mk
> >  UPD out/arm-plat-rockchip/conf.mk
> >  CHK out/arm-plat-rockchip/include/generated/conf.h
> >  UPD out/arm-plat-rockchip/include/generated/conf.h
> >  CHK out/arm-plat-rockchip/core/include/generated/asm-defines.h
> > make: *** No rule, to create „core/include/tee/tee_cryp_provider.h“,  
> > needed by
> >  „out/arm-plat-rockchip/core/arch/arm/kernel/user_ta.o“.
> > 
> 
> make clean; git clean -fx..; then try again
> 
> > [3]
> > TPL Inittimer init done
> > Returning to boot ROM...
> > 
> > U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
> > Trying to boot from MMC1
> > 
> > 
> > U-Boot 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 21:29:43 +0100)
> > 
> > Model: Nexbox A95X R1
> > DRAM:  1022 MiB
> > [...]
> > Starting kernel ...
> > 
> > [0.00] Booting Linux on physical CPU 0xf00
> > [0.00] Linux version 4.14.0-13997-g55102e6ed32a-dirty 
> > (hstuebner@phil) (gcc version 7.2.0 (Debian 7.2.0-11)) #437 SMP Mon Nov 20 
> > 11:33:35 CET 2017
> > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), 
> > cr=10c5387d
> > [0.00] CPU: div instructions available: patching division code
> > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> > instruction cache
> > [0.00] OF: fdt: Machine model: Nexbox A95X R1
> > [0.00] earlycon: uart8250 at MMIO32 0x1103 (options '')
> > [0.00] bootconsole [uart8250] enabled
> > [0.00] Memory policy: Data cache writealloc
> > [0.00] efi: Getting EFI parameters from FDT:
> > [0.00] efi: UEFI not found.
> > [0.00] cma: Reserved 64 MiB at 0x9c00
> > [0.00] psci: probing for conduit method from DT.
> > [0.00] psci: PSCIv1.0 detected in firmware.
> > [0.00] psci: Using standard PSCI v0.2 function IDs
> > [0.00] psci: MIGRATE_INFO_TYPE not supported.
> > [0.00] random: fast init done
> > [0.00] percpu: Embedded 17 pages/cpu @ef7a4000 s39116 r8192 d22324 
> > u69632
> > [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
> > [...]
> > [0.00] CPU0: thread -1, cpu 0, socket 15, mpidr 8f00
> > [0.00] Setting up static identity map for 0x6030 - 0x603000a0
> > [0.00] Hierarchical SRCU implementation.
> > [0.00] EFI services will not be available.
> > [0.00] smp: Bringing up secondary CPUs ...
> > [hangs here]
> > 
> 
> I've been here plenty of times when brining up OP-TEE on TI platforms,
> for me it's OP-TEE 

Re: [U-Boot] sdhci - review?

[Tom Rini]

On Wed, Nov 22, 2017 at 05:25:02PM +0900, Jaehoon Chung wrote:
> On 11/20/2017 09:52 PM, Jorge Ramirez wrote:
> > On 11/10/2017 01:29 PM, Jorge Ramirez wrote:
> >> On 11/07/2017 11:48 PM, Tom Rini wrote:
> >>> On Tue, Nov 07, 2017 at 08:13:02AM +0100, Jorge Ramirez wrote:
>  On 11/07/2017 12:28 AM, Tom Rini wrote:
> > Hey all,
> >
> > It's release day and v2017.11-rc4 is out.  It's a week until release
> > day.  Please let me know if you know of any regressions, thanks!
>  Hi Tom,
> 
>  emmc accesses are broken for dragonboard410c
>  I posted the fix [1] last week. will you merge it?
> >>
> >> just changed the email subject
> >>
> >>> [1] is: https://patchwork.ozlabs.org/patch/833376/
> >>>
> >>> Jaehoon, are you OK with this patch?  Thanks!
> >>>
> >>
> > 
> > a ping on this matter - as the db410c maintainer a quick reminder that the 
> > emmc support remains broken until this (above [1]) (or an alternative fix) 
> > is merged.
> 
> I sent the email to Tom about 1 weeks ago..if it doesn't apply yet, i will 
> pick it..
> Maybe i had replied with the my gmail account, something missed.

Yeah, I missed that, sorry.  Please put together a pull request of all
the various outstanding MMC changes ASAP, thanks!

-- 
Tom


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

[U-Boot] [PATCH v2 5/5] arm: Add Khadas VIM support based on Meson GXL family

[Neil Armstrong]

This adds platform code for the Khadas VIM board based on a
Meson GXL (S905X) SoC with the Meson GXL configuration.

This initial submission supports UART, MMC/SDCard and Ethernet with the
Internal RMII PHY.

The meson-gxl-s905x-khadas-vim.dts is synchronised from the linux 4.13
stable tree as of 4.13.8.

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/Makefile   |   3 +-
 arch/arm/dts/meson-gxl-s905x-khadas-vim.dts | 137 
 arch/arm/mach-meson/Kconfig |   9 ++
 board/amlogic/khadas-vim/Kconfig|  12 +++
 board/amlogic/khadas-vim/MAINTAINERS|   6 ++
 board/amlogic/khadas-vim/Makefile   |   8 ++
 board/amlogic/khadas-vim/README |  96 +++
 board/amlogic/khadas-vim/khadas-vim.c   |  48 ++
 configs/khadas-vim_defconfig|  35 +++
 include/configs/khadas-vim.h|  21 +
 10 files changed, 374 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/meson-gxl-s905x-khadas-vim.dts
 create mode 100644 board/amlogic/khadas-vim/Kconfig
 create mode 100644 board/amlogic/khadas-vim/MAINTAINERS
 create mode 100644 board/amlogic/khadas-vim/Makefile
 create mode 100644 board/amlogic/khadas-vim/README
 create mode 100644 board/amlogic/khadas-vim/khadas-vim.c
 create mode 100644 configs/khadas-vim_defconfig
 create mode 100644 include/configs/khadas-vim.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1845552..b44a915 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -56,7 +56,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-odroidc2.dtb \
meson-gxl-s905x-p212.dtb \
-   meson-gxl-s905x-libretech-cc.dtb
+   meson-gxl-s905x-libretech-cc.dtb \
+   meson-gxl-s905x-khadas-vim.dtb
 dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra20-medcom-wide.dtb \
tegra20-paz00.dtb \
diff --git a/arch/arm/dts/meson-gxl-s905x-khadas-vim.dts 
b/arch/arm/dts/meson-gxl-s905x-khadas-vim.dts
new file mode 100644
index 000..94567eb
--- /dev/null
+++ b/arch/arm/dts/meson-gxl-s905x-khadas-vim.dts
@@ -0,0 +1,137 @@
+/*
+ * Copyright (c) 2017 Martin Blumenstingl .
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include 
+
+#include "meson-gxl-s905x-p212.dtsi"
+
+/ {
+   compatible = "khadas,vim", "amlogic,s905x", "amlogic,meson-gxl";
+   model = "Khadas VIM";
+
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = < 0>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <171>;
+
+   button-function {
+   label = "Function";
+   linux,code = ;
+   press-threshold-microvolt = <1>;
+   };
+   };
+
+   aliases {
+   serial2 = _AO_B;
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <100>;
+
+   button@0 {
+   label = "power";
+   linux,code = ;
+   gpios = <_ao GPIOAO_2 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   pwmleds {
+   compatible = "pwm-leds";
+
+   power {
+   label = "vim:red:power";
+   pwms = <_AO_ab 1 7812500 0>;
+   max-brightness = <255>;
+   linux,default-trigger = "default-on";
+   };
+   };
+
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_tx_tmds_out>;
+   };
+   };
+   };
+};
+
+_tx {
+   status = "okay";
+   pinctrl-0 = <_hpd_pins>, <_i2c_pins>;
+   pinctrl-names = "default";
+};
+
+_tx_tmds_port {
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+};
+
+_A {
+   status = "okay";
+   pinctrl-0 = <_a_pins>;
+   pinctrl-names = "default";
+};
+
+_B {
+   status = "okay";
+   pinctrl-0 = <_b_pins>;
+   pinctrl-names = "default";
+
+   rtc: rtc@51 {
+   /* has to be enabled manually when a battery is connected: */
+   status = "disabled";
+   compatible = "haoyu,hym8563";
+   reg = <0x51>;
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "xin32k";
+   };
+};
+
+ {
+   linux,rc-map-name = "rc-geekbox";
+};
+
+_AO_ab {
+   status = "okay";
+   pinctrl-0 = <_ao_a_3_pins>, <_ao_b_pins>;
+   pinctrl-names = 

[U-Boot] [PATCH v2 3/5] board: p212: use common ethernet init function

[Neil Armstrong]

Switch P212 Ethernet init to the common Ethernet init function.

Signed-off-by: Neil Armstrong 
---
 board/amlogic/p212/p212.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/board/amlogic/p212/p212.c b/board/amlogic/p212/p212.c
index ece8096..a120ab0 100644
--- a/board/amlogic/p212/p212.c
+++ b/board/amlogic/p212/p212.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #define EFUSE_SN_OFFSET20
 #define EFUSE_SN_SIZE  16
@@ -28,17 +28,7 @@ int misc_init_r(void)
char serial[EFUSE_SN_SIZE];
ssize_t len;
 
-   /* Set RMII mode */
-   out_le32(GXBB_ETH_REG_0, GXBB_ETH_REG_0_INVERT_RMII_CLK |
-GXBB_ETH_REG_0_CLK_EN);
-
-   /* Use Internal PHY */
-   out_le32(GXBB_ETH_REG_2, 0x10110181);
-   out_le32(GXBB_ETH_REG_3, 0xe40908ff);
-
-   /* Enable power and clock gate */
-   setbits_le32(GXBB_GCLK_MPEG_1, GXBB_GCLK_MPEG_1_ETH);
-   clrbits_le32(GXBB_MEM_PD_REG_0, GXBB_MEM_PD_REG_0_ETH_MASK);
+   meson_gx_eth_init(PHY_INTERFACE_MODE_RMII, true);
 
if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
len = meson_sm_read_efuse(EFUSE_MAC_OFFSET,
-- 
2.7.4

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

[U-Boot] [PATCH v2 4/5] arm: Add LibreTech CC support based on Meson GXL family

[Neil Armstrong]

This adds platform code for the Libre Computer CC "Le Potato" board based on a
Meson GXL (S905X) SoC with the Meson GXL configuration.

This initial submission supports UART, MMC/SDCard and Ethernet with the
Internal RMII PHY.

The meson-gxl-s905x-libretech-cc.dts is synchronised from the linux 4.13
stable tree as of 4.13.8.

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/meson-gxl-s905x-libretech-cc.dts | 171 ++
 arch/arm/mach-meson/Kconfig   |   9 ++
 board/amlogic/libretech-cc/Kconfig|  12 ++
 board/amlogic/libretech-cc/MAINTAINERS|   6 +
 board/amlogic/libretech-cc/Makefile   |   8 ++
 board/amlogic/libretech-cc/README |  96 +++
 board/amlogic/libretech-cc/libretech-cc.c |  52 
 configs/libretech-cc_defconfig|  35 ++
 include/configs/libretech-cc.h|  21 
 10 files changed, 412 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/meson-gxl-s905x-libretech-cc.dts
 create mode 100644 board/amlogic/libretech-cc/Kconfig
 create mode 100644 board/amlogic/libretech-cc/MAINTAINERS
 create mode 100644 board/amlogic/libretech-cc/Makefile
 create mode 100644 board/amlogic/libretech-cc/README
 create mode 100644 board/amlogic/libretech-cc/libretech-cc.c
 create mode 100644 configs/libretech-cc_defconfig
 create mode 100644 include/configs/libretech-cc.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cd540e9..1845552 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -55,7 +55,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rv1108-evb.dtb
 dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-odroidc2.dtb \
-   meson-gxl-s905x-p212.dtb
+   meson-gxl-s905x-p212.dtb \
+   meson-gxl-s905x-libretech-cc.dtb
 dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra20-medcom-wide.dtb \
tegra20-paz00.dtb \
diff --git a/arch/arm/dts/meson-gxl-s905x-libretech-cc.dts 
b/arch/arm/dts/meson-gxl-s905x-libretech-cc.dts
new file mode 100644
index 000..266fbcf
--- /dev/null
+++ b/arch/arm/dts/meson-gxl-s905x-libretech-cc.dts
@@ -0,0 +1,171 @@
+/*
+ * Copyright (c) 2017 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ * Author: Jerome Brunet 
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include 
+
+#include "meson-gxl-s905x.dtsi"
+
+/ {
+   compatible = "libretech,cc", "amlogic,s905x", "amlogic,meson-gxl";
+   model = "Libre Technology CC";
+
+   aliases {
+   serial0 = _AO;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   cvbs-connector {
+   compatible = "composite-video-connector";
+
+   port {
+   cvbs_connector_in: endpoint {
+   remote-endpoint = <_vdac_out>;
+   };
+   };
+   };
+
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
+   };
+
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_tx_tmds_out>;
+   };
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   system {
+   label = "librecomputer:system-status";
+   gpios = < GPIODV_24 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   panic-indicator;
+   };
+
+   blue {
+   label = "librecomputer:blue";
+   gpios = <_ao GPIOAO_2 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>;
+   };
+
+   vcc_3v3: regulator-vcc_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_card: regulator-vcc-card {
+   compatible = "regulator-gpio";
+
+   regulator-name = "VCC_CARD";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = <_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
+   gpios-states = <0>;
+
+   states = <330 0>,
+<180 1>;
+   };
+
+   vddio_boot: regulator-vddio_boot {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDIO_BOOT";
+   

[U-Boot] [PATCH v2 1/5] ARM: arch-meson: add ethernet common init function

[Neil Armstrong]

Introduce a generic common Ethernet Hardware init function
common to all Amlogic GX SoCs with support for the
Internal PHY enable for GXL SoCs.

Signed-off-by: Neil Armstrong 
---
 arch/arm/include/asm/arch-meson/eth.h | 15 ++
 arch/arm/mach-meson/Makefile  |  2 +-
 arch/arm/mach-meson/eth.c | 53 +++
 3 files changed, 69 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/arch-meson/eth.h
 create mode 100644 arch/arm/mach-meson/eth.c

diff --git a/arch/arm/include/asm/arch-meson/eth.h 
b/arch/arm/include/asm/arch-meson/eth.h
new file mode 100644
index 000..8ea8e10
--- /dev/null
+++ b/arch/arm/include/asm/arch-meson/eth.h
@@ -0,0 +1,15 @@
+/*
+ * Copyright (C) 2016 BayLibre, SAS
+ * Author: Neil Armstrong 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __MESON_ETH_H__
+#define __MESON_ETH_H__
+
+#include 
+
+void meson_gx_eth_init(phy_interface_t mode, bool use_internal_phy);
+
+#endif /* __MESON_ETH_H__ */
diff --git a/arch/arm/mach-meson/Makefile b/arch/arm/mach-meson/Makefile
index bf49b8b..b4e8dde 100644
--- a/arch/arm/mach-meson/Makefile
+++ b/arch/arm/mach-meson/Makefile
@@ -4,4 +4,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y += board.o sm.o
+obj-y += board.o sm.o eth.o
diff --git a/arch/arm/mach-meson/eth.c b/arch/arm/mach-meson/eth.c
new file mode 100644
index 000..46ecb5e
--- /dev/null
+++ b/arch/arm/mach-meson/eth.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2016 BayLibre, SAS
+ * Author: Neil Armstrong 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void meson_gx_eth_init(phy_interface_t mode, bool use_internal_phy)
+{
+   switch (mode) {
+   case PHY_INTERFACE_MODE_RGMII:
+   case PHY_INTERFACE_MODE_RGMII_ID:
+   case PHY_INTERFACE_MODE_RGMII_RXID:
+   case PHY_INTERFACE_MODE_RGMII_TXID:
+   /* Set RGMII mode */
+   setbits_le32(GXBB_ETH_REG_0, GXBB_ETH_REG_0_PHY_INTF |
+GXBB_ETH_REG_0_TX_PHASE(1) |
+GXBB_ETH_REG_0_TX_RATIO(4) |
+GXBB_ETH_REG_0_PHY_CLK_EN |
+GXBB_ETH_REG_0_CLK_EN);
+   break;
+
+   case PHY_INTERFACE_MODE_RMII:
+   /* Set RMII mode */
+   out_le32(GXBB_ETH_REG_0, GXBB_ETH_REG_0_INVERT_RMII_CLK |
+GXBB_ETH_REG_0_CLK_EN);
+
+#ifdef CONFIG_MESON_GXL
+   if (use_internal_phy) {
+   /* Use Internal PHY */
+   out_le32(GXBB_ETH_REG_2, 0x10110181);
+   out_le32(GXBB_ETH_REG_3, 0xe40908ff);
+   }
+#endif
+
+   break;
+   
+   default:
+   printf("Invalid Ethernet interface mode\n");
+   return;
+   }
+
+   /* Enable power and clock gate */
+   setbits_le32(GXBB_GCLK_MPEG_1, GXBB_GCLK_MPEG_1_ETH);
+   clrbits_le32(GXBB_MEM_PD_REG_0, GXBB_MEM_PD_REG_0_ETH_MASK);
+}
-- 
2.7.4

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

Re: [U-Boot] mx6ull evk reboots automatically

[Peng Fan]

Hi Fabio,

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Thursday, November 23, 2017 3:07 AM
> To: Peng Fan 
> Cc: U-Boot-Denx 
> Subject: mx6ull evk reboots automatically
> 
> Hi Peng,
> 
> Booting a mainline U-Boot on a imx6ull evk with a mainline kernel causes the
> board to reboot after about 5 seconds from reaching the Linux prompt.
> 
> If I use the NXP U-Boot version this problem does not happen.
> 
> Do you have any suggestion to fix this problem?

This maybe wdog related settings. You could try disable wdog in kernel or check
Wdog settings in uboot. It maybe kernel configure wdog pins and trigger reset.

Regards,
Peng.

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

Re: [U-Boot] mx6ull evk reboots automatically

[Ye Li]

Hi Fabio,

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Peng Fan
> Sent: Thursday, November 23, 2017 9:40 AM
> To: Fabio Estevam 
> Cc: U-Boot-Denx 
> Subject: Re: [U-Boot] mx6ull evk reboots automatically
> 
> Hi Fabio,
> 
> > -Original Message-
> > From: Fabio Estevam [mailto:feste...@gmail.com]
> > Sent: Thursday, November 23, 2017 3:07 AM
> > To: Peng Fan 
> > Cc: U-Boot-Denx 
> > Subject: mx6ull evk reboots automatically
> >
> > Hi Peng,
> >
> > Booting a mainline U-Boot on a imx6ull evk with a mainline kernel
> > causes the board to reboot after about 5 seconds from reaching the Linux
> prompt.
> >
> > If I use the NXP U-Boot version this problem does not happen.
> >
> > Do you have any suggestion to fix this problem?
> 
> This maybe wdog related settings. You could try disable wdog in kernel or
> check Wdog settings in uboot. It maybe kernel configure wdog pins and trigger
> reset.

 The wdog3 is not disabled for i.mx6ull on mainline U-boot. Please fix it in 
imx_set_wdog_powerdown.

   if (is_mx6sx() || is_mx6ul() || is_mx6ull() || is_mx7())
writew(enable, >wmcr);

Best regards,
Ye Li

> 
> Regards,
> Peng.
> 
> >
> > Thanks,
> >
> > Fabio Estevam
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.de
> nx.de%2Flistinfo%2Fu-
> boot=02%7C01%7Cye.li%40nxp.com%7C9b3b91b0a1694da6a8cf08d5321
> 31ce7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6364699800380
> 79598=%2FWH73G3X8dfGDdng6EVae8oa9YxrYE7%2FjFC%2BX2h0piI%3
> D=0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] net: zynq_gem: Dont enable SGMII and PCS selection

[Siva Durga Prasad Paladugu]

Dont enable SGMII and PCS selection if internal PCS/PMA
is not used, by getting the info about internal/external
PCS/PMA usage from dt property "is-internal-phy".

Signed-off-by: Siva Durga Prasad Paladugu 
---
 drivers/net/zynq_gem.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index f6bbcdc..1dfd631 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -182,6 +182,7 @@ struct zynq_gem_priv {
int phy_of_handle;
struct mii_dev *bus;
struct clk clk;
+   bool int_pcs;
 };
 
 static u32 phy_setup_op(struct zynq_gem_priv *priv, u32 phy_addr, u32 regnum,
@@ -425,7 +426,12 @@ static int zynq_gem_init(struct udevice *dev)
 
nwconfig = ZYNQ_GEM_NWCFG_INIT;
 
-   if (priv->interface == PHY_INTERFACE_MODE_SGMII) {
+   /*
+* Set SGMII enable PCS selection only if internal PCS/PMA
+* core is used and interface is SGMII.
+*/
+   if (priv->interface == PHY_INTERFACE_MODE_SGMII &&
+   priv->int_pcs) {
nwconfig |= ZYNQ_GEM_NWCFG_SGMII_ENBL |
ZYNQ_GEM_NWCFG_PCS_SEL;
 #ifdef CONFIG_ARM64
@@ -697,6 +703,9 @@ static int zynq_gem_ofdata_to_platdata(struct udevice *dev)
}
priv->interface = pdata->phy_interface;
 
+   priv->int_pcs = fdtdec_get_bool(gd->fdt_blob, node,
+   "is-internal-pcspma");
+
printf("ZYNQ GEM: %lx, phyaddr %x, interface %s\n", (ulong)priv->iobase,
   priv->phyaddr, phy_string_for_interface(priv->interface));
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH] ni: Add NIZYNQ platform

[Michal Simek]

On 23.11.2017 04:42, Wilson Lee wrote:
> Hi Michal,
> 
> On Wed, 2017-11-22 at 08:11 +0100, Michal Simek wrote:
>> Hi,
>>
>> On 22.11.2017 04:06, Wilson Lee wrote:
>>>
>>> Hi Michal,
>>>
>>> On Wed, 2017-11-08 at 07:27 +0100, Michal Simek wrote:

 On 8.11.2017 03:54, Wilson Lee wrote:
>
>
> Initial platform creation for NIZYNQ.
>
> Signed-off-by: Joe Hershberger 
> Signed-off-by: Keng Soon Cheah 
> Signed-off-by: Wilson Lee 
> Cc: Chen Yee Chew 
> Cc: Albert Aribaud 
> ---
>  arch/arm/Kconfig  | 15 +++
>  arch/arm/Makefile |  4 +++-
>  board/ni/Kconfig  | 13 +
>  3 files changed, 31 insertions(+), 1 deletion(-)
>  create mode 100644 board/ni/Kconfig
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 83b7aa5..ae34821 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -767,6 +767,20 @@ config ARCH_ZYNQMP
>   select DM_USB if USB
>   imply FAT_WRITE
>  
> +config NIZYNQ
> + bool "National Instruments zynq Platform"
> + select CPU_V7
> + select SUPPORT_SPL
> + select OF_CONTROL
> + select SPL_OF_CONTROL if SPL
> + select DM
> + select DM_ETH
> + select DM_GPIO
> + select SPL_DM if SPL
> + select DM_MMC
> + select DM_SERIAL
> + select SPL_SEPARATE_BSS if SPL
> +
 What's the reason for this? You should reuse current ZYNQ
 fragment
 and
 if this selects something what you don't want then we should
 changethat. Look at syzygy or topic boards which are using
 existing
 zynq
 infrastructure.

 Thanks,
 Michal


>>> The reason for adding NIZYNQ instead of reuse ARCH_ZYNQ. That is
>>> because we need NIZYNQ at the same level with ARCH_ZYNQ in
>>> menuconfig.
>>> We are thinking that it would be missleading, if our customer need
>>> to
>>> select Xilinx Zynq Platform before they can select NI product. 
>>>
>>> Hence, what we wish to get the menuconfig that look like below,
>>>
>>> + Target select +

   Use the arrow keys to navigate this window or press
 the  |  
  hotkey of the item you wish to select followed by the >>>   BAR>. Press  for additional information about
 this|  
 +^(-)---+ |  
>
> ( ) Support pcm-052|
> |  
> ( ) Support BK4r1  |
> |  
  |( ) Xilinx Zynq Platform   |
 |  
>
> ( ) Support Xilinx ZynqMP Platform |
> |  
> (X) National Instruments zynq Platform |
> |  
> ( ) NVIDIA Tegra   |
> |  
 ++(+)---+ |  
>>> +---+  

   < Help
>  |  
>>> +---+
>>>
>> I understand that you want to put there a little bit of marketing but
>> moving to DM should avoid doing this and really I want to make xilinx
>> ports generic as much as possible.
>>
>> What we can do is to change description to be more understandable
>> like
>> "Xilinx Zynq based platform".
> 
> After some discussion, we think that changing the description to be
> more understandable as you suggested above is make sense to us and it
> is a good approache also. May I know, do you will submit a commit to
> change the description or we might need to submit ourself on changing
> the description?

I have just sent that patch. Please look at it and ack/nack or propose
better names.

> 
>>
>> Is there something what will use NIZYNQ symbol in the code? Does that
>> mean that there is something what is not handle now that you have to
>> use
>> this symbol?
> 
> I think that is alright. Because, we are not using NIZYNQ symbol in the
> code.

good.

> 
> Furthermore, we are using our own header file (something like zynq-
> common.h) due to it will provide more flexibility on defining stuff
> (such as undefine something that defined in zynq-common, define
> CONFIG_EXTRA_ENV_SETTINGS, CONFIG_PREBOOT and etc..). I think we can
> easily change the default header file from zynq-common.h to our own one
> by redefine "SYS_CONFIG_NAME" again in defconfig. By the way, may I
> know is it have a better way for not keep on redefining the
> "SYS_CONFIG_NAME" in every board defconfig if we have 20+ boards.

Do you have any repo with these boards to have impression how exactly it
looks like now? Where is the difference? In variables?
Eveything should be moved to Kconfig till the end of this year and 

[U-Boot] [PATCH v2 2/3] cosmetic: atcspi200: Rename function name as atcspi200

[Andes]

From: Rick Chen 

Integrate function and struct name from ae3xx to
atcspi200 will be more reasonable.

Signed-off-by: Rick Chen 
---
 drivers/spi/atcspi200_spi.c | 96 ++---
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/drivers/spi/atcspi200_spi.c b/drivers/spi/atcspi200_spi.c
index f5bd99a..3e29df0 100644
--- a/drivers/spi/atcspi200_spi.c
+++ b/drivers/spi/atcspi200_spi.c
@@ -1,5 +1,5 @@
 /*
- * NDS SPI controller driver.
+ * Andestech ATCSPI200 SPI controller driver.
  *
  * Copyright 2017 Andes Technology, Inc.
  * Author: Rick Chen (r...@andestech.com)
@@ -25,7 +25,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define SPI1_BASE  0xf0f0
 #define NSPI_MAX_CS_NUM1
 
-struct ae3xx_spi_regs {
+struct atcspi200_spi_regs {
u32 rev;
u32 reserve1[3];
u32 format; /* 0x10 */
@@ -78,7 +78,7 @@ struct nds_spi_slave {
 #ifndef CONFIG_DM_SPI
struct spi_slave slave;
 #endif
-   volatile struct ae3xx_spi_regs *regs;
+   volatile struct atcspi200_spi_regs *regs;
int to;
unsigned intfreq;
ulong   clock;
@@ -94,7 +94,7 @@ struct nds_spi_slave {
unsigned intmax_transfer_length;
 };
 
-static int __ae3xx_spi_set_speed(struct nds_spi_slave *ns)
+static int __atcspi200_spi_set_speed(struct nds_spi_slave *ns)
 {
u32 tm;
u8 div;
@@ -117,7 +117,7 @@ static int __ae3xx_spi_set_speed(struct nds_spi_slave *ns)
 
 }
 
-static int __ae3xx_spi_claim_bus(struct nds_spi_slave *ns)
+static int __atcspi200_spi_claim_bus(struct nds_spi_slave *ns)
 {
unsigned int format=0;
ns->regs->ctrl |= (TXFRST|RXFRST|SPIRST);
@@ -128,18 +128,18 @@ static int __ae3xx_spi_claim_bus(struct nds_spi_slave *ns)
ns->cmd_len = 0;
format = ns->mode|DATA_LENGTH(8);
ns->regs->format = format;
-   __ae3xx_spi_set_speed(ns);
+   __atcspi200_spi_set_speed(ns);
 
return 0;
 }
 
-static int __ae3xx_spi_release_bus(struct nds_spi_slave *ns)
+static int __atcspi200_spi_release_bus(struct nds_spi_slave *ns)
 {
/* do nothing */
return 0;
 }
 
-static int __ae3xx_spi_start(struct nds_spi_slave *ns)
+static int __atcspi200_spi_start(struct nds_spi_slave *ns)
 {
int i,olen=0;
int tc = ns->regs->tctrl;
@@ -168,7 +168,7 @@ static int __ae3xx_spi_start(struct nds_spi_slave *ns)
return 0;
 }
 
-static int __ae3xx_spi_stop(struct nds_spi_slave *ns)
+static int __atcspi200_spi_stop(struct nds_spi_slave *ns)
 {
ns->regs->timing = ns->mtiming;
while ((ns->regs->status & SPIBSY)&&(ns->to--))
@@ -190,7 +190,7 @@ static int __nspi_espi_rx(struct nds_spi_slave *ns, void 
*din, unsigned int byte
 }
 
 
-static int __ae3xx_spi_xfer(struct nds_spi_slave *ns,
+static int __atcspi200_spi_xfer(struct nds_spi_slave *ns,
unsigned int bitlen,  const void *data_out, void *data_in,
unsigned long flags)
 {
@@ -230,7 +230,7 @@ static int __ae3xx_spi_xfer(struct nds_spi_slave *ns,
memcpy(cmd_buf, data_out, cmd_len);
data_out = 0;
data_len = 0;
-   __ae3xx_spi_start(ns);
+   __atcspi200_spi_start(ns);
break;
}
debug("spi_xfer: data_out %08X(%p) data_in %08X(%p) data_len 
%u\n",
@@ -245,7 +245,7 @@ static int __ae3xx_spi_xfer(struct nds_spi_slave *ns,
num_bytes = (tran_len) % CHUNK_SIZE;
if(num_bytes == 0)
num_bytes = CHUNK_SIZE;
-   __ae3xx_spi_start(ns);
+   __atcspi200_spi_start(ns);
 
while (num_blks) {
event = in_le32(>regs->status);
@@ -279,9 +279,9 @@ static int __ae3xx_spi_xfer(struct nds_spi_slave *ns,
ns->cmd_buf[3] += ((tran_len)&0xff);
ns->data_len = data_len;
}
-   ret = __ae3xx_spi_stop(ns);
+   ret = __atcspi200_spi_stop(ns);
}
-   ret = __ae3xx_spi_stop(ns);
+   ret = __atcspi200_spi_stop(ns);
 
return ret;
 }
@@ -300,11 +300,11 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
 
switch (bus) {
case SPI0_BUS:
-   ns->regs = (struct ae3xx_spi_regs *)SPI0_BASE;
+   ns->regs = (struct atcspi200_spi_regs *)SPI0_BASE;
break;
 
case SPI1_BUS:
-   ns->regs = (struct ae3xx_spi_regs *)SPI1_BASE;
+   ns->regs = (struct atcspi200_spi_regs *)SPI1_BASE;
  

[U-Boot] [PATCH v2 3/3] dt-bindings: timer: Add andestech atcpit100 timer

[Andes]

From: Rick Chen 

Add a document to describe Andestech atcpit100 timer and
binding information.

Signed-off-by: Rick Chen 
Reviewed-by: Simon Glass 
---
 doc/device-tree-bindings/timer/atcpit100_timer.txt | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 doc/device-tree-bindings/timer/atcpit100_timer.txt

diff --git a/doc/device-tree-bindings/timer/atcpit100_timer.txt 
b/doc/device-tree-bindings/timer/atcpit100_timer.txt
new file mode 100644
index 000..620814e
--- /dev/null
+++ b/doc/device-tree-bindings/timer/atcpit100_timer.txt
@@ -0,0 +1,31 @@
+Andestech ATCPIT100 timer
+--
+ATCPIT100 is a generic IP block from Andes Technology, embedded in
+Andestech AE3XX, AE250 platforms and other designs.
+
+This timer is a set of compact multi-function timers, which can be
+used as pulse width modulators (PWM) as well as simple timers.
+
+It supports up to 4 PIT channels. Each PIT channel is a
+multi-function timer and provide the following usage scenarios:
+One 32-bit timer
+Two 16-bit timers
+Four 8-bit timers
+One 16-bit PWM
+One 16-bit timer and one 8-bit PWM
+Two 8-bit timer and one 8-bit PWM
+
+Required properties:
+- compatible   : Should be "andestech,atcpit100"
+- reg  : Address and length of the register set
+- interrupts   : Reference to the timer interrupt
+- clock-frequency : The rate in HZ in input of the Andestech ATCPIT100 timer
+
+Examples:
+
+timer0: timer@f040 {
+   compatible = "andestech,atcpit100";
+   reg = <0xf040 0x1000>;
+   interrupts = <2 4>;
+   clock-frequency = <3000>;
+}:
-- 
2.7.4

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

[U-Boot] [PATCH v2 1/3] ae3xx: timer: Rename AE3XX to ATCPIT100

[Andes]

From: Rick Chen 

ATCPIT100 is Andestech timer IP which is embeded
in AE3XX and AE250 boards. So rename AE3XX to
ATCPIT100 will be more make sence.

Signed-off-by: Rick Chen 
---
 configs/adp-ae3xx_defconfig| 2 +-
 drivers/timer/Kconfig  | 7 ---
 drivers/timer/Makefile | 2 +-
 drivers/timer/{ae3xx_timer.c => atcpit100_timer.c} | 0
 4 files changed, 6 insertions(+), 5 deletions(-)
 rename drivers/timer/{ae3xx_timer.c => atcpit100_timer.c} (100%)

diff --git a/configs/adp-ae3xx_defconfig b/configs/adp-ae3xx_defconfig
index a3a40bf..337cee1 100644
--- a/configs/adp-ae3xx_defconfig
+++ b/configs/adp-ae3xx_defconfig
@@ -35,4 +35,4 @@ CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_NDS_AE3XX_SPI=y
 CONFIG_TIMER=y
-CONFIG_AE3XX_TIMER=y
+CONFIG_ATCPIT100_TIMER=y
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 6305bbf..fcfdf4e 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -105,11 +105,12 @@ config AG101P_TIMER
help
  Select this to enable a timer for AG01P devices.
 
-config AE3XX_TIMER
-   bool "AE3XX timer support"
+config ATCPIT100_TIMER
+   bool "ATCPIT100 timer support"
depends on TIMER && NDS32
help
- Select this to enable a timer for AE3XX devices.
+ Select this to enable a ATCPIT100 timer which will be embeded
+   in AE3XX, AE250 boards.
 
 config ROCKCHIP_TIMER
 bool "Rockchip timer support"
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index 69e8961..15e5154 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -13,6 +13,6 @@ obj-$(CONFIG_AST_TIMER)   += ast_timer.o
 obj-$(CONFIG_STI_TIMER)+= sti-timer.o
 obj-$(CONFIG_ARC_TIMER)+= arc_timer.o
 obj-$(CONFIG_AG101P_TIMER) += ag101p_timer.o
-obj-$(CONFIG_AE3XX_TIMER) += ae3xx_timer.o
+obj-$(CONFIG_ATCPIT100_TIMER) += atcpit100_timer.o
 obj-$(CONFIG_ROCKCHIP_TIMER) += rockchip_timer.o
 obj-$(CONFIG_ATMEL_PIT_TIMER) += atmel_pit_timer.o
diff --git a/drivers/timer/ae3xx_timer.c b/drivers/timer/atcpit100_timer.c
similarity index 100%
rename from drivers/timer/ae3xx_timer.c
rename to drivers/timer/atcpit100_timer.c
-- 
2.7.4

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

[U-Boot] [PATCH v2 2/3] cosmetic: atcpit100_timer: Rename function name as atcpit100

[Andes]

From: Rick Chen 

Integrate function and struct name as atcpit100 will be
more reasonable.

Signed-off-by: Rick Chen 
---
 drivers/timer/atcpit100_timer.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/timer/atcpit100_timer.c b/drivers/timer/atcpit100_timer.c
index b710c28..d5146dd 100644
--- a/drivers/timer/atcpit100_timer.c
+++ b/drivers/timer/atcpit100_timer.c
@@ -67,51 +67,51 @@ struct atctmr_timer_regs {
u32 int_mask;   /* 0x38 */
 };
 
-struct atftmr_timer_platdata {
+struct atcpit_timer_platdata {
u32 *regs;
 };
 
-static int atftmr_timer_get_count(struct udevice *dev, u64 *count)
+static int atcpit_timer_get_count(struct udevice *dev, u64 *count)
 {
-   struct atftmr_timer_platdata *plat = dev->platdata;
+   struct atcpit_timer_platdata *plat = dev->platdata;
u32 val;
val = ~(REG32_TMR(CH_CNT(1))+0x);
*count = timer_conv_64(val);
return 0;
 }
 
-static int atctmr_timer_probe(struct udevice *dev)
+static int atcpit_timer_probe(struct udevice *dev)
 {
-   struct atftmr_timer_platdata *plat = dev->platdata;
+   struct atcpit_timer_platdata *plat = dev->platdata;
REG32_TMR(CH_REL(1)) = 0x;
REG32_TMR(CH_CTL(1)) = APB_CLK|TMR_32;
REG32_TMR(CH_EN) |= CH_TMR_EN(1 , 0);
return 0;
 }
 
-static int atctme_timer_ofdata_to_platdata(struct udevice *dev)
+static int atcpit_timer_ofdata_to_platdata(struct udevice *dev)
 {
-   struct atftmr_timer_platdata *plat = dev_get_platdata(dev);
+   struct atcpit_timer_platdata *plat = dev_get_platdata(dev);
plat->regs = map_physmem(devfdt_get_addr(dev) , 0x100 , MAP_NOCACHE);
return 0;
 }
 
-static const struct timer_ops ag101p_timer_ops = {
-   .get_count = atftmr_timer_get_count,
+static const struct timer_ops atcpit_timer_ops = {
+   .get_count = atcpit_timer_get_count,
 };
 
-static const struct udevice_id ag101p_timer_ids[] = {
+static const struct udevice_id atcpit_timer_ids[] = {
{ .compatible = "andestech,atcpit100" },
{}
 };
 
-U_BOOT_DRIVER(altera_timer) = {
-   .name   = "ae3xx_timer",
+U_BOOT_DRIVER(atcpit100_timer) = {
+   .name   = "atcpit100_timer",
.id = UCLASS_TIMER,
-   .of_match = ag101p_timer_ids,
-   .ofdata_to_platdata = atctme_timer_ofdata_to_platdata,
-   .platdata_auto_alloc_size = sizeof(struct atftmr_timer_platdata),
-   .probe = atctmr_timer_probe,
-   .ops= _timer_ops,
+   .of_match = atcpit_timer_ids,
+   .ofdata_to_platdata = atcpit_timer_ofdata_to_platdata,
+   .platdata_auto_alloc_size = sizeof(struct atcpit_timer_platdata),
+   .probe = atcpit_timer_probe,
+   .ops= _timer_ops,
.flags = DM_FLAG_PRE_RELOC,
 };
-- 
2.7.4

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

[U-Boot] [PATCH v2 1/3] spi: nds_ae3xx: Rename nds_ae3xx_spi as atcspi200_spi

[Andes]

From: Rick Chen 

atcspi200 is Andestech spi ip which is embedded in
AE3XX and AE250 platforms. So rename as atcspi200
will be more reasonable to be used in different
platforms.

Signed-off-by: Rick Chen 
---
 configs/adp-ae3xx_defconfig  |  2 +-
 drivers/spi/Kconfig  | 10 +-
 drivers/spi/Makefile |  2 +-
 drivers/spi/{nds_ae3xx_spi.c => atcspi200_spi.c} |  0
 4 files changed, 7 insertions(+), 7 deletions(-)
 rename drivers/spi/{nds_ae3xx_spi.c => atcspi200_spi.c} (100%)

diff --git a/configs/adp-ae3xx_defconfig b/configs/adp-ae3xx_defconfig
index 337cee1..38696e6 100644
--- a/configs/adp-ae3xx_defconfig
+++ b/configs/adp-ae3xx_defconfig
@@ -33,6 +33,6 @@ CONFIG_BAUDRATE=38400
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
-CONFIG_NDS_AE3XX_SPI=y
+CONFIG_ATCSPI200_SPI=y
 CONFIG_TIMER=y
 CONFIG_ATCPIT100_TIMER=y
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 88da9a4..494639f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -210,12 +210,12 @@ config FSL_QSPI
  used to access the SPI NOR flash on platforms embedding this
  Freescale IP core.
 
-config NDS_AE3XX_SPI
-   bool "Andestech AE3XX SPI driver"
+config ATCSPI200_SPI
+   bool "Andestech ATCSPI200 SPI driver"
help
- Enable the Andestech AE3XX SPI driver. This driver can be
- used to access the SPI flash on platforms embedding this
- Andestech IP core.
+ Enable the Andestech ATCSPI200 SPI driver. This driver can be
+ used to access the SPI flash on AE3XX and AE250 platforms embedding
+ this Andestech IP core.
 
 config TI_QSPI
bool "TI QSPI driver"
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index ad56203..e3184db 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -34,7 +34,7 @@ obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
 obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
 obj-$(CONFIG_MXC_SPI) += mxc_spi.o
 obj-$(CONFIG_MXS_SPI) += mxs_spi.o
-obj-$(CONFIG_NDS_AE3XX_SPI) += nds_ae3xx_spi.o
+obj-$(CONFIG_ATCSPI200_SPI) += atcspi200_spi.o
 obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o
 obj-$(CONFIG_PIC32_SPI) += pic32_spi.o
 obj-$(CONFIG_ROCKCHIP_SPI) += rk_spi.o
diff --git a/drivers/spi/nds_ae3xx_spi.c b/drivers/spi/atcspi200_spi.c
similarity index 100%
rename from drivers/spi/nds_ae3xx_spi.c
rename to drivers/spi/atcspi200_spi.c
-- 
2.7.4

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

Re: [U-Boot] [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

[Siva Durga Prasad Paladugu]

Hi Jagan,

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, November 01, 2017 2:54 PM
> To: Siva Durga Prasad Paladugu 
> Cc: u-boot@lists.denx.de; Liam Beguin 
> Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for
> ZynqMP qspi driver
> 
> On Tue, Oct 31, 2017 at 6:33 PM, Siva Durga Prasad Paladugu
>  wrote:
> > Hi Jagan,
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> Sent: Tuesday, October 31, 2017 3:01 PM
> >> To: Siva Durga Prasad Paladugu 
> >> Cc: u-boot@lists.denx.de; Liam Beguin 
> >> Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for
> >> ZynqMP qspi driver
> >>
> >> On Tue, Oct 31, 2017 at 2:50 PM, Siva Durga Prasad Paladugu
> >>  wrote:
> >> > Hi Jagan,
> >> >
> >> >> -Original Message-
> >> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> >> Sent: Tuesday, October 31, 2017 2:40 PM
> >> >> To: Siva Durga Prasad Paladugu 
> >> >> Cc: u-boot@lists.denx.de; Liam Beguin ;
> Siva
> >> >> Durga Prasad Paladugu 
> >> >> Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for
> >> >> ZynqMP qspi driver
> >> >>
> >> >> On Tue, Oct 24, 2017 at 3:33 PM, Siva Durga Prasad Paladugu
> >> >>  wrote:
> >> >> > This patch adds qspi driver support for ZynqMP SoC. This driver
> >> >> > is responsible for communicating with qspi flash devices.
> >> >>
> >> >> Legacy question, what is your approach for dual memory setup? Did
> >> >> you write another flash driver?
> >> > No
> >> >
> >> >>
> >> >> I see this driver use dual flash slave 'option' which doesn't live
> >> >> on spi side anymore. better to have a discussion on approach and
> >> >> will
> >> review further.
> >> >
> >> > I can see that spi_flash.c(driver/mtd/spi/spi_flash.c) has the
> >> > option for
> >> dual flash under CONFIG_SF_DUAL_FLASH.
> >> > I thought of using the same. Isn't it takes care of dual flash case?
> >> > Please let me know if you any further thoughts on how it has to be
> >> handled.
> >>
> >> Dual flash case should take for generic spi drivers, if you strictly
> >> want your controller to handle flash device rather !flashes then we
> >> need to write the driver at flash side. ie why I asked as first question.
> >
> > Does this mean that drivers that are present in drivers/spi/ should
> > work for both flashes and !flashes. And the drivers that only targets
> > flash devices should be in different place and doesn’t use Dual flash
> functionality under CONFIG_SF_DUAL_FLASH? Or it can still use this.
> 
> Sorry, you understand it reverse or may be I'm not clear.
> 
> drivers at drivers/spi can handle only generic slaves which includes spi-flash
> and some spi-flash(spi-nor) controllers which only deals with spi-flash
> slaves which can be part of drivers/mtd/spi. Since your driver is categorized
> as spi-nor controller(in above notes from you) it's better to write driver at
> drivers/mtd/spi side.

No, the controller is meant to handle other slaves as well along with spi-nor. 
Also for now, we are targeting single spi flash. So, keeping the driver here
should just be fine. Please let me know if you need any further info.

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

[U-Boot] [PATCH] net: xilinx_axi_emac: Use readl and writel for io ops

[Siva Durga Prasad Paladugu]

This patch uses readl and writel instead of in_be32 and
out_be32 for io ops as these internally uses readl,
writel for microblaze and for Zynq, ZynqMP there is
no need of endianness conversion and readl, writel
should work straightaway. This patch starts supporting
the driver for Zynq and ZynqMP platforms.

Signed-off-by: Siva Durga Prasad Paladugu 
---
 drivers/net/xilinx_axi_emac.c | 86 +--
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/drivers/net/xilinx_axi_emac.c b/drivers/net/xilinx_axi_emac.c
index 25c66c6..aa66e28 100644
--- a/drivers/net/xilinx_axi_emac.c
+++ b/drivers/net/xilinx_axi_emac.c
@@ -152,7 +152,7 @@ static inline int mdio_wait(struct axi_regs *regs)
u32 timeout = 200;
 
/* Wait till MDIO interface is ready to accept a new transaction. */
-   while (timeout && (!(in_be32(>mdio_mcr)
+   while (timeout && (!(readl(>mdio_mcr)
& XAE_MDIO_MCR_READY_MASK))) {
timeout--;
udelay(1);
@@ -180,13 +180,13 @@ static u32 phyread(struct axidma_priv *priv, u32 
phyaddress, u32 registernum,
XAE_MDIO_MCR_INITIATE_MASK |
XAE_MDIO_MCR_OP_READ_MASK;
 
-   out_be32(>mdio_mcr, mdioctrlreg);
+   writel(mdioctrlreg, >mdio_mcr);
 
if (mdio_wait(regs))
return 1;
 
/* Read data */
-   *val = in_be32(>mdio_mrd);
+   *val = readl(>mdio_mrd);
return 0;
 }
 
@@ -207,9 +207,9 @@ static u32 phywrite(struct axidma_priv *priv, u32 
phyaddress, u32 registernum,
XAE_MDIO_MCR_OP_WRITE_MASK;
 
/* Write data */
-   out_be32(>mdio_mwd, data);
+   writel(data, >mdio_mwd);
 
-   out_be32(>mdio_mcr, mdioctrlreg);
+   writel(mdioctrlreg, >mdio_mcr);
 
if (mdio_wait(regs))
return 1;
@@ -233,7 +233,7 @@ static int axiemac_phy_init(struct udevice *dev)
SUPPORTED_1000baseT_Full;
 
/* Set default MDIO divisor */
-   out_be32(>mdio_mc, XAE_MDIO_DIV_DFT | XAE_MDIO_MC_MDIOEN_MASK);
+   writel(XAE_MDIO_DIV_DFT | XAE_MDIO_MC_MDIOEN_MASK, >mdio_mc);
 
if (priv->phyaddr == -1) {
/* Detect the PHY address */
@@ -312,12 +312,12 @@ static int setup_phy(struct udevice *dev)
}
 
/* Setup the emac for the phy speed */
-   emmc_reg = in_be32(>emmc);
+   emmc_reg = readl(>emmc);
emmc_reg &= ~XAE_EMMC_LINKSPEED_MASK;
emmc_reg |= speed;
 
/* Write new speed setting out to Axi Ethernet */
-   out_be32(>emmc, emmc_reg);
+   writel(emmc_reg, >emmc);
 
/*
* Setting the operating speed of the MAC needs a delay. There
@@ -336,13 +336,13 @@ static void axiemac_stop(struct udevice *dev)
u32 temp;
 
/* Stop the hardware */
-   temp = in_be32(>dmatx->control);
+   temp = readl(>dmatx->control);
temp &= ~XAXIDMA_CR_RUNSTOP_MASK;
-   out_be32(>dmatx->control, temp);
+   writel(temp, >dmatx->control);
 
-   temp = in_be32(>dmarx->control);
+   temp = readl(>dmarx->control);
temp &= ~XAXIDMA_CR_RUNSTOP_MASK;
-   out_be32(>dmarx->control, temp);
+   writel(temp, >dmarx->control);
 
debug("axiemac: Halted\n");
 }
@@ -359,7 +359,7 @@ static int axi_ethernet_init(struct axidma_priv *priv)
 * will be valid until this bit is valid.
 * The bit is always a 1 for all other PHY interfaces.
 */
-   while (timeout && (!(in_be32(>is) & XAE_INT_MGTRDY_MASK))) {
+   while (timeout && (!(readl(>is) & XAE_INT_MGTRDY_MASK))) {
timeout--;
udelay(1);
}
@@ -370,21 +370,21 @@ static int axi_ethernet_init(struct axidma_priv *priv)
 
/* Stop the device and reset HW */
/* Disable interrupts */
-   out_be32(>ie, 0);
+   writel(0, >ie);
 
/* Disable the receiver */
-   out_be32(>rcw1, in_be32(>rcw1) & ~XAE_RCW1_RX_MASK);
+   writel(readl(>rcw1) & ~XAE_RCW1_RX_MASK, >rcw1);
 
/*
 * Stopping the receiver in mid-packet causes a dropped packet
 * indication from HW. Clear it.
 */
/* Set the interrupt status register to clear the interrupt */
-   out_be32(>is, XAE_INT_RXRJECT_MASK);
+   writel(XAE_INT_RXRJECT_MASK, >is);
 
/* Setup HW */
/* Set default MDIO divisor */
-   out_be32(>mdio_mc, XAE_MDIO_DIV_DFT | XAE_MDIO_MC_MDIOEN_MASK);
+   writel(XAE_MDIO_DIV_DFT | XAE_MDIO_MC_MDIOEN_MASK, >mdio_mc);
 
debug("axiemac: InitHw done\n");
return 0;
@@ -399,11 +399,11 @@ static int axiemac_write_hwaddr(struct udevice *dev)
/* Set the MAC address */
int val = ((pdata->enetaddr[3] << 24) | (pdata->enetaddr[2] << 16) |
(pdata->enetaddr[1] << 8) | (pdata->enetaddr[0]));
-   out_be32(>uaw0, val);
+   writel(val, 

[U-Boot] [PATCH v2 3/3] dt-bindings: spi: Add andestech atcspi200 spi binding doc

[Andes]

From: Rick Chen 

Add a document to describe Andestech atcspi200 spi and
binding information.

Signed-off-by: Rick Chen 
---
 doc/device-tree-bindings/spi/spi-atcspi200.txt | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 doc/device-tree-bindings/spi/spi-atcspi200.txt

diff --git a/doc/device-tree-bindings/spi/spi-atcspi200.txt 
b/doc/device-tree-bindings/spi/spi-atcspi200.txt
new file mode 100644
index 000..9c0630b
--- /dev/null
+++ b/doc/device-tree-bindings/spi/spi-atcspi200.txt
@@ -0,0 +1,37 @@
+Andestech ATCSPI200 SPI controller Device Tree Bindings
+---
+ATCSPI200 is a Serial Peripheral Interface (SPI) controller
+which serves as a SPI master or a SPI slave.
+
+It is often be embedded in AE3XX and AE250 platforms.
+
+Required properties:
+- compatible: has to be "andestech,atcspi200".
+- reg: Base address and size of the controllers memory area.
+- #address-cells: <1>, as required by generic SPI binding.
+- #size-cells: <0>, also as required by generic SPI binding.
+- interrupts: Property with a value describing the interrupt number.
+- clocks: Clock phandles (see clock bindings for details).
+- spi-max-frequency: Maximum SPI clocking speed of device in Hz.
+
+Optional properties:
+- num-cs: Number of chip selects used.
+
+Example:
+
+   spi: spi@f0b0 {
+   compatible = "andestech,atcspi200";
+   reg = <0xf0b0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   num-cs = <1>;
+   clocks = <>;
+   interrupts = <3 4>;
+   flash@0 {
+   compatible = "spi-flash";
+   spi-max-frequency = <5000>;
+   reg = <0>;
+   spi-cpol;
+   spi-cpha;
+   };
+   };
-- 
2.7.4

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

[U-Boot] [PATCH] arm: zynq: Change Zynq/ZynqMP Kconfig description

[Michal Simek]

Use more accurate description for Xilinx Zynq and ZynqMP based platforms.
With using driver model there shouldn't be a need to create separate
Kconfig config options.

Signed-off-by: Michal Simek 
---

 arch/arm/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 94ad80568446..631c0fa32e54 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -738,7 +738,7 @@ config ARCH_VF610
imply NAND
 
 config ARCH_ZYNQ
-   bool "Xilinx Zynq Platform"
+   bool "Xilinx Zynq based platform"
select BOARD_LATE_INIT
select CPU_V7
select SUPPORT_SPL
@@ -764,7 +764,7 @@ config ARCH_ZYNQ
imply CMD_SPL
 
 config ARCH_ZYNQMP
-   bool "Support Xilinx ZynqMP Platform"
+   bool "Xilinx ZynqMP based platform"
select ARM64
select BOARD_LATE_INIT
select DM
-- 
1.9.1

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

Re: [U-Boot] [PATCH 3/3] mx6sxsabresd: Use PARTUUID to specify the rootfs location

[Stefano Babic]

On 22/11/2017 14:15, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> mx6sxsabresd can run different kernel versions, such as NXP 4.1 or mainline.
> 
> Currently the rootfs location is passed via mmcblk number and the
> problem with this approach is that the mmcblk number for the SD
> card changes depending on the kernel version.
> 
> In order to avoid such issue, use the UUID method to specify the
> rootfs location.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  configs/mx6sxsabresd_defconfig | 1 +
>  include/configs/mx6sxsabresd.h | 5 +++--
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/configs/mx6sxsabresd_defconfig b/configs/mx6sxsabresd_defconfig
> index ac36a18..b707322 100644
> --- a/configs/mx6sxsabresd_defconfig
> +++ b/configs/mx6sxsabresd_defconfig
> @@ -12,6 +12,7 @@ CONFIG_CMD_BOOTZ=y
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
> +CONFIG_CMD_PART=y
>  CONFIG_CMD_PCI=y
>  CONFIG_CMD_USB=y
>  # CONFIG_CMD_SETEXPR is not set
> diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
> index 85b8601..906e677 100644
> --- a/include/configs/mx6sxsabresd.h
> +++ b/include/configs/mx6sxsabresd.h
> @@ -58,9 +58,9 @@
>   
> "videomode=video=ctfb:x:800,y:480,depth:24,pclk:29850,le:89,ri:164,up:23,lo:10,hs:10,vs:10,sync:0,vmode:0\0"
>  \
>   "mmcdev=2\0" \
>   "mmcpart=1\0" \
> - "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
> + "finduuid=part uuid mmc 2:2 uuid\0" \
>   "mmcargs=setenv bootargs console=${console},${baudrate} " \
> - "root=${mmcroot}\0" \
> + "root=PARTUUID=${uuid} rootwait rw\0" \
>   "loadbootscript=" \
>   "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
>   "bootscript=echo Running bootscript from mmc ...; " \
> @@ -68,6 +68,7 @@
>   "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
>   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
>   "mmcboot=echo Booting from mmc ...; " \
> + "run finduuid; " \
>   "run mmcargs; " \
>   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
>   "if run loadfdt; then " \
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano

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

Re: [U-Boot] [PATCH 2/3] mx6sxsabresd: Load the correct dtb for revA board

[Stefano Babic]

On 22/11/2017 14:15, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> Currently only imx6sx-sdb.dtb is loaded, but if revA board is used the
> correct dtb is imx6sx-sdb-reva.dtb, so make this possible.
> 
> While at it, remove an extra 'mmc dev'.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/mach-imx/mx6/Kconfig   |  1 +
>  board/freescale/mx6sxsabresd/mx6sxsabresd.c | 16 +++-
>  configs/mx6sxsabresd_defconfig  |  1 +
>  include/configs/mx6sxsabresd.h  |  8 ++--
>  4 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
> index 6f5a92a..52d9984 100644
> --- a/arch/arm/mach-imx/mx6/Kconfig
> +++ b/arch/arm/mach-imx/mx6/Kconfig
> @@ -266,6 +266,7 @@ config TARGET_MX6SLLEVK
>  
>  config TARGET_MX6SXSABRESD
>   bool "mx6sxsabresd"
> + select BOARD_LATE_INIT
>   select MX6SX
>   select SUPPORT_SPL
>   select DM
> diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c 
> b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
> index 2aeef61..8a918a5 100644
> --- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
> +++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
> @@ -540,9 +540,23 @@ int board_init(void)
>   return 0;
>  }
>  
> +static bool is_reva(void)
> +{
> + return (nxp_board_rev() == 1);
> +}
> +
> +int board_late_init(void)
> +{
> +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> + if (is_reva())
> + env_set("board_rev", "REVA");
> +#endif
> + return 0;
> +}
> +
>  int checkboard(void)
>  {
> - puts("Board: MX6SX SABRE SDB\n");
> + printf("Board: MX6SX SABRE SDB rev%s\n", nxp_board_rev_string());
>  
>   return 0;
>  }
> diff --git a/configs/mx6sxsabresd_defconfig b/configs/mx6sxsabresd_defconfig
> index c4eb7ca..ac36a18 100644
> --- a/configs/mx6sxsabresd_defconfig
> +++ b/configs/mx6sxsabresd_defconfig
> @@ -2,6 +2,7 @@ CONFIG_ARM=y
>  CONFIG_ARCH_MX6=y
>  CONFIG_TARGET_MX6SXSABRESD=y
>  # CONFIG_CMD_BMODE is not set
> +CONFIG_NXP_BOARD_REVISION=y
>  
> CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6sxsabresd/imximage.cfg"
>  # CONFIG_CONSOLE_MUX is not set
>  CONFIG_SYS_CONSOLE_IS_IN_ENV=y
> diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
> index 5ef78a7..85b8601 100644
> --- a/include/configs/mx6sxsabresd.h
> +++ b/include/configs/mx6sxsabresd.h
> @@ -43,6 +43,7 @@
>  #define UPDATE_M4_ENV ""
>  #endif
>  
> +#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>  #define CONFIG_EXTRA_ENV_SETTINGS \
>   UPDATE_M4_ENV \
>   "script=boot.scr\0" \
> @@ -104,10 +105,13 @@
>   "fi; " \
>   "else " \
>   "bootz; " \
> - "fi;\0"
> + "fi;\0" \
> + "findfdt="\
> + "if test test $board_rev = REVA ; then " \
> + "setenv fdt_file imx6sx-sdb-reva.dtb; fi; " \
>  
>  #define CONFIG_BOOTCOMMAND \
> -"mmc dev ${mmcdev};" \
> +"run findfdt; " \
>  "mmc dev ${mmcdev}; if mmc rescan; then " \
>  "if run loadbootscript; then " \
>  "run bootscript; " \
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano

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

Re: [U-Boot] [PATCH v2 1/1] ubifs: avoid possible NULL dereference

[Ladislav Michl]

On Wed, Nov 22, 2017 at 02:37:49PM +0100, Ladislav Michl wrote:
> On Wed, Nov 22, 2017 at 01:37:54PM +0100, Heinrich Schuchardt wrote:
[snip]
> > I agree that there is a memory leak. But we should put fixing that into a
> > separate patch so that we can test both modifications separately.
> 
> There was no such memory leak before above patch.
> 
> > It is not enough to kfree(dent).
> > ubifs_tnc_next_ent may return ERR_PTR(err) and we do not want to pass this
> > value to kfree.
> 
> Nobody is claiming otherwise.
> 
> > As Wolfgang wrote we should pass error codes to the calling chain of
> > ubifs_finddir(), i.e. ubifs_findfile(), ubifs_size(), ubifs_read,
> > ubifs_exists(), ubifs_ls(), ...
> > 
> > The code also lacks support for the driver model.
> > 
> > So a lot of other patches needed.
> 
> Yes, but fix should not add another bug.
> 
> > If you think this patch fixes what it promises to fix, please, add your
> > review comment.
> 
> What about (untested)?
[snip]

Okay, just tried to test it. Does ubifsmount even work for you?
I cannot mount volume neither using name nor id.

Does not work on NAND:
=> ubi part UBI
=> ubifsmount ubi0:rootfs
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
=> ubifsmount ubi5 
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
=> ubifsmount ubi0_5
UBIFS error (pid: 1): cannot open "ubi0_5", error -19Error reading superblock 
on volume 'ubi0_5' errno=-19!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount 
- mount 'volume-name' volume
=> ubifsmount ubi0_5


Does not work on OneNAND:
=> ubifsmount ubi0_5
Error reading superblock on volume 'ubi0_5' errno=-22!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount 
- mount 'volume-name' volume
=> ubifsmount ubi0_5
UBIFS error (ubi0:5 pid 0): check_lpt_crc: invalid crc in LPT node: crc d514 
calc 6695
UBIFS error (ubi0:5 pid 0): read_pnode: error -22 reading pnode at 8:16424
(pid 1) dumping pnode:
address 9dfb2dc0 parent 9dfb2d40 cnext 0
flags 0 iip 1 level 0 num 0
0: free 0 dirty 97240 flags 1 lnum 0
1: free 57344 dirty 39752 flags 34 lnum 0
2: free 0 dirty 111296 flags 1 lnum 0
3: free 0 dirty 85952 flags 34 lnum 0
UBIFS error (ubi0:5 pid 0): read_pnode: calc num: 89
UBIFS assert failed in ubifs_release_lprops at 278
Error reading superblock on volume 'ubi0_5' errno=-22!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount 
- mount 'volume-name' volume

See? It even gives different output for the same command.
Tried every possible options to mount volume found in open_ubi...

So given above unfortunate state, I'm considering fixing $subject mentioned
a bit pointless as I'm not able to test it.

I'll look at mount problems later.

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

[U-Boot] [PATCH v2 2/3] rockchip: rk3399-puma: implement usb_hub_reset_devices for puma-rk3399

[Philipp Tomsich]

For some versions of the RK3399-Q7 (at least revisions v1.1 and v1.2
are affected), we need to turn on the power for the port connected to
the on-module USB hub only when the device is probed for the first
time to ensure that the hub does not enter a low-power mode (that
U-Boot's USB stack can't deal with).

Note that this is needed for U-Boot only, as Linux eventually manages
to attach the hub even when it has entered into its low-power state
(when the hub wakes up the next time) after a few seconds.

Signed-off-by: Philipp Tomsich 

---

Changes in v2:
- moved the power-control logic from xhci.c into the board-specific
  file for the RK3399-Q7, hooking it up via usb_hub_reset_devices

 board/theobroma-systems/puma_rk3399/puma-rk3399.c | 70 ++-
 1 file changed, 69 insertions(+), 1 deletion(-)

diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c 
b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index 2b4988e..7f2dd65 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -7,12 +7,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -158,3 +159,70 @@ void get_board_serial(struct tag_serialnr *serialnr)
serialnr->low = (u32)(serial & 0x);
 }
 #endif
+
+/**
+ * Switch power at an external regulator (for our root hub).
+ *
+ * @param ctrl pointer to the xHCI controller
+ * @param port port number as in the control message (one-based)
+ * @param enable boolean indicating whether to enable or disable power
+ * @return returns 0 on success, an error-code on failure
+ */
+static int board_usb_port_power_set(struct udevice *dev, int port,
+   bool enable)
+{
+#if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(DM_REGULATOR)
+   /* We start counting ports at 0, while USB counts from 1. */
+   int index = port - 1;
+   const char *regname = NULL;
+   struct udevice *regulator;
+   const char *prop = "tsd,usb-port-power";
+   int ret;
+
+   debug("%s: ctrl '%s' port %d enable %s\n", __func__,
+ dev_read_name(dev), port, enable ? "true" : "false");
+
+   ret = dev_read_string_index(dev, prop, index, );
+   if (ret < 0) {
+   debug("%s: ctrl '%s' port %d: no entry in '%s'\n",
+ __func__, dev_read_name(dev), port, prop);
+   return ret;
+   }
+
+   ret = regulator_get_by_platname(regname, );
+   if (ret) {
+   debug("%s: ctrl '%s' port %d: could not get regulator '%s'\n",
+ __func__, dev_read_name(dev), port, regname);
+   return ret;
+   }
+
+   regulator_set_enable(regulator, enable);
+   return 0;
+#else
+   return -ENOTSUPP;
+#endif
+}
+
+void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
+{
+   struct udevice *dev = hub->pusb_dev->dev;
+   struct udevice *ctrl;
+
+   /* We are only interested in our root-hubs */
+   if (usb_hub_is_root_hub(dev) == false)
+   return;
+
+   ctrl = usb_get_bus(dev);
+   if (!ctrl) {
+   debug("%s: could not retrieve ctrl for hub\n", __func__);
+   return;
+   }
+
+   /*
+* To work around an incompatibility between the single-threaded
+* USB stack in U-Boot and (a strange low-power mode of) the USB
+* hub we have on-module, we need to delay powering on the hub
+* until the first time the port is probed.
+*/
+   board_usb_port_power_set(ctrl, port, true);
+}
-- 
2.1.4

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

[U-Boot] [PATCH v2 1/3] usb: hub: identify the hub-device to usb_hub_reset_devices

[Philipp Tomsich]

When usb_hub_reset_devices is called, it should be passed both an
indicator which hub it should operate on and what port number (local
to that hub) should be reset.

This adds an additional 'hub' parameter to usb_hub_reset_devices.
Existing implementations are changed to simply ignore the new
parameter.

Signed-off-by: Philipp Tomsich 

---

Changes in v2:
- new in v2

 board/compulab/cm_t54/cm_t54.c | 2 +-
 board/ti/omap5_uevm/evm.c  | 2 +-
 common/usb_hub.c   | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
index 31730a4..3e6235a 100644
--- a/board/compulab/cm_t54/cm_t54.c
+++ b/board/compulab/cm_t54/cm_t54.c
@@ -246,7 +246,7 @@ int ehci_hcd_stop(void)
return ret;
 }
 
-void usb_hub_reset_devices(int port)
+void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
 {
/* The LAN9730 needs to be reset after the port power has been set. */
if (port == 3) {
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 4b25cc2..67242f5 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -249,7 +249,7 @@ int ehci_hcd_stop(void)
return omap_ehci_hcd_stop();
 }
 
-void usb_hub_reset_devices(int port)
+void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
 {
/* The LAN9730 needs to be reset after the port power has been set. */
if (port == 3) {
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 325d16d..024dadb 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -57,7 +57,7 @@ struct usb_device_scan {
 
 static LIST_HEAD(usb_scan_list);
 
-__weak void usb_hub_reset_devices(int port)
+__weak void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
 {
return;
 }
@@ -853,7 +853,7 @@ static int usb_hub_configure(struct usb_device *dev)
 * should occur in the board file of the device.
 */
for (i = 0; i < dev->maxchild; i++)
-   usb_hub_reset_devices(i + 1);
+   usb_hub_reset_devices(hub, i + 1);
 
/*
 * Only add the connected USB devices, including potential hubs,
-- 
2.1.4

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

[U-Boot] [PATCH v2 3/3] rockchip: dts: rk3399-puma: add a 'tsd, usb-port-power' stringlist for USB1

[Philipp Tomsich]

USB1 is connected to the on-module USB 3.0 hub and power to the hub
(actually it's a reset signal, modeled as a fixed regulator, that will
be released) should be enabled only during the first probing of the
device to avoid the hub from entering its low-power mode (where it
tries to attach on a fixed interval, but we always miss the timeslot
when U-Boot has the controller listening).

This adds a 'tsd,usb-port-power' stringlist to enable the
infrastructure in the board-specific usb_hub_reset_devices to find and
control the fixed regulator associated with control of the USB hub.

Signed-off-by: Philipp Tomsich 

---

Changes in v2:
- changed the property name to 'tsd,usb-port-power' to make it a
  vendor-specific property

 arch/arm/dts/rk3399-puma.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
index 96bd4fe..0f5e6ac 100644
--- a/arch/arm/dts/rk3399-puma.dtsi
+++ b/arch/arm/dts/rk3399-puma.dtsi
@@ -544,6 +544,7 @@
 
 _typec1 {
status = "okay";
+   tsd,usb-port-power = "usbhub_enable";
 };
 
  {
-- 
2.1.4

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

Re: [U-Boot] [PATCH 1/3] imx: Add a common way for detecting NXP boards revision

[Stefano Babic]

Hi Fabio,

On 22/11/2017 14:15, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> NXP development boards based on i.MX6/i.MX7 contain the board
> revision information stored in the fuses.
> 

This is a good idea.

> Introduce a common function that can be shared by different boards and
> convert mx6sabreauto to use this new mechanism.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/include/asm/mach-imx/sys_proto.h   |  3 ++
>  arch/arm/mach-imx/Kconfig   |  8 +
>  arch/arm/mach-imx/cpu.c | 27 +
>  board/freescale/mx6sabreauto/mx6sabreauto.c | 47 
> ++---
>  configs/mx6sabreauto_defconfig  |  1 +
>  5 files changed, 41 insertions(+), 45 deletions(-)
> 
> diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
> b/arch/arm/include/asm/mach-imx/sys_proto.h
> index 7036343..d5e3eec 100644
> --- a/arch/arm/include/asm/mach-imx/sys_proto.h
> +++ b/arch/arm/include/asm/mach-imx/sys_proto.h
> @@ -109,6 +109,9 @@ void imx_set_wdog_powerdown(bool enable);
>  
>  int board_mmc_get_env_dev(int devno);
>  
> +int nxp_board_rev(void);
> +const char *nxp_board_rev_string(void);
> +
>  /*
>   * Initializes on-chip ethernet controllers.
>   * to override, implement board_eth_init()
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index cd8b8d2..81ab125 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -61,3 +61,11 @@ config CMD_HDMIDETECT
>   help
> This enables the 'hdmidet' command which detects if an HDMI monitor
> is connected.
> +
> +config NXP_BOARD_REVISION
> + bool "Read NXP board revision from fuses"
> + depends on ARCH_MX6 || ARCH_MX7
> + help
> +   NXP boards based on i.MX6/7 contain the board revision information
> +   stored in the fuses. Select this option if you want to be able to
> +   retrieve the board revision information.
> diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
> index 18205dc..84e829e 100644
> --- a/arch/arm/mach-imx/cpu.c
> +++ b/arch/arm/mach-imx/cpu.c

ACK. And maybe this can be used by other boards, too, instead of
reinvent the wheel any time :-)

> @@ -323,3 +323,30 @@ void set_chipselect_size(int const cs_size)
>  
>   writel(reg, _regs->gpr[1]);
>  }
> +
> +#ifdef CONFIG_NXP_BOARD_REVISION
> +int nxp_board_rev(void)
> +{
> + /*
> +  * Get Board ID information from OCOTP_GP1[15:8]
> +  * RevA: 0x1
> +  * RevB: 0x2
> +  * RevC: 0x3
> +  */
> + struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
> + struct fuse_bank *bank = >bank[4];
> + struct fuse_bank4_regs *fuse =
> + (struct fuse_bank4_regs *)bank->fuse_regs;
> +
> + return (readl(>gp1) >> 8 & 0x0F);
> +}
> +
> +const char *nxp_board_rev_string(void)
> +{
> + char *rev = "A" - 1;
> +
> + rev += nxp_board_rev();
> +
> + return rev;
> +}
> +#endif
> diff --git a/board/freescale/mx6sabreauto/mx6sabreauto.c 
> b/board/freescale/mx6sabreauto/mx6sabreauto.c
> index bdeb5f7..ced254a 100644
> --- a/board/freescale/mx6sabreauto/mx6sabreauto.c
> +++ b/board/freescale/mx6sabreauto/mx6sabreauto.c
> @@ -397,39 +397,9 @@ int board_eth_init(bd_t *bis)
>   return cpu_eth_init(bis);
>  }
>  
> -#define BOARD_REV_B  0x200
> -#define BOARD_REV_A  0x100
> -
> -static int mx6sabre_rev(void)
> -{
> - /*
> -  * Get Board ID information from OCOTP_GP1[15:8]
> -  * i.MX6Q ARD RevA: 0x01
> -  * i.MX6Q ARD RevB: 0x02
> -  */
> - struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
> - struct fuse_bank *bank = >bank[4];
> - struct fuse_bank4_regs *fuse =
> - (struct fuse_bank4_regs *)bank->fuse_regs;
> - int reg = readl(>gp1);
> - int ret;
> -
> - switch (reg >> 8 & 0x0F) {
> - case 0x02:
> - ret = BOARD_REV_B;
> - break;
> - case 0x01:
> - default:
> - ret = BOARD_REV_A;
> - break;
> - }
> -
> - return ret;
> -}
> -
>  u32 get_board_rev(void)
>  {
> - int rev = mx6sabre_rev();
> + int rev = nxp_board_rev();
>  
>   return (get_cpu_rev() & ~(0xF << 8)) | rev;
>  }
> @@ -703,20 +673,7 @@ int board_late_init(void)
>  
>  int checkboard(void)
>  {
> - int rev = mx6sabre_rev();
> - char *revname;
> -
> - switch (rev) {
> - case BOARD_REV_B:
> - revname = "B";
> - break;
> - case BOARD_REV_A:
> - default:
> - revname = "A";
> - break;
> - }
> -
> - printf("Board: MX6Q-Sabreauto rev%s\n", revname);
> + printf("Board: MX6Q-Sabreauto rev%s\n", nxp_board_rev_string());
>  
>   return 0;
>  }
> diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
> index 418a836..215700b 100644
> --- a/configs/mx6sabreauto_defconfig
> +++ b/configs/mx6sabreauto_defconfig
> @@ -8,6 

Re: [U-Boot] [PATCH 0/5] mmc: fixes for HS200/UHS core support

[Marek Vasut]

On 11/22/2017 01:09 PM, Jaehoon Chung wrote:
> On 11/22/2017 12:13 AM, Jean-Jacques Hiblot wrote:
>> This series applies on top of "[PATCH v2 00/26] mmc: Add support for HS200
>> and UHS modes"
>>
>> It fixes a bug with old SD and MMC cards that support only the legacy mode.
>> It also addresses the comments made on the mailing list:
>> * dump card and host capabilities in debug mode
>> * use 1-bit if the DTS property 'bus-width' is not present.
>> * recognize the "mmc-ddr-1_2v" and "mmc-hs200-1_2v" DTS properties
>>
>> Tested on DRA7, DRA72 and AM335x
> 
> Thanks for sending patches. After testing with my boards, will update.
> For your patches, i made the testing-uhs-supporting branch on u-boot-mmc.
> 
> At least, i will share the result about testing with my boards.
Any chance this UHS support will make it into this release finally ?
It's been dragging on for like half a year already ...

-- 
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 1/3] usb: hub: identify the hub-device to usb_hub_reset_devices

[Marek Vasut]

On 11/22/2017 04:57 PM, Philipp Tomsich wrote:
> When usb_hub_reset_devices is called, it should be passed both an
> indicator which hub it should operate on and what port number (local
> to that hub) should be reset.

Why ?

> This adds an additional 'hub' parameter to usb_hub_reset_devices.
> Existing implementations are changed to simply ignore the new
> parameter.
> 
> Signed-off-by: Philipp Tomsich 
> 
> ---
> 
> Changes in v2:
> - new in v2
> 
>  board/compulab/cm_t54/cm_t54.c | 2 +-
>  board/ti/omap5_uevm/evm.c  | 2 +-
>  common/usb_hub.c   | 4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
> index 31730a4..3e6235a 100644
> --- a/board/compulab/cm_t54/cm_t54.c
> +++ b/board/compulab/cm_t54/cm_t54.c
> @@ -246,7 +246,7 @@ int ehci_hcd_stop(void)
>   return ret;
>  }
>  
> -void usb_hub_reset_devices(int port)
> +void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>  {
>   /* The LAN9730 needs to be reset after the port power has been set. */
>   if (port == 3) {
> diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
> index 4b25cc2..67242f5 100644
> --- a/board/ti/omap5_uevm/evm.c
> +++ b/board/ti/omap5_uevm/evm.c
> @@ -249,7 +249,7 @@ int ehci_hcd_stop(void)
>   return omap_ehci_hcd_stop();
>  }
>  
> -void usb_hub_reset_devices(int port)
> +void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>  {
>   /* The LAN9730 needs to be reset after the port power has been set. */
>   if (port == 3) {
> diff --git a/common/usb_hub.c b/common/usb_hub.c
> index 325d16d..024dadb 100644
> --- a/common/usb_hub.c
> +++ b/common/usb_hub.c
> @@ -57,7 +57,7 @@ struct usb_device_scan {
>  
>  static LIST_HEAD(usb_scan_list);
>  
> -__weak void usb_hub_reset_devices(int port)
> +__weak void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>  {
>   return;
>  }
> @@ -853,7 +853,7 @@ static int usb_hub_configure(struct usb_device *dev)
>* should occur in the board file of the device.
>*/
>   for (i = 0; i < dev->maxchild; i++)
> - usb_hub_reset_devices(i + 1);
> + usb_hub_reset_devices(hub, i + 1);
>  
>   /*
>* Only add the connected USB devices, including potential hubs,
> 


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

[U-Boot] [PATCH v3 2/3] rockchip: rk3399-puma: implement usb_hub_reset_devices for puma-rk3399

[Philipp Tomsich]

For some versions of the RK3399-Q7 (at least revisions v1.1 and v1.2
are affected), we need to turn on the power for the port connected to
the on-module USB hub only when the device is probed for the first
time to ensure that the hub does not enter a low-power mode (that
U-Boot's USB stack can't deal with).

Note that this is needed for U-Boot only, as Linux eventually manages
to attach the hub even when it has entered into its low-power state
(when the hub wakes up the next time) after a few seconds.

Signed-off-by: Philipp Tomsich 
Tested-by: Jakob Unterwurzacher 

---

Changes in v3: None
Changes in v2:
- moved the power-control logic from xhci.c into the board-specific
  file for the RK3399-Q7, hooking it up via usb_hub_reset_devices

 board/theobroma-systems/puma_rk3399/puma-rk3399.c | 70 ++-
 1 file changed, 69 insertions(+), 1 deletion(-)

diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c 
b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index 2b4988e..7f2dd65 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -7,12 +7,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -158,3 +159,70 @@ void get_board_serial(struct tag_serialnr *serialnr)
serialnr->low = (u32)(serial & 0x);
 }
 #endif
+
+/**
+ * Switch power at an external regulator (for our root hub).
+ *
+ * @param ctrl pointer to the xHCI controller
+ * @param port port number as in the control message (one-based)
+ * @param enable boolean indicating whether to enable or disable power
+ * @return returns 0 on success, an error-code on failure
+ */
+static int board_usb_port_power_set(struct udevice *dev, int port,
+   bool enable)
+{
+#if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(DM_REGULATOR)
+   /* We start counting ports at 0, while USB counts from 1. */
+   int index = port - 1;
+   const char *regname = NULL;
+   struct udevice *regulator;
+   const char *prop = "tsd,usb-port-power";
+   int ret;
+
+   debug("%s: ctrl '%s' port %d enable %s\n", __func__,
+ dev_read_name(dev), port, enable ? "true" : "false");
+
+   ret = dev_read_string_index(dev, prop, index, );
+   if (ret < 0) {
+   debug("%s: ctrl '%s' port %d: no entry in '%s'\n",
+ __func__, dev_read_name(dev), port, prop);
+   return ret;
+   }
+
+   ret = regulator_get_by_platname(regname, );
+   if (ret) {
+   debug("%s: ctrl '%s' port %d: could not get regulator '%s'\n",
+ __func__, dev_read_name(dev), port, regname);
+   return ret;
+   }
+
+   regulator_set_enable(regulator, enable);
+   return 0;
+#else
+   return -ENOTSUPP;
+#endif
+}
+
+void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
+{
+   struct udevice *dev = hub->pusb_dev->dev;
+   struct udevice *ctrl;
+
+   /* We are only interested in our root-hubs */
+   if (usb_hub_is_root_hub(dev) == false)
+   return;
+
+   ctrl = usb_get_bus(dev);
+   if (!ctrl) {
+   debug("%s: could not retrieve ctrl for hub\n", __func__);
+   return;
+   }
+
+   /*
+* To work around an incompatibility between the single-threaded
+* USB stack in U-Boot and (a strange low-power mode of) the USB
+* hub we have on-module, we need to delay powering on the hub
+* until the first time the port is probed.
+*/
+   board_usb_port_power_set(ctrl, port, true);
+}
-- 
2.1.4

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

[U-Boot] [PATCH v3 3/3] rockchip: dts: rk3399-puma: add a 'tsd, usb-port-power' stringlist for USB1

[Philipp Tomsich]

USB1 is connected to the on-module USB 3.0 hub and power to the hub
(actually it's a reset signal, modeled as a fixed regulator, that will
be released) should be enabled only during the first probing of the
device to avoid the hub from entering its low-power mode (where it
tries to attach on a fixed interval, but we always miss the timeslot
when U-Boot has the controller listening).

This adds a 'tsd,usb-port-power' stringlist to enable the
infrastructure in the board-specific usb_hub_reset_devices to find and
control the fixed regulator associated with control of the USB hub.

Signed-off-by: Philipp Tomsich 
Tested-by: Jakob Unterwurzacher 

---

Changes in v3: None
Changes in v2:
- changed the property name to 'tsd,usb-port-power' to make it a
  vendor-specific property

 arch/arm/dts/rk3399-puma.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
index 96bd4fe..0f5e6ac 100644
--- a/arch/arm/dts/rk3399-puma.dtsi
+++ b/arch/arm/dts/rk3399-puma.dtsi
@@ -544,6 +544,7 @@
 
 _typec1 {
status = "okay";
+   tsd,usb-port-power = "usbhub_enable";
 };
 
  {
-- 
2.1.4

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

Re: [U-Boot] [PATCH v3 1/3] usb: hub: identify the hub-device to usb_hub_reset_devices

[Dr. Philipp Tomsich]

> On 22 Nov 2017, at 17:23, Marek Vasut  wrote:
> 
> On 11/22/2017 05:15 PM, Philipp Tomsich wrote:
>> When usb_hub_reset_devices is called, it should be passed both an
>> indicator which hub it should operate on and what port number (local
>> to that hub) should be reset.
>> 
>> Previously, the usb_hub.c code did not include such context and
>> always started resets from port number 1, performing multiple
>> reset-requests for the same devices:
>> 
>>   /*
>>* Reset any devices that may be in a bad state when applying
>>* the power.  This is a __weak function.  Resetting of the devices
>>* should occur in the board file of the device.
>>*/
>>   for (i = 0; i < dev->maxchild; i++)
>>  usb_hub_reset_devices(i + 1);
>> 
>> This adds an additional 'hub' parameter to usb_hub_reset_devices
>> that provides the context to fully qualify the port-number in.
>> 
>> Existing implementations are changed to accept and ignore the new
>> parameter.
>> 
>> Signed-off-by: Philipp Tomsich 
>> Tested-by: Jakob Unterwurzacher 
> 
> Reviewed-by: Marek Vasut 
> 
> This is part of a series, what;s the plan here. Pull it via usb or some
> other tree ?

I’ll leave this decision to you:
(a) I move this through the rockchip tree, based on the change to the
USB subsystem being trivial (and you having reviewed this patch)
(b) you apply the entire series through the USB tree … and if there’s any
conflicts created in what I have sitting in the rockchip queue, then 
it’s
my problem anyway

I certainly don’t want to tear the series apart, as I’ll have the later patches
sit in my queue until the first one is merged onto master… 

>> ---
>> 
>> Changes in v3:
>> - updated commit message
>> 
>> Changes in v2:
>> - new in v2
>> 
>> board/compulab/cm_t54/cm_t54.c | 2 +-
>> board/ti/omap5_uevm/evm.c  | 2 +-
>> common/usb_hub.c   | 4 ++--
>> 3 files changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
>> index 31730a4..3e6235a 100644
>> --- a/board/compulab/cm_t54/cm_t54.c
>> +++ b/board/compulab/cm_t54/cm_t54.c
>> @@ -246,7 +246,7 @@ int ehci_hcd_stop(void)
>>  return ret;
>> }
>> 
>> -void usb_hub_reset_devices(int port)
>> +void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>> {
>>  /* The LAN9730 needs to be reset after the port power has been set. */
>>  if (port == 3) {
>> diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
>> index 4b25cc2..67242f5 100644
>> --- a/board/ti/omap5_uevm/evm.c
>> +++ b/board/ti/omap5_uevm/evm.c
>> @@ -249,7 +249,7 @@ int ehci_hcd_stop(void)
>>  return omap_ehci_hcd_stop();
>> }
>> 
>> -void usb_hub_reset_devices(int port)
>> +void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>> {
>>  /* The LAN9730 needs to be reset after the port power has been set. */
>>  if (port == 3) {
>> diff --git a/common/usb_hub.c b/common/usb_hub.c
>> index 325d16d..024dadb 100644
>> --- a/common/usb_hub.c
>> +++ b/common/usb_hub.c
>> @@ -57,7 +57,7 @@ struct usb_device_scan {
>> 
>> static LIST_HEAD(usb_scan_list);
>> 
>> -__weak void usb_hub_reset_devices(int port)
>> +__weak void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>> {
>>  return;
>> }
>> @@ -853,7 +853,7 @@ static int usb_hub_configure(struct usb_device *dev)
>>   * should occur in the board file of the device.
>>   */
>>  for (i = 0; i < dev->maxchild; i++)
>> -usb_hub_reset_devices(i + 1);
>> +usb_hub_reset_devices(hub, i + 1);
>> 
>>  /*
>>   * Only add the connected USB devices, including potential hubs,
>> 
> 
> 
> -- 
> 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 1/3] usb: hub: identify the hub-device to usb_hub_reset_devices

[Dr. Philipp Tomsich]

> On 22 Nov 2017, at 16:59, Marek Vasut  wrote:
> 
> On 11/22/2017 04:57 PM, Philipp Tomsich wrote:
>> When usb_hub_reset_devices is called, it should be passed both an
>> indicator which hub it should operate on and what port number (local
>> to that hub) should be reset.
> 
> Why ?

Simply because there will be multiple root hubs in the system, which may
have multiple hubs attached.  And the usb_hub_reset_devices() function
was being called for every hub with just a port-number, but without the
context of what number-space (i.e. hub) that port-number belonged to.

The code in usb_hub previously was:
/*
 * Reset any devices that may be in a bad state when applying
 * the power.  This is a __weak function.  Resetting of the devices
 * should occur in the board file of the device.
 */
for (i = 0; i < dev->maxchild; i++)
usb_hub_reset_devices(i + 1);

So it would call usb_hub_reset_devices(1) for the first port of every
attached hub (including the root-hubs).

I.e. the implementation of usb_hub_reset_devices had no idea what
(hub, port)-combination it was dealing with...

> 
>> This adds an additional 'hub' parameter to usb_hub_reset_devices.
>> Existing implementations are changed to simply ignore the new
>> parameter.
>> 
>> Signed-off-by: Philipp Tomsich 
>> 
>> ---
>> 
>> Changes in v2:
>> - new in v2
>> 
>> board/compulab/cm_t54/cm_t54.c | 2 +-
>> board/ti/omap5_uevm/evm.c  | 2 +-
>> common/usb_hub.c   | 4 ++--
>> 3 files changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
>> index 31730a4..3e6235a 100644
>> --- a/board/compulab/cm_t54/cm_t54.c
>> +++ b/board/compulab/cm_t54/cm_t54.c
>> @@ -246,7 +246,7 @@ int ehci_hcd_stop(void)
>>  return ret;
>> }
>> 
>> -void usb_hub_reset_devices(int port)
>> +void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>> {
>>  /* The LAN9730 needs to be reset after the port power has been set. */
>>  if (port == 3) {
>> diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
>> index 4b25cc2..67242f5 100644
>> --- a/board/ti/omap5_uevm/evm.c
>> +++ b/board/ti/omap5_uevm/evm.c
>> @@ -249,7 +249,7 @@ int ehci_hcd_stop(void)
>>  return omap_ehci_hcd_stop();
>> }
>> 
>> -void usb_hub_reset_devices(int port)
>> +void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>> {
>>  /* The LAN9730 needs to be reset after the port power has been set. */
>>  if (port == 3) {
>> diff --git a/common/usb_hub.c b/common/usb_hub.c
>> index 325d16d..024dadb 100644
>> --- a/common/usb_hub.c
>> +++ b/common/usb_hub.c
>> @@ -57,7 +57,7 @@ struct usb_device_scan {
>> 
>> static LIST_HEAD(usb_scan_list);
>> 
>> -__weak void usb_hub_reset_devices(int port)
>> +__weak void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>> {
>>  return;
>> }
>> @@ -853,7 +853,7 @@ static int usb_hub_configure(struct usb_device *dev)
>>   * should occur in the board file of the device.
>>   */
>>  for (i = 0; i < dev->maxchild; i++)
>> -usb_hub_reset_devices(i + 1);
>> +usb_hub_reset_devices(hub, i + 1);
>> 
>>  /*
>>   * Only add the connected USB devices, including potential hubs,
>> 
> 
> 
> -- 
> 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 1/3] usb: hub: identify the hub-device to usb_hub_reset_devices

[Marek Vasut]

On 11/22/2017 05:02 PM, Dr. Philipp Tomsich wrote:
> 
>> On 22 Nov 2017, at 16:59, Marek Vasut  wrote:
>>
>> On 11/22/2017 04:57 PM, Philipp Tomsich wrote:
>>> When usb_hub_reset_devices is called, it should be passed both an
>>> indicator which hub it should operate on and what port number (local
>>> to that hub) should be reset.
>>
>> Why ?
> 
> Simply because there will be multiple root hubs in the system, which may
> have multiple hubs attached.  And the usb_hub_reset_devices() function
> was being called for every hub with just a port-number, but without the
> context of what number-space (i.e. hub) that port-number belonged to.
> 
> The code in usb_hub previously was:
> /*
>  * Reset any devices that may be in a bad state when applying
>  * the power.  This is a __weak function.  Resetting of the devices
>  * should occur in the board file of the device.
>  */
> for (i = 0; i < dev->maxchild; i++)
> usb_hub_reset_devices(i + 1);
> 
> So it would call usb_hub_reset_devices(1) for the first port of every
> attached hub (including the root-hubs).
> 
> I.e. the implementation of usb_hub_reset_devices had no idea what
> (hub, port)-combination it was dealing with...

This should be in the commit message ;-)

>>
>>> This adds an additional 'hub' parameter to usb_hub_reset_devices.
>>> Existing implementations are changed to simply ignore the new
>>> parameter.
>>>
>>> Signed-off-by: Philipp Tomsich 
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - new in v2
>>>
>>> board/compulab/cm_t54/cm_t54.c | 2 +-
>>> board/ti/omap5_uevm/evm.c  | 2 +-
>>> common/usb_hub.c   | 4 ++--
>>> 3 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
>>> index 31730a4..3e6235a 100644
>>> --- a/board/compulab/cm_t54/cm_t54.c
>>> +++ b/board/compulab/cm_t54/cm_t54.c
>>> @@ -246,7 +246,7 @@ int ehci_hcd_stop(void)
>>> return ret;
>>> }
>>>
>>> -void usb_hub_reset_devices(int port)
>>> +void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>>> {
>>> /* The LAN9730 needs to be reset after the port power has been set. */
>>> if (port == 3) {
>>> diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
>>> index 4b25cc2..67242f5 100644
>>> --- a/board/ti/omap5_uevm/evm.c
>>> +++ b/board/ti/omap5_uevm/evm.c
>>> @@ -249,7 +249,7 @@ int ehci_hcd_stop(void)
>>> return omap_ehci_hcd_stop();
>>> }
>>>
>>> -void usb_hub_reset_devices(int port)
>>> +void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>>> {
>>> /* The LAN9730 needs to be reset after the port power has been set. */
>>> if (port == 3) {
>>> diff --git a/common/usb_hub.c b/common/usb_hub.c
>>> index 325d16d..024dadb 100644
>>> --- a/common/usb_hub.c
>>> +++ b/common/usb_hub.c
>>> @@ -57,7 +57,7 @@ struct usb_device_scan {
>>>
>>> static LIST_HEAD(usb_scan_list);
>>>
>>> -__weak void usb_hub_reset_devices(int port)
>>> +__weak void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>>> {
>>> return;
>>> }
>>> @@ -853,7 +853,7 @@ static int usb_hub_configure(struct usb_device *dev)
>>>  * should occur in the board file of the device.
>>>  */
>>> for (i = 0; i < dev->maxchild; i++)
>>> -   usb_hub_reset_devices(i + 1);
>>> +   usb_hub_reset_devices(hub, i + 1);
>>>
>>> /*
>>>  * Only add the connected USB devices, including potential hubs,
>>>
>>
>>
>> -- 
>> Best regards,
>> Marek Vasut
> 


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

Re: [U-Boot] [PATCH v3 1/3] usb: hub: identify the hub-device to usb_hub_reset_devices

[Marek Vasut]

On 11/22/2017 05:15 PM, Philipp Tomsich wrote:
> When usb_hub_reset_devices is called, it should be passed both an
> indicator which hub it should operate on and what port number (local
> to that hub) should be reset.
> 
> Previously, the usb_hub.c code did not include such context and
> always started resets from port number 1, performing multiple
> reset-requests for the same devices:
> 
>/*
> * Reset any devices that may be in a bad state when applying
> * the power.  This is a __weak function.  Resetting of the devices
> * should occur in the board file of the device.
> */
>for (i = 0; i < dev->maxchild; i++)
>   usb_hub_reset_devices(i + 1);
> 
> This adds an additional 'hub' parameter to usb_hub_reset_devices
> that provides the context to fully qualify the port-number in.
> 
> Existing implementations are changed to accept and ignore the new
> parameter.
> 
> Signed-off-by: Philipp Tomsich 
> Tested-by: Jakob Unterwurzacher 

Reviewed-by: Marek Vasut 

This is part of a series, what;s the plan here. Pull it via usb or some
other tree ?

> ---
> 
> Changes in v3:
> - updated commit message
> 
> Changes in v2:
> - new in v2
> 
>  board/compulab/cm_t54/cm_t54.c | 2 +-
>  board/ti/omap5_uevm/evm.c  | 2 +-
>  common/usb_hub.c   | 4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
> index 31730a4..3e6235a 100644
> --- a/board/compulab/cm_t54/cm_t54.c
> +++ b/board/compulab/cm_t54/cm_t54.c
> @@ -246,7 +246,7 @@ int ehci_hcd_stop(void)
>   return ret;
>  }
>  
> -void usb_hub_reset_devices(int port)
> +void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>  {
>   /* The LAN9730 needs to be reset after the port power has been set. */
>   if (port == 3) {
> diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
> index 4b25cc2..67242f5 100644
> --- a/board/ti/omap5_uevm/evm.c
> +++ b/board/ti/omap5_uevm/evm.c
> @@ -249,7 +249,7 @@ int ehci_hcd_stop(void)
>   return omap_ehci_hcd_stop();
>  }
>  
> -void usb_hub_reset_devices(int port)
> +void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>  {
>   /* The LAN9730 needs to be reset after the port power has been set. */
>   if (port == 3) {
> diff --git a/common/usb_hub.c b/common/usb_hub.c
> index 325d16d..024dadb 100644
> --- a/common/usb_hub.c
> +++ b/common/usb_hub.c
> @@ -57,7 +57,7 @@ struct usb_device_scan {
>  
>  static LIST_HEAD(usb_scan_list);
>  
> -__weak void usb_hub_reset_devices(int port)
> +__weak void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
>  {
>   return;
>  }
> @@ -853,7 +853,7 @@ static int usb_hub_configure(struct usb_device *dev)
>* should occur in the board file of the device.
>*/
>   for (i = 0; i < dev->maxchild; i++)
> - usb_hub_reset_devices(i + 1);
> + usb_hub_reset_devices(hub, i + 1);
>  
>   /*
>* Only add the connected USB devices, including potential hubs,
> 


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

[U-Boot] [PATCH] omap3_logic: Enable libfdt in SPL

[Adam Ford]

This commit enables libfdt in SPL and removes manual MMC and serial
driver manuipluation during SPL building.

Signed-off-by: Adam Ford 

diff --git a/board/logicpd/omap3som/omap3logic.c 
b/board/logicpd/omap3som/omap3logic.c
index 1da9e38..3d6f3f8 100644
--- a/board/logicpd/omap3som/omap3logic.c
+++ b/board/logicpd/omap3som/omap3logic.c
@@ -40,21 +40,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-/* This is only needed until SPL gets OF support */
-#ifdef CONFIG_SPL_BUILD
-static const struct ns16550_platdata omap3logic_serial = {
-   .base = OMAP34XX_UART1,
-   .reg_shift = 2,
-   .clock = V_NS16550_CLK,
-   .fcr = UART_FCR_DEFVAL,
-};
-
-U_BOOT_DEVICE(omap3logic_uart) = {
-   "ns16550_serial",
-   _serial
-};
-#endif
-
 /*
  * two dimensional array of strucures containining board name and Linux
  * machine IDs; row it selected based on CPU column is slected based
diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
index 8801268..8678271 100644
--- a/configs/omap3_logic_defconfig
+++ b/configs/omap3_logic_defconfig
@@ -55,3 +55,4 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0451
 CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
 CONFIG_USB_ETHER=y
 CONFIG_BCH=y
+CONFIG_SPL_OF_LIBFDT=y
diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h
index 3ecfb58..29a9f70 100644
--- a/include/configs/omap3_logic.h
+++ b/include/configs/omap3_logic.h
@@ -17,21 +17,6 @@
 
 #include 
 
-#ifdef CONFIG_SPL_BUILD
-/*
- * Disable MMC DM for SPL build and can be re-enabled after adding
- * DM support in SPL
- */
-#undef CONFIG_DM_MMC
-#undef OMAP_HSMMC_USE_GPIO
-
-/* select serial console configuration for SPL */
-#undef CONFIG_CONS_INDEX
-#define CONFIG_CONS_INDEX  1
-#define CONFIG_SYS_NS16550_COM1OMAP34XX_UART1
-#endif
-
-
 /*
  * We are only ever GP parts and will utilize all of the "downloaded image"
  * area in SRAM which starts at 0x4020 and ends at 0x4020 (64KB) in
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/3] common: Fix-up MAC addr in dts by fetching env variable serially

[York Sun]

On 11/22/2017 03:52 AM, Prabhakar Kushwaha wrote:
> 
>> -Original Message-
>> From: York Sun
>> Sent: Tuesday, November 21, 2017 10:52 PM
>> To: Prabhakar Kushwaha ; u-
>> b...@lists.denx.de
>> Subject: Re: [PATCH 1/3] common: Fix-up MAC addr in dts by fetching env
>> variable serially
>>
>> On 11/21/2017 08:26 AM, Prabhakar Kushwaha wrote:
>>> Current implementation of MAC address fix-up of device tree uses
>>> tailing number behind "ethernet" found in "/aliases".  It is not
>>> necessary for trailing number of “ethernet” to be sequential. There
>>> can be hole in between or any node disabled.
>>>
>>> So provide support device tree fix-up of “ethernent” node with MAC
>>> addresses fetched sequentially from environment variables.
>>
>> My understanding is current implementation matches the trailing number
>> behind "ethernet" found in "/aliases" with environmental variables
>> ethNaddr (where N is 1, 2, 3, ... or absent). This doesn't require
>> "ethernet" nodes or ethNaddr variables to be consecutive.
>>
>> From your change, I understand you are trying to apply consecutive
>> ethNaddr variables to "ethernet" nodes in the order they appear in
>> device tree.
>>
>> You didn't explain what benefit you get from this new scheme, or what
>> problem you are trying to solve.
>>
>> My understanding is you have device tree with some "ethernet" nodes
>> disabled (or with gap in the numbering). You also have a pool of MAC
>> addresses in the form of consecutive ethNaddr variables. You goal is to
>> assign these ethNaddr to "ethernet" nodes in the order they appear in
>> the device tree. Do I understand you correctly?
> 
> Yes this understanding is correct. 
> I am parsing "ethernet" node from device tree and fixing up ethNaddr 
> sequentially.
> 
> 
>>
>> Is it possible to address this issue from another angle? How about
>> setting ethNaddr variables in U-Boot according to the SerDes protocol?
>> You may have explored this path already. Let me know why this doesn't work.
> 
> Yes, analyzed this path and figured out following 2 changes in u-boot
> 
> A) I2C EEPROM:  Here MAC number has to be read sequentially from EEPROM and 
> they have to save as ethNaddr. here N is MAC number as per SerDes
>   MAC number will be saved in ethaddr, eth1addr, eth2addr, eth3addr,  
> eth10addr depending upon SerDes protocol
>   
> B) net/eth_legacy.c: eth_initialize()  --> eth_write_hwaddr
> here each Ethernet driver read ethNaddr.  Here N represents eth_device-> 
> index.
> Please note eth_device->index in under control of Ethernet subsystem and  
> incremented automatically per Ethernet device.
> 
> for a Ethernet device which require eth9addr (updated as part of A). It must 
> have 10 ethernet device before it to get correct eth9addr. 
> Hence a mapping required from eth_device->index to MAC number.  I wanted to 
> avoid "B" to make sure Ethernet device initialization path remain unchanged. 
> 
> Hence chosen to update fdt_support.c  
> 

Thanks for the explanation. I will leave the decision to Simon Glass.
In the meantime, maybe you can rephrase the commit message to make it
more clear.

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

Re: [U-Boot] [PATCH v2] boston: Add u-boot.mcs make target

[Daniel Schwierzeck]

On 21.11.2017 23:31, Paul Burton wrote:
> U-Boot is generally flashed to a MIPS Boston development board by means
> of a .mcs file which Xilinx Vivado software can write to the flash
> present on the board. As such we'd generally want to produce an mcs file
> when building U-Boot to target the Boston board. Introduce a make target
> for u-boot.mcs which generates it using the srec_cat tool available from
> the SRecord project, and build it by default when srec_cat is present.
> 
> Signed-off-by: Paul Burton 
> Cc: Daniel Schwierzeck 
> Cc: u-boot@lists.denx.de
> 
> ---
> 
> Changes in v2:
> - Use try-run as suggested by Daniel.
> 
>  board/imgtec/boston/config.mk | 14 ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 board/imgtec/boston/config.mk
> 

applied to u-boot-mips, thanks.

-- 
- Daniel



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

[U-Boot] [PATCH] rockchip: pinctrl: rk3399: add support for I2C8

[Philipp Tomsich]

The RK3399 has a total of 9 I2C controllers.  To support these, the
enum in periph.h is extended and the mapping from the IRQ numbers to
the peripheral-ids is extended to ensure that pinctrl requests are
passed through to the function configuring the I2C pins.

For I2C8, the pinctrl is implemented and tested (on a RK3399-Q7) using
communication with the FAN53555 connected on I2C8.

Signed-off-by: Philipp Tomsich 
Tested-by: Klaus Goger 
---

 arch/arm/include/asm/arch-rockchip/grf_rk3399.h |  7 ++-
 arch/arm/include/asm/arch-rockchip/periph.h |  3 +++
 drivers/pinctrl/rockchip/pinctrl_rk3399.c   | 19 +++
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
index 8d21eb7..b541e2c 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
@@ -589,7 +589,12 @@ enum {
PMUGRF_GPIO1C3_SEL_SHIFT= 6,
PMUGRF_GPIO1C3_SEL_MASK = 3 << PMUGRF_GPIO1C3_SEL_SHIFT,
PMUGRF_PWM_2= 1,
-
+   PMUGRF_GPIO1C4_SEL_SHIFT = 8,
+   PMUGRF_GPIO1C4_SEL_MASK = 3 << PMUGRF_GPIO1C4_SEL_SHIFT,
+   PMUGRF_I2C8PMU_SDA = 1,
+   PMUGRF_GPIO1C5_SEL_SHIFT = 10,
+   PMUGRF_GPIO1C5_SEL_MASK = 3 << PMUGRF_GPIO1C5_SEL_SHIFT,
+   PMUGRF_I2C8PMU_SCL = 1,
 };
 
 /* GRF_SOC_CON5 */
diff --git a/arch/arm/include/asm/arch-rockchip/periph.h 
b/arch/arm/include/asm/arch-rockchip/periph.h
index 9f4bc2e..77cf5b9 100644
--- a/arch/arm/include/asm/arch-rockchip/periph.h
+++ b/arch/arm/include/asm/arch-rockchip/periph.h
@@ -24,6 +24,9 @@ enum periph_id {
PERIPH_ID_I2C3,
PERIPH_ID_I2C4,
PERIPH_ID_I2C5,
+   PERIPH_ID_I2C6,
+   PERIPH_ID_I2C7,
+   PERIPH_ID_I2C8,
PERIPH_ID_SPI0,
PERIPH_ID_SPI1,
PERIPH_ID_SPI2,
diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3399.c 
b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
index cab268c..19a7415 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3399.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
@@ -70,11 +70,21 @@ static void pinctrl_rk3399_i2c_config(struct 
rk3399_grf_regs *grf,
 PMUGRF_GPIO1C0_SEL_MASK,
 PMUGRF_I2C0PMU_SCL << PMUGRF_GPIO1C0_SEL_SHIFT);
break;
+   case PERIPH_ID_I2C8:
+   rk_clrsetreg(>gpio1c_iomux,
+PMUGRF_GPIO1C4_SEL_MASK,
+PMUGRF_I2C8PMU_SDA << PMUGRF_GPIO1C4_SEL_SHIFT);
+   rk_clrsetreg(>gpio1c_iomux,
+PMUGRF_GPIO1C5_SEL_MASK,
+PMUGRF_I2C8PMU_SCL << PMUGRF_GPIO1C5_SEL_SHIFT);
+   break;
case PERIPH_ID_I2C1:
case PERIPH_ID_I2C2:
case PERIPH_ID_I2C3:
case PERIPH_ID_I2C4:
case PERIPH_ID_I2C5:
+   case PERIPH_ID_I2C6:
+   case PERIPH_ID_I2C7:
default:
debug("i2c id = %d iomux error!\n", i2c_id);
break;
@@ -301,6 +311,9 @@ static int rk3399_pinctrl_request(struct udevice *dev, int 
func, int flags)
case PERIPH_ID_I2C3:
case PERIPH_ID_I2C4:
case PERIPH_ID_I2C5:
+   case PERIPH_ID_I2C6:
+   case PERIPH_ID_I2C7:
+   case PERIPH_ID_I2C8:
pinctrl_rk3399_i2c_config(priv->grf, priv->pmugrf, func);
break;
case PERIPH_ID_SPI0:
@@ -375,6 +388,12 @@ static int rk3399_pinctrl_get_periph_id(struct udevice 
*dev,
return PERIPH_ID_I2C4;
case 38:
return PERIPH_ID_I2C5;
+   case 37:
+   return PERIPH_ID_I2C6;
+   case 36:
+   return PERIPH_ID_I2C7;
+   case 58:
+   return PERIPH_ID_I2C8;
case 65:
return PERIPH_ID_SDMMC1;
 #if CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
-- 
2.1.4

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

[U-Boot] mx6ull evk reboots automatically

[Fabio Estevam]

Hi Peng,

Booting a mainline U-Boot on a imx6ull evk with a mainline kernel
causes the board to reboot after
about 5 seconds from reaching the Linux prompt.

If I use the NXP U-Boot version this problem does not happen.

Do you have any suggestion to fix this problem?

Thanks,

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

Re: [U-Boot] [PATCH 0/3] ls1012a: fix tftp failure

[York Sun]

On 11/21/2017 10:26 PM, Calvin Johnson wrote:
> This patch series fixes bug which fails tftp sometimes
> while using the pfe interfaces and also has some code clean up.
> 
> 
> Calvin Johnson (3):
>   drivers: net: pfe_eth: add pfe_rx_done to clear bd after packet
> processing
>   drivers: net: pfe_eth: use writel/readl to access hw bds
>   drivers: net: pfe_eth: cleanup typos and indent
> 
>  drivers/net/pfe_eth/pfe_driver.c | 126 
> +++
>  drivers/net/pfe_eth/pfe_eth.c|  13 ++--
>  include/pfe_eth/pfe_driver.h |   1 +
>  3 files changed, 82 insertions(+), 58 deletions(-)
> 

Your PFE patch set is not fully reviewed or accepted. If I were you, I
would probably send v2 version to include all the changes.

It is up to Joe to decide to take a new version, or patches on top of
patches.

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

[U-Boot] [PATCH] rockchip: clk: rk3399: change extract_bits to bitfield_extract

[Philipp Tomsich]

The RK3399 clk driver still has a left-over use of extract_bits, which
can be replaced by using bitfield_extract from include/bitfield.h.
This rewrites the invocation to use the shared function.

Signed-off-by: Philipp Tomsich 
---

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

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 6f85a38..b54cdb8 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -569,11 +569,6 @@ static const struct spi_clkreg spi_clkregs[] = {
.sel_shift = CLK_SPI5_PLL_SEL_SHIFT, },
 };
 
-static inline u32 extract_bits(u32 val, unsigned width, unsigned shift)
-{
-   return (val >> shift) & ((1 << width) - 1);
-}
-
 static ulong rk3399_spi_get_clk(struct rk3399_cru *cru, ulong clk_id)
 {
const struct spi_clkreg *spiclk = NULL;
@@ -590,7 +585,8 @@ static ulong rk3399_spi_get_clk(struct rk3399_cru *cru, 
ulong clk_id)
}
 
val = readl(>clksel_con[spiclk->reg]);
-   div = extract_bits(val, CLK_SPI_PLL_DIV_CON_WIDTH, spiclk->div_shift);
+   div = bitfield_extract(val, spiclk->div_shift,
+  CLK_SPI_PLL_DIV_CON_WIDTH);
 
return DIV_TO_RATE(GPLL_HZ, div);
 }
-- 
2.1.4

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

[U-Boot] [PATCH v2 1/2] power: regulator: add driver for the FAN53555 family

[Philipp Tomsich]

This adds a driver for the FAN53555 family of regulators.

While these devices support a 'normal' and 'suspend' mode (controlled
via an external pin) to switch between two programmable voltages, this
incarnation of the driver assumes that the device is always operating
in 'normal' mode.

Only setting/reading the programmed voltage is supported at this time
and the following device functionality remains unsupported:
  - switching the selected voltage (via a GPIO)
  - disabling the voltage output via software-control
This matches the functionality of the Linux driver.

Tested on a RK3399-Q7 (with 'option 5' devices): setting voltages from
the U-Boot shell and verifying output voltages on the board.

Signed-off-by: Philipp Tomsich 
Tested-by: Klaus Goger 

---

Changes in v2:
- adapted documentation on the device-tree binding from Linux

 doc/device-tree-bindings/regulator/fan53555.txt |  23 +++
 drivers/power/regulator/Kconfig |  14 ++
 drivers/power/regulator/Makefile|   1 +
 drivers/power/regulator/fan53555.c  | 255 
 4 files changed, 293 insertions(+)
 create mode 100644 doc/device-tree-bindings/regulator/fan53555.txt
 create mode 100644 drivers/power/regulator/fan53555.c

diff --git a/doc/device-tree-bindings/regulator/fan53555.txt 
b/doc/device-tree-bindings/regulator/fan53555.txt
new file mode 100644
index 000..b183738
--- /dev/null
+++ b/doc/device-tree-bindings/regulator/fan53555.txt
@@ -0,0 +1,23 @@
+Binding for Fairchild FAN53555 regulators
+
+Required properties:
+  - compatible: "fcs,fan53555"
+  - reg: I2C address
+
+Optional properties:
+  - fcs,suspend-voltage-selector: declare which of the two available
+   voltage selector registers should be used for the suspend
+   voltage. The other one is used for the runtime voltage setting
+   Possible values are either <0> or <1>
+  - vin-supply: regulator supplying the vin pin
+
+Example:
+
+   regulator@40 {
+   compatible = "fcs,fan53555";
+   regulator-name = "fan53555";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_reg>;
+   fcs,suspend-voltage-selector = <1>;
+   };
diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 8892fa1..c26a765 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -69,6 +69,20 @@ config DM_REGULATOR_MAX77686
features for REGULATOR MAX77686. The driver implements get/set api for:
value, enable and mode.
 
+config DM_REGULATOR_FAN53555
+   bool "Enable Driver Model for REGULATOR FAN53555"
+   depends on DM_REGULATOR && DM_I2C
+   ---help---
+   This config enables implementation of driver-model regulator uclass
+   features for the FAN53555 regulator. The FAN53555 is a (family of)
+   single-output regulators that supports transitioning between two
+   different output voltages based on an voltage selection pin.
+
+   The driver implements a get/set api for the voltage of the 'normal
+   mode' voltage only. Switching to 'suspend mode' (i.e. the alternate
+   voltage), disabling output via software, or switching the mode is
+   not supported by this driver (at this time).
+
 config DM_REGULATOR_FIXED
bool "Enable Driver Model for REGULATOR Fixed value"
depends on DM_REGULATOR
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 6c149a9..21040ea 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_REGULATOR_AS3722)+= as3722_regulator.o
 obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
 obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
 obj-$(CONFIG_REGULATOR_PWM) += pwm_regulator.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_FAN53555) += fan53555.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
 obj-$(CONFIG_REGULATOR_RK8XX) += rk8xx.o
diff --git a/drivers/power/regulator/fan53555.c 
b/drivers/power/regulator/fan53555.c
new file mode 100644
index 000..3f0b4e9
--- /dev/null
+++ b/drivers/power/regulator/fan53555.c
@@ -0,0 +1,255 @@
+/*
+ * (C) 2017 Theobroma Systems Design und Consulting GmbH
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * The voltage ramp (i.e. minimum voltage and step) is defined by the
+ * combination of 2 nibbles: DIE_ID and DIE_REV.
+ *
+ * See http://www.onsemi.com/pub/Collateral/FAN53555-D.pdf for details.
+ */
+static const struct {
+   u8 die_id;
+   u8 die_rev;
+   u32 vsel_min;
+   u32 vsel_step;
+} ic_types[] = {
+   { 0x0, 0x3, 

[U-Boot] [PATCH v2 2/2] rockchip: defconfig: puma-rk3399: enable FAN53555 regulator driver

[Philipp Tomsich]

With a driver for the FAN53555 regulator family available, let's
enable it for the RK3399-Q7 (which has two of these devices
on-module).

We enable this for the full U-Boot stage only, as these regulators
provide a suitable default voltage and supply non-critical (i.e.
for booting up) power rails only.

Signed-off-by: Philipp Tomsich 
---

Changes in v2: None

 configs/puma-rk3399_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index ebbf8a9..233c15a 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -67,6 +67,7 @@ CONFIG_PINCTRL_ROCKCHIP_RK3399=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_SPL_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FAN53555=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_SPL_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
-- 
2.1.4

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

[U-Boot] [PATCH v3 1/3] usb: hub: identify the hub-device to usb_hub_reset_devices

[Philipp Tomsich]

When usb_hub_reset_devices is called, it should be passed both an
indicator which hub it should operate on and what port number (local
to that hub) should be reset.

Previously, the usb_hub.c code did not include such context and
always started resets from port number 1, performing multiple
reset-requests for the same devices:

   /*
* Reset any devices that may be in a bad state when applying
* the power.  This is a __weak function.  Resetting of the devices
* should occur in the board file of the device.
*/
   for (i = 0; i < dev->maxchild; i++)
  usb_hub_reset_devices(i + 1);

This adds an additional 'hub' parameter to usb_hub_reset_devices
that provides the context to fully qualify the port-number in.

Existing implementations are changed to accept and ignore the new
parameter.

Signed-off-by: Philipp Tomsich 
Tested-by: Jakob Unterwurzacher 

---

Changes in v3:
- updated commit message

Changes in v2:
- new in v2

 board/compulab/cm_t54/cm_t54.c | 2 +-
 board/ti/omap5_uevm/evm.c  | 2 +-
 common/usb_hub.c   | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
index 31730a4..3e6235a 100644
--- a/board/compulab/cm_t54/cm_t54.c
+++ b/board/compulab/cm_t54/cm_t54.c
@@ -246,7 +246,7 @@ int ehci_hcd_stop(void)
return ret;
 }
 
-void usb_hub_reset_devices(int port)
+void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
 {
/* The LAN9730 needs to be reset after the port power has been set. */
if (port == 3) {
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 4b25cc2..67242f5 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -249,7 +249,7 @@ int ehci_hcd_stop(void)
return omap_ehci_hcd_stop();
 }
 
-void usb_hub_reset_devices(int port)
+void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
 {
/* The LAN9730 needs to be reset after the port power has been set. */
if (port == 3) {
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 325d16d..024dadb 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -57,7 +57,7 @@ struct usb_device_scan {
 
 static LIST_HEAD(usb_scan_list);
 
-__weak void usb_hub_reset_devices(int port)
+__weak void usb_hub_reset_devices(struct usb_hub_device *hub, int port)
 {
return;
 }
@@ -853,7 +853,7 @@ static int usb_hub_configure(struct usb_device *dev)
 * should occur in the board file of the device.
 */
for (i = 0; i < dev->maxchild; i++)
-   usb_hub_reset_devices(i + 1);
+   usb_hub_reset_devices(hub, i + 1);
 
/*
 * Only add the connected USB devices, including potential hubs,
-- 
2.1.4

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

[U-Boot] [PATCH 2/2] rockchip: defconfig: puma-rk3399: enable FAN53555 regulator driver

[Philipp Tomsich]

With a driver for the FAN53555 regulator family available, let's
enable it for the RK3399-Q7 (which has two of these devices
on-module).

We enable this for the full U-Boot stage only, as these regulators
provide a suitable default voltage and supply non-critical (i.e.
for booting up) power rails only.

Signed-off-by: Philipp Tomsich 
---

 configs/puma-rk3399_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index ebbf8a9..233c15a 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -67,6 +67,7 @@ CONFIG_PINCTRL_ROCKCHIP_RK3399=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_SPL_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FAN53555=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_SPL_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
-- 
2.1.4

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

[U-Boot] [PATCH 1/2] power: regulator: add driver for the FAN53555 family

[Philipp Tomsich]

This adds a driver for the FAN53555 family of regulators.

While these devices support a 'normal' and 'suspend' mode (controlled
via an external pin) to switch between two programmable voltages, this
incarnation of the driver assumes that the device is always operating
in 'normal' mode.

Only setting/reading the programmed voltage is supported at this time
and the following device functionality remains unsupported:
  - switching the selected voltage (via a GPIO)
  - disabling the voltage output via software-control
This matches the functionality of the Linux driver.

Tested on a RK3399-Q7 (with 'option 5' devices): setting voltages from
the U-Boot shell and verifying output voltages on the board.

Signed-off-by: Philipp Tomsich 
Tested-by: Klaus Goger 
---

 drivers/power/regulator/Kconfig|  14 ++
 drivers/power/regulator/Makefile   |   1 +
 drivers/power/regulator/fan53555.c | 255 +
 3 files changed, 270 insertions(+)
 create mode 100644 drivers/power/regulator/fan53555.c

diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 8892fa1..c26a765 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -69,6 +69,20 @@ config DM_REGULATOR_MAX77686
features for REGULATOR MAX77686. The driver implements get/set api for:
value, enable and mode.
 
+config DM_REGULATOR_FAN53555
+   bool "Enable Driver Model for REGULATOR FAN53555"
+   depends on DM_REGULATOR && DM_I2C
+   ---help---
+   This config enables implementation of driver-model regulator uclass
+   features for the FAN53555 regulator. The FAN53555 is a (family of)
+   single-output regulators that supports transitioning between two
+   different output voltages based on an voltage selection pin.
+
+   The driver implements a get/set api for the voltage of the 'normal
+   mode' voltage only. Switching to 'suspend mode' (i.e. the alternate
+   voltage), disabling output via software, or switching the mode is
+   not supported by this driver (at this time).
+
 config DM_REGULATOR_FIXED
bool "Enable Driver Model for REGULATOR Fixed value"
depends on DM_REGULATOR
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 6c149a9..21040ea 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_REGULATOR_AS3722)+= as3722_regulator.o
 obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
 obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
 obj-$(CONFIG_REGULATOR_PWM) += pwm_regulator.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_FAN53555) += fan53555.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
 obj-$(CONFIG_REGULATOR_RK8XX) += rk8xx.o
diff --git a/drivers/power/regulator/fan53555.c 
b/drivers/power/regulator/fan53555.c
new file mode 100644
index 000..3f0b4e9
--- /dev/null
+++ b/drivers/power/regulator/fan53555.c
@@ -0,0 +1,255 @@
+/*
+ * (C) 2017 Theobroma Systems Design und Consulting GmbH
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * The voltage ramp (i.e. minimum voltage and step) is defined by the
+ * combination of 2 nibbles: DIE_ID and DIE_REV.
+ *
+ * See http://www.onsemi.com/pub/Collateral/FAN53555-D.pdf for details.
+ */
+static const struct {
+   u8 die_id;
+   u8 die_rev;
+   u32 vsel_min;
+   u32 vsel_step;
+} ic_types[] = {
+   { 0x0, 0x3, 60, 1 },  /* Option 00 */
+   { 0x0, 0xf, 80, 1 },  /* Option 13 */
+   { 0x0, 0xc, 60, 12500 },  /* Option 23 */
+   { 0x1, 0x3, 60, 1 },  /* Option 01 */
+   { 0x3, 0x3, 60, 1 },  /* Option 03 */
+   { 0x4, 0xf, 603000, 12826 },  /* Option 04 */
+   { 0x5, 0x3, 60, 1 },  /* Option 05 */
+   { 0x8, 0x1, 60, 1 },  /* Option 08 */
+   { 0x8, 0xf, 60, 1 },  /* Option 08 */
+   { 0xc, 0xf, 603000, 12826 },  /* Option 09 */
+};
+
+/* I2C-accessible byte-sized registers */
+enum {
+   /* Voltage setting */
+   FAN53555_VSEL0 = 0x00,
+   FAN53555_VSEL1,
+   /* Control register */
+   FAN53555_CONTROL,
+   /* IC Type */
+   FAN53555_ID1,
+   /* IC mask version */
+   FAN53555_ID2,
+   /* Monitor register */
+   FAN53555_MONITOR,
+};
+
+struct fan53555_platdata {
+   /* Voltage setting register */
+   unsigned int vol_reg;
+   unsigned int sleep_reg;
+
+};
+
+struct fan53555_priv {
+   /* IC Vendor */
+   unsigned int vendor;
+   /* IC Type and Rev */
+   unsigned int die_id;
+   unsigned int die_rev;
+   /* Voltage range and step(linear) */
+   unsigned int vsel_min;
+   unsigned 

Re: [U-Boot] [U-Boot,4/8] rockchip: rk3128: add pinctrl driver

[Philipp Tomsich]

> Add rk3128 pinctrl driver and grf/iomux structure definition.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
>  arch/arm/include/asm/arch-rockchip/grf_rk3128.h | 551 
> 
>  drivers/pinctrl/Kconfig |  10 +
>  drivers/pinctrl/rockchip/Makefile   |   4 +-
>  drivers/pinctrl/rockchip/pinctrl_rk3128.c   | 192 +
>  4 files changed, 755 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3128.h
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3128.c
> 

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

Re: [U-Boot] [U-Boot, 7/8] rockchip: rk3128: add defconfig for evb-rk3128

[Philipp Tomsich]

> Enable board config for evb-rk3128.
> Serial output and eMMC works in this version.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
>  configs/evb-rk3128_defconfig | 42 ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 configs/evb-rk3128_defconfig
> 

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