[U-Boot] [PATCH] mkimage: fix missing break for -p switch

[Teddy Reed]

Signed-off-by: Teddy Reed 
---
 tools/mkimage.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index ff3024a..0e501f8 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -225,6 +225,7 @@ static void process_args(int argc, char **argv)
params.cmdname, optarg);
exit(EXIT_FAILURE);
}
+   break;
case 'q':
params.quiet = 1;
break;
-- 
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] rockchip: add option to change method of loading u-boot

[Ziyuan Xu]

hi Andreas,

Thanks for your catch. I will revise the typos.

On 2016年07月12日 12:30, Andreas Färber wrote:

Am 12.07.2016 um 05:18 schrieb Ziyuan Xu:

From: Xu Ziyuan 

If we would like to boot from SD card, we have to implement mmc driver
in SPL stage, and get a slightly large SPL binrary. Rockchip SoC's

"binary"


bootrom code has the ability to load spl and u-boot, then boot.

If CONFIG_ROCKCHIP_SPL_BACK_TO_BROM is enabled, the spl will return to
tbootrom in board_init_f(), then bootrom load u-boot binrary.

"the bootrom", "the bootrom loads", "binary"


This patch does that.

Redundant?


Loading sequence after rework:
bootrom ==> spl ==> bootrom ==> u-boot

Signed-off-by: Ziyuan Xu 
Acked-by: Simon Glass 

Regards,
Andreas




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

Re: [U-Boot] [PATCH v3] driver: spi: fsl-qspi: disable AHB buffer prefetch

[Prabhakar Kushwaha]

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Yunhui Cui
> Sent: Tuesday, July 12, 2016 8:20 AM
> To: york sun 
> Cc: Yunhui Cui ; u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH v3] driver: spi: fsl-qspi: disable AHB buffer 
> prefetch
> 
> From: Yunhui Cui 
> 
> Errata: A-009282: QuadSPI data pre-fetch can result in incorrect data
> We need this errata workaround when CONFIG_SYS_FSL_QSPI_AHB is enabled.
> 

Can we add slightly more details about workaround other than Just enabling 
CONFIG_SYS_FSL_QSPI_AHB.
With this you can avoid details of workaround in code. 

Please add CONFIG_SYS_FSL_QSPI_AHB in README file

> Signed-off-by: Yunhui Cui 
> ---

Patch revision history missing.

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

Re: [U-Boot] [PATCH] i2c: intel_i2c: SMBus driver PCI addition (e.g. BayTrail)

[Bin Meng]

Hi Simon,

On Tue, Jun 28, 2016 at 9:44 PM, Stefan Roese  wrote:
> This patch adds support for the SMBus block read/write functionality.
> Other protocols like the SMBus quick command need to get added
> if this is needed.
>
> This patch also removed the SMBus related defines from the Ivybridge
> pch.h header. As they are integrated in this driver and should be
> used from here. This change is added in this patch to avoid compile
> breakage to keep the source git bisectable.
>
> Tested on a congatec BayTrail board to configure the SMSC2513 USB
> hub.
>
> Signed-off-by: Stefan Roese 
> Cc: Bin Meng 
> Cc: Simon Glass 
> Cc: Heiko Schocher 
> ---
> Simon, I'm not sure if this change breaks your Ivybridge targets
> using the probe part of this driver. Could you please let me
> know if this works? Or let me know what needs changes here?
>

Can you test this patch on Ivybridge to see if it breaks anything? Is
SMBus used on Ivybridge for the memory initialization (eg: reading
SPD?)

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] x86: conga-qeval20-qa3: Add SMBus support and SMSC2513 config code

[Bin Meng]

On Tue, Jun 28, 2016 at 9:45 PM, Stefan Roese  wrote:
> This patch includes the following changes:
>
> - Remove Designware I2C support from dts as its not used
> - Configure SMBus PADs in dts
> - Enable I2C commands and I2C support
> - Configure SMSC2513 USB hub via SMBus upon startup
> - Move environment location to match Minnowmax example
> - Enhancement of the default environment
>
> Signed-off-by: Stefan Roese 
> Cc: Bin Meng 
> Cc: Simon Glass 
> ---
>  arch/x86/dts/conga-qeval20-qa3-e3845.dts   | 18 ++
>  .../conga-qeval20-qa3-e3845/conga-qeval20-qa3.c| 40 
> ++
>  ...conga-qeval20-qa3-e3845-internal-uart_defconfig |  3 ++
>  configs/conga-qeval20-qa3-e3845_defconfig  |  3 ++
>  include/configs/conga-qeval20-qa3-e3845.h  | 12 ---
>  5 files changed, 64 insertions(+), 12 deletions(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] x86: link: Correct a failure in DRAM init

[Bin Meng]

On Mon, Jul 11, 2016 at 11:30 PM, Simon Glass  wrote:
> With the change to set up pinctrl after relocation, link fails to boot. Add
> a special case in the link code to handle this.
>
> Fixes: d8906c1f (x86: Probe pinctrl driver in cpu_init_r())
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/ivybridge/sdram.c | 5 +
>  1 file changed, 5 insertions(+)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 09/13] libfdt: Add fdt_getprop_namelen_w

[David Gibson]

On Mon, Jul 11, 2016 at 09:12:27AM +0200, Maxime Ripard wrote:
> On Wed, Jul 06, 2016 at 11:22:48AM +1000, David Gibson wrote:
> > On Tue, Jul 05, 2016 at 10:26:42AM +0200, Maxime Ripard wrote:
> > > Add a function to retrieve a writeable property only by the first
> > > characters of its name.
> > > 
> > > Signed-off-by: Maxime Ripard 
> > 
> > This shouldn't be exported, so it should go into libfdt_internal.h.
> > 
> > > ---
> > >  include/libfdt.h | 7 +++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/include/libfdt.h b/include/libfdt.h
> > > index f13b01f08f71..a55d2d0d8c7b 100644
> > > --- a/include/libfdt.h
> > > +++ b/include/libfdt.h
> > > @@ -619,6 +619,13 @@ const void *fdt_getprop_by_offset(const void *fdt, 
> > > int offset,
> > >   */
> > >  const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
> > >   const char *name, int namelen, int *lenp);
> > > +static inline void *fdt_getprop_namelen_w(void *fdt, int nodeoffset,
> > > +   const char *name, int namelen,
> > > +   int *lenp)
> > > +{
> > > + return (void *)(uintptr_t)fdt_getprop_namelen(fdt, nodeoffset, name,
> > > +   namelen, lenp);
> > 
> > uintptr_t ??
> 
> This is defined in the exact same way than fdt_getprop_w. Should I
> change that as well?

Good point.  I wonder why I did that in the first place.  I suspect it
was to stop sparse whinging about the removed const.  It's ok for now,
we can clean both up later if we get a better idea.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


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

Re: [U-Boot] [PATCH v4] rockchip: add option to change method of loading u-boot

[Andreas Färber]

Am 12.07.2016 um 05:18 schrieb Ziyuan Xu:
> From: Xu Ziyuan 
> 
> If we would like to boot from SD card, we have to implement mmc driver
> in SPL stage, and get a slightly large SPL binrary. Rockchip SoC's

"binary"

> bootrom code has the ability to load spl and u-boot, then boot.
> 
> If CONFIG_ROCKCHIP_SPL_BACK_TO_BROM is enabled, the spl will return to
> tbootrom in board_init_f(), then bootrom load u-boot binrary.

"the bootrom", "the bootrom loads", "binary"

> 
> This patch does that.

Redundant?

> 
> Loading sequence after rework:
> bootrom ==> spl ==> bootrom ==> u-boot
> 
> Signed-off-by: Ziyuan Xu 
> Acked-by: Simon Glass 

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] driver: spi: fsl-qspi: remove compile Warnings

[Yunhui Cui]

From: Yunhui Cui 

Warnins log:
drivers/spi/fsl_qspi.c: In function ‘qspi_ahb_read’:
drivers/spi/fsl_qspi.c:400:16: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
  memcpy(rxbuf, (u8 *)(priv->cur_amba_base + priv->sf_addr), len);

Signed-off-by: Yunhui Cui 
---
 drivers/spi/fsl_qspi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 75cbab2..6c69be4 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -386,6 +386,7 @@ static inline void qspi_ahb_read(struct fsl_qspi_priv 
*priv, u8 *rxbuf, int len)
 {
struct fsl_qspi_regs *regs = priv->regs;
u32 mcr_reg;
+   void *rx_addr = NULL;
 
mcr_reg = qspi_read32(priv->flags, >mcr);
 
@@ -393,8 +394,9 @@ static inline void qspi_ahb_read(struct fsl_qspi_priv 
*priv, u8 *rxbuf, int len)
 QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK |
 QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE);
 
+   rx_addr += priv->cur_amba_base + priv->sf_addr;
/* Read out the data directly from the AHB buffer. */
-   memcpy(rxbuf, (u8 *)(priv->cur_amba_base + priv->sf_addr), len);
+   memcpy(rxbuf, rx_addr, len);
 
qspi_write32(priv->flags, >mcr, mcr_reg);
 }
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH 6/6] efi_loader: Display which .dtb we found

[Andreas Färber]

We do so for the EFI binary already and it aids debugging.

Cc: Alexander Graf 
Signed-off-by: Andreas Färber 
---
 include/config_distro_bootcmd.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 8f14457..0cf74e2 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -149,6 +149,10 @@
"${prefix}${dtb_prefix}"  \
"${dtb_vendor_prefix}"\
"${efi_fdtfile}; then "   \
+   "echo Found ${prefix}"\
+   "${dtb_prefix}"   \
+   "${dtb_vendor_prefix}"\
+   "${efi_fdtfile}; "\
"run load_efi_dtb; "  \
"fi; "\
"done; "  \
-- 
2.6.6

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

[U-Boot] [PATCH 4/6] efi_loader: Improve .dtb search for arm64

[Andreas Färber]

On arm64 Linux device trees are organized by SoC vendor. Therefore we
need to search the vendor subdirectory as well.

Since the SoC vendor may be different from ${vendor}, introduce a new
${soc_vendor}. If this is not set, the behavior remains unchanged.

Cc: Alexander Graf 
Signed-off-by: Andreas Färber 
---
 include/config_distro_bootcmd.h | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index eadec2e..8f14457 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -113,6 +113,15 @@
 #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
 #endif
 
+#if defined(CONFIG_ARM64)
+#define BOOTENV_EFI_SET_FDTFILE_VENDOR\
+   "if test -n \"${soc_vendor}\"; then " \
+   "setenv efi_dtb_vendor_prefix ${soc_vendor}/; "   \
+   "fi; "
+#else
+#define BOOTENV_EFI_SET_FDTFILE_VENDOR
+#endif
+
 #define BOOTENV_SHARED_EFI\
"boot_efi_binary="\
"load ${devtype} ${devnum}:${distro_bootpart} "   \
@@ -125,18 +134,25 @@
\
"load_efi_dtb="   \
"load ${devtype} ${devnum}:${efi_bootpart} ${fdt_addr_r} "\
-   "${prefix}${dtb_prefix}${efi_fdtfile}\0"  \
+   "${prefix}${dtb_prefix}${dtb_vendor_prefix}"  \
+   "${efi_fdtfile}\0"\
\
"efi_dtb_prefixes=\"\" dtb/ dtb/current/\0"   \
"scan_dev_for_efi_fdt="   \
"for prefix in ${boot_prefixes}; do " \
"for dtb_prefix in ${efi_dtb_prefixes}; do "  \
+   BOOTENV_EFI_SET_FDTFILE_VENDOR\
+   "for dtb_vendor_prefix in \"\" "  \
+   "${efi_dtb_vendor_prefix}; do "   \
"if test -e ${devtype} "  \
"${devnum}:${efi_bootpart} "  \
"${prefix}${dtb_prefix}"  \
+   "${dtb_vendor_prefix}"\
"${efi_fdtfile}; then "   \
"run load_efi_dtb; "  \
"fi; "\
+   "done; "  \
+   "setenv efi_dtb_vendor_prefix; "  \
"done; "  \
"done\0"  \
"scan_dev_for_efi="   \
-- 
2.6.6

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

[U-Boot] [PATCH 0/6] efi_loader: Improvements to .dtb handling

[Andreas Färber]

Hi,

This series modifies the distro boot scripts to better cope with real-world
.dtb scenarios. In particular openSUSE images have the EFI GRUB2 and optional
.dtb files on separate partitions (fat vs. ext4) and installed to /boot/dtb-foo
symlink, which may be /dtb or /boot/dtb for U-Boot. The goal is to obsolete
less sophisticated openSUSE patches and to improve the testing experience.

Further, while testing on the DragonBoard 410c, I ran into U-Boot vs. Linux
naming inconsistencies once again and suggest a workaround: ${soc_vendor}.

For easier review a cleanup patch is prepended.

Regards,
Andreas

Cc: Alexander Graf 
Cc: Tom Rini 
Cc: Stephen Warren 

Andreas Färber (6):
  efi_loader: Cosmetic distro script cleanups
  efi_loader: Respect $boot_prefixes for EFI .dtb search
  efi_loader: Search .dtb on non-EFI partitions
  efi_loader: Improve .dtb search for arm64
  dragonboard410c: Set soc_vendor
  efi_loader: Display which .dtb we found

 include/config_distro_bootcmd.h   | 59 ++-
 include/configs/dragonboard410c.h |  1 +
 2 files changed, 47 insertions(+), 13 deletions(-)

-- 
2.6.6

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

[U-Boot] [PATCH 5/6] dragonboard410c: Set soc_vendor

[Andreas Färber]

Signed-off-by: Andreas Färber 
---
 include/configs/dragonboard410c.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/dragonboard410c.h 
b/include/configs/dragonboard410c.h
index 74a827d..8b019e9 100644
--- a/include/configs/dragonboard410c.h
+++ b/include/configs/dragonboard410c.h
@@ -124,6 +124,7 @@ REFLASH(dragonboard/u-boot.img, 8)\
"linux_image=Image\0" \
"kernel_addr_r=0x8100\0"\
"fdtfile=apq8016-sbc.dtb\0" \
+   "soc_vendor=qcom\0" \
"fdt_addr_r=0x8300\0"\
"ramdisk_addr_r=0x8400\0"\
BOOTENV
-- 
2.6.6

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

[U-Boot] [PATCH 3/6] efi_loader: Search .dtb on non-EFI partitions

[Andreas Färber]

A UEFI setup will typically have an EFI FAT partition, but device trees
are more likely to be located on, e.g., Linux volumes. By convention the
EFI partition will usually be placed first, so that we would find the
EFI removable media binary and enter it without device tree from disk.

Therefore after finding an EFI removable media binary, probe other
partitions on the same device for .dtb files.

In the default case the behavior will be unchanged in that only the
first partition is searched.
In the case that there are two partitions marked bootable and the first
being EFI, we will first check the first partition, then the second
partition for the .dtb.
Duplicate loading will only result from non-first EFI partition order.

Cc: Alexander Graf 
Signed-off-by: Andreas Färber 
---
 include/config_distro_bootcmd.h | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 087f576..eadec2e 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -124,8 +124,7 @@
"fi\0"\
\
"load_efi_dtb="   \
-   "load ${devtype} ${devnum}:${distro_bootpart} "   \
-   "${fdt_addr_r} "  \
+   "load ${devtype} ${devnum}:${efi_bootpart} ${fdt_addr_r} "\
"${prefix}${dtb_prefix}${efi_fdtfile}\0"  \
\
"efi_dtb_prefixes=\"\" dtb/ dtb/current/\0"   \
@@ -133,7 +132,7 @@
"for prefix in ${boot_prefixes}; do " \
"for dtb_prefix in ${efi_dtb_prefixes}; do "  \
"if test -e ${devtype} "  \
-   "${devnum}:${distro_bootpart} "   \
+   "${devnum}:${efi_bootpart} "  \
"${prefix}${dtb_prefix}"  \
"${efi_fdtfile}; then "   \
"run load_efi_dtb; "  \
@@ -143,13 +142,22 @@
"scan_dev_for_efi="   \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
-   "run scan_dev_for_efi_fdt; "  \
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then "  \
"echo Found EFI removable media binary "  \
"efi/boot/"BOOTEFI_NAME"; "   \
+   "for efi_bootpart in ${devplist}; do "\
+   "echo Scanning for device tree "  \
+   "on ${devtype} ${devnum}" \
+   ":${efi_bootpart}...; "   \
+   "run scan_dev_for_efi_fdt; "  \
+   "done; "  \
"run boot_efi_binary; "   \
"echo EFI LOAD FAILED: continuing...; "   \
+   "else "   \
+   "setenv efi_bootpart ${distro_bootpart}; "\
+   "run scan_dev_for_efi_fdt; "  \
+   "setenv efi_bootpart; "   \
"fi; "\
"setenv efi_fdtfile\0"
 #define SCAN_DEV_FOR_EFI "run scan_dev_for_efi;"
-- 
2.6.6

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

[U-Boot] [PATCH 2/6] efi_loader: Respect $boot_prefixes for EFI .dtb search

[Andreas Färber]

Just like boot configs or scripts, .dtb files may be in /boot.
Search $efi_dtb_prefixes for all $boot_prefixes.

Cc: Alexander Graf 
Signed-off-by: Andreas Färber 
---
 include/config_distro_bootcmd.h | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index b1c9d36..087f576 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -125,19 +125,25 @@
\
"load_efi_dtb="   \
"load ${devtype} ${devnum}:${distro_bootpart} "   \
-   "${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
+   "${fdt_addr_r} "  \
+   "${prefix}${dtb_prefix}${efi_fdtfile}\0"  \
\
-   "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
+   "efi_dtb_prefixes=\"\" dtb/ dtb/current/\0"   \
+   "scan_dev_for_efi_fdt="   \
+   "for prefix in ${boot_prefixes}; do " \
+   "for dtb_prefix in ${efi_dtb_prefixes}; do "  \
+   "if test -e ${devtype} "  \
+   "${devnum}:${distro_bootpart} "   \
+   "${prefix}${dtb_prefix}"  \
+   "${efi_fdtfile}; then "   \
+   "run load_efi_dtb; "  \
+   "fi; "\
+   "done; "  \
+   "done\0"  \
"scan_dev_for_efi="   \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
-   "for prefix in ${efi_dtb_prefixes}; do "  \
-   "if test -e ${devtype} "  \
-   "${devnum}:${distro_bootpart} "   \
-   "${prefix}${efi_fdtfile}; then "  \
-   "run load_efi_dtb; "  \
-   "fi; "\
-   "done; "  \
+   "run scan_dev_for_efi_fdt; "  \
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then "  \
"echo Found EFI removable media binary "  \
-- 
2.6.6

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

[U-Boot] [PATCH 1/6] efi_loader: Cosmetic distro script cleanups

[Andreas Färber]

Fix a macro line break whose alignment slipped in commit fba5f93.
Be consistent in having trailing spaces after semicolon.
While at it, drop a duplicate white line.

Cc: Alexander Graf 
Signed-off-by: Andreas Färber 
---
 include/config_distro_bootcmd.h | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 9ecaf38..b1c9d36 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -113,15 +113,14 @@
 #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
 #endif
 
-
 #define BOOTENV_SHARED_EFI\
"boot_efi_binary="\
"load ${devtype} ${devnum}:${distro_bootpart} "   \
"${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; "  \
"if fdt addr ${fdt_addr_r}; then "\
-   "bootefi ${kernel_addr_r} ${fdt_addr_r};" \
-   "else "\
-   "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
+   "bootefi ${kernel_addr_r} ${fdt_addr_r}; "\
+   "else "   \
+   "bootefi ${kernel_addr_r} ${fdtcontroladdr}; "\
"fi\0"\
\
"load_efi_dtb="   \
@@ -137,8 +136,8 @@
"${devnum}:${distro_bootpart} "   \
"${prefix}${efi_fdtfile}; then "  \
"run load_efi_dtb; "  \
-   "fi;" \
-   "done;"   \
+   "fi; "\
+   "done; "  \
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then "  \
"echo Found EFI removable media binary "  \
-- 
2.6.6

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

[U-Boot] [PATCH v4] rockchip: add option to change method of loading u-boot

[Ziyuan Xu]

From: Xu Ziyuan 

If we would like to boot from SD card, we have to implement mmc driver
in SPL stage, and get a slightly large SPL binrary. Rockchip SoC's
bootrom code has the ability to load spl and u-boot, then boot.

If CONFIG_ROCKCHIP_SPL_BACK_TO_BROM is enabled, the spl will return to
tbootrom in board_init_f(), then bootrom load u-boot binrary.

This patch does that.

Loading sequence after rework:
bootrom ==> spl ==> bootrom ==> u-boot

Signed-off-by: Ziyuan Xu 
Acked-by: Simon Glass 
---

Changes in v4:
- Add acked flag from Simon
- Rename to CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
- Add Kconfig option for this feature support
- Revise some nits
- Update comments a little
- Update commit message

Changes in v3:
- Add CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM for enabling this feature
- Update doc/README.rockchip to instruct how to use it
- Detailed commit message

Changes in v2:
- Add sdcard iomux initlization in board_init() to fix sdmmc command
sending timeout issue when booting from eMMC

 arch/arm/mach-rockchip/Kconfig |  8 ++
 arch/arm/mach-rockchip/Makefile|  1 +
 arch/arm/mach-rockchip/board.c | 33 ++
 arch/arm/mach-rockchip/rk3036/Makefile |  1 -
 arch/arm/mach-rockchip/rk3288-board-spl.c  |  5 +++-
 .../mach-rockchip/{rk3036 => }/save_boot_param.S   |  2 +-
 doc/README.rockchip| 14 +
 include/configs/rk3288_common.h|  5 
 8 files changed, 66 insertions(+), 3 deletions(-)
 rename arch/arm/mach-rockchip/{rk3036 => }/save_boot_param.S (90%)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 2a8afac..fe60c7a 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -17,6 +17,14 @@ config ROCKCHIP_RK3036
  and video codec support. Peripherals include Gigabit Ethernet,
  USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.
 
+config ROCKCHIP_SPL_BACK_TO_BROM
+   bool "SPL returns to bootrom"
+   default y if ROCKCHIP_RK3036
+   help
+ Rochchip SoCs have ability to load SPL & U-BOOT binrary. This opinion,
+ if enabled, SPL will return to boorom, then load U-BOOT binrary to 
keep
+ going on.
+
 config SYS_MALLOC_F
default y
 
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 55567cb..c08d61b 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -7,6 +7,7 @@
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
+obj-$(CONFIG_ROCKCHIP_SPL_BACK_TO_BROM) += save_boot_param.o
 else
 obj-$(CONFIG_ROCKCHIP_RK3288) += board.o
 endif
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 816540e..b07e073 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -10,12 +10,45 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
 {
+#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
+   struct udevice *pinctrl;
+   int ret;
+
+/*
+ * We need to implement sdcard iomux here for the further
+ * initlization, otherwise, it'll hit sdcard command sending
+ * timeout exception.
+ */
+   ret = uclass_get_device(UCLASS_PINCTRL, 0, );
+   if (ret) {
+   debug("%s: Cannot find pinctrl device\n", __func__);
+   goto err;
+   }
+   ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_SDCARD);
+   if (ret) {
+   debug("%s: Failed to set up SD card\n", __func__);
+   goto err;
+   }
+
+   return 0;
+err:
+   printf("board_init: Error %d\n", ret);
+
+   /* No way to report error here */
+   hang();
+
+   return -1;
+#else
return 0;
+#endif
 }
 
 int dram_init(void)
diff --git a/arch/arm/mach-rockchip/rk3036/Makefile 
b/arch/arm/mach-rockchip/rk3036/Makefile
index 97d299d..6095777 100644
--- a/arch/arm/mach-rockchip/rk3036/Makefile
+++ b/arch/arm/mach-rockchip/rk3036/Makefile
@@ -10,4 +10,3 @@ obj-y += syscon_rk3036.o
 endif
 
 obj-y += sdram_rk3036.o
