Re: [U-Boot] [PATCH v3 2/3] rtc: pl031: convert the driver to driver model

2018-07-20 Thread Heinrich Schuchardt
On 07/11/2018 11:06 AM, AKASHI Takahiro wrote:
> With this patch, PL031 driver is converted to driver-model-compliant
> driver. In addition, CONFIG_SYS_RTC_PL031_BASE is no longer valid.
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  drivers/rtc/Kconfig  |   6 ++
>  drivers/rtc/pl031.c  | 126 ++-
>  scripts/config_whitelist.txt |   1 -
>  3 files changed, 86 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index a3f8c8aecc..96c4cce410 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -55,6 +55,12 @@ config RTC_MV
> Enable Marvell RTC driver. This driver supports the rtc that is 
> present
> on some Marvell SoCs.
>  
> +config RTC_PL031
> + bool "Enable ARM PL031 driver"
> + depends on DM_RTC
> + help
> +   Enable ARM PL031 driver.
> +

Tom merged
http://git.denx.de/?p=u-boot.git;a=commit;h=b19886b9469174213877ef37670ce35c55acb456
https://patchwork.ozlabs.org/patch/936533/
ARM: qemu-arm: enable RTC
which is superseeded by your patch series.

We should avoid duplicate entries CONFIG_RTC_PL031.

Symbol CONFIG_SYS_RTC_PL031_BASE can be removed in
include/configs/qemu-arm.h with this patch.

Could you, please, respin your patch series.

Best regards

Heinrich

>  config RTC_S35392A
>   bool "Enable S35392A driver"
>   select BITREVERSE
> diff --git a/drivers/rtc/pl031.c b/drivers/rtc/pl031.c
> index 8955805e3b..b8fd944e44 100644
> --- a/drivers/rtc/pl031.c
> +++ b/drivers/rtc/pl031.c
> @@ -8,13 +8,11 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
> -
> -#if defined(CONFIG_CMD_DATE)
> -
> -#ifndef CONFIG_SYS_RTC_PL031_BASE
> -#error CONFIG_SYS_RTC_PL031_BASE is not defined!
> -#endif
> +#include 
> +#include 
>  
>  /*
>   * Register definitions
> @@ -30,78 +28,114 @@
>  
>  #define RTC_CR_START (1 << 0)
>  
> -#define  RTC_WRITE_REG(addr, val) \
> - (*(volatile unsigned int *)(CONFIG_SYS_RTC_PL031_BASE + 
> (addr)) = (val))
> -#define  RTC_READ_REG(addr)  \
> - (*(volatile unsigned int *)(CONFIG_SYS_RTC_PL031_BASE + 
> (addr)))
> +struct pl031_platdata {
> + phys_addr_t base;
> +};
>  
> -static int pl031_initted = 0;
> +static inline u32 pl031_read_reg(struct udevice *dev, int reg)
> +{
> + struct pl031_platdata *pdata = dev_get_platdata(dev);
>  
> -/* Enable RTC Start in Control register*/
> -void rtc_init(void)
> + return readl(pdata->base + reg);
> +}
> +
> +static inline u32 pl031_write_reg(struct udevice *dev, int reg, u32 value)
>  {
> - RTC_WRITE_REG(RTC_CR, RTC_CR_START);
> + struct pl031_platdata *pdata = dev_get_platdata(dev);
>  
> - pl031_initted = 1;
> + return writel(value, pdata->base + reg);
>  }
>  
>  /*
> - * Reset the RTC. We set the date back to 1970-01-01.
> + * Probe RTC device
> + */
> +static int pl031_probe(struct udevice *dev)
> +{
> + /* Enable RTC Start in Control register*/
> + pl031_write_reg(dev, RTC_CR, RTC_CR_START);
> +
> + return 0;
> +}
> +
> +/*
> + * Get the current time from the RTC
>   */
> -void rtc_reset(void)
> +static int pl031_get(struct udevice *dev, struct rtc_time *tm)
>  {
> - RTC_WRITE_REG(RTC_LR, 0x00);
> - if(!pl031_initted)
> - rtc_init();
> + unsigned long tim;
> +
> + if (!tm)
> + return -EINVAL;
> +
> + tim = pl031_read_reg(dev, RTC_DR);
> +
> + rtc_to_tm(tim, tm);
> +
> + debug("Get DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
> + tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_wday,
> + tm->tm_hour, tm->tm_min, tm->tm_sec);
> +
> + return 0;
>  }
>  
>  /*
>   * Set the RTC
> -*/
> -int rtc_set(struct rtc_time *tmp)
> + */
> +static int pl031_set(struct udevice *dev, const struct rtc_time *tm)
>  {
>   unsigned long tim;
>  
> - if(!pl031_initted)
> - rtc_init();
> + if (!tm)
> + return -EINVAL;
>  
> - if (tmp == NULL) {
> - puts("Error setting the date/time\n");
> - return -1;
> - }
> + debug("Set DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
> + tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_wday,
> + tm->tm_hour, tm->tm_min, tm->tm_sec);
>  
>   /* Calculate number of seconds this incoming time represents */
> - tim = rtc_mktime(tmp);
> + tim = rtc_mktime(tm);
>  
> - RTC_WRITE_REG(RTC_LR, tim);
> + pl031_write_reg(dev, RTC_LR, tim);
>  
> - return -1;
> + return 0;
>  }
>  
>  /*
> - * Get the current time from the RTC
> + * Reset the RTC. We set the date back to 1970-01-01.
>   */
> -int rtc_get(struct rtc_time *tmp)
> +static int pl031_reset(struct udevice *dev)
>  {
> - ulong tim;
> + pl031_write_reg(dev, RTC_LR, 0);
>  
> - if(!pl031_initted)
> - rtc_init();
> + return 0;
> +}
>  
> - if (tmp == NULL) {
> - puts("Error 

Re: [U-Boot] Please pull u-boot-x86

2018-07-20 Thread Tom Rini
On Fri, Jul 20, 2018 at 02:01:54PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> The following changes since commit f7e48c54b246c460503e90315d0cd50ccbd586c6:
> 
>   Merge tag 'xilinx-for-v2018.09' of
> git://git.denx.de/u-boot-microblaze (2018-07-19 11:48:33 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to 05855fd31a3f7483534aabe69a7030ff38978510:
> 
>   x86: acpi: Prevent acpi_table.h from being included more than once
> (2018-07-20 09:33:22 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] binman: ensure temp filenames don't collide

2018-07-20 Thread Simon Glass
Hi Stephen,

On 19 July 2018 at 22:43, Stephen Warren  wrote:

> On 07/19/2018 08:17 PM, Simon Glass wrote:
> > Hi Stephen,
> >
> > On 19 July 2018 at 15:14, Stephen Warren  wrote:
> >> On 07/18/2018 07:32 PM, Simon Glass wrote:
> >>> Hi Stephen,
> >>>
> >>> On 16 July 2018 at 16:51, Stephen Warren 
> wrote:
>  From: Stephen Warren 
> 
>  The U-Boot Makefile can invoke binman multiple times in parallel. This
>  is problematic because binman uses a static hard-coded temporary file
>  name. If two instances of binman use that filename at the same time,
> one
>  writing one reading, they may silently read the wrong content or
> actively
>  detect missing signatures and error out the build process. Fix this by
>  using a PID-specific filename instead.
> 
>  Signed-off-by: Stephen Warren 
>  ---
>   tools/binman/control.py | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  diff --git a/tools/binman/control.py b/tools/binman/control.py
>  index a40b300fdacb..515999278949 100644
>  --- a/tools/binman/control.py
>  +++ b/tools/binman/control.py
>  @@ -121,7 +121,7 @@ def Binman(options, args):
>   # output into a file in our output directly. Then scan
> it for use
>   # in binman.
>   dtb_fname = fdt_util.EnsureCompiled(dtb_fname)
>  -fname = tools.GetOutputFilename('u-boot-out.dtb')
>  +fname = tools.GetOutputFilename('u-boot-out.dtb') +
> str(os.getpid())
>   with open(dtb_fname) as infd:
>   with open(fname, 'wb') as outfd:
>   outfd.write(infd.read())
>  --
>  2.18.0
> 
> >>>
> >>> But the output directory is itself (normally) a temporary dir. That
> >>> determines the directly which GetOutputFilename() uses. So I am not
> >>> sure how this can happen in practice?
> >>
> >> IIRC, the output directory for all 3 files was the same; the root of the
> >> build output directory. Perhaps the fact I run "make O=build-xxx" rather
> >> than just "make" makes a difference?
> >
> > Yes you are right - the -O flag sets the output directory and it
> > no-longer uses a temporary directory.
> >
> > But if we add a PID to every filename then we end up with multiple
> > output files and we don't know which is right.
> >
> > I think the correct fix is to change the Makefile to only run binman
> > once. It makes no sense to run it multiple times.
>
> IIRC, this filename is just a temp file that eventually gets removed
> after binman runs. Certainly there are not *.${pid} files left around
> after the build has completed.
>

This is what I see with your patch:

u-boot-out.dtb198273
u-boot-out.dtb198277
u-boot-out.dtb198280

I think there are two options:

1. Add an arg to binman to indicate which output image to create, so that
binman runs three times but only one of those generates the .dtb output
file.

2. Use a GNU make pattern rule, as described here:
https://www.gnu.org/software/make/manual/html_node/Pattern-Examples.html#Pattern-Examples

I'll send a patch for the latter which seems easier to me. But I will
probably have to update binman to support (1) too.

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


[U-Boot] [PATCH] tegra: Indicate that binman makes all three output files

2018-07-20 Thread Simon Glass
Use GNU make pattern rules to indicate that a single run of binman
produces all three Tegra output files. The avoids make running binman
three times (perhaps in parallel) and those instances inteferring with
each other.

See http://patchwork.ozlabs.org/patch/944611/ for the bug report.

Signed-off-by: Simon Glass 
---

 Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 4b3023b259..489b3deef3 100644
--- a/Makefile
+++ b/Makefile
@@ -1234,8 +1234,9 @@ endif
 
 ifneq ($(CONFIG_TEGRA),)
 ifneq ($(CONFIG_BINMAN),)
-u-boot-dtb-tegra.bin u-boot-tegra.bin u-boot-nodtb-tegra.bin: \
-   spl/u-boot-spl u-boot.bin FORCE
+# Makes u-boot-dtb-tegra.bin u-boot-tegra.bin u-boot-nodtb-tegra.bin
+%-dtb-tegra.bin %-tegra.bin %-nodtb-tegra.bin: \
+   spl/%-spl %.bin FORCE
$(call if_changed,binman)
 else
 OBJCOPYFLAGS_u-boot-nodtb-tegra.bin = -O binary 
--pad-to=$(CONFIG_SYS_TEXT_BASE)
-- 
2.18.0.233.g985f88cf7e-goog

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


[U-Boot] [PATCH] doc: Move device tree bindings documentation to doc/device-tree-bindings

2018-07-20 Thread Breno Lima
From: Breno Lima 

Currently the U-Boot project contains 2 documentation directories:

- doc/
- Documentation/

The Documentation directory only contains device tree bindings related
content, so move the 3 files to doc/device-tree-bindings/.

Signed-off-by: Breno Lima 
---
 .../devicetree/bindings => doc/device-tree-bindings}/phy/no-op.txt| 0
 .../bindings => doc/device-tree-bindings}/phy/phy-stm32-usbphyc.txt   | 0
 .../bindings => doc/device-tree-bindings}/rtc/brcm,brcmstb-waketimer.txt  | 0
 3 files changed, 0 insertions(+), 0 deletions(-)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings}/phy/no-op.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings}/phy/phy-stm32-usbphyc.txt (100%)
 rename {Documentation/devicetree/bindings => 
doc/device-tree-bindings}/rtc/brcm,brcmstb-waketimer.txt (100%)

diff --git a/Documentation/devicetree/bindings/phy/no-op.txt 
b/doc/device-tree-bindings/phy/no-op.txt
similarity index 100%
rename from Documentation/devicetree/bindings/phy/no-op.txt
rename to doc/device-tree-bindings/phy/no-op.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.txt 
b/doc/device-tree-bindings/phy/phy-stm32-usbphyc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.txt
rename to doc/device-tree-bindings/phy/phy-stm32-usbphyc.txt
diff --git a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.txt 
b/doc/device-tree-bindings/rtc/brcm,brcmstb-waketimer.txt
similarity index 100%
rename from Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.txt
rename to doc/device-tree-bindings/rtc/brcm,brcmstb-waketimer.txt
-- 
2.7.4

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


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

2018-07-20 Thread Dr. Philipp Tomsich
Tom,

The first batch of changes for u-boot-rockchip/master in this iteration is 
ready for you to pull.
The associated Travis report (prior to the rebase) is at
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/406299101

Thanks,
Philipp.


The following changes since commit 0dd1fc09bb16869fd8adaaad082cd554c60b2c1a:

  board/imgtec/boston: Add new defconfigs to the MAINTAINERS list (2018-07-20 
15:55:10 -0400)

are available in the git repository at:

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

for you to fetch changes up to a2a5053a15e4059c7445737d60f7b8425ca863f8:

  rockchip: utilize CONFIG_DEFAULT_FDT_FILE (2018-07-21 01:56:59 +0200)


Alexander Kochetkov (2):
  rockchip: i2c: enable i2c controller for rk3066 and rk3188
  rockchip: rk3188: add rk_board_late_init() hook

Carlo Caione (3):
  rk3288: veyron: Init boot-on regulators
  rk3288: Disable JTAG function from sdmmc0 IO
  rockchip: veyron: Set vcc33_sd regulator value

Heinrich Schuchardt (3):
  rockchip: evb-rk3399: correct README for board bring up
  rockchip: doc: clarify usage of CONFIG_SPL_ROCKCHIP_BACK_TO_BROM
  rockchip: rk3399: spl: add missing \n to output

Jakob Unterwurzacher (1):
  rockchip: board: lion-rk3368: increase phy autonegotiation timeout

Klaus Goger (2):
  rockchip: rk3399: change boot_target based on u-boot, spl-boot-device
  rockchip: utilize CONFIG_DEFAULT_FDT_FILE

Philipp Tomsich (4):
  smartweb: use SPL_TINY_MEMSET
  spl: record boot_device into spl_image and call spl_perform_fixups
  spl: document 'chosen/u-boot, spl-boot-device'
  rockchip: rk3399: inject 'u-boot, spl-boot-device' for next-stage

 arch/arm/mach-rockchip/rk3188-board.c |  7 +-
 arch/arm/mach-rockchip/rk3288-board.c | 26 ++-
 arch/arm/mach-rockchip/rk3399-board-spl.c | 50 +++-
 board/rockchip/evb_rk3399/README  |  2 +-
 board/theobroma-systems/puma_rk3399/puma-rk3399.c | 74 ++
 common/spl/spl.c  | 12 ++-
 configs/chromebit_mickey_defconfig|  1 +
 configs/chromebook_jerry_defconfig|  1 +
 configs/chromebook_minnie_defconfig   |  1 +
 configs/evb-px5_defconfig |  1 +
 configs/evb-rk3036_defconfig  |  1 +
 configs/evb-rk3128_defconfig  |  1 +
 configs/evb-rk3229_defconfig  |  1 +
 configs/evb-rk3288_defconfig  |  1 +
 configs/evb-rk3328_defconfig  |  1 +
 configs/evb-rk3399_defconfig  |  1 +
 configs/evb-rv1108_defconfig  |  1 +
 configs/fennec-rk3288_defconfig   |  1 +
 configs/firefly-rk3288_defconfig  |  1 +
 configs/firefly-rk3399_defconfig  |  1 +
 configs/geekbox_defconfig |  1 +
 configs/kylin-rk3036_defconfig|  1 +
 configs/lion-rk3368_defconfig |  1 +
 configs/miqi-rk3288_defconfig |  1 +
 configs/phycore-rk3288_defconfig  |  1 +
 configs/popmetal-rk3288_defconfig |  1 +
 configs/puma-rk3399_defconfig |  1 +
 configs/rock2_defconfig   |  1 +
 configs/rock_defconfig|  1 +
 configs/sheep-rk3368_defconfig|  1 +
 configs/smartweb_defconfig|  1 +
 configs/tinker-rk3288_defconfig   |  1 +
 configs/vyasa-rk3288_defconfig|  1 +
 doc/README.rockchip   |  8 +-
 doc/device-tree-bindings/chosen.txt   | 10 +++
 drivers/i2c/rk_i2c.c  | 94 +--
 include/configs/lion_rk3368.h |  2 +
 include/configs/rk3036_common.h   |  1 +
 include/configs/rk3128_common.h   |  1 +
 include/configs/rk3188_common.h   |  1 +
 include/configs/rk322x_common.h   |  1 +
 include/configs/rk3288_common.h   |  2 +-
 include/configs/rk3328_common.h   |  1 +
 include/configs/rk3368_common.h   |  1 +
 include/configs/rk3399_common.h   |  2 +-
 include/spl.h |  7 ++
 46 files changed, 312 insertions(+), 17 deletions(-)

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


Re: [U-Boot] [PATCH v2 00/11] Add ethernet support for phyCORE-RK3288

2018-07-20 Thread Grygorii Strashko



On 07/18/2018 03:46 AM, Janine Hagemann wrote:

- Remove 0004-Net-phy-ti-Fix-fifo_depth-register-write.patch because
   of the change from 0005-net-phy-ti-Recover-from-port-mirroring-
   N-A-MODE4.patch it isn't needed anymore. Before, the MII_DP83867_
   PHYCTRL-register wasn't write correctly without the fix-patch.


I can't find v1 of this series, so above comment looks strange.
What's wrong exactly with "PHYCTRL-register wasn't write correctly"?



- correct commit reference format

Janine Hagemann (11):
   arch: arm: mach-rockchip: rk3288: Enable regulators in board_init
   config: phycore-rk3288_defconfig: add PHY_TI
   net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii
   net: phy: ti: Add lane swapping support in the DP83867 TI's PHY driver
   net: phy: ti: Recover from "port mirroring" N/A MODE4
   net: phy: ti: add workaround for incorrect RX_CTRL pin strap
   net: gmac_rockchip: Add handeling for RGMII_ID/RXID/TXID
   drivers: net: designware: Add reading of DT phy-handle node
   net: phy: ti: Add binding for the CLK_OUT pin muxing
   ARM: dts: rockchip: ADD dp83867 CLK_OUT muxing
   rockchip: rk3288-phycore: set flash1 iodomain to 1.8V

  arch/arm/dts/rk3288-phycore-som.dtsi |   1 +
  arch/arm/mach-rockchip/rk3288-board.c|   6 ++
  board/phytec/phycore_rk3288/phycore-rk3288.c |  16 +
  configs/phycore-rk3288_defconfig |   1 +
  doc/device-tree-bindings/net/ti,dp83867.txt  |   3 +
  drivers/net/designware.c |  11 ++-
  drivers/net/designware.h |   1 +
  drivers/net/gmac_rockchip.c  |  80 -
  drivers/net/phy/ti.c | 104 ++-
  include/dt-bindings/net/ti-dp83867.h |  15 
  10 files changed, 219 insertions(+), 19 deletions(-)



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


Re: [U-Boot] [PATCH v2 06/11] net: phy: ti: add workaround for incorrect RX_CTRL pin strap

2018-07-20 Thread Grygorii Strashko



On 07/18/2018 03:46 AM, Janine Hagemann wrote:

The data manual for DP83867IR/CR, SNLS484E[1], revised march 2017,
advises that strapping RX_DV/RX_CTRL pin in mode 1 and 2 is not
supported (see note below Table 5 (4-Level Strap Pins)).

There are some boards which have the pin strapped this way and need
software workaround suggested by the data manual. Bit[7] of
Configuration Register 4 (address 0x0031) must be cleared to 0. This
ensures proper operation of the PHY.

Implement driver support for device-tree property meant to advertise
the wrong strapping.

[1] http://www.ti.com/lit/ds/snls484e/snls484e.pdf

