Re: [PATCH 4/7] rockchip: Remove ARCH= references from documentation

2020-05-19 Thread klaus . goger

On 2020-05-19 16:51, Tom Rini wrote:
When building U-Boot we select the architecture via Kconfig and not 
ARCH

being passed in via the environment or make cmdline.

Cc: Kever Yang 
Cc: Simon Glass 
Cc: Philipp Tomsich 
Cc: Klaus Goger 
Cc: Jagan Teki 
Signed-off-by: Tom Rini 
---
As an aside, these files should be converted rST and moved to 
doc/board/

and the MAINTAINERS file updated to include the new documentation file
too.  Thanks!
---
 board/rockchip/evb_rk3229/README   | 1 -
 board/rockchip/evb_rk3399/README   | 1 -
 board/theobroma-systems/lion_rk3368/README | 4 ++--
 board/vamrs/rock960_rk3399/README  | 1 -
 4 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/board/rockchip/evb_rk3229/README 
b/board/rockchip/evb_rk3229/README

index 93328c75b204..9068225e2721 100644
--- a/board/rockchip/evb_rk3229/README
+++ b/board/rockchip/evb_rk3229/README
@@ -22,7 +22,6 @@ Compile the U-Boot

   > cd ../u-boot
   > export CROSS_COMPILE=arm-linux-gnueabihf-
-  > export ARCH=arm
   > make evb-rk3229_defconfig
   > make
   > make u-boot.itb
diff --git a/board/rockchip/evb_rk3399/README 
b/board/rockchip/evb_rk3399/README

index da7ae89ab1e9..c6f58203ebe9 100644
--- a/board/rockchip/evb_rk3399/README
+++ b/board/rockchip/evb_rk3399/README
@@ -54,7 +54,6 @@ Compile U-Boot
 ==

   > cd ../u-boot
-  > export ARCH=arm64
   > export CROSS_COMPILE=aarch64-linux-gnu-
   > make evb-rk3399_defconfig
   for firefly-rk3399, use below instead:
diff --git a/board/theobroma-systems/lion_rk3368/README
b/board/theobroma-systems/lion_rk3368/README
index ad3ac93bd44b..7488b18326b9 100644
--- a/board/theobroma-systems/lion_rk3368/README
+++ b/board/theobroma-systems/lion_rk3368/README
@@ -17,12 +17,12 @@ Configure U-Boot
 Build the TPL/SPL stage
 ===

-  > make CROSS_COMPILE=aarch64-unknown-elf- ARCH=arm
+  > make CROSS_COMPILE=aarch64-unknown-elf-

 Build the full U-Boot and a FIT image including the ATF
 ===

-  > make CROSS_COMPILE=aarch64-unknown-elf- ARCH=arm u-boot.itb
+  > make CROSS_COMPILE=aarch64-unknown-elf- u-boot.itb

 Flash the image
 ===
diff --git a/board/vamrs/rock960_rk3399/README
b/board/vamrs/rock960_rk3399/README
index c5c675c4ead1..15df027fbcd4 100644
--- a/board/vamrs/rock960_rk3399/README
+++ b/board/vamrs/rock960_rk3399/README
@@ -57,7 +57,6 @@ Compile the U-Boot

   > cd ../u-boot
   > cp ../rkbin/rk33/rk3399_bl31_v1.00.elf ./bl31.elf
-  > export ARCH=arm64
   > export CROSS_COMPILE=aarch64-linux-gnu-
   > make rock960-rk3399_defconfig
   > make


Reviewed-by: Klaus Goger 

Thanks for the hint about converting to rST. Will send patches
for at least the boards that list me as maintainer.

Best,
Klaus



Re: [U-Boot] [PATCH] rockchip: rk3399-puma: support Gigadevice SPI-NOR flash

2019-02-03 Thread klaus . goger

On 2019-02-03 15:59, Philipp Tomsich wrote:

Over the last quarter, a part of our production has used NOR flash
from Gigadevice in addition to the Winbond parts that we typically
source.  This requires the SPI_FLASH_GIGADEVICE config to be set.

Enable SPI_FLASH_GIGADEVICE in the board's default defconfig.

Signed-off-by: Philipp Tomsich 
---

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

diff --git a/configs/puma-rk3399_defconfig 
b/configs/puma-rk3399_defconfig

index 3fcff25..9b4bfaf 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -67,6 +67,7 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_MMC_SDHCI_ROCKCHIP=y
 CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y


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


Re: [U-Boot] about rk3399 boot speed

2018-12-03 Thread klaus . goger

Hi Kever,

I can confirm that current master behaves the same on Puma.
For a fix please take a look at:
https://patchwork.ozlabs.org/patch/1003412/

On 2018-12-04 04:04, Kever Yang wrote:

Hi Philipp,

    When I test on firefly-rk3399 with latest mainline U-Boot, it boots
very very slow,

and it's due to the first time of cru driver bind(U-Boot proper) and 
the

clk_set_defaults() cost about 5S.

    Does puma board has the same problem?


Thanks,

- Kever

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


