Re: [U-Boot] [U-Boot, RESEND, 2/2] rockchip: clk: add device_bind_driver_to_node for reset driver

[Dr. Philipp Tomsich]

> On 27 Nov 2017, at 11:15, Kever Yang  wrote:
> 
> Philipp,
> 
> 
> On 11/22/2017 06:55 AM, Philipp Tomsich wrote:
>> 
>> 
>> On Fri, 3 Nov 2017, Kever Yang wrote:
>> 
>>> From: Elaine Zhang 
>>> 
>>> all rockchip socs add device_bind_driver_to_node,
>>> to bound device rockchip reset to clock-controller.
>>> 
>>> Signed-off-by: Elaine Zhang 
>>> Signed-off-by: Kever Yang 
>>> Acked-by: Philipp Tomsich 
>> 
>> Reviewed-by: Philipp Tomsich 
>> 
>> See below for requested changes.
>> 
>>> ---
>>> 
>>> arch/arm/include/asm/arch-rockchip/clock.h |  6 +
>>> drivers/clk/rockchip/clk_rk3036.c  | 15 -
>>> drivers/clk/rockchip/clk_rk3128.c  | 15 -
>>> drivers/clk/rockchip/clk_rk3188.c  | 15 -
>>> drivers/clk/rockchip/clk_rk322x.c  | 15 -
>>> drivers/clk/rockchip/clk_rk3288.c  | 15 -
>>> drivers/clk/rockchip/clk_rk3328.c  | 15 -
>>> drivers/clk/rockchip/clk_rk3368.c  | 15 -
>>> drivers/clk/rockchip/clk_rk3399.c  | 36 
>>> +-
>>> drivers/clk/rockchip/clk_rv1108.c  | 15 -
>>> 10 files changed, 153 insertions(+), 9 deletions(-)
>>> 
>>> diff --git a/arch/arm/include/asm/arch-rockchip/clock.h 
>>> b/arch/arm/include/asm/arch-rockchip/clock.h
>>> index 736b260..b812977 100644
>>> --- a/arch/arm/include/asm/arch-rockchip/clock.h
>>> +++ b/arch/arm/include/asm/arch-rockchip/clock.h
>>> @@ -44,6 +44,12 @@ struct sysreset_reg {
>>>unsigned int glb_srst_snd_value;
>>> };
>>> 
>>> +struct softreset_reg {
>>> +void __iomem *base;
>>> +unsigned int sf_reset_offset;
>>> +unsigned int sf_reset_num;
>>> +};
>>> +
>>> /**
>>> * clk_get_divisor() - Calculate the required clock divisior
>>> *
>>> diff --git a/drivers/clk/rockchip/clk_rk3036.c 
>>> b/drivers/clk/rockchip/clk_rk3036.c
>>> index 280ebb9..32b250f 100644
>>> --- a/drivers/clk/rockchip/clk_rk3036.c
>>> +++ b/drivers/clk/rockchip/clk_rk3036.c
>>> @@ -330,8 +330,9 @@ static int rk3036_clk_probe(struct udevice *dev)
>>> static int rk3036_clk_bind(struct udevice *dev)
>>> {
>>>int ret;
>>> -struct udevice *sys_child;
>>> +struct udevice *sys_child, *sf_child;
>>>struct sysreset_reg *priv;
>>> +struct softreset_reg *sf_priv;
>>> 
>>>/* The reset driver does not have a device node, so bind it here */
>>>ret = device_bind_driver(dev, "rockchip_sysreset", "sysreset",
>>> @@ -347,6 +348,18 @@ static int rk3036_clk_bind(struct udevice *dev)
>>>sys_child->priv = priv;
>>>}
>>> 
>>> +ret = device_bind_driver_to_node(dev, "rockchip_reset", "reset",
>>> + dev_ofnode(dev), _child);
>>> +if (ret) {
>>> +debug("Warning: No rockchip reset driver: ret=%d\n", ret);
>>> +} else {
>>> +sf_priv = malloc(sizeof(struct softreset_reg));
>>> +sf_priv->sf_reset_offset = offsetof(struct rk3036_cru,
>>> +cru_softrst_con[0]);
>>> +sf_priv->sf_reset_num = 9;
>>> +sf_child->priv = sf_priv;
>>> +}
>> 
>> This code is repeated throughout our code-base (see below for how often it 
>> appears).  Can you please factor this out into a helper function that is 
>> located with the reset-driver and that can be called?
>> 
>> E.g. something along the lines of
>>rockchip_sysreset_bind(sf_reset_offset, sf_reset_num)
> 
> I don't like them either, but each soc have different configure, we have to
> assign reset_offset and reset_ num for each soc, maybe we can use an in-line
> function which may save a few lines coding?

This should not be time-critical, so even a regular function (in 
sysreset_rockchip.c)
should work. As I said: "rockchip_sysreset_bind(sf_reset_offset, sf_reset_num)”
looks like a possible function call name/signature.

> Thanks,
> - Kever
>> 
>>> +
>>>return 0;
>>> }
>>> 
>>> diff --git a/drivers/clk/rockchip/clk_rk3128.c 
>>> b/drivers/clk/rockchip/clk_rk3128.c
>>> index c75cbf8..45e36a2 100644
>>> --- a/drivers/clk/rockchip/clk_rk3128.c
>>> +++ b/drivers/clk/rockchip/clk_rk3128.c
>>> @@ -325,8 +325,9 @@ static int rk3128_clk_probe(struct udevice *dev)
>>> static int rk3128_clk_bind(struct udevice *dev)
>>> {
>>>int ret;
>>> -struct udevice *sys_child;
>>> +struct udevice *sys_child, *sf_child;
>>>struct sysreset_reg *priv;
>>> +struct softreset_reg *sf_priv;
>>> 
>>>/* The reset driver does not have a device node, so bind it here */
>>>ret = device_bind_driver(dev, "rockchip_sysreset", "sysreset",
>>> @@ -342,6 +343,18 @@ static int rk3128_clk_bind(struct udevice *dev)
>>>sys_child->priv = priv;
>>>}
>>> 
>>> +ret = device_bind_driver_to_node(dev, "rockchip_reset", "reset",
>>> + 

[U-Boot] [PATCH] rockchip: board: evb_rv1108: update README

[Andy Yan]

After commit d962e5dadc2c("rockchip: mkimage: use spl_boot0 for all Rockchip 
SoCs"),
the mkimage will not pad the Tag memroy, so we shoud
pass a Taged ddr.bin/spl.bin to it.

Signed-off-by: Andy Yan 
---

 board/rockchip/evb_rv1108/README | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/board/rockchip/evb_rv1108/README b/board/rockchip/evb_rv1108/README
index 5889596..79a97c3 100644
--- a/board/rockchip/evb_rv1108/README
+++ b/board/rockchip/evb_rv1108/README
@@ -3,12 +3,11 @@ Here is the step-by-step to boot U-Boot on rv1108 evb.
 Get ddr init binary
 ==
   > git clone  https://github.com/rockchip-linux/rkbin.git
-  > dd if=./rkbin/rv1x/rv1108ddr.bin of=ddr.bin bs=4 skip=1
 
 Compile  U-Boot
 ===
   > make CROSS_COMPILE=arm-linux-gnueabi- evb-rv1108_defconfig  all
-  > ./tools/mkimage  -n rv1108 -T rksd -d ddr.bin spl.bin
+  > ./tools/mkimage  -n rv1108 -T rksd -d ../rkbin/rv1x/rv1108ddr_v1.00.bin 
spl.bin
   > cat spl.bin u-boot.bin > u-boot.img
 
 Flash the image by rkdeveloptool
@@ -16,7 +15,7 @@ Flash the image by rkdeveloptool
 rkdeveloptool can get from https://github.com/rockchip-linux/rkdeveloptool.git
 
 Power on(or reset with RESET KEY) with MASKROM KEY preesed, and then:
-  > rkdeveloptool db ./rkbin/rv1x/RV1108_usb_boot.bin
+  > rkdeveloptool db ./rkbin/rv1x/rv1108usbboot_v1.00.bin
   > rkdeveloptool wl 0x40 u-boot.img
   > rkdeveloptool RD
 
-- 
2.7.4


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

[U-Boot] [PATCH] serial: sh: Add support for R7S72100 (RZ/A1)

[Chris Brandt]

Add support for RZ/A1 series SoCs.

Signed-off-by: Chris Brandt 
---
 drivers/serial/serial_sh.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/serial_sh.h b/drivers/serial/serial_sh.h
index 4d27122243..365d944b62 100644
--- a/drivers/serial/serial_sh.h
+++ b/drivers/serial/serial_sh.h
@@ -227,7 +227,7 @@ struct uart_port {
 #elif defined(CONFIG_R8A7790) || defined(CONFIG_R8A7791) || \
defined(CONFIG_R8A7792) || defined(CONFIG_R8A7793) || \
defined(CONFIG_R8A7794) || defined(CONFIG_R8A7795) || \
-   defined(CONFIG_R8A7796)
+   defined(CONFIG_R8A7796) || defined(CONFIG_R7S72100)
 # if defined(CONFIG_SCIF_A)
 #  define SCIF_ORER0x0200
 # else
-- 
2.14.1


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

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

[Tom Rini]

On Sun, Nov 26, 2017 at 09:42:21PM +0100, Dr. Philipp Tomsich wrote:

> Tom,
> 
> Please pull u-boot-rockchip/master.
> 
> This finally merges the SPL-changes for improved ATF support that
> had been in the works since 2 merge-windows ago.  Plus, there’s a
> few fixes to platform-support (e.g. pinctrl on the RK3399) and for
> some recently merged patches that had unexpected side-effects.
> 
> The matching travis run for this P/R is
>   https://travis-ci.org/ptomsich/u-boot-rockchip/builds/307490625
> 
> Thanks,
> Philipp.
> 
> 
> The following changes since commit 93a51d301ad051ec6f8c6016862c7719b8b434d3:
> 
>   Merge git://git.denx.de/u-boot-arc (2017-11-24 11:45:15 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git master
> 
> for you to fetch changes up to e5ee24dda20af5dc87971b497268f9fb1c83027e:
> 
>   rockchip: defconfig: puma-rk3399: bypass ADC-based boot_mode check 
> (2017-11-26 14:59:38 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] UBI / UBIFS booting from NAND support

[jsanabria]

El 27/11/17 a las 12:31, Ladislav Michl escribió:

Dear Jose Miguel,

On Mon, Nov 27, 2017 at 11:45:11AM +0100, Jose Miguel Sanchez Sanabria wrote:

Hi everyone.

I was testing the booting process from NAND using an UBI/UBIFS image in an
igepv2 board.

I'm happy to see someone from ISEE being interested in mainline support
for their own product.


However MLO tries to boot first kernel (falcon mode activated) and then
falls back to u-boot (as expected anyway I just wanted to load u-boot from
ubi) trying to load volume 0, but fails.

Due to size restrictions, MLO does contain only limited UBI functionality,
just enough to load image from static UBI volume.


U-Boot SPL 2017.11-dirty (Nov 24 2017 - 14:29:26)
Trying to boot from NAND
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 3
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 3
UBI warning: Failed
Loading Linux failed, falling back to U-Boot.
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 0
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 0
UBI warning: Failed
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

As noted above, ubispl loader is rather limited and identifies volumes
by volume id. u-boot.img is expected to be found in vol_id=0, while linux
zImage in vol_id=3. Log above indicates there are no such volumes.
What does u-boot's command 'ubi info l' show?


Heres the log of ubi info :

Volume information dump:
    vol_id  0
    reserved_pebs   82
    alignment   1
    data_pad    0
    vol_type    4
    name_len    9
    usable_leb_size 129024
    used_ebs    5
    used_bytes  539424
    last_eb_bytes   23328
    corrupted   0
    upd_marker  0
    name    ubirootfs
Volume information dump:
    vol_id  2147479551
    reserved_pebs   2
    alignment   1
    data_pad    0
    vol_type    3
    name_len    13
    usable_leb_size 129024
    used_ebs    2
    used_bytes  258048
    last_eb_bytes   2
    corrupted   0
    upd_marker  0
    name    layout volume


I created with:

ubi create ubirootfs 0xA0 static 0

I just wanted a volume of 10 MiB (as I only pretend to load u-boot from it for 
now) so that went pretty good.


I can however mount the ubi image but suspicious log appear:

u-boot:> ubifsmount ubi0:ubirootfs

Now you are in u-boot, where different UBI implementation is used, so
you can identify volumes also by name.


I was mounting only to see the correct files were there (u-boot.img and 
uEnv.txt)



UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278

This has to do with the discussion about ubifs null deference so I suppose
it should not affect much to write operation.

Well, I do not use UBIFS in U-Boot at all. Just UBI to read and write volumes.

Ahh I see I was trying to "ubi write" onto volume the ubifs image which 
contained the (u-boot.img and uEnv.txt), but if I do like on your script 
(writing directly the u-boot.img and uEnv.txt) onto the volume it works 
perfectly.

I would finally like to know if the ubi/ubifs support is functional; which
would mean I did not use the ubi tools correctly to create the ubi image.

You will find script I'm using to bring board up at the end of this mail.
But note, that 'fdt memory' is hacked a bit and proper implementaion is welcome:
https://lists.denx.de/pipermail/u-boot/2017-January/279823.html

Also note 'setenv fdtfile "${soc_family}-${board_name}.dtb"' line. That's also
not in mainline as it needs also board revision too and the way it is currently
done, we cannot distinguish rev B. and rev F. Unfortunately this article
http://labs.isee.biz/index.php/IGEP_Technology_devices_revisions#IGEP0020_revisions
does not explain, how all those numbers map to board revisions ISEE is using
in vendor code.

thanks for reporting I'll keep and eye on this later.

That said, I enabled UBIFS for IGEPv2 only localy to verify my ubifs_finddir
reimplementation, but as I was even unable to mount ubifs, original reporter
did not confirm that at least mount works for him and I run out of the time,
ubifs issue is still unresolved.

Best regards,
ladis
I could mount ubifs using ubifsmount command but there were a bit of 
warnings and then after trying to boot the spl did not find volume at all.


Thank you for your time.


echo "*** starting u-boot instalation script ***"
nandecc hw hamming
setenv has_onenand $?
# MLO ...
fatload mmc 0:1 $loadaddr MLO
if test $has_onenand -eq 0
then
nand erase.part SPL
nand write $fileaddr 0 $filesize
nand write $fileaddr 2 $filesize
nand write $fileaddr 4 $filesize
   

Re: [U-Boot] [PATCH] mmc: sh_mmcif: RZ/A1 does not support HS mode

[Chris Brandt]

On Monday, November 27, 2017, Jaehoon Chung wrote:
> On 11/14/2017 05:41 AM, Chris Brandt wrote:
> > Since RZ/A1 (R7S72100) does not support HS mode, remove it from the
> > host caps.
> 
> Doesn't HS mode? Then it's only supported the legacy mode?

Sorry, please ignore this patch.

The MMC controller in the RZ/A1 can generate up to a 33MHz clock, so it 
does support "High Speed" mode.

I just tested it and it works fine the way it is.


Chris

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

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

[Felix Brack]

Hello Simon,

On 26.11.2017 12:38, Simon Glass wrote:
> Hi Felix,
> 
> On 23 November 2017 at 08:36, Felix Brack  wrote:
>>
>>
>> On 22.11.2017 11:39, Felix Brack wrote:
>>> Hello Simon,
>>>
>>> Many thanks for taking the time to review my patch.
>>>
>>> On 20.11.2017 16:38, Simon Glass wrote:
 Hi Felix,

> +
> +/* platform data */
> +struct tps65910_pdata {
> +   u32 supply[TPS65910_NUM_SUPPLIES]; /* regulator supply voltage in 
> uV */
> +};

 Is this used outside the driver? Do you need one driver to access
 another's platform data? That seems dodgy.

>>> No. You are right: no need to place it in the header file. I will move
>>> it to pmic_tps65910_dm.c file.
>>>
>> Sorry, this is not correct. The regulators of the PMIC need access to
>> this. Let me try to explain:
>>
>> The PMIC has 8 different supply inputs. These are therefore properties
>> of the PMIC. Each of the 12 regulators uses one of these 8 supply
>> voltages as its input. Hence the regulators of the TPS65910 need read
>> access to the PMIC's information about the supplies. In other words: a
>> regulator's supply voltage has to be queried from the corresponding PMIC.
>>
>> I think I followed the "rules" when implementing the PMIC and the
>> regulator code in separate files.
> 
> OK, so the problem is that the regulator has to look up the supply
> voltage in the PMIC?
> 
Yes

> Should this be platform data (accessible before the device is probed)
> or private data (which exists only when the device is active)?
> 
The regulator supply voltages are defined in the DT. Hence they should
be read by ofdata_to_platdata() and store as platform data, I think.

> Also why does the PMIC driver itself know about supply voltages? I
> think that info should be in the regulator driver. The PMIC is really
> just a parent driver providing access to the various subsystems of the
> PMIC (regulator, GPIO, battery, etc).
> 
I agree - the PMIC driver does not require the knowledge about the
supply voltage of a distinct regulator. It is just that the PMIC is
modeled like this in the DT, i.e. the supplies are proerties of the PMIC
and not the regulators (which are subnodes on the same level as the
supply nodes).
Having said that, I think the proper solution is as follows:
Use the regulator driver's ofdata_to_platdata() to query the supply
voltage of that specific regulator by device_get_supply_regulator()
using dev->parent (the PMIC) as device parameter.
The supply voltage will then be "part" of the regulator instead of the
PMIC. Do you agree to this solution?

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

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

[Fabio Estevam]

From: Fabio Estevam 

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

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

Signed-off-by: Fabio Estevam 
---
Changes since v2:
- Adjust nxp_board_rev_string() to return char.

 arch/arm/mach-imx/mx6/Kconfig   |  1 +
 board/freescale/mx6sxsabresd/mx6sxsabresd.c | 16 +++-
 configs/mx6sxsabresd_defconfig  |  1 +
 configs/mx6sxsabresd_spl_defconfig  |  1 +
 include/configs/mx6sxsabresd.h  |  8 ++--
 5 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index bee7eab..44d2db4 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -255,6 +255,7 @@ config TARGET_MX6SLLEVK
 
 config TARGET_MX6SXSABRESD
bool "mx6sxsabresd"
+   select BOARD_LATE_INIT
select MX6SX
select SUPPORT_SPL
select DM
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c 
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 2aeef61..3ad2140 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -540,9 +540,23 @@ int board_init(void)
return 0;
 }
 
+static bool is_reva(void)
+{
+   return (nxp_board_rev() == 1);
+}
+
+int board_late_init(void)
+{
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+   if (is_reva())
+   env_set("board_rev", "REVA");
+#endif
+   return 0;
+}
+
 int checkboard(void)
 {
-   puts("Board: MX6SX SABRE SDB\n");
+   printf("Board: MX6SX SABRE SDB rev%c\n", nxp_board_rev_string());
 
return 0;
 }
diff --git a/configs/mx6sxsabresd_defconfig b/configs/mx6sxsabresd_defconfig
index 2c184f6..f489908 100644
--- a/configs/mx6sxsabresd_defconfig
+++ b/configs/mx6sxsabresd_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_MX6SXSABRESD=y
 # CONFIG_CMD_BMODE is not set
+CONFIG_NXP_BOARD_REVISION=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6sxsabresd/imximage.cfg"
 CONFIG_BOOTDELAY=3
 # CONFIG_CONSOLE_MUX is not set
diff --git a/configs/mx6sxsabresd_spl_defconfig 
b/configs/mx6sxsabresd_spl_defconfig
index 5dca33d..2f57773 100644
--- a/configs/mx6sxsabresd_spl_defconfig
+++ b/configs/mx6sxsabresd_spl_defconfig
@@ -9,6 +9,7 @@ CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
 # CONFIG_CMD_BMODE is not set
+CONFIG_NXP_BOARD_REVISION=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 CONFIG_BOOTDELAY=3
 # CONFIG_CONSOLE_MUX is not set
diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
index f4c9c28..906e677 100644
--- a/include/configs/mx6sxsabresd.h
+++ b/include/configs/mx6sxsabresd.h
@@ -43,6 +43,7 @@
 #define UPDATE_M4_ENV ""
 #endif
 
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
 #define CONFIG_EXTRA_ENV_SETTINGS \
UPDATE_M4_ENV \
"script=boot.scr\0" \
@@ -105,10 +106,13 @@
"fi; " \
"else " \
"bootz; " \
-   "fi;\0"
+   "fi;\0" \
+   "findfdt="\
+   "if test test $board_rev = REVA ; then " \
+   "setenv fdt_file imx6sx-sdb-reva.dtb; fi; " \
 
 #define CONFIG_BOOTCOMMAND \
-  "mmc dev ${mmcdev};" \
+  "run findfdt; " \
   "mmc dev ${mmcdev}; if mmc rescan; then " \
   "if run loadbootscript; then " \
   "run bootscript; " \
-- 
2.7.4

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

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

[Fabio Estevam]

From: Fabio Estevam 

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

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

Signed-off-by: Fabio Estevam 
---
Changes since v2:
- Make nxp_board_rev_string() return a char.

 arch/arm/include/asm/mach-imx/sys_proto.h   |  3 ++
 arch/arm/mach-imx/Kconfig   |  8 +
 arch/arm/mach-imx/cpu.c | 25 +++
 board/freescale/mx6sabreauto/mx6sabreauto.c | 47 ++---
 configs/mx6sabreauto_defconfig  |  1 +
 5 files changed, 39 insertions(+), 45 deletions(-)

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

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

[Wolfgang Denk]

Dear Masahiro,

In message  
you wrote:
>
> When we talk about "relocation", two things are happening.
> 
>  [1] U-Boot proper copies itself to the very end of DRAM

...to the very end of DRAM minus space reserved for any memory
regions we want to reserver for / share with the Linux kernel
(video memory, log buffer, protected RAM, ...)

>  [2] Fix-up the global symbols
> 
> In my opinion, only [2] is useful.

This is your opinion, accepted.
I do not agree with this, i. e. I have a different opinion.

> SPL initializes the DRAM, so it knows the base and size of DRAM.

But it does not know the relocation address yet.  As this is
dynamically computed, depending on environment variable settings,
moving this calculation into the SPL means the SPL must be capable to
read the environment.  this pulls in a ton of code, and any
advantages you may have for falcon mode are damaged.

> The following is how the ideal boot loader would work.
> 
> 
> Requirement for U-Boot proper:
> U-Boot never changes the location by itself.

This means you kill all the features that depend on this?

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
f u cn rd ths, itn tyg h myxbl cd.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] UBI / UBIFS booting from NAND support

[Jose Miguel Sanchez Sanabria]

Hi everyone.

I was testing the booting process from NAND using an UBI/UBIFS image in an
igepv2 board.
However MLO tries to boot first kernel (falcon mode activated) and then
falls back to u-boot (as expected anyway I just wanted to load u-boot from
ubi) trying to load volume 0, but fails.

U-Boot SPL 2017.11-dirty (Nov 24 2017 - 14:29:26)
Trying to boot from NAND
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 3
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 3
UBI warning: Failed
Loading Linux failed, falling back to U-Boot.
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 0
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 0
UBI warning: Failed
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

I can however mount the ubi image but suspicious log appear:

u-boot:> ubifsmount ubi0:ubirootfs
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278

This has to do with the discussion about ubifs null deference so I suppose
it should not affect much to write operation.

I would finally like to know if the ubi/ubifs support is functional; which
would mean I did not use the ubi tools correctly to create the ubi image.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] SECURE_BOOT on mx6qsabrelite

[Roger No-Spam]

Hi,


I'm trying to enable CONFIG_SECURE_BOOT for an i.MX6 board (mx6qsabrelite). The 
image boots and seems to be working fine until I do a 'saveenv' command. Then 
my u-boot image stops working. My initial guess was that CONFIG_ENV_OFFSET was 
too small, leading to a 'saveenv' command overwriting parts of the u-boot image 
on the MMC memory card. However, if I increase CONFIG_ENV_OFFSET the size of 
the signed u-boot image created by the CST tool increase by the same amount. 
What configuration change do I need to make in order to make 'saveenv' work?


I'm using u-boot-2017.09


Regard Roger

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

Re: [U-Boot] [PATCH 2/4] i2c: meson: reduce timeout

[Simon Glass]

On 26 November 2017 at 09:40, Beniamino Galvani  wrote:
> The datasheet doesn't specify a suggested timeout and 500ms seems very
> long: reduce it to 100ms.
>
> Signed-off-by: Beniamino Galvani 
> ---
>  drivers/i2c/meson_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH 3/4] i2c: meson: fix return codes on error