Based on commit 371444764b98 ("net: phy: dp83867: add workaround for
incorrect RX_CTRL pin strap") of mainline linux kernel.

Signed-off-by: Janine Hagemann 
---
v2: Change commit reference format
---
  drivers/net/phy/ti.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index ea1ee24..f0ca8f2 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -111,6 +111,7 @@ struct dp83867_private {
int fifo_depth;
int io_impedance;
int port_mirroring;
+   bool rxctrl_strap_quirk;
  };
  
  /**

@@ -219,6 +220,9 @@ static int dp83867_of_init(struct phy_device *phydev)
else
dp83867->io_impedance = -EINVAL;
  
+	dp83867->rxctrl_strap_quirk = fdtdec_get_bool(fdt, node,

+   "ti,dp83867-rxctrl-strap-quirk");
+
dp83867->rx_id_delay = fdtdec_get_uint(gd->fdt_blob, dev_of_offset(dev),
 "ti,rx-internal-delay", -1);
  
@@ -274,6 +278,15 @@ static int dp83867_config(struct phy_device *phydev)

phy_write(phydev, MDIO_DEVAD_NONE, DP83867_CTRL,
  val | DP83867_SW_RESTART);
  
+	/* RX_DV/RX_CTRL strapped in mode 1 or mode 2 workaround */

+   if (dp83867->rxctrl_strap_quirk) {
+   val = phy_read_mmd_indirect(phydev, DP83867_CFG4,
+   DP83867_DEVADDR, phydev->addr);
+   val &= ~BIT(7);
+   phy_write_mmd_indirect(phydev, DP83867_CFG4, DP83867_DEVADDR,
+   phydev->addr, val);
+   }
+
if (phy_interface_is_rgmii(phydev)) {
ret = phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL,
(DP83867_MDI_CROSSOVER_AUTO << DP83867_MDI_CROSSOVER) |



Pls, check
https://patchwork.ozlabs.org/cover/936370/
and
https://patchwork.ozlabs.org/cover/936380/

i'd need to rebase your series.

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


Re: [U-Boot] [U-Boot, v6, 4/6] hashtable: do not recreate whole hash table if vars are passed to himport_r

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 07:16:28PM +0200, Quentin Schulz wrote:

> When vars are passed to the himport_r function with H_NOCLEAR flag,
> those vars will be overridden in the current environment and if one of
> those vars is not in the imported environment, it'll be deleted in the
> current environment whatever the flag passed to himport_r.
> 
> The H_NOCLEAR flag is used to clear the whole environment whether vars
> are passed to the function or not.
> 
> This leads to incoherent behaviour. If one passes vars to himport_r
> with the H_NOCLEAR flag, if a var in vars is not in the imported env,
> that var will be removed from the current env.
> 
> If one passes vars to himport_r without the H_NOCLEAR flag, the whole
> environment will be removed and vars will be imported from the
> environment in RAM.
> 
> It makes more sense to keep the variable that is in the current
> environment but not in the imported environment if the H_NOCLEAR flag is
> set and remove only that variable if the H_NOCLEAR flag is not set.
> 
> Let's clear the whole environment only if H_NOCLEAR and vars are not
> passed to himport_r.
> 
> Let's remove variables that are in the current environment but not in
> the imported env only if the H_NOCLEAR flag is not passed.
> 
> Suggested-by: Wolfgang Denk 
> Signed-off-by: Quentin Schulz 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 3/4] dm: led: move default state support in led uclass

2018-07-20 Thread Tom Rini
On Fri, Jul 13, 2018 at 05:21:10PM +0200, Patrick Delaunay wrote:

> This patch save common LED property "default-state" value
> in post bind of LED uclass.
> The configuration for this default state is only performed when
> led_default_state() is called;
> It can be called in your board_init()
> or it could added in init_sequence_r[] in future.
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v6, 5/6] cmd: nvedit: env import can now import only variables passed as parameters

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 07:16:29PM +0200, Quentin Schulz wrote:

> While the `env export` can take as parameters variables to be exported,
> `env import` does not have such a mechanism of variable selection.
> 
> Let's add the ability to add parameters at the end of the command for
> variables to be imported.
> 
> Every env variable from the env to be imported passed by parameter to
> this command will override the value of the variable in the current env.
> 
> If a variable exists in the current env but not in the imported env, if
> this variable is passed as a parameter to env import, the variable will
> be unset ONLY if the -d option is passed to env import, otherwise the
> current value of the variable is kept.
> 
> If a variable exists in the imported env, the variable in the current
> env will be set to the value of the one from the imported env.
> 
> All the remaining variables are left untouched.
> 
> As the size parameter of env import is positional but optional, let's
> add the possibility to use the sentinel '-' for when we don't want to
> give the size parameter (when the env is '\0' terminated) but we pass a
> list of variables at the end of the command.
> 
> env import addr
> env import addr -
> env import addr size
> env import addr - foo1 foo2
> env import addr size foo1 foo2
> 
> are all valid.
> 
> env import -c addr
> env import -c addr -
> env import -c addr - foo1 foo2
> 
> are all invalid because they don't pass the size parameter required for
> checking, while the following are valid.
> 
> env import addr size
> env import addr size foo1 foo2
> 
> Nothing's changed for the other parameters or the overall behaviour.
> 
> One of its use case could be to load a secure environment from the
> signed U-Boot binary and load only a handful of variables from an
> other, unsecure, environment without completely losing control of
> U-Boot.
> 
> Signed-off-by: Quentin Schulz 
> Tested-by: Alex Kiernan 
> Tested-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v4,2/2] configs: Update Meson GX configs

2018-07-20 Thread Tom Rini
On Tue, Jul 10, 2018 at 10:01:08AM +0200, Loic Devulder wrote:

> Enable ADC support on the Khadas VIM board.
> 
> Signed-off-by: Loic Devulder 
> Acked-by: Neil Armstrong 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v6, 6/6] test/py: add test for whitelist of variables while importing environment

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 07:16:30PM +0200, Quentin Schulz wrote:

> This tests that the importing of an environment with a specified
> whitelist works as intended.
> 
> If there are variables passed as parameter to the env import command,
> those only should be imported in the current environment.
> 
> For each variable passed as parameter, if
>  - foo is bar in current env and bar2 in exported env, after importing
>  exported env, foo shall be bar2,
>  - foo does not exist in current env and foo is bar2 in exported env,
>  after importing exported env, foo shall be bar2,
>  - foo is bar in current env and does not exist in exported env (but is
>  passed as parameter), after importing exported env, foo shall be empty
>  ONLY if the -d option is passed to env import, otherwise foo shall be
>  bar,
> 
> Any variable not passed as parameter should be left untouched.
> 
> Two other tests are made to test that size cannot be '-' if the checksum
> protection is enabled.
> 
> Signed-off-by: Quentin Schulz 
> Reviewed-by: Simon Glass 
> Reviewed-by: Stephen Warren 
> Tested-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,5/6] stm32mp1: clk: add ADC clock gating

2018-07-20 Thread Tom Rini
On Mon, Jul 16, 2018 at 10:41:45AM +0200, Patrick Delaunay wrote:

> Add ADC clock gating, that may be used by STM32 ADC.
> 
> Signed-off-by: Fabrice Gasnier 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 4/6] stm32mp1: add support for stm32mp157c-ev1 board

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 03:17:22PM +0200, Patrick Delaunay wrote:

> Add support of stm32mp157c-ev1, the evaluation board with pmic stpmu1
> (ev1 = mother board + daughter ed1) with device tree.
> EV1 is the selected board by default in basic defconfig.
> 
> PS: CONFIG_PINCTRL_FULL activation avoid to increase
> SYS_MALLOC_F_LEN (Early malloc usage: 2034)
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v6, 1/6] env: add the same prefix to error messages to make it detectable by tests

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 07:16:25PM +0200, Quentin Schulz wrote:

> The error message should start with `## Error: ` so that it's easily
> detectable by tests without needing to have a complex regexp for
> matching all possible error message patterns.
> 
> Let's add the `## Error: ` prefix to the error messages since it's the
> one already in use.
> 
> Suggested-by: Stephen Warren 
> Signed-off-by: Quentin Schulz 
> Reviewed-by: Simon Glass 
> Reviewed-by: Stephen Warren 
> Tested-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,5/6] stm32mp1: activate FIXED regulator

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 03:17:23PM +0200, Patrick Delaunay wrote:

> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,2/6] misc: stm32: Add STM32MP1 support

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 03:17:20PM +0200, Patrick Delaunay wrote:

> Following next kernel rcc bindings, we must use a MFD
> RCC driver which is able to bind both clock and reset
> drivers.
> 
> We can reuse and adapt RCC MFD driver already available
> for MCU SoCs (F4/F7/H7).
> 
> Signed-off-by: Patrice Chotard 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,3/6] stm32mp1: activate MISC support in SPL

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 03:17:21PM +0200, Patrick Delaunay wrote:

> needed for RCC MISC driver and sysreset with syscon
> in SPL
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 2/6] stm32mp1: clk: add common function pll_get_fvco

2018-07-20 Thread Tom Rini
On Mon, Jul 16, 2018 at 10:41:42AM +0200, Patrick Delaunay wrote:

> the function compute the VCO PLL freq, used in
> - stm32mp1_read_pll_freq()
> - pll_set_rate()
> 
> Signed-off-by: Patrick Delaunay 
> # Conflicts:
> # drivers/clk/clk_stm32mp1.c

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,6/6] stm32mp1: clk: support digital bypass

2018-07-20 Thread Tom Rini
On Mon, Jul 16, 2018 at 10:41:46AM +0200, Patrick Delaunay wrote:

> HSE and LSE bypass shall support both analog and digital signals.
> This patch add a way to select digital bypas case in the device tree
> and set the associated bit DIGBYP in RCC_BDCR and RCC_OCEN register
> during clock tree initialization.
> 
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 4/6] stm32mp1: clk: update Ethernet clock gating

2018-07-20 Thread Tom Rini
On Mon, Jul 16, 2018 at 10:41:44AM +0200, Patrick Delaunay wrote:

> Alignment with kernel clock driver
> 
> Signed-off-by: Patrice Chotard 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v2,1/1] Fix README for Khadas VIM board

2018-07-20 Thread Tom Rini
On Fri, Jul 13, 2018 at 11:36:07AM +0200, Loic Devulder wrote:

> Explicitly add 'python' call for 'acs_tool.pyc', to avoid failed
> execution on some OSes.
> 
> Signed-off-by: Loic Devulder 
> Acked-by: Neil Armstrong 
> 
> diff --git a/board/amlogic/khadas-vim/README b/board/amlogic/khadas-vim/README
> index 7eaca724f8..2f30831436 100644

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 1/6] dts: import stm32mp1 device tree from linux kernel

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 03:17:19PM +0200, Patrick Delaunay wrote:

> This patch rebase the stm32mp1 device tree source from
> linux kernel v4.18-rc1.
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 4/4] stm32mp1: use new function led default state

2018-07-20 Thread Tom Rini
On Fri, Jul 13, 2018 at 05:21:11PM +0200, Patrick Delaunay wrote:

> Initialize the led with the default state defined in device tree.
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] sysreset: syscon: update regmap access to syscon

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 02:59:29PM +0200, Patrick Delaunay wrote:

> Use new API syscon_node_to_regmap in sysreset_syscon driver
> for compatible "syscon-reboot"; that's avoid the need of explicit
> syscon binding for "regmap" handle.
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v6, 2/6] test/py: return a RAM address different from 0 as it can be interpreted as NULL

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 07:16:26PM +0200, Quentin Schulz wrote:

> Some functions test that the given address is not NULL (0) and fail or
> have a different behaviour if that's the case (e.g. hexport_r).
> 
> Let's make the RAM base address to be not zero by setting it to 2MiB if
> that's the case.
> 
> 2MiB is chosen because it represents the size of an ARM LPAE/v8 section.
> 
> Suggested-by: Stephen Warren 
> Signed-off-by: Quentin Schulz 
> Reviewed-by: Simon Glass 
> Reviewed-by: Stephen Warren 
> Tested-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v6, 3/6] test/py: remove hacks for non-zero RAM base address in tests

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 07:16:27PM +0200, Quentin Schulz wrote:

> Some functions have different behaviour when the given address is 0
> (assumed to be NULL by the function).
> 
> find_ram_base() does not return 0 anymore so it's safe to remove those
> offsets.
> 
> Suggested-by: Stephen Warren 
> Signed-off-by: Quentin Schulz 
> Reviewed-by: Stephen Warren 
> Tested-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 1/6] stm32mp1: clk: define RCC_PLLNCFGR2_SHIFT macro

2018-07-20 Thread Tom Rini
On Mon, Jul 16, 2018 at 10:41:41AM +0200, Patrick Delaunay wrote:

> This patch define RCC_PLLNCFGR2_SHIFT to reuse it in
> the pll function for set rate.
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Vikas Manocha 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 3/6] stm32mp1: clk: add LDTC and DSI clock support

2018-07-20 Thread Tom Rini
On Mon, Jul 16, 2018 at 10:41:43AM +0200, Patrick Delaunay wrote:

> This patch add clk_enable/clk_disable/clk_get_rate support for
> - DSI_PX
> - LTDC_PX
> - DSI_K (only get rate)
> 
> These clocks are needed for LTDC and DSI drivers with latest device tree.
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


[U-Boot] [PATCH] drivers/ddr/fsl: fix '__hwconfig without a buffer' messages

2018-07-20 Thread Jeremy Gebben
Pass an empty buffer instead of NULL if the hwconfig environment
variable isn't set.

Signed-off-by: Jeremy Gebben 
Cc: Stefano Babic 
Cc: York Sun 
---
 drivers/ddr/fsl/options.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/ddr/fsl/options.c b/drivers/ddr/fsl/options.c
index 5f2acb1c9d..7639a8b3dd 100644
--- a/drivers/ddr/fsl/options.c
+++ b/drivers/ddr/fsl/options.c
@@ -742,8 +742,7 @@ unsigned int populate_memctl_options(const 
common_timing_params_t *common_dimm,
unsigned int ctrl_num)
 {
unsigned int i;
-   char buffer[HWCONFIG_BUFFER_SIZE];
-   char *buf = NULL;
+   char buf[HWCONFIG_BUFFER_SIZE];
 #if defined(CONFIG_SYS_FSL_DDR3) || \
defined(CONFIG_SYS_FSL_DDR2) || \
defined(CONFIG_SYS_FSL_DDR4)
@@ -757,8 +756,8 @@ unsigned int populate_memctl_options(const 
common_timing_params_t *common_dimm,
 * Extract hwconfig from environment since we have not properly setup
 * the environment but need it for ddr config params
 */
-   if (env_get_f("hwconfig", buffer, sizeof(buffer)) > 0)
-   buf = buffer;
+   if (env_get_f("hwconfig", buf, sizeof(buf)) < 0)
+   buf[0] = '\0';
 
 #if defined(CONFIG_SYS_FSL_DDR3) || \
defined(CONFIG_SYS_FSL_DDR2) || \
@@ -1398,15 +1397,14 @@ int fsl_use_spd(void)
int use_spd = 0;
 
 #ifdef CONFIG_DDR_SPD
-   char buffer[HWCONFIG_BUFFER_SIZE];
-   char *buf = NULL;
+   char buf[HWCONFIG_BUFFER_SIZE];
 
/*
 * Extract hwconfig from environment since we have not properly setup
 * the environment but need it for ddr config params
 */
-   if (env_get_f("hwconfig", buffer, sizeof(buffer)) > 0)
-   buf = buffer;
+   if (env_get_f("hwconfig", buf, sizeof(buf)) < 0)
+   buf[0] = '\0';
 
/* if hwconfig is not enabled, or "sdram" is not defined, use spd */
if (hwconfig_sub_f("fsl_ddr", "sdram", buf)) {
-- 
2.17.1

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


Re: [U-Boot] [U-Boot,6/6] stm32mp1: clock tree update

2018-07-20 Thread Tom Rini
On Mon, Jul 09, 2018 at 03:17:24PM +0200, Patrick Delaunay wrote:

> Configure clock tree for all the devices.
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,2/2] bootmenu: Extend BOOTDELAY help text

2018-07-20 Thread Tom Rini
On Thu, Jul 05, 2018 at 12:38:16PM +, Alex Kiernan wrote:

> Extend BOOTDELAY help text to cover its additional usage within the
> bootmenu command.
> 
> Signed-off-by: Alex Kiernan 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v4, 1/2] ARM64: meson: Sync DT with Linux 4.17.5

2018-07-20 Thread Tom Rini
On Tue, Jul 10, 2018 at 10:01:07AM +0200, Loic Devulder wrote:

> Synchronize the Linux Device Tree for Amlogic Meson GX boards from Linux 
> 4.17.5
> (Linux commit 54fb3c180d05e9dfda892a93413514e99f0cbb19).
> 
> This will enable HDMI_5V for USB Amlogic Meson GXL P212 based boards.
> 
> Signed-off-by: Loic Devulder 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,2/2] spl: Make the spl_nand_load_image static

2018-07-20 Thread Tom Rini
On Wed, Jul 04, 2018 at 03:53:37PM +0200, Michael Trimarchi wrote:

> Change-Id: I1c2f71e75fc052c54fc94b13d0942cb9e75ff1c6
> Signed-off-by: Michael Trimarchi 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 1/1] drivers: rtc: correct week day for mc146818

2018-07-20 Thread Tom Rini
On Sun, Jul 08, 2018 at 12:07:26AM +0200, Heinrich Schuchardt wrote:

> For qemu-x86 the date command produces wrong days of the week:
> Date: 2018-07-06 (Saturday)Time: 18:02:03
> Date: 2018-07-07 (unknown day)Time: 21:02:06
> 
> According to a comment in the Linux driver the mc146818 only updates the
> day of the week if the register value is non-zero.
> 
> Sunday is 1, saturday is 7 unlike in U-Boot (see data sheet
> https://www.nxp.com/docs/en/data-sheet/MC146818.pdf).
> 
> So let's use our library function to determine the day of the week.
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 1/2] env: Include bootdelay in environment if negative

2018-07-20 Thread Tom Rini
On Thu, Jul 05, 2018 at 12:38:15PM +, Alex Kiernan wrote:

> The test for (CONFIG_BOOTDELAY >= 0) has been in U-Boot since the
> beginning, but the meaning of it has changed over time. Allow the
> default to be set for any value, including -ve ones. This allows
> (for example) CONFIG_ENV_IS_NOWHERE to have values for bootdelay in
> its compiled in environment.
> 
> The only thing this changes is where the default for bootdelay can be
> fetched from; before this change you get a compiled in default, after
> you'll pull it from the default value in the environment, but both values
> will be the same. Also if there's a value set in the environment then
> that will take precedence (as before).
> 
> Signed-off-by: Alex Kiernan 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2] fs: btrfs: Fix wrong comparison in logical to physical mapping

2018-07-20 Thread Tom Rini
On Wed, Jul 04, 2018 at 08:23:01PM +0200, Marek Behún wrote:

> The comparison
>   logical > item->logical + item->length
> in btrfs_map_logical_to_physical is wrong and should be instead
>   logical >= item->logical + item->length
> For example, if
>   item->logical = 4096
>   item->length = 4096
> and we are looking for logical = 8192, it is not part of item (item is
> [4096, 8191]). But the comparison is false and we think we have found
> the correct item, although we should be searing in the right subtree.
> 
> This fixes some bugs I encountered.
> 
> Signed-off-by: Marek Behun 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] spl: mmc: Skip RAW mode ARGS sectors if not defined

2018-07-20 Thread Tom Rini
On Tue, Jun 26, 2018 at 09:44:39AM -0700, York Sun wrote:

> RAW mode ARGS sector doesn't have to be used for all falcon boot. Skip
> loading ARGS sectors if not defined.
> 
> Signed-off-by: York Sun 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] board/imgtec/boston: Add new defconfigs to the MAINTAINERS list

2018-07-20 Thread Tom Rini
On Fri, Jul 20, 2018 at 09:01:31AM -0400, Tom Rini wrote:

> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] drivers/ddr/fsl: fix '__hwconfig without a buffer' messages