Re: [U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

2018-11-29 Thread Klaus Goger
Wadim, sorry for missing that you already commented in the thread. Threading 
doesn’t work that well on mobile if I’m not CC’ed.

So it looks like we want to keep the BootROM behaviour for at least the 
Rockchip based SoMs. Let’s see if Simon has an opinion regarding the 
Chromebooks.

> On 29.11.2018, at 23:01, Klaus Goger  
> wrote:
> 
> Adding Wadim as he will most likely has something to add to the discussion 
> too.
> 
> Kever,
> 
> I understand your SBC viewpoint especially in terms of developer. But as 
> Philipp already laid out the usage in the SoM and enduser products might be 
> different and changing defaults may have a big impact. So while I don’t have 
> a problem in changing the behaviour we should have a consense for all 
> usecases and define if we want to have it global or a board basis for 
> backwarts compatibility.
> 
> Thanks,
> Klaus
> 
>> On 29.11.2018, at 22:44, Philipp Tomsich 
>>  wrote:
>> 
>> 
>> 
>>>> With this patch, people can use firmware in SD card if they want;
>>>> Without this patch, people never able to use firmware in SD card if eMMC
>>>> firmware exist (even if it's broken).
>>> 
>>> Most boards I know have the ability to bypass the internal eMMC.
>> 
>> One last thing: I know a number of projects developing devices using our
>> modules that have a SD card slot for data exchange (e.g. config data, log
>> files, data acquisition and export) but that don’t want endusers to boot the
>> device from the SD card (possibly using unauthorized firmware).
>> 
>> For factory use, there’s a signal on the mainboard to disable (until turned
>> back on by software) the on-module eMMC and (if available) SPI to allow
>> booting from the external SD card.  For field use, this signal is 
>> unaccessible
>> and can not be asserted…
>> 
>> Hope this provides one example to how different use cases can play out...
>> 
>> Thanks,
>> Philipp.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RESENT PATCH v3] rockchip: update emmc/sd index for distro boot order

2018-11-29 Thread Klaus Goger
Adding Wadim as he will most likely has something to add to the discussion too.

Kever,

I understand your SBC viewpoint especially in terms of developer. But as 
Philipp already laid out the usage in the SoM and enduser products might be 
different and changing defaults may have a big impact. So while I don’t have a 
problem in changing the behaviour we should have a consense for all usecases 
and define if we want to have it global or a board basis for backwarts 
compatibility.

Thanks,
Klaus

> On 29.11.2018, at 22:44, Philipp Tomsich 
>  wrote:
> 
> 
> 
>>> With this patch, people can use firmware in SD card if they want;
>>> Without this patch, people never able to use firmware in SD card if eMMC
>>> firmware exist (even if it's broken).
>> 
>> Most boards I know have the ability to bypass the internal eMMC.
> 
> One last thing: I know a number of projects developing devices using our
> modules that have a SD card slot for data exchange (e.g. config data, log
> files, data acquisition and export) but that don’t want endusers to boot the
> device from the SD card (possibly using unauthorized firmware).
> 
> For factory use, there’s a signal on the mainboard to disable (until turned
> back on by software) the on-module eMMC and (if available) SPI to allow
> booting from the external SD card.  For field use, this signal is unaccessible
> and can not be asserted…
> 
> Hope this provides one example to how different use cases can play out...
> 
> Thanks,
> Philipp.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1] rockchip: utilize CONFIG_DEFAULT_FDT_FILE

2018-06-22 Thread klaus . goger


> On 22.06.2018, at 16:23, Vagrant Cascadian  wrote:
> 
> On 2018-05-27, Vagrant Cascadian wrote:
>> On 2018-05-25, Klaus Goger wrote:
>>> Currently the fdtfile environment variable is set to
>>> CONFIG_DEFAULT_DEVICE_TREE which is іnternally used as U-Boot devicetree
>>> source. The OS can use a different filename and Kconfig gives us the
>>> ability to select a default devicetree via CONFIG_DEFAULT_FDT_FILE.
>>> This also gives user configuring U-Boot via menuconfig the behaviour
>>> someone would expect.
> ...
>> Tested on puma-rk3399.
>> 
>> Tested-By: Vagrant Cascadian 
>> 
>> Was hoping to also test on firefly-rk3399, but having difficulty getting
>> u-boot installed unreleated to this patch.
> 
> Finally was able to test on Firefly-RK3399 applied against u-boot
> 2018.07-rc2, and it also works correctly.
> 
> Are there any outstanding concerns with this patch?

There was a similar patch for sunxi[1] and there it was decided to introduce
the Kconfig option we talked about. That would make this patch obsolete.

@Jagan, I think Martin is still waiting for an answer from you.

[1] https://patchwork.ozlabs.org/patch/923692/


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


Re: [U-Boot] [PATCH] sunxi: use CONFIG_DEFAULT_FDT_FILE everywhere

2018-05-31 Thread klaus . goger


> On 01.06.2018, at 02:59, Martin Kelly  wrote:
> 
> Currently, sunxi-common.h ignores CONFIG_DEFAULT_FDT_FILE and assumes
> the kernel fdtfile and the u-boot devicetree names are the same.
> Although this is typically the case, sometimes you might want to
> customize one of these differently, so it's useful to allow them to be
> different.
> 
> Fix this to use only CONFIG_DEFAULT_FDT_FILE as other boards do, and set
> CONFIG_DEFAULT_FDT_FILE in board files to be the same as the current
> fdtfile= setting.
> 
> Signed-off-by: Martin Kelly 
> ---
> This patch is against u-boot master and thus conflicts with u-boot sunxi patch
> 31510b41f6b736fd03e2779a2585f85df39e667f ("sunxi: allow 
> CONFIG_DEFAULT_FDT_FILE
> override"). If you would like me to apply this against the sunxi tree 
> instead, I
> would be happy to do so and resend it.
> 
> Obviously, I cannot test a change like this on every board. Here's the tests I
> did:
> 
> - Booted on the nanopi neo plus2 (the board I do have).
> - Compile-tested every affected config.
> - To avoid missing anything I generated the config changes with the following
>  Python script. This script mimics what the preprocessor was doing, but 
> encodes
>  it explicitly in the config. Reviewing the script is probably easier than
>  reviewing each individual file:
> 
> #!/usr/bin/python3
> 
> import os
> 
> root = '/home/martin/u-boot/configs'
> for name in os.listdir(root):
>path = os.path.join(root, name)
>with open(path, 'r') as f:
>contents = f.read()
>if 'CONFIG_ARCH_SUNXI=y' not in contents:
>continue
>if 'CONFIG_DEFAULT_FDT_FILE=' in contents:
># Make the script idempotent.
>continue
> 
>if 'CONFIG_MACH_SUN50I=y' in contents or 'CONFIG_MACH_SUN50I_H5=y' in 
> contents:
>arm64 = True
>else:
>arm64 = False
> 
>lines = []
>for line in contents.split('\n'):
>if line.startswith('CONFIG_DEFAULT_DEVICE_TREE='):
>split = line.split('=')
>assert(len(split) == 2)
>dtb = split[1]
> 
>if dtb[0] == '"' and dtb[-1] == '"':
># Dequotify.
>dtb = dtb[1:-1]
> 
>dtb = '%s.dtb' % dtb
>if arm64:
>dtb = 'allwinner/%s' % dtb
> 
>lines.append('CONFIG_DEFAULT_FDT_FILE="%s"' % dtb)
>lines.append(line)
> 
>with open(path, 'w') as f:
>f.write('\n'.join(lines))
> 
> [end script]

Looks fine to me.
My only note would be that your script adds CONFIG_DEFAULT_FDT_FILE at a 
different
line as when generated by savedefconfig.

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


Re: [U-Boot] [PATCH] sunxi: allow CONFIG_DEFAULT_FDT_FILE override

2018-05-31 Thread klaus . goger


> On 31.05.2018, at 21:48, Martin Kelly  wrote:
> 
> On 05/31/2018 11:15 AM, klaus.go...@theobroma-systems.com wrote:
>> Hi Martin,
>>> On 31.05.2018, at 19:49, Martin Kelly  wrote:
>>> 
>>> On 05/23/2018 11:34 AM, Martin Kelly wrote:
 On 05/17/2018 05:01 AM, Maxime Ripard wrote:
> On Tue, May 01, 2018 at 05:46:41PM -0700, Martin Kelly wrote:
>> Currently, sunxi-common.h ignores CONFIG_DEFAULT_FDT_FILE and assumes
>> the kernel fdtfile and the u-boot devicetree names are the same.
>> Although this is typically the case, sometimes you might want to
>> customize one of these differently, so it's useful to allow them to be
>> different.
>> 
>> Add logic in sunxi-common.h to respect CONFIG_DEFAULT_FDT_FILE, if set,
>> and default to the values it currently uses.
>> 
>> Signed-off-by: Martin Kelly 
> 
> Acked-by: Maxime Ripard 
> 
> Maxime
> 
 (ping)
>>> 
>>> (ping again)
>>> 
>>> Can we get this patch merged?
>> The else branch will never be selected.
>> CONFIG_DEFAULT_FDT_FILE will be set to “” if not set by your defconfig.
> 
> Thanks for noticing this; unfortunately you are right. I thought I tested 
> this, but it was in the context of a larger build and I missed it.
> 
> It looks like we have two options:
> 
> (a) Test for empty string in preprocessor language. This is quite ugly and 
> has some gotchas but should be doable (e.g. 
> https://stackoverflow.com/questions/3781520/how-to-test-if-preprocessor-symbol-is-defined-but-has-no-value).
> 
> (b) Always use the value of CONFIG_DEFAULT_FDT_FILE and stop using 
> CONFIG_DEFAULT_DEVICE_TREE as a default. In each board file, explicitly set 
> CONFIG_DEFAULT_FDT_FILE to its current default. This is what other boards are 
> doing.
> 
> I favor (b). If others are in favor, I'll submit a patch for it.

I run into the same issue for the rockchip architecture[1]. After giving up on 
finding a 
rock-solid solution for detecting the emtpy string I decided to go with your 
option (b).
Another solution would be to hide CONFIG_DEFAULT_DEVICE_TREE behind a 
Kconfig bool so it would not be defined until something like CONFIG_FDT_FILE is 
selected. But in favour of having U-Boot devicetree decoupled from any OS fdt I 
still prefer option (b).

[1] https://patchwork.ozlabs.org/patch/920785/


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


Re: [U-Boot] [PATCH] sunxi: allow CONFIG_DEFAULT_FDT_FILE override

2018-05-31 Thread klaus . goger
Hi Martin,

> On 31.05.2018, at 19:49, Martin Kelly  wrote:
> 
> On 05/23/2018 11:34 AM, Martin Kelly wrote:
>> On 05/17/2018 05:01 AM, Maxime Ripard wrote:
>>> On Tue, May 01, 2018 at 05:46:41PM -0700, Martin Kelly wrote:
 Currently, sunxi-common.h ignores CONFIG_DEFAULT_FDT_FILE and assumes
 the kernel fdtfile and the u-boot devicetree names are the same.
 Although this is typically the case, sometimes you might want to
 customize one of these differently, so it's useful to allow them to be
 different.
 
 Add logic in sunxi-common.h to respect CONFIG_DEFAULT_FDT_FILE, if set,
 and default to the values it currently uses.
 
 Signed-off-by: Martin Kelly 
>>> 
>>> Acked-by: Maxime Ripard 
>>> 
>>> Maxime
>>> 
>> (ping)
> 
> (ping again)
> 
> Can we get this patch merged?

The else branch will never be selected.
CONFIG_DEFAULT_FDT_FILE will be set to “” if not set by your defconfig.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1] rockchip: utilize CONFIG_DEFAULT_FDT_FILE

2018-05-27 Thread klaus . goger


> On 27.05.2018, at 21:16, Vagrant Cascadian <vagr...@debian.org> wrote:
> 
> On 2018-05-25, Klaus Goger wrote:
>> Currently the fdtfile environment variable is set to
>> CONFIG_DEFAULT_DEVICE_TREE which is іnternally used as U-Boot devicetree
>> source. The OS can use a different filename and Kconfig gives us the
>> ability to select a default devicetree via CONFIG_DEFAULT_FDT_FILE.
>> This also gives user configuring U-Boot via menuconfig the behaviour
>> someone would expect.
> 
> I did wonder, given that many of these boards the value for
> CONFIG_DEFAULT_DEVICE_TREE and CONFIG_DEFAULT_FDT_FILE is *nearly*
> identical, if it wouldn't make sense to derive CONFIG_DEFAULT_FDT_FILE
> From the value of CONFIG_DEFAULT_DEVICE_TREE by default, only overriding
> it in the unusual cases.
> 
> Though there is a lot to be said about being explicit and not mixing the
> two similar but not identical values.

Would love to to that, but couldn’t find a proper way to do it.
CONFIG_DEFAULT_FDT_FILE is a Kconfig string and therefore always present in the 
.config.
If not set by the user or a defconfig it’s just a empty string (“”). So we 
can’t do a #ifdef and we can’t
do string compares with C macros. An option would be to have DEFAULT_FDT_FILE 
be hidden
behind a Kconfig bool (i.e CONFIG_DEFAULT_FDT_FILE depends on CONFIG_FDT_FILE)
But that change looked a bit to invasive for me.

> Tested on puma-rk3399.
> 
> Tested-By: Vagrant Cascadian <vagr...@debian.org>
> 
> Was hoping to also test on firefly-rk3399, but having difficulty getting
> u-boot installed unreleated to this patch. Also having troubles with
> firefly-rk3288 due to mmc hanging the board: https://bugs.debian.org/898520.
> 
> 
> live well,
>  vagrant
> 
>> configs/puma-rk3399_defconfig   | 1 +
>> include/configs/rk3399_common.h | 2 +-
> 
>> diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
>> index e6539a7da8..e5753b4f20 100644
>> --- a/configs/puma-rk3399_defconfig
>> +++ b/configs/puma-rk3399_defconfig
>> @@ -16,6 +16,7 @@ CONFIG_DEBUG_UART=y
>> CONFIG_FIT=y
>> CONFIG_SPL_LOAD_FIT=y
>> CONFIG_SPL_FIT_SOURCE="board/theobroma-systems/puma_rk3399/fit_spl_atf.its"
>> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-puma-haikou.dtb"
>> # CONFIG_DISPLAY_CPUINFO is not set
>> CONFIG_DISPLAY_BOARDINFO_LATE=y
>> CONFIG_SPL_BOARD_INIT=y
> 
>> diff --git a/include/configs/rk3399_common.h 
>> b/include/configs/rk3399_common.h
>> index a61e74bc03..ee38107ea5 100644
>> --- a/include/configs/rk3399_common.h
>> +++ b/include/configs/rk3399_common.h
>> @@ -55,7 +55,7 @@
>> #include 
>> #define CONFIG_EXTRA_ENV_SETTINGS \
>>  ENV_MEM_LAYOUT_SETTINGS \
>> -"fdtfile=rockchip/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
>> +"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
>>  "partitions=" PARTS_DEFAULT \
>>  BOOTENV
>> 
>> --
>> 2.11.0



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


[U-Boot] [PATCH v1] rockchip: utilize CONFIG_DEFAULT_FDT_FILE

2018-05-25 Thread Klaus Goger
Currently the fdtfile environment variable is set to
CONFIG_DEFAULT_DEVICE_TREE which is іnternally used as U-Boot devicetree
source. The OS can use a different filename and Kconfig gives us the
ability to select a default devicetree via CONFIG_DEFAULT_FDT_FILE.
This also gives user configuring U-Boot via menuconfig the behaviour
someone would expect.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>

---

 configs/chromebit_mickey_defconfig  | 1 +
 configs/chromebook_jerry_defconfig  | 1 +
 configs/chromebook_minnie_defconfig | 1 +
 configs/evb-px5_defconfig   | 1 +
 configs/evb-rk3036_defconfig| 1 +
 configs/evb-rk3128_defconfig| 1 +
 configs/evb-rk3229_defconfig| 1 +
 configs/evb-rk3288_defconfig| 1 +
 configs/evb-rk3328_defconfig| 1 +
 configs/evb-rk3399_defconfig| 1 +
 configs/evb-rv1108_defconfig| 1 +
 configs/fennec-rk3288_defconfig | 1 +
 configs/firefly-rk3288_defconfig| 1 +
 configs/firefly-rk3399_defconfig| 1 +
 configs/geekbox_defconfig   | 1 +
 configs/kylin-rk3036_defconfig  | 1 +
 configs/lion-rk3368_defconfig   | 1 +
 configs/miqi-rk3288_defconfig   | 1 +
 configs/phycore-rk3288_defconfig| 1 +
 configs/popmetal-rk3288_defconfig   | 1 +
 configs/puma-rk3399_defconfig   | 1 +
 configs/rock2_defconfig | 1 +
 configs/rock_defconfig  | 1 +
 configs/sheep-rk3368_defconfig  | 1 +
 configs/tinker-rk3288_defconfig | 1 +
 configs/vyasa-rk3288_defconfig  | 1 +
 include/configs/rk3036_common.h | 1 +
 include/configs/rk3128_common.h | 1 +
 include/configs/rk3188_common.h | 1 +
 include/configs/rk322x_common.h | 1 +
 include/configs/rk3288_common.h | 2 +-
 include/configs/rk3328_common.h | 1 +
 include/configs/rk3368_common.h | 1 +
 include/configs/rk3399_common.h | 2 +-
 34 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/configs/chromebit_mickey_defconfig 
b/configs/chromebit_mickey_defconfig
index d1728ef639..27b0dcaac4 100644
--- a/configs/chromebit_mickey_defconfig
+++ b/configs/chromebit_mickey_defconfig
@@ -11,6 +11,7 @@ CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-mickey"
 CONFIG_DEBUG_UART=y
 # CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_DEFAULT_FDT_FILE="rk3288-veyron-mickey.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
diff --git a/configs/chromebook_jerry_defconfig 
b/configs/chromebook_jerry_defconfig
index 43d93f4637..95fe4bcb26 100644
--- a/configs/chromebook_jerry_defconfig
+++ b/configs/chromebook_jerry_defconfig
@@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-jerry"
 CONFIG_DEBUG_UART=y
 # CONFIG_ANDROID_BOOT_IMAGE is not set
 CONFIG_SILENT_CONSOLE=y
+CONFIG_DEFAULT_FDT_FILE="rk3288-veyron-jerry.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_F=y
diff --git a/configs/chromebook_minnie_defconfig 
b/configs/chromebook_minnie_defconfig
index 706809ca53..bc3bb292c8 100644
--- a/configs/chromebook_minnie_defconfig
+++ b/configs/chromebook_minnie_defconfig
@@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-minnie"
 CONFIG_DEBUG_UART=y
 # CONFIG_ANDROID_BOOT_IMAGE is not set
 CONFIG_SILENT_CONSOLE=y
+CONFIG_DEFAULT_FDT_FILE="rk3288-veyron-minnie.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
diff --git a/configs/evb-px5_defconfig b/configs/evb-px5_defconfig
index c03682c927..a75c3e047f 100644
--- a/configs/evb-px5_defconfig
+++ b/configs/evb-px5_defconfig
@@ -7,6 +7,7 @@ CONFIG_TARGET_EVB_PX5=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3368-px5-evb"
 CONFIG_DEBUG_UART=y
 CONFIG_ANDROID_BOOT_IMAGE=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3368-px5-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_ARCH_EARLY_INIT_R=y
diff --git a/configs/evb-rk3036_defconfig b/configs/evb-rk3036_defconfig
index 33775e8cdd..840c731032 100644
--- a/configs/evb-rk3036_defconfig
+++ b/configs/evb-rk3036_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3036-sdk"
 CONFIG_DEBUG_UART=y
 CONFIG_SPL_SYS_MALLOC_F_LEN=0x0
 # CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_DEFAULT_FDT_FILE="rk3036-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 # CONFIG_SPL_FRAMEWORK is not set
diff --git a/configs/evb-rk3128_defconfig b/configs/evb-rk3128_defconfig
index 796d0ec92e..f4b132faf7 100644
--- a/configs/evb-rk3128_defconfig
+++ b/configs/evb-rk3128_defconfig
@@ -5,6 +5,7 @@ CONFIG_ROCKCHIP_RK3128=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3128-evb"
 CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
+CONFIG_DEFAULT_FDT_FILE="rk3128-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_FASTBOOT_BUF_ADDR=0x60800800
diff --git a/configs/ev

Re: [U-Boot] U-Boot thumb interlink patches

2018-05-25 Thread klaus . goger
Hi Tom,

> On 25.05.2018, at 14:01, Tom Rini  wrote:
> 
> Hey guys,
> 
> So, I want to be sure that I get all of the patches that we need in
> order to fix the thumb interlink problems on older ARM cores applied.
> 
> I believe that we have:
> https://patchwork.ozlabs.org/patch/905299/

Applied on todays master and tested with a Thumb build of a mxs U-Boot.

> Which could still apply, but I'm wondering if the kernel needs this as
> well then (in arch/arm/lib/copy_template.S) ?

Can’t say by just looking at it. And since I did this patches while working
on a ARM926EJS I can’t test it on that board as Linux requires ARMv7(M)
to build a Thumb2 only kernel. Will try it once I’m in front of a suitable
board again. Thanks for the hint.

> And then:
> https://patchwork.ozlabs.org/patch/909652/
> 
> has been reviewed and could be applied.  Is there anything else I'm
> missing?  Thanks!
> 
> --
> Tom



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


Re: [U-Boot] Bug#897671: u-boot does not work on sheevaplug

2018-05-09 Thread klaus . goger


> On 09.05.2018, at 10:19, Markus Krebs  wrote:
> 
> Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:
>> On 2018-05-08, Vagrant Cascadian wrote:
>>> On 2018-05-05, Tom Rini wrote:
 On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
> Markus Krebs discovered that the sheevaplug target has again grown and
> installation overlaps where the u-boot env is saved since u-boot
> ~2017.09. Running saveenv overwrites u-boot, and installing u-boot
> overwrites any prior environment settings.
>> ...
 I've added the maintainer to the list as well.  I would suggest looking
 for things to trim out, perhaps CMD_MEMTEST ?
>>> 
>>> Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
>>> EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
>>> *lot* left to disable in the config, but that's a significant start...
>> And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
>> down to 432k! Thanks to beeble for the suggestion.
>> Anyone who has a sheevaplug can test that it actually boots with
>> CONFIG_SYS_THUMB_BUILD=y enabled?
> 
> I could test it, but I don't know the config-file where I can change those 
> options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).

Both are Kconfig options. So just disable it via menuconfig or in your .config 
file
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/5] ARM: arm926ejs: fix lowlevel_init call

2018-05-07 Thread klaus . goger


> On 07.05.2018, at 10:25, Chris Packham  wrote:
> 
> Hi Mans, Stefano,
> 
> On Fri, Apr 27, 2018 at 9:00 PM Stefano Babic  wrote:
> 
>> On 21/04/2018 17:11, Mans Rullgard wrote:
>>> The code attempts to preserve the value of LR by storing it in R12/IP
>>> across the lowevel_init() call.  However, this register is not saved
>>> by the callee.  Use a register that guaranteed to be preserved instead.
>>> 
>>> Signed-off-by: Mans Rullgard 
>>> ---
>>> arch/arm/cpu/arm926ejs/start.S | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/arch/arm/cpu/arm926ejs/start.S
> b/arch/arm/cpu/arm926ejs/start.S
>>> index 959d1ed86d8a..a6f0bdb70345 100644
>>> --- a/arch/arm/cpu/arm926ejs/start.S
>>> +++ b/arch/arm/cpu/arm926ejs/start.S
>>> @@ -105,9 +105,9 @@ flush_dcache:
>>>  /*
>>>   * Go setup Memory and board specific bits prior to relocation.
>>>   */
>>> - mov ip, lr  /* perserve link reg across call */
>>> + mov r4, lr  /* perserve link reg across call */
>>>  bl  lowlevel_init   /* go setup pll,mux,memory */
>>> - mov lr, ip  /* restore link */
>>> + mov lr, r4  /* restore link */
>>> #endif
>>>  mov pc, lr  /* back to my caller */
>>> #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
>>> 
> 
>> Applied to u-boot-imx, thanks !
> 
> I think this might be causing me a problem on a Marvell Kirkwood board I'm
> working on getting into upstream. It may also be problematic for orion5x
> boards. Both of these use r4 in lowlevel_init.
> 
> Obviously I can fix the board that I'm working on. Is there some
> expectation as to which registers can be clobbered?

The "Procedure Call Standard for the ARM® Architecture” may help:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf
Page 15

   A subroutine must preserve the contents of the registers r4-r8, r10, r11 and
   SP (and r9 in PCS variants that designate r9 as v6).

So for thumb r1-r3 and r12 should be usable  without taking any care of them.
Maybe r13 depending if you already have a stack or not. 

Regards,
Klaus

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


Re: [U-Boot] [PATCH 2/3] rockchip: add support for veyron-speedy (ASUS Chromebook C201)

2018-05-06 Thread klaus . goger