-obj-y += save_boot_param.o
diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c 
b/arch/arm/mach-rockchip/rk3288-board-spl.c
index 773ea42..0728e64 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -151,7 +151,7 @@ static int configure_emmc(struct udevice *pinctrl)
return 0;
 }
 #endif
-
+extern void back_to_bootrom(void);
 void board_init_f(ulong dummy)
 {
struct udevice *pinctrl;
@@ -206,6 +206,9 @@ void board_init_f(ulong dummy)
debug("DRAM init failed: %d\n", ret);
return;
}
+#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
+   back_to_bootrom();
+#endif
 

[U-Boot] [PATCH] armv8: spl: Call board_init_r from crt0_64 in SPL

[Jeremy Hunt]

As part of the startup process for boards using the SPL, the
meaning of board_init_f changed such that it should return normally
rather than calling board_init_r directly.
(see db910353a126d84fe8dff7a694ea792f50fcfb6a)
This was fixed in 32-bit arm, but broke when SPL was added to
64 bit arm. This fixes crt0_64 so that it calls board_init_r
durring the SPL and removes the direct call from board_init_f
from the arm SPL example.

Signed-off-by: Jeremy Hunt 

---

 arch/arm/lib/crt0_64.S |  3 +--
 arch/arm/lib/spl.c | 18 +-
 2 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index cad22c7..91b19e0 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -108,6 +108,7 @@ relocation_return:
  * Set up final (full) environment
  */
bl  c_runtime_cpu_setup /* still call old routine */
+#endif /* !CONFIG_SPL_BUILD */
 
 /* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */
 
@@ -130,6 +131,4 @@ clear_loop:
 
/* NOTREACHED - board_init_r() does not return */
 
-#endif /* !CONFIG_SPL_BUILD */
-
 ENDPROC(_main)
diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index e428868..b188834 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -25,22 +25,22 @@ gd_t gdata __attribute__ ((section(".data")));
 #endif
 
 /*
- * In the context of SPL, board_init_f must ensure that any clocks/etc for
- * DDR are enabled, ensure that the stack pointer is valid, clear the BSS
- * and call board_init_r.  We provide this version by default but mark it
- * as __weak to allow for platforms to do this in their own way if needed.
+ * In the context of SPL, board_init_f() prepares the hardware for execution
+ * from system RAM (DRAM, DDR...). As system RAM may not be available yet,
+ * board_init_f() must use the current GD to store any data which must be
+ * passed on to later stages. These data include the relocation destination,
+ * the future stack, and the future GD location. BSS is cleared after this
+ * function (and therefore must be accessible).
+ *
+ * We provide this version by default but mark it as __weak to allow for
+ * platforms to do this in their own way if needed.
  */
 void __weak board_init_f(ulong dummy)
 {
-   /* Clear the BSS. */
-   memset(__bss_start, 0, __bss_end - __bss_start);
-
 #ifndef CONFIG_SPL_DM
/* TODO: Remove settings of the global data pointer here */
gd = 
 #endif
-
-   board_init_r(NULL, 0);
 }
 
 /*
-- 
2.4.4

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

[U-Boot] [PATCH v3] driver: spi: fsl-qspi: disable AHB buffer prefetch

[Yunhui Cui]

From: Yunhui Cui 

Errata: A-009282: QuadSPI data pre-fetch can result in incorrect data
We need this errata workaround when CONFIG_SYS_FSL_QSPI_AHB is enabled.

Signed-off-by: Yunhui Cui 
---
 drivers/spi/fsl_qspi.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 75cbab2..0354e20 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -438,13 +438,23 @@ static void qspi_enable_ddr_mode(struct fsl_qspi_priv 
*priv)
 static void qspi_init_ahb_read(struct fsl_qspi_priv *priv)
 {
struct fsl_qspi_regs *regs = priv->regs;
+   int rx_size = 0x80;
 
/* AHB configuration for access buffer 0/1/2 .*/
qspi_write32(priv->flags, >buf0cr, QSPI_BUFXCR_INVALID_MSTRID);
qspi_write32(priv->flags, >buf1cr, QSPI_BUFXCR_INVALID_MSTRID);
qspi_write32(priv->flags, >buf2cr, QSPI_BUFXCR_INVALID_MSTRID);
+
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009282
+   /*A-009282: QuadSPI data pre-fetch can result in incorrect data
+*Workaround: Keep the read data size to 64 bits (8 Bytes), which
+*disables the prefetch on the AHB buffer,and prevents this issue
+*from occurring.
+   */
+   rx_size = 0x1;
+#endif
qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK |
-(0x80 << QSPI_BUF3CR_ADATSZ_SHIFT));
+(rx_size << QSPI_BUF3CR_ADATSZ_SHIFT));
 
/* We only use the buffer3 */
qspi_write32(priv->flags, >buf0ind, 0);
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH v2] driver: fsl_qspi: disable AHB buffer prefetch

[Yunhui Cui]

On 07/11, 2016, 11:17 PM, York Wrote:
> On 07/11/2016 12:49 AM, Yunhui Cui wrote:
> > From: Yunhui Cui 
> >
> > Errata: A-009282: QuadSPI data pre-fetch can result in incorrect data
> >
> > Signed-off-by: Yunhui Cui 
> > ---
> >   drivers/spi/fsl_qspi.c | 14 --
> >   1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
> > 75cbab2..99634db 100644
> > --- a/drivers/spi/fsl_qspi.c
> > +++ b/drivers/spi/fsl_qspi.c
> > @@ -438,14 +438,24 @@ static void qspi_enable_ddr_mode(struct
> fsl_qspi_priv *priv)
> >   static void qspi_init_ahb_read(struct fsl_qspi_priv *priv)
> >   {
> > struct fsl_qspi_regs *regs = priv->regs;
> > +   int rx_size = 0x80;
> >
> > /* AHB configuration for access buffer 0/1/2 .*/
> > qspi_write32(priv->flags, >buf0cr,
> QSPI_BUFXCR_INVALID_MSTRID);
> > qspi_write32(priv->flags, >buf1cr,
> QSPI_BUFXCR_INVALID_MSTRID);
> > qspi_write32(priv->flags, >buf2cr,
> QSPI_BUFXCR_INVALID_MSTRID);
> > -   qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK |
> > -(0x80 << QSPI_BUF3CR_ADATSZ_SHIFT));
> >
> > +#if defined(CONFIG_LS1043A) || defined(CONFIG_LS2080A) \
> > +   || defined(CONFIG_LS1012A) || defined(CONFIG_LS102XA)
> > +   /*A-009282: QuadSPI data pre-fetch can result in incorrect data
> > +*Workaround: Keep the read data size to 64 bits (8 Bytes), which
> > +*disables the prefetch on the AHB buffer,and prevents this issue
> > +*from occurring.
> > +   */
> > +   rx_size = 0x1;
> > +#endif
> > +   qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK |
> > +(rx_size << QSPI_BUF3CR_ADATSZ_SHIFT));
> > /* We only use the buffer3 */
> > qspi_write32(priv->flags, >buf0ind, 0);
> > qspi_write32(priv->flags, >buf1ind, 0);
> >
> 
> Yunhui,
> 
> I suggested to use erratum macro, like CONFIG_SYS_FSL_ERRATUM_A009282.

[Yunhui] ok, I will update it in v3, thanks a lot.

> 
> York

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

Re: [U-Boot] [PATCH v3] rockchip: rk3288: Change method of loading u-boot

[Simon Glass]

Hi,

On Jul 11, 2016 20:06, "Ziyuan Xu"  wrote:
>
> hi Simon,
>
>
> On 2016年07月12日 07:29, Simon Glass wrote:
>>
>> Hi Ziyuan,
>>
>> On 27 June 2016 at 02:30, Ziyuan Xu  wrote:
>>>
>>> From: Xu Ziyuan 
>>>
>>> If we would like to boot from SD card, we have to implement mmc driver
>>> in SPL stage, and get a slightly large spl binrary. RK3288's bootrom
code
>>> has the ability to load spl and u-boot, then boot.
>>>
>>> If CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM is enabled, the spl will
>>> return to bootrom in board_init_f(), then bootrom load u-boot binrary.
>>>
>>> This patch does that.
>>>
>>> Loading sequence after rework:
>>> bootrom ==> spl ==> bootrom ==> u-boot
>>>
>>> Signed-off-by: Ziyuan Xu 
>>> ---
>>>
>>> Changes in v3:
>>> - Add CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM for enabling this feature
>>> - Update doc/README.rockchip to instruct how to use it
>>> - Detailed commit message
>>>
>>> Changes in v2:
>>> - Add sdcard iomux initlization in board_init() to fix sdmmc command
>>> sending timeout issue when booting from eMMC
>>
>> Acked-by: Simon Glass 
>>
>> I'm going to apply this, but please can you send a follow-up patch (to
>> u-boot-rockchip/testing) to fix the nits below?
>
> This patch had already apply to u-boot/rockchip, I can't revise commit'
nits.
> I had revise the glitches according to your opinion. May I send patch V4,
and you revert the former commit?

Yes, either that or a new patch with your changes is fine.

Regards,
Simon

>
>>
>>>   arch/arm/mach-rockchip/Makefile|  1 +
>>>   arch/arm/mach-rockchip/board.c | 33
++
>>>   arch/arm/mach-rockchip/rk3036/Makefile |  1 -
>>>   arch/arm/mach-rockchip/rk3288-board-spl.c  |  5 +++-
>>>   .../mach-rockchip/{rk3036 => }/save_boot_param.S   |  2 +-
>>>   doc/README.rockchip| 14 +
>>>   include/configs/rk3288_common.h|  4 +++
>>>   7 files changed, 57 insertions(+), 3 deletions(-)
>>>   rename arch/arm/mach-rockchip/{rk3036 => }/save_boot_param.S (90%)
>>>
>>> diff --git a/arch/arm/mach-rockchip/Makefile
b/arch/arm/mach-rockchip/Makefile
>>> index 55567cb..8e0c0ab 100644
>>> --- a/arch/arm/mach-rockchip/Makefile
>>> +++ b/arch/arm/mach-rockchip/Makefile
>>> @@ -7,6 +7,7 @@
>>>   ifdef CONFIG_SPL_BUILD
>>>   obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o
>>>   obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
>>> +obj-y += save_boot_param.o
>>>   else
>>>   obj-$(CONFIG_ROCKCHIP_RK3288) += board.o
>>>   endif
>>> diff --git a/arch/arm/mach-rockchip/board.c
b/arch/arm/mach-rockchip/board.c
>>> index 816540e..bcb2c9e 100644
>>> --- a/arch/arm/mach-rockchip/board.c
>>> +++ b/arch/arm/mach-rockchip/board.c
>>> @@ -10,12 +10,45 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>> +#include 
>>> +#include 
>>>
>>>   DECLARE_GLOBAL_DATA_PTR;
>>>
>>>   int board_init(void)
>>>   {
>>> +#ifdef CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM
>>
>> How about CONFIG_ROCKCHIP_SPL_BACK_TO_BROM?
>>
>> I think this could be implemented for any SoC.
>>
>> Also please add this to Kconfig as we should not be adding new CONFIG
>> options that are not in Kconfig.
>>
>>> +   struct udevice *pinctrl;
>>> +   int ret;
>>> +
>>> +/*
>>> + * We need to implement sdcard iomux here for the further
>>> + * initlization, otherwise, it'll hit sdcard command sending
>>> + * timeout exception.
>>> + */
>>> +   ret = uclass_get_device(UCLASS_PINCTRL, 0, );
>>> +   if (ret) {
>>> +   debug("%s: Cannot find pinctrl device\n", __func__);
>>> +   goto err;
>>> +   }
>>> +   ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_SDCARD);
>>> +   if (ret) {
>>> +   debug("%s: Failed to set up SD card\n", __func__);
>>> +   goto err;
>>> +   }
>>> +
>>> +   return 0;
>>> +err:
>>> +   printf("board_init: Error %d\n", ret);
>>> +
>>> +   /* No way to report error here */
>>> +   hang();
>>> +
>>> +   return -1;
>>> +#else
>>>  return 0;
>>> +#endif
>>>   }
>>>
>>>   int dram_init(void)
>>> diff --git a/arch/arm/mach-rockchip/rk3036/Makefile
b/arch/arm/mach-rockchip/rk3036/Makefile
>>> index 97d299d..6095777 100644
>>> --- a/arch/arm/mach-rockchip/rk3036/Makefile
>>> +++ b/arch/arm/mach-rockchip/rk3036/Makefile
>>> @@ -10,4 +10,3 @@ obj-y += syscon_rk3036.o
>>>   endif
>>>
>>>   obj-y += sdram_rk3036.o
>>> -obj-y += save_boot_param.o
>>> diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c
b/arch/arm/mach-rockchip/rk3288-board-spl.c
>>> index e133cca..5de060c 100644
>>> --- a/arch/arm/mach-rockchip/rk3288-board-spl.c
>>> +++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
>>> @@ -149,7 +149,7 @@ static int configure_emmc(struct udevice *pinctrl)
>>>  return 0;
>>>   }
>>>   #endif
>>> -
>>> 

Re: [U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288

[Kever Yang]

Hi Simon,

CC Doug for this topic.

On 07/12/2016 07:54 AM, Simon Glass wrote:

Hi Kever,

On 11 July 2016 at 00:58, Kever Yang  wrote:

Hi Simon,

On 07/09/2016 10:39 PM, Simon Glass wrote:

Hi Kever,

On 7 July 2016 at 20:45, Kever Yang  wrote:

The grf setting for rkpwm is only need in rk3288, other SoCs like
RK3399 which also use rkpwm do not need set the grf, let's add a
MACRO to make the code only for RK3288.

Change-Id: I167a4e8cf925e840d4bbbcfb1437aaed52b81477

patman will automatically remove these for you.

Will use patman for my new patches later, thanks.


Signed-off-by: Kever Yang 
---
   drivers/pwm/rk_pwm.c | 8 
   1 file changed, 8 insertions(+)

diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
index 2d289a4..e34adf0 100644
--- a/drivers/pwm/rk_pwm.c
+++ b/drivers/pwm/rk_pwm.c
@@ -13,8 +13,10 @@
   #include 
   #include 
   #include 
+#ifdef CONFIG_ROCKCHIP_RK3288
   #include 
   #include 
+#endif
   #include 
   #include 

@@ -22,7 +24,9 @@ DECLARE_GLOBAL_DATA_PTR;

   struct rk_pwm_priv {
  struct rk3288_pwm *regs;
+#ifdef CONFIG_ROCKCHIP_RK3288
  struct rk3288_grf *grf;
+#endif
   };

   static int rk_pwm_set_config(struct udevice *dev, uint channel, uint
period_ns,
@@ -65,19 +69,23 @@ static int rk_pwm_ofdata_to_platdata(struct udevice
*dev)
  struct regmap *map;

  priv->regs = (struct rk3288_pwm *)dev_get_addr(dev);
+#ifdef CONFIG_ROCKCHIP_RK3288
  map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF);
  if (IS_ERR(map))
  return PTR_ERR(map);
  priv->grf = regmap_get_range(map, 0);
+#endif

I'd like to find a better way. Do all chips have a grf? If so then
perhaps we can have a function like grf_enable_pwm() in the core SoC
code and call it here. The #ifdef can be there.

Or perhaps we should have a general soc.c, with its own struct
containing pointers to grf, sgrf, etc. It can be set up at the start,
and then provide a soc_enable_pwm() function to enable the pwm.

What do you think?

Every Rockchip soc have grf, and maybe sgrf, pmugrf which much like
grf. The content in grf are very different for different SoC, it gathers
all kinds of system/module control registers .
Back to the grf setting for pwm, this control operation is only need in
RK3288, not in RK3399 and new SoC further. so I think the '#ifdef' is
better to stay in driver file like rk_pwm.c.

For these system control registers, I'm sure the dedicate general soc.c is
needed, because they are not so common for different module and different
Soc. We are not able to have a common framework for them, a general soc.c
won't help much except all the system control are gather in one file .

I think the GRF setting is part of the module and driver, so we can leave it
as it is,
and a simple syscon driver is enough for grf like what is kernel do.

I looked quickly at the Linux pwm driver but I don't see any grf
access there. How does the grf register get set in Linux? I really
want to avoid SoC-specific #ifdefs in drivers.
Doug(in cc list) send the patch for this pwm setting, but it seems does 
not accept by upstream,
I think people also don't like this grf access in driver and prefer this 
kind of one time init operation

to be done in bootloader.
patchset 1 implement in arch/arm/mach-rockchip/rockchip.c
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/280064.html
patchset 4 implement in drivers/pwm_rockchip.c
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/280715.html

Hi Doug,
Do you have any suggestion here?

Thanks,
- Kever



Thanks,
- Kever


  return 0;
   }

   static int rk_pwm_probe(struct udevice *dev)
   {
+#ifdef CONFIG_ROCKCHIP_RK3288
  struct rk_pwm_priv *priv = dev_get_priv(dev);

  rk_setreg(>grf->soc_con2, 1 << 0);
+#endif

  return 0;
   }
--
1.9.1



Regards,
Simon






Regards,
Simon






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

Re: [U-Boot] [PATCH v3] rockchip: rk3288: Change method of loading u-boot

[Ziyuan Xu]

hi Simon,

On 2016年07月12日 07:29, Simon Glass wrote:

Hi Ziyuan,

On 27 June 2016 at 02:30, Ziyuan Xu  wrote:

From: Xu Ziyuan 

If we would like to boot from SD card, we have to implement mmc driver
in SPL stage, and get a slightly large spl binrary. RK3288's bootrom code
has the ability to load spl and u-boot, then boot.

If CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM is enabled, the spl will
return to bootrom in board_init_f(), then bootrom load u-boot binrary.

This patch does that.

Loading sequence after rework:
bootrom ==> spl ==> bootrom ==> u-boot

Signed-off-by: Ziyuan Xu 
---

Changes in v3:
- Add CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM for enabling this feature
- Update doc/README.rockchip to instruct how to use it
- Detailed commit message

Changes in v2:
- Add sdcard iomux initlization in board_init() to fix sdmmc command
sending timeout issue when booting from eMMC

Acked-by: Simon Glass 

I'm going to apply this, but please can you send a follow-up patch (to
u-boot-rockchip/testing) to fix the nits below?
This patch had already apply to u-boot/rockchip, I can't revise commit' 
nits.
I had revise the glitches according to your opinion. May I send patch 
V4, and you revert the former commit?



  arch/arm/mach-rockchip/Makefile|  1 +
  arch/arm/mach-rockchip/board.c | 33 ++
  arch/arm/mach-rockchip/rk3036/Makefile |  1 -
  arch/arm/mach-rockchip/rk3288-board-spl.c  |  5 +++-
  .../mach-rockchip/{rk3036 => }/save_boot_param.S   |  2 +-
  doc/README.rockchip| 14 +
  include/configs/rk3288_common.h|  4 +++
  7 files changed, 57 insertions(+), 3 deletions(-)
  rename arch/arm/mach-rockchip/{rk3036 => }/save_boot_param.S (90%)

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 55567cb..8e0c0ab 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -7,6 +7,7 @@
  ifdef CONFIG_SPL_BUILD
  obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o
  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
+obj-y += save_boot_param.o
  else
  obj-$(CONFIG_ROCKCHIP_RK3288) += board.o
  endif
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 816540e..bcb2c9e 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -10,12 +10,45 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+#include 

  DECLARE_GLOBAL_DATA_PTR;

  int board_init(void)
  {
+#ifdef CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM

How about CONFIG_ROCKCHIP_SPL_BACK_TO_BROM?

I think this could be implemented for any SoC.

Also please add this to Kconfig as we should not be adding new CONFIG
options that are not in Kconfig.


+   struct udevice *pinctrl;
+   int ret;
+
+/*
+ * We need to implement sdcard iomux here for the further
+ * initlization, otherwise, it'll hit sdcard command sending
+ * timeout exception.
+ */
+   ret = uclass_get_device(UCLASS_PINCTRL, 0, );
+   if (ret) {
+   debug("%s: Cannot find pinctrl device\n", __func__);
+   goto err;
+   }
+   ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_SDCARD);
+   if (ret) {
+   debug("%s: Failed to set up SD card\n", __func__);
+   goto err;
+   }
+
+   return 0;
+err:
+   printf("board_init: Error %d\n", ret);
+
+   /* No way to report error here */
+   hang();
+
+   return -1;
+#else
 return 0;
+#endif
  }

  int dram_init(void)
diff --git a/arch/arm/mach-rockchip/rk3036/Makefile 
b/arch/arm/mach-rockchip/rk3036/Makefile
index 97d299d..6095777 100644
--- a/arch/arm/mach-rockchip/rk3036/Makefile
+++ b/arch/arm/mach-rockchip/rk3036/Makefile
@@ -10,4 +10,3 @@ obj-y += syscon_rk3036.o
  endif

  obj-y += sdram_rk3036.o
-obj-y += save_boot_param.o
diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c 
b/arch/arm/mach-rockchip/rk3288-board-spl.c
index e133cca..5de060c 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -149,7 +149,7 @@ static int configure_emmc(struct udevice *pinctrl)
 return 0;
  }
  #endif
-
+extern void back_to_bootrom(void);
  void board_init_f(ulong dummy)
  {
 struct udevice *pinctrl;
@@ -204,6 +204,9 @@ void board_init_f(ulong dummy)
 debug("DRAM init failed: %d\n", ret);
 return;
 }
+#ifdef CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM
+   back_to_bootrom();
+#endif
  }

  static int setup_led(void)
diff --git a/arch/arm/mach-rockchip/rk3036/save_boot_param.S 
b/arch/arm/mach-rockchip/save_boot_param.S
similarity index 90%
rename from arch/arm/mach-rockchip/rk3036/save_boot_param.S
rename to arch/arm/mach-rockchip/save_boot_param.S
index 778ec83..85b407b 100644
--- 

Re: [U-Boot] [PATCH] dragonboard410c: prefer sdcard boot over emmc

[Andreas Färber]

Am 03.07.2016 um 18:59 schrieb Ricardo Salveti:
> Make the external devices the preferred ones when booting the system
> (usb is already the first option). This allows users to easily boot
> custom distributions without requiring them to reflash/customize u-boot.
> 
> Cc: Mateusz Kulikowski 
> Signed-off-by: Ricardo Salveti 

Reviewed-by: Andreas Färber 
Tested-by: Andreas Färber 

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/4] rockchip: rk3288: add fastboot support

[Ziyuan Xu]

hi Simon,

On 2016年07月12日 07:54, Simon Glass wrote:

Hi,

On 6 July 2016 at 03:34, Ziyuan Xu  wrote:

This patchset add the fastboot support for rk3288, and I have tested on
firefly-rk3288 board.

Fix an issue which was mentioned in V1's cover-letter:
The DMA buffer was always zero after DMA transfer is complete, It takes
no effect that invalidate dcache after the DMA is complete and before
the CPU reads it. It's important to invalidate dcache before starting
DMA, ensure coherency and prevent from any dirty lines in the cache
which from the DMA buffer.

Summary of changes in this series:
- Achieve UOC_CON_OFFSET physical address from DT
- Make UOC_CON registers to be unfixed which should be got from DT
- Add new commit dd77b11fd44a84 (usb: dwc2: Invalidate dcache before
staring DMA)

Changes in v3:
- Make UOC_CON registers to be unfixed which should be got from DT
- Achieve UOC_CON_OFFSET physical address from DT
- New commit since v3 to fix the coherence issue between memory and
cache

Changes in v2:
- Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
- Rework the behaviour in otg_phy_init() and otg_phy_off()
- Update detailed commit message
- Modify the macro's values
- Achieve the regs_phy from DT
- Update comments a little