2018-07-20 Thread York Sun
On 07/20/2018 03:00 PM, Jeremy Gebben wrote:
> Pass an empty buffer instead of NULL if the hwconfig environment
> variable isn't set.
> 
> Signed-off-by: Jeremy Gebben 
> Cc: Stefano Babic 
> Cc: York Sun 
> ---
>  drivers/ddr/fsl/options.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/ddr/fsl/options.c b/drivers/ddr/fsl/options.c
> index 5f2acb1c9d..7639a8b3dd 100644
> --- a/drivers/ddr/fsl/options.c
> +++ b/drivers/ddr/fsl/options.c
> @@ -742,8 +742,7 @@ unsigned int populate_memctl_options(const 
> common_timing_params_t *common_dimm,
>   unsigned int ctrl_num)
>  {
>   unsigned int i;
> - char buffer[HWCONFIG_BUFFER_SIZE];
> - char *buf = NULL;
> + char buf[HWCONFIG_BUFFER_SIZE];
>  #if defined(CONFIG_SYS_FSL_DDR3) || \
>   defined(CONFIG_SYS_FSL_DDR2) || \
>   defined(CONFIG_SYS_FSL_DDR4)
> @@ -757,8 +756,8 @@ unsigned int populate_memctl_options(const 
> common_timing_params_t *common_dimm,
>* Extract hwconfig from environment since we have not properly setup
>* the environment but need it for ddr config params
>*/
> - if (env_get_f("hwconfig", buffer, sizeof(buffer)) > 0)
> - buf = buffer;
> + if (env_get_f("hwconfig", buf, sizeof(buf)) < 0)
> + buf[0] = '\0';
>  

Thanks for bringing it up.

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


Re: [U-Boot] [PATCH] mtd: spi: spi_flash: fix build with dma enabled

2018-07-20 Thread Grygorii Strashko


On 07/16/2018 03:56 AM, Jagan Teki wrote:
> On Fri, Jun 29, 2018 at 12:56 AM, Grygorii Strashko
>  wrote:
>> Fix build with CONFIG_DMA enabled
>>   drivers/mtd/spi/spi_flash.c:376: undefined reference to `dma_memcpy'
>>
>> Signed-off-by: Grygorii Strashko 
>> ---
>>   drivers/mtd/spi/spi_flash.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
>> index c159124..d6cbdf2 100644
>> --- a/drivers/mtd/spi/spi_flash.c
>> +++ b/drivers/mtd/spi/spi_flash.c
>> @@ -457,7 +457,7 @@ int spi_flash_read_common(struct spi_flash *flash, const 
>> u8 *cmd,
>>*/
>>   void __weak spi_flash_copy_mmap(void *data, void *offset, size_t len)
>>   {
>> -#ifdef CONFIG_DMA
>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_DMA)
> 
> What if SPI flash using in SPL with DMA enabled?
> 

It'd require to do additional fix/rework. I've been thinking about it,
but I don't know how to fix it other way - any advice?


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


Re: [U-Boot] [U-Boot,V3,1/2] spl: Fix redundant image of uboot

2018-07-20 Thread Tom Rini
On Fri, Jul 20, 2018 at 10:27:26PM +0200, Michael Nazzareno Trimarchi wrote:

> Hi
> 
> On Fri, Jul 20, 2018 at 10:11 PM, Tom Rini  wrote:
> > On Fri, Jul 20, 2018 at 10:09:00PM +0200, Michael Nazzareno Trimarchi wrote:
> >> Hi Tom
> >>
> >> On Fri, Jul 20, 2018 at 9:54 PM, Tom Rini  wrote:
> >> > On Fri, Jul 06, 2018 at 05:09:22PM +0200, Michael Trimarchi wrote:
> >> >
> >> >> We need to address the redundat image case and undestand if the
> >> >> image is corrupted or not. In error case we need to try the fallback 
> >> >> copy.
> >> >> The function used before was always return 0 without any evaluation of 
> >> >> the
> >> >> error. We try to make it work properly
> >> >>
> >> >> Signed-off-by: Michael Trimarchi 
> >> >> ---
> >> >> Changes V2->V3:
> >> >> Fix patch mistake due the a wrong edit of it
> >> >> Changes V1->V2:
> >> >> Address the comments on using the err variable
> >> >> ---
> >> >>  common/spl/spl_nand.c | 34 +-
> >> >>  1 file changed, 25 insertions(+), 9 deletions(-)
> >> >
> >> > I see two problems here.  First, this is a generic issue (any
> >> > legacy-style U-Boot image that we load should be verified).  Second, we
> >> > need to make this behavior configurable as as-is this overflows one
> >> > board (omapl138_lcdk) and I expect would be problematic for many more
> >> > boards when we make it done more commonly.
> >>
> >> This patch fix a no-working uboot feature and this was the address problem 
> >> on
> >> the specific case. We can call ->verify image every ->load, anyway can you
> >> explain better why you need a configurable behavior?
> >
> > It fixes the legitimate case of having read in bad data and the
> > controller didn't return up an error to us, and it wasn't in the header,
> > yes.  And it needs to be configurable as adding in these checks
> > increases the binary size and various targets will fail to build, such
> > as omapl138_lcdk does with your patch as-is.  Thanks!
> >
> 
> +#if defined(CONFIG_VERIFY_IMAGE)

CONFIG_SPL_VERIFY_IMAGE, for namespace.

> +int verify_image(spl_image)
> +{
> +...
> +}
> +#else
> +int verify_image(spl_image) { return 0; }
> +#endif
> +
>  static int spl_load_image(struct spl_image_info *spl_image,
>   struct spl_image_loader *loader)
>  {
> struct spl_boot_device bootdev;
> +   int ret;
> 
> bootdev.boot_device = loader->boot_device;
> bootdev.boot_device_name = NULL;
> 
> -   return loader->load_image(spl_image, );
> +   ret = loader->load_image(spl_image, );
> +   if (ret)
> +   return -EINVAL;
> +
> +   return verify_image(spl_image);
>  }
> 
> Somenthing like this?
> 
> or return loader->verify_image()

Yes, something like that.  And please pass it through travis-ci for the
world build and seeing if anything fails to fit into size constraints,
thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,V3,1/2] spl: Fix redundant image of uboot

2018-07-20 Thread Michael Nazzareno Trimarchi
Hi

On Fri, Jul 20, 2018 at 10:11 PM, Tom Rini  wrote:
> On Fri, Jul 20, 2018 at 10:09:00PM +0200, Michael Nazzareno Trimarchi wrote:
>> Hi Tom
>>
>> On Fri, Jul 20, 2018 at 9:54 PM, Tom Rini  wrote:
>> > On Fri, Jul 06, 2018 at 05:09:22PM +0200, Michael Trimarchi wrote:
>> >
>> >> We need to address the redundat image case and undestand if the
>> >> image is corrupted or not. In error case we need to try the fallback copy.
>> >> The function used before was always return 0 without any evaluation of the
>> >> error. We try to make it work properly
>> >>
>> >> Signed-off-by: Michael Trimarchi 
>> >> ---
>> >> Changes V2->V3:
>> >> Fix patch mistake due the a wrong edit of it
>> >> Changes V1->V2:
>> >> Address the comments on using the err variable
>> >> ---
>> >>  common/spl/spl_nand.c | 34 +-
>> >>  1 file changed, 25 insertions(+), 9 deletions(-)
>> >
>> > I see two problems here.  First, this is a generic issue (any
>> > legacy-style U-Boot image that we load should be verified).  Second, we
>> > need to make this behavior configurable as as-is this overflows one
>> > board (omapl138_lcdk) and I expect would be problematic for many more
>> > boards when we make it done more commonly.
>>
>> This patch fix a no-working uboot feature and this was the address problem on
>> the specific case. We can call ->verify image every ->load, anyway can you
>> explain better why you need a configurable behavior?
>
> It fixes the legitimate case of having read in bad data and the
> controller didn't return up an error to us, and it wasn't in the header,
> yes.  And it needs to be configurable as adding in these checks
> increases the binary size and various targets will fail to build, such
> as omapl138_lcdk does with your patch as-is.  Thanks!
>

+#if defined(CONFIG_VERIFY_IMAGE)
+int verify_image(spl_image)
+{
+...
+}
+#else
+int verify_image(spl_image) { return 0; }
+#endif
+
 static int spl_load_image(struct spl_image_info *spl_image,
  struct spl_image_loader *loader)
 {
struct spl_boot_device bootdev;
+   int ret;

bootdev.boot_device = loader->boot_device;
bootdev.boot_device_name = NULL;

-   return loader->load_image(spl_image, );
+   ret = loader->load_image(spl_image, );
+   if (ret)
+   return -EINVAL;
+
+   return verify_image(spl_image);
 }

Somenthing like this?

or return loader->verify_image()

Michael

> --
> Tom



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot,V3,1/2] spl: Fix redundant image of uboot

2018-07-20 Thread Tom Rini
On Fri, Jul 20, 2018 at 10:09:00PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi Tom
> 
> On Fri, Jul 20, 2018 at 9:54 PM, Tom Rini  wrote:
> > On Fri, Jul 06, 2018 at 05:09:22PM +0200, Michael Trimarchi wrote:
> >
> >> We need to address the redundat image case and undestand if the
> >> image is corrupted or not. In error case we need to try the fallback copy.
> >> The function used before was always return 0 without any evaluation of the
> >> error. We try to make it work properly
> >>
> >> Signed-off-by: Michael Trimarchi 
> >> ---
> >> Changes V2->V3:
> >> Fix patch mistake due the a wrong edit of it
> >> Changes V1->V2:
> >> Address the comments on using the err variable
> >> ---
> >>  common/spl/spl_nand.c | 34 +-
> >>  1 file changed, 25 insertions(+), 9 deletions(-)
> >
> > I see two problems here.  First, this is a generic issue (any
> > legacy-style U-Boot image that we load should be verified).  Second, we
> > need to make this behavior configurable as as-is this overflows one
> > board (omapl138_lcdk) and I expect would be problematic for many more
> > boards when we make it done more commonly.
> 
> This patch fix a no-working uboot feature and this was the address problem on
> the specific case. We can call ->verify image every ->load, anyway can you
> explain better why you need a configurable behavior?

It fixes the legitimate case of having read in bad data and the
controller didn't return up an error to us, and it wasn't in the header,
yes.  And it needs to be configurable as adding in these checks
increases the binary size and various targets will fail to build, such
as omapl138_lcdk does with your patch as-is.  Thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,V3,1/2] spl: Fix redundant image of uboot

2018-07-20 Thread Michael Nazzareno Trimarchi
Hi Tom

On Fri, Jul 20, 2018 at 9:54 PM, Tom Rini  wrote:
> On Fri, Jul 06, 2018 at 05:09:22PM +0200, Michael Trimarchi wrote:
>
>> We need to address the redundat image case and undestand if the
>> image is corrupted or not. In error case we need to try the fallback copy.
>> The function used before was always return 0 without any evaluation of the
>> error. We try to make it work properly
>>
>> Signed-off-by: Michael Trimarchi 
>> ---
>> Changes V2->V3:
>> Fix patch mistake due the a wrong edit of it
>> Changes V1->V2:
>> Address the comments on using the err variable
>> ---
>>  common/spl/spl_nand.c | 34 +-
>>  1 file changed, 25 insertions(+), 9 deletions(-)
>
> I see two problems here.  First, this is a generic issue (any
> legacy-style U-Boot image that we load should be verified).  Second, we
> need to make this behavior configurable as as-is this overflows one
> board (omapl138_lcdk) and I expect would be problematic for many more
> boards when we make it done more commonly.
>

This patch fix a no-working uboot feature and this was the address problem on
the specific case. We can call ->verify image every ->load, anyway can you
explain better why you need a configurable behavior?

Michael

> --
> Tom



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2] gpio: xilinx: Convert driver to DM

2018-07-20 Thread Stefan Herbrechtsmeier

Hi Michal,

Am 13.07.2018 um 17:20 schrieb Michal Simek:

This patch is enabling GPIO_DM support to have an option to use this
driver together with zynq gpio driver.
!DM part is kept there till Microblaze is cleanup which will be done
hopefully soon.

Just a note:
There is no reason to initialize uc-priv->name because it is completely
unused.

Signed-off-by: Michal Simek 
---

Changes in v2:
- Show value in set_value when debug is enabled
- Implement xlate function
- Remove tabs from structures for alignment (to be consistent with the
   rest of code)

  drivers/gpio/xilinx_gpio.c | 265 -
  1 file changed, 264 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
index 74c5be0865d1..48b52c985a55 100644
--- a/drivers/gpio/xilinx_gpio.c
+++ b/drivers/gpio/xilinx_gpio.c
@@ -1,6 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0+
  /*
- * Copyright (c) 2013 Xilinx, Michal Simek
+ * Copyright (c) 2013 - 2018 Xilinx, Michal Simek
   */
  
  #include 

@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 
  
  static LIST_HEAD(gpio_list);
  
@@ -23,6 +24,8 @@ struct gpio_regs {

u32 gpiodir;
  };
  
+#if !defined(CONFIG_DM_GPIO)

+
  #define GPIO_NAME_SIZE10
  
  struct gpio_names {

@@ -345,3 +348,263 @@ int gpio_alloc_dual(u32 baseaddr, const char *name, u32 
gpio_no0, u32 gpio_no1)
/* Return the first gpio allocated for this device */
return ret;
  }
+#else
+#include 
+
+#define XILINX_GPIO_MAX_BANK   2
+
+struct xilinx_gpio_platdata {
+   struct gpio_regs *regs;
+   int bank_max[XILINX_GPIO_MAX_BANK];
+   int bank_input[XILINX_GPIO_MAX_BANK];
+   int bank_output[XILINX_GPIO_MAX_BANK];
+};
+
+static int xilinx_gpio_get_bank_pin(unsigned offset, u32 *bank_num,
+   u32 *bank_pin_num, struct udevice *dev)
+{
+   struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+   u32 bank, max_pins;
+   /* the first gpio is 0 not 1 */
+   u32 pin_num = offset;
+
+   for (bank = 0; bank < XILINX_GPIO_MAX_BANK; bank++) {
+   max_pins = platdata->bank_max[bank];
+   if (pin_num < max_pins) {
+   debug("%s: found at bank 0x%x pin 0x%x\n", __func__,
+ bank, pin_num);
+   *bank_num = bank;
+   *bank_pin_num = pin_num;
+   return 0;
+   }
+   pin_num -= max_pins;
+   }
+
+   return -EINVAL;
+}
+
+static int xilinx_gpio_set_value(struct udevice *dev, unsigned offset,
+int value)
+{
+   struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+   int val, ret;
+   u32 bank, pin;
+
+   ret = xilinx_gpio_get_bank_pin(offset, , , dev);
+   if (ret)
+   return ret;
+
+   debug("%s: regs: %lx, value: %x, gpio: %x, bank %x, pin %x\n",
+ __func__, (ulong)platdata->regs, value, offset, bank, pin);
+
+   if (value) {
+   val = readl(>regs->gpiodata + bank * 2);
+   val = val | (1 << pin);
+   writel(val, >regs->gpiodata + bank * 2);
+   } else {
+   val = readl(>regs->gpiodata + bank * 2);
+   val = val & ~(1 << pin);
+   writel(val, >regs->gpiodata + bank * 2);
+   }


The old driver doesn't read the value from the register because this 
values represents the external status of the inputs and not the value of 
the outputs. This implementation doesn't works with a wired-OR. 
Additionally you could simplify the code.



+
+   return val;
+};
+
+static int xilinx_gpio_get_value(struct udevice *dev, unsigned offset)
+{
+   struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+   int val, ret;
+   u32 bank, pin;
+
+   ret = xilinx_gpio_get_bank_pin(offset, , , dev);
+   if (ret)
+   return ret;
+
+   debug("%s: regs: %lx, gpio: %x, bank %x, pin %x\n", __func__,
+ (ulong)platdata->regs, offset, bank, pin);
+
+   val = readl(>regs->gpiodata + bank * 2);
+   val = !!(val & (1 << pin));
+
+   return val;
+};
+
+static int xilinx_gpio_get_function(struct udevice *dev, unsigned offset)
+{
+   struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+   int val, ret;
+   u32 bank, pin;
+
+   /* Check if all pins are inputs */
+   if (platdata->bank_input[bank])
+   return GPIOF_INPUT;
+
+   /* Check if all pins are outputs */
+   if (platdata->bank_output[bank])
+   return GPIOF_OUTPUT;
+
+   ret = xilinx_gpio_get_bank_pin(offset, , , dev);
+   if (ret)
+   return ret;


This must be called before the checks otherwise the bank is undefined.


+
+   /* FIXME test on dual */
+   val = readl(>regs->gpiodir + bank * 2);
+   val = !(val & (1 << pin));
+
+   /* 

Re: [U-Boot] [U-Boot,V3,1/2] spl: Fix redundant image of uboot

2018-07-20 Thread Tom Rini
On Fri, Jul 06, 2018 at 05:09:22PM +0200, Michael Trimarchi wrote:

> We need to address the redundat image case and undestand if the
> image is corrupted or not. In error case we need to try the fallback copy.
> The function used before was always return 0 without any evaluation of the
> error. We try to make it work properly
> 
> Signed-off-by: Michael Trimarchi 
> ---
> Changes V2->V3:
> Fix patch mistake due the a wrong edit of it
> Changes V1->V2:
> Address the comments on using the err variable
> ---
>  common/spl/spl_nand.c | 34 +-
>  1 file changed, 25 insertions(+), 9 deletions(-)

I see two problems here.  First, this is a generic issue (any
legacy-style U-Boot image that we load should be verified).  Second, we
need to make this behavior configurable as as-is this overflows one
board (omapl138_lcdk) and I expect would be problematic for many more
boards when we make it done more commonly.

-- 
Tom


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


Re: [U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name

2018-07-20 Thread Stefan Herbrechtsmeier

Hi Michal,

Am 12.07.2018 um 16:04 schrieb Michal Simek:

There should be proper bank name setup to distiguish between different
gpio drivers. Use dev->name for it.

Signed-off-by: Michal Simek 
---

  drivers/gpio/zynq_gpio.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c
index 26f69b1a713f..f793ee5754a8 100644
--- a/drivers/gpio/zynq_gpio.c
+++ b/drivers/gpio/zynq_gpio.c
@@ -337,6 +337,8 @@ static int zynq_gpio_probe(struct udevice *dev)
struct zynq_gpio_privdata *priv = dev_get_priv(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
  
+	uc_priv->bank_name = dev->name;

+
if (priv->p_data)
uc_priv->gpio_count = priv->p_data->ngpio;
  
Does this not lead to ugly names because the gpio number is append to 
the bank_name? Have you check the "gpio status -a" output?


Other drivers use the gpio-bank-name from the device tree.

Best regards
  Stefan


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


Re: [U-Boot] [PATCH 02/17] fs: fat: handle "." and ".." of root dir correctly with fat_itr_resolve()

2018-07-20 Thread Heinrich Schuchardt
On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> FAT's root directory does not have "." nor ".."
> So care must be taken when scanning root directory with fat_itr_resolve().
> Without this patch, any file path starting with "." or ".." will not be
> resolved at all.
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  fs/fat/fat.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index b48f48a751..fd6523c66b 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -927,6 +927,27 @@ static int fat_itr_resolve(fat_itr *itr, const char 
> *path, unsigned type)
>   while (next[0] && !ISDIRDELIM(next[0]))
>   next++;
>  
> + if (itr->is_root) {
> + /* root dir doesn't have "." nor ".." */

I understand why root has no ../ but  /./ should be valid.

On Linux 'ls /./' displays the root directory.

Best regards

Heinrich

> + if next - path) == 1) && !strncmp(path, ".", 1)) ||
> + (((next - path) == 2) && !strncmp(path, "..", 2))) {
> + /* point back to itself */
> + itr->clust = itr->fsdata->root_cluster;
> + itr->dent = NULL;
> + itr->remaining = 0;
> + itr->last_cluster = 0;
> +
> + if (next[0] == 0) {
> + if (type & TYPE_DIR)
> + return 0;
> + else
> + return -ENOENT;
> + }
> +
> + return fat_itr_resolve(itr, next, type);
> + }
> + }
> +
>   while (fat_itr_next(itr)) {
>   int match = 0;
>   unsigned n = max(strlen(itr->name), (size_t)(next - path));
> 

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


Re: [U-Boot] [PATCH 01/17] fs: fat: extend get_fs_info() for write use

2018-07-20 Thread Heinrich Schuchardt
On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> get_fs_info() was introduced in major re-work of read operation by Rob.
> We want to reuse this function in write operation by extending it with
> additional members in fsdata structure.
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  fs/fat/fat.c  | 3 +++
>  include/fat.h | 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index 4efe8a3eda..b48f48a751 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -556,6 +556,9 @@ static int get_fs_info(fsdata *mydata)
>   return ret;
>   }
>  
> + mydata->bs_total_sect = bs.total_sect;
> + mydata->bs_fats = bs.fats;
> +
>   if (mydata->fatsize == 32) {
>   mydata->fatlength = bs.fat32_length;
>   } else {
> diff --git a/include/fat.h b/include/fat.h
> index 09e1423685..0c88b59a4a 100644
> --- a/include/fat.h
> +++ b/include/fat.h
> @@ -173,6 +173,8 @@ typedef struct {
>   int fatbufnum;  /* Used by get_fatent, init to -1 */
>   int rootdir_size;   /* Size of root dir for non-FAT32 */
>   __u32   root_cluster;   /* First cluster of root dir for FAT32 */
> + __u32   bs_total_sect;  /* Boot sector's number of sectors */

How can one sector have multiple sectors?
Please, reword the comment to something more obvious.

Best regards

Heinrich

> + __u8bs_fats;/* Boot sector's number of FATs */
>  } fsdata;
>  
>  static inline u32 clust_to_sect(fsdata *fsdata, u32 clust)
> 

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


Re: [U-Boot] [PATCH 03/17] fs: fat: make directory iterator global for write use

2018-07-20 Thread Heinrich Schuchardt
On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> Directory iterator was introduced in major re-work of read operation by
> Rob. We want to use it for write operation extensively as well.
> This patch makes relevant functions, as well as iterator defition, visible
> outside of fat.c.
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  fs/fat/fat.c  | 39 ++-
>  include/fat.h | 32 
>  2 files changed, 38 insertions(+), 33 deletions(-)
> 
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index fd6523c66b..0f82cbe1bd 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -634,25 +634,6 @@ static int get_fs_info(fsdata *mydata)
>   * For more complete example, see fat_itr_resolve()
>   */
>  
> -typedef struct {
> - fsdata*fsdata;/* filesystem parameters */
> - unsigned   clust; /* current cluster */
> - intlast_cluster;  /* set once we've read last cluster */
> - intis_root;   /* is iterator at root directory */
> - intremaining; /* remaining dent's in current cluster */
> -
> - /* current iterator position values: */
> - dir_entry *dent;  /* current directory entry */
> - char   l_name[VFAT_MAXLEN_BYTES];/* long (vfat) name */
> - char   s_name[14];/* short 8.3 name */
> - char  *name;  /* l_name if there is one, else s_name */
> -
> - /* storage for current cluster in memory: */
> - u8 block[MAX_CLUSTSIZE] __aligned(ARCH_DMA_MINALIGN);
> -} fat_itr;
> -
> -static int fat_itr_isdir(fat_itr *itr);
> -
>  /**
>   * fat_itr_root() - initialize an iterator to start at the root
>   * directory
> @@ -661,7 +642,7 @@ static int fat_itr_isdir(fat_itr *itr);
>   * @fsdata: filesystem data for the partition
>   * @return 0 on success, else -errno
>   */
> -static int fat_itr_root(fat_itr *itr, fsdata *fsdata)
> +int fat_itr_root(fat_itr *itr, fsdata *fsdata)
>  {
>   if (get_fs_info(fsdata))
>   return -ENXIO;
> @@ -693,7 +674,7 @@ static int fat_itr_root(fat_itr *itr, fsdata *fsdata)
>   * @parent: the iterator pointing at a directory entry in the
>   *parent directory of the directory to iterate
>   */
> -static void fat_itr_child(fat_itr *itr, fat_itr *parent)
> +void fat_itr_child(fat_itr *itr, fat_itr *parent)
>  {
>   fsdata *mydata = parent->fsdata;  /* for silly macros */
>   unsigned clustnum = START(parent->dent);
> @@ -713,7 +694,7 @@ static void fat_itr_child(fat_itr *itr, fat_itr *parent)
>   itr->last_cluster = 0;
>  }
>  
> -static void *next_cluster(fat_itr *itr)
> +void *next_cluster(fat_itr *itr)
>  {
>   fsdata *mydata = itr->fsdata;  /* for silly macros */
>   int ret;
> @@ -834,7 +815,7 @@ static dir_entry *extract_vfat_name(fat_itr *itr)
>   * @return boolean, 1 if success or 0 if no more entries in the
>   *current directory
>   */
> -static int fat_itr_next(fat_itr *itr)
> +int fat_itr_next(fat_itr *itr)
>  {
>   dir_entry *dent;
>  
> @@ -879,19 +860,11 @@ static int fat_itr_next(fat_itr *itr)
>   * @itr: the iterator
>   * @return true if cursor is at a directory
>   */
> -static int fat_itr_isdir(fat_itr *itr)
> +int fat_itr_isdir(fat_itr *itr)
>  {
>   return !!(itr->dent->attr & ATTR_DIR);
>  }
>  
> -/*
> - * Helpers:
> - */
> -
> -#define TYPE_FILE 0x1
> -#define TYPE_DIR  0x2
> -#define TYPE_ANY  (TYPE_FILE | TYPE_DIR)
> -
>  /**
>   * fat_itr_resolve() - traverse directory structure to resolve the
>   * requested path.
> @@ -907,7 +880,7 @@ static int fat_itr_isdir(fat_itr *itr)
>   * @type: bitmask of allowable file types
>   * @return 0 on success or -errno
>   */
> -static int fat_itr_resolve(fat_itr *itr, const char *path, unsigned type)
> +int fat_itr_resolve(fat_itr *itr, const char *path, unsigned type)
>  {
>   const char *next;
>  
> diff --git a/include/fat.h b/include/fat.h
> index 0c88b59a4a..577e6b4592 100644
> --- a/include/fat.h
> +++ b/include/fat.h
> @@ -187,6 +187,38 @@ static inline u32 sect_to_clust(fsdata *fsdata, int sect)
>   return (sect - fsdata->data_begin) / fsdata->clust_size;
>  }
>  
> +/*
> + * Directory iterator
> + */
> +
> +#define TYPE_FILE 0x1
> +#define TYPE_DIR  0x2
> +#define TYPE_ANY  (TYPE_FILE | TYPE_DIR)

Please, rename these to something more specific like FS_ITER_ANY.

TYPE_ANY already is defined in fs/reiserfs/reiserfs_private.h:

fs/reiserfs/reiserfs_private.h:160:#define TYPE_ANY 15

Best regards

Heinrich

> +
> +typedef struct {
> + fsdata*fsdata;/* filesystem parameters */
> + unsigned   clust; /* current cluster */
> + intlast_cluster;  /* set once we've read last cluster */
> + intis_root;   /* is iterator at root directory */
> + intremaining; /* remaining dent's in current cluster */
> +
> + /* current iterator position values: */
> + dir_entry *dent;  /* current directory entry */
> + 

Re: [U-Boot] [PATCH 06/17] fs: fat: write returns error code instead of -1

2018-07-20 Thread Heinrich Schuchardt
On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> It would be good that FAT write function return error code instead of
> just returning -1 as fat_read_file() does.
> This patch attempts to address this issue although it is 'best effort
> (or estimate)' for now.
> 
> Signed-off-by: AKASHI Takahiro 

Some of the error message are written with debug() others with printf().

Shouldn't we switch everything to debug() so that the EFI console is not
messed up?

Best regards

Heinrich

> ---
>  fs/fat/fat_write.c | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> index 6c715a70f4..1e4f5af910 100644
> --- a/fs/fat/fat_write.c
> +++ b/fs/fat/fat_write.c
> @@ -956,7 +956,7 @@ static int do_fat_write(const char *filename, void 
> *buffer, loff_t size,
>  
>   if (read_bootsectandvi(, , >fatsize)) {
>   debug("error: reading boot sector\n");
> - return -1;
> + return -EIO;
>   }
>  
>   total_sector = bs.total_sect;
> @@ -997,7 +997,7 @@ static int do_fat_write(const char *filename, void 
> *buffer, loff_t size,
>   mydata->fatbuf = memalign(ARCH_DMA_MINALIGN, FATBUFSIZE);
>   if (mydata->fatbuf == NULL) {
>   debug("Error: allocating memory\n");
> - return -1;
> + return -ENOMEM;
>   }
>  
>   if (disk_read(cursect,
> @@ -1005,6 +1005,7 @@ static int do_fat_write(const char *filename, void 
> *buffer, loff_t size,
>   (mydata->clust_size) :
>   PREFETCH_BLOCKS, do_fat_read_at_block) < 0) {
>   debug("Error: reading rootdir block\n");
> + ret = -EIO;
>   goto exit;
>   }
>   dentptr = (dir_entry *) do_fat_read_at_block;
> @@ -1029,6 +1030,7 @@ static int do_fat_write(const char *filename, void 
> *buffer, loff_t size,
>   size);
>   if (ret) {
>   printf("Error: %llu overflow\n", size);
> + ret = -ENOSPC;
>   goto exit;
>   }
>   }
> @@ -1036,6 +1038,7 @@ static int do_fat_write(const char *filename, void 
> *buffer, loff_t size,
>   ret = clear_fatent(mydata, start_cluster);
>   if (ret) {
>   printf("Error: clearing FAT entries\n");
> + ret = -EIO;
>   goto exit;
>   }
>  
> @@ -1045,12 +1048,14 @@ static int do_fat_write(const char *filename, void 
> *buffer, loff_t size,
>   ret = start_cluster = find_empty_cluster(mydata);
>   if (ret < 0) {
>   printf("Error: finding empty cluster\n");
> + ret = -ENOSPC;
>   goto exit;
>   }
>  
>   ret = check_overflow(mydata, start_cluster, size);
>   if (ret) {
>   printf("Error: %llu overflow\n", size);
> + ret = -ENOSPC;
>   goto exit;
>   }
>  
> @@ -1065,12 +1070,14 @@ static int do_fat_write(const char *filename, void 
> *buffer, loff_t size,
>   ret = start_cluster = find_empty_cluster(mydata);
>   if (ret < 0) {
>   printf("Error: finding empty cluster\n");
> + ret = -ENOSPC;
>   goto exit;
>   }
>  
>   ret = check_overflow(mydata, start_cluster, size);
>   if (ret) {
>   printf("Error: %llu overflow\n", size);
> + ret = -ENOSPC;
>   goto exit;
>   }
>   } else {
> @@ -1087,6 +1094,7 @@ static int do_fat_write(const char *filename, void 
> *buffer, loff_t size,
>   ret = set_contents(mydata, retdent, buffer, size, actwrite);
>   if (ret < 0) {
>   printf("Error: writing contents\n");
> + ret = -EIO;
>   goto exit;
>   }
>   debug("attempt to write 0x%llx bytes\n", *actwrite);
> @@ -1095,14 +1103,17 @@ static int do_fat_write(const char *filename, void 
> *buffer, loff_t size,
>   ret = flush_dirty_fat_buffer(mydata);
>   if (ret) {
>   printf("Error: flush fat buffer\n");
> + ret = -EIO;
>   goto exit;
>   }
>  
>   /* Write directory table to device */
>   ret = set_cluster(mydata, dir_curclust, get_dentfromdir_block,
>   mydata->clust_size * mydata->sect_size);
> - if (ret)
> + if (ret) {
>   printf("Error: writing 

Re: [U-Boot] [PATCH 09/17] fs: fat: support write with non-zero offset

2018-07-20 Thread Heinrich Schuchardt
On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> In this patch, all the necessary code for allowing for a file offset
> at write is implemented. What plays a major roll here is get_set_cluster(),
> which, in contrast to its counterpart, set_cluster(), only operates on
> already-allocated clusters, overwriting with data.
> 
> So, with a file offset specified, set_contents() seeks and writes data
> with set_get_cluster() until the end of a file, and, once it reaches
> there, continues writing with set_cluster() for the rest.
> 
> Please note that a file will be trimmed as a result of write operation if
> write ends before reaching file's end. This is an intended behavior
> in order to maitain compatibility with the current interface.

This does not match the EFI spec.

> 
> Signed-off-by: AKASHI Takahiro 

When testing I observed that I could not write at an offset larger than
the file size. This does not match the EFI spec:

EFI_FILE_PROTOCOL.SetPosition():
seeking past the end of the file is allowed (a subsequent write would
grow the file).

Best regards

Heinrich


> ---
>  fs/fat/fat_write.c | 287 ++---
>  1 file changed, 272 insertions(+), 15 deletions(-)
> 
> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> index 3a9c53e253..cc45a33876 100644
> --- a/fs/fat/fat_write.c
> +++ b/fs/fat/fat_write.c
> @@ -450,6 +450,120 @@ set_cluster(fsdata *mydata, __u32 clustnum, __u8 
> *buffer,
>   return 0;
>  }
>  
> +static __u8 tmpbuf_cluster[MAX_CLUSTSIZE] __aligned(ARCH_DMA_MINALIGN);
> +
> +/*
> + * Read and modify data on existing and consecutive cluster blocks
> + */
> +static int
> +get_set_cluster(fsdata *mydata, __u32 clustnum, loff_t pos, __u8 *buffer,
> + loff_t size, loff_t *gotsize)
> +{
> + unsigned int bytesperclust = mydata->clust_size * mydata->sect_size;
> + __u32 startsect;
> + loff_t wsize;
> + int clustcount, i, ret;
> +
> + *gotsize = 0;
> + if (!size)
> + return 0;
> +
> + assert(pos < bytesperclust);
> + startsect = clust_to_sect(mydata, clustnum);
> +
> + debug("clustnum: %d, startsect: %d, pos: %lld\n", clustnum, startsect,
> + pos);
> +
> + /* partial write at beginning */
> + if (pos) {
> + wsize = min(bytesperclust - pos, size);
> + ret = disk_read(startsect, mydata->clust_size, tmpbuf_cluster);
> + if (ret != mydata->clust_size) {
> + debug("Error reading data (got %d)\n", ret);
> + return -1;
> + }
> +
> + memcpy(tmpbuf_cluster + pos, buffer, wsize);
> + ret = disk_write(startsect, mydata->clust_size, tmpbuf_cluster);
> + if (ret != mydata->clust_size) {
> + debug("Error writing data (got %d)\n", ret);
> + return -1;
> + }
> +
> + size -= wsize;
> + buffer += wsize;
> + *gotsize += wsize;
> +
> + startsect += mydata->clust_size;
> +
> + if (!size)
> + return 0;
> + }
> +
> + /* full-cluster write */
> + if (size >= bytesperclust) {
> + clustcount = lldiv(size, bytesperclust);
> +
> + if (!((unsigned long)buffer & (ARCH_DMA_MINALIGN - 1))) {
> + wsize = clustcount * bytesperclust;
> + ret = disk_write(startsect,
> + clustcount * mydata->clust_size,
> + buffer);
> + if (ret != clustcount * mydata->clust_size) {
> + debug("Error writing data (got %d)\n", ret);
> + return -1;
> + }
> +
> + size -= wsize;
> + buffer += wsize;
> + *gotsize += wsize;
> +
> + startsect += clustcount * mydata->clust_size;
> + } else {
> + for (i = 0; i < clustcount; i++) {
> + memcpy(tmpbuf_cluster, buffer, bytesperclust);
> + ret = disk_write(startsect, mydata->clust_size,
> + tmpbuf_cluster);
> + if (ret != mydata->clust_size) {
> + debug("Error writing data (got %d)\n",
> + ret);
> + return -1;
> + }
> +
> + size -= bytesperclust;
> + buffer += bytesperclust;
> + *gotsize += bytesperclust;
> +
> + startsect += mydata->clust_size;
> + }
> + }
> + }
> +
> + /* partial 

Re: [U-Boot] [PATCH 11/17] fs: add mkdir interface

2018-07-20 Thread Heinrich Schuchardt
On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> "mkdir" interface is added to file operations.
> This is a preparatory change as mkdir support for FAT file system
> will be added in next patch.
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  fs/fs.c  | 45 +
>  include/fs.h | 10 ++
>  2 files changed, 55 insertions(+)
> 
> diff --git a/fs/fs.c b/fs/fs.c
> index 33808d549e..3cb6b21fe9 100644
> --- a/fs/fs.c
> +++ b/fs/fs.c
> @@ -105,6 +105,11 @@ static inline int fs_opendir_unsupported(const char 
> *filename,
>   return -EACCES;
>  }
>  
> +static inline int fs_mkdir_unsupported(const char *dirname)
> +{
> + return -1;
> +}
> +
>  struct fstype_info {
>   int fstype;
>   char *name;
> @@ -142,6 +147,7 @@ struct fstype_info {
>   int (*readdir)(struct fs_dir_stream *dirs, struct fs_dirent **dentp);
>   /* see fs_closedir() */
>   void (*closedir)(struct fs_dir_stream *dirs);
> + int (*mkdir)(const char *dirname);
>  };
>  
>  static struct fstype_info fstypes[] = {
> @@ -165,6 +171,7 @@ static struct fstype_info fstypes[] = {
>   .opendir = fat_opendir,
>   .readdir = fat_readdir,
>   .closedir = fat_closedir,
> + .mkdir = fs_mkdir_unsupported,

Why should we create a dummy function? Just use NULL as an indicator
that the interface method is not implemented. See the use of structures
for the driver model.

@Simon
The array fstypes[] should be replaced by a linker list to match the
driver model.

>   },
>  #endif
>  #ifdef CONFIG_FS_EXT4
> @@ -185,6 +192,7 @@ static struct fstype_info fstypes[] = {
>  #endif
>   .uuid = ext4fs_uuid,
>   .opendir = fs_opendir_unsupported,
> + .mkdir = fs_mkdir_unsupported,
>   },
>  #endif
>  #ifdef CONFIG_SANDBOX
> @@ -201,6 +209,7 @@ static struct fstype_info fstypes[] = {
>   .write = fs_write_sandbox,
>   .uuid = fs_uuid_unsupported,
>   .opendir = fs_opendir_unsupported,
> + .mkdir = fs_mkdir_unsupported,
>   },
>  #endif
>  #ifdef CONFIG_CMD_UBIFS
> @@ -217,6 +226,7 @@ static struct fstype_info fstypes[] = {
>   .write = fs_write_unsupported,
>   .uuid = fs_uuid_unsupported,
>   .opendir = fs_opendir_unsupported,
> + .mkdir = fs_mkdir_unsupported,
>   },
>  #endif
>  #ifdef CONFIG_FS_BTRFS
> @@ -233,6 +243,7 @@ static struct fstype_info fstypes[] = {
>   .write = fs_write_unsupported,
>   .uuid = btrfs_uuid,
>   .opendir = fs_opendir_unsupported,
> + .mkdir = fs_mkdir_unsupported,
>   },
>  #endif
>   {
> @@ -248,6 +259,7 @@ static struct fstype_info fstypes[] = {
>   .write = fs_write_unsupported,
>   .uuid = fs_uuid_unsupported,
>   .opendir = fs_opendir_unsupported,
> + .mkdir = fs_mkdir_unsupported,
>   },
>  };
>  
> @@ -498,6 +510,20 @@ void fs_closedir(struct fs_dir_stream *dirs)
>  }
>  
>  
> +int fs_mkdir(const char *dirname)
> +{
> + int ret;
> +
> + struct fstype_info *info = fs_get_info(fs_type);
> +
> + ret = info->mkdir(dirname);

Please, check if mkdir is NULL before calling.

> +
> + fs_type = FS_TYPE_ANY;
> + fs_close();

What do you want to close here if mkdir() is not implemented by the file
system?

Best regards

Heinrich

> +
> + return ret;
> +}
> +
>  int do_size(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
>   int fstype)
>  {
> @@ -700,3 +726,22 @@ int do_fs_type(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
>   return CMD_RET_SUCCESS;
>  }
>  
> +int do_mkdir(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
> + int fstype)
> +{
> + int ret;
> +
> + if (argc != 4)
> + return CMD_RET_USAGE;
> +
> + if (fs_set_blk_dev(argv[1], argv[2], fstype))
> + return 1;
> +
> + ret = fs_mkdir(argv[3]);
> + if (ret) {
> + printf("** Unable to create a directory \"%s\" **\n", argv[3]);
> + return 1;
> + }
> +
> + return 0;
> +}
> diff --git a/include/fs.h b/include/fs.h
> index 163da103b4..fbaee154dd 100644
> --- a/include/fs.h
> +++ b/include/fs.h
> @@ -155,6 +155,14 @@ struct fs_dirent *fs_readdir(struct fs_dir_stream *dirs);
>   */
>  void fs_closedir(struct fs_dir_stream *dirs);
>  
> +/*
> + * fs_mkdir - Create a directory
> + *
> + * @filename: Name of directory to create
> + * @return 0 on success, -1 on error conditions
> + */
> +int fs_mkdir(const char *filename);
> +
>  /*
>   * Common implementation for various filesystem commands, optionally limited
>   * to a specific filesystem type via the fstype parameter.
> @@ -169,6 +177,8 @@ int file_exists(const char *dev_type, const char 
> *dev_part, const char *file,
>   int fstype);
>  int 

Re: [U-Boot] [U-Boot, 1/3] arm: dts: rockchip: add some common pin-settings to rk3399

2018-07-20 Thread Philipp Tomsich
> From: Randy Li 
> 
> Those pins would be used by many boards.
> 
> Signed-off-by: Randy Li 
> Signed-off-by: Heiko Stuebner 
> Signed-off-by: Ezequiel Garcia 
> Reviewed-by: Simon Glass 
> Reviewed-by: Philipp Tomsich 
> ---
>  arch/arm/dts/rk3399.dtsi | 55 +++-
>  1 file changed, 49 insertions(+), 6 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, 3/3] rockchip: rk3399: Add more instructions to the README

2018-07-20 Thread Philipp Tomsich
> This commit adds a content section and also instructions
> on how to create a bootable SD/MMC device for RK3399 boards.
> 
> Signed-off-by: Ezequiel Garcia 
> Reviewed-by: Simon Glass 
> Reviewed-by: Philipp Tomsich 
> ---
>  board/rockchip/evb_rk3399/README | 55 ++--
>  1 file changed, 53 insertions(+), 2 deletions(-)
> 

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


Re: [U-Boot] [U-Boot,2/3] ARM: add RK3399 Ficus board

2018-07-20 Thread Philipp Tomsich
> This commit adds support for RK3399 Ficus board,
> aka ROCK960 Enterprise Edition.
> 
> Following peripherals are tested and known to work:
> * Gigabit Ethernet
> * USB 2.0
> * MMC
> 
> Signed-off-by: Ezequiel Garcia 
> Reviewed-by: Simon Glass 
> Reviewed-by: Philipp Tomsich 
> ---
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/rk3399-ficus.dts| 564 +++
>  board/rockchip/evb_rk3399/README |   2 +
>  configs/ficus-rk3399_defconfig   |  71 
>  4 files changed, 638 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-ficus.dts
>  create mode 100644 configs/ficus-rk3399_defconfig
> 

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


Re: [U-Boot] [U-Boot, 1/3] arm: dts: rockchip: add some common pin-settings to rk3399

2018-07-20 Thread Dr. Philipp Tomsich

> On 20 Jul 2018, at 19:14, Ezequiel Garcia  wrote:
> 
> On Fri, 2018-07-20 at 18:26 +0200, Philipp Tomsich wrote:
>> 
>> On Mon, 16 Jul 2018, Ezequiel Garcia wrote:
>> 
>>> From: Randy Li 
>>> 
>>> Those pins would be used by many boards.
>> 
>> The Rockchip pinctrl driver in U-Boot does not (yet) read the DTS for pin 
>> configuration information.
>> 
>> Is this a sync of the Linux DTS (which seems unlikely, as I'd expect more 
>> changes) or why are we doing this as part of this series?
>> 
> 
> As a matter of fact, it is a sync. It is literally this commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?h=v4.19-armsoc/dts64=b41023282d07b61a53e2c9b9508912b1e7ce7b4f
> 
> It's just needed so that at least the ficus.dts file compiles.
> 
> Thanks,
> Eze

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


Re: [U-Boot] [U-Boot, 3/4] dm: led: move default state support in led uclass

2018-07-20 Thread Patrick DELAUNAY
Hi Tom

> From: Tom Rini 
> Sent: vendredi 20 juillet 2018 15:54
> 
> On Fri, Jul 13, 2018 at 05:21:10PM +0200, Patrick Delaunay wrote:
> 
> > This patch save common LED property "default-state" value in post bind
> > of LED uclass.
> >
> > Signed-off-by: Patrick Delaunay 
> > Reviewed-by: Simon Glass 
> 
> Making the change like this breaks (and leaves broken) the default state test 
> in
> test/dm/led.c so 'make tests' fails.  Please rework the series to include 
> fixing the
> test, thanks!

Sorry for the disturbance...

I tried this compilation but I was blocked by lib SDL issues and other 
configuration on my PC and I push the patch without test execution.  
Today I take the time to solve my compilation issue and I reproduce the test 
error.

I will push a corrective version of this patch next Monday.

Today I add a board_init function for sandbox arch to call the added 
function... it is now working in sandbox:
./u-boot -d ./arch/sandbox/dts/test.dtb

but I have still issue with test because board_init() is not called.

> --
> Tom

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


Re: [U-Boot] [U-Boot, 1/3] arm: dts: rockchip: add some common pin-settings to rk3399

2018-07-20 Thread Ezequiel Garcia
On Fri, 2018-07-20 at 18:26 +0200, Philipp Tomsich wrote:
> 
> On Mon, 16 Jul 2018, Ezequiel Garcia wrote:
> 
> > From: Randy Li 
> > 
> > Those pins would be used by many boards.
> 
> The Rockchip pinctrl driver in U-Boot does not (yet) read the DTS for pin 
> configuration information.
> 
> Is this a sync of the Linux DTS (which seems unlikely, as I'd expect more 
> changes) or why are we doing this as part of this series?
> 

As a matter of fact, it is a sync. It is literally this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?h=v4.19-armsoc/dts64=b41023282d07b61a53e2c9b9508912b1e7ce7b4f

It's just needed so that at least the ficus.dts file compiles.

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


Re: [U-Boot] [PATCH 13/17] fs: fat: support mkdir

2018-07-20 Thread Heinrich Schuchardt
On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> In this patch, mkdir support is added to FAT file system.
> A newly created directory contains only "." and ".." entries.
> 
> Signed-off-by: AKASHI Takahiro 

The patch does set the creation date of the directory according to the
real time clock but to 1980-01-01T00:00:00Z.

$ ls /mnt/dir1/ -la --full-time
drwxr-xr-x 2 root root  2048 1980-01-01 01:00:00.0 +0100 dir3

Please, set the time correctly if the real time clock is available.

Best regards

Heinrich

> ---
>  fs/fat/fat_write.c | 138 +
>  fs/fs.c|   3 +-
>  include/fat.h  |   1 +
>  3 files changed, 141 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> index cc45a33876..781883c9f4 100644
> --- a/fs/fat/fat_write.c
> +++ b/fs/fat/fat_write.c
> @@ -1185,3 +1185,141 @@ int file_fat_write(const char *filename, void 
> *buffer, loff_t offset,
>  {
>   return file_fat_write_at(filename, offset, buffer, maxsize, actwrite);
>  }
> +
> +int fat_mkdir(const char *new_dirname)
> +{
> + dir_entry *retdent;
> + fsdata datablock = { .fatbuf = NULL, };
> + fsdata *mydata = 
> + fat_itr *itr = NULL;
> + char *dirname_copy, *parent, *dirname;
> + char l_dirname[VFAT_MAXLEN_BYTES];
> + int ret = -1;
> + loff_t actwrite;
> + unsigned int bytesperclust;
> + dir_entry *dotdent = NULL;
> +
> + dirname_copy = strdup(new_dirname);
> + if (!dirname_copy)
> + goto exit;
> +
> + split_filename(dirname_copy, , );
> + if (!strlen(dirname)) {
> + ret = -EINVAL;
> + goto exit;
> + }
> +
> + if (normalize_longname(l_dirname, dirname)) {
> + printf("FAT: illegal filename (%s)\n", dirname);
> + ret = -EINVAL;
> + goto exit;
> + }
> +
> + itr = malloc_cache_aligned(sizeof(fat_itr));
> + if (!itr) {
> + ret = -ENOMEM;
> + goto exit;
> + }
> +
> + ret = fat_itr_root(itr, );
> + if (ret)
> + goto exit;
> +
> + total_sector = datablock.bs_total_sect;
> + if (total_sector == 0)
> + total_sector = (int)cur_part_info.size; /* cast of lbaint_t */
> +
> + ret = fat_itr_resolve(itr, parent, TYPE_DIR);
> + if (ret) {
> + printf("%s: doesn't exist (%d)\n", parent, ret);
> + goto exit;
> + }
> +
> + retdent = find_directory_entry(itr, l_dirname);
> +
> + if (retdent) {
> + printf("%s: already exists\n", l_dirname);
> + ret = -EEXIST;
> + goto exit;
> + } else {
> + if (itr->is_root) {
> + /* root dir cannot have "." or ".." */
> + if (!strcmp(l_dirname, ".") ||
> + !strcmp(l_dirname, "..")) {
> + ret = -EINVAL;
> + goto exit;
> + }
> + }
> +
> + if (!itr->dent) {
> + printf("Error: allocating new dir entry\n");
> + ret = -EIO;
> + goto exit;
> + }
> +
> + memset(itr->dent, 0, sizeof(*itr->dent));
> +
> + /* Set short name to set alias checksum field in dir_slot */
> + set_name(itr->dent, dirname);
> + fill_dir_slot(itr, dirname);
> +
> + /* Set attribute as archieve for regular file */
> + fill_dentry(itr->fsdata, itr->dent, dirname, 0, 0,
> + ATTR_DIR | ATTR_ARCH);
> +
> + retdent = itr->dent;
> + }
> +
> + /* Default entries */
> + bytesperclust = mydata->clust_size * mydata->sect_size;
> + dotdent = malloc_cache_aligned(bytesperclust);
> + if (!dotdent) {
> + ret = -ENOMEM;
> + goto exit;
> + }
> + memset(dotdent, 0, bytesperclust);
> +
> + memcpy(dotdent[0].name, ".   ", 8);
> + memcpy(dotdent[0].ext, "   ", 3);
> + dotdent[0].attr = ATTR_DIR | ATTR_ARCH;
> +
> + memcpy(dotdent[1].name, "..  ", 8);
> + memcpy(dotdent[1].ext, "   ", 3);
> + dotdent[1].attr = ATTR_DIR | ATTR_ARCH;
> + set_start_cluster(mydata, [1], itr->start_clust);
> +
> + ret = set_contents(mydata, retdent, 0, (__u8 *)dotdent, bytesperclust,
> + );
> + if (ret < 0) {
> + printf("Error: writing contents\n");
> + goto exit;
> + }
> + /* Write twice for "." */
> + set_start_cluster(mydata, [0], START(retdent));
> + ret = set_contents(mydata, retdent, 0, (__u8 *)dotdent, bytesperclust,
> + );
> + if (ret < 0) {
> + printf("Error: writing contents\n");
> + goto exit;
> + }
> +
> + /* Flush fat buffer */
> + 

Re: [U-Boot] [U-Boot, 3/3] rockchip: rk3399: Add more instructions to the README

2018-07-20 Thread Dr. Philipp Tomsich
Thanks for the clarification, I’ll take this as-is.

> On 20 Jul 2018, at 19:09, Ezequiel Garcia  wrote:
> 
> On Fri, 2018-07-20 at 18:28 +0200, Philipp Tomsich wrote:
>> 
>> On Mon, 16 Jul 2018, Ezequiel Garcia wrote:
>> 
>>> This commit adds a content section and also instructions
>>> on how to create a bootable SD/MMC device for RK3399 boards.
>> 
>> Are any of these instructions Ficus-specific?  We have our own README for 
>> our own boards, as these have different instructions from the EVB boards.
>> 
> 
> Nope, it applies to any rk3399 board. And the rest of the file as well,
> as long as the board has eMMC.
> 
>> Just wondering, as I'd have expected this to come in as part of the ficus 
>> board-directory...
>> 
> 
> Yeah, but all the instructions on this file applied to the Ficus
> (and to many others) so I decided to just extend it for now.
> 
> If it needs moving to some generic doc, I think we can do that as a follow up 
> patch.
> 
>>> Signed-off-by: Ezequiel Garcia 
>>> Reviewed-by: Simon Glass 
>> 
>> Reviewed-by: Philipp Tomsich 
>> 
> 
> Thanks for the review!
> Eze

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


Re: [U-Boot] [PATCH 14/17] cmd: fat: add fatmkdir command

2018-07-20 Thread Heinrich Schuchardt
On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> In this patch, a new command, fatmkdir, is added.
> 
> Please note that, as there is no notion of "current directory" on u-boot,
> a directory name specified must contains an absolute directory path as
> a parent directory. Otherwise, "/" (root directory) is assumed.
> 
> Signed-off-by: AKASHI Takahiro 
> ---

Please, provide a Python test with an additional patch.

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


Re: [U-Boot] [U-Boot, 3/3] rockchip: rk3399: Add more instructions to the README

2018-07-20 Thread Ezequiel Garcia
On Fri, 2018-07-20 at 18:28 +0200, Philipp Tomsich wrote:
> 
> On Mon, 16 Jul 2018, Ezequiel Garcia wrote:
> 
> > This commit adds a content section and also instructions
> > on how to create a bootable SD/MMC device for RK3399 boards.
> 
> Are any of these instructions Ficus-specific?  We have our own README for 
> our own boards, as these have different instructions from the EVB boards.
> 

Nope, it applies to any rk3399 board. And the rest of the file as well,
as long as the board has eMMC.

> Just wondering, as I'd have expected this to come in as part of the ficus 
> board-directory...
> 

Yeah, but all the instructions on this file applied to the Ficus
(and to many others) so I decided to just extend it for now.

If it needs moving to some generic doc, I think we can do that as a follow up 
patch.

> > Signed-off-by: Ezequiel Garcia 
> > Reviewed-by: Simon Glass 
> 
> Reviewed-by: Philipp Tomsich 
> 

Thanks for the review!
Eze
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v3, 8/9] usb: rockchip: fix printing csw debug info

2018-07-20 Thread Philipp Tomsich



On Thu, 12 Jul 2018, Alberto Panizzo wrote:


Workstation tool was happy while console on device were printing
random numbers..


Please provide a more meaningful commit message.



Signed-off-by: Alberto Panizzo 
---
drivers/usb/gadget/f_rockusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
index 0959b8c..574d610 100644
--- a/drivers/usb/gadget/f_rockusb.c
+++ b/drivers/usb/gadget/f_rockusb.c
@@ -384,7 +384,7 @@ static int rockusb_tx_write_csw(u32 tag, int residue, u8 
status, int size)
csw->residue = cpu_to_be32(residue);
csw->status = status;
#ifdef DEBUG
-   printcsw((char *));
+   printcsw((char *)csw);
#endif
return rockusb_tx_write((char *)csw, size);
}


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


Re: [U-Boot] [U-Boot, v3, 3/9] rockchip: rk3288: implement reading chip version from bootrom code

2018-07-20 Thread Philipp Tomsich



On Thu, 12 Jul 2018, Alberto Panizzo wrote:


This allows rockusb code to reply correctly to K_FW_GET_CHIP_VER
command.

On RK3288 chip version is at 0x4ff0 and on tested hardware it
corresponds at the string "320A20140813V200"

Signed-off-by: Alberto Panizzo 
Reviewed-by: Simon Glass 


Reviewed-by: Philipp Tomsich 

See below for requested changes.


---
arch/arm/mach-rockchip/rk3288/Makefile |  1 +
arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c | 30 ++
2 files changed, 31 insertions(+)
create mode 100644 arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c

diff --git a/arch/arm/mach-rockchip/rk3288/Makefile 
b/arch/arm/mach-rockchip/rk3288/Makefile
index a0033a0..da0eb4a 100644
--- a/arch/arm/mach-rockchip/rk3288/Makefile
+++ b/arch/arm/mach-rockchip/rk3288/Makefile
@@ -7,3 +7,4 @@
obj-y += clk_rk3288.o
obj-y += rk3288.o
obj-y += syscon_rk3288.o
+obj-$(CONFIG_USB_FUNCTION_ROCKUSB) += rockusb_rk3288.o


This should be conditional on the RK3288.
After all, the below code implements a weak function specifically for the 
RK3288.


We might want to decide on a better architecture (a misc device maybe?) 
that allows us to abstract the various chips' methods to access the device 
id in a more DM-aware way.



diff --git a/arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c 
b/arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c
new file mode 100644
index 000..62057c1
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Written by Alberto Panizzo 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ROM_PHYS   0x
+
+#define ROM_CHIP_VER_ADDR_ADDR (ROM_PHYS + 0x4FF0)
+#define ROM_CHIP_VER_ADDR_SIZE 16
+
+int rk_get_bootrom_chip_version(unsigned int *chip_info, int size)
+{
+   if (!chip_info)
+   return -1;
+   if (size < ROM_CHIP_VER_ADDR_SIZE / sizeof(int))
+   return -1;


This should use appropriate error-codes.


+
+   memcpy((char *)chip_info, (char *)ROM_CHIP_VER_ADDR_ADDR,
+  ROM_CHIP_VER_ADDR_SIZE);
+
+   return 0;
+}


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


Re: [U-Boot] [U-Boot, v3, 2/9] usb: rockchip: implement skeleton for K_FW_GET_CHIP_VER command

2018-07-20 Thread Philipp Tomsich



On Thu, 12 Jul 2018, Alberto Panizzo wrote:


Chip Version is a string saved in BOOTROM address space Little Endian.


There's just one tiny problem: the BOOTROM will not be accessible on ARMv8 
targets after ATF has been loaded.


We should define a common mechanism how to deal with this (e.g. by 
injecting it into the DTS of later stages during SPL) and then provide a 
common abstraction over the platforms that always allow accessing the 
BootROM and those that require additional magic.




Ex for rk3288: 0x33323041 0x32303134 0x30383133 0x56323030
which brings:  320A20140813V200

Note that memory version do invert MSB/LSB so printing the char
buffer would show: A02341023180002V

Signed-off-by: Alberto Panizzo 


Reviewed-by: Philipp Tomsich 

Other requested changes (on top of the architectural one from above) 
below.



---
doc/README.rockusb |  9 ++---
drivers/usb/gadget/f_rockusb.c | 44 +-
2 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/doc/README.rockusb b/doc/README.rockusb
index 5405dc4..3a93edc 100644
--- a/doc/README.rockusb
+++ b/doc/README.rockusb
@@ -42,9 +42,12 @@ see doc/README.rockchip for more detail about how to get 
U-Boot binary.

sudo rkdeveloptool wl  64 

-There are plenty of Rockusb command. but wl(write lba) and
-rd(reboot) command. These two command can let people flash
-image to device.
+Current set of rkdeveloptool commands supported:
+- rci: Read Chip Info
+- rfi: Read Flash Id
+- rd : Reset Device
+- td : Test Device Ready
+- wl : Write blocks using LBA

To do
-
diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
index 58e483c..0314ff0 100644
--- a/drivers/usb/gadget/f_rockusb.c
+++ b/drivers/usb/gadget/f_rockusb.c
@@ -523,6 +523,48 @@ static void cb_read_storage_id(struct usb_ep *ep, struct 
usb_request *req)
rockusb_tx_write_str(emmc_id);
}

+int __weak rk_get_bootrom_chip_version(unsigned int *chip_info, int size)
+{
+   return 0


The default implementation should return an appropriate error code.
Also, I would recommend to return the number of bytes used in the bootrom 
chip-version on the chip this is implemented for.


Documentation for the rk_get_bootrom_chip_version might be useful too 
(e.g. is 'size' a maximum buffer size that needs to be checked against)?



+}
+
+static void cb_get_chip_version(struct usb_ep *ep, struct usb_request *req)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(struct fsg_bulk_cb_wrap, cbw,
+sizeof(struct fsg_bulk_cb_wrap));
+   struct f_rockusb *f_rkusb = get_rkusb();
+   unsigned int chip_info[4], i;
+
+   memset(chip_info, 0, sizeof(chip_info));


While it doesn't hurt, there's no need to perform a memset... you will 
call rk_get_bootrom_chip_version() next anyway.



+   rk_get_bootrom_chip_version(chip_info, 4);


You should check the error code returned (e.g. in case that a CPU does not 
implement this).  Also: why is the 4 open-coded here and sizeof(chip_info) 
above?



+
+   /*
+* Chip Version is a string saved in BOOTROM address space Little Endian
+*
+* Ex for rk3288: 0x33323041 0x32303134 0x30383133 0x56323030
+* which brings:  320A20140813V200
+*
+* Note that memory version do invert MSB/LSB so printing the char
+* buffer will show: A02341023180002V
+*/
+   printf("read chip version: ");
+   for (i = 0; i < 4; i++) {
+   printf("%c%c%c%c",
+  (chip_info[i] >> 24) & 0xFF,
+  (chip_info[i] >> 16) & 0xFF,
+  (chip_info[i] >>  8) & 0xFF,
+  (chip_info[i] >>  0) & 0xFF);


I'd recommend to do first swap using the functions from 
include/linux/byteorder/generic.h and then just print as a string...


Why the printf? I think you want a debug() ...


+   }
+   printf("\n");


Same.


+   memcpy((char *)cbw, req->buf, USB_BULK_CB_WRAP_LEN);
+
+   /* Prepare for sending subsequent CSW_GOOD */
+   f_rkusb->tag = cbw->tag;
+   f_rkusb->in_req->complete = tx_handler_send_csw;
+
+   rockusb_tx_write((char *)chip_info, sizeof(chip_info));
+}
+
static void cb_write_lba(struct usb_ep *ep, struct usb_request *req)
{
ALLOC_CACHE_ALIGN_BUFFER(struct fsg_bulk_cb_wrap, cbw,
@@ -661,7 +703,7 @@ static const struct cmd_dispatch_info cmd_dispatch_info[] = 
{
},
{
.cmd = K_FW_GET_CHIP_VER,
-   .cb = cb_not_support,
+   .cb = cb_get_chip_version,
},
{
.cmd = K_FW_LOW_FORMAT,


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


Re: [U-Boot] [U-Boot, v3, 1/9] usb: rockchip: fix command failed on host side due to missing data

2018-07-20 Thread Philipp Tomsich



On Thu, 12 Jul 2018, Alberto Panizzo wrote:


Two consecutive rockusb_tx_write without waiting for request complete
do results in transfer reset of first request and thus no or incomplete
data transfer. This because rockusb_tx_write do use just one USB request
to keep serialization.

So calls like:
rockusb_tx_write_str(emmc_id);
rockusb_tx_write_csw(cbw->tag, cbw->data_transfer_length, CSW_GOOD);

was succeeding only when DEBUG was defined because the time spent
printing debug info was enough for transfer to complete.

This patch fixes the issue adding a simple request complete handler
called rockusb_tx_write_csw to be set as complete handler of in_req
when sending back simple payload + CSW replies to commands.

This new handler will always send CSW_GOOD replies because in case
of error the command callback itself must send back an error CSW as
unique reply to command.

This patch fixes execution of:
$ rkdeveloptool rfi
when DEBUG is not defined.

Signed-off-by: Alberto Panizzo 
---
drivers/usb/gadget/f_rockusb.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
index b8833d0..58e483c 100644
--- a/drivers/usb/gadget/f_rockusb.c
+++ b/drivers/usb/gadget/f_rockusb.c
@@ -388,6 +388,20 @@ static int rockusb_tx_write_csw(u32 tag, int residue, u8 
status, int size)
return rockusb_tx_write((char *)csw, size);
}

+static void tx_handler_send_csw(struct usb_ep *ep, struct usb_request *req)
+{
+   struct f_rockusb *f_rkusb = get_rkusb();
+   int status = req->status;
+
+   if (status)
+   debug("status: %d ep '%s' trans: %d\n",
+ status, ep->name, req->actual);


This looks like an error-message.  So shouldn't you always signal the 
error to the use, even if DEBUG is not defined?



+
+   /* Return back to default in_req complete function after sending CSW */
+   req->complete = rockusb_complete;
+   rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_GOOD, USB_BULK_CS_WRAP_LEN);
+}
+
static unsigned int rx_bytes_expected(struct usb_ep *ep)
{
struct f_rockusb *f_rkusb = get_rkusb();
@@ -496,13 +510,17 @@ static void cb_read_storage_id(struct usb_ep *ep, struct 
usb_request *req)
{
ALLOC_CACHE_ALIGN_BUFFER(struct fsg_bulk_cb_wrap, cbw,
 sizeof(struct fsg_bulk_cb_wrap));
+   struct f_rockusb *f_rkusb = get_rkusb();
char emmc_id[] = "EMMC ";

printf("read storage id\n");


Should this really be a 'printf'?


memcpy((char *)cbw, req->buf, USB_BULK_CB_WRAP_LEN);
+
+   /* Prepare for sending subsequent CSW_GOOD */
+   f_rkusb->tag = cbw->tag;
+   f_rkusb->in_req->complete = tx_handler_send_csw;
+
rockusb_tx_write_str(emmc_id);
-   rockusb_tx_write_csw(cbw->tag, cbw->data_transfer_length, CSW_GOOD,
-USB_BULK_CS_WRAP_LEN);
}

static void cb_write_lba(struct usb_ep *ep, struct usb_request *req)


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


Re: [U-Boot] [U-Boot, v3, 6/9] usb: rockchip: be quiet on serial port while transferring data

2018-07-20 Thread Philipp Tomsich
> While downloading or uploading megabytes of data we had thousands of
> printf in console like:
> 
> transfer 0x1 bytes done
> OR
> Uploading 0x1000 bytes
> 
> This because transfers are chunked and there is no way on target
> side to know the overall transfer size (to print one string per
> overall transfer).
> 
> All these prints on serial console do slow down significantly the
> transfer and does not offer a significant information to the
> developer: rkdeveloptool and Rockchip original tool do use small
> chunks read/writes on big transfers. This allows on workstation
> to print percentage of transfer complete and as well offers to
> developer the information about: transfer is running OK.
> On error, either the percentage will stop or an error will be shown
> on workstation console.
> 
> Signed-off-by: Alberto Panizzo 
> ---
>  drivers/usb/gadget/f_rockusb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, v3, 5/9] usb: rockchip: implement K_FW_LBA_ERASE_10 command

2018-07-20 Thread Philipp Tomsich
> This command is part of the write partition sequence performed by
> rkdeveloptool: one partition is first completely erased and
> than wrote.
> 
> Signed-off-by: Alberto Panizzo 
> Reviewed-by: Simon Glass 
> ---
>  arch/arm/include/asm/arch-rockchip/f_rockusb.h |  1 +
>  doc/README.rockusb |  1 +
>  drivers/usb/gadget/f_rockusb.c | 48 
> ++
>  3 files changed, 50 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v3, 4/9] usb: rockchip: implement K_FW_LBA_READ_10 command

2018-07-20 Thread Philipp Tomsich
> This patch implement reading blocks form selected device with
> LBA addressing.
> 
> Corresponding command on workstation is:
> rkdeveloptool rl   
> 
> While we support reading more than one blocks per K_FW_LBA_READ_10
> request, rkdeveloptool and original rockchip tool do perform
> chunk reads limiting the maximum size per chunk far lower
> than max int values.
> 
> Signed-off-by: Alberto Panizzo 
> Reviewed-by: Simon Glass 
> ---
>  arch/arm/include/asm/arch-rockchip/f_rockusb.h |   3 +
>  doc/README.rockusb |   1 +
>  drivers/usb/gadget/f_rockusb.c | 104 
> -
>  3 files changed, 107 insertions(+), 1 deletion(-)
> 

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


Re: [U-Boot] [U-Boot,5/5] rk3288: vyasa: Fixup indentation

2018-07-20 Thread Philipp Tomsich
> Indent file using tabs
> 
> Signed-off-by: Alberto Panizzo 
> ---
>  board/amarula/vyasa-rk3288/vyasa-rk3288.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, 3/5] rockchip: rk3288-vyasa: increase heap space after relocation

2018-07-20 Thread Philipp Tomsich
> Before relocation (TPL or early SPL) we are executing in internal
> SDRAM with limited space.
> As soon as SPL is relocated increase malloc size, big enough
> to manage loading kernel images from eMMC
> 
> Signed-off-by: Alberto Panizzo 
> ---
>  configs/vyasa-rk3288_defconfig | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, 4/5] rk3288: vyasa: Allow booting from internal eMMC

2018-07-20 Thread Philipp Tomsich
> Keeping SD-Card as priority for easy board recovery
> 
> Signed-off-by: Alberto Panizzo 
> Reviewed-by: Jagan Teki 
> ---
>  include/configs/vyasa-rk3288.h | 1 +
>  1 file changed, 1 insertion(+)
> 

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


Re: [U-Boot] [U-Boot,2/3] ARM: add RK3399 Ficus board

2018-07-20 Thread Philipp Tomsich
> This commit adds support for RK3399 Ficus board,
> aka ROCK960 Enterprise Edition.
> 
> Following peripherals are tested and known to work:
> * Gigabit Ethernet
> * USB 2.0
> * MMC
> 
> Signed-off-by: Ezequiel Garcia 
> Reviewed-by: Simon Glass 
> ---
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/rk3399-ficus.dts| 564 +++
>  board/rockchip/evb_rk3399/README |   2 +
>  configs/ficus-rk3399_defconfig   |  71 
>  4 files changed, 638 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-ficus.dts
>  create mode 100644 configs/ficus-rk3399_defconfig
> 

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


Re: [U-Boot] [U-Boot, 1/5] mmc: dw_mmc: prevent silent memory corruption when stack and heap are too small

2018-07-20 Thread Philipp Tomsich
> ALLOC_CACHE_ALIGN_BUFFER was called here in a way to alloc in stack a
> possible huge quantity of memory depending on data transer size.
> 
> Es: loading kernel 8MB from eMMC we have
> Transfer size:   0x80
> Block size:  0x200
> Transfer blocks: 0x4000
> struct size: 0x10
> Stack allocation: ((0x200 / 8) + 1) * 0x10 = 0x8010 (~32KB)
> 
> Since this allocation is done on stack, there is no current way to get
> an error on stack memory limit exceeded, overlapping heap space on
> environments with very strict stack + heap limits like TPL or SPL (where
> malloc size can be 16KB).
> Results are silent corruptions of heap on mmc transfer and random errors
> or CPU hang.
> 
> Using malloc_cache_aligned() we will alloc slightly bigger buffers
> but we do have evidence about memory allocation failure allowing developer
> to recognize the issue and take actions.
> 
> Signed-off-by: Alberto Panizzo 
> ---
>  drivers/mmc/dw_mmc.c | 33 +
>  1 file changed, 25 insertions(+), 8 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, 3/3] rockchip: rk3399: Add more instructions to the README

2018-07-20 Thread Philipp Tomsich



On Mon, 16 Jul 2018, Ezequiel Garcia wrote:


This commit adds a content section and also instructions
on how to create a bootable SD/MMC device for RK3399 boards.


Are any of these instructions Ficus-specific?  We have our own README for 
our own boards, as these have different instructions from the EVB boards.


Just wondering, as I'd have expected this to come in as part of the ficus 
board-directory...



Signed-off-by: Ezequiel Garcia 
Reviewed-by: Simon Glass 


Reviewed-by: Philipp Tomsich 


---
board/rockchip/evb_rk3399/README | 55 ++--
1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/board/rockchip/evb_rk3399/README b/board/rockchip/evb_rk3399/README
index 0b4c6d19ad39..3775d3ff447f 100644
--- a/board/rockchip/evb_rk3399/README
+++ b/board/rockchip/evb_rk3399/README
@@ -1,3 +1,21 @@
+Contents
+
+
+1. Introduction
+2. Get the Source and prebuild binary
+3. Compile the ATF
+4. Compile the U-Boot
+5. Compile the rkdeveloptool
+6. Package the image
+   6.1. Package the image for U-Boot SPL(option 1)
+   6.2. Package the image for Rockchip miniloader(option 2)
+7. Bootloader storage options
+8. Flash the image to eMMC
+   8.1. Flash the image with U-Boot SPL(option 1)
+   8.2. Flash the image with Rockchip miniloader(option 2)
+9. Create a bootable SD/MMC
+10. And that is it
+
Introduction


@@ -97,6 +115,12 @@ Package the image for Rockchip miniloader(option 2)

  Get trust.img and uboot.img in this step.

+Bootloader storage options
+==
+
+There are a few different storage options for the bootloader.
+This document explores two of these: eMMC and removable SD/MMC.
+
Flash the image to eMMC
===

@@ -117,6 +141,33 @@ Power on(or reset with RESET KEY) with MASKROM KEY 
preesed, and then:
  > rkdeveloptool wl 0x6000 u-boot/trust.img
  > rkdeveloptool rd

+Create a bootable SD/MMC
+
+
+The idbspl.img contains the first stage, and the u-boot.img the second stage.
+As explained in the Rockchip partition table reference [2], the first stage
+(aka loader1) start sector is 64, and the second stage start sector is 16384.
+
+Each sector is 512 bytes, which means the first stage offset is 32 KiB,
+and the second stage offset is 8 MiB.
+
+Note: the second stage location is actually not as per the spec,
+but defined by the SPL. Mainline SPL defines an 8 MiB offset for the second
+stage.
+
+Assuming the SD card is exposed by device /dev/mmcblk0, the commands
+to write the two stages are:
+
+  > dd if=idbspl.img of=/dev/mmcblk0 bs=1k seek=32
+  > dd if=u-boot.itb of=/dev/mmcblk0 bs=1k seek=8192
+
+Setting up the kernel and rootfs is beyond the scope of this document.
+
+And that is it
+==
+
You should be able to get U-Boot log in console/UART2(baurdrate 150)
-For more detail, please reference to:
-http://opensource.rock-chips.com/wiki_Boot_option
+For more detail, please reference [2].
+
+[1] http://opensource.rock-chips.com/wiki_Partitions
+[2] http://opensource.rock-chips.com/wiki_Boot_option


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


Re: [U-Boot] [U-Boot, 1/3] arm: dts: rockchip: add some common pin-settings to rk3399

2018-07-20 Thread Philipp Tomsich



On Mon, 16 Jul 2018, Ezequiel Garcia wrote:


From: Randy Li 

Those pins would be used by many boards.


The Rockchip pinctrl driver in U-Boot does not (yet) read the DTS for pin 
configuration information.


Is this a sync of the Linux DTS (which seems unlikely, as I'd expect more 
changes) or why are we doing this as part of this series?




Signed-off-by: Randy Li 
Signed-off-by: Heiko Stuebner 
Signed-off-by: Ezequiel Garcia 
Reviewed-by: Simon Glass 
---
arch/arm/dts/rk3399.dtsi | 55 +++-
1 file changed, 49 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 83c257b1228b..8349451b03dc 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -1602,19 +1602,49 @@
drive-strength = <12>;
};

+   pcfg_pull_none_13ma: pcfg-pull-none-13ma {
+   bias-disable;
+   drive-strength = <13>;
+   };
+
+   pcfg_pull_none_18ma: pcfg-pull-none-18ma {
+   bias-disable;
+   drive-strength = <18>;
+   };
+
+   pcfg_pull_none_20ma: pcfg-pull-none-20ma {
+   bias-disable;
+   drive-strength = <20>;
+   };
+
+   pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+   bias-pull-up;
+   drive-strength = <2>;
+   };
+
pcfg_pull_up_8ma: pcfg-pull-up-8ma {
bias-pull-up;
drive-strength = <8>;
};

+   pcfg_pull_up_18ma: pcfg-pull-up-18ma {
+   bias-pull-up;
+   drive-strength = <18>;
+   };
+
+   pcfg_pull_up_20ma: pcfg-pull-up-20ma {
+   bias-pull-up;
+   drive-strength = <20>;
+   };
+
pcfg_pull_down_4ma: pcfg-pull-down-4ma {
bias-pull-down;
drive-strength = <4>;
};

-   pcfg_pull_up_2ma: pcfg-pull-up-2ma {
-   bias-pull-up;
-   drive-strength = <2>;
+   pcfg_pull_down_8ma: pcfg-pull-down-8ma {
+   bias-pull-down;
+   drive-strength = <8>;
};

pcfg_pull_down_12ma: pcfg-pull-down-12ma {
@@ -1622,9 +1652,22 @@
drive-strength = <12>;
};

-   pcfg_pull_none_13ma: pcfg-pull-none-13ma {
-   bias-disable;
-   drive-strength = <13>;
+   pcfg_pull_down_18ma: pcfg-pull-down-18ma {
+   bias-pull-down;
+   drive-strength = <18>;
+   };
+
+   pcfg_pull_down_20ma: pcfg-pull-down-20ma {
+   bias-pull-down;
+   drive-strength = <20>;
+   };
+
+   pcfg_output_high: pcfg-output-high {
+   output-high;
+   };
+
+   pcfg_output_low: pcfg-output-low {
+   output-low;
};

clock {


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


Re: [U-Boot] [U-Boot, 2/5] mmc: dw_mmc: increase cmd timeout to fix eMMC enumeration error

2018-07-20 Thread Philipp Tomsich



On Wed, 4 Jul 2018, Alberto Panizzo wrote:


Errors are reported to happen running U-Boot after SPL kernel load failure.
In this case mmc host is not clean, and card enumeration timeouts
do happen frequently.

Signed-off-by: Alberto Panizzo 


See below for requested changes.


---
drivers/mmc/dw_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 0126563..b6890d3 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -199,7 +199,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd 
*cmd,
(1 + (data ? DIV_ROUND_UP(data->blocks, 8) : 0)));
int ret = 0, flags = 0, i;
unsigned int timeout = 500;
-   u32 retry = 10;
+   u32 retry = 100;


I feel rather uneasy about this, especially as it affects all devices (not 
just limited to Rockchip) that include a Designware MMC controller.


This affects code that effectivly 'retries' reading the status register to 
wait for a DONE bit:

for (i = 0; i < retry; i++) {
status = readl(...);
if (status & BITMASK) {
writel(...);
break;  // done
}
}

if (i == retry)
// a timeout happened

There's two main issues I have:
(a) the number of retries is an implicit timeout (i.e. depending on the
CPU frequency, instruction-set, whether the i-cache is enabled, ...) a
different number of microseconds will expire per pass through the loop
(b) you commit message states (I am paraphrasing here) 'because the
BootROM has left the state dirty', we need to increase the timeout

So there's two things (addressing these two issues) I'd like to see:
(a) the use of a polling loop that uses a timer where possible (I don't
know whether there's an execution context in someone's SPL or TPL that
doesn't have a timebase running, though... so: caveat emptor) --- this
might even lend itself to the use of include/linux/iopoll.h macros.
(b) a clean reset of the MMC controller for your/our platform in case we
expect the BootROM having left things in disarray.


u32 mask, ctrl;
ulong start = get_timer(0);
struct bounce_buffer bbstate;


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


Re: [U-Boot] [RFC PATCH 0/4] arm: zynq: implement FPGA load from SPL

2018-07-20 Thread Luis Araneda
Hi Michal,

On Fri, Jul 20, 2018 at 6:38 AM Michal Simek  wrote:
> On 20.7.2018 01:37, Luis Araneda wrote:
> > Hi Michal,
> >
> > On Thu, Jul 19, 2018 at 2:23 AM Michal Simek  
> > wrote:
> We need that functionality first but then enable it for all boards is
> fine for me and via one patch.

Ok

> Can you please be more specific what time1/time2 and time3 means?

The exact location of time 1/2/3 are on the attached diff file, and
they are placed within the spl_load_simple_fit() function.
They represent, roughly:
- time1: Time to load the the FIT image
- time2: Time to extract (and decompress)
  the FPGA image from the FIT image
- time3: Time to program the FPGA

Thanks,

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


Re: [U-Boot] [PATCH] ARM: mx6ul: Apply ERR011115 errata workaround

2018-07-20 Thread Marcin Niestroj

Hi,

On 20.07.2018 16:29, Sébastien Szymanski wrote:

Hi,

On 07/19/2018 01:37 PM, Marcin Niestroj wrote:

ERR05 in IMX6UL errata says to use OCRAM memory above
0x908000 (instead of 0x907000) for silicon revision 1.2 shipped
prior date code 1740.

As we cannot check affected targets in runtime, apply that
workaround by default for all IMX6UL platforms. Leave possibility
to disable that workaround for non-affected targets, so more OCRAM
area can be used by SPL (e.g. for featureful SPL images).

Signed-off-by: Marcin Niestroj 
---
  arch/arm/mach-imx/mx6/Kconfig |  9 +
  include/configs/imx6_spl.h| 11 +--
  2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 521fad74b5..61708a0526 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -58,6 +58,15 @@ config MX6UL
select SYSCOUNTER_TIMER
bool
  
+config MX6UL_ERR05

+   bool "Workaround for ERR05 in IMX6UL Errata"
+   depends on MX6UL
+   default MX6UL
+   help
+ Say N here if you are sure that your platform is not affected
+ with ERR05. Doing so might be useful in case of featureful
+ (big) SPL images.
+
  config MX6UL_LITESOM
bool
select MX6UL
diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
index 720ff045a7..42d12c7503 100644
--- a/include/configs/imx6_spl.h
+++ b/include/configs/imx6_spl.h
@@ -19,16 +19,23 @@
   *which consists of a 4K header in front of us that contains the IVT, DCD
   *and some padding thus 'our' max size is really 0x00908000 - 0x00918000
   *or 64KB
+ *  - Use 0x00909000 as start of OCRAM Free Area as a workaround for
+ *ERR05 in IMX6UL Errata
   */
+#ifdef CONFIG_MX6UL_ERR05
+#define CONFIG_SPL_TEXT_BASE   0x00909000
+#else
  #define CONFIG_SPL_TEXT_BASE  0x00908000
-#define CONFIG_SPL_MAX_SIZE0x1
+#endif
+
+#define CONFIG_SPL_MAX_SIZE(0x00918000 - CONFIG_SPL_TEXT_BASE)
  #define CONFIG_SPL_STACK  0x0091FFB8
  /*
   * Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
   * SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
   * boot media (given that boot media specific offset is configured properly).
   */
-#define CONFIG_SPL_PAD_TO  0x11000
+#define CONFIG_SPL_PAD_TO  (CONFIG_SPL_MAX_SIZE + 0x1000)


I got the following error when building the u-boot-with-spl.imx file:

/home/sszy/development/armadeus-git-opos6ul/buildroot/output/host/usr/bin/arm-linux-gnueabihf-objcopy:
--pad-to: bad number: (CONFIG_SPL_MAX_SIZE + 0x1000)

Anyway, this is wrong and will break the u-boot-with-spl.imx for MMC/SD
boot device.

The default offset for the U-Boot image on MMC/SD boot device is 69KB
(see SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR) so I think CONFIG_SPL_PAD_TO
should always be 0x11000 (== 68KB).


Thanks for catching this! You are right, CONFIG_SPL_PAD_TO is used
during u-boot with spl single image generation (always with objcopy
+ cat). Using 0x11000 value fixes build and makes u-boot-with-spl.imx
successfully booting SPL as well as u-boot.

I will post new patch with this issue fixed soon.



Regards,

  
  /* MMC support */

  #if defined(CONFIG_SPL_MMC_SUPPORT)






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


[U-Boot] [PATCHv2 4/6] bootcount: Configure length limit for I2C bootcount

2018-07-20 Thread Sebastian Reichel
From: Denis Zalevskiy 

Bootcount driver should verify size against the maximum available space. New
configuration parameter adds this capability and keeps backward compatibility by
providing default value.

Signed-off-by: Denis Zalevskiy 
Signed-off-by: Sebastian Reichel 
---
 drivers/bootcount/Kconfig |  6 ++
 drivers/bootcount/bootcount_i2c.c | 10 ++
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index a5349a62fdc3..e7f2e1ef65e0 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -132,4 +132,10 @@ config SYS_BOOTCOUNT_I2C_ADDR
depends on BOOTCOUNT_I2C
help
  I2C address of the device used to store bootcounter
+
+config BOOTCOUNT_I2C_LEN
+   int "Maximum length of bootcounter in bytes"
+   default 2
+   depends on BOOTCOUNT_I2C
+
 endif
diff --git a/drivers/bootcount/bootcount_i2c.c 
b/drivers/bootcount/bootcount_i2c.c
index 02c313fc11e1..ed22389bdc86 100644
--- a/drivers/bootcount/bootcount_i2c.c
+++ b/drivers/bootcount/bootcount_i2c.c
@@ -53,14 +53,15 @@ void bootcount_store(ulong a)
if (prev_i2c_bus < 0)
return;
 
-   unsigned char buf[3];
+   unsigned char buf[2];
int ret;
 
+   BUILD_BUG_ON(CONFIG_BOOTCOUNT_I2C_LEN < sizeof(buf));
buf[0] = BC_MAGIC;
buf[1] = (a & 0xff);
ret = i2c_write(CONFIG_SYS_BOOTCOUNT_I2C_ADDR,
CONFIG_SYS_BOOTCOUNT_ADDR,
-   CONFIG_BOOTCOUNT_ALEN, buf, 2);
+   CONFIG_BOOTCOUNT_ALEN, buf, sizeof(buf));
if (ret != 0)
puts("Error writing bootcount\n");
 
@@ -76,12 +77,13 @@ ulong bootcount_load(void)
if (prev_i2c_bus < 0)
return count;
 
-   unsigned char buf[3];
+   unsigned char buf[2];
int ret;
 
+   BUILD_BUG_ON(CONFIG_BOOTCOUNT_I2C_LEN < sizeof(buf));
ret = i2c_read(CONFIG_SYS_BOOTCOUNT_I2C_ADDR,
   CONFIG_SYS_BOOTCOUNT_ADDR,
-  CONFIG_BOOTCOUNT_ALEN, buf, 2);
+  CONFIG_BOOTCOUNT_ALEN, buf, sizeof(buf));
if (ret != 0) {
puts("Error loading bootcount\n");
goto out;
-- 
2.18.0

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


[U-Boot] [PATCHv2 6/6] board: ge: Store bootcount in EEPROM on PPD and Bx50v3

2018-07-20 Thread Sebastian Reichel
From: Denis Zalevskiy 

u-boot's ext3/4 write/modify functionality sometimes corrupts filesystem in the
case if it requires recovery (e.g. after unexpected shutdown) and we want to
avoid the only filesystem modification we have - bootcounter writing. So,
bootcounter will be stored in the EEPROM where VPD is stored.

Signed-off-by: Denis Zalevskiy 
Signed-off-by: Sebastian Reichel 
---
 board/ge/common/vpd_reader.c | 20 
 configs/ge_bx50v3_defconfig  | 18 ++
 configs/mx53ppd_defconfig| 19 +++
 include/configs/ge_bx50v3.h  |  6 +++---
 include/configs/mx53ppd.h|  6 +++---
 5 files changed, 55 insertions(+), 14 deletions(-)

diff --git a/board/ge/common/vpd_reader.c b/board/ge/common/vpd_reader.c
index 12410d9b715b..14507b45e485 100644
--- a/board/ge/common/vpd_reader.c
+++ b/board/ge/common/vpd_reader.c
@@ -5,6 +5,7 @@
 
 #include "vpd_reader.h"
 
+#include 
 #include 
 #include 
 #include 
@@ -200,7 +201,26 @@ int read_vpd(struct vpd_cache *cache,
 int (*process_block)(struct vpd_cache *, u8 id, u8 version,
  u8 type, size_t size, u8 const *data))
 {
+#if defined(CONFIG_BOOTCOUNT_I2C) &&   \
+   (CONFIG_SYS_BOOTCOUNT_I2C_BUS == CONFIG_SYS_VPD_EEPROM_I2C_BUS) && \
+   ((CONFIG_SYS_BOOTCOUNT_I2C_ADDR & 0xf0) == 
CONFIG_SYS_VPD_EEPROM_I2C_ADDR)
+   /*
+* bootcount is expected to reside at the end of EEPROM
+*
+* check is hard-wired to the logic of the 24C08 EEPROM 256-bytes
+* page-wise (4 pages) i2c_address/bootcount_address structure combined
+* with raw I2C access, so the I2C address and offset are combined into:
+*
+* i2c_addr = (device_i2c_addr | page),
+* offset = (offset - (page * 256)))
+*/
+   BUILD_BUG_ON((CONFIG_SYS_BOOTCOUNT_I2C_ADDR & 0x0f) * 256 +
+CONFIG_SYS_BOOTCOUNT_ADDR + CONFIG_BOOTCOUNT_I2C_LEN !=
+CONFIG_SYS_VPD_EEPROM_SIZE);
+   static const size_t size = CONFIG_SYS_BOOTCOUNT_ADDR;
+#else
static const size_t size = CONFIG_SYS_VPD_EEPROM_SIZE;
+#endif
 
int res;
u8 *data;
diff --git a/configs/ge_bx50v3_defconfig b/configs/ge_bx50v3_defconfig
index 0c2d033ad8e1..952e87d62d84 100644
--- a/configs/ge_bx50v3_defconfig
+++ b/configs/ge_bx50v3_defconfig
@@ -16,6 +16,20 @@ CONFIG_SYS_VPD_EEPROM_I2C_ADDR=0x50
 CONFIG_SYS_VPD_EEPROM_I2C_ADDR_LEN=1
 CONFIG_SYS_VPD_EEPROM_SIZE=1024
 
+CONFIG_BOOTCOUNT_I2C=y
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_SYS_BOOTCOUNT_I2C_BUS=4
+# bootcount is stored in VPD EEPROM
+# we are using generic driver instead of EEPROM one (while should use it)
+# at the end of VPD EEPROM: (SYS_VPD_EEPROM_SIZE - CONFIG_BOOTCOUNT_I2C_LEN)
+# so, the address is 0x3FE:
+# ("VPD EEPROM chip address" | "3rd 256-byte page"):
+CONFIG_SYS_BOOTCOUNT_I2C_ADDR=0x53
+# (+ "offset in the page"):
+CONFIG_SYS_BOOTCOUNT_ADDR=0xfe
+CONFIG_BOOTCOUNT_I2C_LEN=2
+CONFIG_BOOTCOUNT_ALEN=1
+
 CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_LAST_STAGE_INIT=y
@@ -35,10 +49,6 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_DOS_PARTITION=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
-CONFIG_BOOTCOUNT_LIMIT=y
-CONFIG_BOOTCOUNT_EXT=y
-CONFIG_SYS_BOOTCOUNT_EXT_DEVPART="1:5"
-CONFIG_SYS_BOOTCOUNT_ADDR=0x7000A000
 CONFIG_FSL_ESDHC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
diff --git a/configs/mx53ppd_defconfig b/configs/mx53ppd_defconfig
index 4a7e8eee0df1..43672d88e202 100644
--- a/configs/mx53ppd_defconfig
+++ b/configs/mx53ppd_defconfig
@@ -18,6 +18,21 @@ CONFIG_SYS_VPD_EEPROM_I2C_ADDR=0x50
 CONFIG_SYS_VPD_EEPROM_I2C_ADDR_LEN=1
 CONFIG_SYS_VPD_EEPROM_SIZE=1024
 
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_BOOTCOUNT_I2C=y
+# using bus where monitor's EEPROM is connected to
+CONFIG_SYS_BOOTCOUNT_I2C_BUS=2
+# bootcount is stored in Monitor's VPD EEPROM
+# we are using generic driver instead of EEPROM one (while should use it)
+# at the end of VPD EEPROM: (SYS_VPD_EEPROM_SIZE - CONFIG_BOOTCOUNT_I2C_LEN)
+# so, the address is 0x3FE:
+# ("VPD EEPROM chip address" | "3rd 256-byte page"):
+CONFIG_SYS_BOOTCOUNT_I2C_ADDR=0x53
+# (+ "offset in the page"):
+CONFIG_SYS_BOOTCOUNT_ADDR=0xfe
+CONFIG_BOOTCOUNT_I2C_LEN=2
+CONFIG_BOOTCOUNT_ALEN=1
+
 CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
@@ -33,10 +48,6 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_ENV_IS_IN_MMC=y
-CONFIG_BOOTCOUNT_LIMIT=y
-CONFIG_BOOTCOUNT_EXT=y
-CONFIG_SYS_BOOTCOUNT_EXT_DEVPART="0:5"
-CONFIG_SYS_BOOTCOUNT_ADDR=0x7000A000
 CONFIG_FSL_ESDHC=y
 CONFIG_NETDEVICES=y
 CONFIG_RTC_S35392A=y
diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index fef41a8a1887..a6e31f7e91a9 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -116,9 +116,9 @@
"setenv stdout vga; " \
"echo \"\n\n\n\n\" $msg; " \

[U-Boot] [PATCHv2 3/6] bootcount: i2c: Add bus switching to the I2C bootcount driver

2018-07-20 Thread Sebastian Reichel
From: Denis Zalevskiy 

If there is an I2C mux, current bus should be switched before manipulating with
I2C.

Signed-off-by: Denis Zalevskiy 
Signed-off-by: Sebastian Reichel 
---
 drivers/bootcount/Kconfig | 15 ++-
 drivers/bootcount/bootcount_i2c.c | 70 +++
 2 files changed, 76 insertions(+), 9 deletions(-)

diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index d335ed14b961..a5349a62fdc3 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -62,7 +62,9 @@ config BOOTCOUNT_I2C
bool "Boot counter on I2C device"
help
  Enable support for the bootcounter on an i2c (like RTC) device.
- CONFIG_SYS_I2C_RTC_ADDR = i2c chip address
+ CONFIG_SYS_BOOTCOUNT_I2C_BUS = bus of the target I2C device,
+CONFIG_SYS_I2C_RTC_ADDR is used as 
fallback
+ CONFIG_SYS_BOOTCOUNT_I2C_ADDR = target I2C device address
  CONFIG_SYS_BOOTCOUNT_ADDR = i2c addr which is used for
  the bootcounter.
 
@@ -119,4 +121,15 @@ config SYS_BOOTCOUNT_ADDR
help
  Set the address used for reading and writing the boot counter.
 
+config SYS_BOOTCOUNT_I2C_BUS
+   int "I2C bootcounter device bus"
+   depends on BOOTCOUNT_I2C
+   help
+ I2C bus of the device used to store bootcounter
+
+config SYS_BOOTCOUNT_I2C_ADDR
+   hex "I2C bootcounter device address"
+   depends on BOOTCOUNT_I2C
+   help
+ I2C address of the device used to store bootcounter
 endif
diff --git a/drivers/bootcount/bootcount_i2c.c 
b/drivers/bootcount/bootcount_i2c.c
index 496741d63f78..02c313fc11e1 100644
--- a/drivers/bootcount/bootcount_i2c.c
+++ b/drivers/bootcount/bootcount_i2c.c
@@ -8,36 +8,90 @@
 #include 
 #include 
 
+#ifndef CONFIG_SYS_BOOTCOUNT_I2C_ADDR
+/* compatibility with the previous logic:
+ * previous version of driver used RTC device to store bootcount
+ */
+#define CONFIG_SYS_BOOTCOUNT_I2C_ADDR CONFIG_SYS_I2C_RTC_ADDR
+#endif
+
 #define BC_MAGIC   0xbc
 
+#ifdef CONFIG_SYS_BOOTCOUNT_I2C_BUS
+static int bootcount_set_bus(void)
+{
+   unsigned int current_bus = i2c_get_bus_num();
+
+   assert(current_bus <= INT_MAX);
+
+   int res = i2c_set_bus_num(CONFIG_SYS_BOOTCOUNT_I2C_BUS);
+
+   if (res < 0) {
+   puts("Error switching I2C bus\n");
+   return res;
+   }
+   return (int)current_bus;
+}
+
+static void bootcount_set_bus_back(int prev_bus)
+{
+   if (i2c_set_bus_num(prev_bus) < 0)
+   puts("Can't switch I2C bus back\n");
+}
+#else
+static inline int bootcount_set_bus(void) { return 0; }
+
+static inline void bootcount_set_bus_back(int prev_bus __attribute__((unused)))
+{
+}
+#endif
+
 void bootcount_store(ulong a)
 {
+   int prev_i2c_bus = bootcount_set_bus();
+
+   if (prev_i2c_bus < 0)
+   return;
+
unsigned char buf[3];
int ret;
 
buf[0] = BC_MAGIC;
buf[1] = (a & 0xff);
-   ret = i2c_write(CONFIG_SYS_I2C_RTC_ADDR, CONFIG_SYS_BOOTCOUNT_ADDR,
- CONFIG_BOOTCOUNT_ALEN, buf, 2);
+   ret = i2c_write(CONFIG_SYS_BOOTCOUNT_I2C_ADDR,
+   CONFIG_SYS_BOOTCOUNT_ADDR,
+   CONFIG_BOOTCOUNT_ALEN, buf, 2);
if (ret != 0)
puts("Error writing bootcount\n");
+
+   bootcount_set_bus_back(prev_i2c_bus);
 }
 
 ulong bootcount_load(void)
 {
+   ulong count = 0;
+
+   int prev_i2c_bus = bootcount_set_bus();
+
+   if (prev_i2c_bus < 0)
+   return count;
+
unsigned char buf[3];
int ret;
 
-   ret = i2c_read(CONFIG_SYS_I2C_RTC_ADDR, CONFIG_SYS_BOOTCOUNT_ADDR,
+   ret = i2c_read(CONFIG_SYS_BOOTCOUNT_I2C_ADDR,
+  CONFIG_SYS_BOOTCOUNT_ADDR,
   CONFIG_BOOTCOUNT_ALEN, buf, 2);
if (ret != 0) {
puts("Error loading bootcount\n");
-   return 0;
+   goto out;
}
if (buf[0] == BC_MAGIC)
-   return buf[1];
-
-   bootcount_store(0);
+   count = buf[1];
+   else
+   bootcount_store(count);
 
-   return 0;
+out:
+   bootcount_set_bus_back(prev_i2c_bus);
+   return count;
 }
-- 
2.18.0

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


[U-Boot] [PATCHv2 2/6] board: ge: Move VPD EEPROM configuration to the defconfig

2018-07-20 Thread Sebastian Reichel
From: Denis Zalevskiy 

Use standard configuration logic to define EEPROM constants. Names are based on
VPD_EEPROM_ prefix because EEPROM_ is already used by i2c_eeprom driver.

Signed-off-by: Denis Zalevskiy 
Signed-off-by: Sebastian Reichel 
---
 board/ge/bx50v3/Kconfig |  2 ++
 board/ge/bx50v3/bx50v3.c| 17 -
 board/ge/common/Kconfig | 14 ++
 board/ge/mx53ppd/Kconfig|  2 ++
 board/ge/mx53ppd/mx53ppd.c  | 14 --
 configs/ge_bx50v3_defconfig |  9 +
 configs/mx53ppd_defconfig   | 10 ++
 7 files changed, 45 insertions(+), 23 deletions(-)
 create mode 100644 board/ge/common/Kconfig

diff --git a/board/ge/bx50v3/Kconfig b/board/ge/bx50v3/Kconfig
index 993b0559302b..05938560abda 100644
--- a/board/ge/bx50v3/Kconfig
+++ b/board/ge/bx50v3/Kconfig
@@ -15,4 +15,6 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ge_bx50v3"
 
+source "board/ge/common/Kconfig"
+
 endif
diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 55623d429179..594e1265093f 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -38,15 +38,6 @@ struct vpd_cache;
 static int confidx = 3;  /* Default to b850v3. */
 static struct vpd_cache vpd;
 
-#ifndef CONFIG_SYS_I2C_EEPROM_ADDR
-# define CONFIG_SYS_I2C_EEPROM_ADDR 0x50
-# define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
-#endif
-
-#ifndef CONFIG_SYS_I2C_EEPROM_BUS
-#define CONFIG_SYS_I2C_EEPROM_BUS   4
-#endif
-
 #define NC_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
PAD_CTL_HYS)
@@ -626,11 +617,11 @@ static void process_vpd(struct vpd_cache *vpd)
 static int read_vpd()
 {
int res;
-   int size = 1024;
+   static const int size = CONFIG_SYS_VPD_EEPROM_SIZE;
uint8_t *data;
unsigned int current_i2c_bus = i2c_get_bus_num();
 
-   res = i2c_set_bus_num(CONFIG_SYS_I2C_EEPROM_BUS);
+   res = i2c_set_bus_num(CONFIG_SYS_VPD_EEPROM_I2C_BUS);
if (res < 0)
return res;
 
@@ -638,8 +629,8 @@ static int read_vpd()
if (!data)
return -ENOMEM;
 
-   res = i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0,
-   CONFIG_SYS_I2C_EEPROM_ADDR_LEN, data, size);
+   res = i2c_read(CONFIG_SYS_VPD_EEPROM_I2C_ADDR, 0,
+  CONFIG_SYS_VPD_EEPROM_I2C_ADDR_LEN, data, size);
 
if (res == 0) {
memset(, 0, sizeof(vpd));
diff --git a/board/ge/common/Kconfig b/board/ge/common/Kconfig
new file mode 100644
index ..637b264954a1
--- /dev/null
+++ b/board/ge/common/Kconfig
@@ -0,0 +1,14 @@
+config SYS_VPD_EEPROM_I2C_ADDR
+   hex "I2C address of the EEPROM device used for VPD"
+   help
+ VPD = Vital Product Data
+
+config SYS_VPD_EEPROM_I2C_BUS
+   int "I2C bus of the EEPROM device used for VPD."
+
+config SYS_VPD_EEPROM_SIZE
+   int "Size in bytes of the EEPROM device used for VPD"
+
+config SYS_VPD_EEPROM_I2C_ADDR_LEN
+   int "Number of bytes to use for VPD EEPROM address"
+   default 1
diff --git a/board/ge/mx53ppd/Kconfig b/board/ge/mx53ppd/Kconfig
index 6dc3818cb7bb..bebb2fab0173 100644
--- a/board/ge/mx53ppd/Kconfig
+++ b/board/ge/mx53ppd/Kconfig
@@ -13,4 +13,6 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "mx53ppd"
 
+source "board/ge/common/Kconfig"
+
 endif
diff --git a/board/ge/mx53ppd/mx53ppd.c b/board/ge/mx53ppd/mx53ppd.c
index 850b8d517e82..13a5263040aa 100644
--- a/board/ge/mx53ppd/mx53ppd.c
+++ b/board/ge/mx53ppd/mx53ppd.c
@@ -40,13 +40,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-/* Index of I2C1, SEGMENT 1 (see CONFIG_SYS_I2C_BUSES). */
-#define VPD_EEPROM_BUS 2
-
-/* Address of 24C08 EEPROM. */
-#define VPD_EEPROM_ADDR0x50
-#define VPD_EEPROM_ADDR_LEN1
-
 static u32 mx53_dram_size[2];
 
 phys_size_t get_effective_memsize(void)
@@ -332,11 +325,11 @@ static int read_vpd()
 {
struct vpd_cache vpd;
int res;
-   int size = 1024;
+   static const int size = CONFIG_SYS_VPD_EEPROM_SIZE;
u8 *data;
unsigned int current_i2c_bus = i2c_get_bus_num();
 
-   res = i2c_set_bus_num(VPD_EEPROM_BUS);
+   res = i2c_set_bus_num(CONFIG_SYS_VPD_EEPROM_I2C_BUS);
if (res < 0)
return res;
 
@@ -344,7 +337,8 @@ static int read_vpd()
if (!data)
return -ENOMEM;
 
-   res = i2c_read(VPD_EEPROM_ADDR, 0, VPD_EEPROM_ADDR_LEN, data, size);
+   res = i2c_read(CONFIG_SYS_VPD_EEPROM_I2C_ADDR, 0,
+  CONFIG_SYS_VPD_EEPROM_I2C_ADDR_LEN, data, size);
if (res == 0) {
memset(, 0, sizeof(vpd));
vpd_reader(size, data, , vpd_callback);
diff --git a/configs/ge_bx50v3_defconfig b/configs/ge_bx50v3_defconfig
index b312920a2543..0c2d033ad8e1 100644
--- a/configs/ge_bx50v3_defconfig
+++ b/configs/ge_bx50v3_defconfig
@@ -7,6 +7,15 @@ CONFIG_FIT=y
 CONFIG_BOOTDELAY=1
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 

[U-Boot] [PATCHv2 5/6] board: ge: Move VPD reading to the vpd_reader

2018-07-20 Thread Sebastian Reichel
From: Denis Zalevskiy 

Merge functionality duplicated in bx50v3 and mx53ppd: the logic is the same
except that process_vpd is called at different phases. Also read_vpd could end
up in error, so there is no VPD data in this case - it shouldn't be processed.

Signed-off-by: Denis Zalevskiy 
Signed-off-by: Sebastian Reichel 
---
 board/ge/bx50v3/bx50v3.c | 48 +---
 board/ge/common/vpd_reader.c | 37 ---
 board/ge/common/vpd_reader.h | 16 
 board/ge/mx53ppd/mx53ppd.c   | 44 +++--
 4 files changed, 65 insertions(+), 80 deletions(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 594e1265093f..78e7ee62926f 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -33,8 +33,6 @@
 #include "../../../drivers/net/e1000.h"
 DECLARE_GLOBAL_DATA_PTR;
 
-struct vpd_cache;
-
 static int confidx = 3;  /* Default to b850v3. */
 static struct vpd_cache vpd;
 
@@ -552,6 +550,7 @@ int overwrite_console(void)
 #define VPD_MAC_ADDRESS_LENGTH 6
 
 struct vpd_cache {
+   bool is_read;
u8 product_id;
u8 has;
unsigned char mac1[VPD_MAC_ADDRESS_LENGTH];
@@ -561,11 +560,9 @@ struct vpd_cache {
 /*
  * Extracts MAC and product information from the VPD.
  */
-static int vpd_callback(void *userdata, u8 id, u8 version, u8 type,
+static int vpd_callback(struct vpd_cache *vpd, u8 id, u8 version, u8 type,
size_t size, u8 const *data)
 {
-   struct vpd_cache *vpd = (struct vpd_cache *)userdata;
-
if (id == VPD_BLOCK_HWID && version == 1 && type != VPD_TYPE_INVALID &&
size >= 1) {
vpd->product_id = data[0];
@@ -589,6 +586,11 @@ static void process_vpd(struct vpd_cache *vpd)
int fec_index = -1;
int i210_index = -1;
 
+   if (!vpd->is_read) {
+   printf("VPD wasn't read");
+   return;
+   }
+
switch (vpd->product_id) {
case VPD_PRODUCT_B450:
env_set("confidx", "1");
@@ -614,35 +616,6 @@ static void process_vpd(struct vpd_cache *vpd)
eth_env_set_enetaddr_by_index("eth", i210_index, vpd->mac2);
 }
 
-static int read_vpd()
-{
-   int res;
-   static const int size = CONFIG_SYS_VPD_EEPROM_SIZE;
-   uint8_t *data;
-   unsigned int current_i2c_bus = i2c_get_bus_num();
-
-   res = i2c_set_bus_num(CONFIG_SYS_VPD_EEPROM_I2C_BUS);
-   if (res < 0)
-   return res;
-
-   data = (uint8_t *)malloc(size);
-   if (!data)
-   return -ENOMEM;
-
-   res = i2c_read(CONFIG_SYS_VPD_EEPROM_I2C_ADDR, 0,
-  CONFIG_SYS_VPD_EEPROM_I2C_ADDR_LEN, data, size);
-
-   if (res == 0) {
-   memset(, 0, sizeof(vpd));
-   vpd_reader(size, data, , vpd_callback);
-   }
-
-   free(data);
-
-   i2c_set_bus_num(current_i2c_bus);
-   return res;
-}
-
 int board_eth_init(bd_t *bis)
 {
setup_iomux_enet();
@@ -705,9 +678,10 @@ int board_init(void)
setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info2);
setup_i2c(3, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info3);
 
-   read_vpd();
-
-   set_confidx();
+   if (!read_vpd(, vpd_callback)) {
+   vpd.is_read = true;
+   set_confidx();
+   }
 
gpio_direction_output(SUS_S3_OUT, 1);
gpio_direction_output(WIFI_EN, 1);
diff --git a/board/ge/common/vpd_reader.c b/board/ge/common/vpd_reader.c
index c471583be86b..12410d9b715b 100644
--- a/board/ge/common/vpd_reader.c
+++ b/board/ge/common/vpd_reader.c
@@ -5,6 +5,7 @@
 
 #include "vpd_reader.h"
 
+#include 
 #include 
 #include 
 
@@ -105,9 +106,9 @@ static const size_t HEADER_BLOCK_ECC_LEN = 4;
 
 static const u8 ECC_BLOCK_ID = 0xFF;
 
-int vpd_reader(size_t size, u8 *data, void *userdata,
-  int (*fn)(void *userdata, u8 id, u8 version, u8 type,
-size_t size, u8 const *data))
+static int vpd_reader(size_t size, u8 *data, struct vpd_cache *userdata,
+ int (*fn)(struct vpd_cache *, u8 id, u8 version, u8 type,
+   size_t size, u8 const *data))
 {
if (size < HEADER_BLOCK_LEN || !data || !fn)
return -EINVAL;
@@ -194,3 +195,33 @@ int vpd_reader(size_t size, u8 *data, void *userdata,
return ret;
}
 }
+
+int read_vpd(struct vpd_cache *cache,
+int (*process_block)(struct vpd_cache *, u8 id, u8 version,
+ u8 type, size_t size, u8 const *data))
+{
+   static const size_t size = CONFIG_SYS_VPD_EEPROM_SIZE;
+
+   int res;
+   u8 *data;
+   unsigned int current_i2c_bus = i2c_get_bus_num();
+
+   res = i2c_set_bus_num(CONFIG_SYS_VPD_EEPROM_I2C_BUS);
+   if (res < 0)
+   return res;
+
+   data = malloc(size);
+   if (!data)
+   return -ENOMEM;
+
+   res = 

[U-Boot] [PATCHv2 1/6] board: ge: Remove EEPROM bus param from read_vpd()

2018-07-20 Thread Sebastian Reichel
From: Denis Zalevskiy 

The bus is statically defined, so remove redundant parameters from read_vpd()
for PPD and Bx50v3.

Signed-off-by: Denis Zalevskiy 
Signed-off-by: Sebastian Reichel 
---
 board/ge/bx50v3/bx50v3.c   | 6 +++---
 board/ge/mx53ppd/mx53ppd.c | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index b2d065c1b801..55623d429179 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -623,14 +623,14 @@ static void process_vpd(struct vpd_cache *vpd)
eth_env_set_enetaddr_by_index("eth", i210_index, vpd->mac2);
 }
 
-static int read_vpd(uint eeprom_bus)
+static int read_vpd()
 {
int res;
int size = 1024;
uint8_t *data;
unsigned int current_i2c_bus = i2c_get_bus_num();
 
-   res = i2c_set_bus_num(eeprom_bus);
+   res = i2c_set_bus_num(CONFIG_SYS_I2C_EEPROM_BUS);
if (res < 0)
return res;
 
@@ -714,7 +714,7 @@ int board_init(void)
setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info2);
setup_i2c(3, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info3);
 
-   read_vpd(CONFIG_SYS_I2C_EEPROM_BUS);
+   read_vpd();
 
set_confidx();
 
diff --git a/board/ge/mx53ppd/mx53ppd.c b/board/ge/mx53ppd/mx53ppd.c
index cf278e8f47c6..850b8d517e82 100644
--- a/board/ge/mx53ppd/mx53ppd.c
+++ b/board/ge/mx53ppd/mx53ppd.c
@@ -328,7 +328,7 @@ static void process_vpd(struct vpd_cache *vpd)
eth_env_set_enetaddr("ethaddr", vpd->mac1);
 }
 
-static int read_vpd(uint eeprom_bus)
+static int read_vpd()
 {
struct vpd_cache vpd;
int res;
@@ -336,7 +336,7 @@ static int read_vpd(uint eeprom_bus)
u8 *data;
unsigned int current_i2c_bus = i2c_get_bus_num();
 
-   res = i2c_set_bus_num(eeprom_bus);
+   res = i2c_set_bus_num(VPD_EEPROM_BUS);
if (res < 0)
return res;
 
@@ -390,7 +390,7 @@ int board_late_init(void)
 {
int res;
 
-   read_vpd(VPD_EEPROM_BUS);
+   read_vpd();
 
res = clock_1GHz();
if (res != 0)
-- 
2.18.0

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


[U-Boot] [PATCHv2 0/6] GE: Move from ext4 to eeprom bootcounter

2018-07-20 Thread Sebastian Reichel
Writing to ext4 from U-Boot is dangerous in case of inconsistent filesystem
state (i.e. due to power-loss). The current U-Boot code can modify the 
filesystem,
so that it is no longer usable by Linux after fsck. This patchset avoids writing
to the partition on GE devices by moving the boot counter to the last two bytes
of VPD EEPROM (together with some VPD cleanups). It also adds non RTC device 
support
to the i2c bootcounter driver.

Changes since PATCHv1:
 * add missing Kconfig file
 * rebase to current master (992c1db45591)

-- Sebastian

Denis Zalevskiy (6):
  board: ge: Remove EEPROM bus param from read_vpd()
  board: ge: Move VPD EEPROM configuration to the defconfig
  bootcount: i2c: Add bus switching to the I2C bootcount driver
  bootcount: Configure length limit for I2C bootcount
  board: ge: Move VPD reading to the vpd_reader
  board: ge: Store bootcount in EEPROM on PPD and Bx50v3

 board/ge/bx50v3/Kconfig   |  2 +
 board/ge/bx50v3/bx50v3.c  | 57 +-
 board/ge/common/Kconfig   | 14 ++
 board/ge/common/vpd_reader.c  | 57 --
 board/ge/common/vpd_reader.h  | 16 +--
 board/ge/mx53ppd/Kconfig  |  2 +
 board/ge/mx53ppd/mx53ppd.c| 50 
 configs/ge_bx50v3_defconfig   | 27 +--
 configs/mx53ppd_defconfig | 29 ++--
 drivers/bootcount/Kconfig | 21 -
 drivers/bootcount/bootcount_i2c.c | 78 ++-
 include/configs/ge_bx50v3.h   |  6 +--
 include/configs/mx53ppd.h |  6 +--
 13 files changed, 244 insertions(+), 121 deletions(-)
 create mode 100644 board/ge/common/Kconfig

-- 
2.18.0

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


Re: [U-Boot] smartweb: use SPL_TINY_MEMSET

2018-07-20 Thread Philipp Tomsich
> The SPL code for smartweb is close to its limit and adding a few extra
> instructions to SPL will cause it to overrun its sram allotement (thus
> causing build failures).  To allow adding the 'spl_perform_fixups'
> extension point to SPL, we'll enable SPL_TINY_MEMSET for smartweb.
> 
> Signed-off-by: Philipp Tomsich 
> ---
> 
>  configs/smartweb_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 

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


[U-Boot] [PATCH v2 2/2] disk: part: Don't show redundant error message

2018-07-20 Thread Sam Protsenko
Underlying API should already print some meaningful error message, so
this one is just brings more noise. E.g. we can see log like this:

MMC: no card present
** Bad device mmc 0 **

Obviously, second error message is unwanted. Let's only print it in case
when DEBUG is defined to keep log short and clear.

Signed-off-by: Sam Protsenko 
---
Changes in v2:
  - Instead of removing error message, print it with debug()

 disk/part.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disk/part.c b/disk/part.c
index 9266a09ec3..9e457a6e72 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -400,7 +400,7 @@ int blk_get_device_by_str(const char *ifname, const char 
*dev_hwpart_str,
 
*dev_desc = get_dev_hwpart(ifname, dev, hwpart);
if (!(*dev_desc) || ((*dev_desc)->type == DEV_TYPE_UNKNOWN)) {
-   printf("** Bad device %s %s **\n", ifname, dev_hwpart_str);
+   debug("** Bad device %s %s **\n", ifname, dev_hwpart_str);
dev = -ENOENT;
goto cleanup;
}
-- 
2.18.0

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


[U-Boot] [PATCH v2 1/2] env: Don't print "Failed" error message

2018-07-20 Thread Sam Protsenko
"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Remove this "Failed" message to keep log short and clear.

Signed-off-by: Sam Protsenko 
---
Changes in v2:
  - Join two consecutive "if (!ret)" conditions
  - Add the comment with requirement for underlying API to print error
message (as we don't print "Failed" message anymore)

 env/env.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/env/env.c b/env/env.c
index 5c0842ac07..c830001eee 100644
--- a/env/env.c
+++ b/env/env.c
@@ -195,14 +195,16 @@ int env_load(void)
continue;
 
printf("Loading Environment from %s... ", drv->name);
+   /*
+* In error case, the error message must be printed during
+* drv->load() in some underlying API, and it must be exactly
+* one message.
+*/
ret = drv->load();
-   if (ret)
-   printf("Failed (%d)\n", ret);
-   else
+   if (!ret) {
printf("OK\n");
-
-   if (!ret)
return 0;
+   }
}
 
return -ENODEV;
-- 
2.18.0

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


[U-Boot] [PATCH v2 0/2] env: Make environment loading log more clear

2018-07-20 Thread Sam Protsenko
This patch series intended to make boot log better. Basically here we
just remove unwanted error messages, relying on the message from most
deep API to be printed (like mmc subsystem). At the moment this looks
like most clean solution to cluttered log problem, as any other solution
will be hackish.

With this patch set applied we will see something like this:

Loading Environment from FAT... MMC: no card present
Loading Environment from MMC... OK

instead of:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)
Loading Environment from MMC... OK

Sam Protsenko (2):
  env: Don't print "Failed" error message
  disk: part: Don't show redundant error message

 disk/part.c |  2 +-
 env/env.c   | 12 +++-
 2 files changed, 8 insertions(+), 6 deletions(-)

-- 
2.18.0

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


[U-Boot] [PATCH] smartweb: use SPL_TINY_MEMSET

2018-07-20 Thread Philipp Tomsich
The SPL code for smartweb is close to its limit and adding a few extra
instructions to SPL will cause it to overrun its sram allotement (thus
causing build failures).  To allow adding the 'spl_perform_fixups'
extension point to SPL, we'll enable SPL_TINY_MEMSET for smartweb.

Signed-off-by: Philipp Tomsich 
---

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

diff --git a/configs/smartweb_defconfig b/configs/smartweb_defconfig
index 1f246e3..9ae30a1 100644
--- a/configs/smartweb_defconfig
+++ b/configs/smartweb_defconfig
@@ -54,4 +54,5 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_MCS7830=y
+CONFIG_SPL_TINY_MEMSET=y
 # CONFIG_EFI_LOADER is not set
-- 
2.1.4

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


Re: [U-Boot] [PATCH 1/2] env: Don't print "Failed" error message

2018-07-20 Thread Sam Protsenko
On Fri, Jul 20, 2018 at 4:29 PM, Wolfgang Denk  wrote:
> Dear Sam,
>
> In message <20180720131421.7136-2-semen.protse...@linaro.org> you wrote:
>>
>> + if (!ret)
>>   printf("OK\n");
>>
>>   if (!ret)
>
> Now we have two "if (!ret)" in sequence.  Make this one block,
> please.
>

Good point. Will do in v2, thanks.

> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Commitment, n.:  Commitment can be illustrated by a breakfast
> of ham and eggs. The chicken was involved, the pig was committed.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v3 0/2] env: Make environment loading log more clear

2018-07-20 Thread Sam Protsenko
On Fri, Jul 20, 2018 at 4:27 PM, Wolfgang Denk  wrote:
> Dear Sam,
>
> In message <20180719222843.28316-1-semen.protse...@linaro.org> you wrote:
>>
>>  1. With no "Failed" message, at some point we *can* end up with no
>> error messages printed at all
>
> That would mean that we did not check the whole call tree as needed.
> It is not that complicated, or is it?
>

I've checked the error chain for FAT/MMC env load: [1]. As for the
rest of possible sources, frankly I didn't check, as I don't have such
boards at my disposal anyway, and I may not be aware of all sources we
have. That's why I've only corrected the path for loading from FAT,
which I can test and can argue it's working right. I will add the
comment in env_load() saying that error message must be printed from
underlying subsystem, and it should be exactly one error. If we catch
any related issues further, we can check it on the sport. I hope
you're ok with this approach, as fixing all possible error cases for
all possible sources in at once seems to be too complex task. And some
further messages can appear further, if someone would manage to get
such a patch merged. So let's start with clear requirement in
env_load().

[1] https://pastebin.com/q6kgpprb

>>  2. Removing some collateral error messages *may* lead to loss of useful
>> debug info in other use-cases (env_load() is not only user of those
>> APIs).
>
> I dislike the "can" and "may" parts here.  If this is done
> thoroughly, we should know exactly that no such damage gets done.
>

Agree. Also, I like Tom's suggestion to move those to debug() instead
of removing.

> As I mentioend before: if we get here, somewhere an error must have
> occurred.  And in the error handling an error message (one) must be
> printed.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Software entities are more complex for their size  than  perhaps  any
> other human construct because no two parts are alike. If they are, we
> make  the  two  similar parts into a subroutine -- open or closed. In
> this respect, software  systems  differ  profoundly  from  computers,
> buildings, or automobiles, where repeated elements abound.
>- Fred Brooks, Jr.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 04/20] W1-EEPROM: Add an W1-EEPROM uclass for 1 wire EEPROMs

2018-07-20 Thread Maxime Ripard
Hi Eugen,

Thanks for giving those patches another shot.

On Thu, Jul 19, 2018 at 12:57:52PM +0300, Eugen Hristev wrote:
> From: Maxime Ripard 
> 
> We might want to access data stored onto one wire EEPROMs.
> Create a framework to provide a consistent API.
> 
> Signed-off-by: Maxime Ripard 
> [eugen.hris...@microchip.com: reworked patch]
> Signed-off-by: Eugen Hristev 
> ---
>  drivers/Kconfig  |  2 ++
>  drivers/Makefile |  1 +
>  drivers/w1-eeprom/Kconfig| 17 +++
>  drivers/w1-eeprom/Makefile   |  2 ++
>  drivers/w1-eeprom/w1-eeprom-uclass.c | 56 
> 
>  include/dm/uclass-id.h   |  1 +
>  include/w1-eeprom.h  | 28 ++
>  7 files changed, 107 insertions(+)
>  create mode 04 drivers/w1-eeprom
>  create mode 100644 drivers/w1-eeprom/Kconfig
>  create mode 100644 drivers/w1-eeprom/Makefile
>  create mode 100644 drivers/w1-eeprom/w1-eeprom-uclass.c
>  create mode 100644 include/w1-eeprom.h

I believe that we shouldn't have a framework solely for 1-wire
EEPROMs, but for EEPROMs, connected to any bus.

The 1-Wire EEPROMs all behave pretty much the same, so we'll probably
only see a single driver within that framework. And at the same time,
we'll want to have a consistent interface to access all the EEPROMs,
no matter on which bus they sit on.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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


Re: [U-Boot] [PATCH] ARM: mx6ul: Apply ERR011115 errata workaround

2018-07-20 Thread Sébastien Szymanski
Hi,

On 07/19/2018 01:37 PM, Marcin Niestroj wrote:
> ERR05 in IMX6UL errata says to use OCRAM memory above
> 0x908000 (instead of 0x907000) for silicon revision 1.2 shipped
> prior date code 1740.
> 
> As we cannot check affected targets in runtime, apply that
> workaround by default for all IMX6UL platforms. Leave possibility
> to disable that workaround for non-affected targets, so more OCRAM
> area can be used by SPL (e.g. for featureful SPL images).
> 
> Signed-off-by: Marcin Niestroj 
> ---
>  arch/arm/mach-imx/mx6/Kconfig |  9 +
>  include/configs/imx6_spl.h| 11 +--
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
> index 521fad74b5..61708a0526 100644
> --- a/arch/arm/mach-imx/mx6/Kconfig
> +++ b/arch/arm/mach-imx/mx6/Kconfig
> @@ -58,6 +58,15 @@ config MX6UL
>   select SYSCOUNTER_TIMER
>   bool
>  
> +config MX6UL_ERR05
> + bool "Workaround for ERR05 in IMX6UL Errata"
> + depends on MX6UL
> + default MX6UL
> + help
> +   Say N here if you are sure that your platform is not affected
> +   with ERR05. Doing so might be useful in case of featureful
> +   (big) SPL images.
> +
>  config MX6UL_LITESOM
>   bool
>   select MX6UL
> diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
> index 720ff045a7..42d12c7503 100644
> --- a/include/configs/imx6_spl.h
> +++ b/include/configs/imx6_spl.h
> @@ -19,16 +19,23 @@
>   *which consists of a 4K header in front of us that contains the IVT, DCD
>   *and some padding thus 'our' max size is really 0x00908000 - 0x00918000
>   *or 64KB
> + *  - Use 0x00909000 as start of OCRAM Free Area as a workaround for
> + *ERR05 in IMX6UL Errata
>   */
> +#ifdef CONFIG_MX6UL_ERR05
> +#define CONFIG_SPL_TEXT_BASE 0x00909000
> +#else
>  #define CONFIG_SPL_TEXT_BASE 0x00908000
> -#define CONFIG_SPL_MAX_SIZE  0x1
> +#endif
> +
> +#define CONFIG_SPL_MAX_SIZE  (0x00918000 - CONFIG_SPL_TEXT_BASE)
>  #define CONFIG_SPL_STACK 0x0091FFB8
>  /*
>   * Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
>   * SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
>   * boot media (given that boot media specific offset is configured properly).
>   */
> -#define CONFIG_SPL_PAD_TO0x11000
> +#define CONFIG_SPL_PAD_TO(CONFIG_SPL_MAX_SIZE + 0x1000)

I got the following error when building the u-boot-with-spl.imx file:

/home/sszy/development/armadeus-git-opos6ul/buildroot/output/host/usr/bin/arm-linux-gnueabihf-objcopy:
--pad-to: bad number: (CONFIG_SPL_MAX_SIZE + 0x1000)

Anyway, this is wrong and will break the u-boot-with-spl.imx for MMC/SD
boot device.

The default offset for the U-Boot image on MMC/SD boot device is 69KB
(see SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR) so I think CONFIG_SPL_PAD_TO
should always be 0x11000 (== 68KB).

Regards,

>  
>  /* MMC support */
>  #if defined(CONFIG_SPL_MMC_SUPPORT)
> 


-- 
Sébastien Szymanski
Software engineer, Armadeus Systems
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 11/20] w1: enumerate sandbox driver if configured

2018-07-20 Thread Lukasz Majewski
Hi Eugen,

Thanks for (re-)bringing the One wire support to u-boot.

> Add a sandbox eeprom on the bus as a device, if sandbox driver is
> configured.
> 
> Signed-off-by: Eugen Hristev 
> ---
>  drivers/w1/w1-uclass.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c
> index cfddda3..e58c1ca 100644
> --- a/drivers/w1/w1-uclass.c
> +++ b/drivers/w1/w1-uclass.c
> @@ -142,6 +142,11 @@ static int w1_enumerate(struct udevice *bus)
>   }
>   }
>  
> +#ifdef CONFIG_W1_EEPROM_SANDBOX
> + /* before we are finished, add a sandbox device if we can */
> + w1_new_device(bus, W1_FAMILY_EEP_SANDBOX);
> +#endif

IMHO we shouldn't mix the sandbox code with production (on boards) code.

Maybe Simon (+CCed) could provide some more input here?

> +
>   return 0;
>  }
>  




Best regards,

Lukasz Majewski

--

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


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


Re: [U-Boot] [PATCH 3/3] rockchip: rk3399: Add more instructions to the README

2018-07-20 Thread Ezequiel Garcia
On Wed, 2018-07-18 at 19:32 -0600, Simon Glass wrote:
> On 16 July 2018 at 13:41, Ezequiel Garcia  wrote:
> > This commit adds a content section and also instructions
> > on how to create a bootable SD/MMC device for RK3399 boards.
> > 
> > Signed-off-by: Ezequiel Garcia 
> > ---
> >  board/rockchip/evb_rk3399/README | 55 ++--
> >  1 file changed, 53 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> Hmm, we should convert all of rockchip to use binman I think.
> 

Yeah, that would be sweet.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


  1   2   >