> On 06.05.2018, at 16:25, Marty E. Plummer  wrote:
> 
> This adds support for the ASUS C201, a RK3288-based clamshell
> device. The device tree comes from linus's linux tree at
> 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539. The SDRAM parameters
> are for 4GB Samsung LPDDR3, decoded from coreboot's
> src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc
> 
> Signed-off-by: Marty E. Plummer 
> ---
> arch/arm/dts/Makefile |   1 +
> arch/arm/dts/rk3288-veyron-speedy.dts | 189 ++
> arch/arm/mach-rockchip/rk3288-board-spl.c |   3 +-
> arch/arm/mach-rockchip/rk3288/Kconfig |  11 ++
> board/google/veyron/Kconfig   |  16 ++
> configs/chromebook_speedy_defconfig   |  96 +++
> 6 files changed, 315 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
> create mode 100644 configs/chromebook_speedy_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index ac7667b1e8..ee04d9bedd 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3288-veyron-jerry.dtb \
>   rk3288-veyron-mickey.dtb \
>   rk3288-veyron-minnie.dtb \
> + rk3288-veyron-speedy.dtb \
>   rk3288-vyasa.dtb \
>   rk3328-evb.dtb \
>   rk3368-lion.dtb \
> diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts 
> b/arch/arm/dts/rk3288-veyron-speedy.dts
> new file mode 100644
> index 00..d5383cef0d
> --- /dev/null
> +++ b/arch/arm/dts/rk3288-veyron-speedy.dts

This file looks quite different then the one I see on kernel.org with that 
revision id. So you are sure you
imported that one?

> @@ -0,0 +1,189 @@
> +/*
> + * Google Veyron Speedy Rev 1+ board device tree source
> + *
> + * Copyright 2015 Google, Inc
> + *
> + * SPDX-License-Identifier:  GPL-2.0

This file is dual licensed upstream, keep it that way.
The comment will claim it’s a X11 license but the license text below
is actually MIT so you may want to use the MIT SPDX tag for that.

> + */
> +
> +/dts-v1/;
> +#include "rk3288-veyron-chromebook.dtsi"
> +#include "cros-ec-sbs.dtsi"
> +
> +/ {
> + model = "Google Speedy";
> + compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
> +  "google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
> +  "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
> +  "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> +  "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> +
> + chosen {
> + stdout-path = 
> + };
> +
> + panel_regulator: panel-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_enable_h>;
> + regulator-name = "panel_regulator";
> + startup-delay-us = <10>;
> + vin-supply = <_sys>;
> + };
> +
> + vcc18_lcd: vcc18-lcd {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = < RK_PB5 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_1v8_disp_en>;
> + regulator-name = "vcc18_lcd";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <_wl>;
> + };
> +
> + backlight_regulator: backlight-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = < RK_PB4 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pwr_en>;
> + regulator-name = "backlight_regulator";
> + vin-supply = <_sys>;
> + startup-delay-us = <15000>;
> + };
> +};
> +
> + {
> + rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
> + 0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
> + 0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
> + 0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
> + 0x8 0x1f4>;
> + rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
> + 0x0 0xc3 0x6 0x1>;
> + rockchip,sdram-params = <0x20D266A4 0x5B6 6 53300 6 13 0>;
> +};

Not sure if this should go into a separate dtsi. One of the maintainer will have
a preferred way I think, so lets see what they will add.

> +_keys {
> + power {
> + gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> + {
> + power-supply = <_regulator>;
> +};
> +
> + {
> + power-supply = <_regulator>;
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_int_l>;
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_clk _cmd _cd_disabled _cd_gpio
> + _bus4>;
> + disable-wp;
> +};
> +
> +_5v {
> 

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

2018-05-06 Thread klaus . goger

> On 06.05.2018, at 22:03, Marty E. Plummer  wrote:
> 
> On Sun, May 06, 2018 at 02:08:25PM -0500, Marty E. Plummer wrote:
>>> On Sun, May 06, 2018 at 08:39:23PM +0200, klaus.go...@theobroma-systems.com 
>>> wrote:
 On 06.05.2018, at 16:25, Marty E. Plummer  wrote:
 +   * we use the 0x~0xfeff space
 +   * since 0xff00~0x is soc register space
 +   * so we reserve it 
 +   */
>>> 
>>> That's not true for all Rockchip SoCs. On the RK3399 for example the upper 
>>> limit 
>>> is 0xf800. Even on the RK3288 DRAM address range is actually
>>> 0x-0xfe0
>>> 
 +  size_mb = min(size_mb, 0xff00/SZ_1M);
}
>>> 
>>> Should be 0xfe00 (4G-32MB) for RK3288.
>>> But there is already a define for that, SDRAM_MAX_SIZE is defined in
>>> rkxxx_common.h. Using that one would help to avoid possible breakage
>>> of other Rockchip SoCs.
>>> 
>> Oh, does that get #defined properly for each SoC? if so, I'll sub that
>> in for better compat.
> In fact, could you or someone else help me to understand the #include
> chain here? I'm not certain as to what that is available in each header
> mentioned can be used in this file to get max compat across the rockchip
> lineup, and I don't want to break someone elses board/etc with something
> that 'works for me’.

You can get a full list of included headers by adding the -H file to the gcc 
command line.
make V=1 will help you to see how it’s called on your system.

In that particular case the relevant include chain is:
. include/common.h
.. include/config.h
... include/configs/popmetal_rk3288.h
 include/configs/rk3288_common.h

So the correct rk3xxx_common.h will be selected by config.h and SDRAM_MAX_SIZE
is defined in all of them. 

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


Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

2018-05-06 Thread klaus . goger
CC Philipp and Simon due maintainership (you may want to use get_maintainer.pl 
in the future)
and Kever as the original author of the file.

> On 06.05.2018, at 16:25, Marty E. Plummer  wrote:
> 
> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> 
> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
> is incorrectly detected as 0 Bytes of ram.
> 
> Signed-off-by: Marty E. Plummer 
> ---
> arch/arm/mach-rockchip/sdram_common.c | 62 ---
> 1 file changed, 37 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
> b/arch/arm/mach-rockchip/sdram_common.c
> index 76dbdc8715..a9c9f970a4 100644
> --- a/arch/arm/mach-rockchip/sdram_common.c
> +++ b/arch/arm/mach-rockchip/sdram_common.c
> @@ -10,6 +10,8 @@
> #include 
> #include 
> #include 
> +#include 
> +#include 

Is adding these headers really necessary?
common.h already includes kernel.h and sizes.h (with some redirections of 
config.h)

> DECLARE_GLOBAL_DATA_PTR;
> size_t rockchip_sdram_size(phys_addr_t reg)
> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>   size_t size_mb = 0;
>   u32 ch;
> 
> - u32 sys_reg = readl(reg);
> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> -& SYS_REG_NUM_CH_MASK);
> + if (!size_mb) {

Is this really required? I don’t see a way that size_mb will already be set at 
this point.
But it blows up your diff that it takes quite a while to see that your only 
real change is 
the size_mb = min(...) part at the end.

> - debug("%s %x %x\n", __func__, (u32)reg, sys_reg);
> - for (ch = 0; ch < ch_num; ch++) {
> - rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) &
> - SYS_REG_RANK_MASK);
> - col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) & SYS_REG_COL_MASK);
> - bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
> - cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) &
> - SYS_REG_CS0_ROW_MASK);
> - cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) &
> - SYS_REG_CS1_ROW_MASK);
> - bw = (2 >> ((sys_reg >> SYS_REG_BW_SHIFT(ch)) &
> - SYS_REG_BW_MASK));
> - row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
> - SYS_REG_ROW_3_4_MASK;
> + u32 sys_reg = readl(reg);
> + u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> +& SYS_REG_NUM_CH_MASK);
> 
> - chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
> + debug("%s %x %x\n", __func__, (u32)reg, sys_reg);
> + for (ch = 0; ch < ch_num; ch++) {
> + rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) &
> + SYS_REG_RANK_MASK);
> + col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) & 
> SYS_REG_COL_MASK);
> + bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) & 
> SYS_REG_BK_MASK);
> + cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) &
> + SYS_REG_CS0_ROW_MASK);
> + cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) &
> + SYS_REG_CS1_ROW_MASK);
> + bw = (2 >> ((sys_reg >> SYS_REG_BW_SHIFT(ch)) &
> + SYS_REG_BW_MASK));
> + row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
> + SYS_REG_ROW_3_4_MASK;
> 
> - if (rank > 1)
> - chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
> - if (row_3_4)
> - chipsize_mb = chipsize_mb * 3 / 4;
> - size_mb += chipsize_mb;
> - debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
> -   rank, col, bk, cs0_row, bw, row_3_4);
> + chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
> +
> + if (rank > 1)
> + chipsize_mb += chipsize_mb >> (cs0_row - 
> cs1_row);
> + if (row_3_4)
> + chipsize_mb = chipsize_mb * 3 / 4;
> + size_mb += chipsize_mb;
> + debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 
> %d\n",
> +   rank, col, bk, cs0_row, bw, row_3_4);
> + }
> +
> + /*
> +  * we use the 0x~0xfeff space
> +  * since 0xff00~0x is soc register space
> +  * so we reserve it 
> +  */

That’s not true for all Rockchip SoCs. On the RK3399 for example the upper 
limit 
is 0xf800. Even on the RK3288 DRAM address range is actually
 0x-0xfe0

> + size_mb = min(size_mb, 0xff00/SZ_1M);
>   }


Re: [U-Boot] [PATCH] rockchip: update emmc/sd index

2018-05-04 Thread klaus . goger
Hi Kever

> On 04.05.2018, at 10:50, Kever Yang  wrote:
> 
> We define emmc/sdcard index in dts alias, emmc is 0 and sdcard is 1.

The commit message is a bit misleading at first. When reading it i thought
you update or add dts alias indexes. But you actually change the default
boot order of distroboot. So having the commit message reflect that would
be nice.

> Signed-off-by: Kever Yang 
> ---
> 
> include/configs/rockchip-common.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/configs/rockchip-common.h 
> b/include/configs/rockchip-common.h
> index 4062480..d658854 100644
> --- a/include/configs/rockchip-common.h
> +++ b/include/configs/rockchip-common.h
> @@ -16,11 +16,11 @@
> 
> #ifndef CONFIG_SPL_BUILD
> 
> -/* First try to boot from SD (index 0), then eMMC (index 1) */
> +/* First try to boot from SD (index 1), then eMMC (index 0) */
> #if CONFIG_IS_ENABLED(CMD_MMC)
>   #define BOOT_TARGET_MMC(func) \
> - func(MMC, mmc, 0) \
> - func(MMC, mmc, 1)
> + func(MMC, mmc, 1) \
> + func(MMC, mmc, 0)

While I agree that the comment is wrong I’m against this patch as it will 
change the 
current default behaviour that people are depending on. Wouldn’t it be better 
to 
change the comment to reflect current reality?
Also prioritising SD card over eMMC does not make any sense to me. At least on
RK3399 and RK3368 the default ROM boot order is first eMMC then SD card. So 
starting U-Boot from eMMC and then loading the Kernel from SD-card doesn’t sound
right for me. 

> #else
>   #define BOOT_TARGET_MMC(func)
> #endif
> -- 
> 1.9.1

Best Regards,
Klaus

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


[U-Boot] [PATCH v3 2/2] arm: Make arch specific memcpy thumb-safe.

2018-04-26 Thread Klaus Goger
The current arch implementation of memcpy cannot be called
from thumb code, because it does not use bx instructions on return.
This patch addresses that. Note, that this patch does not touch
the hot loop of memcpy, so performance is not affected.

Tested on MXS (arm926ejs) with and without thumb-mode enabled.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muell...@theobroma-systems.com>

---

Changes in v3: None
Changes in v2:
- added memcpy patch to the series

 arch/arm/lib/memcpy.S | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 588b3f8971..9e9a193c2a 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -62,7 +62,7 @@
 #endif
 ENTRY(memcpy)
cmp r0, r1
-   moveq   pc, lr
+   bxeqlr
 
enter   r4, lr
 
@@ -150,7 +150,8 @@ ENTRY(memcpy)
str1b   r0, r4, cs, abort=21f
str1b   r0, ip, cs, abort=21f
 
-   exitr4, pc
+   exitr4, lr
+   bx  lr
 
 9: rsb ip, ip, #4
cmp ip, #2
@@ -259,7 +260,8 @@ ENTRY(memcpy)
.endm
 
.macro  copy_abort_end
-   ldmfd   sp!, {r4, pc}
+   ldmfd   sp!, {r4, lr}
+   bx  lr
.endm
 
 ENDPROC(memcpy)
-- 
2.11.0

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


[U-Boot] [PATCH v3 0/2] Fix thumb interwork in assembly code

2018-04-26 Thread Klaus Goger
While trying to compile u-boot in thumb due space constraints on a mxs
platform it was observed that there are some thumb-interwork issues
in the handwritten assembly files.

Since the first patch only applies to ARM926EJS and no board on that platform
has thumb enabled for now,it was probably never observed.
Strictly speaking it is not thumb specific as it can be triggered in ARM
mode too. But as it was discovered by enabling thumb and no mxs board is
currently using any relevant ARM code in lowlevel_init, we put the series
under the thumb subject.

The second one applies to the ARM specific assembly memcpy implementation
that is not enabled on any of the boards enabling thumb.

grep -l CONFIG_SYS_THUMB_BUILD=y configs/* | \
  xargs grep -c CONFIG_USE_ARCH_MEMCPY
configs/apalis_imx6_nospl_com_defconfig:0
configs/apalis_imx6_nospl_it_defconfig:0
configs/bk4r1_defconfig:0
configs/colibri_imx6_nospl_defconfig:0
configs/colibri_imx7_defconfig:0
configs/colibri_vf_defconfig:0
configs/highbank_defconfig:0
configs/openrd_base_defconfig:0
configs/openrd_client_defconfig:0
configs/openrd_ultimate_defconfig:0
configs/pcm052_defconfig:0
configs/tbs2910_defconfig:0
configs/x600_defconfig:0

With CONFIG_USE_ARCH_MEMCPY on our mxs platform the speedup for memcopy
was about 100%.

Changes in v3:
- reword commit message as it isn't thumb specific
- use r10 instead of sl alias as we don't use it as stack limit pointer
- revert return to a pc mov as it is a unnecessary change for this patch

Changes in v2:
- use bl instead of blx to call lowlevel_init
- remove mxs tag as it apply to all arm926ejs platforms
- added memcpy patch to the series

Klaus Goger (2):
  arm: preserve lr correctly in arm926ejs startup code
  arm: Make arch specific memcpy thumb-safe.

 arch/arm/cpu/arm926ejs/start.S | 4 ++--
 arch/arm/lib/memcpy.S  | 8 +---
 2 files changed, 7 insertions(+), 5 deletions(-)

-- 
2.11.0

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


[U-Boot] [PATCH v3 1/2] arm: preserve lr correctly in arm926ejs startup code

2018-04-26 Thread Klaus Goger
When building the mxs platform in thumb mode gcc generates code using
the intra procedure call scratch register (ip/r12) for the calling the
lowlevel_init function. This modifies the lr in flush_dcache which
causes u-boot proper to end in an endless loop.

40002334:   e1a0c00emov ip, lr
40002338:   eb00df4cbl  4003a070
<__lowlevel_init_from_arm>
4000233c:   e1a0e00cmov lr, ip
40002340:   e1a0f00emov pc, lr
[...]
4003a070 <__lowlevel_init_from_arm>:
4003a070:   e59fc004ldr ip, [pc, #4]; 4003a07c
<__lowlevel_init_from_arm+0xc>
4003a074:   e08fc00cadd ip, pc, ip
4003a078:   e12fff1cbx  ip
4003a07c:   fffc86cd.word   0xfffc86cd

Instead of using the the ip/r12 register we use sl/r10 to preserve the
link register.

According to "Procedure Call Standard for the ARM Architecture" by ARM
subroutines have to preserve the contents of register r4-r8, r10, r11
and SP. So using r12 to store the link register will fail if the called
function is using r12 and not preserving it as allowed.
This can happen in ARM and thumb mode but will definitely be triggered
by building it in thumb.
Using r10 should be safe in any case as we are startup code and not
called by any C-function and no stack is set up.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muell...@theobroma-systems.com>

---

Changes in v3:
- reword commit message as it isn't thumb specific
- use r10 instead of sl alias as we don't use it as stack limit pointer
- revert return to a pc mov as it is a unnecessary change for this patch

Changes in v2:
- use bl instead of blx to call lowlevel_init
- remove mxs tag as it apply to all arm926ejs platforms

 arch/arm/cpu/arm926ejs/start.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 959d1ed86d..a625b39787 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -105,9 +105,9 @@ flush_dcache:
/*
 * Go setup Memory and board specific bits prior to relocation.
 */