[Simon Glass]

On 26 November 2017 at 09:40, Beniamino Galvani  wrote:
> Change meson_i2c_xfer_msg() to return -EREMOTEIO in case of NACK, as
> done by other drivers. Also, don't change the return error in
> meson_i2c_xfer().
>
> Signed-off-by: Beniamino Galvani 
> ---
>  drivers/i2c/meson_i2c.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v2 1/4] dm: mmc: update mmc_of_parse()

[Simon Glass]

Hi Jean-Jacques,

On 27 November 2017 at 02:59, Jean-Jacques Hiblot  wrote:
> * convert to livetree API
> * don't fail because of an invalid bus-width, instead default to 1-bit.
> * recognize 1.2v DDR and 1.2v HS200 flags
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
> changes since v1:
> * convert to livetree
> * squashed all change to mmc_of_parse into this single commit
> * Add a descriptive comment fo mmc_of_parse in the header
>
>  drivers/mmc/mmc-uclass.c | 37 ++---
>  include/mmc.h| 11 ++-
>  2 files changed, 32 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index e30cde7..f117923 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "mmc_private.h"
>
> @@ -120,11 +121,12 @@ int mmc_execute_tuning(struct mmc *mmc, uint opcode)
> return dm_mmc_execute_tuning(mmc->dev, opcode);
>  }
>
> -int mmc_of_parse(const void *fdt, int node, struct mmc_config *cfg)
> +int mmc_of_parse(struct udevice *dev, struct mmc_config *cfg)
>  {
> int val;
> +   ofnode ref = dev_ofnode(dev);

Do you need this? I think you can just use dev_read_...() below
instead of ofnode_...() ?

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

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

[Simon Glass]

On 27 November 2017 at 02:59, Jean-Jacques Hiblot  wrote:
> Make sure that those basic capabilities are advertised by the host.
>
> Signed-off-by: Jean-Jacques Hiblot 
> Reviewed-by: Lukasz Majewski 
> ---
>
> no change since v1
>
>  drivers/mmc/mmc.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)

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

[U-Boot] [PATCHv3] env: enable accessing the environment in an EXT4 partition

[Jorge Ramirez-Ortiz]

the following commit enables accessing the environment in an ext4
partition. In order to do that, some definitions need to be added to
include/configs/board_x.h file.

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, you should define:

  EXT4_ENV_DEVICE_AND_PART"0:1"
  EXT4_ENV_INTERFACE  "mmc"
  EXT4_ENV_FILE   "/uboot.env"
---
 env/Kconfig | 7 +++
 env/env.c   | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/env/Kconfig b/env/Kconfig
index 2477bf8..09309ab 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -81,6 +81,13 @@ config ENV_IS_IN_FAT
  - CONFIG_FAT_WRITE:
  This must be enabled. Otherwise it cannot save the environment file.
 
+config ENV_IS_IN_EXT4
+   bool "Environment is in a EXT4 filesystem"
+   depends on !CHAIN_OF_TRUST
+   select EXT4_WRITE
+   help
+ Define this if you want to use the EXT4 file system for the 
environment.
+
 config ENV_IS_IN_FLASH
bool "Environment in flash memory"
depends on !CHAIN_OF_TRUST
diff --git a/env/env.c b/env/env.c
index 76a5608..7455632 100644
--- a/env/env.c
+++ b/env/env.c
@@ -32,6 +32,8 @@ static enum env_location env_get_default_location(void)
return ENVL_EEPROM;
else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
return ENVL_FAT;
+   else if IS_ENABLED(CONFIG_ENV_IS_IN_EXT4)
+   return ENVL_EXT4;
else if IS_ENABLED(CONFIG_ENV_IS_IN_FLASH)
return ENVL_FLASH;
else if IS_ENABLED(CONFIG_ENV_IS_IN_MMC)
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2] x86: lib: Implement standalone __udivdi3 etc instead of libgcc ones

[Stefan Roese]

Hi Bin,

On 27.11.2017 10:46, Bin Meng wrote:

On Fri, Nov 24, 2017 at 5:29 PM, Stefan Roese  wrote:

Hi Bin,


On 24.11.2017 09:29, Bin Meng wrote:


On Mon, Nov 20, 2017 at 6:43 PM, Stefan Roese  wrote:


Hi Bin,


On 20.11.2017 08:24, Bin Meng wrote:



On Fri, Nov 17, 2017 at 2:02 PM, Stefan Roese  wrote:



This patch removes the inclusion of the libgcc math functions and
replaces them by functions coded in C, taken from the coreboot
project. This makes U-Boot building more independent from the toolchain
installed / available on the build system.

The code taken from coreboot is authored from Vadim Bendebury
 on 2014-11-28 and committed with commit
ID e63990ef [libpayload: provide basic 64bit division implementation]
(coreboot git repository located here [1]).

I modified the code so that its checkpatch clean without any
functional changes.

[1] git://github.com/coreboot/coreboot.git

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Bin Meng 
---
v2:
- Added coreboot git repository link to commit message

arch/x86/config.mk|   3 --
arch/x86/lib/Makefile |   2 +-
arch/x86/lib/div64.c  | 113
++
arch/x86/lib/gcc.c|  29 -
4 files changed, 114 insertions(+), 33 deletions(-)
create mode 100644 arch/x86/lib/div64.c
delete mode 100644 arch/x86/lib/gcc.c

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 8835dcf36f..472ada5490 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -34,9 +34,6 @@ PLATFORM_RELFLAGS += -ffunction-sections
-fvisibility=hidden
PLATFORM_LDFLAGS += -Bsymbolic -Bsymbolic-functions
PLATFORM_LDFLAGS += -m $(if $(IS_32BIT),elf_i386,elf_x86_64)

-LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3
-LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3
-
# This is used in the top-level Makefile which does not include
# PLATFORM_LDFLAGS
LDFLAGS_EFI_PAYLOAD := -Bsymbolic -Bsymbolic-functions -shared
--no-undefined
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index fe00d7573f..d9b23f5cc4 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_SEABIOS) += coreboot_table.o
obj-y  += early_cmos.o
obj-$(CONFIG_EFI) += efi/
obj-y  += e820.o
-obj-y  += gcc.o
+obj-y  += div64.o
obj-y  += init_helpers.o
obj-y  += interrupts.o
obj-y  += lpc-uclass.o
diff --git a/arch/x86/lib/div64.c b/arch/x86/lib/div64.c
new file mode 100644
index 00..4efed74037
--- /dev/null
+++ b/arch/x86/lib/div64.c
@@ -0,0 +1,113 @@
+/*
+ * This file is copied from the coreboot repository as part of
+ * the libpayload project:
+ *
+ * Copyright 2014 Google Inc.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+
+union overlay64 {
+   u64 longw;
+   struct {
+   u32 lower;
+   u32 higher;
+   } words;
+};
+
+u64 __ashldi3(u64 num, unsigned int shift)
+{
+   union overlay64 output;
+
+   output.longw = num;
+   if (shift >= 32) {
+   output.words.higher = output.words.lower << (shift -
32);
+   output.words.lower = 0;
+   } else {
+   if (!shift)
+   return num;
+   output.words.higher = (output.words.higher << shift) |
+   (output.words.lower >> (32 - shift));
+   output.words.lower = output.words.lower << shift;
+   }
+   return output.longw;
+}
+
+u64 __lshrdi3(u64 num, unsigned int shift)
+{
+   union overlay64 output;
+
+   output.longw = num;
+   if (shift >= 32) {
+   output.words.lower = output.words.higher >> (shift -
32);
+   output.words.higher = 0;
+   } else {
+   if (!shift)
+   return num;
+   output.words.lower = output.words.lower >> shift |
+   (output.words.higher << (32 - shift));
+   output.words.higher = output.words.higher >> shift;
+   }
+   return output.longw;
+}
+
+#define MAX_32BIT_UINT u64)1) << 32) - 1)
+
+static u64 _64bit_divide(u64 dividend, u64 divider, u64 *rem_p)
+{
+   u64 result = 0;
+
+   /*
+* If divider is zero - let the rest of the system care about
the
+* exception.
+*/
+   if (!divider)
+   return 1 / (u32)divider;
+
+   /* As an optimization, let's not use 64 bit division unless we
must. */
+   if (dividend <= MAX_32BIT_UINT) {
+   if (divider > MAX_32BIT_UINT) {
+   result = 0;
+   if (rem_p)
+   *rem_p = divider;
+   } else {
+   result = (u32)dividend / (u32)divider;
+   if (rem_p)
+   *rem_p = (u32)dividend % (u32)divider;
+   }
+

Re: [U-Boot] [PATCH 1/4] i2c: meson: improve Kconfig description

[Simon Glass]

On 26 November 2017 at 09:40, Beniamino Galvani  wrote:
> Expand the Kconfig description with hardware features.
>
> Signed-off-by: Beniamino Galvani 
> ---
>  drivers/i2c/Kconfig | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> index 1989f8eb57..a7931aa6d4 100644
> --- a/drivers/i2c/Kconfig
> +++ b/drivers/i2c/Kconfig
> @@ -141,7 +141,12 @@ config SYS_I2C_MESON
> bool "Amlogic Meson I2C driver"
> depends on DM_I2C && ARCH_MESON
> help
> - Add support for the Amlogic Meson I2C driver.
> + Add support for the I2C controller available in Amlogic Meson
> + SoCs. The controller supports programmable bus speed including
> + standard (100kbits/s) and fast (400kbit/s) speed and allows the
> + software to define a flexible format of the bit streams. It has an
> + internal buffer holding up to 8 bytes for transfers and supports
> + both 7-bit and 10-bit addresses.
>
>  config SYS_I2C_MXC
> bool "NXP i.MX I2C driver"
> --
> 2.14.3
>

Great!

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

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

[Simon Glass]

(Tom - any thoughts about a more expansive cc list on this?)

Hi Masahiro,

On 26 November 2017 at 07:16, Masahiro Yamada
 wrote:
> 2017-11-26 20:38 GMT+09:00 Simon Glass :
>> Hi Philipp,
>>
>> On 25 November 2017 at 16:31, Dr. Philipp Tomsich
>>  wrote:
>>> Hi,
>>>
 On 25 Nov 2017, at 23:34, Simon Glass  wrote:

 +Tom, Masahiro, Philipp

 Hi,

 On 22 November 2017 at 03:27, Wolfgang Denk  wrote:
> Dear Kever Yang,
>
> In message  you 
> wrote:
>>
>> I can understand this feature, we always do dram_init_banks() first,
>> then we relocate to 'known' area, then will be no risk to access memory.
>> I believe there must be some historical reason for some kind of device,
>> the relocate feature is a wonderful idea for it.
>
> This is actuallyu not so much a feature needed to support some
> specific device (in this case much simpler approahces would be
> possible), but to support a whole set of features.  Unfortunately
> these appear to get forgotten / ignored over time.
>
>> many other SoCs should be similar.
>> - Without relocate we can save many step, some of our customer really
>> care much about the boot time duration.
>> * no need to relocate everything
>> * no need to copy all the code
>> * no need init the driver more than once
>
> Please have a look at the README, section "Memory Management".
> The reloaction is not done to any _fixed_ address, but the address
> is actually computed at runtime, depending on a number features
> enabled (at least this is how it used to be - appearently little of
> this is tested on a regular base, so I would not be surprised if
> things are broken today).
>
> The basic idea was to reserve areas of memory at the top of RAM,
> that would not be initialized / modified by U-Boot and Linux, not
> even across a reset / warm boot.
>
> This was used for exaple for:
>
> - pRAM (Protected RAM) which could be used to store all kind of data
>  (for example, using a pramfs [Protected and Persistent RAM
>  Filesystem]) that could be kept across reboots of the OS.
>
> - shared frame buffer / video memory. U-Boot and Linux would be able
>  to initialize the video memory just once (in U-Boot) and then
>  share it, maybe even across reboots.  especially, this would allow
>  for a very early splash screen that gets passed (flicker free) to
>  Linux until some Linux GUI takes over (much more difficult today).
>
> - shared log buffer: U-Boot and Linux used to use the same syslog
>  buffer mechanism, so you could share it between U-Boot and Linux.
>  this allows for example to
>  * read the Linux kernel panic messages after reset in U-Boot; this
>is very useful when you bring up a new system and Linux crashes
>before it can display the log buffer on the console
>  * pass U-Boot POST results on to Linux, so the application code
>can read and process these
>  * process the system log of the previous run (especially after a
>panic) in Lunux after it rebootet.
>
> etc.
>
> There are a number of such features which require to reserve room at
> the top of RAM, the size of which is calculatedat runtime, often
> depending on user settable environment data.
>
> All this cannot be done without relocation to a (dynmaically
> computed) target address.
>
>
> Yes, the code could be simpler and faster without that - but then,
> you cut off a number of features.

 I would be interested in seeing benchmarks showing the cost of
 relocation in terms of boot time. Last time I did this was on Exynos 5
 and it was some years ago. The time was pretty small provided the
 cache was on for the memory copies associated with relocation itself.
 Something like 10-20ms but I don't have the numbers handy.

 I think it is useful to be able to allocate memory in board_init_f()
 for use by U-Boot for things like the display and the malloc() region.

 Options we might consider:

 1. Don't relocate the code and data. Thus we could avoid the copy and
 relocation cost. This is already supported with the GD_FLG_SKIP_RELOC
 used when U-Boot runs as an EFI app

 2. Rather than throwing away the old malloc() region, keep it around
 so existing allocated blocks work. Then new malloc() region would be
 used for future allocations. We could perhaps ignore free() calls in
 that region

 2a. This would allow us to avoid re-init of driver model in most cases
 I think. E.g. we could init serial and timer before relocation and
 leave them inited 

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

[Simon Glass]

Hi Felix,

On 27 November 2017 at 06:51, Felix Brack  wrote:
> Hello Simon,
>
> On 26.11.2017 12:38, Simon Glass wrote:
>> Hi Felix,
>>
>> On 23 November 2017 at 08:36, Felix Brack  wrote:
>>>
>>>
>>> On 22.11.2017 11:39, Felix Brack wrote:
 Hello Simon,

 Many thanks for taking the time to review my patch.

 On 20.11.2017 16:38, Simon Glass wrote:
> Hi Felix,
>
>> +
>> +/* platform data */
>> +struct tps65910_pdata {
>> +   u32 supply[TPS65910_NUM_SUPPLIES]; /* regulator supply voltage 
>> in uV */
>> +};
>
> Is this used outside the driver? Do you need one driver to access
> another's platform data? That seems dodgy.
>
 No. You are right: no need to place it in the header file. I will move
 it to pmic_tps65910_dm.c file.

>>> Sorry, this is not correct. The regulators of the PMIC need access to
>>> this. Let me try to explain:
>>>
>>> The PMIC has 8 different supply inputs. These are therefore properties
>>> of the PMIC. Each of the 12 regulators uses one of these 8 supply
>>> voltages as its input. Hence the regulators of the TPS65910 need read
>>> access to the PMIC's information about the supplies. In other words: a
>>> regulator's supply voltage has to be queried from the corresponding PMIC.
>>>
>>> I think I followed the "rules" when implementing the PMIC and the
>>> regulator code in separate files.
>>
>> OK, so the problem is that the regulator has to look up the supply
>> voltage in the PMIC?
>>
> Yes
>
>> Should this be platform data (accessible before the device is probed)
>> or private data (which exists only when the device is active)?
>>
> The regulator supply voltages are defined in the DT. Hence they should
> be read by ofdata_to_platdata() and store as platform data, I think.

OK.

>
>> Also why does the PMIC driver itself know about supply voltages? I
>> think that info should be in the regulator driver. The PMIC is really
>> just a parent driver providing access to the various subsystems of the
>> PMIC (regulator, GPIO, battery, etc).
>>
> I agree - the PMIC driver does not require the knowledge about the
> supply voltage of a distinct regulator. It is just that the PMIC is
> modeled like this in the DT, i.e. the supplies are proerties of the PMIC
> and not the regulators (which are subnodes on the same level as the
> supply nodes).
> Having said that, I think the proper solution is as follows:
> Use the regulator driver's ofdata_to_platdata() to query the supply
> voltage of that specific regulator by device_get_supply_regulator()
> using dev->parent (the PMIC) as device parameter.
> The supply voltage will then be "part" of the regulator instead of the
> PMIC. Do you agree to this solution?

Yes I think that is best from what I understand.

However if you find that you really do need to blur the line between
the regulator and the pmic, and share the pdata structure, it is not
the end of the world. It seems wrong to me, so I'd like to avoid it if
possible. We should have a good reason. The DT node structure is
certainly a reason, but it does not seem a strong enough reason to me.

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

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

[Simon Glass]

Hi Andes,

On 26 November 2017 at 20:03, Andes  wrote:
> From: Rick Chen 
>
> Integrate function and struct name as atcpit100 will be
> more reasonable.
>
> Signed-off-by: Rick Chen 
> ---
>  drivers/timer/atcpit100_timer.c | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/timer/atcpit100_timer.c b/drivers/timer/atcpit100_timer.c
> index b710c28..d5146dd 100644
> --- a/drivers/timer/atcpit100_timer.c
> +++ b/drivers/timer/atcpit100_timer.c
> @@ -67,51 +67,51 @@ struct atctmr_timer_regs {
> u32 int_mask;   /* 0x38 */
>  };
>
> -struct atftmr_timer_platdata {
> +struct atcpit_timer_platdata {
> u32 *regs;
>  };
>
> -static int atftmr_timer_get_count(struct udevice *dev, u64 *count)
> +static int atcpit_timer_get_count(struct udevice *dev, u64 *count)
>  {
> -   struct atftmr_timer_platdata *plat = dev->platdata;
> +   struct atcpit_timer_platdata *plat = dev->platdata;

dev_get_platdata()

and below

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

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

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

[Simon Glass]

On 27 November 2017 at 02:59, Jean-Jacques Hiblot  wrote:
> As the legacy modes were not added to the list of supported modes, old
> cards that do not support other modes could not be used.
>
> Signed-off-by: Jean-Jacques Hiblot 
> Reviewed-by: Lukasz Majewski 
> ---
>
> no change since v1
>
>
>  drivers/mmc/mmc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH] usb: r8a66597: Add support for RZ/A series

[Chris Brandt]

Hello Marek,

On Friday, November 17, 2017, Marek Vasut wrote:
> > +#ifdef RZA_USB
> > +   dcpctr = r8a66597_read(r8a66597, DCPCTR);
> 
> use wait_for_bit() .
> 
> > +   if ((dcpctr & PID) == PID_BUF) {
> > +   timeout2 = 1;
> > +   while (!(dcpctr & BSTS)) {
> > +   dcpctr = r8a66597_read(r8a66597, DCPCTR);
> > +   if (timeout2-- < 0) {
> > +   printf("DCPCTR clear timeout!\n");
> > +   break;
> > +   }
> > +   }
> > +   }
> > +#endif


wait_for_bit() wants you to pass a direct address of a 32-bit register.
The register I am waiting for is a 16-bit register and the hardware 
manual doesn't say 32-bit is allowed.
When I do a 32-bit read on that address, I actually get a different 
value.

For example:

=> md.w E8010060 1
e8010060: 0040
=> md.l E8010060 1
e8010060: 0040


So, I can't use wait_for_bit()

Chris

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

[U-Boot] [PATCH] env: enable CONFIG_ENV_IS_IN_EXT4

[Jorge Ramirez-Ortiz]

---
 env/Kconfig | 10 ++
 env/env.c   |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/env/Kconfig b/env/Kconfig
index 2477bf8..4387a2c 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -81,6 +81,16 @@ config ENV_IS_IN_FAT
  - CONFIG_FAT_WRITE:
  This must be enabled. Otherwise it cannot save the environment file.
 
+config ENV_IS_IN_EXT4
+   bool "Environment is in a EXT4 filesystem"
+   depends on !CHAIN_OF_TRUST
+   select EXT4_WRITE
+   help
+ Define this if you want to use the EXT4 file system for the 
environment.
+
+ - CONFIG_EXT4_WRITE:
+ This must be enabled. Otherwise it cannot save the environment file.
+
 config ENV_IS_IN_FLASH
bool "Environment in flash memory"
depends on !CHAIN_OF_TRUST
diff --git a/env/env.c b/env/env.c
index 76a5608..7455632 100644
--- a/env/env.c
+++ b/env/env.c
@@ -32,6 +32,8 @@ static enum env_location env_get_default_location(void)
return ENVL_EEPROM;
else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
return ENVL_FAT;
+   else if IS_ENABLED(CONFIG_ENV_IS_IN_EXT4)
+   return ENVL_EXT4;
else if IS_ENABLED(CONFIG_ENV_IS_IN_FLASH)
return ENVL_FLASH;
else if IS_ENABLED(CONFIG_ENV_IS_IN_MMC)
-- 
2.7.4

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

Re: [U-Boot] [PATCH v3] power: extend prefix match to regulator-name property

[Simon Glass]

On 27 November 2017 at 01:14, Felix Brack  wrote:
> This patch extends pmic_bind_children prefix matching. In addition to
> the node name the property regulator-name is used while trying to match
> prefixes. This allows assigning different drivers to regulator nodes
> named regulator@1 and regulator@10 for example.
> I have discarded the idea of using other properties then regulator-name
> as I do not see any benefit in using property compatible or even
> regulator-compatible. Of course I am open to change this if there are
> good reasons to do so.
>
> Signed-off-by: Felix Brack 
> ---
>
> Changes in v3:
> - refactoring improving code readability
>
> Changes in v2:
> - add documentation
> - add a regulator to the sandbox for testing
> - extend the test for the new sandbox regulator
>
>  arch/sandbox/dts/sandbox_pmic.dtsi   |  6 ++
>  doc/device-tree-bindings/regulator/regulator.txt | 16 ++--
>  drivers/power/pmic/pmic-uclass.c | 11 +--
>  include/power/sandbox_pmic.h |  5 -
>  test/dm/regulator.c  |  2 ++
>  5 files changed, 35 insertions(+), 5 deletions(-)

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

Re: [U-Boot] [PATCH u-boot v2] ARM: arch-meson: build memory banks using reported memory from registers

[Simon Glass]

On 27 November 2017 at 02:35, Neil Armstrong  wrote:
> As discussed at [1], the Amlogic Meson GX SoCs can embed a BL31 firmware
> and a secondary BL32 firmware.
> Since mid-2017, the reserved memory address of the BL31 firmware was moved
> and grown for security reasons.
>
> But mainline U-Boot and Linux has the old address and size fixed.
>
> These SoCs have a register interface to get the two firmware reserved
> memory start and sizes.
>
> This patch adds a dynamic reservation of the memory zones in the device tree 
> bootmem
> reserved memory zone used by the kernel in early boot.
> To be complete, the memory zones are also added to the EFI reserved zones.
>
> Depends on patchset "Add support for Amlogic GXL Based SBCs" at [2].
>
> [1] 
> http://lists.infradead.org/pipermail/linux-amlogic/2017-October/004860.html
> [2] 
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005410.html
>
> Changes since v1:
> - switched the #if to if(IS_ENABLED()) to compile all code paths
> - renamed function to meson_board_add_reserved_memory()
> - added a mem.h header with comment
> - updated all boards ft_board_setup()
>
> Changes since RFC v2:
> - reduced preprocessor load
> - kept Odroid-C2 static memory mapping as exception
>
> Changes since RFC v1:
> - switch to fdt rsv mem table and efi reserve memory
> - replaced in_le32 by readl()
>
> Reviewed-by: Simon Glass 
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm/include/asm/arch-meson/gxbb.h| 17 +++
>  arch/arm/include/asm/arch-meson/mem.h | 16 +++
>  arch/arm/mach-meson/board.c   | 74 
> +++
>  board/amlogic/khadas-vim/khadas-vim.c |  7 +++
>  board/amlogic/libretech-cc/libretech-cc.c |  8 
>  board/amlogic/odroid-c2/odroid-c2.c   |  8 
>  board/amlogic/p212/p212.c |  8 
>  configs/khadas-vim_defconfig  |  1 +
>  configs/libretech-cc_defconfig|  1 +
>  configs/odroid-c2_defconfig   |  1 +
>  configs/p212_defconfig|  1 +
>  include/configs/meson-gxbb-common.h   |  2 +-
>  12 files changed, 135 insertions(+), 9 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-meson/mem.h

Seems good, so far as I understand it.

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

[U-Boot] [PATCHv2] env: enable accessing the environemnt in EXT4 partition

[Jorge Ramirez-Ortiz]

the following commit enables accessing the environment in an ext4
partition. In order to do that, some definitions need to be added to
include/configs/board_x.h file.

For example to store the environment in a file named "uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, you should define:

  EXT4_ENV_DEVICE_AND_PART"0:1"
  EXT4_ENV_INTERFACE  "mmc"
  EXT4_ENV_FILE   "/uboot.env"
---
 env/Kconfig | 7 +++
 env/env.c   | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/env/Kconfig b/env/Kconfig
index 2477bf8..09309ab 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -81,6 +81,13 @@ config ENV_IS_IN_FAT
  - CONFIG_FAT_WRITE:
  This must be enabled. Otherwise it cannot save the environment file.
 
+config ENV_IS_IN_EXT4
+   bool "Environment is in a EXT4 filesystem"
+   depends on !CHAIN_OF_TRUST
+   select EXT4_WRITE
+   help
+ Define this if you want to use the EXT4 file system for the 
environment.
+
 config ENV_IS_IN_FLASH
bool "Environment in flash memory"
depends on !CHAIN_OF_TRUST
diff --git a/env/env.c b/env/env.c
index 76a5608..7455632 100644
--- a/env/env.c
+++ b/env/env.c
@@ -32,6 +32,8 @@ static enum env_location env_get_default_location(void)
return ENVL_EEPROM;
else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
return ENVL_FAT;
+   else if IS_ENABLED(CONFIG_ENV_IS_IN_EXT4)
+   return ENVL_EXT4;
else if IS_ENABLED(CONFIG_ENV_IS_IN_FLASH)
return ENVL_FLASH;
else if IS_ENABLED(CONFIG_ENV_IS_IN_MMC)
-- 
2.7.4

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

Re: [U-Boot] [PATCHv3] env: enable accessing the environment in an EXT4 partition

[Jorge Ramirez]

On 11/27/2017 06:49 PM, Tom Rini wrote:

On Mon, Nov 27, 2017 at 06:45:35PM +0100, Jorge Ramirez-Ortiz wrote:

the following commit enables accessing the environment in an ext4
partition. In order to do that, some definitions need to be added to
include/configs/board_x.h file.

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, you should define:

   EXT4_ENV_DEVICE_AND_PART"0:1"
   EXT4_ENV_INTERFACE  "mmc"
   EXT4_ENV_FILE   "/uboot.env"

We have examples of these kind of configurations in Kconfig today,
please add them as well so the feature can be fully used, thanks!


oops, yeah, sorry about that. ok doing it now
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCHv3] env: enable accessing the environment in an EXT4 partition

[Tom Rini]

On Mon, Nov 27, 2017 at 07:06:02PM +0100, Jorge Ramirez wrote:
> On 11/27/2017 06:51 PM, Jorge Ramirez wrote:
> >On 11/27/2017 06:49 PM, Tom Rini wrote:
> >>On Mon, Nov 27, 2017 at 06:45:35PM +0100, Jorge Ramirez-Ortiz wrote:
> >>>the following commit enables accessing the environment in an ext4
> >>>partition. In order to do that, some definitions need to be added to
> >>>include/configs/board_x.h file.
> >>>
> >>>For example to store the environment in a file named "/uboot.env" in
> >>>MMC
> >>>"0", where partition "1" contains the EXT4 filesystem, you should
> >>>define:
> >>>
> >>>   EXT4_ENV_DEVICE_AND_PART"0:1"
> >>>   EXT4_ENV_INTERFACE  "mmc"
> >>>   EXT4_ENV_FILE   "/uboot.env"
> >>We have examples of these kind of configurations in Kconfig today,
> >>please add them as well so the feature can be fully used, thanks!
> >>
> >oops, yeah, sorry about that. ok doing it now
> 
> just checking but you realize that I will have to modify env/ext4.c to use
> these new CONFIG_ just like we do for FAT?
> for EXT4 we were using include/configs/.h instead as described in the commit
> (so the feature was fully functional, just slightly different to FAT when
> defining the variables).
> 
> ok?

Yes, we need to move them to CONFIG_xxx and have them in Kconfig.  And
we should rename them to CONFIG_ENV_EXT4_xxx while at it.  I think I had
to do this when migrating FAT env support and left EXT4 out as there
were no in-tree users at the time so it fell off my TODO list.  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 1/2] i2c: add Amlogic Meson driver