Xu Ziyuan (4):
   usb: rockchip-phy: implement USB2.0 phy control for Synopsys
   usb: dwc2-otg: re-define fifo-size for Rockchip SoCs
   rockchip: rk3288: add fastboot support
   usb: dwc2: invalidate dcache before starting DMA

  arch/arm/dts/rk3288.dtsi   |  1 +
  arch/arm/mach-rockchip/board.c | 60 ++
  drivers/usb/gadget/dwc2_udc_otg_regs.h |  6 +++
  drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c |  3 ++
  drivers/usb/phy/Makefile   |  1 +
  drivers/usb/phy/rockchip_usb_syno_phy.c| 47 +++
  include/configs/rk3288_common.h| 26 +
  7 files changed, 144 insertions(+)
  create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c

I'm holding off applying for a new version of this series.

okay, I will send v4 patch later, thanks!


Regards,
Simon






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

Re: [U-Boot] storage support for ub_dev_write API function

[Simon Glass]

Hi,

On 6 July 2016 at 08:44, Ihar Filipau  wrote:
> Hi All!
>
> I have stumbled upon the lack of support for storage devices in API's
> ub_dev_write()/API_dev_write() functions. Currently the function
> supports only the network devices.
>
> I have implemented the support for the storage by adapting the code
> from API_dev_read() function, and added the ub_dev_write() to the
> glue.c. Interface for the network devices is unchanged.
>
> I could only test the ub_dev_write() for storage, but my application
> doesn't use the ub_dev_send() thus I can't test it (but 99% sure that
> it still works).
>
> The patch is attached (should apply cleanly to the current git master
> git.denx.de/u-boot.git).
>
> Comments are welcome. Applying it to the git master is even more so.

Can you please resend this inline with patman / git send-email, rather
than as an attachment?

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

Re: [U-Boot] [RESEND PATCH] board: move all the rockchip board in one folder

[Simon Glass]

On 10 July 2016 at 21:14, Kever Yang  wrote:
> The 'evb_rk3036' and 'kylin' is not a vendor name, let's replace them
> to 'rockchip' which is a real _vendor_ name, and meet the architecure
> 'board///'.
>
> More boards from rockchip like evb_rk3288, evb_rk3399 will comes later.
>
> Signed-off-by: Kever Yang 
> ---
>
>  arch/arm/mach-rockchip/rk3036/Kconfig  | 4 ++--
>  board/{evb_rk3036 => rockchip}/evb_rk3036/Kconfig  | 2 +-
>  board/{evb_rk3036 => rockchip}/evb_rk3036/MAINTAINERS  | 0
>  board/{evb_rk3036 => rockchip}/evb_rk3036/Makefile | 0
>  board/{evb_rk3036 => rockchip}/evb_rk3036/evb_rk3036.c | 0
>  board/{kylin => rockchip}/kylin_rk3036/Kconfig | 2 +-
>  board/{kylin => rockchip}/kylin_rk3036/MAINTAINERS | 0
>  board/{kylin => rockchip}/kylin_rk3036/Makefile| 0
>  board/{kylin => rockchip}/kylin_rk3036/kylin_rk3036.c  | 0
>  9 files changed, 4 insertions(+), 4 deletions(-)
>  rename board/{evb_rk3036 => rockchip}/evb_rk3036/Kconfig (89%)
>  rename board/{evb_rk3036 => rockchip}/evb_rk3036/MAINTAINERS (100%)
>  rename board/{evb_rk3036 => rockchip}/evb_rk3036/Makefile (100%)
>  rename board/{evb_rk3036 => rockchip}/evb_rk3036/evb_rk3036.c (100%)
>  rename board/{kylin => rockchip}/kylin_rk3036/Kconfig (90%)
>  rename board/{kylin => rockchip}/kylin_rk3036/MAINTAINERS (100%)
>  rename board/{kylin => rockchip}/kylin_rk3036/Makefile (100%)
>  rename board/{kylin => rockchip}/kylin_rk3036/kylin_rk3036.c (100%)

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

Re: [U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288

[Simon Glass]

Hi Kever,

On 11 July 2016 at 00:58, Kever Yang  wrote:
> Hi Simon,
>
> On 07/09/2016 10:39 PM, Simon Glass wrote:
>>
>> Hi Kever,
>>
>> On 7 July 2016 at 20:45, Kever Yang  wrote:
>>>
>>> The grf setting for rkpwm is only need in rk3288, other SoCs like
>>> RK3399 which also use rkpwm do not need set the grf, let's add a
>>> MACRO to make the code only for RK3288.
>>>
>>> Change-Id: I167a4e8cf925e840d4bbbcfb1437aaed52b81477
>>
>> patman will automatically remove these for you.
>
> Will use patman for my new patches later, thanks.
>
>>
>>> Signed-off-by: Kever Yang 
>>> ---
>>>   drivers/pwm/rk_pwm.c | 8 
>>>   1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
>>> index 2d289a4..e34adf0 100644
>>> --- a/drivers/pwm/rk_pwm.c
>>> +++ b/drivers/pwm/rk_pwm.c
>>> @@ -13,8 +13,10 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#ifdef CONFIG_ROCKCHIP_RK3288
>>>   #include 
>>>   #include 
>>> +#endif
>>>   #include 
>>>   #include 
>>>
>>> @@ -22,7 +24,9 @@ DECLARE_GLOBAL_DATA_PTR;
>>>
>>>   struct rk_pwm_priv {
>>>  struct rk3288_pwm *regs;
>>> +#ifdef CONFIG_ROCKCHIP_RK3288
>>>  struct rk3288_grf *grf;
>>> +#endif
>>>   };
>>>
>>>   static int rk_pwm_set_config(struct udevice *dev, uint channel, uint
>>> period_ns,
>>> @@ -65,19 +69,23 @@ static int rk_pwm_ofdata_to_platdata(struct udevice
>>> *dev)
>>>  struct regmap *map;
>>>
>>>  priv->regs = (struct rk3288_pwm *)dev_get_addr(dev);
>>> +#ifdef CONFIG_ROCKCHIP_RK3288
>>>  map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF);
>>>  if (IS_ERR(map))
>>>  return PTR_ERR(map);
>>>  priv->grf = regmap_get_range(map, 0);
>>> +#endif
>>
>> I'd like to find a better way. Do all chips have a grf? If so then
>> perhaps we can have a function like grf_enable_pwm() in the core SoC
>> code and call it here. The #ifdef can be there.
>>
>> Or perhaps we should have a general soc.c, with its own struct
>> containing pointers to grf, sgrf, etc. It can be set up at the start,
>> and then provide a soc_enable_pwm() function to enable the pwm.
>>
>> What do you think?
>
> Every Rockchip soc have grf, and maybe sgrf, pmugrf which much like
> grf. The content in grf are very different for different SoC, it gathers
> all kinds of system/module control registers .
> Back to the grf setting for pwm, this control operation is only need in
> RK3288, not in RK3399 and new SoC further. so I think the '#ifdef' is
> better to stay in driver file like rk_pwm.c.
>
> For these system control registers, I'm sure the dedicate general soc.c is
> needed, because they are not so common for different module and different
> Soc. We are not able to have a common framework for them, a general soc.c
> won't help much except all the system control are gather in one file .
>
> I think the GRF setting is part of the module and driver, so we can leave it
> as it is,
> and a simple syscon driver is enough for grf like what is kernel do.

I looked quickly at the Linux pwm driver but I don't see any grf
access there. How does the grf register get set in Linux? I really
want to avoid SoC-specific #ifdefs in drivers.

>
> Thanks,
> - Kever
>
>>
>>>  return 0;
>>>   }
>>>
>>>   static int rk_pwm_probe(struct udevice *dev)
>>>   {
>>> +#ifdef CONFIG_ROCKCHIP_RK3288
>>>  struct rk_pwm_priv *priv = dev_get_priv(dev);
>>>
>>>  rk_setreg(>grf->soc_con2, 1 << 0);
>>> +#endif
>>>
>>>  return 0;
>>>   }
>>> --
>>> 1.9.1
>>>
>>>
>> Regards,
>> Simon
>>
>>
>>
>
>

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

Re: [U-Boot] [PATCH v3 0/4] rockchip: rk3288: add fastboot support

[Simon Glass]

Hi,

On 6 July 2016 at 03:34, Ziyuan Xu  wrote:
> This patchset add the fastboot support for rk3288, and I have tested on
> firefly-rk3288 board.
>
> Fix an issue which was mentioned in V1's cover-letter:
> The DMA buffer was always zero after DMA transfer is complete, It takes
> no effect that invalidate dcache after the DMA is complete and before
> the CPU reads it. It's important to invalidate dcache before starting
> DMA, ensure coherency and prevent from any dirty lines in the cache
> which from the DMA buffer.
>
> Summary of changes in this series:
> - Achieve UOC_CON_OFFSET physical address from DT
> - Make UOC_CON registers to be unfixed which should be got from DT
> - Add new commit dd77b11fd44a84 (usb: dwc2: Invalidate dcache before
> staring DMA)
>
> Changes in v3:
> - Make UOC_CON registers to be unfixed which should be got from DT
> - Achieve UOC_CON_OFFSET physical address from DT
> - New commit since v3 to fix the coherence issue between memory and
> cache
>
> Changes in v2:
> - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
> - Rework the behaviour in otg_phy_init() and otg_phy_off()
> - Update detailed commit message
> - Modify the macro's values
> - Achieve the regs_phy from DT
> - Update comments a little
>
> Xu Ziyuan (4):
>   usb: rockchip-phy: implement USB2.0 phy control for Synopsys
>   usb: dwc2-otg: re-define fifo-size for Rockchip SoCs
>   rockchip: rk3288: add fastboot support
>   usb: dwc2: invalidate dcache before starting DMA
>
>  arch/arm/dts/rk3288.dtsi   |  1 +
>  arch/arm/mach-rockchip/board.c | 60 
> ++
>  drivers/usb/gadget/dwc2_udc_otg_regs.h |  6 +++
>  drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c |  3 ++
>  drivers/usb/phy/Makefile   |  1 +
>  drivers/usb/phy/rockchip_usb_syno_phy.c| 47 +++
>  include/configs/rk3288_common.h| 26 +
>  7 files changed, 144 insertions(+)
>  create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c

I'm holding off applying for a new version of this series.

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

Re: [U-Boot] [PATCH] board: move all the rockchip board in one folder

[Simon Glass]

Hi Kever,

On 10 July 2016 at 21:14, Kever Yang  wrote:
> Hi Simon,
>
>
> On 07/09/2016 10:38 PM, Simon Glass wrote:
>
> Hi Kevin,
>
> On 7 July 2016 at 21:49, Eddie Cai  wrote:
>
> 2016-07-08 11:30 GMT+08:00 Kever Yang :
>
> The 'evb_rk3036' and 'kylin' is not a vendor name, let's replace them
> to 'rockchip' which is a real _vendor_ name, and meet the architecure
> 'board///'.
>
> More boards from rockchip like evb_rk3288, evb_rk3399 will comes later.
>
> Signed-off-by: Kever Yang 
>
> Reviewed-by: Eddie Cai 
>
> ---
>  arch/arm/mach-rockchip/rk3036/Kconfig  |  4 +-
>  board/evb_rk3036/evb_rk3036/Kconfig| 15 --
>  board/evb_rk3036/evb_rk3036/MAINTAINERS|  0
>  board/evb_rk3036/evb_rk3036/Makefile   |  7 ---
>  board/evb_rk3036/evb_rk3036/evb_rk3036.c   | 49 --
>  board/kylin/kylin_rk3036/Kconfig   | 15 --
>  board/kylin/kylin_rk3036/MAINTAINERS   |  0
>  board/kylin/kylin_rk3036/Makefile  |  7 ---
>  board/kylin/kylin_rk3036/kylin_rk3036.c| 81
> --
>  board/rockchip/evb_rk3036/Kconfig  | 15 ++
>  board/rockchip/evb_rk3036/MAINTAINERS  |  0
>  board/rockchip/evb_rk3036/Makefile |  7 +++
>  board/rockchip/evb_rk3036/evb_rk3036.c | 49 ++
>  board/rockchip/kylin_rk3036/Kconfig| 15 ++
>  board/rockchip/kylin_rk3036/MAINTAINERS|  0
>  board/rockchip/kylin_rk3036/Makefile   |  7 +++
>  board/rockchip/kylin_rk3036/kylin_rk3036.c | 81
> ++
>  17 files changed, 176 insertions(+), 176 deletions(-)
>  delete mode 100644 board/evb_rk3036/evb_rk3036/Kconfig
>  delete mode 100644 board/evb_rk3036/evb_rk3036/MAINTAINERS
>  delete mode 100644 board/evb_rk3036/evb_rk3036/Makefile
>  delete mode 100644 board/evb_rk3036/evb_rk3036/evb_rk3036.c
>  delete mode 100644 board/kylin/kylin_rk3036/Kconfig
>  delete mode 100644 board/kylin/kylin_rk3036/MAINTAINERS
>  delete mode 100644 board/kylin/kylin_rk3036/Makefile
>  delete mode 100644 board/kylin/kylin_rk3036/kylin_rk3036.c
>  create mode 100644 board/rockchip/evb_rk3036/Kconfig
>  create mode 100644 board/rockchip/evb_rk3036/MAINTAINERS
>  create mode 100644 board/rockchip/evb_rk3036/Makefile
>  create mode 100644 board/rockchip/evb_rk3036/evb_rk3036.c
>  create mode 100644 board/rockchip/kylin_rk3036/Kconfig
>  create mode 100644 board/rockchip/kylin_rk3036/MAINTAINERS
>  create mode 100644 board/rockchip/kylin_rk3036/Makefile
>  create mode 100644 board/rockchip/kylin_rk3036/kylin_rk3036.c
>
> Did you use patman for these? I think it should show these as renames
> rather than delete/add deltas.
>
> Sorry, I didn't use the patman, I use git  format-patch and get send-email
> instead,
> I will re-send this patch again with patman.
>
> BTW, I get below error when I use patman, I have no idea about where I need
> to define the 'board' node.
>
> Cleaned 1 patches
> Traceback (most recent call last):
>   File "./tools/patman/patman", line 159, in 
> options.add_maintainers)
>   File "u-boot/tools/patman/series.py", line 225, in MakeCcFile
> raise_on_error=raise_on_error)
>   File "u-boot/tools/patman/gitutil.py", line 326, in BuildEmailList
> raw += LookupEmail(item, alias, raise_on_error=raise_on_error)
>   File "u-boot/tools/patman/gitutil.py", line 500, in LookupEmail
> raise ValueError, msg
> ValueError: Alias 'board' not found

Please see 'Where Patches Are Sent' are sent in the README which talks
about tags. If you want to skip this error, please add the -t flag.

You are providing a 'board:' tag and there is no such alias.

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

Re: [U-Boot] [PATCH v3] rockchip: rk3288: Change method of loading u-boot

[Simon Glass]

On 27 June 2016 at 02:30, Ziyuan Xu  wrote:
> From: Xu Ziyuan 
>
> If we would like to boot from SD card, we have to implement mmc driver
> in SPL stage, and get a slightly large spl binrary. RK3288's bootrom code
> has the ability to load spl and u-boot, then boot.
>
> If CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM is enabled, the spl will
> return to bootrom in board_init_f(), then bootrom load u-boot binrary.
>
> This patch does that.
>
> Loading sequence after rework:
> bootrom ==> spl ==> bootrom ==> u-boot
>
> Signed-off-by: Ziyuan Xu 
> ---
>
> Changes in v3:
> - Add CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM for enabling this feature
> - Update doc/README.rockchip to instruct how to use it
> - Detailed commit message
>
> Changes in v2:
> - Add sdcard iomux initlization in board_init() to fix sdmmc command
> sending timeout issue when booting from eMMC
>
>  arch/arm/mach-rockchip/Makefile|  1 +
>  arch/arm/mach-rockchip/board.c | 33 
> ++
>  arch/arm/mach-rockchip/rk3036/Makefile |  1 -
>  arch/arm/mach-rockchip/rk3288-board-spl.c  |  5 +++-
>  .../mach-rockchip/{rk3036 => }/save_boot_param.S   |  2 +-
>  doc/README.rockchip| 14 +
>  include/configs/rk3288_common.h|  4 +++
>  7 files changed, 57 insertions(+), 3 deletions(-)
>  rename arch/arm/mach-rockchip/{rk3036 => }/save_boot_param.S (90%)
>

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

Re: [U-Boot] [PATCH v2] rockchip: add basic support for evb-rk3288 board

[Simon Glass]

On 11 July 2016 at 03:14, Ziyuan Xu  wrote:
> From: Xu Ziyuan 
>
> evb-3288 board RK3288-based development board with 2 USB ports, HDMI,
> VGA, micro-SD card, audio, WiFi and Gigabit Ethernet. It also includes
> on-board 8G eMMC and 2GB of SDRAM. Expansion connector provide access to
> display pins, I2C, SPI, UART and GPIOs. This add some basic files
> required to allow the board to output serial messaged and can run
> command(mmc info etc).
>
> evb-rk3288 also supports booting from eMMC or SD card, the default is eMMC.
>
> Signed-off-by: Ziyuan Xu 
> Reviewed-by: Simon Glass 
> ---
>
> Changes in v2:
> - Fix a comment nit
> - Add reviewed flag from Simon
>
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/rk3288-evb.dts   |  59 +
>  arch/arm/dts/rk3288-evb.dtsi  | 379 
> ++
>  arch/arm/mach-rockchip/rk3288-board-spl.c |   4 +-
>  arch/arm/mach-rockchip/rk3288/Kconfig |  10 +
>  board/evb-rk3288/evb-rk3288/Kconfig   |  15 ++
>  board/evb-rk3288/evb-rk3288/MAINTAINERS   |   6 +
>  board/evb-rk3288/evb-rk3288/Makefile  |   7 +
>  board/evb-rk3288/evb-rk3288/evb-rk3288.c  |  15 ++
>  configs/evb-rk3288_defconfig  |  67 ++
>  doc/README.rockchip   |   3 +-
>  include/configs/evb-rk3288.h  |  26 ++
>  12 files changed, 590 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/dts/rk3288-evb.dts
>  create mode 100644 arch/arm/dts/rk3288-evb.dtsi
>  create mode 100644 board/evb-rk3288/evb-rk3288/Kconfig
>  create mode 100644 board/evb-rk3288/evb-rk3288/MAINTAINERS
>  create mode 100644 board/evb-rk3288/evb-rk3288/Makefile
>  create mode 100644 board/evb-rk3288/evb-rk3288/evb-rk3288.c
>  create mode 100644 configs/evb-rk3288_defconfig
>  create mode 100644 include/configs/evb-rk3288.h

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

Re: [U-Boot] [PATCH v3] rockchip: rk3288: Change method of loading u-boot

[Simon Glass]

Hi Ziyuan,

On 27 June 2016 at 02:30, Ziyuan Xu  wrote:
> From: Xu Ziyuan 
>
> If we would like to boot from SD card, we have to implement mmc driver
> in SPL stage, and get a slightly large spl binrary. RK3288's bootrom code
> has the ability to load spl and u-boot, then boot.
>
> If CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM is enabled, the spl will
> return to bootrom in board_init_f(), then bootrom load u-boot binrary.
>
> This patch does that.
>
> Loading sequence after rework:
> bootrom ==> spl ==> bootrom ==> u-boot
>
> Signed-off-by: Ziyuan Xu 
> ---
>
> Changes in v3:
> - Add CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM for enabling this feature
> - Update doc/README.rockchip to instruct how to use it
> - Detailed commit message
>
> Changes in v2:
> - Add sdcard iomux initlization in board_init() to fix sdmmc command
> sending timeout issue when booting from eMMC

Acked-by: Simon Glass 

I'm going to apply this, but please can you send a follow-up patch (to
u-boot-rockchip/testing) to fix the nits below?

>
>  arch/arm/mach-rockchip/Makefile|  1 +
>  arch/arm/mach-rockchip/board.c | 33 
> ++
>  arch/arm/mach-rockchip/rk3036/Makefile |  1 -
>  arch/arm/mach-rockchip/rk3288-board-spl.c  |  5 +++-
>  .../mach-rockchip/{rk3036 => }/save_boot_param.S   |  2 +-
>  doc/README.rockchip| 14 +
>  include/configs/rk3288_common.h|  4 +++
>  7 files changed, 57 insertions(+), 3 deletions(-)
>  rename arch/arm/mach-rockchip/{rk3036 => }/save_boot_param.S (90%)
>
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 55567cb..8e0c0ab 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -7,6 +7,7 @@
>  ifdef CONFIG_SPL_BUILD
>  obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o
>  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> +obj-y += save_boot_param.o
>  else
>  obj-$(CONFIG_ROCKCHIP_RK3288) += board.o
>  endif
> diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
> index 816540e..bcb2c9e 100644
> --- a/arch/arm/mach-rockchip/board.c
> +++ b/arch/arm/mach-rockchip/board.c
> @@ -10,12 +10,45 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>
>  DECLARE_GLOBAL_DATA_PTR;
>
>  int board_init(void)
>  {
> +#ifdef CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM

How about CONFIG_ROCKCHIP_SPL_BACK_TO_BROM?

I think this could be implemented for any SoC.

Also please add this to Kconfig as we should not be adding new CONFIG
options that are not in Kconfig.

> +   struct udevice *pinctrl;
> +   int ret;
> +
> +/*
> + * We need to implement sdcard iomux here for the further
> + * initlization, otherwise, it'll hit sdcard command sending
> + * timeout exception.
> + */
> +   ret = uclass_get_device(UCLASS_PINCTRL, 0, );
> +   if (ret) {
> +   debug("%s: Cannot find pinctrl device\n", __func__);
> +   goto err;
> +   }
> +   ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_SDCARD);
> +   if (ret) {
> +   debug("%s: Failed to set up SD card\n", __func__);
> +   goto err;
> +   }
> +
> +   return 0;
> +err:
> +   printf("board_init: Error %d\n", ret);
> +
> +   /* No way to report error here */
> +   hang();
> +
> +   return -1;
> +#else
> return 0;
> +#endif
>  }
>
>  int dram_init(void)
> diff --git a/arch/arm/mach-rockchip/rk3036/Makefile 
> b/arch/arm/mach-rockchip/rk3036/Makefile
> index 97d299d..6095777 100644
> --- a/arch/arm/mach-rockchip/rk3036/Makefile
> +++ b/arch/arm/mach-rockchip/rk3036/Makefile
> @@ -10,4 +10,3 @@ obj-y += syscon_rk3036.o
>  endif
>
>  obj-y += sdram_rk3036.o
> -obj-y += save_boot_param.o
> diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c 
> b/arch/arm/mach-rockchip/rk3288-board-spl.c
> index e133cca..5de060c 100644
> --- a/arch/arm/mach-rockchip/rk3288-board-spl.c
> +++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
> @@ -149,7 +149,7 @@ static int configure_emmc(struct udevice *pinctrl)
> return 0;
>  }
>  #endif
> -
> +extern void back_to_bootrom(void);
>  void board_init_f(ulong dummy)
>  {
> struct udevice *pinctrl;
> @@ -204,6 +204,9 @@ void board_init_f(ulong dummy)
> debug("DRAM init failed: %d\n", ret);
> return;
> }
> +#ifdef CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM
> +   back_to_bootrom();
> +#endif
>  }
>
>  static int setup_led(void)
> diff --git a/arch/arm/mach-rockchip/rk3036/save_boot_param.S 
> b/arch/arm/mach-rockchip/save_boot_param.S
> similarity index 90%
> rename from arch/arm/mach-rockchip/rk3036/save_boot_param.S
> rename to arch/arm/mach-rockchip/save_boot_param.S
> index 778ec83..85b407b 100644
> --- 

Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support

[Carlo Caione]

On Tue, Jul 12, 2016 at 12:54 AM, Andreas Färber  wrote:
> Am 12.07.2016 um 00:52 schrieb Carlo Caione:
>> On Mon, Jul 11, 2016 at 11:38 PM, Andreas Färber  wrote:
>>> Am 11.07.2016 um 22:36 schrieb Carlo Caione:
 On Mon, Jul 11, 2016 at 10:15 PM, Andreas Färber  wrote:
>>
>> [...]
>>
>
> DRAM:  2 GiB
> No maUsing default environment
>
> In:serial@4c0
> Out:   serial@4c0
> Err:   serial@4c0
> Net:   No ethernet found.
> =>
>
> The eth_designware line (twice, if counting "No ma") is due to what Tom
> mentioned wrt DM GPIO, I guess.
>
> Shouldn't we get a version line from SPL, too? A serial driver issue?

 AFAIKT there is no SPL. U-Boot is loaded by BL3-1 also in the U-Boot
 shipped by amlogic.
>>>
>>> You're right, Hardkernel's version is without SPL, too.
>>>
>>> Still I wonder about that "No ma" (after the DRAM line).
>>
>> drivers/core/lists.c:   dm_warn("No match for driver
>> '%s'\n", entry->name);
>>
>> :)
>
> How does that explain the incomplete "No ma"?

The only thing I can think of is a shitty queueing by the UART driver
/ hardware.

-- 
Carlo Caione
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support

[Andreas Färber]

Am 12.07.2016 um 00:52 schrieb Carlo Caione:
> On Mon, Jul 11, 2016 at 11:38 PM, Andreas Färber  wrote:
>> Am 11.07.2016 um 22:36 schrieb Carlo Caione:
>>> On Mon, Jul 11, 2016 at 10:15 PM, Andreas Färber  wrote:
> 
> [...]
> 

 DRAM:  2 GiB
 No maUsing default environment

 In:serial@4c0
 Out:   serial@4c0
 Err:   serial@4c0
 Net:   No ethernet found.
 =>

 The eth_designware line (twice, if counting "No ma") is due to what Tom
 mentioned wrt DM GPIO, I guess.

 Shouldn't we get a version line from SPL, too? A serial driver issue?
>>>
>>> AFAIKT there is no SPL. U-Boot is loaded by BL3-1 also in the U-Boot
>>> shipped by amlogic.
>>
>> You're right, Hardkernel's version is without SPL, too.
>>
>> Still I wonder about that "No ma" (after the DRAM line).
> 
> drivers/core/lists.c:   dm_warn("No match for driver
> '%s'\n", entry->name);
> 
> :)

How does that explain the incomplete "No ma"?

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support

[Carlo Caione]

On Mon, Jul 11, 2016 at 11:38 PM, Andreas Färber  wrote:
> Am 11.07.2016 um 22:36 schrieb Carlo Caione:
>> On Mon, Jul 11, 2016 at 10:15 PM, Andreas Färber  wrote:

[...]

>>>
>>> DRAM:  2 GiB
>>> No maUsing default environment
>>>
>>> In:serial@4c0
>>> Out:   serial@4c0
>>> Err:   serial@4c0
>>> Net:   No ethernet found.
>>> =>
>>>
>>> The eth_designware line (twice, if counting "No ma") is due to what Tom
>>> mentioned wrt DM GPIO, I guess.
>>>
>>> Shouldn't we get a version line from SPL, too? A serial driver issue?
>>
>> AFAIKT there is no SPL. U-Boot is loaded by BL3-1 also in the U-Boot
>> shipped by amlogic.
>
> You're right, Hardkernel's version is without SPL, too.
>
> Still I wonder about that "No ma" (after the DRAM line).

drivers/core/lists.c:   dm_warn("No match for driver
'%s'\n", entry->name);

:)

-- 
Carlo Caione
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 00/62] dm: rockchip: sandbox: Add support for compiled-in platform data

[Simon Glass]

Hi,

On 4 July 2016 at 11:57, Simon Glass  wrote:
>
> Note: This v3 series adds a test and fixes a few bugs found in generation of
> of-platdata.
>
> This series provides a way to compile in the contents of a device tree as C
> code into U-Boot, implementing an idea that Tom Rini came up with. It is
> intended to deal with extremely tight environments where there is not enough
> space for the ~3KB device tree code overhead. Examples include SPL where
> there is only 16KB of available RAM yet a full MMC stack is required.
>
> To provide a reasonable test environment, SPL support is added to sandbox,
> through a new 'sandbox_spl' target. A new tool 'dtoc' converts device tree
> data to C code (and structure definitions).
>
> To check its effectiveness for a real application, the v2 series includes
> support for enabling of-platdata for a rockchip board (firefly-rk3288). The
> results are as follows:
>
>   Code   Data  u-boot-spl.bin size
> of-platdata disabled  23159  1624  28864
> of-platdata enabled   19093  2616  21761
>
> Overall the saving is 7103 bytes, about 7KB. Approximately 4KB of this comes
> from removing the device tree data from SPL although this is offset by
> the size of the of-platdata itself (around 1KB). On top of this effective
> 3KB reduction, another ~3KB reduction comes from dropping libfdt and a
> further 1KB from dropping unused setup and driver-model code.
>
> Clearly this approach does have value. Looked at with a favourable light it
> provides the best of both worlds: configuration using standard device tree
> bindings without the run-time overhead.
>
> Looking under the hood shows a less rosy picture. Effectively we end up
> with a new set of C structures which must be handled by the driver. This
> series suggests a suitable approach for dealing with this (see of-plat.txt)
> which is workable. However there are a number of serious caveats. See that
> file for details.
>
> Thsi feature should be used sparingly. Rockchip is to some extent an unusual
> case: lots of features (leading to a large SPL device tree size of 4KB), no
> MMC stack available to SPL from the internal ROM* and a very limited maximum
> SPL code size. Most SoCs will not benefit from this.
>
> However, for an SoC with very small SRAM where only a few drivers are needed
> in SPL (such as serial and MMC) then of-platdata could provide a useful
> benefit, without a significant increase in complexity.
>
> With the v3 series this feature is ready for use. It is available at
> u-boot-dm/dt-working.
>
> The dtoc tool might be better renamed fdttoc (which is clumsy) or fdt2c.
> Ideas welcome.

I'm planning to apply this series soon. Please let me know if there
are any further comments.

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

[U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

This includes the MMC block-device stuff (which needs lots of testing
time), cleaning up some fdtdec COMPAT strings and some patman improvements.

The following changes since commit 19ce924ff914f315dc2fdf79f357825c513aed6e:

  Prepare v2016.07 (2016-07-11 15:01:01 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-dm.git

for you to fetch changes up to 94fbd3e37d6bdbf5490a185607ca20f862637220:

  tools: patman: Handle missing 'END' in non-last commit of a series
(2016-07-11 14:06:44 -0600)


Bin Meng (6):
  dm: Sort the uclass id in alphabetical order
  tools: patman: Use cover_match for 'Cover-letter'
  tools: patman: Handle tag sections without an 'END'
  tools: patman: Generate cover letter correctly when 'END' is missing
  tools: patman: Handle missing blank line for 'Series-changes'
  tools: patman: Handle missing 'END' in non-last commit of a series

Hamish Martin (1):
  dm: gpio: MPC85XX GPIO platform data support

Simon Glass (26):
  dm: mmc: dwmmc: Add comments to the dwmmc setup functions
  rockchip: Use 'select' instead of defaults in Kconfig
  mmc: Add function declarations for mmc_bread() and mmc_switch_part()
  dm: mmc: Move CONFIG_BLK code into the mmc uclass
  dm: mmc: Move non-CONFIG_BLK code into mmc_legacy.c
  mmc: Move MMC boot code into its own file
  dm: mmc: rockchip: Support only CONFIG_BLK
  mmc: Move tracing code into separate functions
  rockchip: Disable CONFIG_SDHCI
  dm: mmc: Add a way to use driver model for MMC operations
  dm: mmc: dwmmc: Support CONFIG_DM_MMC_OPS
  dm: mmc: rockchip: Enable CONFIG_DM_MMC_OPS for all boards
  rockchip: Add MAINTAINER files for kylin_rk3036, evb_rk3036
  dm: sandbox: Convert to use CONFIG_CMD_MMC_OPS
  dm: mmc: sdhci: Refactor configuration setup to support DM
  dm: mmc: sdhci: Support CONFIG_BLK and CONFIG_DM_MMC_OPS
  dm: mmc: msm_sdhci: Support CONFIG_BLK and CONFIG_DM_MMC_OPS
  dm: mmc: Move dragonboard410c to use CONFIG_BLK and CONFIG_DM_MMC_OPS
  dm: mmc: msmsdhic: Drop old MMC code
  dm: spl: mmc: Support CONFIG_BLK in SPL MMC
  dm: dfu: mmc: Support CONFIG_BLK in DFU for MMC
  x86: fdt: Drop the unused compatible strings in fdtdec
  fdt: Drop unused exynos compatible strings
  fdt: Add a note to avoid adding new compatible strings
  fdt: x86: Tidy up a few COMPAT string definitions
  sandbox: Find keyboard driver using driver model

Xu Ziyuan (1):
  common: block: fix compiler error with CONFIG_FASTBOOT_FLASH_MMC_DEV

 arch/Kconfig |   1 +
 arch/arm/Kconfig |  11 +++
 arch/arm/mach-rockchip/Kconfig   |  27 --
 arch/powerpc/include/asm/arch-mpc85xx/gpio.h |   6 ++
 arch/x86/cpu/ivybridge/lpc.c |   6 --
 board/evb_rk3036/evb_rk3036/MAINTAINERS  |   6 ++
 board/kylin/kylin_rk3036/MAINTAINERS |   6 ++
 common/fb_mmc.c  |   2 +-
 common/spl/spl_mmc.c |   6 +-
 configs/dragonboard410c_defconfig|   2 +
 configs/sandbox_defconfig|   4 +-
 drivers/dfu/dfu_mmc.c|  11 ++-
 drivers/gpio/mpc85xx_gpio.c  |  37 ++--
 drivers/misc/cros_ec_sandbox.c   |  11 ++-
 drivers/mmc/Kconfig  |  11 ++-
 drivers/mmc/Makefile |   3 +
 drivers/mmc/dw_mmc.c |  33 +++
 drivers/mmc/mmc-uclass.c | 146
+++
 drivers/mmc/mmc.c| 371
+++
 drivers/mmc/mmc_boot.c   | 131

 drivers/mmc/mmc_legacy.c |  91 
 drivers/mmc/mmc_private.h|  47 ++
 drivers/mmc/msm_sdhci.c  |  35 +++-
 drivers/mmc/rockchip_dw_mmc.c|  14 +--
 drivers/mmc/sandbox_mmc.c|  17 ++--
 drivers/mmc/sdhci.c  | 147
---
 include/configs/rk3036_common.h  |   1 -
 include/configs/rk3288_common.h  |   1 -
 include/dm/uclass-id.h   |   4 +-
 include/dwmmc.h  |  73 
 include/fdtdec.h |   8 --
 include/mmc.h|  66 +-
 include/sdhci.h  |  80 +
 lib/fdtdec.c |  19 ++--
 tools/patman/patchstream.py  |  38 +++-
 35 files changed, 995 insertions(+), 477 deletions(-)
 create mode 100644 drivers/mmc/mmc_boot.c

Regards,
Simon

Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support

[Andreas Färber]

Am 11.07.2016 um 22:36 schrieb Carlo Caione:
> On Mon, Jul 11, 2016 at 10:15 PM, Andreas Färber  wrote:
>> [...]
>> NOTICE:  BL3-1: v1.0(debug):4d2e34d
>> NOTICE:  BL3-1: Built : 17:08:35, Oct 29 2015
>> INFO:BL3-1: Initializing runtime services
>> INFO:BL3-1: Preparing for EL3 exit to normal world
>> INFO:BL3-1: Next image address = 0x100
>> INFO:BL3-1: Next image spsr = 0x3c9
>> No match for driver 'eth_designware'
>> Some drivers were not found
>>
>>
>> U-Boot 2016.07-1-g10a9e48 (Jul 11 2016 - 21:58:13 +0200) odroid-c2
>>
>> DRAM:  2 GiB
>> No maUsing default environment
>>
>> In:serial@4c0
>> Out:   serial@4c0
>> Err:   serial@4c0
>> Net:   No ethernet found.
>> =>
>>
>> The eth_designware line (twice, if counting "No ma") is due to what Tom
>> mentioned wrt DM GPIO, I guess.
>>
>> Shouldn't we get a version line from SPL, too? A serial driver issue?
> 
> AFAIKT there is no SPL. U-Boot is loaded by BL3-1 also in the U-Boot
> shipped by amlogic.

You're right, Hardkernel's version is without SPL, too.

Still I wonder about that "No ma" (after the DRAM line).

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ANN] U-Boot v2016.07 is released

[Wolfgang Denk]

Dear Tom,

In message <20160711195212.GA25382@bill-the-cat> you wrote:
> 
> I've released v2016.07 and it's now live on git and FTP and ACD.  As a
> possible bonus, the tarball is now signed with my PGP key.

Thanks a lot.  Release statistics are also up now, oth for the recent
[1] and for the previous [2] release:

[1] http://www.denx.de/wiki/U-Boot/UbootStat_2016_07
[2] http://www.denx.de/wiki/U-Boot/UbootStat_2016_05

Here a short summary:

v2016.07 - recent release:
==

Processed 1078 csets from 133 developers
25 employers found
A total of 87409 lines added, 35501 removed (delta 51908)

Developers with the most changesets
Simon Glass143 (13.3%)
Masahiro Yamada 84 (7.8%)
Bin Meng78 (7.2%)
Marek Vasut 57 (5.3%)
Michal Simek49 (4.5%)
Lokesh Vutla40 (3.7%)
Peng Fan35 (3.2%)
Stephen Warren  30 (2.8%)
Heiko Schocher  26 (2.4%)
Tim Harvey  22 (2.0%)
...

Developers with the most changed lines
Bin Meng  17039 (16.1%)
Simon Glass   13892 (13.1%)
Heiko Schocher8276 (7.8%)
Marek Vasut   7755 (7.3%)
Stephen Warren5584 (5.3%)
Wills Wang4848 (4.6%)
Lokesh Vutla  3682 (3.5%)
Andre Renaud  3544 (3.3%)
Steve Rae 2874 (2.7%)
Eddy Petrișor2792 (2.6%)
...

Developers with the most lines removed
Robert P. J. Day  2538 (7.1%)
Scott Wood1385 (3.9%)
Hans de Goede  258 (0.7%)
Abhimanyu Saini 96 (0.3%)
Eric Nelson 27 (0.1%)
Chris Packham   21 (0.1%)
Chris Brand  4 (0.0%)
Fabio Estevam3 (0.0%)
Nathan Rossi 3 (0.0%)
Yangbo Lu1 (0.0%)
...

Developers with the most signoffs (total 190)
Minkyu Kang 36 (18.9%)
Hans de Goede   31 (16.3%)
Tom Warren  15 (7.9%)
Tom Rini11 (5.8%)
Srinivas, Madan  9 (4.7%)
Daniel Schwierzeck   8 (4.2%)
Simon Glass  8 (4.2%)
Calvin Johnson   7 (3.7%)
Prabhakar Kushwaha   7 (3.7%)
Andreas Bießmann6 (3.2%)
...

Developers with the most reviews (total 566)
Simon Glass157 (27.7%)
Tom Rini   105 (18.6%)
York Sun81 (14.3%)
Stefan Roese43 (7.6%)
Andreas Bießmann   35 (6.2%)
Joe Hershberger 28 (4.9%)
Heiko Schocher  19 (3.4%)
Bin Meng18 (3.2%)
Lokesh Vutla17 (3.0%)
Hans de Goede   16 (2.8%)
...

Developers with the most test credits (total 61)
Stefan Roese22 (36.1%)
Andreas Dannenberg   8 (13.1%)
Heiko Schocher   7 (11.5%)
Michal Simek 6 (9.8%)
Mugunthan V N5 (8.2%)
Fabio Estevam4 (6.6%)
George McCollister   2 (3.3%)
Simon Glass  1 (1.6%)
Tom Rini 1 (1.6%)
Masahiro Yamada  1 (1.6%)
...

Developers who gave the most tested-by credits (total 61)
Bin Meng23 (37.7%)
Simon Glass  6 (9.8%)
Dan Murphy   6 (9.8%)
Peng Fan 4 (6.6%)
Srinivas, Madan  4 (6.6%)
Lokesh Vutla 3 (4.9%)
Daniel Allred3 (4.9%)
Steve Rae2 (3.3%)
Fabio Estevam1 (1.6%)
Masahiro Yamada  1 (1.6%)
...

Developers with the most report credits (total 10)
Srinivas, Madan  1 (10.0%)
Daiane Angolini  1 (10.0%)
Peter Robinson   1 (10.0%)
Nishanth Menon   1 (10.0%)
Chris Brand  1 (10.0%)
Jonathan Gray1 (10.0%)
Richard Woodruff 1 (10.0%)
Bernhard Nortmann1 (10.0%)
Suman Anna   1 (10.0%)
Pavel Machek 1 (10.0%)

Developers who gave the most report credits (total 10)
Lokesh Vutla 2 (20.0%)
Keerthy  2 (20.0%)
Peng Fan 1 (10.0%)
Steve Rae1 (10.0%)
Fabio Estevam1 (10.0%)
Alexander Graf   1 (10.0%)
Stefan Roese 1 (10.0%)
Hans de Goede1 (10.0%)

Top changeset contributors by employer
(Unknown)  354 (32.8%)
Google, Inc.   143 (13.3%)
Texas Instruments  100 (9.3%)
NXP 95 (8.8%)
DENX Software Engineering   94 (8.7%)
Socionext Inc.  85 (7.9%)
Xilinx  52 (4.8%)
NVidia  30 (2.8%)
Novell  21 (1.9%)
Collabora Ltd.  13 (1.2%)
...

Top lines changed by employer
(Unknown) 43274 (40.9%)
DENX Software Engineering 17697 (16.7%)
Google, Inc. 

Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support

[Carlo Caione]

On Mon, Jul 11, 2016 at 10:15 PM, Andreas Färber  wrote:
> Am 11.07.2016 um 21:48 schrieb Beniamino Galvani:
>> On Mon, Jul 11, 2016 at 05:23:15AM +0100, Peter Robinson wrote:
>>> On Mon, Jul 11, 2016 at 4:57 AM, Andreas Färber  wrote:
 Last output:

 NOTICE:  BL3-1: v1.0(debug):4d2e34d
 NOTICE:  BL3-1: Built : 17:08:35, Oct 29 2015
 INFO:BL3-1: Initializing runtime services
 INFO:BL3-1: Preparing for EL3 exit to normal world
 INFO:BL3-1: Next image address = 0x100
 INFO:BL3-1: Next image spsr = 0x3c9

 I.e., no U-Boot SPL output on serial.
>>>
>>> I see similar on Pine64 with 2016.07rc3
>>
>> Here the first non-booting commit is:
>>
>> commit d73718f3236c520a92efa401084c658e6cc067f3
>> Author: Mingkai Hu 
>> Date:   Thu Jul 7 12:22:12 2016 +0800
>>
>> armv8: Enable CPUECTLR.SMPEN for coherency
>
> Thanks! With that reverted I get:
>
> [...]
> NOTICE:  BL3-1: v1.0(debug):4d2e34d
> NOTICE:  BL3-1: Built : 17:08:35, Oct 29 2015
> INFO:BL3-1: Initializing runtime services
> INFO:BL3-1: Preparing for EL3 exit to normal world
> INFO:BL3-1: Next image address = 0x100
> INFO:BL3-1: Next image spsr = 0x3c9
> No match for driver 'eth_designware'
> Some drivers were not found
>
>
> U-Boot 2016.07-1-g10a9e48 (Jul 11 2016 - 21:58:13 +0200) odroid-c2
>
> DRAM:  2 GiB
> No maUsing default environment
>
> In:serial@4c0
> Out:   serial@4c0
> Err:   serial@4c0
> Net:   No ethernet found.
> =>
>
> The eth_designware line (twice, if counting "No ma") is due to what Tom
> mentioned wrt DM GPIO, I guess.
>
> Shouldn't we get a version line from SPL, too? A serial driver issue?

AFAIKT there is no SPL. U-Boot is loaded by BL3-1 also in the U-Boot
shipped by amlogic.

-- 
Carlo Caione
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support

[Andreas Färber]

Am 11.07.2016 um 21:48 schrieb Beniamino Galvani:
> On Mon, Jul 11, 2016 at 05:23:15AM +0100, Peter Robinson wrote:
>> On Mon, Jul 11, 2016 at 4:57 AM, Andreas Färber  wrote:
>>> Last output:
>>>
>>> NOTICE:  BL3-1: v1.0(debug):4d2e34d
>>> NOTICE:  BL3-1: Built : 17:08:35, Oct 29 2015
>>> INFO:BL3-1: Initializing runtime services
>>> INFO:BL3-1: Preparing for EL3 exit to normal world
>>> INFO:BL3-1: Next image address = 0x100
>>> INFO:BL3-1: Next image spsr = 0x3c9
>>>
>>> I.e., no U-Boot SPL output on serial.
>>
>> I see similar on Pine64 with 2016.07rc3
> 
> Here the first non-booting commit is:
> 
> commit d73718f3236c520a92efa401084c658e6cc067f3
> Author: Mingkai Hu 
> Date:   Thu Jul 7 12:22:12 2016 +0800
> 
> armv8: Enable CPUECTLR.SMPEN for coherency

Thanks! With that reverted I get:

[...]
NOTICE:  BL3-1: v1.0(debug):4d2e34d
NOTICE:  BL3-1: Built : 17:08:35, Oct 29 2015
INFO:BL3-1: Initializing runtime services
INFO:BL3-1: Preparing for EL3 exit to normal world
INFO:BL3-1: Next image address = 0x100
INFO:BL3-1: Next image spsr = 0x3c9
No match for driver 'eth_designware'
Some drivers were not found


U-Boot 2016.07-1-g10a9e48 (Jul 11 2016 - 21:58:13 +0200) odroid-c2

DRAM:  2 GiB
No maUsing default environment

In:serial@4c0
Out:   serial@4c0
Err:   serial@4c0
Net:   No ethernet found.
=>

The eth_designware line (twice, if counting "No ma") is due to what Tom
mentioned wrt DM GPIO, I guess.

Shouldn't we get a version line from SPL, too? A serial driver issue?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [ANN] U-Boot v2016.07 is released

[Tom Rini]

Hey all,

I've released v2016.07 and it's now live on git and FTP and ACD.  As a
possible bonus, the tarball is now signed with my PGP key.

Looking over the changes in this release, I would say it's another good,
solid, iterative improvement over the last.  MMC has moved to DM, we
have more tests for DM now too.  ARM (32 and 64bit), MIPS, x86 have all
seen improvements.  We've also switched to mirroring what the Linux
Kernel does for "libgcc" type functionality now which should help with
supporting the compilers that most distributions ship while still
catching the types of errors we want caught.  We've moved a few more
options over to Kconfig (caught some problems in our tools too) and are
once again ready for more.  I think we have enough tests available now
(thanks to tbot) that really even the complicated things can be moved
over now and verified as correct, it's just a matter of doing it.  We
also have the ability for SPL to load FIT images and thus pick the right
DT to pass along to the main U-Boot binary.

As always, I know I'm missing pointing out a few things that I should
point out and would encourage folks to chime in if there's anything they
would like to highlight.  But one last thing I want to highlight is that
with the two month release cycle I am feeling more comfortable with
saying that we can wait a little bit longer to pull in changes.  It's
not quite like the Linux Kernel -rc1 window but I'm expecting more
critical review from myself, and everyone else too in terms of taking in
changes the later in the release cycle it gets.

Thanks again everyone!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support

[Beniamino Galvani]

On Mon, Jul 11, 2016 at 05:23:15AM +0100, Peter Robinson wrote:
> On Mon, Jul 11, 2016 at 4:57 AM, Andreas Färber  wrote:

> > Last output:
> >
> > NOTICE:  BL3-1: v1.0(debug):4d2e34d
> > NOTICE:  BL3-1: Built : 17:08:35, Oct 29 2015
> > INFO:BL3-1: Initializing runtime services
> > INFO:BL3-1: Preparing for EL3 exit to normal world
> > INFO:BL3-1: Next image address = 0x100
> > INFO:BL3-1: Next image spsr = 0x3c9
> >
> > I.e., no U-Boot SPL output on serial.
> 
> I see similar on Pine64 with 2016.07rc3

Here the first non-booting commit is:

commit d73718f3236c520a92efa401084c658e6cc067f3
Author: Mingkai Hu 
Date:   Thu Jul 7 12:22:12 2016 +0800

armv8: Enable CPUECTLR.SMPEN for coherency


Mingkai, any ideas about how to debug or fix this?

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

[U-Boot] [PATCH v2] video: allow version string to be optional when using LOGO

[Anatolij Gustschin]

From: Tim Harvey 

The CONFIG_HIDE_LOGO_VERSION config can be used to disable putting the
U-Boot version string on top of the logo.

Signed-off-by: Tim Harvey 
---
Changes in v2:
 - move len and space variables to functio top
 - hide extra string if CONFIG_CONSOLE_EXTRA_INFO is defined

 README  |3 +++
 drivers/video/cfb_console.c |4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/README b/README
index 26d5ad2..e86934a 100644
--- a/README
+++ b/README
@@ -840,6 +840,9 @@ The following options need to be configured:
CONFIG_CONSOLE_EXTRA_INFO
additional board info beside
the logo
+   CONFIG_HIDE_LOGO_VERSION
+   do not display bootloader
+   version string
 
When CONFIG_CFB_CONSOLE_ANSI is defined, console will support
a limited number of ANSI escape sequences (cursor control,
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index ef4984b..30b53db 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1929,10 +1929,10 @@ static void plot_logo_or_black(void *screen, int x, int 
y, int black)
 static void *video_logo(void)
 {
char info[128];
-   int space, len;
__maybe_unused int y_off = 0;
__maybe_unused ulong addr;
__maybe_unused char *s;
+   __maybe_unused int len, space;
 
splash_get_pos(_logo_xpos, _logo_ypos);
 
@@ -1978,6 +1978,7 @@ static void *video_logo(void)
 
sprintf(info, " %s", version_string);
 
+#ifndef CONFIG_HIDE_LOGO_VERSION
space = (VIDEO_LINE_LEN / 2 - VIDEO_INFO_X) / VIDEO_FONT_WIDTH;
len = strlen(info);
 
@@ -2027,6 +2028,7 @@ static void *video_logo(void)
}
}
 #endif
+#endif
 
return (video_fb_address + video_logo_height * VIDEO_LINE_LEN);
 }