-   mov ip, lr  /* perserve link reg across call */
+   mov r10, lr /* perserve link reg across call */
bl  lowlevel_init   /* go setup pll,mux,memory */
-   mov lr, ip  /* restore link */
+   mov lr, r10 /* restore link */
 #endif
mov pc, lr  /* back to my caller */
 #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
-- 
2.11.0

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


Re: [U-Boot] [PATCH v2 1/2] arm: make arm926ejs startup code thumb compatible

2018-04-20 Thread klaus . goger


> On 20.04.2018, at 23:55, Marek Vasut <ma...@denx.de> wrote:
> 
> On 04/20/2018 09:51 PM, Klaus Goger wrote:
>> When building the mxs platform in thumb mode gcc generates code using
>> the intra procedure call scratch register (ip/r12) for the calling the
>> lowlevel_init function. This modifies the lr in flush_dcache which
>> causes u-boot proper to end in an endless loop.
>> 
>> 40002334:   e1a0c00emov ip, lr
>> 40002338:   eb00df4cbl  4003a070
>> <__lowlevel_init_from_arm>
>> 4000233c:   e1a0e00cmov lr, ip
>> 40002340:   e1a0f00emov pc, lr
>> [...]
>> 4003a070 <__lowlevel_init_from_arm>:
>> 4003a070:   e59fc004ldr ip, [pc, #4]; 4003a07c
>> <__lowlevel_init_from_arm+0xc>
>> 4003a074:   e08fc00cadd ip, pc, ip
>> 4003a078:   e12fff1cbx  ip
>> 4003a07c:   fffc86cd.word   0xfffc86cd
>> 
>> Instead of using the the ip/r12 register we use sl/r10 to preserve the
>> link register.
>> 
>> According to "Procedure Call Standard for the ARM Architecture" by ARM
>> subroutines have to preserve the contents of register r4-r8, r10, r11
>> and SP. So using r10 instead of r12 should be save.
>> 
>> Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
>> Signed-off-by: Christoph Muellner <christoph.muell...@theobroma-systems.com>
>> 
>> ---
>> 
>> Changes in v2:
>> - use bl instead of blx to call lowlevel_init
>> - remove mxs tag as it apply to all arm926ejs platforms
> 
> What is lowlevel_init() is implemented as a C code and therefore thumb ?
> :-) doesn't ie. armv7a handle this somehow already ?
 
lowlevel_init() is implemented in C (you wrote it :)) and therefore thumb if
compiled as thumb.
armv7 lowlevel_init is implemented in assembly.

As the compiler will generate the necessary interwork code there was no need
to change the branch instruction to blx. So I changed it back to bl as the 
original
code as this will work with both generated codes (arm and thumb) and also
if someone decides to reimplement lowlevel_init as arm assembly.

> 
>> arch/arm/cpu/arm926ejs/start.S | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
>> index 959d1ed86d..317df5c401 100644
>> --- a/arch/arm/cpu/arm926ejs/start.S
>> +++ b/arch/arm/cpu/arm926ejs/start.S
>> @@ -105,9 +105,9 @@ flush_dcache:
>>  /*
>>   * Go setup Memory and board specific bits prior to relocation.
>>   */
>> -mov ip, lr  /* perserve link reg across call */
>> +mov sl, lr  /* perserve link reg across call */
>>  bl  lowlevel_init   /* go setup pll,mux,memory */
>> -mov lr, ip  /* restore link */
>> +mov lr, sl  /* restore link */
>> #endif
>> -mov pc, lr  /* back to my caller */
>> +bx  lr  /* back to my caller */
>> #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
>> 
> 
> 
> -- 
> Best regards,
> Marek Vasut

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


[U-Boot] [PATCH v2 0/2] While trying to compile u-boot in thumb due space constraints on a mxs

2018-04-20 Thread Klaus Goger
platform it was observed that there are some thumb-interwork issues
in the handwritten assembly files.

Since the first patch only applies to ARM926EJS and no board on that platform
has thumb enabled for now,it was probably never observed.

The second one applies to the ARM specific assembly memcpy implementation
that is not enabled on any of the boards enabling thumb.

grep -l CONFIG_SYS_THUMB_BUILD=y configs/* | \
  xargs grep -c CONFIG_USE_ARCH_MEMCPY
configs/apalis_imx6_nospl_com_defconfig:0
configs/apalis_imx6_nospl_it_defconfig:0
configs/bk4r1_defconfig:0
configs/colibri_imx6_nospl_defconfig:0
configs/colibri_imx7_defconfig:0
configs/colibri_vf_defconfig:0
configs/highbank_defconfig:0
configs/openrd_base_defconfig:0
configs/openrd_client_defconfig:0
configs/openrd_ultimate_defconfig:0
configs/pcm052_defconfig:0
configs/tbs2910_defconfig:0
configs/x600_defconfig:0

With CONFIG_USE_ARCH_MEMCPY on our mxs platform the speedup for memcopy
was about 100%.

Changes in v2:
- use bl instead of blx to call lowlevel_init
- remove mxs tag as it apply to all arm926ejs platforms

Klaus Goger (2):
  arm: make arm926ejs startup code thumb compatible
  arm: Make arch specific memcpy thumb-safe.

 arch/arm/cpu/arm926ejs/start.S | 6 +++---
 arch/arm/lib/memcpy.S  | 8 +---
 2 files changed, 8 insertions(+), 6 deletions(-)

-- 
2.11.0

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


[U-Boot] [PATCH v2 2/2] arm: Make arch specific memcpy thumb-safe.

2018-04-20 Thread Klaus Goger
The current arch implementation of memcpy cannot be called
from thumb code, because it does not use bx instructions on return.
This patch addresses that. Note, that this patch does not touch
the hot loop of memcpy, so performance is not affected.

Tested on MXS (arm926ejs) with and without thumb-mode enabled.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muell...@theobroma-systems.com>

---

Changes in v2: None

 arch/arm/lib/memcpy.S | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 588b3f8971..9e9a193c2a 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -62,7 +62,7 @@
 #endif
 ENTRY(memcpy)
cmp r0, r1
-   moveq   pc, lr
+   bxeqlr
 
enter   r4, lr
 
@@ -150,7 +150,8 @@ ENTRY(memcpy)
str1b   r0, r4, cs, abort=21f
str1b   r0, ip, cs, abort=21f
 
-   exitr4, pc
+   exitr4, lr
+   bx  lr
 
 9: rsb ip, ip, #4
cmp ip, #2
@@ -259,7 +260,8 @@ ENTRY(memcpy)
.endm
 
.macro  copy_abort_end
-   ldmfd   sp!, {r4, pc}
+   ldmfd   sp!, {r4, lr}
+   bx  lr
.endm
 
 ENDPROC(memcpy)
-- 
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] arm: make arm926ejs startup code thumb compatible

2018-04-20 Thread Klaus Goger
When building the mxs platform in thumb mode gcc generates code using
the intra procedure call scratch register (ip/r12) for the calling the
lowlevel_init function. This modifies the lr in flush_dcache which
causes u-boot proper to end in an endless loop.

40002334:   e1a0c00emov ip, lr
40002338:   eb00df4cbl  4003a070
<__lowlevel_init_from_arm>
4000233c:   e1a0e00cmov lr, ip
40002340:   e1a0f00emov pc, lr
[...]
4003a070 <__lowlevel_init_from_arm>:
4003a070:   e59fc004ldr ip, [pc, #4]; 4003a07c
<__lowlevel_init_from_arm+0xc>
4003a074:   e08fc00cadd ip, pc, ip
4003a078:   e12fff1cbx  ip
4003a07c:   fffc86cd.word   0xfffc86cd

Instead of using the the ip/r12 register we use sl/r10 to preserve the
link register.

According to "Procedure Call Standard for the ARM Architecture" by ARM
subroutines have to preserve the contents of register r4-r8, r10, r11
and SP. So using r10 instead of r12 should be save.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muell...@theobroma-systems.com>

---

Changes in v2:
- use bl instead of blx to call lowlevel_init
- remove mxs tag as it apply to all arm926ejs platforms

 arch/arm/cpu/arm926ejs/start.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 959d1ed86d..317df5c401 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -105,9 +105,9 @@ flush_dcache:
/*
 * Go setup Memory and board specific bits prior to relocation.
 */
-   mov ip, lr  /* perserve link reg across call */
+   mov sl, lr  /* perserve link reg across call */
bl  lowlevel_init   /* go setup pll,mux,memory */
-   mov lr, ip  /* restore link */
+   mov lr, sl  /* restore link */
 #endif
-   mov pc, lr  /* back to my caller */
+   bx  lr  /* back to my caller */
 #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
-- 
2.11.0

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


Re: [U-Boot] [PATCH v1] arm: mxs: make startup code thumb compatible

2018-04-19 Thread klaus . goger