[Simon Glass]

Hi Benjamin,

On 26 November 2017 at 09:49, Beniamino Galvani  wrote:
> On Mon, Nov 20, 2017 at 08:36:34AM -0700, Simon Glass wrote:
>> Hi Benjamin,
>>
>> On 29 October 2017 at 03:09, Beniamino Galvani  wrote:
>> >
>> > Add a driver for the I2C controller available on Amlogic Meson SoCs.
>> >
>> > Signed-off-by: Beniamino Galvani 
>> > ---
>> >  arch/arm/include/asm/arch-meson/i2c.h |  11 ++
>> >  drivers/i2c/Kconfig   |   6 +
>> >  drivers/i2c/Makefile  |   1 +
>> >  drivers/i2c/meson_i2c.c   | 263 
>> > ++
>> >  4 files changed, 281 insertions(+)
>> >  create mode 100644 arch/arm/include/asm/arch-meson/i2c.h
>> >  create mode 100644 drivers/i2c/meson_i2c.c
>>
>> Reviewed-by: Simon Glass 
>>
>> But please look at the comments below.
>
> Hi Simon,
>
> I addressed your suggestions in a follow-up series, thanks.
>
>> > +U_BOOT_DRIVER(i2c_meson) = {
>> > +   .name = "i2c_meson",
>> > +   .id   = UCLASS_I2C,
>> > +   .of_match = meson_i2c_ids,
>> > +   .probe = meson_i2c_probe,
>> > +   .priv_auto_alloc_size = sizeof(struct meson_i2c),
>>
>> I think meson_i2c_priv might be a better name since it indicates that
>> it is driver-private data. But if you prefer the shorter name, that's
>> fine with me.
>
> I think I slightly prefer it, but both would be fine. Since the patch
> is already applied, let's keep it as is?

OK.

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

Re: [U-Boot] [PATCH] MAINTAINERS: update maintained files for Rockchip

[Simon Glass]

On 26 November 2017 at 16:18, Philipp Tomsich
 wrote:
> With some of the recent cleanups (e.g. moving the DRAM controller
> drivers for Rockchip devices to drivers/ram/rockchip), the files
> and paths listed in MAINTAINERS no longer covered what really is
> looked after as part of the Rockchip port.
>
> This commit updates the files/paths listed in MAINTAINERS for the
> Rockchip port.  I am certain, though, that this will have missed some
> additional paths that should have been included...
>
> Signed-off-by: Philipp Tomsich 
> ---
>
>  MAINTAINERS | 12 
>  1 file changed, 12 insertions(+)

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

Re: [U-Boot] [PATCH 1/2] libfdt: move fdt_find_regions() to fdt_region.c from fdt_wip.c

[Simon Glass]

On 27 November 2017 at 00:06, Masahiro Yamada
 wrote:
> All the other fdt_*_region() functions are located in fdt_region.c,
> while only fdt_find_regions() was added to fdt_wip.c, strangely.
>
> Move it to the suitable place.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  lib/libfdt/fdt_region.c | 129 
> 
>  lib/libfdt/fdt_wip.c| 129 
> 
>  2 files changed, 129 insertions(+), 129 deletions(-)

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

Re: [U-Boot] [PATCHv3] env: enable accessing the environment in an EXT4 partition

[Tom Rini]

On Mon, Nov 27, 2017 at 06:45:35PM +0100, Jorge Ramirez-Ortiz wrote:
> the following commit enables accessing the environment in an ext4
> partition. In order to do that, some definitions need to be added to
> include/configs/board_x.h file.
> 
> For example to store the environment in a file named "/uboot.env" in MMC
> "0", where partition "1" contains the EXT4 filesystem, you should define:
> 
>   EXT4_ENV_DEVICE_AND_PART"0:1"
>   EXT4_ENV_INTERFACE  "mmc"
>   EXT4_ENV_FILE   "/uboot.env"

We have examples of these kind of configurations in Kconfig today,
please add them as well so the feature can be fully used, 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] [PATCHv3] env: enable accessing the environment in an EXT4 partition

[Jorge Ramirez]

On 11/27/2017 06:51 PM, Jorge Ramirez wrote:

On 11/27/2017 06:49 PM, Tom Rini wrote:

On Mon, Nov 27, 2017 at 06:45:35PM +0100, Jorge Ramirez-Ortiz wrote:

the following commit enables accessing the environment in an ext4
partition. In order to do that, some definitions need to be added to
include/configs/board_x.h file.

For example to store the environment in a file named "/uboot.env" in 
MMC
"0", where partition "1" contains the EXT4 filesystem, you should 
define:


   EXT4_ENV_DEVICE_AND_PART"0:1"
   EXT4_ENV_INTERFACE  "mmc"
   EXT4_ENV_FILE   "/uboot.env"

We have examples of these kind of configurations in Kconfig today,
please add them as well so the feature can be fully used, thanks!


oops, yeah, sorry about that. ok doing it now


just checking but you realize that I will have to modify env/ext4.c to 
use these new CONFIG_ just like we do for FAT?
for EXT4 we were using include/configs/.h instead as described in the 
commit (so the feature was fully functional, just slightly different to 
FAT when defining the variables).


ok?




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

Re: [U-Boot] [PATCH v3 00/18] efi_loader: manage protocols in a linked list (v3)

[Simon Glass]

Hi,

On 26 November 2017 at 06:05, Heinrich Schuchardt  wrote:
> Up to now the protocols of an EFI handle where contained in an
> array of fixed size. With the patch series the protocols are
> managed in a linked list. This both saves memory and gives
> more flexibility.
>
> The LocateDevicePath boot service is implemented according
> to the UEFI specification.
>
> A unit test for the LocateDevicePath boot service and the
> device path to text protocol are added.
>
> Some bug fixes are provided.
>
> v3
> Remove patch
> efi_loader: efi_bootmgr: do not make hidden assignments
> (A patch to add device path printing in printf() is
> pending.)
> Resubmit
> efi_loader: helloworld.c: remove superfluous include
> v2
> Enhance the helloworld example to check if the image
> handle is passed corectly. Adjust the related py
> test.
>
> Use a helper function to initialize EFI objects.
>
> Further minor bug fixes.
>
> Heinrich Schuchardt (18):
>   efi_loader: helloworld.c: remove superfluous include
>   efi_loader: size of media device path node represenation
>   efi_loader: efi_dp_str should print path not node
>   efi_loader: fix efi_convert_device_node_to_text
>   efi_loader: reimplement LocateDevicePath
>   efi_selftest: test EFI_DEVICE_PATH_TO_TEXT_PROTOCOL
>   efi_loader: efi_disk: use efi_add_protocol
>   efi_loader: efi_net: use efi_add_protocol
>   efi_loader: efi_gop: use efi_add_protocol
>   efi_loader: simplify efi_open_protocol
>   efi_loader: simplify find_obj
>   efi_loader: manage protocols in a linked list
>   efi_selftest: compile without special compiler flags
>   efi_selftest: add missing line feed
>   efi_loader: output load options in helloworld
>   test/py: check return code of helloworld
>   efi_loader: pass handle of loaded image
>   efi_loader: helper function to add EFI object to list
>

This series seems to have been hanging around for a while. Is it going
to be applied soon?

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

Re: [U-Boot] [PATCH 1/2] rockchip: rk3399-puma: add code to allow forcing a power-on reset

[Dr. Philipp Tomsich]