-- 
1.7.9.5

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

Re: [U-Boot] [RFC PATCH 4/7] env: Introduce "transient" and "system" access flags

[Bernhard Nortmann]

Am 11.07.2016 um 20:14 schrieb Bernhard Nortmann:

"transient" (='t') is like "any", but requests that a variable
should not be exported (ENV_FLAGS_VARACCESS_PREVENT_EXPORT).

"system" (='S') is meant for 'internal' variables that
aren't supposed to be changed by the user. It corresponds
to "transient" plus "read-only".

Signed-off-by: Bernhard Nortmann 
---

[...]

diff --git a/include/env_flags.h b/include/env_flags.h
index 7e2362a..9997a25 100644
--- a/include/env_flags.h
+++ b/include/env_flags.h
@@ -25,6 +25,8 @@ enum env_flags_varaccess {
env_flags_varaccess_readonly,
env_flags_varaccess_writeonce,
env_flags_varaccess_changedefault,
+   env_flags_varaccess_transient,
+   env_flags_varaccess_locked,
env_flags_varaccess_end
  };
  


The "env_flags_varaccess_locked" is a remnant of a previous iteration and
should of course read "env_flags_varaccess_system" instead. I've fixed this
in my local branch, and the correction will be part of a future v2.

Regards, B. Nortmann

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

Re: [U-Boot] [RFC PATCH 0/7] "Transient" (= export-restricted) environment vars

[Joe Hershberger]

Hi Bernhard,

On Mon, Jul 11, 2016 at 1:14 PM, Bernhard Nortmann
 wrote:
> This series evolved around the idea of introducing a new env_op
> type to control (and possibly restrict) the export of variables.
> This is especially useful if one wants to prevent dynamic
> configuration information from ending up in a saved environment -
> the 'classic' example being network setup with "dhcp" followed
> by the "saveenv" command.
>
> (The networking case is even further complicated by the fact
> that users may actually wish to setup and save a static IP
> configuration manually, which means that "locking up" the
> corresponding variables right away isn't a viable solution.)
>
> See also:
> http://lists.denx.de/pipermail/u-boot/2015-September/227611.html
> http://lists.denx.de/pipermail/u-boot/2016-April/250237.html

Also see:

http://lists.denx.de/pipermail/u-boot/2010-May/071315.html
http://lists.denx.de/pipermail/u-boot/2010-June/073031.html

> Regards, B. Nortmann
>
> BTW: What the correct 'subsystem'/prefix for the "core" changes
> related to env vars? patman isn't happy with my "env:" choice...

I still use "env:" and just silence patman.

>
> Bernhard Nortmann (7):
>   env: Allow unconditional access if H_PROGRAMMATIC is set
>   net: dm: Ignore unknown env_op_* constants
>   env: Introduce "export" operation and (access flag) restriction
>   env: Introduce "transient" and "system" access flags
>   sunxi: env: flag fel_* environment vars as "system"
>   env: Introduce setenv_transient() helper function
>   env: Automatically mark dynamic configuration info as "do not export"
>
>  cmd/net.c  | 34 +-
>  cmd/nvedit.c   | 24 +++-
>  common/env_flags.c | 21 ++---
>  include/common.h   |  1 +
>  include/configs/sunxi-common.h |  8 
>  include/env_flags.h|  5 -
>  include/search.h   |  1 +
>  lib/hashtable.c|  4 
>  net/eth-uclass.c   |  2 ++
>  9 files changed, 78 insertions(+), 22 deletions(-)
>
> --
> 2.7.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/4] Disable CONFIG_EFI_LOADER for rock2.

[Sandy Patterson]

I'm not sure why this breaks kernel loading.

Signed-off-by: Sandy Patterson 
---

 configs/rock2_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/rock2_defconfig b/configs/rock2_defconfig
index 3e16b80..3a06b7e 100644
--- a/configs/rock2_defconfig
+++ b/configs/rock2_defconfig
@@ -67,3 +67,4 @@ CONFIG_USE_PRIVATE_LIBGCC=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+# CONFIG_EFI_LOADER is not set
-- 
1.9.1

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

[U-Boot] [PATCH 4/4] RK3288 needs fdt and initrd below 256M now.

[Sandy Patterson]

I am not sure why this limit is changing. But my kernel
doesn't load when it's above 256. This was testing on the
rock2 board.

Signed-off-by: Sandy Patterson 
---

 include/configs/rk3288_common.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
index 9d50d83..b88e7e5 100644
--- a/include/configs/rk3288_common.h
+++ b/include/configs/rk3288_common.h
@@ -97,11 +97,11 @@
 
 #include 
 
-/* Linux fails to load the fdt if it's loaded above 512M on a Rock 2 board, so
+/* Linux fails to load the fdt if it's loaded above 256M on a Rock 2 board, so
  * limit the fdt reallocation to that */
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "fdt_high=0x1fff\0" \
-   "initrd_high=0x1fff\0" \
+   "fdt_high=0x0fff\0" \
+   "initrd_high=0x0fff\0" \
ENV_MEM_LAYOUT_SETTINGS \
ROCKCHIP_DEVICE_SETTINGS \
BOOTENV
-- 
1.9.1

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

[U-Boot] [PATCH 2/4] Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with asm code"

[Sandy Patterson]

This reverts commit df120142f36b6ff8b12187b8860269763b2b3203.

Conflicts:
arch/arm/cpu/armv7/cache_v7.c
arch/arm/cpu/armv7/cache_v7_asm.S

Signed-off-by: Sandy Patterson 
---

 arch/arm/cpu/armv7/cache_v7.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 85b0b0e..3e1ea2c 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -10,10 +10,16 @@
 #include 
 #include 
 
-#define ARMV7_DCACHE_INVAL_RANGE   1
-#define ARMV7_DCACHE_CLEAN_INVAL_RANGE 2
+#define ARMV7_DCACHE_INVAL_ALL 1
+#define ARMV7_DCACHE_CLEAN_INVAL_ALL   2
+#define ARMV7_DCACHE_INVAL_RANGE   3
+#define ARMV7_DCACHE_CLEAN_INVAL_RANGE 4
 
 #ifndef CONFIG_SYS_DCACHE_OFF
+
+/* Asm functions from cache_v7_asm.S */
+void v7_flush_dcache_all(void);
+
 static int check_cache_range(unsigned long start, unsigned long stop)
 {
int ok = 1;
@@ -31,6 +37,18 @@ static int check_cache_range(unsigned long start, unsigned 
long stop)
return ok;
 }
 
+/*
+ * Write the level and type you want to Cache Size Selection Register(CSSELR)
+ * to get size details from Current Cache Size ID Register(CCSIDR)
+ */
+static void set_csselr(u32 level, u32 type)
+{
+   u32 csselr = level << 1 | type;
+
+   /* Write to Cache Size Selection Register(CSSELR) */
+   asm volatile ("mcr p15, 2, %0, c0, c0, 0" : : "r" (csselr));
+}
+
 static u32 get_ccsidr(void)
 {
u32 ccsidr;
@@ -238,7 +256,7 @@ static void v7_inval_tlb(void)
 
 void invalidate_dcache_all(void)
 {
-   v7_invalidate_dcache_all();
+   v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL);
 
v7_outer_cache_inval_all();
 }
-- 
1.9.1

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

[U-Boot] [PATCH 1/4] Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) with asm code"

[Sandy Patterson]

This reverts commit c09d29057ab0b04db0857d319c6bff74de31b9c3.

Conflicts:
arch/arm/cpu/armv7/cache_v7.c
arch/arm/cpu/armv7/cache_v7_asm.S

Signed-off-by: Sandy Patterson 
---

 arch/arm/cpu/armv7/Makefile  |   2 +-
 arch/arm/cpu/armv7/cache_v7.c| 119 +++--
 arch/arm/cpu/armv7/cache_v7_asm.S| 154 ---
 arch/arm/mach-uniphier/arm32/lowlevel_init.S |  67 +++-
 4 files changed, 180 insertions(+), 162 deletions(-)
 delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S

diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index ddd8d12..34bd42b 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -7,7 +7,7 @@
 
 extra-y:= start.o
 
-obj-y  += cache_v7.o cache_v7_asm.o
+obj-y  += cache_v7.o
 
 obj-y  += cpu.o cp15.o
 obj-y  += syslib.o
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index dc309da..85b0b0e 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -14,11 +14,6 @@
 #define ARMV7_DCACHE_CLEAN_INVAL_RANGE 2
 
 #ifndef CONFIG_SYS_DCACHE_OFF
-
-/* Asm functions from cache_v7_asm.S */
-void v7_flush_dcache_all(void);
-void v7_invalidate_dcache_all(void);
-
 static int check_cache_range(unsigned long start, unsigned long stop)
 {
int ok = 1;
@@ -45,6 +40,118 @@ static u32 get_ccsidr(void)
return ccsidr;
 }
 
+static u32 get_clidr(void)
+{
+   u32 clidr;
+
+   /* Read current CP15 Cache Level ID Register */
+   asm volatile ("mrc p15,1,%0,c0,c0,1" : "=r" (clidr));
+   return clidr;
+}
+
+static void v7_inval_dcache_level_setway(u32 level, u32 num_sets,
+u32 num_ways, u32 way_shift,
+u32 log2_line_len)
+{
+   int way, set;
+   u32 setway;
+
+   /*
+* For optimal assembly code:
+*  a. count down
+*  b. have bigger loop inside
+*/
+   for (way = num_ways - 1; way >= 0 ; way--) {
+   for (set = num_sets - 1; set >= 0; set--) {
+   setway = (level << 1) | (set << log2_line_len) |
+(way << way_shift);
+   /* Invalidate data/unified cache line by set/way */
+   asm volatile (" mcr p15, 0, %0, c7, c6, 2"
+   : : "r" (setway));
+   }
+   }
+   /* DSB to make sure the operation is complete */
+   DSB;
+}
+
+static void v7_clean_inval_dcache_level_setway(u32 level, u32 num_sets,
+  u32 num_ways, u32 way_shift,
+  u32 log2_line_len)
+{
+   int way, set;
+   u32 setway;
+
+   /*
+* For optimal assembly code:
+*  a. count down
+*  b. have bigger loop inside
+*/
+   for (way = num_ways - 1; way >= 0 ; way--) {
+   for (set = num_sets - 1; set >= 0; set--) {
+   setway = (level << 1) | (set << log2_line_len) |
+(way << way_shift);
+   /*
+* Clean & Invalidate data/unified
+* cache line by set/way
+*/
+   asm volatile (" mcr p15, 0, %0, c7, c14, 2"
+   : : "r" (setway));
+   }
+   }
+   /* DSB to make sure the operation is complete */
+   DSB;
+}
+
+static void v7_maint_dcache_level_setway(u32 level, u32 operation)
+{
+   u32 ccsidr;
+   u32 num_sets, num_ways, log2_line_len, log2_num_ways;
+   u32 way_shift;
+
+   set_csselr(level, ARMV7_CSSELR_IND_DATA_UNIFIED);
+
+   ccsidr = get_ccsidr();
+
+   log2_line_len = ((ccsidr & CCSIDR_LINE_SIZE_MASK) >>
+   CCSIDR_LINE_SIZE_OFFSET) + 2;
+   /* Converting from words to bytes */
+   log2_line_len += 2;
+
+   num_ways  = ((ccsidr & CCSIDR_ASSOCIATIVITY_MASK) >>
+   CCSIDR_ASSOCIATIVITY_OFFSET) + 1;
+   num_sets  = ((ccsidr & CCSIDR_NUM_SETS_MASK) >>
+   CCSIDR_NUM_SETS_OFFSET) + 1;
+   /*
+* According to ARMv7 ARM number of sets and number of ways need
+* not be a power of 2
+*/
+   log2_num_ways = log_2_n_round_up(num_ways);
+
+   way_shift = (32 - log2_num_ways);
+   if (operation == ARMV7_DCACHE_INVAL_ALL) {
+   v7_inval_dcache_level_setway(level, num_sets, num_ways,
+ way_shift, log2_line_len);
+   } else if (operation == ARMV7_DCACHE_CLEAN_INVAL_ALL) {
+   v7_clean_inval_dcache_level_setway(level, num_sets, num_ways,
+  way_shift, log2_line_len);
+   }
+}
+
+static void 

[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Sandy Patterson]

I wasn't able to load the linux kernel using a Rock2 board
using the latest master branch. The board hangs after it has
handed executing over to the kernel. I found that the latest release
that worked was v2016.03.

I did some searching and I suspect the problem may be cache related.

This patchset allows the kernel to start by reverting two problem
commits and disabling EFI_LOADER which I suspect rubs the caching the
wrong way. We also found that the 512M limit for fdt and initrd is now 256M.
I'm not sure why this is.

This still doesn't work 100%. I think it's not initializing the SD card
volages correctly, but at least the Kernel is loading.

I also am not sure changing the caching for all armv7 is the right
answer. I wasn't too sure about the revert. I am not very familiar with
this low level stuff.

Sandy Patterson


Sandy Patterson (4):
  Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL)
with asm code"
  Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with
asm code"
  Disable CONFIG_EFI_LOADER for rock2.
  RK3288 needs fdt and initrd below 256M now.

 arch/arm/cpu/armv7/Makefile  |   2 +-
 arch/arm/cpu/armv7/cache_v7.c| 135 ++-
 arch/arm/cpu/armv7/cache_v7_asm.S| 154 ---
 arch/arm/mach-uniphier/arm32/lowlevel_init.S |  67 +++-
 configs/rock2_defconfig  |   1 +
 include/configs/rk3288_common.h  |   6 +-
 6 files changed, 201 insertions(+), 164 deletions(-)
 delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S

-- 
1.9.1

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

[U-Boot] [RFC PATCH 5/7] sunxi: env: flag fel_* environment vars as "system"

[Bernhard Nortmann]

"fel_booted" and "fel_scriptaddr" have a special meaning and get
used by U-Boot internally.

This patch aims at both preventing user modification of these
values, and at excluding them from being stored on "saveenv".

As this is achieved by setting specialized access flags,
also enable the "env flags" command.

Signed-off-by: Bernhard Nortmann 
---

 include/configs/sunxi-common.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 94275a7..1b48cf2 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -433,6 +433,14 @@ extern int soft_i2c_gpio_scl;
"fdt ram " FDT_ADDR_R " 0x10;" \
"ramdisk ram " RAMDISK_ADDR_R " 0x400\0"
 
+/*
+ * flag environment vars for FEL mode ("usb boot") as special. "system" access
+ * means they're marked read-only, and shouldn't be written on "saveenv".
+ */
+#define CONFIG_ENV_FLAGS_LIST_STATIC "fel_booted:bS,fel_scriptaddr:xS"
+/* support "env flags" command */
+#define CONFIG_CMD_ENV_FLAGS
+
 #ifdef CONFIG_MMC
 #define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0)
 #if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
-- 
2.7.3

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

[U-Boot] [RFC PATCH 3/7] env: Introduce "export" operation and (access flag) restriction

[Bernhard Nortmann]

This patch introduces a new "export" environment operation
(env_op_export) and the corresponding access flag
ENV_FLAGS_VARACCESS_PREVENT_EXPORT; so that env_flags_validate()
may now check requests to export specific variables.

In turn, hexport_r() makes uses of this ability to suppress the
export of variables that are flagged accordingly.

Note that env_flags_validate() and hexport_r() will respect H_FORCE
and H_PROGRAMMATIC flags, allowing to bypass the export filtering.
H_PROGRAMMATIC gets used within env_print() to make sure all
variables are listed. This is necessary because env_print() is
essentially an "export to text" operation.

Signed-off-by: Bernhard Nortmann 
---

 cmd/nvedit.c| 3 ++-
 common/env_flags.c  | 8 +++-
 include/env_flags.h | 3 ++-
 include/search.h| 1 +
 lib/hashtable.c | 4 
 5 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index b67563b..88dbcb9 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -101,7 +101,8 @@ static int env_print(char *name, int flag)
}
 
/* print whole list */
-   len = hexport_r(_htab, '\n', flag, , 0, 0, NULL);
+   len = hexport_r(_htab, '\n',
+   flag | H_PROGRAMMATIC, , 0, 0, NULL);
 
