Re: [PATCH 4/7] rockchip: Remove ARCH= references from documentation
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
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
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
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
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
> 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
> 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
> 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
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
> 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
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
Hi Tom, > On 25.05.2018, at 14:01, Tom Riniwrote: > > 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
> On 09.05.2018, at 10:19, Markus Krebswrote: > > 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
> On 07.05.2018, at 10:25, Chris Packhamwrote: > > 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)
> On 06.05.2018, at 16:25, Marty E. Plummerwrote: > > 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
> On 06.05.2018, at 22:03, Marty E. Plummerwrote: > > 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
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. Plummerwrote: > > 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
Hi Kever > On 04.05.2018, at 10:50, Kever Yangwrote: > > 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.
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
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
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
> 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
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.
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
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
> 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
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
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
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
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
> 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
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
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]
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]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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