> On 27 Nov 2017, at 18:10, Simon Glass  wrote:
> 
> Hi Philipp,
> 
> On 26 November 2017 at 16:22, Philipp Tomsich
>  wrote:
>> The reset circuitry in the RK3399 only resets 'almost all logic' when
>> a software reset is performed.  To make our software maintenance
>> easier in the future, we want to have the option (controlled by a DTS
>> property) to force all reset causes other than a power-on reset to
>> trigger a power-on reset via a GPIO trigger.
>> 
>> This adds the necessary support to the rk3399-puma (i.e. RK3399-Q7)
>> board-support and the documentation for the new property
>> (sysreset-gpio) within the /config-node.
>> 
>> Signed-off-by: Philipp Tomsich 
>> Tested-by: Klaus Goger 
>> ---
>> 
>> board/theobroma-systems/puma_rk3399/puma-rk3399.c | 46 
>> +++
>> doc/device-tree-bindings/config.txt   |  6 +++
>> 2 files changed, 52 insertions(+)
> 
> Reviewed-by: Simon Glass 
> 
>> 
>> diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c 
>> b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
>> index 2b4988e..79dbdf4 100644
>> --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
>> +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
>> @@ -9,7 +9,10 @@
>> #include 
>> #include 
>> #include 
>> +#include 
>> #include 
>> +#include 
>> +#include 
>> #include 
>> #include 
>> #include 
>> @@ -32,9 +35,52 @@ int board_init(void)
>>return 0;
>> }
>> 
>> +static void rk3399_force_power_on_reset(void)
>> +{
>> +   ofnode node;
>> +   struct gpio_desc sysreset_gpio;
>> +
>> +   debug("%s: trying to force a power-on reset\n", __func__);
>> +
>> +   node = ofnode_path("/config");
>> +   if (!ofnode_valid(node)) {
>> +   debug("%s: no /config node?\n", __func__);
>> +   return;
>> +   }
>> +
>> +   gpio_request_by_name_nodev(node, "sysreset-gpio", 0,
>> +  _gpio, GPIOD_IS_OUT);
>> +
>> +   if (!dm_gpio_is_valid(_gpio)) {
> 
> If you don't support this GPIO being option, you should check the
> return value of gpio_request_by_name_nodev() instead. If it is < 0
> then it did not find a GPIO.

We want to treat this as an option, if either the software stack is known
to handle partial resets correctly or if the software stack already always
generates a cold-reset of the entire platform.

> 
>> +   debug("%s: could not find a /config/sysreset-gpio\n", 
>> __func__);
>> +   return;
>> +   }
>> +
>> +   dm_gpio_set_value(_gpio, 1);
>> +}
>> +
>> void spl_board_init(void)
>> {
>>int  ret;
>> +   struct rk3399_cru *cru = rockchip_get_cru();
>> +
>> +   /*
>> +* The RK3399 resets only 'almost all logic' (see also in the TRM
>> +* "3.9.4 Global software reset"), when issuing a software reset.
>> +* This may cause issues during boot-up for some configurations of
>> +* the application software stack.
>> +*
>> +* To work around this, we test whether the last reset reason was
>> +* a power-on reset and (if not) issue an overtemp-reset to reset
>> +* the entire module.
>> +*
>> +* While this was previously fixed by modifying the various places
>> +* that could generate a software reset (e.g. U-Boot's sysreset
>> +* driver, the ATF or Linux), we now have it here to ensure that
>> +* we no longer have to track this through the various components.
>> +*/
>> +   if (cru->glb_rst_st != 0)
>> +   rk3399_force_power_on_reset();
>> 
>>/*
>> * Turning the eMMC and SPI back on (if disabled via the Qseven
>> diff --git a/doc/device-tree-bindings/config.txt 
>> b/doc/device-tree-bindings/config.txt
>> index 15e4349..6cdc16d 100644
>> --- a/doc/device-tree-bindings/config.txt
>> +++ b/doc/device-tree-bindings/config.txt
>> @@ -46,3 +46,9 @@ u-boot,spl-payload-offset
>>If present (and SPL is controlled by the device-tree), this allows
>>to override the CONFIG_SYS_SPI_U_BOOT_OFFS setting using a value
>>from the device-tree.
>> +
>> +sysreset-gpio
>> +   If present (and supported by the specific board), indicates a
>> +   GPIO that can be set to trigger a system reset.  It is assumed
>> +   that such a system reset will effect a complete platform reset,
>> +   being roughly equivalent to a power-on reset.
> 
> Is there no kernel binding for this sort of thing?

Not to my knowledge (and grep didn’t find anything either).

Note that the kernel (for ARM64) requests the reset via PSCI (from
the ATF) and the ATF then needs to do “the right thing”.  Many other
platforms have relied on their watchdog timers to effect a reset in the
past.  So in other words: most of the kernel doesn’t really care about
a setting like this.

> 

Re: [U-Boot] [PATCH 2/2] libfdt: migrate fdt_wip.c to a wrapper of scripts/dtc/libfdt/fdt_wip.c

[Simon Glass]

On 27 November 2017 at 00:06, Masahiro Yamada
 wrote:
> Now, lib/libfdt/fdt_wip.c is the same as scripts/dtc/libfdt/fdt_wip.c
>
> Change the former to a wrapper of the latter.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  lib/libfdt/Makefile|   4 +-
>  lib/libfdt/fdt_wip.c   | 100 
> +
>  tools/Makefile |   4 +-
>  tools/libfdt/fdt_wip.c |   2 +
>  4 files changed, 8 insertions(+), 102 deletions(-)
>  create mode 100644 tools/libfdt/fdt_wip.c

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

Re: [U-Boot] [PATCH] env: enable CONFIG_ENV_IS_IN_EXT4

[Tom Rini]

On Mon, Nov 27, 2017 at 05:26:19PM +0100, Jorge Ramirez-Ortiz wrote:

Please add a line or two here, thanks.

> ---
>  env/Kconfig | 10 ++
>  env/env.c   |  2 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/env/Kconfig b/env/Kconfig
> index 2477bf8..4387a2c 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -81,6 +81,16 @@ config ENV_IS_IN_FAT
> - CONFIG_FAT_WRITE:
> This must be enabled. Otherwise it cannot save the environment file.
>  
> +config ENV_IS_IN_EXT4
> + bool "Environment is in a EXT4 filesystem"
> + depends on !CHAIN_OF_TRUST
> + select EXT4_WRITE
> + help
> +   Define this if you want to use the EXT4 file system for the 
> environment.
> +
> +   - CONFIG_EXT4_WRITE:
> +   This must be enabled. Otherwise it cannot save the environment file.

We can remove this bit about needing CONFIG_EXT4_WRITE as we're
expressing this dependency via select above now.  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 1/2] rockchip: rk3399-puma: add code to allow forcing a power-on reset

[Simon Glass]

Hi Philipp,

On 26 November 2017 at 16:22, Philipp Tomsich
 wrote:
> The reset circuitry in the RK3399 only resets 'almost all logic' when
> a software reset is performed.  To make our software maintenance
> easier in the future, we want to have the option (controlled by a DTS
> property) to force all reset causes other than a power-on reset to
> trigger a power-on reset via a GPIO trigger.
>
> This adds the necessary support to the rk3399-puma (i.e. RK3399-Q7)
> board-support and the documentation for the new property
> (sysreset-gpio) within the /config-node.
>
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 
> ---
>
>  board/theobroma-systems/puma_rk3399/puma-rk3399.c | 46 
> +++
>  doc/device-tree-bindings/config.txt   |  6 +++
>  2 files changed, 52 insertions(+)

Reviewed-by: Simon Glass 

>
> diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c 
> b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> index 2b4988e..79dbdf4 100644
> --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> @@ -9,7 +9,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -32,9 +35,52 @@ int board_init(void)
> return 0;
>  }
>
> +static void rk3399_force_power_on_reset(void)
> +{
> +   ofnode node;
> +   struct gpio_desc sysreset_gpio;
> +
> +   debug("%s: trying to force a power-on reset\n", __func__);
> +
> +   node = ofnode_path("/config");
> +   if (!ofnode_valid(node)) {
> +   debug("%s: no /config node?\n", __func__);
> +   return;
> +   }
> +
> +   gpio_request_by_name_nodev(node, "sysreset-gpio", 0,
> +  _gpio, GPIOD_IS_OUT);
> +
> +   if (!dm_gpio_is_valid(_gpio)) {

If you don't support this GPIO being option, you should check the
return value of gpio_request_by_name_nodev() instead. If it is < 0
then it did not find a GPIO.

> +   debug("%s: could not find a /config/sysreset-gpio\n", 
> __func__);
> +   return;
> +   }
> +
> +   dm_gpio_set_value(_gpio, 1);
> +}
> +
>  void spl_board_init(void)
>  {
> int  ret;
> +   struct rk3399_cru *cru = rockchip_get_cru();
> +
> +   /*
> +* The RK3399 resets only 'almost all logic' (see also in the TRM
> +* "3.9.4 Global software reset"), when issuing a software reset.
> +* This may cause issues during boot-up for some configurations of
> +* the application software stack.
> +*
> +* To work around this, we test whether the last reset reason was
> +* a power-on reset and (if not) issue an overtemp-reset to reset
> +* the entire module.
> +*
> +* While this was previously fixed by modifying the various places
> +* that could generate a software reset (e.g. U-Boot's sysreset
> +* driver, the ATF or Linux), we now have it here to ensure that
> +* we no longer have to track this through the various components.
> +*/
> +   if (cru->glb_rst_st != 0)
> +   rk3399_force_power_on_reset();
>
> /*
>  * Turning the eMMC and SPI back on (if disabled via the Qseven
> diff --git a/doc/device-tree-bindings/config.txt 
> b/doc/device-tree-bindings/config.txt
> index 15e4349..6cdc16d 100644
> --- a/doc/device-tree-bindings/config.txt
> +++ b/doc/device-tree-bindings/config.txt
> @@ -46,3 +46,9 @@ u-boot,spl-payload-offset
> If present (and SPL is controlled by the device-tree), this allows
> to override the CONFIG_SYS_SPI_U_BOOT_OFFS setting using a value
> from the device-tree.
> +
> +sysreset-gpio
> +   If present (and supported by the specific board), indicates a
> +   GPIO that can be set to trigger a system reset.  It is assumed
> +   that such a system reset will effect a complete platform reset,
> +   being roughly equivalent to a power-on reset.

Is there no kernel binding for this sort of thing?

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

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

[Simon Glass]

On 26 November 2017 at 19:33, Andes  wrote:
> From: Rick Chen 
>
> ATCPIT100 is Andestech timer IP which is embeded
> in AE3XX and AE250 boards. So rename AE3XX to
> ATCPIT100 will be more make sence.
>
> Signed-off-by: Rick Chen 
> ---
> Changelog v2
>  - Patch 1/3: Changed.
>  - Patch 2/3: Changed.
>  - Patch 3/3: No change.
>
> Patch 1/3
>  1. Only rename ae3xx as atcpit100.
>  2. Squashed Kconfig rename ae3xx into this patch
> to keep things in a consistent state.
>
> Patch 2/3
>  1. Modify function name from ae3xx to atcpit100.
> ---
>  configs/adp-ae3xx_defconfig| 2 +-
>  drivers/timer/Kconfig  | 7 ---
>  drivers/timer/Makefile | 2 +-
>  drivers/timer/{ae3xx_timer.c => atcpit100_timer.c} | 0
>  4 files changed, 6 insertions(+), 5 deletions(-)
>  rename drivers/timer/{ae3xx_timer.c => atcpit100_timer.c} (100%)
>

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

Re: [U-Boot] [PATCH 4/4] i2c: meson: add some comments

[Simon Glass]

On 26 November 2017 at 09:40, Beniamino Galvani  wrote:
> Add some comment describing the purpose of struct members and
> functions.
>
> Signed-off-by: Beniamino Galvani 
> ---
>  drivers/i2c/meson_i2c.c | 25 +++--
>  1 file changed, 19 insertions(+), 6 deletions(-)

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

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

[Simon Glass]

Hi Neil,

On 27 November 2017 at 01:48, Neil Armstrong  wrote:
> On 26/11/2017 12:39, Simon Glass wrote:
>> Hi Neil,
>>
>> On 25 November 2017 at 02:45, Neil Armstrong  wrote:
>>> Hi Simon,
>>>
>>> Le 24/11/2017 23:35, Simon Glass a écrit :
 Hi Neil,

 On 22 November 2017 at 06:25, Neil Armstrong  
 wrote:
> Introduce a generic common Ethernet Hardware init function
> common to all Amlogic GX SoCs with support for the
> Internal PHY enable for GXL SoCs.
>
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm/include/asm/arch-meson/eth.h | 15 ++
>  arch/arm/mach-meson/Makefile  |  2 +-
>  arch/arm/mach-meson/eth.c | 53 
> +++
>  3 files changed, 69 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/arch-meson/eth.h
>  create mode 100644 arch/arm/mach-meson/eth.c
>
> diff --git a/arch/arm/include/asm/arch-meson/eth.h 
> b/arch/arm/include/asm/arch-meson/eth.h
> new file mode 100644
> index 000..8ea8e10
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-meson/eth.h
> @@ -0,0 +1,15 @@
> +/*
> + * Copyright (C) 2016 BayLibre, SAS
> + * Author: Neil Armstrong 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef __MESON_ETH_H__
> +#define __MESON_ETH_H__
> +
> +#include 
> +
> +void meson_gx_eth_init(phy_interface_t mode, bool use_internal_phy);
> +
> +#endif /* __MESON_ETH_H__ */
> diff --git a/arch/arm/mach-meson/Makefile b/arch/arm/mach-meson/Makefile
> index bf49b8b..b4e8dde 100644
> --- a/arch/arm/mach-meson/Makefile
> +++ b/arch/arm/mach-meson/Makefile
> @@ -4,4 +4,4 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  #
>
> -obj-y += board.o sm.o
> +obj-y += board.o sm.o eth.o
> diff --git a/arch/arm/mach-meson/eth.c b/arch/arm/mach-meson/eth.c
> new file mode 100644
> index 000..46ecb5e
> --- /dev/null
> +++ b/arch/arm/mach-meson/eth.c
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright (C) 2016 BayLibre, SAS
> + * Author: Neil Armstrong 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +void meson_gx_eth_init(phy_interface_t mode, bool use_internal_phy)

 Can you add a header file addition for this somewhere, with comments?
>>>
>>> Do you mean comments in the added arch/arm/include/asm/arch-meson/eth.h in 
>>> this
>>> same patchset ?
>>
>> Yes that's what I meant.
>>
>>>

> +{
> +   switch (mode) {
> +   case PHY_INTERFACE_MODE_RGMII:
> +   case PHY_INTERFACE_MODE_RGMII_ID:
> +   case PHY_INTERFACE_MODE_RGMII_RXID:
> +   case PHY_INTERFACE_MODE_RGMII_TXID:
> +   /* Set RGMII mode */
> +   setbits_le32(GXBB_ETH_REG_0, GXBB_ETH_REG_0_PHY_INTF |
> +GXBB_ETH_REG_0_TX_PHASE(1) |
> +GXBB_ETH_REG_0_TX_RATIO(4) |
> +GXBB_ETH_REG_0_PHY_CLK_EN |
> +GXBB_ETH_REG_0_CLK_EN);
> +   break;
> +
> +   case PHY_INTERFACE_MODE_RMII:
> +   /* Set RMII mode */
> +   out_le32(GXBB_ETH_REG_0, GXBB_ETH_REG_0_INVERT_RMII_CLK |
> +GXBB_ETH_REG_0_CLK_EN);

 How come this is using out_le32() instead of (for example) writel()?
>>>
>>> It should be writel(), but since the register size is 32bit, it can be 
>>> out_le32
>>
>> So why do we have out_le32()? What is the difference?

Still unsure about this one.

>>
>>>

> +
> +#ifdef CONFIG_MESON_GXL

 This doesn't seem fully generic if it has this #ifdef in it. Can this
 be a parameter? At worst can we use if() instead of #ifdef ?
>>>
>>> Yeah, I didn't really figured out how to specify the internal PHY.
>>>
>>> GXL and GXM SoCs have an internal PHY, but yeah GXBB does't.
>>> I hesitated to add a different meson_gx_eth_init() signature
>>> for these different SoCs, what do you think about that ?
>>>
>>> The new AXG SoC does not have internal PHY, so it will use the same
>>> code as GXBB.
>>
>> I think this function needs to be told which SoC type it is dealing
>> with, as a separate enum parameters.
>
> It's more complex since the S905D from the same GXL family can also use an
> external RGMII interface *and* the internal PHY depending on the board.
>
> Could a generic flags parameter be better, and add a GXL specific
> MESON_GXL_USE_INTERNAL_RMII_PHY to be passed only on GXL platforms ?

Yes that sounds good and will get rid of the 

Re: [U-Boot] [PATCH 4/5] test/py: Allow any unit test suite to be found

[Stephen Warren]

On 11/25/2017 11:57 AM, Simon Glass wrote:

The u-boot.sym file is scanned to find unit test suites for execution. At
present it only finds those whose names start with 'dm' or 'env'. This
code is buried in the bowels of the test code so when adding a new suite
it is not easy to discover why it is ignored by the test framework.

There seems to be no need to make this restriction. Drop it.


Acked-by: Stephen Warren 


diff --git a/test/py/conftest.py b/test/py/conftest.py



-re_ut_test_list = 
re.compile(r'_u_boot_list_2_(dm|env)_test_2_\1_test_(.*)\s*$')
+re_ut_test_list = re.compile(r'_u_boot_list_2_(.*)_test_2_\1_test_(.*)\s*$')


I think I made this regex restrictive to avoid accidentally matching 
lists (symbols) with "test" in the name that weren't known unit tests. 
Or maybe there were some unit tests that didn't work yet when I wrote 
it? If we're confident that won't happen, this change seems fine. If we 
do have a problem in the future, I guess we could just rename the symbol 
to s/test/unit_test/ or something to make matching more explicit.

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

Re: [U-Boot] [U-Boot, v2, 5/7] rockchip: rk3128: add evb-rk3128 support

[Philipp Tomsich]

> evb-rk3128 is an evb from Rockchip based on rk3128 SoC:
> - 2 USB2.0 Host port;
> - 1 HDMI port;
> - 2 10/100M eth port;
> - 2GB ddr;
> - 16GB eMMC;
> - UART to USB debug port;
> 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v2:
> - enable usb nodes
> 
>  arch/arm/mach-rockchip/rk3128/Kconfig  | 24 
>  board/rockchip/evb_rk3128/Kconfig  | 15 +++
>  board/rockchip/evb_rk3128/MAINTAINERS  |  6 ++
>  board/rockchip/evb_rk3128/Makefile |  7 +++
>  board/rockchip/evb_rk3128/evb-rk3128.c |  9 +
>  include/configs/evb_rk3128.h   | 15 +++
>  6 files changed, 76 insertions(+)
>  create mode 100644 board/rockchip/evb_rk3128/Kconfig
>  create mode 100644 board/rockchip/evb_rk3128/MAINTAINERS
>  create mode 100644 board/rockchip/evb_rk3128/Makefile
>  create mode 100644 board/rockchip/evb_rk3128/evb-rk3128.c
>  create mode 100644 include/configs/evb_rk3128.h
> 

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

Re: [U-Boot] [PATCHv4] env: enable accessing the environment in an EXT4 partition

[Tom Rini]

On Mon, Nov 27, 2017 at 08:19:20PM +0100, Jorge Ramirez-Ortiz wrote:

> For example to store the environment in a file named "/uboot.env" in MMC
> "0", where partition "1" contains the EXT4 filesystem, the following
> configs should be added to the board's default config:
> 
>   CONFIG_ENV_IS_IN_EXT4=y
>   CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
>   CONFIG_ENV_EXT4_FILE="/uboot.env"
>   CONFIG_ENV_EXT4_INTERFACE="mmc"

Reviewed-by: Tom Rini 

-- 
Tom


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

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

[Philipp Tomsich]

> Add rk3128 pinctrl driver and grf/iomux structure definition.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v2:
> - remove debug info
> - update GPIO2C4/C5 SHIFT
> 
>  arch/arm/include/asm/arch-rockchip/grf_rk3128.h | 551 
> 
>  drivers/pinctrl/Kconfig |  10 +
>  drivers/pinctrl/rockchip/Makefile   |   4 +-
>  drivers/pinctrl/rockchip/pinctrl_rk3128.c   | 187 
>  4 files changed, 750 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3128.h
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3128.c
> 

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

Re: [U-Boot] [U-Boot, v2, 2/7] rockchip: rk3128: add soc basic support

[Philipp Tomsich]

> RK3128 is a SoC from Rockchip with quad-core Cortex-A7 CPU
> and mali400 GPU. Support Nand flash, eMMC, SD card, USB 2.0 host
> and device, HDMI/LVDS/MIPI display.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v2:
> - update setup_boot_mode() with master
> - enable board_late_init()
> 
>  arch/arm/mach-rockchip/Kconfig|  10 ++
>  arch/arm/mach-rockchip/Makefile   |   2 +
>  arch/arm/mach-rockchip/rk3128-board.c | 127 
> ++
>  arch/arm/mach-rockchip/rk3128/Kconfig |   0
>  arch/arm/mach-rockchip/rk3128/Makefile|   8 ++
>  arch/arm/mach-rockchip/rk3128/rk3128.c|  12 +++
>  arch/arm/mach-rockchip/rk3128/syscon_rk3128.c |  21 +
>  include/configs/rk3128_common.h   |  70 ++
>  8 files changed, 250 insertions(+)
>  create mode 100644 arch/arm/mach-rockchip/rk3128-board.c
>  create mode 100644 arch/arm/mach-rockchip/rk3128/Kconfig
>  create mode 100644 arch/arm/mach-rockchip/rk3128/Makefile
>  create mode 100644 arch/arm/mach-rockchip/rk3128/rk3128.c
>  create mode 100644 arch/arm/mach-rockchip/rk3128/syscon_rk3128.c
>  create mode 100644 include/configs/rk3128_common.h
> 

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, v2, 6/7] rockchip: rk3128: add defconfig for evb-rk3128

[Philipp Tomsich]

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

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

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

[Tom Rini]

On Sun, Nov 26, 2017 at 11:16:45PM +0900, Masahiro Yamada wrote:
[snip]
> This discussion should have happened.
> U-Boot boot sequence is crazily inefficient.
> 
> 
> 
> When we talk about "relocation", two things are happening.
> 
>  [1] U-Boot proper copies itself to the very end of DRAM
>  [2] Fix-up the global symbols
> 
> In my opinion, only [2] is useful.
> 
> 
> SPL initializes the DRAM, so it knows the base and size of DRAM.
> SPL should be able to load the U-Boot proper to the final destination.
> So, [1] is unnecessary.

Knowing this final destination isn't necessarily easy in all cases.  One
thing to keep in mind here is that long long ago, U-Boot did not do this
relocation step.  But that was also well before SPL, so some level of
what was made easier with relocation isn't so necessary now.

It's also somewhat of an important safety feature.  We have a lot of
values that get re-used (and sometimes re-based) without sufficient
care.  Take for example where for the longest time nearly everyone on
ARM32 was loading the kernel to.  Having U-Boot automatically end up way
out of the way rather than hoping everyone calculates a good address
that won't get stepped on is important.  It's also one of those things
that will change over time as features get added / changed and our
footprint grows.  We're already fairly often talking about "oops, what
do we do now to keep X into size constraint of $Y storage?".  It'll be
even worse to deal with "oops, adding $X means we need more run-time
space".

All of that said, I'd be happy to see logs showing that we in fact spend
a measurable amount of time in relocation and what we can do about it.

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 proper(not SPL) relocate option

[Tom Rini]

On Mon, Nov 27, 2017 at 10:13:09AM -0700, Simon Glass wrote:
> (Tom - any thoughts about a more expansive cc list on this?)

Not really, sorry.

> Hi Masahiro,
> 
> On 26 November 2017 at 07:16, Masahiro Yamada
>  wrote:
> > 2017-11-26 20:38 GMT+09:00 Simon Glass :
> >> Hi Philipp,
> >>
> >> On 25 November 2017 at 16:31, Dr. Philipp Tomsich
> >>  wrote:
> >>> Hi,
> >>>
>  On 25 Nov 2017, at 23:34, Simon Glass  wrote:
> 
>  +Tom, Masahiro, Philipp
> 
>  Hi,
> 
>  On 22 November 2017 at 03:27, Wolfgang Denk  wrote:
> > Dear Kever Yang,
> >
> > In message  you 
> > wrote:
> >>
> >> I can understand this feature, we always do dram_init_banks() first,
> >> then we relocate to 'known' area, then will be no risk to access 
> >> memory.
> >> I believe there must be some historical reason for some kind of device,
> >> the relocate feature is a wonderful idea for it.
> >
> > This is actuallyu not so much a feature needed to support some
> > specific device (in this case much simpler approahces would be
> > possible), but to support a whole set of features.  Unfortunately
> > these appear to get forgotten / ignored over time.
> >
> >> many other SoCs should be similar.
> >> - Without relocate we can save many step, some of our customer really
> >> care much about the boot time duration.
> >> * no need to relocate everything
> >> * no need to copy all the code
> >> * no need init the driver more than once
> >
> > Please have a look at the README, section "Memory Management".
> > The reloaction is not done to any _fixed_ address, but the address
> > is actually computed at runtime, depending on a number features
> > enabled (at least this is how it used to be - appearently little of
> > this is tested on a regular base, so I would not be surprised if
> > things are broken today).
> >
> > The basic idea was to reserve areas of memory at the top of RAM,
> > that would not be initialized / modified by U-Boot and Linux, not
> > even across a reset / warm boot.
> >
> > This was used for exaple for:
> >
> > - pRAM (Protected RAM) which could be used to store all kind of data
> >  (for example, using a pramfs [Protected and Persistent RAM
> >  Filesystem]) that could be kept across reboots of the OS.
> >
> > - shared frame buffer / video memory. U-Boot and Linux would be able
> >  to initialize the video memory just once (in U-Boot) and then
> >  share it, maybe even across reboots.  especially, this would allow
> >  for a very early splash screen that gets passed (flicker free) to
> >  Linux until some Linux GUI takes over (much more difficult today).
> >
> > - shared log buffer: U-Boot and Linux used to use the same syslog
> >  buffer mechanism, so you could share it between U-Boot and Linux.
> >  this allows for example to
> >  * read the Linux kernel panic messages after reset in U-Boot; this
> >is very useful when you bring up a new system and Linux crashes
> >before it can display the log buffer on the console
> >  * pass U-Boot POST results on to Linux, so the application code
> >can read and process these
> >  * process the system log of the previous run (especially after a
> >panic) in Lunux after it rebootet.
> >
> > etc.
> >
> > There are a number of such features which require to reserve room at
> > the top of RAM, the size of which is calculatedat runtime, often
> > depending on user settable environment data.
> >
> > All this cannot be done without relocation to a (dynmaically
> > computed) target address.
> >
> >
> > Yes, the code could be simpler and faster without that - but then,
> > you cut off a number of features.
> 
>  I would be interested in seeing benchmarks showing the cost of
>  relocation in terms of boot time. Last time I did this was on Exynos 5
>  and it was some years ago. The time was pretty small provided the
>  cache was on for the memory copies associated with relocation itself.
>  Something like 10-20ms but I don't have the numbers handy.
> 
>  I think it is useful to be able to allocate memory in board_init_f()
>  for use by U-Boot for things like the display and the malloc() region.
> 
>  Options we might consider:
> 
>  1. Don't relocate the code and data. Thus we could avoid the copy and
>  relocation cost. This is already supported with the GD_FLG_SKIP_RELOC
>  used when U-Boot runs as an EFI app
> 
>  2. Rather than throwing away the old malloc() region, keep it around
>  so existing allocated blocks work. 

Re: [U-Boot] MAINTAINERS: update maintained files for Rockchip

[Philipp Tomsich]

> With some of the recent cleanups (e.g. moving the DRAM controller
> drivers for Rockchip devices to drivers/ram/rockchip), the files
> and paths listed in MAINTAINERS no longer covered what really is
> looked after as part of the Rockchip port.
> 
> This commit updates the files/paths listed in MAINTAINERS for the
> Rockchip port.  I am certain, though, that this will have missed some
> additional paths that should have been included...
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
>  MAINTAINERS | 12 
>  1 file changed, 12 insertions(+)
> 

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

Re: [U-Boot] rockchip: board: evb_rv1108: update README

[Philipp Tomsich]

> After commit d962e5dadc2c("rockchip: mkimage: use spl_boot0 for all Rockchip 
> SoCs"),
> the mkimage will not pad the Tag memroy, so we shoud
> pass a Taged ddr.bin/spl.bin to it.
> 
> Signed-off-by: Andy Yan 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  board/rockchip/evb_rv1108/README | 5 ++---
>  1 file changed, 2 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, v2, 1/7] rockchip: rk3128: add device tree file

[Philipp Tomsich]

> Add dts binding header for rk3128, files origin from kernel.
> 
> Series-Changes: 2
> - fix i2c address
> - add saradc and usb phy node
> - emmc using fifo mode for there is no dma support in rk3128 emmc
> - add some clock id in cru.h
> 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/dts/Makefile  |   1 +
>  arch/arm/dts/rk3128-evb.dts|  95 
>  arch/arm/dts/rk3128.dtsi   | 804 
> +
>  include/dt-bindings/clock/rk3128-cru.h | 190 
>  4 files changed, 1090 insertions(+)
>  create mode 100644 arch/arm/dts/rk3128-evb.dts
>  create mode 100644 arch/arm/dts/rk3128.dtsi
>  create mode 100644 include/dt-bindings/clock/rk3128-cru.h
> 

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, v2, 2/7] rockchip: rk3128: add soc basic support

[Philipp Tomsich]

> RK3128 is a SoC from Rockchip with quad-core Cortex-A7 CPU
> and mali400 GPU. Support Nand flash, eMMC, SD card, USB 2.0 host
> and device, HDMI/LVDS/MIPI display.
> 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v2:
> - update setup_boot_mode() with master
> - enable board_late_init()
> 
>  arch/arm/mach-rockchip/Kconfig|  10 ++
>  arch/arm/mach-rockchip/Makefile   |   2 +
>  arch/arm/mach-rockchip/rk3128-board.c | 127 
> ++
>  arch/arm/mach-rockchip/rk3128/Kconfig |   0
>  arch/arm/mach-rockchip/rk3128/Makefile|   8 ++
>  arch/arm/mach-rockchip/rk3128/rk3128.c|  12 +++
>  arch/arm/mach-rockchip/rk3128/syscon_rk3128.c |  21 +
>  include/configs/rk3128_common.h   |  70 ++
>  8 files changed, 250 insertions(+)
>  create mode 100644 arch/arm/mach-rockchip/rk3128-board.c
>  create mode 100644 arch/arm/mach-rockchip/rk3128/Kconfig
>  create mode 100644 arch/arm/mach-rockchip/rk3128/Makefile
>  create mode 100644 arch/arm/mach-rockchip/rk3128/rk3128.c
>  create mode 100644 arch/arm/mach-rockchip/rk3128/syscon_rk3128.c
>  create mode 100644 include/configs/rk3128_common.h
> 

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, v2, 6/7] rockchip: rk3128: add defconfig for evb-rk3128