if (len > 0) {
puts(res);
diff --git a/common/env_flags.c b/common/env_flags.c
index 1087f4e..f39d952 100644
--- a/common/env_flags.c
+++ b/common/env_flags.c
@@ -510,7 +510,7 @@ int env_flags_validate(const ENTRY *item, const char 
*newval, enum env_op op,
newval = newval ? : "";
 
/* validate the value to match the variable type */
-   if (op != env_op_delete) {
+   if (op != env_op_delete && op != env_op_export) {
enum env_flags_vartype type = (enum env_flags_vartype)
(ENV_FLAGS_VARTYPE_BIN_MASK & item->flags);
 
@@ -560,6 +560,12 @@ int env_flags_validate(const ENTRY *item, const char 
*newval, enum env_op op,
return 1;
}
break;
+   case env_op_export:
+   if (item->flags & ENV_FLAGS_VARACCESS_PREVENT_EXPORT) {
+   printf("## Don't export \"%s\"\n", name);
+   return 1;
+   }
+   break;
}
 
return 0;
diff --git a/include/env_flags.h b/include/env_flags.h
index 0dcec06..7e2362a 100644
--- a/include/env_flags.h
+++ b/include/env_flags.h
@@ -173,6 +173,7 @@ int env_flags_validate(const ENTRY *item, const char 
*newval, enum env_op op,
 #define ENV_FLAGS_VARACCESS_PREVENT_CREATE 0x0010
 #define ENV_FLAGS_VARACCESS_PREVENT_OVERWR 0x0020
 #define ENV_FLAGS_VARACCESS_PREVENT_NONDEF_OVERWR  0x0040
-#define ENV_FLAGS_VARACCESS_BIN_MASK   0x0078
+#define ENV_FLAGS_VARACCESS_PREVENT_EXPORT 0x0080
+#define ENV_FLAGS_VARACCESS_BIN_MASK   0x00F8
 
 #endif /* __ENV_FLAGS_H__ */
diff --git a/include/search.h b/include/search.h
index 343dbc3..bb95265 100644
--- a/include/search.h
+++ b/include/search.h
@@ -23,6 +23,7 @@ enum env_op {
env_op_create,
env_op_delete,
env_op_overwrite,
+   env_op_export,
 };
 
 /* Action which shall be performed in the call the hsearch.  */
diff --git a/lib/hashtable.c b/lib/hashtable.c
index 02b4105..708319d 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -621,6 +621,10 @@ ssize_t hexport_r(struct hsearch_data *htab, const char 
sep, int flag,
if ((flag & H_HIDE_DOT) && ep->key[0] == '.')
continue;
 
+   if (env_flags_validate(ep, NULL, env_op_export,
+  flag & H_FORCE) != 0)
+   continue;
+
list[n++] = ep;
 
totlen += strlen(ep->key) + 2;
-- 
2.7.3

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

[U-Boot] [RFC PATCH 6/7] env: Introduce setenv_transient() helper function

[Bernhard Nortmann]

Like setenv(), but automatically marks the entry as "don't export".

Signed-off-by: Bernhard Nortmann 
---

 cmd/nvedit.c | 21 +
 include/common.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 88dbcb9..3c408f6 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -300,6 +300,27 @@ int setenv(const char *varname, const char *varvalue)
 }
 
 /**
+ * Set a "transient" environment variable
+ *
+ * Like setenv(), but this automatically marks the
+ * resulting entry as transient (= "do not export").
+ */
+int setenv_transient(const char *varname, const char *varvalue)
+{
+   int rc = setenv(varname, varvalue);
+   if (rc == 0) {
+   ENTRY e, *ep;
+
+   e.key = varname;
+   e.data = NULL;
+   hsearch_r(e, FIND, , _htab, 0);
+   if (ep)
+   ep->flags |= ENV_FLAGS_VARACCESS_PREVENT_EXPORT;
+   }
+   return rc;
+}
+
+/**
  * Set an environment variable to an integer value
  *
  * @param varname  Environment variable to set
diff --git a/include/common.h b/include/common.h
index 3feaae6..a8e019a 100644
--- a/include/common.h
+++ b/include/common.h
@@ -380,6 +380,7 @@ ulong getenv_hex(const char *varname, ulong default_val);
 int getenv_yesno(const char *var);
 intsaveenv  (void);
 intsetenv   (const char *, const char *);
+intsetenv_transient(const char *, const char *);
 int setenv_ulong(const char *varname, ulong value);
 int setenv_hex(const char *varname, ulong value);
 /**
-- 
2.7.3

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

[U-Boot] [RFC PATCH 7/7] env: Automatically mark dynamic configuration info as "do not export"

[Bernhard Nortmann]

This is an attempt to prevent such information from ending up
in exported environment data, especially when doing "saveenv".
(http://lists.denx.de/pipermail/u-boot/2015-September/227611.html)

The patch makes use of the new setenv_transient() helper for
environment variables that get updated via network configuration:
BOOTP/DHCP (netboot_update_env), CDP (cdp_update_env) and
link-local protocol (do_link_local).

Signed-off-by: Bernhard Nortmann 
---

 cmd/net.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/cmd/net.c b/cmd/net.c
index b2f3c7b..84b34ce 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -116,23 +116,23 @@ static void netboot_update_env(void)
 
if (net_gateway.s_addr) {
ip_to_string(net_gateway, tmp);
-   setenv("gatewayip", tmp);
+   setenv_transient("gatewayip", tmp);
}
 
if (net_netmask.s_addr) {
ip_to_string(net_netmask, tmp);
-   setenv("netmask", tmp);
+   setenv_transient("netmask", tmp);
}
 
if (net_hostname[0])
-   setenv("hostname", net_hostname);
+   setenv_transient("hostname", net_hostname);
 
if (net_root_path[0])
-   setenv("rootpath", net_root_path);
+   setenv_transient("rootpath", net_root_path);
 
if (net_ip.s_addr) {
ip_to_string(net_ip, tmp);
-   setenv("ipaddr", tmp);
+   setenv_transient("ipaddr", tmp);
}
 #if !defined(CONFIG_BOOTP_SERVERIP)
/*
@@ -141,32 +141,32 @@ static void netboot_update_env(void)
 */
if (net_server_ip.s_addr) {
ip_to_string(net_server_ip, tmp);
-   setenv("serverip", tmp);
+   setenv_transient("serverip", tmp);
}
 #endif
if (net_dns_server.s_addr) {
ip_to_string(net_dns_server, tmp);
-   setenv("dnsip", tmp);
+   setenv_transient("dnsip", tmp);
}
 #if defined(CONFIG_BOOTP_DNS2)
if (net_dns_server2.s_addr) {
ip_to_string(net_dns_server2, tmp);
-   setenv("dnsip2", tmp);
+   setenv_transient("dnsip2", tmp);
}
 #endif
if (net_nis_domain[0])
-   setenv("domain", net_nis_domain);
+   setenv_transient("domain", net_nis_domain);
 
 #if defined(CONFIG_CMD_SNTP) && defined(CONFIG_BOOTP_TIMEOFFSET)
if (net_ntp_time_offset) {
sprintf(tmp, "%d", net_ntp_time_offset);
-   setenv("timeoffset", tmp);
+   setenv_transient("timeoffset", tmp);
}
 #endif
 #if defined(CONFIG_CMD_SNTP) && defined(CONFIG_BOOTP_NTPSERVER)
if (net_ntp_server.s_addr) {
ip_to_string(net_ntp_server, tmp);
-   setenv("ntpserverip", tmp);
+   setenv_transient("ntpserverip", tmp);
}
 #endif
 }
@@ -294,14 +294,14 @@ static void cdp_update_env(void)
printf("CDP offered appliance VLAN %d\n",
   ntohs(cdp_appliance_vlan));
vlan_to_string(cdp_appliance_vlan, tmp);
-   setenv("vlan", tmp);
+   setenv_transient("vlan", tmp);
net_our_vlan = cdp_appliance_vlan;
}
 
if (cdp_native_vlan != htons(-1)) {
printf("CDP offered native VLAN %d\n", ntohs(cdp_native_vlan));
vlan_to_string(cdp_native_vlan, tmp);
-   setenv("nvlan", tmp);
+   setenv_transient("nvlan", tmp);
net_native_vlan = cdp_native_vlan;
}
 }
@@ -426,14 +426,14 @@ static int do_link_local(cmd_tbl_t *cmdtp, int flag, int 
argc,
 
net_gateway.s_addr = 0;
ip_to_string(net_gateway, tmp);
-   setenv("gatewayip", tmp);
+   setenv_transient("gatewayip", tmp);
 
ip_to_string(net_netmask, tmp);
-   setenv("netmask", tmp);
+   setenv_transient("netmask", tmp);
 
ip_to_string(net_ip, tmp);
-   setenv("ipaddr", tmp);
-   setenv("llipaddr", tmp); /* store this for next time */
+   setenv_transient("ipaddr", tmp);
+   setenv_transient("llipaddr", tmp); /* store this for next time */
 
return CMD_RET_SUCCESS;
 }
-- 
2.7.3

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

[U-Boot] [RFC PATCH 4/7] env: Introduce "transient" and "system" access flags

[Bernhard Nortmann]

"transient" (='t') is like "any", but requests that a variable
should not be exported (ENV_FLAGS_VARACCESS_PREVENT_EXPORT).

"system" (='S') is meant for 'internal' variables that
aren't supposed to be changed by the user. It corresponds
to "transient" plus "read-only".

Signed-off-by: Bernhard Nortmann 
---

 common/env_flags.c  | 11 +--
 include/env_flags.h |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/common/env_flags.c b/common/env_flags.c
index f39d952..2c30c7f 100644
--- a/common/env_flags.c
+++ b/common/env_flags.c
@@ -28,7 +28,7 @@
 #endif
 
 static const char env_flags_vartype_rep[] = "sdxb" ENV_FLAGS_NET_VARTYPE_REPS;
-static const char env_flags_varaccess_rep[] = "aroc";
+static const char env_flags_varaccess_rep[] = "aroctS";
 static const int env_flags_varaccess_mask[] = {
0,
ENV_FLAGS_VARACCESS_PREVENT_DELETE |
@@ -37,7 +37,12 @@ static const int env_flags_varaccess_mask[] = {
ENV_FLAGS_VARACCESS_PREVENT_DELETE |
ENV_FLAGS_VARACCESS_PREVENT_OVERWR,
ENV_FLAGS_VARACCESS_PREVENT_DELETE |
-   ENV_FLAGS_VARACCESS_PREVENT_NONDEF_OVERWR};
+   ENV_FLAGS_VARACCESS_PREVENT_NONDEF_OVERWR,
+   ENV_FLAGS_VARACCESS_PREVENT_EXPORT,
+   ENV_FLAGS_VARACCESS_PREVENT_DELETE |
+   ENV_FLAGS_VARACCESS_PREVENT_CREATE |
+   ENV_FLAGS_VARACCESS_PREVENT_OVERWR |
+   ENV_FLAGS_VARACCESS_PREVENT_EXPORT};
 
 #ifdef CONFIG_CMD_ENV_FLAGS
 static const char * const env_flags_vartype_names[] = {
@@ -55,6 +60,8 @@ static const char * const env_flags_varaccess_names[] = {
"read-only",
"write-once",
"change-default",
+   "transient",/* do not export/save */
+   "system",   /* = "transient" plus "read-only" */
 };
 
 /*
diff --git a/include/env_flags.h b/include/env_flags.h
index 7e2362a..9997a25 100644
--- a/include/env_flags.h
+++ b/include/env_flags.h
@@ -25,6 +25,8 @@ enum env_flags_varaccess {
env_flags_varaccess_readonly,
env_flags_varaccess_writeonce,
env_flags_varaccess_changedefault,
+   env_flags_varaccess_transient,
+   env_flags_varaccess_locked,
env_flags_varaccess_end
 };
 
-- 
2.7.3

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

[U-Boot] [RFC PATCH 2/7] net: dm: Ignore unknown env_op_* constants

[Bernhard Nortmann]

This prevents a possible compiler warning similar to
"net/eth-uclass.c::: warning: enumeration value
'env_op_*' not handled in switch [-Wswitch]".

Signed-off-by: Bernhard Nortmann 
---

 net/eth-uclass.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index c15cc4d..e38edd7 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -230,6 +230,8 @@ static int on_ethaddr(const char *name, const char *value, 
enum env_op op,
break;
case env_op_delete:
memset(pdata->enetaddr, 0, 6);
+   default:
+   break; /* ignore */
}
}
 
-- 
2.7.3

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

[U-Boot] [RFC PATCH 0/7] "Transient" (= export-restricted) environment vars

[Bernhard Nortmann]

This series evolved around the idea of introducing a new env_op
type to control (and possibly restrict) the export of variables.
This is especially useful if one wants to prevent dynamic
configuration information from ending up in a saved environment -
the 'classic' example being network setup with "dhcp" followed
by the "saveenv" command.

(The networking case is even further complicated by the fact
that users may actually wish to setup and save a static IP
configuration manually, which means that "locking up" the
corresponding variables right away isn't a viable solution.)

See also:
http://lists.denx.de/pipermail/u-boot/2015-September/227611.html
http://lists.denx.de/pipermail/u-boot/2016-April/250237.html

Regards, B. Nortmann

BTW: What the correct 'subsystem'/prefix for the "core" changes
related to env vars? patman isn't happy with my "env:" choice...


Bernhard Nortmann (7):
  env: Allow unconditional access if H_PROGRAMMATIC is set
  net: dm: Ignore unknown env_op_* constants
  env: Introduce "export" operation and (access flag) restriction
  env: Introduce "transient" and "system" access flags
  sunxi: env: flag fel_* environment vars as "system"
  env: Introduce setenv_transient() helper function
  env: Automatically mark dynamic configuration info as "do not export"

 cmd/net.c  | 34 +-
 cmd/nvedit.c   | 24 +++-
 common/env_flags.c | 21 ++---
 include/common.h   |  1 +
 include/configs/sunxi-common.h |  8 
 include/env_flags.h|  5 -
 include/search.h   |  1 +
 lib/hashtable.c|  4 
 net/eth-uclass.c   |  2 ++
 9 files changed, 78 insertions(+), 22 deletions(-)

-- 
2.7.3

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

[U-Boot] [RFC PATCH 1/7] env: Allow unconditional access if H_PROGRAMMATIC is set

[Bernhard Nortmann]

This patch modifies env_flags_validate() in such a way that any
operation will *always* be allowed if H_PROGRAMMATIC is present.

Without this change, programmatically changing environment vars
may fail depending on their flags, e.g. when trying to setenv*()
a variable that is marked "read-only".
http://lists.denx.de/pipermail/u-boot/2016-April/250237.html

Notes: H_FORCE may be insufficient for this purpose, as it can be
disabled by CONFIG_ENV_ACCESS_IGNORE_FORCE.
H_PROGRAMMATIC indicates "U-Boot internal" use. By contrast, any
user interaction (from U-Boot prompt or scripts) is expected to
be marked H_INTERACTIVE.

Signed-off-by: Bernhard Nortmann 

---

 common/env_flags.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/env_flags.c b/common/env_flags.c
index 921d377..1087f4e 100644
--- a/common/env_flags.c
+++ b/common/env_flags.c
@@ -523,6 +523,8 @@ int env_flags_validate(const ENTRY *item, const char 
*newval, enum env_op op,
}
 
/* check for access permission */
+   if (flag & H_PROGRAMMATIC)
+   return 0;
 #ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE
if (flag & H_FORCE)
return 0;
-- 
2.7.3

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

[U-Boot] SPL on ZynqMP ZCU102 evaluation board

[Oleksy, Adam (Nokia - PL/Wroclaw)]

Hi all

I'm working with zynqmp evalutation board (zcu102 revB) and currently I rely on 
FSBL generated by petalinux and I'm thinking of dropping it ans using u-boot's 
SPL. I have spent some time trying to configure and use SPL, but I've stuck on 
booting up the board.

I've prepared SD card as described here:
http://lists.denx.de/pipermail/u-boot/2016-May/254902.html

Boot process has end with following message:
 Debug uart enabled

U-Boot SPL 2016.07-rc3 (Jul 11 2016 - 13:13:28)
EL Level:   EL3
Trying to boot from MMC1
reading u-boot.bin
"Synchronous Abort" handler, esr 0x9610
ELR: fffc65d8
LR:  fffc6530
x0 : 00010eb0 x1 : 8181
x2 : 8ce8 x3 : 7ff0
x4 :  x5 : 
x6 : 7d18 x7 : 000f
x8 : 7b80 x9 : 0080
x10: 73f3 x11: 
x12:  x13: 
x14: 7d6c x15: fffd34b0
x16: 66540500c006 x17: d800b24018c0082c
x18: 7e80 x19: 0058
x20: 8d30 x21: 8d30
x22: 0210 x23: 0200
x24: 7d18 x25: fffcf000
x26: fffd9b40 x27: 0001
x28: 8521b220c0c38d88 x29: 7200

Resetting CPU ...

resetting ... 

I use u-boot 2016.07-rc3 with psu_init_gpl, which is also used in FSBL (and 
FSBL boot up board correctly). I suppose that the loading u-boot.bin to the RAM 
fails, because DDR controller is not initialized correctly. Probably I've 
forgotten enable something in .config, but I do not have idea what.
Could somebody help me with this issue?
If I forgot to add some information, please inform me.

BR,
Adam Oleksy


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

Re: [U-Boot] [PATCH] video: allow version string to be optional when using LOGO

[Anatolij Gustschin]

Hi Tim,

On Fri, 8 Jul 2016 06:45:10 -0700
Tim Harvey thar...@gateworks.com wrote:
...
> I haven't seen any feedback on this. Do you have any comment or ack?

sorry for delay, I was on vacation. Applied slightly modified patch
to u-boot-video/next.

Thanks,

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

Re: [U-Boot] [PATCH 1/2] spi: ti_qspi: Fix failure on multiple READ_ID cmd

[R, Vignesh]

On 7/11/2016 12:05 PM, Jagan Teki wrote:
> On 11 July 2016 at 11:00, Vignesh R  wrote:
>> Populating QSPI_RD_SNGL bit(0x1) in priv->cmd means that value
>> QSPI_INVAL (0x4) is not written to CMD field of QSPI_SPI_CMD_REG in
>> ti_qspi_cs_deactivate(). Therefore CS is never deactivated between
>> successive READ ID which results in sf probe to fail.
>> Fix this by not populating priv->cmd with QSPI_RD_SNGL and OR it wih
>> priv->cmd as required (similar to the convention followed in the
>> driver).
>>
>> Signed-off-by: Vignesh R 
>> ---
>>  drivers/spi/ti_qspi.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
>> index 9a372ad31dae..376fe378ed63 100644
>> --- a/drivers/spi/ti_qspi.c
>> +++ b/drivers/spi/ti_qspi.c
>> @@ -247,13 +247,12 @@ static int __ti_qspi_xfer(struct ti_qspi_priv *priv, 
>> unsigned int bitlen,
>> debug("tx done, status %08x\n", status);
>> }
>> if (rxp) {
>> -   priv->cmd |= QSPI_RD_SNGL;
>> debug("rx cmd %08x dc %08x\n",
>>   priv->cmd, priv->dc);
> 
> | QSPI_RD_SNGL on debug statement as well.

Thanks, will fix this in v2.

> 
>> #ifdef CONFIG_DRA7XX
>> udelay(500);
>> #endif
> 
> Can't we fix this delay, still need?

The patch that added this delay ( b545a98f5dc563 spi: ti_qspi: Add delay
for successful bulk erase) says its added to meet bulk erase timing
constraints (AFAIK, I believe bulk erase is same as chip erase which is
not supported by sf erase but may be supported in future). I will
experiment a bit and convince myself whether this delay is really
applicable or not.

Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] driver: fsl_qspi: disable AHB buffer prefetch

[Yunhui Cui]

From: Yunhui Cui 

Errata: A-009282: QuadSPI data pre-fetch can result in incorrect data

Signed-off-by: Yunhui Cui 
---
 drivers/spi/fsl_qspi.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 75cbab2..99634db 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -438,14 +438,24 @@ static void qspi_enable_ddr_mode(struct fsl_qspi_priv 
*priv)
 static void qspi_init_ahb_read(struct fsl_qspi_priv *priv)
 {
struct fsl_qspi_regs *regs = priv->regs;
+   int rx_size = 0x80;
 
/* AHB configuration for access buffer 0/1/2 .*/
qspi_write32(priv->flags, >buf0cr, QSPI_BUFXCR_INVALID_MSTRID);
qspi_write32(priv->flags, >buf1cr, QSPI_BUFXCR_INVALID_MSTRID);
qspi_write32(priv->flags, >buf2cr, QSPI_BUFXCR_INVALID_MSTRID);
-   qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK |
-(0x80 << QSPI_BUF3CR_ADATSZ_SHIFT));
 
+#if defined(CONFIG_LS1043A) || defined(CONFIG_LS2080A) \
+   || defined(CONFIG_LS1012A) || defined(CONFIG_LS102XA)
+   /*A-009282: QuadSPI data pre-fetch can result in incorrect data
+*Workaround: Keep the read data size to 64 bits (8 Bytes), which
+*disables the prefetch on the AHB buffer,and prevents this issue
+*from occurring.
+   */
+   rx_size = 0x1;
+#endif
+   qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK |
+(rx_size << QSPI_BUF3CR_ADATSZ_SHIFT));
/* We only use the buffer3 */
qspi_write32(priv->flags, >buf0ind, 0);
qspi_write32(priv->flags, >buf1ind, 0);
-- 
2.1.0.27.g96db324

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

[U-Boot] SPL on ZynqMP ZCU102 evaluation board

[Oleksy, Adam (Nokia - PL/Wroclaw)]

Hi all

I'm working with zynqmp evalutation board (zcu102 revB) and currently I rely on 
FSBL generated by petalinux and I'm thinking of dropping it ans using u-boot's 
SPL. I have spent some time trying to configure and use SPL, but I've stuck on 
booting up the board.

I've prepared SD card as described here:
http://lists.denx.de/pipermail/u-boot/2016-May/254902.html

Boot process has end with following message:
 Debug uart enabled

U-Boot SPL 2016.07-rc3 (Jul 11 2016 - 13:13:28)
EL Level:   EL3
Trying to boot from MMC1
reading u-boot.bin
"Synchronous Abort" handler, esr 0x9610
ELR: fffc65d8
LR:  fffc6530
x0 : 00010eb0 x1 : 8181
x2 : 8ce8 x3 : 7ff0
x4 :  x5 : 
x6 : 7d18 x7 : 000f
x8 : 7b80 x9 : 0080
x10: 73f3 x11: 
x12:  x13: 
x14: 7d6c x15: fffd34b0
x16: 66540500c006 x17: d800b24018c0082c
x18: 7e80 x19: 0058
x20: 8d30 x21: 8d30
x22: 0210 x23: 0200
x24: 7d18 x25: fffcf000
x26: fffd9b40 x27: 0001
x28: 8521b220c0c38d88 x29: 7200

Resetting CPU ...

resetting ... 

I use u-boot 2016.07-rc3 with psu_init_gpl, which is also used in FSBL. I 
suppose that the loading u-boot.bin to the RAM fails, because DDR controller is 
not initialized correctly (I can be wrong:). Probably I've forgotten enable 
something in .config, but I do not have idea what.
Could somebody help me with this issue?
If I forgot to add some information, please inform me.

BR,
Adam Oleksy

ATT78522.config
Description: ATT78522.config
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] x86: link: Correct a failure in DRAM init

[Simon Glass]

With the change to set up pinctrl after relocation, link fails to boot. Add
a special case in the link code to handle this.

Fixes: d8906c1f (x86: Probe pinctrl driver in cpu_init_r())

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/ivybridge/sdram.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
index 9d9f63d..e0b06b5 100644
--- a/arch/x86/cpu/ivybridge/sdram.c
+++ b/arch/x86/cpu/ivybridge/sdram.c
@@ -458,6 +458,11 @@ int dram_init(void)
struct udevice *dev, *me_dev;
int ret;
 
+   /* We need the pinctrl set up early */
+   ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, );
+   if (ret)
+   return ret;
+
ret = uclass_first_device_err(UCLASS_NORTHBRIDGE, );
if (ret)
return ret;
-- 
2.8.0.rc3.226.g39d4020

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

Re: [U-Boot] [PATCH v2] driver: fsl_qspi: disable AHB buffer prefetch

[york sun]

On 07/11/2016 12:49 AM, Yunhui Cui wrote:
> From: Yunhui Cui 
>
> Errata: A-009282: QuadSPI data pre-fetch can result in incorrect data
>
> Signed-off-by: Yunhui Cui 
> ---
>   drivers/spi/fsl_qspi.c | 14 --
>   1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
> index 75cbab2..99634db 100644
> --- a/drivers/spi/fsl_qspi.c
> +++ b/drivers/spi/fsl_qspi.c
> @@ -438,14 +438,24 @@ static void qspi_enable_ddr_mode(struct fsl_qspi_priv 
> *priv)
>   static void qspi_init_ahb_read(struct fsl_qspi_priv *priv)
>   {
>   struct fsl_qspi_regs *regs = priv->regs;
> + int rx_size = 0x80;
>
>   /* AHB configuration for access buffer 0/1/2 .*/
>   qspi_write32(priv->flags, >buf0cr, QSPI_BUFXCR_INVALID_MSTRID);
>   qspi_write32(priv->flags, >buf1cr, QSPI_BUFXCR_INVALID_MSTRID);
>   qspi_write32(priv->flags, >buf2cr, QSPI_BUFXCR_INVALID_MSTRID);
> - qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK |
> -  (0x80 << QSPI_BUF3CR_ADATSZ_SHIFT));
>
> +#if defined(CONFIG_LS1043A) || defined(CONFIG_LS2080A) \
> + || defined(CONFIG_LS1012A) || defined(CONFIG_LS102XA)
> + /*A-009282: QuadSPI data pre-fetch can result in incorrect data
> +  *Workaround: Keep the read data size to 64 bits (8 Bytes), which
> +  *disables the prefetch on the AHB buffer,and prevents this issue
> +  *from occurring.
> + */
> + rx_size = 0x1;
> +#endif
> + qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK |
> +  (rx_size << QSPI_BUF3CR_ADATSZ_SHIFT));
>   /* We only use the buffer3 */
>   qspi_write32(priv->flags, >buf0ind, 0);
>   qspi_write32(priv->flags, >buf1ind, 0);
>

Yunhui,

I suggested to use erratum macro, like CONFIG_SYS_FSL_ERRATUM_A009282.

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

Re: [U-Boot] drivers/crypto/fsl/Makefile: strange assignment

[Tom Rini]

On Mon, Jul 11, 2016 at 09:56:48AM -0300, Fabio Estevam wrote:
> Hi Tom,
> 
> On Fri, May 13, 2016 at 9:30 AM, Tom Rini  wrote:
> > On Thu, May 12, 2016 at 11:22:17PM -0300, Fabio Estevam wrote:
> >> On Thu, May 12, 2016 at 11:12 PM, Fabio Estevam  wrote:
> >> > Hi Raul,
> >> >
> >> > In commit 0200020bc2b8192 ("imx6: Added DEK blob generator command") you 
> >> > did:
> >> >
> >> > diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
> >> > index c0cf642..4aa91e4 100644
> >> > --- a/drivers/crypto/fsl/Makefile
> >> > +++ b/drivers/crypto/fsl/Makefile
> >> > @@ -8,5 +8,5 @@
> >> >
> >> >  obj-y += sec.o
> >> >  obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
> >> > -obj-$(CONFIG_CMD_BLOB) += fsl_blob.o
> >> > +obj-$(CONFIG_CMD_BLOB)$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
> >> >
> >> > ,which does not seem correct.
> >> >
> >> > Could you please take a look at this?
> >>
> >> Would this be a fix for this?
> >>
> >> --- a/drivers/crypto/fsl/Makefile
> >> +++ b/drivers/crypto/fsl/Makefile
> >> @@ -6,5 +6,7 @@
> >>
> >>  obj-y += sec.o
> >>  obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
> >> -obj-$(CONFIG_CMD_BLOB)$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
> >> +ifeq ($(CONFIG_CMD_BLOB),y)
> >> +obj-$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
> >> +endif
> >>  obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
> >
> > No, CMD_DEKBLOB is just broken.  It's not set anywhere in-tree so we
> > can't quite say but I suspect they want fsl_blob.o included in case of
> > either, in which case we can just duplicate the entry.
> 
> Is this what you mean?
> 
> diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
> index fd736cf..ea878e1 100644
> --- a/drivers/crypto/fsl/Makefile
> +++ b/drivers/crypto/fsl/Makefile
> @@ -6,5 +6,6 @@
> 
>  obj-y += sec.o
>  obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
> -obj-$(CONFIG_CMD_BLOB)$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
> +obj-$(CONFIG_CMD_BLOB) += fsl_blob.o
> +obj-$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
>  obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o


Yes, along with adding CMD_DEKBLOB to Kconfig so that it could be set at
all :)

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] git-mailrc: add rockchip alias

[Tom Rini]

On Sat, Jul 09, 2016 at 09:12:04PM +0800, jk wrote:

> It's easier to Cc rockchip maintainers on rockchip-releated patches.
> 
> Signed-off-by: jk 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] driver/net/fec: support fixed speed connection

[Hannes Schmelzer]

On 07/11/2016 04:23 PM, Stefano Babic wrote:

Hi Hannes,

Hi Stefano,


On 22/06/2016 12:07, Hannes Schmelzer wrote:

If MAC is directly connected to another MAC (like a switch for example)
we don't need to probe for a phy, autoneogation and so on. We simply
have to setup speed.