> On 18.04.2018, at 22:02, Marek Vasut <ma...@denx.de> wrote:
> 
> On 04/18/2018 06:25 PM, Klaus Goger wrote:
>> When building the mxs platform in thumb mode gcc generates code using
>> the intra procedure call scratch register (ip/r12) for the calling the
>> lowlevel_init function. This modifies the lr in flush_dcache which
>> causes u-boot proper to end in an endless loop.
>> 
>> 40002334:   e1a0c00emov ip, lr
>> 40002338:   eb00df4cbl  4003a070
>> <__lowlevel_init_from_arm>
>> 4000233c:   e1a0e00cmov lr, ip
>> 40002340:   e1a0f00emov pc, lr
>> [...]
>> 4003a070 <__lowlevel_init_from_arm>:
>> 4003a070:   e59fc004ldr ip, [pc, #4]; 4003a07c
>> <__lowlevel_init_from_arm+0xc>
>> 4003a074:   e08fc00cadd ip, pc, ip
>> 4003a078:   e12fff1cbx  ip
>> 4003a07c:   fffc86cd.word   0xfffc86cd
>> 
>> Instead of using the the ip/r12 register we use sl/r10 to preserve the
>> link register.
>> 
>> According to "Procedure Call Standard for the ARM Architecture" by ARM
>> subroutines have to preserve the contents of register r4-r8, r10, r11
>> and SP. So using r10 instead of r12 should be save.
>> 
>> Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
>> Signed-off-by: Christoph Muellner <christoph.muell...@theobroma-systems.com>
>> 
>> ---
>> 
>> arch/arm/cpu/arm926ejs/start.S | 8 
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
>> index 959d1ed86d..103bd15914 100644
>> --- a/arch/arm/cpu/arm926ejs/start.S
>> +++ b/arch/arm/cpu/arm926ejs/start.S
>> @@ -105,9 +105,9 @@ flush_dcache:
>>  /*
>>   * Go setup Memory and board specific bits prior to relocation.
>>   */
>> -mov ip, lr  /* perserve link reg across call */
>> -bl  lowlevel_init   /* go setup pll,mux,memory */
>> -mov lr, ip  /* restore link */
>> +mov sl, lr  /* perserve link reg across call */
>> +blx lowlevel_init   /* go setup pll,mux,memory */
>> +mov lr, sl  /* restore link */
>> #endif
>> -mov pc, lr  /* back to my caller */
>> +bx  lr  /* back to my caller */
>> #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
> 
> Are you sure this doesn't break the non-thumb operation ?

Yes I’m sure. I also tested thumb and non-thumb builds on the same device with
that patch. Both give you a proper u-boot shell.

I think there will be more patches down the road fixing other thumb/non-thumb 
issues
(like booting a kernel). But they are not related to that patchset.

> Also, is this really MXS specific or not ?

My error, shouldn’t have tagged it mxs as it’s for all arm926ejs platforms.

I guess arm920t, arm946es, arm720t, arm1136 and omap3 will have the same issue 
as
it has more or less verbatim copies of these functions.
But do the lack of hardware I could not test it.




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


[U-Boot] [PATCH v1] arm: mxs: make startup code thumb compatible

2018-04-18 Thread Klaus Goger
When building the mxs platform in thumb mode gcc generates code using
the intra procedure call scratch register (ip/r12) for the calling the
lowlevel_init function. This modifies the lr in flush_dcache which
causes u-boot proper to end in an endless loop.

40002334:   e1a0c00emov ip, lr
40002338:   eb00df4cbl  4003a070
<__lowlevel_init_from_arm>
4000233c:   e1a0e00cmov lr, ip
40002340:   e1a0f00emov pc, lr
[...]
4003a070 <__lowlevel_init_from_arm>:
4003a070:   e59fc004ldr ip, [pc, #4]; 4003a07c
<__lowlevel_init_from_arm+0xc>
4003a074:   e08fc00cadd ip, pc, ip
4003a078:   e12fff1cbx  ip
4003a07c:   fffc86cd.word   0xfffc86cd

Instead of using the the ip/r12 register we use sl/r10 to preserve the
link register.

According to "Procedure Call Standard for the ARM Architecture" by ARM
subroutines have to preserve the contents of register r4-r8, r10, r11
and SP. So using r10 instead of r12 should be save.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muell...@theobroma-systems.com>

---

 arch/arm/cpu/arm926ejs/start.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 959d1ed86d..103bd15914 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -105,9 +105,9 @@ flush_dcache:
/*
 * Go setup Memory and board specific bits prior to relocation.
 */
-   mov ip, lr  /* perserve link reg across call */
-   bl  lowlevel_init   /* go setup pll,mux,memory */
-   mov lr, ip  /* restore link */
+   mov sl, lr  /* perserve link reg across call */
+   blx lowlevel_init   /* go setup pll,mux,memory */
+   mov lr, sl  /* restore link */
 #endif
-   mov pc, lr  /* back to my caller */
+   bx  lr  /* back to my caller */
 #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
-- 
2.11.0

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


[U-Boot] [PATCH v1] rockchip: defconfig: puma-rk3399: enable RTC

2018-04-13 Thread Klaus Goger
commit: 52280315a4 ("rtc: rewrite isl1208 to support DM") enables us to
use the on-module RTC emulation with the rk3399 device model i2c driver.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>

---

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

diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 4324a82e76..b809a7 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -80,6 +80,8 @@ CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_RAM=y
 CONFIG_SPL_RAM=y
+CONFIG_DM_RTC=y
+CONFIG_RTC_ISL1208=y
 CONFIG_DEBUG_UART_BASE=0xFF18
 CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_DEBUG_UART_SHIFT=2
-- 
2.11.0

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


[U-Boot] [PATCH v3] rtc: rewrite isl1208 to support DM

2018-03-19 Thread Klaus Goger
Adds devicemodel support to the ISL1208 driver.
This patch drops the non-dm API as no board was using it anyway.
Also add it to Kconfig.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Reviewed-by: Simon Glass <s...@chromium.org>

---

Changes in v3:
- Actually adding the changed files before submitting them. Sorry for
that.

Changes in v2:
- Reword of Kconfig help text

 drivers/rtc/Kconfig   |  12 +
 drivers/rtc/isl1208.c | 141 ++
 2 files changed, 98 insertions(+), 55 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 95ac031243..277dc3de73 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -30,6 +30,18 @@ config RTC_DS1307
  Support for Dallas Semiconductor (now Maxim) DS1307 and DS1338/9 and
  compatible Real Time Clock devices.
 
+config RTC_ISL1208
+   bool "Enable ISL1208 driver"
+   depends on DM_RTC
+   help
+ The Renesas (formerly Intersil) ISL1208 is a I2C Real Time Clock 
(RTC) and
+ calendar with automatic leap year correction, 2-byte battery backed 
SRAM,
+ automatic power switch-over, alarm function and 15 selectable 
frequency
+ outputs.
+
+ This driver supports reading and writing the RTC/calendar and detects
+ total power failures.
+
 config RTC_RX8010SJ
bool "Enable RX8010SJ driver"
depends on DM_RTC
diff --git a/drivers/rtc/isl1208.c b/drivers/rtc/isl1208.c
index 807e2e404e..fa1178a36e 100644
--- a/drivers/rtc/isl1208.c
+++ b/drivers/rtc/isl1208.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -51,45 +52,38 @@
 #define RTC_STAT_BIT_BAT   0x02/* BATTERY BIT */
 #define RTC_STAT_BIT_RTCF  0x01/* REAL TIME CLOCK FAIL BIT */
 
-static uchar rtc_read (uchar reg);
-static void rtc_write (uchar reg, uchar val);
-
 /*
  * Get the current time from the RTC
  */
 
-int rtc_get (struct rtc_time *tmp)
+static int isl1208_rtc_get(struct udevice *dev, struct rtc_time *tmp)
 {
-   int rel = 0;
-   uchar sec, min, hour, mday, wday, mon, year, status;
-
-   status = rtc_read (RTC_STAT_REG_ADDR);
-   sec = rtc_read (RTC_SEC_REG_ADDR);
-   min = rtc_read (RTC_MIN_REG_ADDR);
-   hour = rtc_read (RTC_HR_REG_ADDR);
-   wday = rtc_read (RTC_DAY_REG_ADDR);
-   mday = rtc_read (RTC_DATE_REG_ADDR);
-   mon = rtc_read (RTC_MON_REG_ADDR);
-   year = rtc_read (RTC_YR_REG_ADDR);
-
-   DEBUGR ("Get RTC year: %02x mon: %02x mday: %02x wday: %02x "
-   "hr: %02x min: %02x sec: %02x status: %02x\n",
-   year, mon, mday, wday, hour, min, sec, status);
-
-   if (status & RTC_STAT_BIT_RTCF) {
+   int ret;
+   uchar buf[8], val;
+
+   ret = dm_i2c_read(dev, 0, buf, sizeof(buf));
+   if (ret < 0)
+   return ret;
+
+   if (buf[RTC_STAT_REG_ADDR] & RTC_STAT_BIT_RTCF) {
printf ("### Warning: RTC oscillator has stopped\n");
-   rtc_write(RTC_STAT_REG_ADDR,
-   rtc_read(RTC_STAT_REG_ADDR) &~ 
(RTC_STAT_BIT_BAT|RTC_STAT_BIT_RTCF));
-   rel = -1;
+   ret = dm_i2c_read(dev, RTC_STAT_REG_ADDR, , sizeof(val));
+   if (ret < 0)
+   return ret;
+
+   val = val & ~(RTC_STAT_BIT_BAT | RTC_STAT_BIT_RTCF);
+   ret = dm_i2c_write(dev, RTC_STAT_REG_ADDR, , sizeof(val));
+   if (ret < 0)
+   return ret;
}
 
-   tmp->tm_sec  = bcd2bin (sec & 0x7F);
-   tmp->tm_min  = bcd2bin (min & 0x7F);
-   tmp->tm_hour = bcd2bin (hour & 0x3F);
-   tmp->tm_mday = bcd2bin (mday & 0x3F);
-   tmp->tm_mon  = bcd2bin (mon & 0x1F);
-   tmp->tm_year = bcd2bin (year)+2000;
-   tmp->tm_wday = bcd2bin (wday & 0x07);
+   tmp->tm_sec  = bcd2bin(buf[RTC_SEC_REG_ADDR] & 0x7F);
+   tmp->tm_min  = bcd2bin(buf[RTC_MIN_REG_ADDR] & 0x7F);
+   tmp->tm_hour = bcd2bin(buf[RTC_HR_REG_ADDR] & 0x3F);
+   tmp->tm_mday = bcd2bin(buf[RTC_DATE_REG_ADDR] & 0x3F);
+   tmp->tm_mon  = bcd2bin(buf[RTC_MON_REG_ADDR] & 0x1F);
+   tmp->tm_year = bcd2bin(buf[RTC_YR_REG_ADDR]) + 2000;
+   tmp->tm_wday = bcd2bin(buf[RTC_DAY_REG_ADDR] & 0x07);
tmp->tm_yday = 0;
tmp->tm_isdst= 0;
 
@@ -97,51 +91,88 @@ int rtc_get (struct rtc_time *tmp)
tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
 
-   return rel;
+   return 0;
 }
 
 /*
  * Set the RTC
  */
-int rtc_set (struct rtc_time *tmp)
+static int isl1208_rtc_set(struct udevice *dev, const struct rtc_time *tmp)
 {
+ 

[U-Boot] [PATCH v2] rtc: rewrite isl1208 to support DM

2018-03-19 Thread Klaus Goger
Adds devicemodel support to the ISL1208 driver.
This patch drops the non-dm API as no board was using it anyway.
Also add it to Kconfig.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Reviewed-by: Simon Glass <s...@chromium.org>

---

Changes in v2:
- Reword of Kconfig help text

 drivers/rtc/Kconfig   |   7 +++
 drivers/rtc/isl1208.c | 141 ++
 2 files changed, 93 insertions(+), 55 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 95ac031243..960c3fc3e2 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -30,6 +30,13 @@ config RTC_DS1307
  Support for Dallas Semiconductor (now Maxim) DS1307 and DS1338/9 and
  compatible Real Time Clock devices.
 
+config RTC_ISL1208
+   bool "Enable ISL1208 driver"
+   depends on DM_RTC
+   help
+ Support for Renesas (formerly Intersil) ISL1208 and compatible Real 
Time
+ Clock devices.
+
 config RTC_RX8010SJ
bool "Enable RX8010SJ driver"
depends on DM_RTC
diff --git a/drivers/rtc/isl1208.c b/drivers/rtc/isl1208.c
index 807e2e404e..fa1178a36e 100644
--- a/drivers/rtc/isl1208.c
+++ b/drivers/rtc/isl1208.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -51,45 +52,38 @@
 #define RTC_STAT_BIT_BAT   0x02/* BATTERY BIT */
 #define RTC_STAT_BIT_RTCF  0x01/* REAL TIME CLOCK FAIL BIT */
 
-static uchar rtc_read (uchar reg);
-static void rtc_write (uchar reg, uchar val);
-
 /*
  * Get the current time from the RTC
  */
 
-int rtc_get (struct rtc_time *tmp)
+static int isl1208_rtc_get(struct udevice *dev, struct rtc_time *tmp)
 {
-   int rel = 0;
-   uchar sec, min, hour, mday, wday, mon, year, status;
-
-   status = rtc_read (RTC_STAT_REG_ADDR);
-   sec = rtc_read (RTC_SEC_REG_ADDR);
-   min = rtc_read (RTC_MIN_REG_ADDR);
-   hour = rtc_read (RTC_HR_REG_ADDR);
-   wday = rtc_read (RTC_DAY_REG_ADDR);
-   mday = rtc_read (RTC_DATE_REG_ADDR);
-   mon = rtc_read (RTC_MON_REG_ADDR);
-   year = rtc_read (RTC_YR_REG_ADDR);
-
-   DEBUGR ("Get RTC year: %02x mon: %02x mday: %02x wday: %02x "
-   "hr: %02x min: %02x sec: %02x status: %02x\n",
-   year, mon, mday, wday, hour, min, sec, status);
-
-   if (status & RTC_STAT_BIT_RTCF) {
+   int ret;
+   uchar buf[8], val;
+
+   ret = dm_i2c_read(dev, 0, buf, sizeof(buf));
+   if (ret < 0)
+   return ret;
+
+   if (buf[RTC_STAT_REG_ADDR] & RTC_STAT_BIT_RTCF) {
printf ("### Warning: RTC oscillator has stopped\n");
-   rtc_write(RTC_STAT_REG_ADDR,
-   rtc_read(RTC_STAT_REG_ADDR) &~ 
(RTC_STAT_BIT_BAT|RTC_STAT_BIT_RTCF));
-   rel = -1;
+   ret = dm_i2c_read(dev, RTC_STAT_REG_ADDR, , sizeof(val));
+   if (ret < 0)
+   return ret;
+
+   val = val & ~(RTC_STAT_BIT_BAT | RTC_STAT_BIT_RTCF);
+   ret = dm_i2c_write(dev, RTC_STAT_REG_ADDR, , sizeof(val));
+   if (ret < 0)
+   return ret;
}
 
-   tmp->tm_sec  = bcd2bin (sec & 0x7F);
-   tmp->tm_min  = bcd2bin (min & 0x7F);
-   tmp->tm_hour = bcd2bin (hour & 0x3F);
-   tmp->tm_mday = bcd2bin (mday & 0x3F);
-   tmp->tm_mon  = bcd2bin (mon & 0x1F);
-   tmp->tm_year = bcd2bin (year)+2000;
-   tmp->tm_wday = bcd2bin (wday & 0x07);
+   tmp->tm_sec  = bcd2bin(buf[RTC_SEC_REG_ADDR] & 0x7F);
+   tmp->tm_min  = bcd2bin(buf[RTC_MIN_REG_ADDR] & 0x7F);
+   tmp->tm_hour = bcd2bin(buf[RTC_HR_REG_ADDR] & 0x3F);
+   tmp->tm_mday = bcd2bin(buf[RTC_DATE_REG_ADDR] & 0x3F);
+   tmp->tm_mon  = bcd2bin(buf[RTC_MON_REG_ADDR] & 0x1F);
+   tmp->tm_year = bcd2bin(buf[RTC_YR_REG_ADDR]) + 2000;
+   tmp->tm_wday = bcd2bin(buf[RTC_DAY_REG_ADDR] & 0x07);
tmp->tm_yday = 0;
tmp->tm_isdst= 0;
 
@@ -97,51 +91,88 @@ int rtc_get (struct rtc_time *tmp)
tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
 
-   return rel;
+   return 0;
 }
 
 /*
  * Set the RTC
  */
-int rtc_set (struct rtc_time *tmp)
+static int isl1208_rtc_set(struct udevice *dev, const struct rtc_time *tmp)
 {
+   int ret;
+   uchar val, buf[7];
+
DEBUGR ("Set DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
 
+   if (tmp->tm_year < 2000 || tmp->tm_year > 2099)
+   p

Re: [U-Boot] rockchip: rk3399: set fdtfile

2018-03-19 Thread klaus . goger

> On 17.03.2018, at 09:48, Mark Kettenis <kette...@openbsd.org> wrote:
> 
> Signed-off-by: Mark Kettenis <kette...@openbsd.org>
> Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
> ---
> include/configs/rk3399_common.h | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
> index d700bf2549..9a5de3a7e3 100644
> --- a/include/configs/rk3399_common.h
> +++ b/include/configs/rk3399_common.h
> @@ -59,6 +59,7 @@
> #include 
> #define CONFIG_EXTRA_ENV_SETTINGS \
>   ENV_MEM_LAYOUT_SETTINGS \
> + "fdtfile=rockchip/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
>   "partitions=" PARTS_DEFAULT \
>   BOOTENV
> 

This assumes that the devicetree files in U-Boot and the OS are the same.
As it’s our goal to keep Linux devicetrees in sync with U-Boot this patch should
be fine in the long-term. But at the moment this only applies for 
rk3399-firefly (on
Linux).

Mark, where would one find the devicetrees included in OpenBSD?
I looked in sys/arch/amd64 but couldn’t find any.

Anyhow, I’m fine with that change.

Tested-by: Klaus Goger <klaus.go...@theobroma-systems.com>

— 
Klaus

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


[U-Boot] [PATCH v1] rtc: rewrite isl1208 to support DM

2018-03-18 Thread Klaus Goger
Adds devicemodel support to the ISL1208 driver.
This patch drops the non-dm API as no board was using it anyway.
Also add it to Kconfig.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>

---

 drivers/rtc/Kconfig   |   7 +++
 drivers/rtc/isl1208.c | 141 ++
 2 files changed, 93 insertions(+), 55 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 95ac031243..960c3fc3e2 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -30,6 +30,13 @@ config RTC_DS1307
  Support for Dallas Semiconductor (now Maxim) DS1307 and DS1338/9 and
  compatible Real Time Clock devices.
 
+config RTC_ISL1208
+   bool "Enable ISL1208 driver"
+   depends on DM_RTC
+   help
+ Support for Renesas (formerly Intersil) ISL1208 and compatible Real 
Time
+ Clock devices.
+
 config RTC_RX8010SJ
bool "Enable RX8010SJ driver"
depends on DM_RTC
diff --git a/drivers/rtc/isl1208.c b/drivers/rtc/isl1208.c
index 807e2e404e..fa1178a36e 100644
--- a/drivers/rtc/isl1208.c
+++ b/drivers/rtc/isl1208.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -51,45 +52,38 @@
 #define RTC_STAT_BIT_BAT   0x02/* BATTERY BIT */
 #define RTC_STAT_BIT_RTCF  0x01/* REAL TIME CLOCK FAIL BIT */
 
-static uchar rtc_read (uchar reg);
-static void rtc_write (uchar reg, uchar val);
-
 /*
  * Get the current time from the RTC
  */
 
-int rtc_get (struct rtc_time *tmp)
+static int isl1208_rtc_get(struct udevice *dev, struct rtc_time *tmp)
 {
-   int rel = 0;
-   uchar sec, min, hour, mday, wday, mon, year, status;
-
-   status = rtc_read (RTC_STAT_REG_ADDR);
-   sec = rtc_read (RTC_SEC_REG_ADDR);
-   min = rtc_read (RTC_MIN_REG_ADDR);
-   hour = rtc_read (RTC_HR_REG_ADDR);
-   wday = rtc_read (RTC_DAY_REG_ADDR);
-   mday = rtc_read (RTC_DATE_REG_ADDR);
-   mon = rtc_read (RTC_MON_REG_ADDR);
-   year = rtc_read (RTC_YR_REG_ADDR);
-
-   DEBUGR ("Get RTC year: %02x mon: %02x mday: %02x wday: %02x "
-   "hr: %02x min: %02x sec: %02x status: %02x\n",
-   year, mon, mday, wday, hour, min, sec, status);
-
-   if (status & RTC_STAT_BIT_RTCF) {
+   int ret;
+   uchar buf[8], val;
+
+   ret = dm_i2c_read(dev, 0, buf, sizeof(buf));
+   if (ret < 0)
+   return ret;
+
+   if (buf[RTC_STAT_REG_ADDR] & RTC_STAT_BIT_RTCF) {
printf ("### Warning: RTC oscillator has stopped\n");
-   rtc_write(RTC_STAT_REG_ADDR,
-   rtc_read(RTC_STAT_REG_ADDR) &~ 
(RTC_STAT_BIT_BAT|RTC_STAT_BIT_RTCF));
-   rel = -1;
+   ret = dm_i2c_read(dev, RTC_STAT_REG_ADDR, , sizeof(val));
+   if (ret < 0)
+   return ret;
+
+   val = val & ~(RTC_STAT_BIT_BAT | RTC_STAT_BIT_RTCF);
+   ret = dm_i2c_write(dev, RTC_STAT_REG_ADDR, , sizeof(val));
+   if (ret < 0)
+   return ret;
}
 
-   tmp->tm_sec  = bcd2bin (sec & 0x7F);
-   tmp->tm_min  = bcd2bin (min & 0x7F);
-   tmp->tm_hour = bcd2bin (hour & 0x3F);
-   tmp->tm_mday = bcd2bin (mday & 0x3F);
-   tmp->tm_mon  = bcd2bin (mon & 0x1F);
-   tmp->tm_year = bcd2bin (year)+2000;
-   tmp->tm_wday = bcd2bin (wday & 0x07);
+   tmp->tm_sec  = bcd2bin(buf[RTC_SEC_REG_ADDR] & 0x7F);
+   tmp->tm_min  = bcd2bin(buf[RTC_MIN_REG_ADDR] & 0x7F);
+   tmp->tm_hour = bcd2bin(buf[RTC_HR_REG_ADDR] & 0x3F);
+   tmp->tm_mday = bcd2bin(buf[RTC_DATE_REG_ADDR] & 0x3F);
+   tmp->tm_mon  = bcd2bin(buf[RTC_MON_REG_ADDR] & 0x1F);
+   tmp->tm_year = bcd2bin(buf[RTC_YR_REG_ADDR]) + 2000;
+   tmp->tm_wday = bcd2bin(buf[RTC_DAY_REG_ADDR] & 0x07);
tmp->tm_yday = 0;
tmp->tm_isdst= 0;
 
@@ -97,51 +91,88 @@ int rtc_get (struct rtc_time *tmp)
tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
 
-   return rel;
+   return 0;
 }
 
 /*
  * Set the RTC
  */
-int rtc_set (struct rtc_time *tmp)
+static int isl1208_rtc_set(struct udevice *dev, const struct rtc_time *tmp)
 {
+   int ret;
+   uchar val, buf[7];
+
DEBUGR ("Set DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
 
+   if (tmp->tm_year < 2000 || tmp->tm_year > 2099)
+   printf("WARNING: year should be between 2000 and 2099!\n");
+
/* enable write */
-   rtc_write(RTC_STAT_REG_ADDR,
-   rtc_read(RTC_STAT_RE

[U-Boot] [PATCH v1 1/2] rockchip: pinctrl: rk3399: fix GPIO2B1 and GPIO2B2 shift value

2018-03-12 Thread Klaus Goger
From: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

The shift values for GPIO2B1 and GPIO2B2 had in fact referred to
GPIO2B0 and GPIO2B1, respectively.  This substitutes the correct
values.

Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
---

 arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
index b541e2caa1..fbcec932b4 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
@@ -325,10 +325,10 @@ check_member(rk3399_pmusgrf_regs, slv_secure_con4, 
0xe3d4);
 
 enum {
/* GRF_GPIO2B_IOMUX */
-   GRF_GPIO2B1_SEL_SHIFT   = 0,
+   GRF_GPIO2B1_SEL_SHIFT   = 2,
GRF_GPIO2B1_SEL_MASK= 3 << GRF_GPIO2B1_SEL_SHIFT,
GRF_SPI2TPM_RXD = 1,
-   GRF_GPIO2B2_SEL_SHIFT   = 2,
+   GRF_GPIO2B2_SEL_SHIFT   = 4,
GRF_GPIO2B2_SEL_MASK= 3 << GRF_GPIO2B2_SEL_SHIFT,
GRF_SPI2TPM_TXD = 1,
GRF_GPIO2B3_SEL_SHIFT   = 6,
-- 
2.11.0

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


[U-Boot] [PATCH v1 2/2] rockchip: pinctrl: rk3399: add support for I2C[123467]

2018-03-12 Thread Klaus Goger
From: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

This adds support for the (to date unsupported) I2C controllers 1~4
and 6~7 (i.e. now all controllers except I2C5, which is not accessible
on the RK3399-Q7, are supported by pinctrl).

Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Tested-by: Klaus Goger <klaus.go...@theobroma-systems.com>

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
---

 arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 30 
 drivers/pinctrl/rockchip/pinctrl_rk3399.c   | 61 ++---
 2 files changed, 85 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
index fbcec932b4..91e8d2d216 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
@@ -324,13 +324,29 @@ struct rk3399_pmusgrf_regs {
 check_member(rk3399_pmusgrf_regs, slv_secure_con4, 0xe3d4);
 
 enum {
+   /* GRF_GPIO2A_IOMUX */
+   GRF_GPIO2A0_SEL_SHIFT   = 0,
+   GRF_GPIO2A0_SEL_MASK= 3 << GRF_GPIO2A0_SEL_SHIFT,
+   GRF_I2C2_SDA= 2,
+   GRF_GPIO2A1_SEL_SHIFT   = 2,
+   GRF_GPIO2A1_SEL_MASK= 3 << GRF_GPIO2A1_SEL_SHIFT,
+   GRF_I2C2_SCL= 2,
+   GRF_GPIO2A7_SEL_SHIFT   = 14,
+   GRF_GPIO2A7_SEL_MASK= 3 << GRF_GPIO2A7_SEL_SHIFT,
+   GRF_I2C7_SDA= 2,
+
/* GRF_GPIO2B_IOMUX */
+   GRF_GPIO2B0_SEL_SHIFT   = 0,
+   GRF_GPIO2B0_SEL_MASK= 3 << GRF_GPIO2B0_SEL_SHIFT,
+   GRF_I2C7_SCL= 2,
GRF_GPIO2B1_SEL_SHIFT   = 2,
GRF_GPIO2B1_SEL_MASK= 3 << GRF_GPIO2B1_SEL_SHIFT,
GRF_SPI2TPM_RXD = 1,
+   GRF_I2C6_SDA= 2,
GRF_GPIO2B2_SEL_SHIFT   = 4,
GRF_GPIO2B2_SEL_MASK= 3 << GRF_GPIO2B2_SEL_SHIFT,
GRF_SPI2TPM_TXD = 1,
+   GRF_I2C6_SCL= 2,
GRF_GPIO2B3_SEL_SHIFT   = 6,
GRF_GPIO2B3_SEL_MASK= 3 << GRF_GPIO2B3_SEL_SHIFT,
GRF_SPI2TPM_CLK = 1,
@@ -414,6 +430,14 @@ enum {
GRF_GPIO3C1_SEL_MASK= 3 << GRF_GPIO3C1_SEL_SHIFT,
GRF_MAC_TXCLK   = 1,
 
+   /* GRF_GPIO4A_IOMUX */
+   GRF_GPIO4A1_SEL_SHIFT   = 2,
+   GRF_GPIO4A1_SEL_MASK= 3 << GRF_GPIO4A1_SEL_SHIFT,
+   GRF_I2C1_SDA= 1,
+   GRF_GPIO4A2_SEL_SHIFT   = 4,
+   GRF_GPIO4A2_SEL_MASK= 3 << GRF_GPIO4A2_SEL_SHIFT,
+   GRF_I2C1_SCL= 1,
+
/* GRF_GPIO4B_IOMUX */
GRF_GPIO4B0_SEL_SHIFT   = 0,
GRF_GPIO4B0_SEL_MASK= 3 << GRF_GPIO4B0_SEL_SHIFT,
@@ -575,6 +599,12 @@ enum {
PMUGRF_GPIO1B2_SEL_SHIFT= 4,
PMUGRF_GPIO1B2_SEL_MASK = 3 << PMUGRF_GPIO1B2_SEL_SHIFT,
PMUGRF_SPI1EC_CSN0  = 2,
+   PMUGRF_GPIO1B3_SEL_SHIFT= 6,
+   PMUGRF_GPIO1B3_SEL_MASK = 3 << PMUGRF_GPIO1B3_SEL_SHIFT,
+   PMUGRF_I2C4_SDA = 1,
+   PMUGRF_GPIO1B4_SEL_SHIFT= 8,
+   PMUGRF_GPIO1B4_SEL_MASK = 3 << PMUGRF_GPIO1B4_SEL_SHIFT,
+   PMUGRF_I2C4_SCL = 1,
PMUGRF_GPIO1B6_SEL_SHIFT= 12,
PMUGRF_GPIO1B6_SEL_MASK = 3 << PMUGRF_GPIO1B6_SEL_SHIFT,
PMUGRF_PWM_3B   = 1,
diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3399.c 
b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
index 19a7415522..c7052257aa 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3399.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
@@ -70,6 +70,60 @@ static void pinctrl_rk3399_i2c_config(struct rk3399_grf_regs 
*grf,
 PMUGRF_GPIO1C0_SEL_MASK,
 PMUGRF_I2C0PMU_SCL << PMUGRF_GPIO1C0_SEL_SHIFT);
break;
+
+   case PERIPH_ID_I2C1:
+   rk_clrsetreg(>gpio4a_iomux,
+GRF_GPIO4A1_SEL_MASK,
+GRF_I2C1_SDA << GRF_GPIO4A1_SEL_SHIFT);
+   rk_clrsetreg(>gpio4a_iomux,
+GRF_GPIO4A2_SEL_MASK,
+GRF_I2C1_SCL << GRF_GPIO4A2_SEL_SHIFT);
+   break;
+
+   case PERIPH_ID_I2C2:
+   rk_clrsetreg(>gpio2a_iomux,
+GRF_GPIO2A0_SEL_MASK,
+GRF_I2C2_SDA << GRF_GPIO2A0_SEL_SHIFT);
+   rk_clrsetreg(>gpio2a_iomux,
+GRF_GPIO2A1_SEL_MASK,
+GRF_I2C2_SCL << GRF_GPIO2A1_SEL_SHIFT);
+   break;
+   case PERIPH_ID_I2C3:
+   rk_clrsetreg(>gpio4c_iomux,
+GRF_GPIO4C0_SEL_MASK,
+GRF_HDMII2C_SCL << GRF_GPIO4C0_SEL_SHIFT);
+   rk_clrsetreg(>gpio4c_iomux,
+GRF_GPIO4C1_SEL_MASK,

[U-Boot] [PATCH v1 0/2] Add pinctrl support for RK3399 I2C[123467]

2018-03-12 Thread Klaus Goger
This patch series adds support for the I2C controller 1-4 and 6-7


Philipp Tomsich (2):
  rockchip: pinctrl: rk3399: fix GPIO2B1 and GPIO2B2 shift value
  rockchip: pinctrl: rk3399: add support for I2C[123467]

 arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 34 +-
 drivers/pinctrl/rockchip/pinctrl_rk3399.c   | 61 ++---
 2 files changed, 87 insertions(+), 8 deletions(-)

-- 
2.11.0

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


[U-Boot] [PATCH] rockchip: add text_offset to kernel_addr_r on aarch64 platforms

2018-02-18 Thread Klaus Goger
Booting a aarch64 Linux kernel requires the image to be placed
text_offset bytes from a 2MB aligned address.
See https://www.kernel.org/doc/Documentation/arm64/booting.txt

booti_setup() takes care about this alignment and will relocate the
image if not properly aligned with memmove(). This can require up
to double the size of the loaded image and therefore accidentally
overwrite content placed there (i.e ramdisk_addr_r) for large kernel
images.

By adding text_offset to the default kernel_addr_r we can prevent that
from happening for kernels larger 18MB and also save a few cycles.

We can assume a text_offset of 0x8 for most cases, all others will be
handled by booti_setup() anyway.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>

---

 include/configs/rk3328_common.h | 2 +-
 include/configs/rk3399_common.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/rk3328_common.h b/include/configs/rk3328_common.h
index 7018668e00..517d058a11 100644
--- a/include/configs/rk3328_common.h
+++ b/include/configs/rk3328_common.h
@@ -42,7 +42,7 @@
"scriptaddr=0x0050\0" \
"pxefile_addr_r=0x0060\0" \
"fdt_addr_r=0x01f0\0" \
-   "kernel_addr_r=0x0200\0" \
+   "kernel_addr_r=0x0208\0" \
"ramdisk_addr_r=0x0400\0"
 
 #include 
diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index d700bf2549..8582252dc3 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -53,7 +53,7 @@
"scriptaddr=0x0050\0" \
"pxefile_addr_r=0x0060\0" \
"fdt_addr_r=0x01f0\0" \
-   "kernel_addr_r=0x0200\0" \
+   "kernel_addr_r=0x0208\0" \
"ramdisk_addr_r=0x0400\0"
 
 #include 
-- 
2.11.0

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


[U-Boot] [PATCH] spl: include timezone in banner

2018-01-03 Thread Klaus Goger
Include the timezone in the SPL banner so the timestamp matches with
that from u-boot proper.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

---
I know this is kind of a nitpick patch and we don't really have any space
to waste in SPL. But the inconsistency annoyed me after wasting some time 
figuring out why one of my testcases always failed due a regex not matching. 

The additional 6 bytes don't break any builds as verified with Travis-CI:
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/324694323

 common/spl/spl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 76c1963611..660e4011e6 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -478,7 +478,7 @@ void preloader_console_init(void)
gd->have_console = 1;
 
puts("\nU-Boot SPL " PLAIN_VERSION " (" U_BOOT_DATE " - " \
-   U_BOOT_TIME ")\n");
+   U_BOOT_TIME " " U_BOOT_TZ ")\n");
 #ifdef CONFIG_SPL_DISPLAY_PRINT
spl_display_print();
 #endif
-- 
2.11.0

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


[U-Boot] [PATCH] cmd: pmic: update help description

2018-01-03 Thread Klaus Goger
Change help description to match the style of the other U-Boot commands
and get rid of the leading whitespace.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>

---

 cmd/pmic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/pmic.c b/cmd/pmic.c
index 970767cdfa..7bf23fb2a9 100644
--- a/cmd/pmic.c
+++ b/cmd/pmic.c
@@ -201,7 +201,7 @@ static int do_pmic(cmd_tbl_t *cmdtp, int flag, int argc,
 }
 
 U_BOOT_CMD(pmic, CONFIG_SYS_MAXARGS, 1, do_pmic,
-   " operations",
+   "PMIC sub-system",
"list  - list pmic devices\n"
"pmic dev [name]- show or [set] operating PMIC device\n"
"pmic dump  - dump registers\n"
-- 
2.11.0

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


[U-Boot] [PATCH] rockchip: move CONFIG_ENV_SIZE and CONFIG_ENV_OFFSET to Kconfig

2017-12-11 Thread Klaus Goger
These settings are not not user visible via a menuconfig prompt. This is
necessary to have the possibility to select new default values if
CONFIG_IS_IN_* is changed (interactively or with oldconfig). Otherwise it
will always be set to a previous value if used with a prompt.
As an example if we do a defconfig with CONFIG_IS_IN_MMC and change it to
CONFIG_IS_IN_SPI_FLASH via menuconfig, ENV_SIZE and ENV_OFFSET will not
be changed to the correct values as defconfig will already have set them
to the default values of CONFIG_IS_IN_MMC in .config.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>

---

 board/theobroma-systems/puma_rk3399/Kconfig |  6 ++
 env/Kconfig | 19 +++
 include/configs/puma_rk3399.h   |  8 
 include/configs/rockchip-common.h   |  6 --
 4 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/board/theobroma-systems/puma_rk3399/Kconfig 
b/board/theobroma-systems/puma_rk3399/Kconfig
index a645590d78..80b3460d4c 100644
--- a/board/theobroma-systems/puma_rk3399/Kconfig
+++ b/board/theobroma-systems/puma_rk3399/Kconfig
@@ -12,4 +12,10 @@ config SYS_CONFIG_NAME
 config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
 
+config ENV_SIZE
+   default 0x2000 if ENV_IS_IN_SPI_FLASH
+
+config ENV_OFFSET
+   default 0x3c000 if ENV_IS_IN_SPI_FLASH
+
 endif
diff --git a/env/Kconfig b/env/Kconfig
index 2477bf8530..12c6d80785 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -427,4 +427,23 @@ config ENV_UBI_VOLUME
 
 endif
 
+if ARCH_ROCKCHIP
+
+config ENV_OFFSET
+   hex
+   depends on !ENV_IS_IN_UBI
+   depends on !ENV_IS_NOWHERE
+   default 0x3f8000
+   help
+ Offset from the start of the device (or partition)
+
+config ENV_SIZE
+   hex
+   depends on !ENV_IS_NOWHERE
+   default 0x8000
+   help
+ Size of the environment storage area
+
+endif
+
 endmenu
diff --git a/include/configs/puma_rk3399.h b/include/configs/puma_rk3399.h
index 39d0786266..6523a7c34a 100644
--- a/include/configs/puma_rk3399.h
+++ b/include/configs/puma_rk3399.h
@@ -9,14 +9,6 @@
 
 #include 
 
-/*
- * SPL @ 32kB for ~130kB
- * ENV @ 240KB for 8kB
- * FIT payload (ATF, U-Boot, FDT) @ 256kB
- */
-#undef CONFIG_ENV_OFFSET
-#define CONFIG_ENV_OFFSET (240 * 1024)
-
 #if defined(CONFIG_ENV_IS_IN_MMC)
 #define CONFIG_SYS_MMC_ENV_DEV 1
 #elif defined(CONFIG_ENV_IS_IN_SPI_FLASH)
diff --git a/include/configs/rockchip-common.h 
b/include/configs/rockchip-common.h
index 35d948ae29..9da6dcaf72 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -61,12 +61,6 @@
 
 #endif
 
-/*
- * Rockchip SoCs use fixed ENV 32KB@(4MB-32KB)
- */
-#define CONFIG_ENV_OFFSET  (SZ_4M - SZ_32K)
-#define CONFIG_ENV_SIZESZ_32K
-
 #define CONFIG_DISPLAY_BOARDINFO_LATE
 
 #endif /* _ROCKCHIP_COMMON_H_ */
-- 
2.11.0

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


[U-Boot] [PATCH] rockchip: board: puma-rk3399: define ENV_SIZE for SPI FLASH

2017-12-07 Thread Klaus Goger
be942f2e0d introduced a common CONFIG_ENV_SIZE of 32k in rockchip-common.h
On puma-rk3399 with ENV_IN_SPI active we place the environment in the
gap between SPL and the FIT image. Previously undefined it defaulted to
one sector defined with CONFIG_ENV_SECT_SIZE. With the now larger
environment a saveenv overwrites the FIT image. Therefore we now
redefine CONFIG_ENV_SIZE if build for ENV_IS_IN_SPI_FLASH.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>

---

 include/configs/puma_rk3399.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/puma_rk3399.h b/include/configs/puma_rk3399.h
index 39d0786266..c9d475ebbb 100644
--- a/include/configs/puma_rk3399.h
+++ b/include/configs/puma_rk3399.h
@@ -20,6 +20,8 @@
 #if defined(CONFIG_ENV_IS_IN_MMC)
 #define CONFIG_SYS_MMC_ENV_DEV 1
 #elif defined(CONFIG_ENV_IS_IN_SPI_FLASH)
+#undef CONFIG_ENV_SIZE
+#define CONFIG_ENV_SIZESZ_8K
 #define CONFIG_ENV_SECT_SIZE   (8 * 1024)
 #define CONFIG_ENV_SPI_BUS CONFIG_SF_DEFAULT_BUS
 #define CONFIG_ENV_SPI_CS  CONFIG_SF_DEFAULT_CS
-- 
2.11.0

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


[U-Boot] [PATCH v4 2/2] rockchip: configs: use rockchip-common.h for rk3368

2017-10-06 Thread Klaus Goger
rockchip-common.h already defines values that are missing from
rk3368_common.h

For example BOOT_TARGET_DEVICES was defined empty and therefore
distroboot had no boot targets.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 include/configs/rk3368_common.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
index 8b4155f37c..b643cc2464 100644
--- a/include/configs/rk3368_common.h
+++ b/include/configs/rk3368_common.h
@@ -7,6 +7,8 @@
 #ifndef __CONFIG_RK3368_COMMON_H
 #define __CONFIG_RK3368_COMMON_H
 
+#include "rockchip-common.h"
+
 #define CONFIG_SYS_CACHELINE_SIZE  64
 
 #include 
@@ -44,10 +46,6 @@
"kernel_addr_r=0x28\0" \
"ramdisk_addr_r=0x5bf\0"
 
-#include 
-
-#define BOOT_TARGET_DEVICES(func)
-
 #include 
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-- 
2.11.0

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


[U-Boot] [PATCH v4 1/2] rockchip: configs: only add available BOOT_TARGET_DEVICES

2017-10-06 Thread Klaus Goger
BOOT_TARGET_DEVICES should only be added if the corresponding u-boot
command is enabled.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

---

Changes in v4:
- rebase on mаster

Changes in v3:
- Use CONFIG_IS_ENABLED macro instead of #ifdefs
- Add missing else path

Changes in v2:
- Add patch to series to prevent build errors if boards don't enable the
  required u-boot command for distroboot

 include/configs/rockchip-common.h | 43 +++
 1 file changed, 30 insertions(+), 13 deletions(-)

diff --git a/include/configs/rockchip-common.h 
b/include/configs/rockchip-common.h
index 5e9b6deb48..96b5fce46f 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -11,22 +11,39 @@
 #ifndef CONFIG_SPL_BUILD
 #include 
 
-/* First try to boot from SD (index 0), then eMMC (index 1 */
-#ifdef CONFIG_CMD_USB
-#define BOOT_TARGET_DEVICES(func) \
-   func(MMC, mmc, 0) \
-   func(MMC, mmc, 1) \
-   func(USB, usb, 0) \
-   func(PXE, pxe, na) \
-   func(DHCP, dchp, na)
+/* First try to boot from SD (index 0), then eMMC (index 1) */
+#if CONFIG_IS_ENABLED(CMD_MMC)
+   #define BOOT_TARGET_MMC(func) \
+   func(MMC, mmc, 0) \
+   func(MMC, mmc, 1)
 #else
-#define BOOT_TARGET_DEVICES(func) \
-   func(MMC, mmc, 0) \
-   func(MMC, mmc, 1) \
-   func(PXE, pxe, na) \
-   func(DHCP, dchp, na)
+   #define BOOT_TARGET_MMC(func)
 #endif
 
+#if CONFIG_IS_ENABLED(CMD_USB)
+   #define BOOT_TARGET_USB(func) func(USB, usb, 0)
+#else
+   #define BOOT_TARGET_USB(func)
+#endif
+
+#if CONFIG_IS_ENABLED(CMD_PXE)
+   #define BOOT_TARGET_PXE(func) func(PXE, pxe, na)
+#else
+   #define BOOT_TARGET_PXE(func)
+#endif
+
+#if CONFIG_IS_ENABLED(CMD_DHCP)
+   #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na)
+#else
+   #define BOOT_TARGET_DHCP(func)
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+   BOOT_TARGET_MMC(func) \
+   BOOT_TARGET_USB(func) \
+   BOOT_TARGET_PXE(func) \
+   BOOT_TARGET_DHCP(func)
+
 #ifdef CONFIG_ARM64
 #define ROOT_UUID "B921B045-1DF0-41C3-AF44-4C6F280D3FAE;\0"
 #else
-- 
2.11.0

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


[U-Boot] [PATCH v3 2/2] rockchip: configs: use rockchip-common.h for rk3368

2017-10-06 Thread Klaus Goger
rockchip-common.h already defines values that are missing from
rk3368_common.h

For example BOOT_TARGET_DEVICES was defined empty and therefore
distroboot had no boot targets.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

---

Changes in v3: None
Changes in v2: None

 include/configs/rk3368_common.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
index 8b4155f37c..b643cc2464 100644
--- a/include/configs/rk3368_common.h
+++ b/include/configs/rk3368_common.h
@@ -7,6 +7,8 @@
 #ifndef __CONFIG_RK3368_COMMON_H
 #define __CONFIG_RK3368_COMMON_H
 
+#include "rockchip-common.h"
+
 #define CONFIG_SYS_CACHELINE_SIZE  64
 
 #include 
@@ -44,10 +46,6 @@
"kernel_addr_r=0x28\0" \
"ramdisk_addr_r=0x5bf\0"
 
-#include 
-
-#define BOOT_TARGET_DEVICES(func)
-
 #include 
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-- 
2.11.0

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


[U-Boot] [PATCH v3 1/2] rockchip: configs: only add available BOOT_TARGET_DEVICES

2017-10-06 Thread Klaus Goger
BOOT_TARGET_DEVICES should only be added if the corresponding u-boot
command is enabled.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

---

Changes in v3:
- Use CONFIG_IS_ENABLED macro instead of #ifdefs
- Add missing else path

Changes in v2:
- Add patch to series to prevent build errors if boards don't enable the
  required u-boot command for distroboot

 include/configs/rockchip-common.h | 43 +++
 1 file changed, 30 insertions(+), 13 deletions(-)

diff --git a/include/configs/rockchip-common.h 
b/include/configs/rockchip-common.h
index 2d190a964a..a57ba1118f 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -11,22 +11,39 @@
 #ifndef CONFIG_SPL_BUILD
 #include 
 
-/* First try to boot from SD (index 0), then eMMC (index 1 */
-#ifdef CONFIG_CMD_USB
-#define BOOT_TARGET_DEVICES(func) \
-   func(MMC, mmc, 0) \
-   func(MMC, mmc, 1) \
-   func(USB, usb, 0) \
-   func(PXE, pxe, na) \
-   func(DHCP, dhcp, na)
+/* First try to boot from SD (index 0), then eMMC (index 1) */
+#if CONFIG_IS_ENABLED(CMD_MMC)
+   #define BOOT_TARGET_MMC(func) \
+   func(MMC, mmc, 0) \
+   func(MMC, mmc, 1)
 #else
-#define BOOT_TARGET_DEVICES(func) \
-   func(MMC, mmc, 0) \
-   func(MMC, mmc, 1) \
-   func(PXE, pxe, na) \
-   func(DHCP, dhcp, na)
+   #define BOOT_TARGET_MMC(func)
 #endif
 
+#if CONFIG_IS_ENABLED(CMD_USB)
+   #define BOOT_TARGET_USB(func) func(USB, usb, 0)
+#else
+   #define BOOT_TARGET_USB(func)
+#endif
+
+#if CONFIG_IS_ENABLED(CMD_PXE)
+   #define BOOT_TARGET_PXE(func) func(PXE, pxe, na)
+#else
+   #define BOOT_TARGET_PXE(func)
+#endif
+
+#if CONFIG_IS_ENABLED(CMD_DHCP)
+   #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na)
+#else
+   #define BOOT_TARGET_DHCP(func)
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+   BOOT_TARGET_MMC(func) \
+   BOOT_TARGET_USB(func) \
+   BOOT_TARGET_PXE(func) \
+   BOOT_TARGET_DHCP(func)
+
 #define CONFIG_RANDOM_UUID
 
 #ifdef CONFIG_ARM64
-- 
2.11.0

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


[U-Boot] [PATCH v2 2/2] rockchip: configs: use rockchip-common.h for rk3368

2017-10-06 Thread Klaus Goger
rockchip-common.h already defines values that are missing from
rk3368_common.h

For example BOOT_TARGET_DEVICES was defined empty and therefore
distroboot had no boot targets.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

---

Changes in v2: None

 include/configs/rk3368_common.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
index 8b4155f37c..b643cc2464 100644
--- a/include/configs/rk3368_common.h
+++ b/include/configs/rk3368_common.h
@@ -7,6 +7,8 @@
 #ifndef __CONFIG_RK3368_COMMON_H
 #define __CONFIG_RK3368_COMMON_H
 
+#include "rockchip-common.h"
+
 #define CONFIG_SYS_CACHELINE_SIZE  64
 
 #include 
@@ -44,10 +46,6 @@
"kernel_addr_r=0x28\0" \
"ramdisk_addr_r=0x5bf\0"
 
-#include 
-
-#define BOOT_TARGET_DEVICES(func)
-
 #include 
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-- 
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] rockchip: configs: only add available BOOT_TARGET_DEVICES

2017-10-06 Thread Klaus Goger
BOOT_TARGET_DEVICES should only be added if the corresponding u-boot
command is enabled.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
---

Changes in v2:
- Add patch to series to prevent build errors if boards don't enable the
  required u-boot command for distroboot

 include/configs/rockchip-common.h | 39 +++
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/include/configs/rockchip-common.h 
b/include/configs/rockchip-common.h
index 2d190a964a..3292525fd5 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -11,22 +11,37 @@
 #ifndef CONFIG_SPL_BUILD
 #include 
 
-/* First try to boot from SD (index 0), then eMMC (index 1 */
+/* First try to boot from SD (index 0), then eMMC (index 1) */
+#ifdef CONFIG_CMD_MMC
+   #define BOOT_TARGET_MMC(func) \
+   func(MMC, mmc, 0) \
+   func(MMC, mmc, 1)
+#else
+   #define BOOT_TARGET_MMC(func)
+#endif
+
 #ifdef CONFIG_CMD_USB
-#define BOOT_TARGET_DEVICES(func) \
-   func(MMC, mmc, 0) \
-   func(MMC, mmc, 1) \
-   func(USB, usb, 0) \
-   func(PXE, pxe, na) \
-   func(DHCP, dhcp, na)
+   #define BOOT_TARGET_USB(func) func(USB, usb, 0)
 #else
-#define BOOT_TARGET_DEVICES(func) \
-   func(MMC, mmc, 0) \
-   func(MMC, mmc, 1) \
-   func(PXE, pxe, na) \
-   func(DHCP, dhcp, na)
+   #define BOOT_TARGET_USB(func)
+#endif
+
+#if CONFIG_CMD_PXE
+   #define BOOT_TARGET_PXE(func) func(PXE, pxe, na)
+#else
+   #define BOOT_TARGET_PXE(func)
+#endif
+
+#if CONFIG_CMD_DHCP
+   #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na)
 #endif
 
+#define BOOT_TARGET_DEVICES(func) \
+   BOOT_TARGET_MMC(func) \
+   BOOT_TARGET_USB(func) \
+   BOOT_TARGET_PXE(func) \
+   BOOT_TARGET_DHCP(func)
+
 #define CONFIG_RANDOM_UUID
 
 #ifdef CONFIG_ARM64
-- 
2.11.0

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


[U-Boot] [PATCH] rockchip: configs: use rockchip-common.h for rk3368

2017-10-06 Thread Klaus Goger
rockchip-common.h already defines values that are missing from
rk3368_common.h

For example BOOT_TARGET_DEVICES was defined empty and therefore
distroboot had no boot targets.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>

---

 include/configs/rk3368_common.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
index 8b4155f37c..b643cc2464 100644
--- a/include/configs/rk3368_common.h
+++ b/include/configs/rk3368_common.h
@@ -7,6 +7,8 @@
 #ifndef __CONFIG_RK3368_COMMON_H
 #define __CONFIG_RK3368_COMMON_H
 
+#include "rockchip-common.h"
+
 #define CONFIG_SYS_CACHELINE_SIZE  64
 
 #include 
@@ -44,10 +46,6 @@
"kernel_addr_r=0x28\0" \
"ramdisk_addr_r=0x5bf\0"
 
-#include 
-
-#define BOOT_TARGET_DEVICES(func)
-
 #include 
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-- 
2.11.0

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


[U-Boot] [PATCH] rockchip: configs: fix typo in BOOT_TARGET_DEVICES

2017-10-06 Thread Klaus Goger
dchp should be dhcp. fixed copy-paste versions too.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>

---

 include/configs/rockchip-common.h | 4 ++--
 include/configs/tinker_rk3288.h   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/rockchip-common.h 
b/include/configs/rockchip-common.h
index b3986c28af..2d190a964a 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -18,13 +18,13 @@
func(MMC, mmc, 1) \
func(USB, usb, 0) \
func(PXE, pxe, na) \
-   func(DHCP, dchp, na)
+   func(DHCP, dhcp, na)
 #else
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
func(MMC, mmc, 1) \
func(PXE, pxe, na) \
-   func(DHCP, dchp, na)
+   func(DHCP, dhcp, na)
 #endif
 
 #define CONFIG_RANDOM_UUID
diff --git a/include/configs/tinker_rk3288.h b/include/configs/tinker_rk3288.h
index 58eea3c405..15f5fc538a 100644
--- a/include/configs/tinker_rk3288.h
+++ b/include/configs/tinker_rk3288.h
@@ -16,7 +16,7 @@
func(MMC, mmc, 1) \
func(USB, usb, 0) \
func(PXE, pxe, na) \
-   func(DHCP, dchp, na)
+   func(DHCP, dhcp, na)
 
 #define CONFIG_SYS_MMC_ENV_DEV 1
 
-- 
2.11.0

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


[U-Boot] [PATCH] dm: ofnode: query correct property in livetree ofnode_get_addr_size

2017-09-20 Thread Klaus Goger
The livetree codepath of ofnode_get_addr_size always used the "reg"
property for of_get_property. Use the property parameter of the function
call instead and check the return value if the property exists.
Otherwise return FDT_ADDR_T_NONE.

This was discoverd while using SPI NOR with livetree.
spi_flash_decode_fdt checks for memory-map and will not fail with
livetree even if the property does not exist.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

---

 drivers/core/ofnode.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index c6ca13fabf..0030ab962e 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -468,8 +468,10 @@ fdt_addr_t ofnode_get_addr_size(ofnode node, const char 
*property,
int na, ns;
int psize;
const struct device_node *np = ofnode_to_np(node);
-   const __be32 *prop = of_get_property(np, "reg", );
+   const __be32 *prop = of_get_property(np, property, );
 
+   if (!prop)
+   return FDT_ADDR_T_NONE;
na = of_n_addr_cells(np);
ns = of_n_addr_cells(np);
*sizep = of_read_number(prop + na, ns);
-- 
2.11.0

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


[U-Boot] [PATCH] rockchip: puma_rk3399: increase serialno_str size

2017-09-15 Thread Klaus Goger
Increase serialno_str to 17 bytes so it can hold the 16 bytes long serial
nummer and the terminating null byte added by snprintf.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>

---

 board/theobroma-systems/puma_rk3399/puma-rk3399.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c 
b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index b49fa66fb3..dab37d2673 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -96,7 +96,7 @@ static void setup_serial(void)
u8 low[cpuid_length/2], high[cpuid_length/2];
char cpuid_str[cpuid_length * 2 + 1];
u64 serialno;
-   char serialno_str[16];
+   char serialno_str[17];
 
/* retrieve the device */
ret = uclass_get_device_by_driver(UCLASS_MISC,
-- 
2.11.0

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


[U-Boot] [PATCH v2 2/2] rockchip: board: puma_rk3399: update README flash instructions

2017-09-11 Thread Klaus Goger
Puma supports other boot sources then SD-Card. Update README to include
the required steps.

 * how to package a SPI-NOR SPL
 * how to flash eMMC with rkdeveloptool

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

---

Changes in v2:
- add missing ./configure step while building rkdeveloptool

 board/theobroma-systems/puma_rk3399/README | 51 +-
 1 file changed, 43 insertions(+), 8 deletions(-)

diff --git a/board/theobroma-systems/puma_rk3399/README 
b/board/theobroma-systems/puma_rk3399/README
index 214281a329..f67dfb451f 100644
--- a/board/theobroma-systems/puma_rk3399/README
+++ b/board/theobroma-systems/puma_rk3399/README
@@ -55,18 +55,53 @@ Compile the U-Boot
 Package the image
 =
 
-   > tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin spl.img
-   > make CROSS_COMPILE=aarch64-linux-gnu- u-boot.itb
+Creating a SPL image for SD-Card/eMMC
+  > tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin spl_mmc.img
+Creating a SPL image for SPI-NOR
+  > tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin spl_nor.img
+Create the FIT image containing U-Boot proper, ATF, M0 Firmware, devicetree
+  > make CROSS_COMPILE=aarch64-linux-gnu- u-boot.itb
 
 Flash the image
 ===
 
-Copy the SPL to offset 32k and the FIT image containing the payloads
-(U-Boot proper, ATF, M0 Firmware, devicetree) to offset 256k on a SD
-card.
+Copy the SPL to offset 32k for SD/eMMC, offset 0 for NOR-Flash and the FIT
+image to offset 256k card.
 
-  > dd if=spl.img of=/dev/sdb seek=64
+SD-Card
+---
+
+  > dd if=spl_mmc.img of=/dev/sdb seek=64
   > dd if=u-boot.itb of=/dev/sdb seek=512
 
-After powering up the board (with the inserted SD card), you should see
-a U-Boot console on UART0 (115200n8).
+eMMC
+
+
+rkdeveloptool allows to flash the on-board eMMC via the USB OTG interface with
+help of the Rockchip loader binary.
+
+  > git clone https://github.com/rockchip-linux/rkdeveloptool
+  > cd rkdeveloptool
+  > autoreconf -i && ./configure && make
+  > git clone https://github.com/rockchip-linux/rkbin.git
+  > ./rkdeveloptool db rkbin/rk33/rk3399_loader_v1.08.106.bin
+  > ./rkdeveloptool wl 64 ../spl_mmc.img
+  > ./rkdeveloptool wl 512 ../u-boot.itb
+
+NOR-Flash
+-
+
+Writing the SPI NOR Flash requires a running U-Boot. For the sake of simplicity
+we assume you have a SD-Card with a partition containing the required files
+ready.
+
+  > load mmc 1:1 ${kernel_addr_r} spl_nor.img
+  > sf probe
+  > sf erase 0 +$filesize
+  > sf write $kernel_addr_r 0 ${filesize}
+  > load mmc 1:1 ${kernel_addr_r} u-boot.itb
+  > sf erase 0x4 +$filesize
+  > sf write $kernel_addr_r 0x4 ${filesize}
+
+
+Reboot the system and you should see a U-Boot console on UART0 (115200n8).
-- 
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] rockchip: board: lion_rk3368: update README flash instructions

2017-09-11 Thread Klaus Goger
Add a section to the README on how to flash the on-board eMMC
with the rkdeveloptool.

Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com>
Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
---

Changes in v2: None

 board/theobroma-systems/lion_rk3368/README | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/board/theobroma-systems/lion_rk3368/README 
b/board/theobroma-systems/lion_rk3368/README
index 47304fcba6..83e4332984 100644
--- a/board/theobroma-systems/lion_rk3368/README
+++ b/board/theobroma-systems/lion_rk3368/README
@@ -26,12 +26,32 @@ Build the full U-Boot and a FIT image including the ATF
 
   > make CROSS_COMPILE=aarch64-unknown-elf- ARCH=arm u-boot.itb
 
-Write to a SD-card
-==
+Flash the image
+===
+
+Copy the SPL to offset 32k and the FIT image containing the payloads
+(U-Boot proper, ATF, devicetree) to offset 256k card.
+
+SD-Card
+---
 
   > dd if=spl-3368.img of=/dev/sdb seek=64
   > dd if=u-boot.itb of=/dev/sdb seek=512
 
+eMMC
+
+
+rkdeveloptool allows to flash the on-board eMMC via the USB OTG interface with
+help of the Rockchip loader binary.
+
+  > git clone https://github.com/rockchip-linux/rkdeveloptool
+  > cd rkdeveloptool
+  > autoreconf -i && && ./configure && make
+  > git clone https://github.com/rockchip-linux/rkbin.git
+  > ./rkdeveloptool db rkbin/rk33/rk3368_loader_v2.00.256.bin
+  > ./rkdeveloptool wl 64 ../spl.img
+  > ./rkdeveloptool wl 512 ../u-boot.itb
+
 
 If everything went according to plan, you should see the following
 output on UART0:
-- 
2.11.0

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


Re: [U-Boot] [PATCH] rockchip: pinctrl: rk3399: add gmac io strength support

2017-04-20 Thread Klaus Goger

> On 20 Apr 2017, at 10:48, Dr. Philipp Tomsich 
>  wrote:
> 
>> On 20 Apr 2017, at 10:44, Kever Yang  wrote:
>> 
>> Hi Philipp,
>>> 
>>> 
>>> Do you know if this is required for all board designs?
>>> We have a total run length of less than 2cm to the KSZ9031 PHY and wondered 
>>> about this ourselves—our testing has shown that with these small distances 
>>> (and the PHY we use) the setting doesn’t seem to be required.
>> 
>> If your layout is very good, it might work without this patch, did you test 
>> with 1000M Ethernet on many boards?
>> With patch, we can keep the setting with kernel and make sure all the 
>> hardware able to work at 1000M mode.
>> The firefly-rk3399 and rockchip rk3399-evb can't work at 1000M Ethernet mode 
>> without this patch.
> 
> Yes, we have full GbE in U-Boot (without this change) across the entire board 
> population of our initial batch.
> This is most likely due to the very short distance between the RK3399 and PHY 
> (there isn’t really an alternative
> to having it close due to the size constraints of the module).

Just for completeness, Linux with default drive strength (_pull_none) 
works on puma-rk3399 too.
Tested with iperf3 we get about 935Mbit with zero RX/TX errors.

Regards,
Klaus

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


Re: [U-Boot] [PATCH] mx6: gpio: read data register if direction is out

2014-06-24 Thread Klaus Goger
On Jun 24, 2014, at 3:13 PM, Fabio Estevam feste...@gmail.com wrote:

 On Tue, Jun 24, 2014 at 10:07 AM, Stefano Babic sba...@denx.de wrote:
 
 What you are describing looks an issue in your pinmux configuration
 because you do not set the SION bit, as requested to read back the value
 of the GPIO from the Pad Register.
 
 Yes, correct.
 
 Klaus, please check this commit:
 
 commit 7773fd196918826ebaab769e63a4775607f5256c
 Author: Otavio Salvador ota...@ossystems.com.br
 Date:   Mon Dec 16 20:44:00 2013 -0200
 
imx: Easy enabling of SION per-pin using MUX_MODE_SION helper macro

Using the MUX_MODE_SION macro helped indeed.
Thank you Stefano and Fabio.

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


[U-Boot] [PATCH] mx6: gpio: read data register if direction is out

2014-06-23 Thread Klaus Goger
On i.MX6 GPIOx_PSR does not reflect the current output value if the
direction is set to output. Instead we should read GPIOx_DR.

Signed-off-by: Klaus Goger klaus.go...@theobroma-systems.com
---
 drivers/gpio/mxc_gpio.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
index 6a572d5..5838fc2 100644
--- a/drivers/gpio/mxc_gpio.c
+++ b/drivers/gpio/mxc_gpio.c
@@ -101,8 +101,16 @@ int gpio_get_value(unsigned gpio)
gpio = 0x1f;
 
regs = (struct gpio_regs *)gpio_ports[port];
-
+#if defined(CONFIG_MX6)
+   /* if the direction is set to output we will always read 0 as pad 
status.
+* so we have to read the data register to get the current output state 
*/
+   if (readl(regs-gpio_dir)  gpio  0x01)
+   val = (readl(regs-gpio_dr)  gpio  0x01);
+   else
+   val = (readl(regs-gpio_psr)  gpio)  0x01;
+#else
val = (readl(regs-gpio_psr)  gpio)  0x01;
+#endif
 
return val;
 }
-- 
1.9.0

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