[Philipp Tomsich]

> Enable board config for evb-rk3128.
> Serial output and eMMC works in this version.
> 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  configs/evb-rk3128_defconfig | 56 
> 
>  1 file changed, 56 insertions(+)
>  create mode 100644 configs/evb-rk3128_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,v2,7/7] rockchip: rk3128: add sdram driver

[Philipp Tomsich]

> RK3128 support up to 2GB DDR3 sdram, one channel, 32bit data width.
> 
> This patch is only used for U-Boot, but not for SPL which will
> comes later, maybe after we merge all the common code into a common
> file.
> 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  drivers/ram/rockchip/Makefile   |  1 +
>  drivers/ram/rockchip/sdram_rk3128.c | 59 
> +
>  2 files changed, 60 insertions(+)
>  create mode 100644 drivers/ram/rockchip/sdram_rk3128.c
> 

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, v2, 5/7] rockchip: rk3128: add evb-rk3128 support

[Philipp Tomsich]

On Mon, 27 Nov 2017, Kever Yang wrote:


evb-rk3128 is an evb from Rockchip based on rk3128 SoC:
- 2 USB2.0 Host port;
- 1 HDMI port;
- 2 10/100M eth port;
- 2GB ddr;
- 16GB eMMC;
- UART to USB debug port;

Signed-off-by: Kever Yang 
Acked-by: Philipp Tomsich 


Reviewed-by: Philipp Tomsich 

See below for requested changes.


---

Changes in v2:
- enable usb nodes

arch/arm/mach-rockchip/rk3128/Kconfig  | 24 
board/rockchip/evb_rk3128/Kconfig  | 15 +++
board/rockchip/evb_rk3128/MAINTAINERS  |  6 ++
board/rockchip/evb_rk3128/Makefile |  7 +++
board/rockchip/evb_rk3128/evb-rk3128.c |  9 +
include/configs/evb_rk3128.h   | 15 +++
6 files changed, 76 insertions(+)
create mode 100644 board/rockchip/evb_rk3128/Kconfig
create mode 100644 board/rockchip/evb_rk3128/MAINTAINERS
create mode 100644 board/rockchip/evb_rk3128/Makefile
create mode 100644 board/rockchip/evb_rk3128/evb-rk3128.c
create mode 100644 include/configs/evb_rk3128.h

diff --git a/arch/arm/mach-rockchip/rk3128/Kconfig 
b/arch/arm/mach-rockchip/rk3128/Kconfig
index e69de29..40655a2 100644
--- a/arch/arm/mach-rockchip/rk3128/Kconfig
+++ b/arch/arm/mach-rockchip/rk3128/Kconfig
@@ -0,0 +1,24 @@
+if ROCKCHIP_RK3128
+
+choice
+   prompt "RK3128 board select"
+
+config TARGET_EVB_RK3128
+   bool "RK3128 evaluation board"
+   select BOARD_LATE_INIT
+   help
+ RK3128evb is a evaluation board for Rockchip rk3128,
+ with full function and phisical connectors support like
+ usb2.0 host ports, LVDS, JTAG, MAC, SDcard, HDMI, USB-2-serial...
+
+endchoice
+
+config SYS_SOC
+   default "rockchip"
+
+config SYS_MALLOC_F_LEN
+   default 0x0800
+
+source "board/rockchip/evb_rk3128/Kconfig"
+
+endif
diff --git a/board/rockchip/evb_rk3128/Kconfig 
b/board/rockchip/evb_rk3128/Kconfig
new file mode 100644
index 000..5b3095a
--- /dev/null
+++ b/board/rockchip/evb_rk3128/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_EVB_RK3128
+
+config SYS_BOARD
+   default "evb_rk3128"
+
+config SYS_VENDOR
+   default "rockchip"
+
+config SYS_CONFIG_NAME
+   default "evb_rk3128"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+   def_bool y
+
+endif
diff --git a/board/rockchip/evb_rk3128/MAINTAINERS 
b/board/rockchip/evb_rk3128/MAINTAINERS
new file mode 100644
index 000..f5145d1
--- /dev/null
+++ b/board/rockchip/evb_rk3128/MAINTAINERS
@@ -0,0 +1,6 @@
+EVB-RK3128
+M:  Kever Yang 
+S:  Maintained
+F:  board/rockchip/evb_rk3128
+F:  include/configs/evb_rk3128.h
+F:  configs/evb-rk3128_defconfig
diff --git a/board/rockchip/evb_rk3128/Makefile 
b/board/rockchip/evb_rk3128/Makefile
new file mode 100644
index 000..6040891
--- /dev/null
+++ b/board/rockchip/evb_rk3128/Makefile
@@ -0,0 +1,7 @@
+#
+# (C) Copyright 2017 Rockchip Electronics Co., Ltd
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += evb-rk3128.o
diff --git a/board/rockchip/evb_rk3128/evb-rk3128.c 
b/board/rockchip/evb_rk3128/evb-rk3128.c
new file mode 100644
index 000..bf36e25
--- /dev/null
+++ b/board/rockchip/evb_rk3128/evb-rk3128.c
@@ -0,0 +1,9 @@
+/*
+ * (C) Copyright 2017 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;


If this file is (essentially) empty, there is no point in having it.
And once this one gets removed, the 'obj-y +=' in the Makefile should also 
be changed respectively.



diff --git a/include/configs/evb_rk3128.h b/include/configs/evb_rk3128.h
new file mode 100644
index 000..a34153a
--- /dev/null
+++ b/include/configs/evb_rk3128.h
@@ -0,0 +1,15 @@
+/*
+ * (C) Copyright 2017 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __EVB_RK3128_H
+#define __EVB_RK3128_H
+
+#include 
+
+#define CONFIG_ENV_IS_IN_MMC


This has been migrated to Kconfig, please use the defconfig for this.


+#define CONFIG_SYS_MMC_ENV_DEV 0
+
+#endif


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

Re: [U-Boot] MAINTAINERS: update maintained files for Rockchip

[Philipp Tomsich]

> With some of the recent cleanups (e.g. moving the DRAM controller
> drivers for Rockchip devices to drivers/ram/rockchip), the files
> and paths listed in MAINTAINERS no longer covered what really is
> looked after as part of the Rockchip port.
> 
> This commit updates the files/paths listed in MAINTAINERS for the
> Rockchip port.  I am certain, though, that this will have missed some
> additional paths that should have been included...
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> Acked-by: Philipp Tomsich 
> ---
> 
>  MAINTAINERS | 12 
>  1 file changed, 12 insertions(+)
> 

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

Re: [U-Boot] rockchip: board: evb_rv1108: update README

[Philipp Tomsich]

> After commit d962e5dadc2c("rockchip: mkimage: use spl_boot0 for all Rockchip 
> SoCs"),
> the mkimage will not pad the Tag memroy, so we shoud
> pass a Taged ddr.bin/spl.bin to it.
> 
> Signed-off-by: Andy Yan 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  board/rockchip/evb_rv1108/README | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 

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

Re: [U-Boot] [U-Boot,v2,7/7] rockchip: rk3128: add sdram driver

[Philipp Tomsich]

> RK3128 support up to 2GB DDR3 sdram, one channel, 32bit data width.
> 
> This patch is only used for U-Boot, but not for SPL which will
> comes later, maybe after we merge all the common code into a common
> file.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v2: None
> 
>  drivers/ram/rockchip/Makefile   |  1 +
>  drivers/ram/rockchip/sdram_rk3128.c | 59 
> +
>  2 files changed, 60 insertions(+)
>  create mode 100644 drivers/ram/rockchip/sdram_rk3128.c
> 

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

Re: [U-Boot] [PATCHv4] env: enable accessing the environment in an EXT4 partition

[Jorge Ramirez]

On 11/27/2017 08:51 PM, Tom Rini wrote:

On Mon, Nov 27, 2017 at 08:19:20PM +0100, Jorge Ramirez-Ortiz wrote:


For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

   CONFIG_ENV_IS_IN_EXT4=y
   CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
   CONFIG_ENV_EXT4_FILE="/uboot.env"
   CONFIG_ENV_EXT4_INTERFACE="mmc"

Reviewed-by: Tom Rini 



thanks. I am using this feature for the Dragonboard 820c (will post the 
patches for review this week I think)

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

[U-Boot] [PATCH v2] usb: r8a66597: Add support for RZ/A series

[Chris Brandt]

While the USB HW in the RZ/A is basically the same, there are some
differences from the original versions that were in the SH SoCs.

Signed-off-by: Chris Brandt 
---
v2
 * Changed to CONFIG_RZA_USB to be set in Kconfig
 * Fixed multi-line comments
 * Switched to using setbits/clrbits
---
 drivers/usb/host/r8a66597-hcd.c | 47 +
 drivers/usb/host/r8a66597.h | 21 --
 2 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index 6ef51906c2..28d2bc8454 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -82,6 +82,7 @@ static int r8a66597_clock_enable(struct r8a66597 *r8a66597)
}
} while ((tmp & USBE) != USBE);
r8a66597_bclr(r8a66597, USBE, SYSCFG0);
+#if !defined(CONFIG_RZA_USB)
r8a66597_mdfy(r8a66597, CONFIG_R8A66597_XTAL, XTAL, SYSCFG0);
 
i = 0;
@@ -94,6 +95,20 @@ static int r8a66597_clock_enable(struct r8a66597 *r8a66597)
return -1;
}
} while ((tmp & SCKE) != SCKE);
+#else
+   /*
+* RZ/A Only:
+* Bits XTAL(UCKSEL) and UPLLE in SYSCFG0 for USB0 controls both USB0
+* and USB1, so we must always set the USB0 register
+*/
+#if (CONFIG_R8A66597_XTAL == 1)
+   setbits(le16, R8A66597_BASE0, XTAL);
+#endif
+   mdelay(1);
+   setbits(le16, R8A66597_BASE0, UPLLE);
+   mdelay(1);
+   r8a66597_bset(r8a66597, SUSPM, SUSPMODE0);
+#endif /* CONFIG_RZA_USB */
 #endif /* #if defined(CONFIG_SUPERH_ON_CHIP_R8A66597) */
 
return 0;
@@ -101,6 +116,7 @@ static int r8a66597_clock_enable(struct r8a66597 *r8a66597)
 
 static void r8a66597_clock_disable(struct r8a66597 *r8a66597)
 {
+#if !defined(CONFIG_RZA_USB)
r8a66597_bclr(r8a66597, SCKE, SYSCFG0);
udelay(1);
 #if !defined(CONFIG_SUPERH_ON_CHIP_R8A66597)
@@ -108,6 +124,15 @@ static void r8a66597_clock_disable(struct r8a66597 
*r8a66597)
r8a66597_bclr(r8a66597, XCKE, SYSCFG0);
r8a66597_bclr(r8a66597, USBE, SYSCFG0);
 #endif
+#else
+   r8a66597_bclr(r8a66597, SUSPM, SUSPMODE0);
+
+   clrbits(le16, R8A66597_BASE0, UPLLE);
+   mdelay(1);
+   r8a66597_bclr(r8a66597, USBE, SYSCFG0);
+   mdelay(1);
+
+#endif
 }
 
 static void r8a66597_enable_port(struct r8a66597 *r8a66597, int port)
@@ -118,7 +143,9 @@ static void r8a66597_enable_port(struct r8a66597 *r8a66597, 
int port)
r8a66597_bset(r8a66597, val, get_syscfg_reg(port));
r8a66597_bset(r8a66597, HSE, get_syscfg_reg(port));
 
+#if !defined(CONFIG_RZA_USB)
r8a66597_write(r8a66597, BURST | CPU_ADR_RD_WR, get_dmacfg_reg(port));
+#endif
 }
 
 static void r8a66597_disable_port(struct r8a66597 *r8a66597, int port)
@@ -148,7 +175,9 @@ static int enable_controller(struct r8a66597 *r8a66597)
if (ret < 0)
return ret;
 
+#if !defined(CONFIG_RZA_USB)
r8a66597_bset(r8a66597, CONFIG_R8A66597_LDRV & LDRV, PINCFG);
+#endif
r8a66597_bset(r8a66597, USBE, SYSCFG0);
 