Signed-off-by: Hannes Schmelzer 
---

  doc/README.fec_mxc| 5 +
  drivers/net/fec_mxc.c | 4 
  2 files changed, 9 insertions(+)

diff --git a/doc/README.fec_mxc b/doc/README.fec_mxc
index ed7e47d..9ca6ac2 100644
--- a/doc/README.fec_mxc
+++ b/doc/README.fec_mxc
@@ -27,6 +27,11 @@ CONFIG_FEC_MXC_PHYADDR
Optional, selects the exact phy address that should be connected
and function fecmxc_initialize will try to initialize it.
  
+CONFIG_FEC_FIXED_SPEED

+   Optional, selects a fixed speed on the MAC interface without asking some
+   phy. This is usefull if there is a direct MAC <-> MAC connection, for
+   example if the CPU is connected directly via the RGMII interface to a
+   ethernet-switch.
  
  Reading the ethaddr from the SoC eFuses:

  if CONFIG_FEC_MXC is defined and the U-Boot environment does not contain the
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 360f8e4..e871b3e 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -233,6 +233,7 @@ static int miiphy_restart_aneg(struct eth_device *dev)
return ret;
  }
  
+#ifndef CONFIG_FEC_FIXED_SPEED

  static int miiphy_wait_aneg(struct eth_device *dev)
  {
uint32_t start;
@@ -260,6 +261,7 @@ static int miiphy_wait_aneg(struct eth_device *dev)
  
  	return 0;

  }
+#endif /* CONFIG_FEC_FIXED_SPEED */
  #endif
  
  static int fec_rx_task_enable(struct fec_priv *fec)

@@ -502,6 +504,8 @@ static int fec_open(struct eth_device *edev)
}
speed = fec->phydev->speed;
}
+#elif CONFIG_FEC_FIXED_SPEED
+   speed = CONFIG_FEC_FIXED_SPEED;
  #else
miiphy_wait_aneg(edev);
speed = miiphy_speed(edev->name, fec->phy_id);



Really I had already sent a patch for this issue, and I merged this into
u-boot-imx, - next

http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=57b7371e24e429ee37403cfb084d142cf7699bd7

Anyway, your patch is more complete as mine. I will drop my patch and
substitute with your.

many thanks, looking forward for getting merged into u-boot master.


Best regards,
Stefano Babic

cheers,
Hannes
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, for, v2016.07] mkimage -l is broken for images after gpimage

[Tom Rini]

On Mon, Jul 11, 2016 at 04:09:48PM +0200, Stefano Babic wrote:

> Because a gpimage cannot be detected, a false
> GP header is printed instead of checking
> for further image types.
> 
> Move gpimage as last to be linked, letting check
> all other image types and printing a GP header just
> in case no image is detected.
> 
> Signed-off-by: Stefano Babic 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,for,v2016.07] doc: ARMv8: add README.pine64

[Tom Rini]

On Fri, Jul 08, 2016 at 03:25:23PM +0100, Andre Przywara wrote:

> Since we lack information about the DRAM initialization for the
> Allwinner A64 SoC, booting any A64 based board like the Pine64 is a bit
> involved at the moment.
> Add a README file to explain the process.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Tom Rini 

Moved to board/sunxi/ and applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] imx6: clock: typo fix

[Stefano Babic]

On 30/06/2016 15:08, Peng Fan wrote:
> Typo fix, "PPL2 -> PLL2"
> 
> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> ---
>  arch/arm/cpu/armv7/mx6/clock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
> index ff932aa..9b4b69c 100644
> --- a/arch/arm/cpu/armv7/mx6/clock.c
> +++ b/arch/arm/cpu/armv7/mx6/clock.c
> @@ -281,7 +281,7 @@ static u32 mxc_get_pll_pfd(enum pll_clocks pll, int 
> pfd_num)
>   case PLL_BUS:
>   if (!is_mx6ul()) {
>   if (pfd_num == 3) {
> - /* No PFD3 on PPL2 */
> + /* No PFD3 on PLL2 */
>   return 0;
>   }
>   }
> 

Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] arch-mx6: fix MX6_PAD_DECLARE macro to work with MX6 duallite

[Otavio Salvador]

On Wed, Jun 22, 2016 at 7:07 AM, Hannes Schmelzer  wrote:
> if we build for an i.mx6 (d)ual(l)ite CONFIC_MX6DL we shall use
> MX6DL_PAD instead the common MX6_PAD.
>
> Signed-off-by: Hannes Schmelzer 

Please put this for the current release; this is a bugfix and a critical one.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arch-mx6: fix MX6_PAD_DECLARE macro to work with MX6 duallite

[Stefano Babic]

On 22/06/2016 12:07, Hannes Schmelzer wrote:
> if we build for an i.mx6 (d)ual(l)ite CONFIC_MX6DL we shall use
> MX6DL_PAD instead the common MX6_PAD.
> 
> Signed-off-by: Hannes Schmelzer 
> ---
> 
>  arch/arm/include/asm/arch-mx6/mx6-pins.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-mx6/mx6-pins.h 
> b/arch/arm/include/asm/arch-mx6/mx6-pins.h
> index 4b6bb18..3465205 100644
> --- a/arch/arm/include/asm/arch-mx6/mx6-pins.h
> +++ b/arch/arm/include/asm/arch-mx6/mx6-pins.h
> @@ -18,7 +18,7 @@ enum {
>  #include "mx6q_pins.h"
>  #undef MX6_PAD_DECL
>  #define MX6_PAD_DECL(name, pco, mc, mm, sio, si, pc) \
> - MX6_PAD_DECLARE(MX6DL_PAD_,name, pco, mc, mm, sio, si, pc),
> + MX6_PAD_DECLARE(MX6DL_PAD_, name, pco, mc, mm, sio, si, pc),
>  #include "mx6dl_pins.h"
>  };
>  #elif defined(CONFIG_MX6Q)
> @@ -30,7 +30,7 @@ enum {
>  #elif defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
>  enum {
>  #define MX6_PAD_DECL(name, pco, mc, mm, sio, si, pc) \
> - MX6_PAD_DECLARE(MX6_PAD_,name, pco, mc, mm, sio, si, pc),
> + MX6_PAD_DECLARE(MX6DL_PAD_, name, pco, mc, mm, sio, si, pc),
>  #include "mx6dl_pins.h"
>  };
>  #elif defined(CONFIG_MX6SL)
> 

Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] driver/net/fec: support fixed speed connection

[Stefano Babic]

Hi Hannes,

On 22/06/2016 12:07, Hannes Schmelzer wrote:
> If MAC is directly connected to another MAC (like a switch for example)
> we don't need to probe for a phy, autoneogation and so on. We simply
> have to setup speed.
> 
> Signed-off-by: Hannes Schmelzer 
> ---
> 
>  doc/README.fec_mxc| 5 +
>  drivers/net/fec_mxc.c | 4 
>  2 files changed, 9 insertions(+)
> 
> diff --git a/doc/README.fec_mxc b/doc/README.fec_mxc
> index ed7e47d..9ca6ac2 100644
> --- a/doc/README.fec_mxc
> +++ b/doc/README.fec_mxc
> @@ -27,6 +27,11 @@ CONFIG_FEC_MXC_PHYADDR
>   Optional, selects the exact phy address that should be connected
>   and function fecmxc_initialize will try to initialize it.
>  
> +CONFIG_FEC_FIXED_SPEED
> + Optional, selects a fixed speed on the MAC interface without asking some
> + phy. This is usefull if there is a direct MAC <-> MAC connection, for
> + example if the CPU is connected directly via the RGMII interface to a
> + ethernet-switch.
>  
>  Reading the ethaddr from the SoC eFuses:
>  if CONFIG_FEC_MXC is defined and the U-Boot environment does not contain the
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index 360f8e4..e871b3e 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -233,6 +233,7 @@ static int miiphy_restart_aneg(struct eth_device *dev)
>   return ret;
>  }
>  
> +#ifndef CONFIG_FEC_FIXED_SPEED
>  static int miiphy_wait_aneg(struct eth_device *dev)
>  {
>   uint32_t start;
> @@ -260,6 +261,7 @@ static int miiphy_wait_aneg(struct eth_device *dev)
>  
>   return 0;
>  }
> +#endif /* CONFIG_FEC_FIXED_SPEED */
>  #endif
>  
>  static int fec_rx_task_enable(struct fec_priv *fec)
> @@ -502,6 +504,8 @@ static int fec_open(struct eth_device *edev)
>   }
>   speed = fec->phydev->speed;
>   }
> +#elif CONFIG_FEC_FIXED_SPEED
> + speed = CONFIG_FEC_FIXED_SPEED;
>  #else
>   miiphy_wait_aneg(edev);
>   speed = miiphy_speed(edev->name, fec->phy_id);
> 


Really I had already sent a patch for this issue, and I merged this into
u-boot-imx, - next

http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=57b7371e24e429ee37403cfb084d142cf7699bd7

Anyway, your patch is more complete as mine. I will drop my patch and
substitute with your.

Best regards,
Stefano Babic


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

[U-Boot] [PATCH for v2016.07] mkimage -l is broken for images after gpimage

[Stefano Babic]

Because a gpimage cannot be detected, a false
GP header is printed instead of checking
for further image types.

Move gpimage as last to be linked, letting check
all other image types and printing a GP header just
in case no image is detected.

Signed-off-by: Stefano Babic 
---
 tools/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index 63355aa..f72294a 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -76,8 +76,6 @@ dumpimage-mkimage-objs := aisimage.o \
lib/fdtdec.o \
fit_common.o \
fit_image.o \
-   gpimage.o \
-   gpimage-common.o \
common/image-fit.o \
image-host.o \
common/image.o \
@@ -100,6 +98,8 @@ dumpimage-mkimage-objs := aisimage.o \
zynqimage.o \
zynqmpimage.o \
$(LIBFDT_OBJS) \
+   gpimage.o \
+   gpimage-common.o \
$(RSA_OBJS-y)
 
 dumpimage-objs := $(dumpimage-mkimage-objs) dumpimage.o
-- 
1.9.1

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

Re: [U-Boot] [PATCH] pico-imx6ul: Add USB Host support

[Stefano Babic]

On 11/07/2016 14:41, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Mon, Jun 13, 2016 at 1:49 PM, Fabio Estevam  wrote:
>> On Mon, Jun 13, 2016 at 1:01 PM, Vanessa Maegima
>>  wrote:
>>> Add USB host support.
>>>
>>> Tested by connecting a USB pen drive:
>>>
>>> => usb start
>>> starting USB...
>>> USB0:   Port not available.
>>> USB1:   USB EHCI 1.00
>>> scanning bus 1 for devices... 2 USB Device(s) found
>>>scanning usb for storage devices... 1 Storage Device(s) found
>>>
>>> Signed-off-by: Vanessa Maegima 
>>
>> Reviewed-by: Fabio Estevam 
> 
> Looks like this one did not go into your -next branch yet.
> 
> Please consider applying it if you are happy with it.
> 

Ok, thnaks - I will push it.

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
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] sunxi: Add support for multiple ethadrr-esses

[Ian Campbell]

On Mon, 2016-07-11 at 11:02 +0200, Hans de Goede wrote:
> > On Sat, 2016-07-09 at 15:12 +0200, Hans de Goede wrote:
> > > 
> > > [...]
> > > +static void setup_environment(const void *fdt)
> > 
> > It might be worth adding a commit to this function noting that it
> > must
> > remain idempotent.
> 
> Done, although I avoided the use of the word idempotent, I had to google
> it to make sure it meant what I thought it meant, so using a simpler
> description for us non native Enlgish speakers seemed better :)

Fair enough.

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

Re: [U-Boot] drivers/crypto/fsl/Makefile: strange assignment

[Fabio Estevam]

Hi Tom,

On Fri, May 13, 2016 at 9:30 AM, Tom Rini  wrote:
> On Thu, May 12, 2016 at 11:22:17PM -0300, Fabio Estevam wrote:
>> On Thu, May 12, 2016 at 11:12 PM, Fabio Estevam  wrote:
>> > Hi Raul,
>> >
>> > In commit 0200020bc2b8192 ("imx6: Added DEK blob generator command") you 
>> > did:
>> >
>> > diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
>> > index c0cf642..4aa91e4 100644
>> > --- a/drivers/crypto/fsl/Makefile
>> > +++ b/drivers/crypto/fsl/Makefile
>> > @@ -8,5 +8,5 @@
>> >
>> >  obj-y += sec.o
>> >  obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
>> > -obj-$(CONFIG_CMD_BLOB) += fsl_blob.o
>> > +obj-$(CONFIG_CMD_BLOB)$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
>> >
>> > ,which does not seem correct.
>> >
>> > Could you please take a look at this?
>>
>> Would this be a fix for this?
>>
>> --- a/drivers/crypto/fsl/Makefile
>> +++ b/drivers/crypto/fsl/Makefile
>> @@ -6,5 +6,7 @@
>>
>>  obj-y += sec.o
>>  obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
>> -obj-$(CONFIG_CMD_BLOB)$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
>> +ifeq ($(CONFIG_CMD_BLOB),y)
>> +obj-$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
>> +endif
>>  obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
>
> No, CMD_DEKBLOB is just broken.  It's not set anywhere in-tree so we
> can't quite say but I suspect they want fsl_blob.o included in case of
> either, in which case we can just duplicate the entry.

Is this what you mean?

diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
index fd736cf..ea878e1 100644
--- a/drivers/crypto/fsl/Makefile
+++ b/drivers/crypto/fsl/Makefile
@@ -6,5 +6,6 @@

 obj-y += sec.o
 obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
-obj-$(CONFIG_CMD_BLOB)$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
+obj-$(CONFIG_CMD_BLOB) += fsl_blob.o
+obj-$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
 obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/3] COSMETIC: mmc: sdhci: Add CONFIG_ prefix to SDHCI_READ_STATUS_TIMEOUT

[Lukasz Majewski]

This change gives common prefix for SDHCI_READ_STATUS_TIMEOUT.

Signed-off-by: Lukasz Majewski 
---
 drivers/mmc/sdhci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 604f18d..aa4cd4f 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -127,7 +127,7 @@ static int sdhci_transfer_data(struct sdhci_host *host, 
struct mmc_data *data,
 #define CONFIG_SDHCI_CMD_MAX_TIMEOUT   3200
 #endif
 #define CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT   100
-#define SDHCI_READ_STATUS_TIMEOUT  1000
+#define CONFIG_SDHCI_READ_STATUS_TIMEOUT   1000
 
 static int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
   struct mmc_data *data)
@@ -244,9 +244,9 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
if (stat & SDHCI_INT_ERROR)
break;
} while (((stat & mask) != mask) &&
-(get_timer(start) < SDHCI_READ_STATUS_TIMEOUT));
+(get_timer(start) < CONFIG_SDHCI_READ_STATUS_TIMEOUT));
 
-   if (get_timer(start) >= SDHCI_READ_STATUS_TIMEOUT) {
+   if (get_timer(start) >= CONFIG_SDHCI_READ_STATUS_TIMEOUT) {
if (host->quirks & SDHCI_QUIRK_BROKEN_R1B)
return 0;
else {
-- 
2.0.0.rc2

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

[U-Boot] [PATCH 2/3] FIX: mmc: sdhci: Board specific definitions for SDHCI CMD and READ TIMEOUTS

[Lukasz Majewski]

For some boards - e.g. odroid u3, it is necessary to adjust manually those
two timeouts.

Exynos4 based boards, which use SDHCI controller to read data from SD cards,
have SDHCI_QUIRK_BROKEN_R1B flag set. This quirk requires short timeout
values, since in fact it relies on timeout exit, because the controller is
not able to read status bit properly for this kind of response.

Change: 29905a451b7ecf86785a4404e926fb14a8daced3, introduced longer timeouts
for boards with SDHCI_QUIRK_BROKEN_R1B, which resulted in write speed
regression (to ext4 fs via DFU):

Before (31 MiB test file):
32505856 bytes written in 4342 ms (7.1 MiB/s)

After this change:
32505856 bytes written in 20466 ms (1.5 MiB/s)

Such performance regression caused timeouts during DFU write (observed at
HWT test setup).

This commit, however introduces possibility to define different timeout
values for SDHCI mmc IP blocks embedded in different SoCs (and boards).

This problem was observed only in SDHCI controller, when target board was
running solely from SD card.

Signed-off-by: Lukasz Majewski 
---
 drivers/mmc/sdhci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index aa4cd4f..9f38ecb 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -126,8 +126,12 @@ static int sdhci_transfer_data(struct sdhci_host *host, 
struct mmc_data *data,
 #ifndef CONFIG_SDHCI_CMD_MAX_TIMEOUT
 #define CONFIG_SDHCI_CMD_MAX_TIMEOUT   3200
 #endif
+#ifndef CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT
 #define CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT   100
+#endif
+#ifndef CONFIG_SDHCI_READ_STATUS_TIMEOUT
 #define CONFIG_SDHCI_READ_STATUS_TIMEOUT   1000
+#endif
 
 static int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
   struct mmc_data *data)
-- 
2.0.0.rc2

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

[U-Boot] [PATCH 3/3] FIX: mmc: sdhci: exynos4: Define smaller SDHCI timeouts for Exynos4 based boards

[Lukasz Majewski]

Those values are necessary to provide SDHCI controller SD card write speed
comparable to those before introducing the commit:
29905a451b7ecf86785a4404e926fb14a8daced3.

Such adjustments are required on boards with SDHCI's SDHCI_QUIRK_BROKEN_R1B
quirk flag set.

Signed-off-by: Lukasz Majewski 
---
 include/configs/exynos4-common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/exynos4-common.h b/include/configs/exynos4-common.h
index fbe0fa9..9cf2d2d 100644
--- a/include/configs/exynos4-common.h
+++ b/include/configs/exynos4-common.h
@@ -21,6 +21,8 @@
 /* SD/MMC configuration */
 #define CONFIG_MMC_SDMA
 #define CONFIG_MMC_DEFAULT_DEV 0
+#define CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT 10
+#define CONFIG_SDHCI_READ_STATUS_TIMEOUT 5
 
 #undef CONFIG_CMD_ONENAND
 #undef CONFIG_CMD_MTDPARTS
-- 
2.0.0.rc2

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

Re: [U-Boot] [PATCH] pico-imx6ul: Add USB Host support

[Fabio Estevam]

Hi Stefano,

On Mon, Jun 13, 2016 at 1:49 PM, Fabio Estevam  wrote:
> On Mon, Jun 13, 2016 at 1:01 PM, Vanessa Maegima
>  wrote:
>> Add USB host support.
>>
>> Tested by connecting a USB pen drive:
>>
>> => usb start
>> starting USB...
>> USB0:   Port not available.
>> USB1:   USB EHCI 1.00
>> scanning bus 1 for devices... 2 USB Device(s) found
>>scanning usb for storage devices... 1 Storage Device(s) found
>>
>> Signed-off-by: Vanessa Maegima 
>
> Reviewed-by: Fabio Estevam 

Looks like this one did not go into your -next branch yet.

Please consider applying it if you are happy with it.

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

Re: [U-Boot] [PATCH 2/3] ARM: board: cm_fx6: fixup mtd partitions in the fdt

[Christopher Spinrath]

Hi Nikita,

On 10.07.2016 09:52, Nikita Kiryanov wrote:

Hi Christopher,

On Thu, Jul 07, 2016 at 03:30:25PM +0200, Christopher Spinrath wrote:

Hi Nikita,

On 07/07/2016 10:53 AM, Nikita Kiryanov wrote:

On Wed, Jun 22, 2016 at 07:17:53PM +0300, Igor Grinberg wrote:

On 06/19/2016 06:44 PM, Christopher Spinrath wrote:

The cm-fx6 module has an on-board st,m25p compatible spi flash chip
used for u-boot (binary & environment). Overwrite the partitions in
the device tree by the partition table provided in the mtdparts
environment variable, if it is set.

This allows to specify a kernel independent partitioning in the
environment and provides a convient way for the user to adapt the
partition table.

Signed-off-by: Christopher Spinrath 
---
  board/compulab/cm_fx6/cm_fx6.c | 16 +++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
index 712057a..81a7ae2 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c


[...]


+#ifdef CONFIG_FDT_FIXUP_PARTITIONS
+struct node_info nodes[] = {
+   { "st,m25p",  MTD_DEV_TYPE_NOR,   },


Nikita, is this enough for all flashes we assemble on cm-fx6?


Yes, CM-FX6 is using M25PX16 and SST25VF016B, both of which are
supported by the m25p80.c driver. However, on the mainline branch
I don't see "m25p" in the list of device ids, and IIRC the request
is to favor "jedec,spi-nor" as compatible string over device specific
ones.


Linux is going to use "st,m25p", "jedec,spi-nor" as compatible list
(currently queued for inclusion in v4.8:
https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/tree/arch/arm/boot/dts/imx6q-cm-fx6.dts?h=next/dt#n123
).

I have chosen "st,m25p" here to cover both the mainline and CompuLab's
device trees (I have seen some where "jedec,spi-nor" is not in the
list). However, if you prefer I will switch to "jedec,spi-nor"
(excluding some device trees) in v2.


Does it have to be an "or" situation? m25p is necessary to serve older CM-FX6
kernels, but it is not supported in the mainline kernel, so the correct
course of actions seems to be to use both "st,m25p" and "jedec,spi-nor".


This has nothing to do with the kernel itself; the compatible is only 
used to find the correct dt node describing the flash chip and as I said 
in my previous email, the upstream device tree node is going to have the 
st,m25p compatible string.


On the other hand, m25p is not documented but it used to be in upstream 
device trees. Since it has been removed from most of them recently, I 
agree that having both compatibles is a good idea. From a quick look at 
the source code it should be possible. I will verify this for v2.


Thanks,
Christopher
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img

[Otavio Salvador]

On Mon, Jul 11, 2016 at 3:51 AM, Alexey Brodkin
 wrote:
> On Sat, 2016-07-09 at 10:02 -0300, Otavio Salvador wrote:
>> On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin
>>  wrote:
>> >
>> > Recently I started to notice that u-boot.img built for Wandboard
>> > by some toolchains becomes so large that it basically overlaps with
>> > U-Boot environment area on SD-card.
>> >
>> > According to
>> > http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout
>> > Wandboard's SD-card layout is as follows:
>> > -->8---
>> > ==
>> > 1. 0x   Reserved For MBR
>> > 2. 0x0200   512 Secondary Image Table (optional)
>> > 3. 0x0400   1024uBoot Image (Starting From IVT)
>> > 4. 0x0006   393216  start of uboot env (size:8k)
>> > 5. 0x00062000   end of uboot env
>> > 6. 0x0010   1048576 Linux kernel start
>> > 7. 0x0076AC00   280 start of partition 1
>> > -->8---
>> >
>> > So for U-Boot we have 383kB (392192 bytes).
>> >
>> > But in up to date U-Boot for Wandboard we build separately
>> >  a) SPL
>> >  b) u-boot.img
>> >
>> > which gives us a bit more detailed SD-card layout:
>> > -->8---
>> > ==
>> > 1. 0x   Reserved For MBR
>> > 2. 0x0200   512 Secondary Image Table (optional)
>> > 3. 0x0400   1024SPL
>> > 4. 0x00011400   70656   u-boot.img
>> > 5. 0x0006   393216  start of uboot env (size:8k)
>> > 6. 0x00062000   end of uboot env
>> > ...
>> > -->8---
>> >
>> > From that layout we may calculate amount of space reserved for
>> > u-boot.img. It's just 315kb (322560 bytes).
>> >
>> > Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced
>> > u-boot.img is already more than we expected
>> > (323840 bytes instead of "< 322560"):
>> > -->8---
>> > ls -la u-boot.img
>> > -rw-rw-r-- 1 user user 323840 Jul  5 07:38 u-boot.img
>> > -->8---
>> >
>> > Funny enough if I rebuild U-Boot with ARM toolchain available in
>> > my Fedora 23 distro u-boot.img becomes a little bit smaller:
>> > -->8---
>> > ls -la u-boot.img
>> > -rw-rw-r-- 1 user user 322216 Jul  5 07:39 u-boot.img
>> > -->8---
>> >
>> > What's worse this problem might not affect people most of the time
>> > because what happens people would just copy u-boot.img on SD-card and
>> > live in happiness with it... well until somebody attempts to save
>> > environment in U-Boot with "saveenv" command which will simply
>> > overwrite the very end of u-boot.img.
>> > That will lead to unusable SD-card until user dd u-boot.img on
>> > SD-card again.
>> >
>> > I may foresee this issue in the future to become more visible once we
>> > add more features in U-Boot for Wandboard or just existing code base
>> > becomes bulkier and people will consistently get larger u-boot.img
>> > files produced.
>> >
>> > IMHO there's an obvious solution for all that - just move U-Boot's env
>> > to the very end of the gap between U-Boot and the first real partition
>> > on the SD-card. This patch will follow
>> > 8fb9eea5653796 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'").
>> > So env is still not in the very end of the gap (obviously 256kb is way
>> > too much for U-Boot's env) but at least we have now the same
>> > partitioning for i.MX6 boards.
>> >
>> > Signed-off-by: Alexey Brodkin 
>> > Cc: Fabio Estevam 
>> > Cc: Otavio Salvador 
>> > Cc: Peter Robinson 
>> > Cc: Tom Rini 
>> > Cc: Peter Korsgaard 
>> > Cc: Wolfgang Denk 
>>
>> Couldn't this be done on the common header?
>
> It could be done but that's not so straight-forward.
> See not all boards that use "mx6_common.h" store U-Boot's environment
> on SD card. There're ones that put env in SPI flash ("cm_fx6", "aristainetos"
> etc). Moreover some "include/configs/XXX.h" files put "mx6_common.h" in
> the very beginning some in the middle, some in the very end. I.e. we cannot 
> rely
> on "#ifdef CONFIG_ENV_IS_IN_MMC" - it might be defined later easily.
>
> That means if we move CONFIG_ENV_OFFSET in "mx6_common.h" we'll need to wrap
> CONFIG_ENV_OFFSET on some boards with #undef to allow them to override 
> ENV_OFFSET.
>
> IMHO better solution would be as Tom suggested to move all ENV related things 
> in
> Kconfig and there we'll be able to handle it more gracefully.

Great; I agree.

Acked-by: 

[U-Boot] [PATCH] bootm: fixup silent Linux out of BOOTM_STATE_LOADOS state

[Hector Palacios]

The function fixup_silent_linux() is called in status BOOTM_STATE_LOADOS
to silence Linux if variable 'silent' is set.
Currently only the 'bootm' command state machine contains
BOOTM_STATE_LOADOS, but others like 'booti' or 'bootz' commands do not.
This means silent Linux does not work with these commands.

This patch moves the fixup_silent_linux() call out of the
BOOTM_STATE_LOADOS state and into BOOTM_STATE_OS_PREP, to silence Linux
independently of the used command (booti, bootm or bootz).

Signed-off-by: Hector Palacios 
---
 common/bootm.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/common/bootm.c b/common/bootm.c
index 81a522eec348..521468c1ecd0 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -668,10 +668,6 @@ int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[],
goto err;
else if (ret == BOOTM_ERR_OVERLAP)
ret = 0;
-#if defined(CONFIG_SILENT_CONSOLE) && !defined(CONFIG_SILENT_U_BOOT_ONLY)
-   if (images->os.os == IH_OS_LINUX)
-   fixup_silent_linux();
-#endif
}
 
/* Relocate the ramdisk */
@@ -711,13 +707,19 @@ int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[],
return 1;
}
 