r8a66597_bset(r8a66597, INTL, SOFCFG);
@@ -266,12 +295,30 @@ static int send_setup_packet(struct r8a66597 *r8a66597, 
struct usb_device *dev,
unsigned long setup_addr = USBREQ;
u16 intsts1;
int timeout = 3000;
+#if defined(CONFIG_RZA_USB)
+   u16 dcpctr;
+   int timeout2 = 1;
+#endif
u16 devsel = setup->request == USB_REQ_SET_ADDRESS ? 0 : dev->devnum;
 
r8a66597_write(r8a66597, make_devsel(devsel) |
 (8 << dev->maxpacketsize), DCPMAXP);
r8a66597_write(r8a66597, ~(SIGN | SACK), INTSTS1);
 
+#if defined(CONFIG_RZA_USB)
+   dcpctr = r8a66597_read(r8a66597, DCPCTR);
+   if ((dcpctr & PID) == PID_BUF) {
+   timeout2 = 1;
+   while (!(dcpctr & BSTS)) {
+   dcpctr = r8a66597_read(r8a66597, DCPCTR);
+   if (timeout2-- < 0) {
+   printf("DCPCTR clear timeout!\n");
+   break;
+   }
+   }
+   }
+#endif
+
for (i = 0; i < 4; i++) {
r8a66597_write(r8a66597, le16_to_cpu(p[i]), setup_addr);
setup_addr += 2;
diff --git a/drivers/usb/host/r8a66597.h b/drivers/usb/host/r8a66597.h
index 67dc3c4588..baa16605d8 100644
--- a/drivers/usb/host/r8a66597.h
+++ b/drivers/usb/host/r8a66597.h
@@ -87,8 +87,10 @@
 #define DEVADD80xE0
 #define DEVADD90xE2
 #define DEVADDA0xE4
+#define SUSPMODE0  0x102   /* RZ/A only */
 
 /* System Configuration Control Register */
+#if !defined(CONFIG_RZA_USB)
 #defineXTAL0xC000  /* b15-14: Crystal selection */
 #define  XTAL48 0x8000   /* 48MHz */
 #define  XTAL24 0x4000   /* 24MHz */
@@ -98,10 +100,17 @@
 #define

Re: [U-Boot] [U-Boot,v2,3/7] rockchip: rk3128: add clock driver

[Philipp Tomsich]

> Add rk3128 clock driver and cru structure definition.
> 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v2:
> - add clock for saradc, vop, nandc, i2c
> - update driver bind for sysreset driver and reset driver
> - add "rockchip,rk3126-cru" for compatible
> 
>  arch/arm/include/asm/arch-rockchip/cru_rk3128.h | 212 +
>  arch/arm/mach-rockchip/rk3128/Makefile  |   1 +
>  arch/arm/mach-rockchip/rk3128/clk_rk3128.c  |  32 ++
>  drivers/clk/rockchip/Makefile   |   3 +-
>  drivers/clk/rockchip/clk_rk3128.c   | 609 
> 
>  5 files changed, 856 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3128.h
>  create mode 100644 arch/arm/mach-rockchip/rk3128/clk_rk3128.c
>  create mode 100644 drivers/clk/rockchip/clk_rk3128.c
> 

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,v2,4/7] rockchip: rk3128: add pinctrl driver

[Philipp Tomsich]

> Add rk3128 pinctrl driver and grf/iomux structure definition.
> 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v2:
> - remove debug info
> - update GPIO2C4/C5 SHIFT
> 
>  arch/arm/include/asm/arch-rockchip/grf_rk3128.h | 551 
> 
>  drivers/pinctrl/Kconfig |  10 +
>  drivers/pinctrl/rockchip/Makefile   |   4 +-
>  drivers/pinctrl/rockchip/pinctrl_rk3128.c   | 187 
>  4 files changed, 750 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3128.h
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3128.c
> 

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

Re: [U-Boot] rockchip: board: evb_rv1108: update README

[Philipp Tomsich]

> After commit d962e5dadc2c("rockchip: mkimage: use spl_boot0 for all Rockchip 
> SoCs"),
> the mkimage will not pad the Tag memroy, so we shoud
> pass a Taged ddr.bin/spl.bin to it.
> 
> Signed-off-by: Andy Yan 
> ---
> 
>  board/rockchip/evb_rv1108/README | 5 ++---
>  1 file changed, 2 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] rockchip: board: evb_rv1108: update README

[Philipp Tomsich]

> After commit d962e5dadc2c("rockchip: mkimage: use spl_boot0 for all Rockchip 
> SoCs"),
> the mkimage will not pad the Tag memroy, so we shoud
> pass a Taged ddr.bin/spl.bin to it.
> 
> Signed-off-by: Andy Yan 
> ---
> 
>  board/rockchip/evb_rv1108/README | 5 ++---
>  1 file changed, 2 insertions(+), 3 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, v2, 1/7] rockchip: rk3128: add device tree file

[Philipp Tomsich]

> Add dts binding header for rk3128, files origin from kernel.
> 
> Series-Changes: 2
> - fix i2c address
> - add saradc and usb phy node
> - emmc using fifo mode for there is no dma support in rk3128 emmc
> - add some clock id in cru.h
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/dts/Makefile  |   1 +
>  arch/arm/dts/rk3128-evb.dts|  95 
>  arch/arm/dts/rk3128.dtsi   | 804 
> +
>  include/dt-bindings/clock/rk3128-cru.h | 190 
>  4 files changed, 1090 insertions(+)
>  create mode 100644 arch/arm/dts/rk3128-evb.dts
>  create mode 100644 arch/arm/dts/rk3128.dtsi
>  create mode 100644 include/dt-bindings/clock/rk3128-cru.h
> 

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

[U-Boot] [PATCH 2/5] warp: imximage.cfg: Handle the CONFIG_SECURE_BOOT case

[Breno Lima]

From: Breno Lima 

Secure boot is not enabled in warp imximage.cfg, add support for it.

Signed-off-by: Breno Lima 
---
 board/warp/imximage.cfg | 9 +
 1 file changed, 9 insertions(+)

diff --git a/board/warp/imximage.cfg b/board/warp/imximage.cfg
index 771dbb3..8420968 100644
--- a/board/warp/imximage.cfg
+++ b/board/warp/imximage.cfg
@@ -8,6 +8,8 @@
  *
  * The syntax is taken as close as possible with the kwbimage
  */
+#define __ASSEMBLY__
+#include 
 
 /* image version */
 
@@ -21,6 +23,13 @@ IMAGE_VERSION 2
 BOOT_FROM  sd
 
 /*
+ * Secure boot support
+ */
+#ifdef CONFIG_SECURE_BOOT
+CSF CONFIG_CSF_SIZE
+#endif
+
+/*
  * Device Configuration Data (DCD)
  *
  * Each entry must have the format:
-- 
2.7.4

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

[U-Boot] [PATCH 3/5] mx6sl: Select MX6SL option via Kconfig

[Breno Lima]

From: Breno Lima 

Currently the MX6SL option is selected via CONFIG_SYS_EXTRA_OPTIONS,
but it is better to select it directly via Kconfig.

Signed-off-by: Breno Lima 
---
 arch/arm/mach-imx/mx6/Kconfig | 2 ++
 configs/mx6slevk_defconfig| 2 +-
 configs/mx6slevk_spinor_defconfig | 2 +-
 configs/mx6slevk_spl_defconfig| 2 +-
 configs/warp_defconfig| 2 +-
 5 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index bee7eab..4f8bb8f 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -244,6 +244,7 @@ config TARGET_MX6SABRESD
 
 config TARGET_MX6SLEVK
bool "mx6slevk"
+   select MX6SL
select SUPPORT_SPL
 
 config TARGET_MX6SLLEVK
@@ -395,6 +396,7 @@ config TARGET_WANDBOARD
 
 config TARGET_WARP
bool "WaRP"
+   select MX6SL
select BOARD_LATE_INIT
 
 config TARGET_XPRESS
diff --git a/configs/mx6slevk_defconfig b/configs/mx6slevk_defconfig
index 7b1ddac..aafddfa 100644
--- a/configs/mx6slevk_defconfig
+++ b/configs/mx6slevk_defconfig
@@ -3,7 +3,7 @@ CONFIG_ARCH_MX6=y
 CONFIG_TARGET_MX6SLEVK=y
 # CONFIG_CMD_BMODE is not set
 CONFIG_DEFAULT_DEVICE_TREE="imx6sl-evk"
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg,MX6SL"
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg"
 CONFIG_BOOTDELAY=3
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_HUSH_PARSER=y
diff --git a/configs/mx6slevk_spinor_defconfig 
b/configs/mx6slevk_spinor_defconfig
index 4b9c04e..0d3cb59 100644
--- a/configs/mx6slevk_spinor_defconfig
+++ b/configs/mx6slevk_spinor_defconfig
@@ -3,7 +3,7 @@ CONFIG_ARCH_MX6=y
 CONFIG_TARGET_MX6SLEVK=y
 # CONFIG_CMD_BMODE is not set
 CONFIG_DEFAULT_DEVICE_TREE="imx6sl-evk"
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg,MX6SL"
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg"
 CONFIG_SPI_BOOT=y
 CONFIG_BOOTDELAY=3
 CONFIG_BOARD_EARLY_INIT_F=y
diff --git a/configs/mx6slevk_spl_defconfig b/configs/mx6slevk_spl_defconfig
index 05a5c9e..0dbd308 100644
--- a/configs/mx6slevk_spl_defconfig
+++ b/configs/mx6slevk_spl_defconfig
@@ -10,7 +10,7 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
 # CONFIG_CMD_BMODE is not set
 CONFIG_DEFAULT_DEVICE_TREE="imx6sl-evk"
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,MX6SL"
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 CONFIG_BOOTDELAY=3
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_SPL=y
diff --git a/configs/warp_defconfig b/configs/warp_defconfig
index 5e7eef0..2ac1c6c 100644
--- a/configs/warp_defconfig
+++ b/configs/warp_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_WARP=y
 # CONFIG_CMD_BMODE is not set
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/warp/imximage.cfg,MX6SL"
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/warp/imximage.cfg"
 CONFIG_BOOTDELAY=3
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_HUSH_PARSER=y
-- 
2.7.4

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

[U-Boot] [PATCH 5/5] imx: Kconfig: Add HAS_CAAM option

[Breno Lima]

From: Breno Lima 

Currently CONFIG_SECURE_BOOT is selecting FSL_CAAM for all i.MX devices,
this causes the following error when building mx6sl boards since
this SoC doesn't have the CAAM block:

In file included from drivers/crypto/fsl/jobdesc.c:12:0:
drivers/crypto/fsl/jobdesc.c: In function 'inline_cnstr_jobdesc_blob_dek':
include/fsl_sec.h:268:25: error: 'CAAM_ARB_BASE_ADDR' undeclared (first use
in this function)
 #define SEC_MEM_PAGE1  (CAAM_ARB_BASE_ADDR + 0x1000)
 ^
drivers/crypto/fsl/jobdesc.c:140:21: note: in expansion of macro 'SEC_MEM_PAGE1'
  memcpy((uint32_t *)SEC_MEM_PAGE1, (uint32_t *)plain_txt, in_sz);
 ^
include/fsl_sec.h:268:25: note: each undeclared identifier is reported only
once for each function it appears in
 #define SEC_MEM_PAGE1  (CAAM_ARB_BASE_ADDR + 0x1000)
 ^
drivers/crypto/fsl/jobdesc.c:140:21: note: in expansion of macro 'SEC_MEM_PAGE1'
  memcpy((uint32_t *)SEC_MEM_PAGE1, (uint32_t *)plain_txt, in_sz);
 ^
scripts/Makefile.build:280: recipe for target 'drivers/crypto/fsl/jobdesc.o'
failed
make[3]: *** [drivers/crypto/fsl/jobdesc.o] Error 1
scripts/Makefile.build:425: recipe for target 'drivers/crypto/fsl' failed
make[2]: *** [drivers/crypto/fsl] Error 2
scripts/Makefile.build:425: recipe for target 'drivers/crypto' failed
make[1]: *** [drivers/crypto] Error 2

Add HAS_CAAM configuration to avoid this error.

Signed-off-by: Breno Lima 
---
 arch/arm/mach-imx/Kconfig | 5 -
 arch/arm/mach-imx/mx6/Kconfig | 7 +++
 arch/arm/mach-imx/mx7/Kconfig | 1 +
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index cd8b8d2..a6f67c8 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -1,3 +1,6 @@
+config HAS_CAAM
+   bool
+
 config IMX_CONFIG
string
 
@@ -28,7 +31,7 @@ config USE_IMXIMG_PLUGIN
 config SECURE_BOOT
bool "Support i.MX HAB features"
depends on ARCH_MX7 || ARCH_MX6 || ARCH_MX5
-   select FSL_CAAM
+   select FSL_CAAM if HAS_CAAM
imply CMD_DEKBLOB
help
  This option enables the support for secure boot (HAB).
diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 279f088..8f98d9f 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -14,28 +14,34 @@ config MX6
imply CMD_FUSE
 
 config MX6D
+   select HAS_CAAM
select MX6_SMP
bool
 
 config MX6DL
+   select HAS_CAAM
select MX6_SMP
bool
 
 config MX6Q
+   select HAS_CAAM
select MX6_SMP
bool
 
 config MX6QDL
+   select HAS_CAAM
select MX6_SMP
bool
 
 config MX6S
+   select HAS_CAAM
bool
 
 config MX6SL
bool
 
 config MX6SX
+   select HAS_CAAM
select ROM_UNIFIED_SECTIONS
bool
 
@@ -44,6 +50,7 @@ config MX6SLL
bool
 
 config MX6UL
+   select HAS_CAAM
select SYS_L2CACHE_OFF
select ROM_UNIFIED_SECTIONS
bool
diff --git a/arch/arm/mach-imx/mx7/Kconfig b/arch/arm/mach-imx/mx7/Kconfig
index 365501d..4f8b4e1 100644
--- a/arch/arm/mach-imx/mx7/Kconfig
+++ b/arch/arm/mach-imx/mx7/Kconfig
@@ -10,6 +10,7 @@ config MX7
default y
 
 config MX7D
+   select HAS_CAAM
select ROM_UNIFIED_SECTIONS
imply CMD_FUSE
bool
-- 
2.7.4

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

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

[Fabio Estevam]

From: Fabio Estevam 

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

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

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Add CONFIG_NXP_BOARD_REVISION=y into mx6sxsabresd_spl_defconfig (Stefano)

 arch/arm/mach-imx/mx6/Kconfig   |  1 +
 board/freescale/mx6sxsabresd/mx6sxsabresd.c | 16 +++-
 configs/mx6sxsabresd_defconfig  |  1 +
 configs/mx6sxsabresd_spl_defconfig  |  1 +
 include/configs/mx6sxsabresd.h  |  8 ++--
 5 files changed, 24 insertions(+), 3 deletions(-)

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

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

[U-Boot] [PATCH] ARM: imx: display5: config: Update display5_factory_defconfig to use USE_BOOTCOMMAND

[Lukasz Majewski]

This commit switch display5_factory_defconfig to use new, generic
USE_BOOTCOMMAND Kconfig option.

Signed-off-by: Lukasz Majewski 
---

 configs/display5_factory_defconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configs/display5_factory_defconfig 
b/configs/display5_factory_defconfig
index 3f10ffad03..b65485fde7 100644
--- a/configs/display5_factory_defconfig
+++ b/configs/display5_factory_defconfig
@@ -11,6 +11,8 @@ CONFIG_FIT=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,MX6Q"
 CONFIG_BOOTDELAY=3
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run factory"
 CONFIG_SPL=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
@@ -22,8 +24,6 @@ CONFIG_SPL_USB_GADGET_SUPPORT=y
 CONFIG_SPL_USB_SDP_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="display5 factory > "
-CONFIG_BOOTCMD_OVERRIDE=y
-CONFIG_BOOTCOMMAND="run factory"
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_ELF is not set
 CONFIG_CMD_ASKENV=y
-- 
2.11.0

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

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

[Fabio Estevam]

From: Fabio Estevam 

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

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

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Fix nxp_board_rev_string() - Stefano

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

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

Re: [U-Boot] UBI / UBIFS booting from NAND support

[Ladislav Michl]

Dear Jose Miguel,

On Mon, Nov 27, 2017 at 11:45:11AM +0100, Jose Miguel Sanchez Sanabria wrote:
> Hi everyone.
> 
> I was testing the booting process from NAND using an UBI/UBIFS image in an
> igepv2 board.

I'm happy to see someone from ISEE being interested in mainline support
for their own product.

> However MLO tries to boot first kernel (falcon mode activated) and then
> falls back to u-boot (as expected anyway I just wanted to load u-boot from
> ubi) trying to load volume 0, but fails.

Due to size restrictions, MLO does contain only limited UBI functionality,
just enough to load image from static UBI volume.

> U-Boot SPL 2017.11-dirty (Nov 24 2017 - 14:29:26)
> Trying to boot from NAND
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 3
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 3
> UBI warning: Failed
> Loading Linux failed, falling back to U-Boot.
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 0
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 0
> UBI warning: Failed
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###

As noted above, ubispl loader is rather limited and identifies volumes
by volume id. u-boot.img is expected to be found in vol_id=0, while linux
zImage in vol_id=3. Log above indicates there are no such volumes.
What does u-boot's command 'ubi info l' show?

> I can however mount the ubi image but suspicious log appear:
> 
> u-boot:> ubifsmount ubi0:ubirootfs

Now you are in u-boot, where different UBI implementation is used, so
you can identify volumes also by name.

> UBIFS assert failed in ubifs_change_lp at 540
> UBIFS assert failed in ubifs_release_lprops at 278
> UBIFS assert failed in ubifs_change_lp at 540
> UBIFS assert failed in ubifs_release_lprops at 278
> 
> This has to do with the discussion about ubifs null deference so I suppose
> it should not affect much to write operation.

Well, I do not use UBIFS in U-Boot at all. Just UBI to read and write volumes.

> I would finally like to know if the ubi/ubifs support is functional; which
> would mean I did not use the ubi tools correctly to create the ubi image.

You will find script I'm using to bring board up at the end of this mail.
But note, that 'fdt memory' is hacked a bit and proper implementaion is welcome:
https://lists.denx.de/pipermail/u-boot/2017-January/279823.html

Also note 'setenv fdtfile "${soc_family}-${board_name}.dtb"' line. That's also
not in mainline as it needs also board revision too and the way it is currently
done, we cannot distinguish rev B. and rev F. Unfortunately this article
http://labs.isee.biz/index.php/IGEP_Technology_devices_revisions#IGEP0020_revisions
does not explain, how all those numbers map to board revisions ISEE is using
in vendor code.

That said, I enabled UBIFS for IGEPv2 only localy to verify my ubifs_finddir
reimplementation, but as I was even unable to mount ubifs, original reporter
did not confirm that at least mount works for him and I run out of the time,
ubifs issue is still unresolved.

Best regards,
ladis

echo "*** starting u-boot instalation script ***"
nandecc hw hamming
setenv has_onenand $?
# MLO ...
fatload mmc 0:1 $loadaddr MLO
if test $has_onenand -eq 0
then
nand erase.part SPL
nand write $fileaddr 0 $filesize
nand write $fileaddr 2 $filesize
nand write $fileaddr 4 $filesize
nand write $fileaddr 6 $filesize
nandecc sw bch8
nand read $loadaddr UBI 2
if test $? != 0
then
ubi detach
nand erase.part UBI
fi
else
ubi part UBI
ubi check loader
if test $? != 0
then
ubi detach
onenand erase
else
onenand erase 0 8
fi
onenand write $fileaddr 0 2
onenand write $fileaddr 2 2
onenand write $fileaddr 4 2
onenand write $fileaddr 6 2
fi

# UBI volumes
ubi part UBI

echo "Creating UBI volumes..."
ubi check loader
if test $? != 0
then
ubi createvol loader 10 static 0
fi
ubi check config
if test $? != 0
then
ubi createvol config 8000 static 1
fi
ubi check config_r
if test $? != 0
then
ubi createvol config_r 8000 static 2
fi
ubi check kernel
if test $? != 0
then
ubi createvol kernel 40 static 3
fi
ubi check dtb
if test $? != 0
then
ubi createvol dtb 4 static 4
fi
ubi check rootfs
if test $? != 0
then
ubi createvol rootfs
fi

setenv fdtfile "${soc_family}-${board_name}.dtb"

# U-Boot ...
fatload mmc 0:1 $loadaddr u-boot.img
ubi write $fileaddr loader $filesize
# ... and root filesystem first
fatload mmc 0:1 $loadaddr root.ubifs
ubi write $fileaddr rootfs $filesize
# now load FDT blob ...
fatload mmc 0:1 $fdtaddr $fdtfile
# and fix it...
setenv bootargs "console=ttyO2,115200n8 

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

[Andes]

From: Rick Chen 

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

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

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

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

[U-Boot] [PATCH v3 3/4] cosmetic: atcpit100_timer: Use device api to get platdata

[Andes]

From: Rick Chen 

Use dev_get_platdata to get private platdata.

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

diff --git a/drivers/timer/atcpit100_timer.c b/drivers/timer/atcpit100_timer.c
index d5146dd..963f978 100644
--- a/drivers/timer/atcpit100_timer.c
+++ b/drivers/timer/atcpit100_timer.c
@@ -73,7 +73,7 @@ struct atcpit_timer_platdata {
 
 static int atcpit_timer_get_count(struct udevice *dev, u64 *count)
 {
-   struct atcpit_timer_platdata *plat = dev->platdata;
+   struct atcpit_timer_platdata *plat = dev_get_platdata(dev);
u32 val;
val = ~(REG32_TMR(CH_CNT(1))+0x);
*count = timer_conv_64(val);
@@ -82,7 +82,7 @@ static int atcpit_timer_get_count(struct udevice *dev, u64 
*count)
 
 static int atcpit_timer_probe(struct udevice *dev)
 {
-   struct atcpit_timer_platdata *plat = dev->platdata;
+   struct atcpit_timer_platdata *plat = dev_get_platdata(dev);
REG32_TMR(CH_REL(1)) = 0x;
REG32_TMR(CH_CTL(1)) = APB_CLK|TMR_32;
REG32_TMR(CH_EN) |= CH_TMR_EN(1 , 0);
-- 
2.7.4

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

[U-Boot] [PATCH v3 4/4] dt-bindings: timer: Add andestech atcpit100 timer

[Andes]

From: Rick Chen 

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

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

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

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

[U-Boot] [PATCH v3 1/4] ae3xx: timer: Rename AE3XX to ATCPIT100

[Andes]

From: Rick Chen 

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

Signed-off-by: rick 
Signed-off-by: Rick Chen 
Reviewed-by: Simon Glass 
---
 configs/adp-ae3xx_defconfig |   2 +-
 drivers/timer/Kconfig   |   7 +--
 drivers/timer/Makefile  |   2 +-
 drivers/timer/ae3xx_timer.c | 117 
 drivers/timer/atcpit100_timer.c | 117 
 5 files changed, 123 insertions(+), 122 deletions(-)
 delete mode 100644 drivers/timer/ae3xx_timer.c
 create mode 100644 drivers/timer/atcpit100_timer.c

diff --git a/configs/adp-ae3xx_defconfig b/configs/adp-ae3xx_defconfig
index a3a40bf..337cee1 100644
--- a/configs/adp-ae3xx_defconfig
+++ b/configs/adp-ae3xx_defconfig
@@ -35,4 +35,4 @@ CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_NDS_AE3XX_SPI=y
 CONFIG_TIMER=y
-CONFIG_AE3XX_TIMER=y
+CONFIG_ATCPIT100_TIMER=y
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 6305bbf..fcfdf4e 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -105,11 +105,12 @@ config AG101P_TIMER
help
  Select this to enable a timer for AG01P devices.
 
-config AE3XX_TIMER
-   bool "AE3XX timer support"
+config ATCPIT100_TIMER
+   bool "ATCPIT100 timer support"
depends on TIMER && NDS32
help
- Select this to enable a timer for AE3XX devices.
+ Select this to enable a ATCPIT100 timer which will be embeded
+   in AE3XX, AE250 boards.
 
 config ROCKCHIP_TIMER
 bool "Rockchip timer support"
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index 69e8961..15e5154 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -13,6 +13,6 @@ obj-$(CONFIG_AST_TIMER)   += ast_timer.o
 obj-$(CONFIG_STI_TIMER)+= sti-timer.o
 obj-$(CONFIG_ARC_TIMER)+= arc_timer.o
 obj-$(CONFIG_AG101P_TIMER) += ag101p_timer.o
-obj-$(CONFIG_AE3XX_TIMER) += ae3xx_timer.o
+obj-$(CONFIG_ATCPIT100_TIMER) += atcpit100_timer.o
 obj-$(CONFIG_ROCKCHIP_TIMER) += rockchip_timer.o
 obj-$(CONFIG_ATMEL_PIT_TIMER) += atmel_pit_timer.o
diff --git a/drivers/timer/ae3xx_timer.c b/drivers/timer/ae3xx_timer.c
deleted file mode 100644
index b710c28..000
--- a/drivers/timer/ae3xx_timer.c
+++ /dev/null
@@ -1,117 +0,0 @@
-/*
- * Andestech ATCPIT100 timer driver
- *
- * (C) Copyright 2016
- * Rick Chen, NDS32 Software Engineering, r...@andestech.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#define REG32_TMR(x)   (*(u32 *)   ((plat->regs) + (x>>2)))
-
-/*
- * Definition of register offsets
- */
-
-/* ID and Revision Register */
-#define ID_REV 0x0
-
-/* Configuration Register */
-#define CFG0x10
-
-/* Interrupt Enable Register */
-#define INT_EN 0x14
-#define CH_INT_EN(c , i)   ((1<platdata;
-   u32 val;
-   val = ~(REG32_TMR(CH_CNT(1))+0x);
-   *count = timer_conv_64(val);
-   return 0;
-}
-
-static int atctmr_timer_probe(struct udevice *dev)
-{
-   struct atftmr_timer_platdata *plat = dev->platdata;
-   REG32_TMR(CH_REL(1)) = 0x;
-   REG32_TMR(CH_CTL(1)) = APB_CLK|TMR_32;
-   REG32_TMR(CH_EN) |= CH_TMR_EN(1 , 0);
-   return 0;
-}
-
-static int atctme_timer_ofdata_to_platdata(struct udevice *dev)
-{
-   struct atftmr_timer_platdata 

[U-Boot] [PATCH v3 1/4] ae3xx: timer: Rename AE3XX to ATCPIT100

[Rick Chen]

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

Signed-off-by: rick 
Signed-off-by: Rick Chen 
Reviewed-by: Simon Glass 
---
 configs/adp-ae3xx_defconfig |   2 +-
 drivers/timer/Kconfig   |   7 +--
 drivers/timer/Makefile  |   2 +-
 drivers/timer/ae3xx_timer.c | 117 
 drivers/timer/atcpit100_timer.c | 117 
 5 files changed, 123 insertions(+), 122 deletions(-)
 delete mode 100644 drivers/timer/ae3xx_timer.c
 create mode 100644 drivers/timer/atcpit100_timer.c

diff --git a/configs/adp-ae3xx_defconfig b/configs/adp-ae3xx_defconfig
index a3a40bf..337cee1 100644
--- a/configs/adp-ae3xx_defconfig
+++ b/configs/adp-ae3xx_defconfig
@@ -35,4 +35,4 @@ CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_NDS_AE3XX_SPI=y
 CONFIG_TIMER=y
-CONFIG_AE3XX_TIMER=y
+CONFIG_ATCPIT100_TIMER=y
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 6305bbf..fcfdf4e 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -105,11 +105,12 @@ config AG101P_TIMER
help
  Select this to enable a timer for AG01P devices.
 
-config AE3XX_TIMER
-   bool "AE3XX timer support"
+config ATCPIT100_TIMER
+   bool "ATCPIT100 timer support"
depends on TIMER && NDS32
help
- Select this to enable a timer for AE3XX devices.
+ Select this to enable a ATCPIT100 timer which will be embeded
+   in AE3XX, AE250 boards.
 
 config ROCKCHIP_TIMER
 bool "Rockchip timer support"
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index 69e8961..15e5154 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -13,6 +13,6 @@ obj-$(CONFIG_AST_TIMER)   += ast_timer.o
 obj-$(CONFIG_STI_TIMER)+= sti-timer.o
 obj-$(CONFIG_ARC_TIMER)+= arc_timer.o
 obj-$(CONFIG_AG101P_TIMER) += ag101p_timer.o
-obj-$(CONFIG_AE3XX_TIMER) += ae3xx_timer.o
+obj-$(CONFIG_ATCPIT100_TIMER) += atcpit100_timer.o
 obj-$(CONFIG_ROCKCHIP_TIMER) += rockchip_timer.o
 obj-$(CONFIG_ATMEL_PIT_TIMER) += atmel_pit_timer.o
diff --git a/drivers/timer/ae3xx_timer.c b/drivers/timer/ae3xx_timer.c
deleted file mode 100644
index b710c28..000
--- a/drivers/timer/ae3xx_timer.c
+++ /dev/null
@@ -1,117 +0,0 @@
-/*
- * Andestech ATCPIT100 timer driver
- *
- * (C) Copyright 2016
- * Rick Chen, NDS32 Software Engineering, r...@andestech.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#define REG32_TMR(x)   (*(u32 *)   ((plat->regs) + (x>>2)))
-
-/*
- * Definition of register offsets
- */
-
-/* ID and Revision Register */
-#define ID_REV 0x0
-
-/* Configuration Register */
-#define CFG0x10
-
-/* Interrupt Enable Register */
-#define INT_EN 0x14
-#define CH_INT_EN(c , i)   ((1<platdata;
-   u32 val;
-   val = ~(REG32_TMR(CH_CNT(1))+0x);
-   *count = timer_conv_64(val);
-   return 0;
-}
-
-static int atctmr_timer_probe(struct udevice *dev)
-{
-   struct atftmr_timer_platdata *plat = dev->platdata;
-   REG32_TMR(CH_REL(1)) = 0x;
-   REG32_TMR(CH_CTL(1)) = APB_CLK|TMR_32;
-   REG32_TMR(CH_EN) |= CH_TMR_EN(1 , 0);
-   return 0;
-}
-
-static int atctme_timer_ofdata_to_platdata(struct udevice *dev)
-{
-   struct atftmr_timer_platdata *plat = dev_get_platdata(dev);
-   

[U-Boot] [PATCH v3 0/4] Rename AE3XX timer to ATCPIT100

[Rick Chen]

Changelog v3

 - Patch 1/4: No change.
 - Patch 2/4: No change.
 - Patch 3/4: New.
 - Patch 4/4: No change.

 Patch 3/4
  1. Use dev_get_platdata to get dev private platdata.

Rick Chen (4):
  ae3xx: timer: Rename AE3XX to ATCPIT100
  cosmetic: atcpit100_timer: Rename function name as atcpit100
  cosmetic: atcpit100_timer: Use device api to get platdata
  dt-bindings: timer: Add andestech atcpit100 timer

 configs/adp-ae3xx_defconfig|   2 +-
 doc/device-tree-bindings/timer/atcpit100_timer.txt |  31 ++
 drivers/timer/Kconfig  |   7 +-
 drivers/timer/Makefile |   2 +-
 drivers/timer/ae3xx_timer.c| 117 -
 drivers/timer/atcpit100_timer.c| 117 +
 6 files changed, 154 insertions(+), 122 deletions(-)
 create mode 100644 doc/device-tree-bindings/timer/atcpit100_timer.txt
 delete mode 100644 drivers/timer/ae3xx_timer.c
 create mode 100644 drivers/timer/atcpit100_timer.c

-- 
2.7.4

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

[U-Boot] [PATCH v3 3/4] cosmetic: atcpit100_timer: Use device api to get platdata

[Rick Chen]

Use dev_get_platdata to get private platdata.

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

diff --git a/drivers/timer/atcpit100_timer.c b/drivers/timer/atcpit100_timer.c
index d5146dd..963f978 100644
--- a/drivers/timer/atcpit100_timer.c
+++ b/drivers/timer/atcpit100_timer.c
@@ -73,7 +73,7 @@ struct atcpit_timer_platdata {
 
 static int atcpit_timer_get_count(struct udevice *dev, u64 *count)
 {
-   struct atcpit_timer_platdata *plat = dev->platdata;
+   struct atcpit_timer_platdata *plat = dev_get_platdata(dev);
u32 val;
val = ~(REG32_TMR(CH_CNT(1))+0x);
*count = timer_conv_64(val);
@@ -82,7 +82,7 @@ static int atcpit_timer_get_count(struct udevice *dev, u64 
*count)
 
 static int atcpit_timer_probe(struct udevice *dev)
 {
-   struct atcpit_timer_platdata *plat = dev->platdata;
+   struct atcpit_timer_platdata *plat = dev_get_platdata(dev);
REG32_TMR(CH_REL(1)) = 0x;
REG32_TMR(CH_CTL(1)) = APB_CLK|TMR_32;
REG32_TMR(CH_EN) |= CH_TMR_EN(1 , 0);
-- 
2.7.4

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

[U-Boot] [PATCH] SPL: Add FIT data-position property support

[Peng Fan]

For external data, FIT has a optional property "data-position" which
can set the external data to a fixed offset to FIT beginning.
Add the support for this property in SPL FIT.

Signed-off-by: Ye Li 
Signed-off-by: Peng Fan 
Cc: Simon Glass 
Cc: Pantelis Antoniou 
Cc: "Andrew F. Davis" 
Cc: Igor Grinberg 
Cc: "tomas.me...@vaisala.com" 
Cc: Kever Yang 
Cc: Andre Przywara 
Cc: York Sun 
Cc: Lokesh Vutla 
Cc: "Cooper Jr., Franklin" 
Cc: George McCollister 
Cc: Tuomas Tynkkynen 
Cc: Jean-Jacques Hiblot 
Cc: Rick Altherr 
Cc: Tom Rini 
---
 common/image-fit.c   | 25 +
 common/spl/spl_fit.c | 11 +--
 include/image.h  |  3 +++
 3 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 7f17fd1410..b785d8a36e 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -806,6 +806,31 @@ int fit_image_get_data_offset(const void *fit, int 
noffset, int *data_offset)
return 0;
 }
 
+/**
+ * Get 'data-position' property from a given image node.
+ *
+ * @fit: pointer to the FIT image header
+ * @noffset: component image node offset
+ * @data_position: holds the data-position property
+ *
+ * returns:
+ * 0, on success
+ * -ENOENT if the property could not be found
+ */
+int fit_image_get_data_position(const void *fit, int noffset,
+   int *data_position)
+{
+   const fdt32_t *val;
+
+   val = fdt_getprop(fit, noffset, FIT_DATA_POSITION_PROP, NULL);
+   if (!val)
+   return -ENOENT;
+
+   *data_position = fdt32_to_cpu(*val);
+
+   return 0;
+}
+
 /**
  * Get 'data-size' property from a given image node.
  *
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 32d9ee5901..c915b4b149 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -143,6 +143,7 @@ static int spl_load_fit_image(struct spl_load_info *info, 
ulong sector,
int align_len = ARCH_DMA_MINALIGN - 1;
uint8_t image_comp = -1, type = -1;
const void *data;
+   bool external_data = false;
 
if (IS_ENABLED(CONFIG_SPL_OS_BOOT) && IS_ENABLED(CONFIG_SPL_GZIP)) {
if (fit_image_get_comp(fit, node, _comp))
@@ -159,9 +160,15 @@ static int spl_load_fit_image(struct spl_load_info *info, 
ulong sector,
if (fit_image_get_load(fit, node, _addr))
load_addr = image_info->load_addr;
 
-   if (!fit_image_get_data_offset(fit, node, )) {
-   /* External data */
+   if (!fit_image_get_data_position(fit, node, )) {
+   external_data = true;
+   } else if (!fit_image_get_data_offset(fit, node, )) {
offset += base_offset;
+   external_data = true;
+   }
+
+   if (external_data) {
+   /* External data */
if (fit_image_get_data_size(fit, node, ))
return -ENOENT;
 
diff --git a/include/image.h b/include/image.h
index 127cfc5148..15e171d037 100644
--- a/include/image.h
+++ b/include/image.h
@@ -886,6 +886,7 @@ int bootz_setup(ulong image, ulong *start, ulong *end);
 
 /* image node */
 #define FIT_DATA_PROP  "data"
+#define FIT_DATA_POSITION_PROP "data-position"
 #define FIT_DATA_OFFSET_PROP   "data-offset"
 #define FIT_DATA_SIZE_PROP "data-size"
 #define FIT_TIMESTAMP_PROP "timestamp"
@@ -967,6 +968,8 @@ int fit_image_get_entry(const void *fit, int noffset, ulong 
*entry);
 int fit_image_get_data(const void *fit, int noffset,
const void **data, size_t *size);
 int fit_image_get_data_offset(const void *fit, int noffset, int *data_offset);
+int fit_image_get_data_position(const void *fit, int noffset,
+   int *data_position);
 int fit_image_get_data_size(const void *fit, int noffset, int *data_size);
 
 int fit_image_hash_get_algo(const void *fit, int noffset, char **algo);
-- 
2.14.1

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

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

[Rick Chen]

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

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

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

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

[U-Boot] [PATCH v3 1/4] ae3xx: timer: Rename AE3XX to ATCPIT100

[Rick Chen]

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

Signed-off-by: rick 
Signed-off-by: Rick Chen 
Reviewed-by: Simon Glass 
---
 configs/adp-ae3xx_defconfig |   2 +-
 drivers/timer/Kconfig   |   7 +--
 drivers/timer/Makefile  |   2 +-
 drivers/timer/ae3xx_timer.c | 117 
 drivers/timer/atcpit100_timer.c | 117 
 5 files changed, 123 insertions(+), 122 deletions(-)
 delete mode 100644 drivers/timer/ae3xx_timer.c
 create mode 100644 drivers/timer/atcpit100_timer.c

diff --git a/configs/adp-ae3xx_defconfig b/configs/adp-ae3xx_defconfig
index a3a40bf..337cee1 100644
--- a/configs/adp-ae3xx_defconfig
+++ b/configs/adp-ae3xx_defconfig
@@ -35,4 +35,4 @@ CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_NDS_AE3XX_SPI=y
 CONFIG_TIMER=y
-CONFIG_AE3XX_TIMER=y
+CONFIG_ATCPIT100_TIMER=y
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 6305bbf..fcfdf4e 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -105,11 +105,12 @@ config AG101P_TIMER
help
  Select this to enable a timer for AG01P devices.
 
-config AE3XX_TIMER
-   bool "AE3XX timer support"
+config ATCPIT100_TIMER
+   bool "ATCPIT100 timer support"
depends on TIMER && NDS32
help
- Select this to enable a timer for AE3XX devices.
+ Select this to enable a ATCPIT100 timer which will be embeded
+   in AE3XX, AE250 boards.
 
 config ROCKCHIP_TIMER
 bool "Rockchip timer support"
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index 69e8961..15e5154 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -13,6 +13,6 @@ obj-$(CONFIG_AST_TIMER)   += ast_timer.o
 obj-$(CONFIG_STI_TIMER)+= sti-timer.o
 obj-$(CONFIG_ARC_TIMER)+= arc_timer.o
 obj-$(CONFIG_AG101P_TIMER) += ag101p_timer.o
-obj-$(CONFIG_AE3XX_TIMER) += ae3xx_timer.o
+obj-$(CONFIG_ATCPIT100_TIMER) += atcpit100_timer.o
 obj-$(CONFIG_ROCKCHIP_TIMER) += rockchip_timer.o
 obj-$(CONFIG_ATMEL_PIT_TIMER) += atmel_pit_timer.o
diff --git a/drivers/timer/ae3xx_timer.c b/drivers/timer/ae3xx_timer.c
deleted file mode 100644
index b710c28..000
--- a/drivers/timer/ae3xx_timer.c
+++ /dev/null
@@ -1,117 +0,0 @@
-/*
- * Andestech ATCPIT100 timer driver
- *
- * (C) Copyright 2016
- * Rick Chen, NDS32 Software Engineering, r...@andestech.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#define REG32_TMR(x)   (*(u32 *)   ((plat->regs) + (x>>2)))
-
-/*
- * Definition of register offsets
- */
-
-/* ID and Revision Register */
-#define ID_REV 0x0
-
-/* Configuration Register */
-#define CFG0x10
-
-/* Interrupt Enable Register */
-#define INT_EN 0x14
-#define CH_INT_EN(c , i)   ((1<platdata;
-   u32 val;
-   val = ~(REG32_TMR(CH_CNT(1))+0x);
-   *count = timer_conv_64(val);
-   return 0;
-}
-
-static int atctmr_timer_probe(struct udevice *dev)
-{
-   struct atftmr_timer_platdata *plat = dev->platdata;
-   REG32_TMR(CH_REL(1)) = 0x;
-   REG32_TMR(CH_CTL(1)) = APB_CLK|TMR_32;
-   REG32_TMR(CH_EN) |= CH_TMR_EN(1 , 0);
-   return 0;
-}
-
-static int atctme_timer_ofdata_to_platdata(struct udevice *dev)
-{
-   struct atftmr_timer_platdata *plat = dev_get_platdata(dev);
-   

[U-Boot] [PATCH v3 4/4] dt-bindings: timer: Add andestech atcpit100 timer

[Rick Chen]

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

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

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

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

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

[Rick Chen]

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

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

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

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

[U-Boot] [PATCH v3 3/4] cosmetic: atcpit100_timer: Use device api to get platdata

[Rick Chen]

Use dev_get_platdata to get private platdata.

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

diff --git a/drivers/timer/atcpit100_timer.c b/drivers/timer/atcpit100_timer.c
index d5146dd..963f978 100644
--- a/drivers/timer/atcpit100_timer.c
+++ b/drivers/timer/atcpit100_timer.c
@@ -73,7 +73,7 @@ struct atcpit_timer_platdata {
 
 static int atcpit_timer_get_count(struct udevice *dev, u64 *count)
 {
-   struct atcpit_timer_platdata *plat = dev->platdata;
+   struct atcpit_timer_platdata *plat = dev_get_platdata(dev);
u32 val;
val = ~(REG32_TMR(CH_CNT(1))+0x);
*count = timer_conv_64(val);
@@ -82,7 +82,7 @@ static int atcpit_timer_get_count(struct udevice *dev, u64 
*count)
 
 static int atcpit_timer_probe(struct udevice *dev)
 {
-   struct atcpit_timer_platdata *plat = dev->platdata;
+   struct atcpit_timer_platdata *plat = dev_get_platdata(dev);
REG32_TMR(CH_REL(1)) = 0x;
REG32_TMR(CH_CTL(1)) = APB_CLK|TMR_32;
REG32_TMR(CH_EN) |= CH_TMR_EN(1 , 0);
-- 
2.7.4

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

[U-Boot] [PATCH v3 0/4] Rename AE3XX timer to ATCPIT100

[Rick Chen]

Changelog v3

 - Patch 1/4: No change.
 - Patch 2/4: No change.
 - Patch 3/4: New.
 - Patch 4/4: No change.

 Patch 3/4
  1. Use dev_get_platdata to get dev private platdata.

Rick Chen (4):
  ae3xx: timer: Rename AE3XX to ATCPIT100
  cosmetic: atcpit100_timer: Rename function name as atcpit100
  cosmetic: atcpit100_timer: Use device api to get platdata
  dt-bindings: timer: Add andestech atcpit100 timer

 configs/adp-ae3xx_defconfig|   2 +-
 doc/device-tree-bindings/timer/atcpit100_timer.txt |  31 ++
 drivers/timer/Kconfig  |   7 +-
 drivers/timer/Makefile |   2 +-
 drivers/timer/ae3xx_timer.c| 117 -
 drivers/timer/atcpit100_timer.c| 117 +
 6 files changed, 154 insertions(+), 122 deletions(-)
 create mode 100644 doc/device-tree-bindings/timer/atcpit100_timer.txt
 delete mode 100644 drivers/timer/ae3xx_timer.c
 create mode 100644 drivers/timer/atcpit100_timer.c

-- 
2.7.4

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

Re: [U-Boot] [PATCH] usb: r8a66597: Add support for RZ/A series

[Marek Vasut]

On 11/27/2017 06:27 PM, Chris Brandt wrote:
> Hello Marek,
> 
> On Friday, November 17, 2017, Marek Vasut wrote:
>>> +#ifdef RZA_USB
>>> +   dcpctr = r8a66597_read(r8a66597, DCPCTR);
>>
>> use wait_for_bit() .
>>
>>> +   if ((dcpctr & PID) == PID_BUF) {
>>> +   timeout2 = 1;
>>> +   while (!(dcpctr & BSTS)) {
>>> +   dcpctr = r8a66597_read(r8a66597, DCPCTR);
>>> +   if (timeout2-- < 0) {
>>> +   printf("DCPCTR clear timeout!\n");
>>> +   break;
>>> +   }
>>> +   }
>>> +   }
>>> +#endif
> 
> 
> wait_for_bit() wants you to pass a direct address of a 32-bit register.
> The register I am waiting for is a 16-bit register and the hardware 
> manual doesn't say 32-bit is allowed.
> When I do a 32-bit read on that address, I actually get a different 
> value.
> 
> For example:
> 
> => md.w E8010060 1
> e8010060: 0040
> => md.l E8010060 1
> e8010060: 0040
> 
> 
> So, I can't use wait_for_bit()

Can we somehow extend wait_for_bit() ?

> Chris
> 


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

Re: [U-Boot] [PATCH v2] usb: r8a66597: Add support for RZ/A series

[Marek Vasut]

On 11/27/2017 08:04 PM, Chris Brandt wrote:
> While the USB HW in the RZ/A is basically the same, there are some
> differences from the original versions that were in the SH SoCs.
> 
> Signed-off-by: Chris Brandt 
> ---
> v2
>  * Changed to CONFIG_RZA_USB to be set in Kconfig
>  * Fixed multi-line comments
>  * Switched to using setbits/clrbits

Applied, thanks.

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

[U-Boot] [PATCH v3 4/4] dt-bindings: timer: Add andestech atcpit100 timer

[Rick Chen]

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

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

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

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

Re: [U-Boot] [PATCH v3 1/4] ae3xx: timer: Rename AE3XX to ATCPIT100

[rick]

Hi Simon

According to your suggestions.
I have applied a gmail account for patch works
I send the patchs via rickche...@gmail.com, but I can not see the patchs appear 
in the patchwaotk list.
http://patchwork.ozlabs.org/project/uboot/list/

But if I send via Andes , the patchwork list can see my 
sending patchs
I don't know what is wrong with that ?


> -Original Message-
> From: Rick Chen [mailto:rickche...@gmail.com]
> Sent: Tuesday, November 28, 2017 10:20 AM
> To: u-boot@lists.denx.de; w...@denx.de; d...@denx.de; s...@chromium.org
> Cc: Rick Jian-Zhi Chen(陳建志)
> Subject: [PATCH v3 1/4] ae3xx: timer: Rename AE3XX to ATCPIT100
>
> ATCPIT100 is Andestech timer IP which is embeded in AE3XX and AE250 boards.
> So rename AE3XX to
> ATCPIT100 will be more make sence.
>
> Signed-off-by: rick 
> Signed-off-by: Rick Chen 
> Reviewed-by: Simon Glass 
> ---
>  configs/adp-ae3xx_defconfig |   2 +-
>  drivers/timer/Kconfig   |   7 +--
>  drivers/timer/Makefile  |   2 +-
>  drivers/timer/ae3xx_timer.c | 117 
> 
>  drivers/timer/atcpit100_timer.c | 117
> 
>  5 files changed, 123 insertions(+), 122 deletions(-)  delete mode 100644
> drivers/timer/ae3xx_timer.c  create mode 100644
> drivers/timer/atcpit100_timer.c
>
> diff --git a/configs/adp-ae3xx_defconfig b/configs/adp-ae3xx_defconfig index
> a3a40bf..337cee1 100644
> --- a/configs/adp-ae3xx_defconfig
> +++ b/configs/adp-ae3xx_defconfig
> @@ -35,4 +35,4 @@ CONFIG_SYS_NS16550=y
>  CONFIG_DM_SPI=y
>  CONFIG_NDS_AE3XX_SPI=y
>  CONFIG_TIMER=y
> -CONFIG_AE3XX_TIMER=y
> +CONFIG_ATCPIT100_TIMER=y
> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig index 
> 6305bbf..fcfdf4e
> 100644
> --- a/drivers/timer/Kconfig
> +++ b/drivers/timer/Kconfig
> @@ -105,11 +105,12 @@ config AG101P_TIMER
>   help
> Select this to enable a timer for AG01P devices.
>
> -config AE3XX_TIMER
> - bool "AE3XX timer support"
> +config ATCPIT100_TIMER
> + bool "ATCPIT100 timer support"
>   depends on TIMER && NDS32
>   help
> -   Select this to enable a timer for AE3XX devices.
> +   Select this to enable a ATCPIT100 timer which will be embeded
> + in AE3XX, AE250 boards.
>
>  config ROCKCHIP_TIMER
>  bool "Rockchip timer support"
> diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile index
> 69e8961..15e5154 100644
> --- a/drivers/timer/Makefile
> +++ b/drivers/timer/Makefile
> @@ -13,6 +13,6 @@ obj-$(CONFIG_AST_TIMER) += ast_timer.o
>  obj-$(CONFIG_STI_TIMER)  += sti-timer.o
>  obj-$(CONFIG_ARC_TIMER)  += arc_timer.o
>  obj-$(CONFIG_AG101P_TIMER) += ag101p_timer.o
> -obj-$(CONFIG_AE3XX_TIMER) += ae3xx_timer.o
> +obj-$(CONFIG_ATCPIT100_TIMER) += atcpit100_timer.o
>  obj-$(CONFIG_ROCKCHIP_TIMER) += rockchip_timer.o
>  obj-$(CONFIG_ATMEL_PIT_TIMER) += atmel_pit_timer.o diff --git
> a/drivers/timer/ae3xx_timer.c b/drivers/timer/ae3xx_timer.c deleted file mode
> 100644 index b710c28..000
> --- a/drivers/timer/ae3xx_timer.c
> +++ /dev/null
> @@ -1,117 +0,0 @@
> -/*
> - * Andestech ATCPIT100 timer driver
> - *
> - * (C) Copyright 2016
> - * Rick Chen, NDS32 Software Engineering, r...@andestech.com
> - *
> - * SPDX-License-Identifier:  GPL-2.0+
> - */
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -DECLARE_GLOBAL_DATA_PTR;
> -
> -#define REG32_TMR(x) (*(u32 *)   ((plat->regs) + (x>>2)))
> -
> -/*
> - * Definition of register offsets
> - */
> -
> -/* ID and Revision Register */
> -#define ID_REV   0x0
> -
> -/* Configuration Register */
> -#define CFG  0x10
> -
> -/* Interrupt Enable Register */
> -#define INT_EN   0x14
> -#define CH_INT_EN(c , i) ((1< -
> -/* Interrupt Status Register */
> -#define INT_STA  0x18
> -#define CH_INT_STA(c , i)((1< -
> -/* Channel Enable Register */
> -#define CH_EN0x1C
> -#define CH_TMR_EN(c , t) ((1< -
> -/* Ch n Control REgister */
> -#define CH_CTL(n)(0x20+0x10*n)
> -/* Channel clock source , bit 3 , 0:External clock , 1:APB clock */
> -#define APB_CLK  (1<<3)
> -/* Channel mode , bit 0~2 */
> -#define TMR_32   1
> -#define TMR_16   2
> -#define TMR_83
> -#define PWM  4
> -
> -#define CH_REL(n)(0x24+0x10*n)
> -#define CH_CNT(n)(0x28+0x10*n)
> -
> -struct atctmr_timer_regs {
> - u32 id_rev; /* 0x00 */
> - u32 reservd[3]; /* 0x04 ~ 0x0c */
> - u32 cfg;/* 0x10 */
> - u32 int_en; /* 0x14 */
> - u32 int_st; /* 0x18 */
> - u32 ch_en;  /* 0x1c */
> - u32 ch0_ctrl;   /* 0x20 */
> - u32 ch0_reload; /* 0x24 */
> - u32 ch0_cntr;   /* 0x28 */
> - u32 

Re: [U-Boot] [PATCH v3 1/4] ae3xx: timer: Rename AE3XX to ATCPIT100

[rick]

> -Original Message-
> From: Rick Jian-Zhi Chen(陳建志)
> Sent: Tuesday, November 28, 2017 11:27 AM
> To: 'Rick Chen'; u-boot@lists.denx.de; w...@denx.de; s...@chromium.org
> Subject: RE: [PATCH v3 1/4] ae3xx: timer: Rename AE3XX to ATCPIT100
>
> Hi Simon
>
> According to your suggestions.
> I have applied a gmail account for patch works I send the patchs via
> rickche...@gmail.com, but I can not see the patchs appear in the patchwaotk
> list.
> http://patchwork.ozlabs.org/project/uboot/list/
>
> But if I send via Andes , the patchwork list can see my
> sending patchs I don't know what is wrong with that ?
>
>

Finally it appear in the patchwork list.
But somehow it appears very slowly.

> > -Original Message-
> > From: Rick Chen [mailto:rickche...@gmail.com]
> > Sent: Tuesday, November 28, 2017 10:20 AM
> > To: u-boot@lists.denx.de; w...@denx.de; d...@denx.de; s...@chromium.org
> > Cc: Rick Jian-Zhi Chen(陳建志)
> > Subject: [PATCH v3 1/4] ae3xx: timer: Rename AE3XX to ATCPIT100
> >
> > ATCPIT100 is Andestech timer IP which is embeded in AE3XX and AE250 boards.
> > So rename AE3XX to
> > ATCPIT100 will be more make sence.
> >
> > Signed-off-by: rick 
> > Signed-off-by: Rick Chen 
> > Reviewed-by: Simon Glass 
> > ---
> >  configs/adp-ae3xx_defconfig |   2 +-
> >  drivers/timer/Kconfig   |   7 +--
> >  drivers/timer/Makefile  |   2 +-
> >  drivers/timer/ae3xx_timer.c | 117 
> > 
> >  drivers/timer/atcpit100_timer.c | 117
> > 
> >  5 files changed, 123 insertions(+), 122 deletions(-)  delete mode
> > 100644 drivers/timer/ae3xx_timer.c  create mode 100644
> > drivers/timer/atcpit100_timer.c
> >
> > diff --git a/configs/adp-ae3xx_defconfig b/configs/adp-ae3xx_defconfig
> > index
> > a3a40bf..337cee1 100644
> > --- a/configs/adp-ae3xx_defconfig
> > +++ b/configs/adp-ae3xx_defconfig
> > @@ -35,4 +35,4 @@ CONFIG_SYS_NS16550=y  CONFIG_DM_SPI=y
> > CONFIG_NDS_AE3XX_SPI=y  CONFIG_TIMER=y -CONFIG_AE3XX_TIMER=y
> > +CONFIG_ATCPIT100_TIMER=y
> > diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig index
> > 6305bbf..fcfdf4e
> > 100644
> > --- a/drivers/timer/Kconfig
> > +++ b/drivers/timer/Kconfig
> > @@ -105,11 +105,12 @@ config AG101P_TIMER
> > help
> >   Select this to enable a timer for AG01P devices.
> >
> > -config AE3XX_TIMER
> > -   bool "AE3XX timer support"
> > +config ATCPIT100_TIMER
> > +   bool "ATCPIT100 timer support"
> > depends on TIMER && NDS32
> > help
> > - Select this to enable a timer for AE3XX devices.
> > + Select this to enable a ATCPIT100 timer which will be embeded
> > +   in AE3XX, AE250 boards.
> >
> >  config ROCKCHIP_TIMER
> >  bool "Rockchip timer support"
> > diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile index
> > 69e8961..15e5154 100644
> > --- a/drivers/timer/Makefile
> > +++ b/drivers/timer/Makefile
> > @@ -13,6 +13,6 @@ obj-$(CONFIG_AST_TIMER)   += ast_timer.o
> >  obj-$(CONFIG_STI_TIMER)+= sti-timer.o
> >  obj-$(CONFIG_ARC_TIMER)+= arc_timer.o
> >  obj-$(CONFIG_AG101P_TIMER) += ag101p_timer.o
> > -obj-$(CONFIG_AE3XX_TIMER) += ae3xx_timer.o
> > +obj-$(CONFIG_ATCPIT100_TIMER) += atcpit100_timer.o
> >  obj-$(CONFIG_ROCKCHIP_TIMER) += rockchip_timer.o
> >  obj-$(CONFIG_ATMEL_PIT_TIMER) += atmel_pit_timer.o diff --git
> > a/drivers/timer/ae3xx_timer.c b/drivers/timer/ae3xx_timer.c deleted
> > file mode
> > 100644 index b710c28..000
> > --- a/drivers/timer/ae3xx_timer.c
> > +++ /dev/null
> > @@ -1,117 +0,0 @@
> > -/*
> > - * Andestech ATCPIT100 timer driver
> > - *
> > - * (C) Copyright 2016
> > - * Rick Chen, NDS32 Software Engineering, r...@andestech.com
> > - *
> > - * SPDX-License-Identifier:GPL-2.0+
> > - */
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -
> > -DECLARE_GLOBAL_DATA_PTR;
> > -
> > -#define REG32_TMR(x)   (*(u32 *)   ((plat->regs) + (x>>2)))
> > -
> > -/*
> > - * Definition of register offsets
> > - */
> > -
> > -/* ID and Revision Register */
> > -#define ID_REV 0x0
> > -
> > -/* Configuration Register */
> > -#define CFG0x10
> > -
> > -/* Interrupt Enable Register */
> > -#define INT_EN 0x14
> > -#define CH_INT_EN(c , i)   ((1< > -
> > -/* Interrupt Status Register */
> > -#define INT_STA0x18
> > -#define CH_INT_STA(c , i)  ((1< > -
> > -/* Channel Enable Register */
> > -#define CH_EN  0x1C
> > -#define CH_TMR_EN(c , t)   ((1< > -
> > -/* Ch n Control REgister */
> > -#define CH_CTL(n)  (0x20+0x10*n)
> > -/* Channel clock source , bit 3 , 0:External clock , 1:APB clock */
> > -#define APB_CLK(1<<3)
> > -/* Channel mode , bit 0~2 */
> > -#define TMR_32 1
> > -#define TMR_16 2
> > -#define TMR_8  

[U-Boot] [PATCHv2] spl: TI: Do not default to SPL_FIT_IMAGE_TINY being enabled

[Tom Rini]

This option prevents booting on am335x_evm at least along with most
likely other platforms.

Fixes: 337bbb629777 ("spl: fit: add SPL_FIT_IMAGE_TINY config to reduce 
code-size")
Signed-off-by: Tom Rini 
---
Changes in v2:
- Turn off SPL_USE_ARCH_MEMSET/MEMCPY on am335x_hs_evm_defconfig due to
  size constraints, which I suspect is what caused the initial change.
  Since I can't confirm that SPL_FIT_IMAGE_TINY works on am335x_hs_evm
  this is the safer option.
---
 common/spl/Kconfig  | 1 -
 configs/am335x_hs_evm_defconfig | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index b1ee15c96d13..aef0034b3356 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -232,7 +232,6 @@ config SPL_FIT_IMAGE_TINY
bool "Remove functionality from SPL FIT loading to reduce size"
depends on SPL_FIT
default y if MACH_SUN50I || MACH_SUN50I_H5
-   default y if ARCH_OMAP2PLUS
help
  Enable this to reduce the size of the FIT image loading code
  in SPL, if space for the SPL binary is very tight.
diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
index 9bc9dc339436..48b0e8583997 100644
--- a/configs/am335x_hs_evm_defconfig
+++ b/configs/am335x_hs_evm_defconfig
@@ -1,4 +1,6 @@
 CONFIG_ARM=y
+# CONFIG_SPL_USE_ARCH_MEMCPY is not set
+# CONFIG_SPL_USE_ARCH_MEMSET is not set
 CONFIG_ARCH_OMAP2PLUS=y
 CONFIG_TI_COMMON_CMD_OPTIONS=y
 CONFIG_AM33XX=y
-- 
2.7.4

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

[U-Boot] [PATCH] armv8: ls1088ardb: support force SDHC mode by hwconfig

[Yangbo Lu]

The BRDCFG5[SPISDHC] register field of Qixis device is used
to control SPI and SDHC signal routing.

10 = Force SDHC Mode
  - SPI_CS[0] is routed to CPLD for SDHC_VS use.
  - SPI_CS[1] is unused.
  - SPI_CS[2:3] are routed to the TDMRiser slot.

11 = Force eMMC Mode
  - SPI_CS[0:3] are routed to the eMMC card.

0X = Auto Mode
  - If SDHC_CS_B=0 (SDHC card installed): Use SDHC mode
described above.
  - Else SDHC_CS_B=1 (no SDHC card installed): Use eMMC
mode described above.

In default the hardware uses auto mode, but sometimes we need
to use force SDHC mode to support SD card hotplug, or SD sleep
waking up in kernel. This patch is to support force SDHC mode
by hwconfig.

Signed-off-by: Yangbo Lu 
---
 board/freescale/ls1088a/ls1088a.c   | 18 ++
 board/freescale/ls1088a/ls1088a_qixis.h |  6 ++
 include/configs/ls1088ardb.h|  2 ++
 3 files changed, 26 insertions(+)

diff --git a/board/freescale/ls1088a/ls1088a.c 
b/board/freescale/ls1088a/ls1088a.c
index 96d9ae7f1d..60f40edb5a 100644
--- a/board/freescale/ls1088a/ls1088a.c
+++ b/board/freescale/ls1088a/ls1088a.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../common/qixis.h"
 #include "ls1088a_qixis.h"
@@ -296,6 +297,23 @@ void board_retimer_init(void)
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
 }
 
+#ifdef CONFIG_MISC_INIT_R
+int misc_init_r(void)
+{
+#ifdef CONFIG_TARGET_LS1088ARDB
+   u8 brdcfg5;
+
+   if (hwconfig("esdhc-force-sd")) {
+   brdcfg5 = QIXIS_READ(brdcfg[5]);
+   brdcfg5 &= ~BRDCFG5_SPISDHC_MASK;
+   brdcfg5 |= BRDCFG5_FORCE_SD;
+   QIXIS_WRITE(brdcfg[5], brdcfg5);
+   }
+#endif
+   return 0;
+}
+#endif
+
 int board_init(void)
 {
init_final_memctl_regs();
diff --git a/board/freescale/ls1088a/ls1088a_qixis.h 
b/board/freescale/ls1088a/ls1088a_qixis.h
index 4790461b47..6cad396cff 100644
--- a/board/freescale/ls1088a/ls1088a_qixis.h
+++ b/board/freescale/ls1088a/ls1088a_qixis.h
@@ -36,4 +36,10 @@
 #define BRDCFG9_SFPTX_MASK 0x10
 #define BRDCFG9_SFPTX_SHIFT4
 
+/* Definitions of QIXIS Registers for LS1088ARDB */
+
+/* BRDCFG5 */
+#define BRDCFG5_SPISDHC_MASK   0x0C
+#define BRDCFG5_FORCE_SD   0x08
+
 #endif
diff --git a/include/configs/ls1088ardb.h b/include/configs/ls1088ardb.h
index e6bf2b8d87..f7b502d1b0 100644
--- a/include/configs/ls1088ardb.h
+++ b/include/configs/ls1088ardb.h
@@ -11,6 +11,8 @@
 
 #define CONFIG_DISPLAY_BOARDINFO_LATE
 
+#define CONFIG_MISC_INIT_R
+
 #if defined(CONFIG_QSPI_BOOT)
 #define CONFIG_ENV_SIZE0x2000  /* 8KB */
 #define CONFIG_ENV_OFFSET  0x30/* 3MB */
-- 
2.14.1

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

[U-Boot] [PATCH v3] power: extend prefix match to regulator-name property

[Felix Brack]

This patch extends pmic_bind_children prefix matching. In addition to
the node name the property regulator-name is used while trying to match
prefixes. This allows assigning different drivers to regulator nodes
named regulator@1 and regulator@10 for example.
I have discarded the idea of using other properties then regulator-name
as I do not see any benefit in using property compatible or even
regulator-compatible. Of course I am open to change this if there are
good reasons to do so.

Signed-off-by: Felix Brack 
---

Changes in v3:
- refactoring improving code readability

Changes in v2:
- add documentation
- add a regulator to the sandbox for testing
- extend the test for the new sandbox regulator

 arch/sandbox/dts/sandbox_pmic.dtsi   |  6 ++
 doc/device-tree-bindings/regulator/regulator.txt | 16 ++--
 drivers/power/pmic/pmic-uclass.c | 11 +--
 include/power/sandbox_pmic.h |  5 -
 test/dm/regulator.c  |  2 ++
 5 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/arch/sandbox/dts/sandbox_pmic.dtsi 
b/arch/sandbox/dts/sandbox_pmic.dtsi
index ce261b9..acb4799 100644
--- a/arch/sandbox/dts/sandbox_pmic.dtsi
+++ b/arch/sandbox/dts/sandbox_pmic.dtsi
@@ -75,4 +75,10 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+   no_match_by_nodename {
+   regulator-name = "buck_SUPPLY_1.5V";
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   };
 };
diff --git a/doc/device-tree-bindings/regulator/regulator.txt 
b/doc/device-tree-bindings/regulator/regulator.txt
index 918711e..65b69c4 100644
--- a/doc/device-tree-bindings/regulator/regulator.txt
+++ b/doc/device-tree-bindings/regulator/regulator.txt
@@ -2,7 +2,8 @@ Voltage/Current regulator
 
 Binding:
 The regulator devices don't use the "compatible" property. The binding is done
-by the prefix of regulator node's name. Usually the pmic I/O driver will 
provide
+by the prefix of regulator node's name, or, if this fails, by the prefix of the
+regulator's "regulator-name" property. Usually the pmic I/O driver will provide
 the array of 'struct pmic_child_info' with the prefixes and compatible drivers.
 The bind is done by calling function: pmic_bind_childs().
 Example drivers:
@@ -15,8 +16,19 @@ For the node name e.g.: "prefix[:alpha:]num { ... }":
 
 Example the prefix "ldo" will pass for: "ldo1", "ldo@1", "ldoreg@1, ...
 
+Binding by means of the node's name is preferred. However if the node names
+would produce ambiguous prefixes (like "regulator@1" and "regualtor@11") and 
you
+can't or do not want to change them then binding against the "regulator-name"
+property is possible. The syntax for the prefix of the "regulator-name" 
property
+is the same as the one for the regulator's node name.
+Use case: a regulator named "regulator@1" to be bound to a driver named
+"LDO_DRV" and a regulator named "regualator@11" to be bound to an other driver
+named "BOOST_DRV". Using prefix "regualtor@1" for driver matching would load
+the same driver for both regulators, hence the prefix is ambiguous.
+
 Optional properties:
-- regulator-name: a string, required by the regulator uclass
+- regulator-name: a string, required by the regulator uclass, used for driver
+  binding if binding by node's name prefix fails
 - regulator-min-microvolt: a minimum allowed Voltage value
 - regulator-max-microvolt: a maximum allowed Voltage value
 - regulator-min-microamp: a minimum allowed Current value
diff --git a/drivers/power/pmic/pmic-uclass.c b/drivers/power/pmic/pmic-uclass.c
index 64964e4..9347b40 100644
--- a/drivers/power/pmic/pmic-uclass.c
+++ b/drivers/power/pmic/pmic-uclass.c
@@ -26,6 +26,7 @@ int pmic_bind_children(struct udevice *pmic, ofnode parent,
struct driver *drv;
struct udevice *child;
const char *node_name;
+   const char *reg_name;
int bind_count = 0;
ofnode node;
int prefix_len;
@@ -44,8 +45,14 @@ int pmic_bind_children(struct udevice *pmic, ofnode parent,
debug("  - compatible prefix: '%s'\n", info->prefix);
 
prefix_len = strlen(info->prefix);
-   if (strncmp(info->prefix, node_name, prefix_len))
-   continue;
+   if (strncmp(info->prefix, node_name, prefix_len)) {
+   reg_name = ofnode_read_string(node,
+ "regulator-name");
+   if (!reg_name)
+   continue;
+   if (strncmp(info->prefix, reg_name, prefix_len))
+   continue;
+   }
 
drv = 

Re: [U-Boot] Problem with initialize in mmc_initialize in mmc.c

[Jaehoon Chung]

Hi Faiz,

On 11/02/2017 11:23 PM, Faiz Abbas wrote:
> 
> 
> On Monday 30 October 2017 07:37 PM, Faiz Abbas wrote:
>> Hi,
>>
>> The variable *initialized* in mmc_initialize() is declared as static and
>> initialised to 0 in the following commit. This makes the compiler put it
>> in the .bss section of the image.
>>
>> commit 1b26bab12e85e8b0d382d6775e40d14445249574
>> Author: Daniel Kochmański 
>> Date:   Fri May 29 16:55:43 2015 +0200
>>
>> mmc: Protect `mmc_initialize` from initialising mmc multiple times
>>
>> `mmc_initialize` might be called multiple times leading to the
>> mmc-controllers being initialised twice, and initialising the
>> `mmc_devices` list head twice which may lead to memory leaks.
>>
>> Signed-off-by: Daniel Kochmański 
>> CC: Roy Spliet 
>> Cc: Ian Campbell 
>> CC: Pantelis Antoniou 
>> Acked-by: Hans de Goede 
>> Signed-off-by: Hans de Goede 
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index da47037..f12546a 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -1762,6 +1762,11 @@ static void do_preinit(void)
>>
>>  int mmc_initialize(bd_t *bis)
>>  {
>> +   static int initialized = 0;
>> +   if (initialized)/* Avoid initializing mmc multiple times */
>> +   return 0;
>> +   initialized = 1;
>> +
>> INIT_LIST_HEAD (_devices);
>> cur_dev_num = 0;
>>
>>
>> .bss should not be accessed in u-boot before relocation because it
>> overlaps with fdt and writing to variables in .bss can corrupt the fdt.
>> MMC can be probed before relocation if it contains the u-boot
>> environment. Therefore, I tried to move this variable to the .data
>> section by

Will check with T32..but i didn't have seen about similar case..
You means it should be the multiple initializing?

Best Regards,
Jaehoon Chung

>>
>> static int initialized __attribute__((section(".data")));
>>
>> When *initialized* was a part of .bss it was getting re-initilized to 0
>> as a part of relocation. Therefore, mmc was getting probed again
>> successfully after relocation with new addresses for mmc devices.
>>
>> Now when *initialized* is not a part of .bss, it holds its value across
>> relocation and a second call to mmc_initialize() returns without doing
>> anything. However, the *mmc_devices* list containing pointers to the
>> older locations of mmc devices is not refreshed and thus mmc devices
>> fail to enumerate.
>>
>> So *initialized* is a problem whether it is in .data or .bss.
>> I am not sure how to fix this. Any help is appreciated.
> 
> I have been told that all pointers are supposed to be updated during
> relocation. Can anyone point to relevant code or example of the same?
> 
> Thanks,
> Faiz
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 

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

Re: [U-Boot] [PATCH v2 3/5] sunxi: Enable EMAC on the Cubietruck Plus

[Chen-Yu Tsai]

On Mon, Nov 27, 2017 at 4:09 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Sat, Nov 25, 2017 at 01:08:30PM +0800, Chen-Yu Tsai wrote:
>> The Cubietruck Plus has an RTL8211E PHY connected to the EMAC using
>> RGMII. The PHY is powered by DLDO4 @ 3.3V, while the I/O pins are
>> powered by DLDO3 @ 2.5V.
>>
>> This patch adds a U-boot specific dtsi file for the board adding
>> an enabled EMAC node, and enables the EMAC driver in the defconfig.
>> The binding used here is the old revision currently supported in
>> U-boot. The U-boot driver has not been updated to support the new
>> binding.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  .../arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi | 38 
>> ++
>>  configs/Cubietruck_plus_defconfig  |  2 ++
>>  2 files changed, 40 insertions(+)
>>  create mode 100644 arch/arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi
>>
>> diff --git a/arch/arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi 
>> b/arch/arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi
>> new file mode 100644
>> index ..4637e128f76e
>> --- /dev/null
>> +++ b/arch/arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi
>> @@ -0,0 +1,38 @@
>> +#include "sunxi-u-boot.dtsi"
>> +
>> +/ {
>> + aliases {
>> + ethernet0 = 
>> + };
>> +
>> + soc {
>> + emac: ethernet@01c3 {
>> + compatible = "allwinner,sun8i-a83t-emac";
>> + reg = <0x01c3 0x2000>, <0x01c00030 0x4>;
>> + reg-names = "emac", "syscon";
>> + interrupts = ;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins>;
>> + phy-mode = "rgmii";
>> + phy = <>;
>> + status = "okay";
>> +
>> + phy1: ethernet-phy@1 {
>> + reg = <1>;
>> + };
>> + };
>> + };
>> +};
>
> Now that we have a binding merged, can't we use that instead?

That is the next step. It's also why I have these in a U-boot
specific dtsi file. The driver is upgraded to support the now
official bindings, then we sync up the dts files and rip out
the u-boot stuff.

However I'm not sure when I'll get to that, and I'd like this
feature to be available for people that need might it, such as
the kernelci.org board farms.

>> + {
>> + rgmii_pins: rgmii_pins {
>> + allwinner,pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
>> +  "PD11", "PD12", "PD13", "PD14", "PD18",
>> +  "PD19", "PD21", "PD22", "PD23";
>> + allwinner,function = "emac";
>> + allwinner,drive = <3>;
>> + allwinner,pull = <0>;
>> + };
>> +};
>
> You should also use the new bindings here.

See above.

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

[U-Boot] [v2] armv8: ls1012a: enable/disable eSDHC1 through hwconfig for RDB

[Yangbo Lu]

For LS1012ARDB RevD and later versions, the I2C reading for DIP
switch setting had been no longer reliable since the board was
reworked. This patch is to add hwconfig support to enable/disable
eSDHC1 manually.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Just used hwconfig() instead of getenv() and hwconfig_f().
---
 board/freescale/ls1012ardb/ls1012ardb.c | 28 ++--
 1 file changed, 2 insertions(+), 26 deletions(-)

diff --git a/board/freescale/ls1012ardb/ls1012ardb.c 
b/board/freescale/ls1012ardb/ls1012ardb.c
index c6c1c71202..3e2b9c27eb 100644
--- a/board/freescale/ls1012ardb/ls1012ardb.c
+++ b/board/freescale/ls1012ardb/ls1012ardb.c
@@ -132,39 +132,15 @@ int board_init(void)
 
 int esdhc_status_fixup(void *blob, const char *compat)
 {
-   char esdhc0_path[] = "/soc/esdhc@156";
char esdhc1_path[] = "/soc/esdhc@158";
-   u8 io = 0;
-   u8 mux_sdhc2;
 
-   do_fixup_by_path(blob, esdhc0_path, "status", "okay",
-sizeof("okay"), 1);
-
-   i2c_set_bus_num(0);
-
-   /*
-* The I2C IO-expander for mux select is used to control the muxing
-* of various onboard interfaces.
-*
-* IO1[3:2] indicates SDHC2 interface demultiplexer select lines.
-*  00 - SDIO wifi
-*  01 - GPIO (to Arduino)
-*  10 - eMMC Memory
-*  11 - SPI
-*/
-   if (i2c_read(I2C_MUX_IO1_ADDR, 0, 1, , 1) < 0) {
-   printf("Error reading i2c boot information!\n");
-   return 0; /* Don't want to hang() on this error */
-   }
-
-   mux_sdhc2 = (io & 0x0c) >> 2;
-   /* Enable SDHC2 only when use SDIO wifi and eMMC */
-   if (mux_sdhc2 == 2 || mux_sdhc2 == 0)
+   if (hwconfig("esdhc1"))
do_fixup_by_path(blob, esdhc1_path, "status", "okay",
 sizeof("okay"), 1);
else
do_fixup_by_path(blob, esdhc1_path, "status", "disabled",
 sizeof("disabled"), 1);
+
return 0;
 }
 
-- 
2.14.1

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