+
/* Call various other states that are not generally used */
if (!ret && (states & BOOTM_STATE_OS_CMDLINE))
ret = boot_fn(BOOTM_STATE_OS_CMDLINE, argc, argv, images);
if (!ret && (states & BOOTM_STATE_OS_BD_T))
ret = boot_fn(BOOTM_STATE_OS_BD_T, argc, argv, images);
-   if (!ret && (states & BOOTM_STATE_OS_PREP))
+   if (!ret && (states & BOOTM_STATE_OS_PREP)) {
+#if defined(CONFIG_SILENT_CONSOLE) && !defined(CONFIG_SILENT_U_BOOT_ONLY)
+   if (images->os.os == IH_OS_LINUX)
+   fixup_silent_linux();
+#endif
ret = boot_fn(BOOTM_STATE_OS_PREP, argc, argv, images);
+   }
 
 #ifdef CONFIG_TRACE
/* Pretend to run the OS, then run a user command */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] rockchip: add basic support for evb-rk3288 board

[Ziyuan Xu]

From: Xu Ziyuan 

evb-3288 board RK3288-based development board with 2 USB ports, HDMI,
VGA, micro-SD card, audio, WiFi and Gigabit Ethernet. It also includes
on-board 8G eMMC and 2GB of SDRAM. Expansion connector provide access to
display pins, I2C, SPI, UART and GPIOs. This add some basic files
required to allow the board to output serial messaged and can run
command(mmc info etc).

evb-rk3288 also supports booting from eMMC or SD card, the default is eMMC.

Signed-off-by: Ziyuan Xu 
Reviewed-by: Simon Glass 
---

Changes in v2:
- Fix a comment nit
- Add reviewed flag from Simon

 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/rk3288-evb.dts   |  59 +
 arch/arm/dts/rk3288-evb.dtsi  | 379 ++
 arch/arm/mach-rockchip/rk3288-board-spl.c |   4 +-
 arch/arm/mach-rockchip/rk3288/Kconfig |  10 +
 board/evb-rk3288/evb-rk3288/Kconfig   |  15 ++
 board/evb-rk3288/evb-rk3288/MAINTAINERS   |   6 +
 board/evb-rk3288/evb-rk3288/Makefile  |   7 +
 board/evb-rk3288/evb-rk3288/evb-rk3288.c  |  15 ++
 configs/evb-rk3288_defconfig  |  67 ++
 doc/README.rockchip   |   3 +-
 include/configs/evb-rk3288.h  |  26 ++
 12 files changed, 590 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/rk3288-evb.dts
 create mode 100644 arch/arm/dts/rk3288-evb.dtsi
 create mode 100644 board/evb-rk3288/evb-rk3288/Kconfig
 create mode 100644 board/evb-rk3288/evb-rk3288/MAINTAINERS
 create mode 100644 board/evb-rk3288/evb-rk3288/Makefile
 create mode 100644 board/evb-rk3288/evb-rk3288/evb-rk3288.c
 create mode 100644 configs/evb-rk3288_defconfig
 create mode 100644 include/configs/evb-rk3288.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5d463ce..493b9da 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -31,6 +31,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-firefly.dtb \
rk3288-jerry.dtb \
rk3288-rock2-square.dtb \
+   rk3288-evb.dtb \
rk3036-sdk.dtb
 dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-odroidc2.dtb
diff --git a/arch/arm/dts/rk3288-evb.dts b/arch/arm/dts/rk3288-evb.dts
new file mode 100644
index 000..caf24ee
--- /dev/null
+++ b/arch/arm/dts/rk3288-evb.dts
@@ -0,0 +1,59 @@
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+ X11
+ */
+
+/dts-v1/;
+#include "rk3288-evb.dtsi"
+
+/ {
+   model = "Evb-RK3288";
+   compatible = "evb-rk3288,evb-rk3288", "rockchip,rk3288";
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   rockchip,num-channels = <2>;
+   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+   0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+   0x8 0x1f4>;
+   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+   0x0 0xc3 0x6 0x2>;
+   rockchip,sdram-channel = /bits/ 8 <0x2 0xa 0x3 0x2 0x2 0x0 0xe 0xe>;
+   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   reg-shift = <2>;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3288-evb.dtsi b/arch/arm/dts/rk3288-evb.dtsi
new file mode 100644
index 000..cb7d03e
--- /dev/null
+++ b/arch/arm/dts/rk3288-evb.dtsi
@@ -0,0 +1,379 @@
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+ X11
+ */
+
+#include "rk3288.dtsi"
+
+/ {
+   memory {
+   reg = <0 0x8000>;
+   };
+
+   keys: gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   button@0 {
+   gpio-key,wakeup = <1>;
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   label = "GPIO Power";
+   linux,code = <116>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_key>;
+   };
+   };
+
+   vcc_sys: vsys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   vcc_flash: flash-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_flash";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = 

Re: [U-Boot] [PATCH 1/4] sunxi: Use BROM stored boot_media value to determine our boot-source

[Hans de Goede]

Hi,

On 10-07-16 10:17, Ian Campbell wrote:

On Sat, 2016-07-09 at 22:22 +0200, Hans de Goede wrote:

Now that we know that the BROM stores a value indicating the boot-
source
at the beginning of SRAM, use that instead of trying to recreate the
BROM's boot probing.

Signed-off-by: Hans de Goede 


All 4 patches:
Acked-by: Ian Campbell 

You might want to s/3th/3rd/ in the third patch's description.


Done.

Thanks for all the reviews.

Regards,

Hans

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

Re: [U-Boot] [PATCH v2] sunxi: Add support for multiple ethadrr-esses

[Hans de Goede]

Hi,

On 10-07-16 10:15, Ian Campbell wrote:

On Sat, 2016-07-09 at 15:12 +0200, Hans de Goede wrote:

Currently we fill ethaddr with a fixed unique address based on the
SoCs
serial (from the sid) to make sure that boards which use the
integrated
emac / gmac get a fixed mac rather then a random one.

On some boards the wifi does not come with a fixed mac either, so we
need
to also set eth1addr.

This commit changes the ethaddr setting code to check for ethernet%d
aliases (as fdt_fixup_ethernet does) and set an ethaddr variable for
all present aliases.

Signed-off-by: Hans de Goede 


Acked-by: Ian Campbell 


[...]
+static void setup_environment(const void *fdt)


It might be worth adding a commit to this function noting that it must
remain idempotent.


Done, although I avoided the use of the word idempotent, I had to google
it to make sure it meant what I thought it meant, so using a simpler
description for us non native Enlgish speakers seemed better :)

Regards,

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

Re: [U-Boot] [PATCH] driver: fsl_qspi: disable AHB buffer prefetch

[Yunhui Cui]

On 07/07/2016 10:55 PM, York wrote:
> On 07/07/2016 12:52 AM, Yunhui Cui wrote:
> >
> >> On 07/07/2016 1:01 AM, york sun wrote:
> >> On 07/03/2016 08:27 PM, Yunhui Cui wrote:
> >>> From: Yunhui Cui 
> >>>
> >>> A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect
> >>> data
> >>> Affects: QuadSPI
> >>> Description: With AHB buffer prefetch enabled, the QuadSPI may
> >>> return incorrect data on the AHB interface. The buffer pre-fetch is
> >>> enabled if the fetch size as configured either in the LUT or in the
> >>> BUFxCR register is greater than 8 bytes.
> >>> Impact: Only 64 bit read allowed.
> >>> Workaround: Keep the read data size to 64 bits (8 Bytes), which
> >>> disables the prefetch on the AHB buffer, and prevents this issue
> >>> from occurring.
> >>>
> >>> Signed-off-by: Yunhui Cui 
> >>> ---
> >>>drivers/spi/fsl_qspi.c | 2 +-
> >>>1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
> >>> 75cbab2..e0a002d 100644
> >>> --- a/drivers/spi/fsl_qspi.c
> >>> +++ b/drivers/spi/fsl_qspi.c
> >>> @@ -444,7 +444,7 @@ static void qspi_init_ahb_read(struct
> >>> fsl_qspi_priv
> >> *priv)
> >>>   qspi_write32(priv->flags, >buf1cr,
> >> QSPI_BUFXCR_INVALID_MSTRID);
> >>>   qspi_write32(priv->flags, >buf2cr,
> >> QSPI_BUFXCR_INVALID_MSTRID);
> >>>   qspi_write32(priv->flags, >buf3cr,
> QSPI_BUF3CR_ALLMST_MASK |
> >>> -  (0x80 << QSPI_BUF3CR_ADATSZ_SHIFT));
> >>> +  (0x1 << QSPI_BUF3CR_ADATSZ_SHIFT));
> >>>
> >>>   /* We only use the buffer3 */
> >>>   qspi_write32(priv->flags, >buf0ind, 0);
> >>>
> >>
> >> Yunhui,
> >>
> >> We handle erratum workaround using macros in case the workaround has
> >> impact on other SoCs.
> >
> > [Yunhui] For now, all SoCs with Qspi module need this errata.
> 
> I still think it is better to gate the workaround with #ifdef in case we
> need to disable it for future SoCs. It will also be easier to locate the
> workaround code.

[Yunhui] ok, I will update it in v2, thanks.

> 
> >
> >> We also put the erratum information either in a
> >> README file, or inline comment. It will be easier to read the code
> later.
> >
> > [Yunhui] ok, I will add inline comment in next version.
> >
> >> You don't have to put the whole erratum description in the commit
> message,
> >> as long as it explains what this patch does and refer the erratum
> number
> >> somewhere in the message so we can search the git log.
> >>
> >> York
> >
> > [Yunhui] ok, I will update the commit message in next version.
> >
> 
> Thanks.
> 
> York
> 

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

Re: [U-Boot] [PATCH v4 09/13] libfdt: Add fdt_getprop_namelen_w

[Maxime Ripard]

On Wed, Jul 06, 2016 at 11:22:48AM +1000, David Gibson wrote:
> On Tue, Jul 05, 2016 at 10:26:42AM +0200, Maxime Ripard wrote:
> > Add a function to retrieve a writeable property only by the first
> > characters of its name.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> This shouldn't be exported, so it should go into libfdt_internal.h.
> 
> > ---
> >  include/libfdt.h | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/include/libfdt.h b/include/libfdt.h
> > index f13b01f08f71..a55d2d0d8c7b 100644
> > --- a/include/libfdt.h
> > +++ b/include/libfdt.h
> > @@ -619,6 +619,13 @@ const void *fdt_getprop_by_offset(const void *fdt, int 
> > offset,
> >   */
> >  const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
> > const char *name, int namelen, int *lenp);
> > +static inline void *fdt_getprop_namelen_w(void *fdt, int nodeoffset,
> > + const char *name, int namelen,
> > + int *lenp)
> > +{
> > +   return (void *)(uintptr_t)fdt_getprop_namelen(fdt, nodeoffset, name,
> > + namelen, lenp);
> 
> uintptr_t ??

This is defined in the exact same way than fdt_getprop_w. Should I
change that as well?

Thanks,
Maxime

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


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

Re: [U-Boot] [PATCH v4 07/13] libfdt: Fix separator spelling

[Maxime Ripard]

Hi David,

On Wed, Jul 06, 2016 at 11:16:41AM +1000, David Gibson wrote:
> On Tue, Jul 05, 2016 at 10:26:40AM +0200, Maxime Ripard wrote:
> > The function fdt_path_next_seperator had an obvious mispell. Fix it.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Huh.. this entire function appears not to be in upstream libfdt.

Indeed, it was introduced in this commit:
http://git.denx.de/?p=u-boot.git;a=commit;h=77d7fff8cec2652be8c2494b6b66d14a398ec860

I have no idea why it wasn't upstreamed.

I'll make it part of my serie for libfdt.

Maxime

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


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

Re: [U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288

[Kever Yang]

Hi Simon,

On 07/09/2016 10:39 PM, Simon Glass wrote:

Hi Kever,

On 7 July 2016 at 20:45, Kever Yang  wrote:

The grf setting for rkpwm is only need in rk3288, other SoCs like
RK3399 which also use rkpwm do not need set the grf, let's add a
MACRO to make the code only for RK3288.

Change-Id: I167a4e8cf925e840d4bbbcfb1437aaed52b81477

patman will automatically remove these for you.

Will use patman for my new patches later, thanks.



Signed-off-by: Kever Yang 
---
  drivers/pwm/rk_pwm.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
index 2d289a4..e34adf0 100644
--- a/drivers/pwm/rk_pwm.c
+++ b/drivers/pwm/rk_pwm.c
@@ -13,8 +13,10 @@
  #include 
  #include 
  #include 
+#ifdef CONFIG_ROCKCHIP_RK3288
  #include 
  #include 
+#endif
  #include 
  #include 

@@ -22,7 +24,9 @@ DECLARE_GLOBAL_DATA_PTR;

  struct rk_pwm_priv {
 struct rk3288_pwm *regs;
+#ifdef CONFIG_ROCKCHIP_RK3288
 struct rk3288_grf *grf;
+#endif
  };

  static int rk_pwm_set_config(struct udevice *dev, uint channel, uint 
period_ns,
@@ -65,19 +69,23 @@ static int rk_pwm_ofdata_to_platdata(struct udevice *dev)
 struct regmap *map;

 priv->regs = (struct rk3288_pwm *)dev_get_addr(dev);
+#ifdef CONFIG_ROCKCHIP_RK3288
 map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF);
 if (IS_ERR(map))
 return PTR_ERR(map);
 priv->grf = regmap_get_range(map, 0);
+#endif

I'd like to find a better way. Do all chips have a grf? If so then
perhaps we can have a function like grf_enable_pwm() in the core SoC
code and call it here. The #ifdef can be there.

Or perhaps we should have a general soc.c, with its own struct
containing pointers to grf, sgrf, etc. It can be set up at the start,
and then provide a soc_enable_pwm() function to enable the pwm.

What do you think?

Every Rockchip soc have grf, and maybe sgrf, pmugrf which much like
grf. The content in grf are very different for different SoC, it gathers
all kinds of system/module control registers .
Back to the grf setting for pwm, this control operation is only need in
RK3288, not in RK3399 and new SoC further. so I think the '#ifdef' is
better to stay in driver file like rk_pwm.c.

For these system control registers, I'm sure the dedicate general soc.c is
needed, because they are not so common for different module and different
Soc. We are not able to have a common framework for them, a general soc.c
won't help much except all the system control are gather in one file .

I think the GRF setting is part of the module and driver, so we can 
leave it as it is,

and a simple syscon driver is enough for grf like what is kernel do.

Thanks,
- Kever



 return 0;
  }

  static int rk_pwm_probe(struct udevice *dev)
  {
+#ifdef CONFIG_ROCKCHIP_RK3288
 struct rk_pwm_priv *priv = dev_get_priv(dev);

 rk_setreg(>grf->soc_con2, 1 << 0);
+#endif

 return 0;
  }
--
1.9.1



Regards,
Simon






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

Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img

[Alexey Brodkin]

Hi Otavio,

On Sat, 2016-07-09 at 10:02 -0300, Otavio Salvador wrote:
> On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin
>  wrote:
> > 
> > Recently I started to notice that u-boot.img built for Wandboard
> > by some toolchains becomes so large that it basically overlaps with
> > U-Boot environment area on SD-card.
> > 
> > According to
> > http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout
> > Wandboard's SD-card layout is as follows:
> > -->8---
> > ==
> > 1. 0x   Reserved For MBR
> > 2. 0x0200   512 Secondary Image Table (optional)
> > 3. 0x0400   1024uBoot Image (Starting From IVT)
> > 4. 0x0006   393216  start of uboot env (size:8k)
> > 5. 0x00062000   end of uboot env
> > 6. 0x0010   1048576 Linux kernel start
> > 7. 0x0076AC00   280 start of partition 1
> > -->8---
> > 
> > So for U-Boot we have 383kB (392192 bytes).
> > 
> > But in up to date U-Boot for Wandboard we build separately
> >  a) SPL
> >  b) u-boot.img
> > 
> > which gives us a bit more detailed SD-card layout:
> > -->8---
> > ==
> > 1. 0x   Reserved For MBR
> > 2. 0x0200   512 Secondary Image Table (optional)
> > 3. 0x0400   1024SPL
> > 4. 0x00011400   70656   u-boot.img
> > 5. 0x0006   393216  start of uboot env (size:8k)
> > 6. 0x00062000   end of uboot env
> > ...
> > -->8---
> > 
> > From that layout we may calculate amount of space reserved for
> > u-boot.img. It's just 315kb (322560 bytes).
> > 
> > Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced
> > u-boot.img is already more than we expected
> > (323840 bytes instead of "< 322560"):
> > -->8---
> > ls -la u-boot.img
> > -rw-rw-r-- 1 user user 323840 Jul  5 07:38 u-boot.img
> > -->8---
> > 
> > Funny enough if I rebuild U-Boot with ARM toolchain available in
> > my Fedora 23 distro u-boot.img becomes a little bit smaller:
> > -->8---
> > ls -la u-boot.img
> > -rw-rw-r-- 1 user user 322216 Jul  5 07:39 u-boot.img
> > -->8---
> > 
> > What's worse this problem might not affect people most of the time
> > because what happens people would just copy u-boot.img on SD-card and
> > live in happiness with it... well until somebody attempts to save
> > environment in U-Boot with "saveenv" command which will simply
> > overwrite the very end of u-boot.img.
> > That will lead to unusable SD-card until user dd u-boot.img on
> > SD-card again.
> > 
> > I may foresee this issue in the future to become more visible once we
> > add more features in U-Boot for Wandboard or just existing code base
> > becomes bulkier and people will consistently get larger u-boot.img
> > files produced.
> > 
> > IMHO there's an obvious solution for all that - just move U-Boot's env
> > to the very end of the gap between U-Boot and the first real partition
> > on the SD-card. This patch will follow
> > 8fb9eea5653796 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'").
> > So env is still not in the very end of the gap (obviously 256kb is way
> > too much for U-Boot's env) but at least we have now the same
> > partitioning for i.MX6 boards.
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Fabio Estevam 
> > Cc: Otavio Salvador 
> > Cc: Peter Robinson 
> > Cc: Tom Rini 
> > Cc: Peter Korsgaard 
> > Cc: Wolfgang Denk 
>
> Couldn't this be done on the common header?

It could be done but that's not so straight-forward.
See not all boards that use "mx6_common.h" store U-Boot's environment
on SD card. There're ones that put env in SPI flash ("cm_fx6", "aristainetos"
etc). Moreover some "include/configs/XXX.h" files put "mx6_common.h" in
the very beginning some in the middle, some in the very end. I.e. we cannot rely
on "#ifdef CONFIG_ENV_IS_IN_MMC" - it might be defined later easily.

That means if we move CONFIG_ENV_OFFSET in "mx6_common.h" we'll need to wrap
CONFIG_ENV_OFFSET on some boards with #undef to allow them to override 
ENV_OFFSET.

IMHO better solution would be as Tom suggested to move all ENV related things in
Kconfig and there we'll be able to handle it more gracefully.

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

Re: [U-Boot] [PATCH 1/2] spi: ti_qspi: Fix failure on multiple READ_ID cmd

[Jagan Teki]

On 11 July 2016 at 11:00, Vignesh R  wrote:
> Populating QSPI_RD_SNGL bit(0x1) in priv->cmd means that value
> QSPI_INVAL (0x4) is not written to CMD field of QSPI_SPI_CMD_REG in
> ti_qspi_cs_deactivate(). Therefore CS is never deactivated between
> successive READ ID which results in sf probe to fail.
> Fix this by not populating priv->cmd with QSPI_RD_SNGL and OR it wih
> priv->cmd as required (similar to the convention followed in the
> driver).
>
> Signed-off-by: Vignesh R 
> ---
>  drivers/spi/ti_qspi.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
> index 9a372ad31dae..376fe378ed63 100644
> --- a/drivers/spi/ti_qspi.c
> +++ b/drivers/spi/ti_qspi.c
> @@ -247,13 +247,12 @@ static int __ti_qspi_xfer(struct ti_qspi_priv *priv, 
> unsigned int bitlen,
> debug("tx done, status %08x\n", status);
> }
> if (rxp) {
> -   priv->cmd |= QSPI_RD_SNGL;
> debug("rx cmd %08x dc %08x\n",
>   priv->cmd, priv->dc);

| QSPI_RD_SNGL on debug statement as well.

> #ifdef CONFIG_DRA7XX
> udelay(500);
> #endif

Can't we fix this delay, still need?

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot