Re: [U-Boot] [PATCH v3 6/8] distro: Extend with RISC-V defines
On 04/23/2018 07:59 AM, Alexander Graf wrote: While we don't have UEFI naming conventions for RISC-V file paths yet, we need to search for something. So let's copy the removable file paths from the RISC-V edk2 port. Also add the official VCI strings that contain the standardized RISC-V architecture ID fields. Signed-off-by: Alexander Graf Reviewed-by: Heinrich Schuchardt --- v1 -> v2: - Use edk2 default boot file names v2 -> v3: - Use official values for vci --- include/config_distro_bootcmd.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index f567cebd38..989b5556af 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -100,6 +100,10 @@ #define BOOTEFI_NAME "bootia32.efi" #elif defined(CONFIG_X86_RUN_64BIT) #define BOOTEFI_NAME "bootx64.efi" +#elif defined(CONFIG_CPU_RISCV_32) +#define BOOTEFI_NAME "bootriscv32.efi" +#elif defined(CONFIG_CPU_RISCV_64) +#define BOOTEFI_NAME "bootriscv64.efi" #endif #endif @@ -241,6 +245,7 @@ #if defined(CONFIG_CMD_DHCP) #if defined(CONFIG_EFI_LOADER) +/* http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml */ #if defined(CONFIG_ARM64) #define BOOTENV_EFI_PXE_ARCH "0xb" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00011:UNDI:003000" @@ -251,6 +256,12 @@ /* Always assume we're running 64bit */ #define BOOTENV_EFI_PXE_ARCH "0x7" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:7:UNDI:003000" +#elif defined(CONFIG_CPU_RISCV_32) +#define BOOTENV_EFI_PXE_ARCH "0x19" +#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00025:UNDI:003000" +#elif defined(CONFIG_CPU_RISCV_64) +#define BOOTENV_EFI_PXE_ARCH "0x1b" +#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00027:UNDI:003000" #else #error Please specify an EFI client identifier #endif ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] sunxi: mmc: Fix phase delays
On Thu, Mar 29, 2018 at 6:52 PM, Maxime Ripard wrote: > On Tue, Mar 27, 2018 at 04:57:23PM +0300, Stefan Mavrodiev wrote: >> U-boot driver for sunxi-mmc uses PLL6, unlike linux kernel where >> PLL5 is used, with clock rates respectively 600MHz and 768MHz. >> Thus there are different phase degree steps - 24 for the kernel and >> 30 for u-boot. >> >> In the kernel driver the phase is set 90 deg for output and 120 for >> sample. Dividing by 30 will result values 3 and 4. Those are the >> values set in the u-boot driver. >> >> However, the condition defining delays is wrong. MMC core driver >> requests clock of 52MHz, sunxi-driver sets clock of 50MHz, but >> phase is set 30 deg for output and 120 deg for sample. >> >> Apparently this works for most cards. >> On A20-SOM204-EVB-eMMC there is eMMC card (KLMAG2GEND) which complains >> about it. Maybe there is other boards with similar problem? >> So the fix is to match delays for both u-boot and kernel. >> >> Signed-off-by: Stefan Mavrodiev > > Acked-by: Maxime Ripard Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: Add minimal support for Cortex-R5
On 23.4.2018 05:53, Lokesh Vutla wrote: > > > On Friday 20 April 2018 07:21 PM, Michal Simek wrote: >> This minimal support will be used by Xilinx ZynqMP R5 cpu. >> >> Signed-off-by: Michal Simek >> --- >> >> arch/arm/Kconfig | 6 ++ >> arch/arm/cpu/armv7r/Makefile | 4 >> arch/arm/cpu/armv7r/config.mk | 3 +++ >> arch/arm/cpu/armv7r/cpu.c | 24 >> arch/arm/cpu/armv7r/start.S | 17 + >> 5 files changed, 54 insertions(+) >> create mode 100644 arch/arm/cpu/armv7r/Makefile >> create mode 100644 arch/arm/cpu/armv7r/config.mk >> create mode 100644 arch/arm/cpu/armv7r/cpu.c >> create mode 100644 arch/arm/cpu/armv7r/start.S >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index b5fbce03667d..b10804f55224 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -192,6 +192,10 @@ config CPU_V7M >> select THUMB2_KERNEL >> select SYS_CACHE_SHIFT_5 >> >> +config CPU_V7R >> +bool >> +select SYS_CACHE_SHIFT_6 > > select HAS_THUMB2 might be a good option? I didn't enable it because I didn't test it. It can be added when someone tests this. > >> + >> config CPU_PXA >> bool >> select SYS_CACHE_SHIFT_5 >> @@ -209,6 +213,7 @@ config SYS_CPU >> default "arm1176" if CPU_ARM1176 >> default "armv7" if CPU_V7 >> default "armv7m" if CPU_V7M >> +default "armv7r" if CPU_V7R >> default "pxa" if CPU_PXA >> default "sa1100" if CPU_SA1100 >> default "armv8" if ARM64 >> @@ -223,6 +228,7 @@ config SYS_ARM_ARCH >> default 6 if CPU_ARM1176 >> default 7 if CPU_V7 >> default 7 if CPU_V7M >> +default 7 if CPU_V7R >> default 5 if CPU_PXA >> default 4 if CPU_SA1100 >> default 8 if ARM64 > > I did a grep of CPU_V7, and you might want to update for CPU_V7R in the > following places: > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 4fa8b38397..f4bc1f250d 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -18,6 +18,7 @@ arch-$(CONFIG_CPU_ARM1136) =-march=armv5 > arch-$(CONFIG_CPU_ARM1176) =-march=armv5t > arch-$(CONFIG_CPU_V7)=$(call cc-option, -march=armv7-a, \ >$(call cc-option, -march=armv7, -march=armv5)) > +arch-$(CONFIG_CPU_V7R) =-march=armv7-r I have setup PLATFORM_CPPFLAGS via config.mk If both options are selected I am getting this compilation warning. cc1: warning: switch -mcpu=cortex-r5 conflicts with -march=armv7-r switch Not sure which one is better or if it is better to have this arch flag via this makefile or as platform cppflags via config.mk. I choose the second option because it seems to me better if this is in subfolder. But not a problem to use different flag and put it to this Makefile. The same style is used for cpu_v7m. > arch-$(CONFIG_ARM64) =-march=armv8-a > > # On Tegra systems we must build SPL for the armv4 core on the device > @@ -41,6 +42,7 @@ tune-$(CONFIG_CPU_PXA) =-mcpu=xscale > tune-$(CONFIG_CPU_ARM1136) = > tune-$(CONFIG_CPU_ARM1176) = > tune-$(CONFIG_CPU_V7)= > +tune-$(CONFIG_CPU_V7R) = Again as above. I used v7m as pattern and there is also empty tune parameter. Is there any good reason to have it empty? > tune-$(CONFIG_ARM64) = > > # Evaluate tune cc-option calls now > > >> diff --git a/arch/arm/cpu/armv7r/Makefile b/arch/arm/cpu/armv7r/Makefile >> new file mode 100644 >> index ..3c66976dfa62 >> --- /dev/null >> +++ b/arch/arm/cpu/armv7r/Makefile > > hmm..do we really need to create a separate folder? IIUC, the main > difference between V7 and V7R is MMU vs MPU. IMHO, we should be able to > get it using Kconfigs. I have used V7 for the initial port and then was checking V7M which is already there and used it as pattern for writing this patch. I have debugged V7 and found that I need to disable CONFIG_HAS_VBAR that's why I have created new symbol as for V7M. Definitely I am open to hear your suggestions. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: uniphier: move SPL stack address
Currently, the address region, 0xf8000 - 0x10, is used for SPL stack for the 32bit SoCs. Because the U-Boot proper image starts from 0x7, the maximum size of the U-Boot proper image is 544KB (0x7 - 0xf8000) for the NOR boot mode. Now uniphier_v7_defconfig is almost hitting this size limit. Changing CONFIG_SPL_STACK can raise the size limit with less impact. With this, the size limit will increase to 576KB (0x7 - 0x10). If we need to increase it even more, we would be able to change CONFIG_SYS_UBOOT_BASE at the cost of the flashing command changes. Signed-off-by: Masahiro Yamada --- include/configs/uniphier.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h index a00bfd9..f252073 100644 --- a/include/configs/uniphier.h +++ b/include/configs/uniphier.h @@ -219,7 +219,7 @@ #define CONFIG_SPL_TEXT_BASE 0x0010 #endif -#define CONFIG_SPL_STACK (0x0010) +#define CONFIG_SPL_STACK (0x0020) #define CONFIG_SYS_NAND_U_BOOT_OFFS0x2 -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/8] riscv: Enable efi_loader support
We now have RISC-V support in U-Boot - which is great! However, not that we're finally making progress to converge on efi_loader and distro boot for booting on ARM platforms, we really want to make sure there is no technical reason not to do the same on RISC-V as well. So this patch set introduces distro boot and efi_loader support for RISC-V! So far, I've only tested it with the selftest and hello world target in U-Boot, as the number of target binaries to run is still slim. But it should at least give us a good starting point. v1 -> v2: - Allow 32bit target - Also save/restore ra, sp - Use edk2 default boot file names - Enable hello world binary - remove patch: efi_loader: selftest: Do not build relocation tests for risc-v - new patch: riscv: Add EFI application infrastructure v2 -> v3: - Add missing crt0 source - Use official values for vci Alexander Graf (8): riscv: Add setjmp/longjmp code riscv: Enable function sections riscv: Add EFI application infrastructure riscv: Add board_quiesce_devices stub efi_loader: Use EFI_CACHELINE_SIZE in the image loader too distro: Extend with RISC-V defines riscv: nx25: Enable distro boot efi_loader: Enable RISC-V support arch/riscv/config.mk | 7 +- arch/riscv/cpu/nx25/u-boot.lds| 16 arch/riscv/include/asm/setjmp.h | 26 ++ arch/riscv/include/asm/u-boot-riscv.h | 1 + arch/riscv/lib/Makefile | 12 +++ arch/riscv/lib/bootm.c| 4 + arch/riscv/lib/crt0_riscv_efi.S | 152 ++ arch/riscv/lib/elf_riscv32_efi.lds| 70 arch/riscv/lib/elf_riscv64_efi.lds| 70 arch/riscv/lib/reloc_riscv_efi.c | 97 ++ arch/riscv/lib/setjmp.S | 66 +++ cmd/Kconfig | 2 +- configs/nx25-ae250_defconfig | 1 + include/config_distro_bootcmd.h | 11 +++ include/configs/nx25-ae250.h | 17 include/efi_loader.h | 7 ++ lib/efi_loader/Kconfig| 2 +- lib/efi_loader/efi_image_loader.c | 2 +- lib/efi_loader/efi_runtime.c | 48 --- 19 files changed, 595 insertions(+), 16 deletions(-) create mode 100644 arch/riscv/include/asm/setjmp.h create mode 100644 arch/riscv/lib/crt0_riscv_efi.S create mode 100644 arch/riscv/lib/elf_riscv32_efi.lds create mode 100644 arch/riscv/lib/elf_riscv64_efi.lds create mode 100644 arch/riscv/lib/reloc_riscv_efi.c create mode 100644 arch/riscv/lib/setjmp.S -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 13/16] arm: socfpga: stratix10: Add timer support for Stratix10 SoC
On Mon, Apr 23, 2018 at 11:40 AM, Marek Vasut wrote: > On 04/23/2018 03:54 AM, Ley Foon Tan wrote: >> On Thu, Apr 19, 2018 at 4:21 PM, Marek Vasut wrote: >>> On 04/19/2018 07:26 AM, See, Chin Liang wrote: On Thu, 2018-04-19 at 04:59 +0200, Marek Vasut wrote: > On 04/19/2018 11:50 AM, Ley Foon Tan wrote: >> >> Add timer support for Stratix SoC > Is this really custom timer or is that some armv8 thing you're adding > here ? Don't we already have a generic implementation for that ? If > not, > that's what we should do here. Yes but not the init function. It's left with platform specific code to init it. >>> >>> Where is the common part ? >>> >>> -- >>> Best regards, >>> Marek Vasut >> >> timer_init weak function is in lib/time.c and common code is in this >> file as well. >> >> int __weak timer_init(void) >> { >> return 0; >> } > > Oh, that's what you use, I see. > > I suspect having a timer_gen5. and timer_gen10.c would be a bit cleaner > than the ifdef. > > -- Okay, will split them into different files. Thanks. Regards Ley Foon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 6/8] distro: Extend with RISC-V defines
While we don't have UEFI naming conventions for RISC-V file paths yet, we need to search for something. So let's copy the removable file paths from the RISC-V edk2 port. Also add the official VCI strings that contain the standardized RISC-V architecture ID fields. Signed-off-by: Alexander Graf --- v1 -> v2: - Use edk2 default boot file names v2 -> v3: - Use official values for vci --- include/config_distro_bootcmd.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index f567cebd38..989b5556af 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -100,6 +100,10 @@ #define BOOTEFI_NAME "bootia32.efi" #elif defined(CONFIG_X86_RUN_64BIT) #define BOOTEFI_NAME "bootx64.efi" +#elif defined(CONFIG_CPU_RISCV_32) +#define BOOTEFI_NAME "bootriscv32.efi" +#elif defined(CONFIG_CPU_RISCV_64) +#define BOOTEFI_NAME "bootriscv64.efi" #endif #endif @@ -241,6 +245,7 @@ #if defined(CONFIG_CMD_DHCP) #if defined(CONFIG_EFI_LOADER) +/* http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml */ #if defined(CONFIG_ARM64) #define BOOTENV_EFI_PXE_ARCH "0xb" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00011:UNDI:003000" @@ -251,6 +256,12 @@ /* Always assume we're running 64bit */ #define BOOTENV_EFI_PXE_ARCH "0x7" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:7:UNDI:003000" +#elif defined(CONFIG_CPU_RISCV_32) +#define BOOTENV_EFI_PXE_ARCH "0x19" +#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00025:UNDI:003000" +#elif defined(CONFIG_CPU_RISCV_64) +#define BOOTENV_EFI_PXE_ARCH "0x1b" +#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00027:UNDI:003000" #else #error Please specify an EFI client identifier #endif -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 7/8] riscv: nx25: Enable distro boot
Distro boot allows for a common boot path on systems that allow distributions to easily boot from a default configuration. This patch enables distro boot for the nx25-ae250. Hopefully this can serve as a good example for new boards, so they enable it as well. Signed-off-by: Alexander Graf --- configs/nx25-ae250_defconfig | 1 + include/configs/nx25-ae250.h | 17 + 2 files changed, 18 insertions(+) diff --git a/configs/nx25-ae250_defconfig b/configs/nx25-ae250_defconfig index 4f9bd58f75..437083231b 100644 --- a/configs/nx25-ae250_defconfig +++ b/configs/nx25-ae250_defconfig @@ -37,3 +37,4 @@ CONFIG_DM_SPI=y CONFIG_ATCSPI200_SPI=y CONFIG_TIMER=y CONFIG_ATCPIT100_TIMER=y +CONFIG_DISTRO_DEFAULTS=y diff --git a/include/configs/nx25-ae250.h b/include/configs/nx25-ae250.h index 0e4c431cab..a90c75abc4 100644 --- a/include/configs/nx25-ae250.h +++ b/include/configs/nx25-ae250.h @@ -105,4 +105,21 @@ /* Increase max gunzip size */ #define CONFIG_SYS_BOOTM_LEN (64 << 20) +/* When we use RAM as ENV */ +#define CONFIG_ENV_SIZE 0x2000 + +/* Enable distro boot */ +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 0) \ + func(DHCP, dhcp, na) +#include + +#define CONFIG_EXTRA_ENV_SETTINGS \ + "kernel_addr_r=0x0008\0" \ + "pxefile_addr_r=0x01f0\0" \ + "scriptaddr=0x01f0\0" \ + "fdt_addr_r=0x0200\0" \ + "ramdisk_addr_r=0x0280\0" \ + BOOTENV + #endif /* __CONFIG_H */ -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/8] riscv: Enable function sections
The linker can remove sections that are never addressed, so it makes a lot of sense to declare every function as an individual section. This reduces the output U-Boot code size by ~30kb for me. Signed-off-by: Alexander Graf --- arch/riscv/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk index 6b681c4286..69f4cf6ce8 100644 --- a/arch/riscv/config.mk +++ b/arch/riscv/config.mk @@ -29,5 +29,5 @@ CONFIG_STANDALONE_LOAD_ADDR = 0x \ -T $(srctree)/examples/standalone/riscv.lds PLATFORM_CPPFLAGS += -ffixed-gp -fpic -PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -gdwarf-2 +PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -gdwarf-2 -ffunction-sections LDFLAGS_u-boot += --gc-sections -static -pie -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 5/8] efi_loader: Use EFI_CACHELINE_SIZE in the image loader too
We were using our EFI_CACHELINE_SIZE define only in the runtime service code, but left the image loader to use plain CONFIG_SYS_CACHELINE_SIZE. This patch moves EFI_CACHELINE_SIZE into efi_loader.h and converts the image loader to use it. Signed-off-by: Alexander Graf --- include/efi_loader.h | 7 +++ lib/efi_loader/efi_image_loader.c | 2 +- lib/efi_loader/efi_runtime.c | 7 --- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/include/efi_loader.h b/include/efi_loader.h index 17f9d3d1ef..0b1b3df55a 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -76,6 +76,13 @@ const char *__efi_nesting_dec(void); ##__VA_ARGS__); \ }) +#ifdef CONFIG_SYS_CACHELINE_SIZE +#define EFI_CACHELINE_SIZE CONFIG_SYS_CACHELINE_SIZE +#else +/* Just use the greatest cache flush alignment requirement I'm aware of */ +#define EFI_CACHELINE_SIZE 128 +#endif + extern struct efi_runtime_services efi_runtime_services; extern struct efi_system_table systab; diff --git a/lib/efi_loader/efi_image_loader.c b/lib/efi_loader/efi_image_loader.c index d5fbba3138..2476a97a6a 100644 --- a/lib/efi_loader/efi_image_loader.c +++ b/lib/efi_loader/efi_image_loader.c @@ -290,7 +290,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image *loaded_image_info) /* Flush cache */ flush_cache((ulong)efi_reloc, - ALIGN(virt_size, CONFIG_SYS_CACHELINE_SIZE)); + ALIGN(virt_size, EFI_CACHELINE_SIZE)); invalidate_icache_all(); /* Populate the loaded image interface bits */ diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c index 8558124c0a..573a5d6ac1 100644 --- a/lib/efi_loader/efi_runtime.c +++ b/lib/efi_loader/efi_runtime.c @@ -30,13 +30,6 @@ static efi_status_t __efi_runtime EFIAPI efi_unimplemented(void); static efi_status_t __efi_runtime EFIAPI efi_device_error(void); static efi_status_t __efi_runtime EFIAPI efi_invalid_parameter(void); -#ifdef CONFIG_SYS_CACHELINE_SIZE -#define EFI_CACHELINE_SIZE CONFIG_SYS_CACHELINE_SIZE -#else -/* Just use the greatest cache flush alignment requirement I'm aware of */ -#define EFI_CACHELINE_SIZE 128 -#endif - #if defined(CONFIG_ARM64) #define R_RELATIVE 1027 #define R_MASK 0xULL -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/8] riscv: Add setjmp/longjmp code
To support efi_loader we need to have platform support for setjmp/longjmp. Add it here. Signed-off-by: Alexander Graf --- v1 -> v2: - Allow 32bit target - Also save/restore ra, sp --- arch/riscv/include/asm/setjmp.h | 26 arch/riscv/lib/Makefile | 1 + arch/riscv/lib/setjmp.S | 66 + 3 files changed, 93 insertions(+) create mode 100644 arch/riscv/include/asm/setjmp.h create mode 100644 arch/riscv/lib/setjmp.S diff --git a/arch/riscv/include/asm/setjmp.h b/arch/riscv/include/asm/setjmp.h new file mode 100644 index 00..01ad6d081f --- /dev/null +++ b/arch/riscv/include/asm/setjmp.h @@ -0,0 +1,26 @@ +/* + * (C) Copyright 2018 Alexander Graf + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef _SETJMP_H_ +#define _SETJMP_H_ 1 + +/* + * This really should be opaque, but the EFI implementation wrongly + * assumes that a 'struct jmp_buf_data' is defined. + */ +struct jmp_buf_data { + /* x2, x8, x9, x18, x19, x20, x21, x22, x23, x24, x25, x26, x27, sp */ + unsigned long s_regs[12]; /* s0 - s11 */ + unsigned long ra; + unsigned long sp; +}; + +typedef struct jmp_buf_data jmp_buf[1]; + +int setjmp(jmp_buf jmp); +void longjmp(jmp_buf jmp, int ret); + +#endif /* _SETJMP_H_ */ diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 323cf3e835..6d97aa2719 100644 --- a/arch/riscv/lib/Makefile +++ b/arch/riscv/lib/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_GO) += boot.o obj-y += cache.o obj-y += interrupts.o +obj-y += setjmp.o diff --git a/arch/riscv/lib/setjmp.S b/arch/riscv/lib/setjmp.S new file mode 100644 index 00..103f359185 --- /dev/null +++ b/arch/riscv/lib/setjmp.S @@ -0,0 +1,66 @@ +/* + * (C) 2018 Alexander Graf + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include + +#ifdef CONFIG_CPU_RISCV_64 +#define STORE_IDX(reg, idx)sd reg, (idx*8)(a0) +#define LOAD_IDX(reg, idx) ld reg, (idx*8)(a0) +#else +#define STORE_IDX(reg, idx)sw reg, (idx*4)(a0) +#define LOAD_IDX(reg, idx) lw reg, (idx*4)(a0) +#endif + +.pushsection .text.setjmp, "ax" +ENTRY(setjmp) + /* Preserve all callee-saved registers and the SP */ + STORE_IDX(s0, 0) + STORE_IDX(s1, 1) + STORE_IDX(s2, 2) + STORE_IDX(s3, 3) + STORE_IDX(s4, 4) + STORE_IDX(s5, 5) + STORE_IDX(s6, 6) + STORE_IDX(s7, 7) + STORE_IDX(s8, 8) + STORE_IDX(s9, 9) + STORE_IDX(s10, 10) + STORE_IDX(s11, 11) + STORE_IDX(ra, 12) + STORE_IDX(sp, 13) + li a0, 0 + ret +ENDPROC(setjmp) +.popsection + +.pushsection .text.longjmp, "ax" +ENTRY(longjmp) + LOAD_IDX(s0, 0) + LOAD_IDX(s1, 1) + LOAD_IDX(s2, 2) + LOAD_IDX(s3, 3) + LOAD_IDX(s4, 4) + LOAD_IDX(s5, 5) + LOAD_IDX(s6, 6) + LOAD_IDX(s7, 7) + LOAD_IDX(s8, 8) + LOAD_IDX(s9, 9) + LOAD_IDX(s10, 10) + LOAD_IDX(s11, 11) + LOAD_IDX(ra, 12) + LOAD_IDX(sp, 13) + + /* Move the return value in place, but return 1 if passed 0. */ + beq a1, zero, longjmp_1 + mv a0, a1 + ret + + longjmp_1: + li a0, 1 + ret +ENDPROC(longjmp) +.popsection -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 8/8] efi_loader: Enable RISC-V support
We have almost all pieces needed to support RISC-V UEFI binaries in place already. The only missing piece are ELF relocations for runtime code and data. This patch adds respective support in the linker script and the runtime relocation code. It also allows users to enable the EFI_LOADER configuration switch on RISC-V platforms. Signed-off-by: Alexander Graf --- v1 -> v2: - Enable hello world binary --- arch/riscv/cpu/nx25/u-boot.lds | 16 cmd/Kconfig| 2 +- lib/efi_loader/Kconfig | 2 +- lib/efi_loader/efi_runtime.c | 41 - 4 files changed, 54 insertions(+), 7 deletions(-) diff --git a/arch/riscv/cpu/nx25/u-boot.lds b/arch/riscv/cpu/nx25/u-boot.lds index 936fd779aa..508fa7e58d 100644 --- a/arch/riscv/cpu/nx25/u-boot.lds +++ b/arch/riscv/cpu/nx25/u-boot.lds @@ -38,6 +38,22 @@ SECTIONS KEEP(*(SORT(.u_boot_list*))); } + . = ALIGN(4); + + .efi_runtime : { +__efi_runtime_start = .; + *(efi_runtime_text) + *(efi_runtime_data) +__efi_runtime_stop = .; + } + + .efi_runtime_rel : { +__efi_runtime_rel_start = .; + *(.relaefi_runtime_text) + *(.relaefi_runtime_data) +__efi_runtime_rel_stop = .; + } + . = ALIGN(4); /DISCARD/ : { *(.rela.plt*) } diff --git a/cmd/Kconfig b/cmd/Kconfig index bc1d2f31c0..c9883a40e7 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -228,7 +228,7 @@ config CMD_BOOTEFI config CMD_BOOTEFI_HELLO_COMPILE bool "Compile a standard EFI hello world binary for testing" - depends on CMD_BOOTEFI && (ARM || X86) + depends on CMD_BOOTEFI && (ARM || X86 || RISCV) default y help This compiles a standard EFI hello world application with U-Boot so diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 83d75c4fdc..9de58bb012 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" - depends on (ARM || X86) && OF_LIBFDT + depends on (ARM || X86 || RISCV) && OF_LIBFDT # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c index 573a5d6ac1..33bbc8d6cc 100644 --- a/lib/efi_loader/efi_runtime.c +++ b/lib/efi_loader/efi_runtime.c @@ -41,6 +41,25 @@ static efi_status_t __efi_runtime EFIAPI efi_invalid_parameter(void); #include #define R_RELATIVE R_386_RELATIVE #define R_MASK 0xffULL +#elif defined(CONFIG_RISCV) +#include +#define R_RELATIVE R_RISCV_RELATIVE +#define R_MASK 0xffULL +#define IS_RELA1 + +struct dyn_sym { + ulong foo1; + ulong addr; + u32 foo2; + u32 foo3; +}; +#ifdef CONFIG_CPU_RISCV_32 +#define R_ABSOLUTE R_RISCV_32 +#define SYM_INDEX 8 +#else +#define R_ABSOLUTE R_RISCV_64 +#define SYM_INDEX 32 +#endif #else #error Need to add relocation awareness #endif @@ -247,15 +266,27 @@ void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map) p = (void*)((ulong)rel->offset - base) + gd->relocaddr; - if ((rel->info & R_MASK) != R_RELATIVE) { - continue; - } + debug("%s: rel->info=%#lx *p=%#lx rel->offset=%p\n", __func__, rel->info, *p, rel->offset); + switch (rel->info & R_MASK) { + case R_RELATIVE: #ifdef IS_RELA - newaddr = rel->addend + offset - CONFIG_SYS_TEXT_BASE; + newaddr = rel->addend + offset - CONFIG_SYS_TEXT_BASE; #else - newaddr = *p - lastoff + offset; + newaddr = *p - lastoff + offset; #endif + break; +#ifdef R_ABSOLUTE + case R_ABSOLUTE: { + ulong symidx = rel->info >> SYM_INDEX; + extern struct dyn_sym __dyn_sym_start[]; + newaddr = __dyn_sym_start[symidx].addr + offset; + break; + } +#endif + default: + continue; + } /* Check if the relocation is inside bounds */ if (map && ((newaddr < map->virtual_start) || -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/8] riscv: Add EFI application infrastructure
The hello world binary and a few selftests require to build EFI target binaries, not just the EFI host environment. This patch adds all required files to generate an EFI binary for RISC-V. Signed-off-by: Alexander Graf --- new in v2 v2 -> v3: - Add missing crt0 source --- arch/riscv/config.mk | 5 ++ arch/riscv/lib/Makefile| 11 +++ arch/riscv/lib/crt0_riscv_efi.S| 152 + arch/riscv/lib/elf_riscv32_efi.lds | 70 + arch/riscv/lib/elf_riscv64_efi.lds | 70 + arch/riscv/lib/reloc_riscv_efi.c | 97 +++ 6 files changed, 405 insertions(+) create mode 100644 arch/riscv/lib/crt0_riscv_efi.S create mode 100644 arch/riscv/lib/elf_riscv32_efi.lds create mode 100644 arch/riscv/lib/elf_riscv64_efi.lds create mode 100644 arch/riscv/lib/reloc_riscv_efi.c diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk index 69f4cf6ce8..9175aa765d 100644 --- a/arch/riscv/config.mk +++ b/arch/riscv/config.mk @@ -19,10 +19,12 @@ endif ifdef CONFIG_32BIT PLATFORM_LDFLAGS += -m $(32bit-emul) +EFI_LDS:= elf_riscv32_efi.lds endif ifdef CONFIG_64BIT PLATFORM_LDFLAGS += -m $(64bit-emul) +EFI_LDS:= elf_riscv64_efi.lds endif CONFIG_STANDALONE_LOAD_ADDR = 0x \ @@ -31,3 +33,6 @@ CONFIG_STANDALONE_LOAD_ADDR = 0x \ PLATFORM_CPPFLAGS += -ffixed-gp -fpic PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -gdwarf-2 -ffunction-sections LDFLAGS_u-boot += --gc-sections -static -pie + +EFI_CRT0 := crt0_riscv_efi.o +EFI_RELOC := reloc_riscv_efi.o diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 6d97aa2719..33f80ebdca 100644 --- a/arch/riscv/lib/Makefile +++ b/arch/riscv/lib/Makefile @@ -13,3 +13,14 @@ obj-$(CONFIG_CMD_GO) += boot.o obj-y += cache.o obj-y += interrupts.o obj-y += setjmp.o + +# For building EFI apps +CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI) +CFLAGS_REMOVE_$(EFI_CRT0) := $(CFLAGS_NON_EFI) + +CFLAGS_$(EFI_RELOC) := $(CFLAGS_EFI) +CFLAGS_REMOVE_$(EFI_RELOC) := $(CFLAGS_NON_EFI) + +extra-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += $(EFI_CRT0) $(EFI_RELOC) +extra-$(CONFIG_CMD_BOOTEFI_SELFTEST) += $(EFI_CRT0) $(EFI_RELOC) +extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC) diff --git a/arch/riscv/lib/crt0_riscv_efi.S b/arch/riscv/lib/crt0_riscv_efi.S new file mode 100644 index 00..498870e1be --- /dev/null +++ b/arch/riscv/lib/crt0_riscv_efi.S @@ -0,0 +1,152 @@ +/* + * crt0-efi-riscv.S - PE/COFF header for RISC-V EFI applications + * + * Copright (C) 2014 Linaro Ltd. + * Copright (C) 2018 Alexander Graf + * + * SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause + * + * This file is inspired by arch/arm/lib/crt0_aarch64_efi.S + */ + +#include + +#if __riscv_xlen == 64 +#define SIZE_LONG 8 +#define SAVE_LONG(reg, idx)sd reg, (idx*SIZE_LONG)(sp) +#define LOAD_LONG(reg, idx)ld reg, (idx*SIZE_LONG)(sp) +#define PE_MACHINE 0x5064 +#else +#define SIZE_LONG 4 +#define SAVE_LONG(reg, idx)sw reg, (idx*SIZE_LONG)(sp) +#define LOAD_LONG(reg, idx)lw reg, (idx*SIZE_LONG)(sp) +#define PE_MACHINE 0x5032 +#endif + + + .section.text.head + + /* +* Magic "MZ" signature for PE/COFF +*/ + .globl ImageBase +ImageBase: + .ascii "MZ" + .skip 58 /* 'MZ' + pad + offset == 64 */ + .long pe_header - ImageBase /* Offset to the PE header */ +pe_header: + .ascii "PE" + .short 0 +coff_header: + .short PE_MACHINE /* RISC-V 64/32-bit */ + .short 2 /* nr_sections */ + .long 0 /* TimeDateStamp */ + .long 0 /* PointerToSymbolTable */ + .long 1 /* NumberOfSymbols */ + .short section_table - optional_header /* SizeOfOptionalHeader */ + /* +* Characteristics: IMAGE_FILE_DEBUG_STRIPPED | +* IMAGE_FILE_EXECUTABLE_IMAGE | IMAGE_FILE_LINE_NUMS_STRIPPED +*/ + .short 0x206 +optional_header: + .short 0x20b /* PE32+ format */ + .byte 0x02/* MajorLinkerVersion */ + .byte 0x14/* MinorLinkerVersion */ + .long _edata - _start /* SizeOfCode */ + .long 0 /* SizeOfInitializedData */ + .long 0 /* SizeOfUninitializedData */ + .long _start - ImageBase /* AddressOfEntryPoint */ + .long _start - ImageBase /* BaseOfCode */ + +extra_header_fields: + .quad 0 /* ImageBase */ + .long 0x20/* SectionAlignment */ +
[U-Boot] [PATCH v3 4/8] riscv: Add board_quiesce_devices stub
This patch adds an empty stub for board_quiesce_devices() which allows boards to quiesce their devices before we boot into an OS in a platform agnostic way. Signed-off-by: Alexander Graf --- arch/riscv/include/asm/u-boot-riscv.h | 1 + arch/riscv/lib/bootm.c| 4 2 files changed, 5 insertions(+) diff --git a/arch/riscv/include/asm/u-boot-riscv.h b/arch/riscv/include/asm/u-boot-riscv.h index 18099cd260..0b6428b1ae 100644 --- a/arch/riscv/include/asm/u-boot-riscv.h +++ b/arch/riscv/include/asm/u-boot-riscv.h @@ -17,5 +17,6 @@ int cleanup_before_linux(void); /* board/.../... */ int board_init(void); +void board_quiesce_devices(void); #endif /* _U_BOOT_RISCV_H_ */ diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c index 9242fa891a..b80274adba 100644 --- a/arch/riscv/lib/bootm.c +++ b/arch/riscv/lib/bootm.c @@ -16,6 +16,10 @@ DECLARE_GLOBAL_DATA_PTR; +__weak void board_quiesce_devices(void) +{ +} + int arch_fixup_fdt(void *blob) { return 0; -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/8] riscv: Add EFI application infrastructure
On 23.04.18 07:54, 陳建志 wrote: >> The hello world binary and a few selftests require to build EFI target >> binaries, not just the EFI host environment. >> >> This patch adds all required files to generate an EFI binary for RISC-V. >> >> Signed-off-by: Alexander Graf >> >> --- >> >> new in v2 >> --- >> arch/riscv/config.mk | 5 ++ >> arch/riscv/lib/Makefile| 11 + >> arch/riscv/lib/elf_riscv32_efi.lds | 70 +++ >> arch/riscv/lib/elf_riscv64_efi.lds | 70 +++ >> arch/riscv/lib/reloc_riscv_efi.c | 97 >> ++ >> 5 files changed, 253 insertions(+) >> create mode 100644 arch/riscv/lib/elf_riscv32_efi.lds >> create mode 100644 arch/riscv/lib/elf_riscv64_efi.lds >> create mode 100644 arch/riscv/lib/reloc_riscv_efi.c >> >> diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk index >> 69f4cf6ce8..9175aa765d 100644 >> --- a/arch/riscv/config.mk >> +++ b/arch/riscv/config.mk >> @@ -19,10 +19,12 @@ endif >> >> ifdef CONFIG_32BIT >> PLATFORM_LDFLAGS += -m $(32bit-emul) >> +EFI_LDS:= elf_riscv32_efi.lds >> endif >> >> ifdef CONFIG_64BIT >> PLATFORM_LDFLAGS += -m $(64bit-emul) >> +EFI_LDS:= elf_riscv64_efi.lds >> endif >> >> CONFIG_STANDALONE_LOAD_ADDR = 0x \ @@ -31,3 +33,6 @@ >> CONFIG_STANDALONE_LOAD_ADDR = 0x \ >> PLATFORM_CPPFLAGS += -ffixed-gp -fpic >> PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -gdwarf-2 >> -ffunction-sections LDFLAGS_u-boot += --gc-sections -static -pie >> + >> +EFI_CRT0 := crt0_riscv_efi.o >> +EFI_RELOC := reloc_riscv_efi.o > > Hi Alexander > > make fail as below > > make[1]: *** No rule to make target 'arch/riscv/lib/crt0_riscv_efi.o', > needed by '__build'. Stop. > Makefile:1340: recipe for target 'arch/riscv/lib' failed > > Shall crt0_riscv_efi.c be uploaded there ? Sorry, I forgot to send out v3 where I fixed that bit :). I'll do that immediately. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/8] riscv: Add EFI application infrastructure
> The hello world binary and a few selftests require to build EFI target > binaries, not just the EFI host environment. > > This patch adds all required files to generate an EFI binary for RISC-V. > > Signed-off-by: Alexander Graf > > --- > > new in v2 > --- > arch/riscv/config.mk | 5 ++ > arch/riscv/lib/Makefile| 11 + > arch/riscv/lib/elf_riscv32_efi.lds | 70 +++ > arch/riscv/lib/elf_riscv64_efi.lds | 70 +++ > arch/riscv/lib/reloc_riscv_efi.c | 97 > ++ > 5 files changed, 253 insertions(+) > create mode 100644 arch/riscv/lib/elf_riscv32_efi.lds > create mode 100644 arch/riscv/lib/elf_riscv64_efi.lds > create mode 100644 arch/riscv/lib/reloc_riscv_efi.c > > diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk index > 69f4cf6ce8..9175aa765d 100644 > --- a/arch/riscv/config.mk > +++ b/arch/riscv/config.mk > @@ -19,10 +19,12 @@ endif > > ifdef CONFIG_32BIT > PLATFORM_LDFLAGS += -m $(32bit-emul) > +EFI_LDS:= elf_riscv32_efi.lds > endif > > ifdef CONFIG_64BIT > PLATFORM_LDFLAGS += -m $(64bit-emul) > +EFI_LDS:= elf_riscv64_efi.lds > endif > > CONFIG_STANDALONE_LOAD_ADDR = 0x \ @@ -31,3 +33,6 @@ > CONFIG_STANDALONE_LOAD_ADDR = 0x \ > PLATFORM_CPPFLAGS += -ffixed-gp -fpic > PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -gdwarf-2 > -ffunction-sections LDFLAGS_u-boot += --gc-sections -static -pie > + > +EFI_CRT0 := crt0_riscv_efi.o > +EFI_RELOC := reloc_riscv_efi.o Hi Alexander make fail as below make[1]: *** No rule to make target 'arch/riscv/lib/crt0_riscv_efi.o', needed by '__build'. Stop. Makefile:1340: recipe for target 'arch/riscv/lib' failed Shall crt0_riscv_efi.c be uploaded there ? B.R. Rick > diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index > 6d97aa2719..33f80ebdca 100644 > --- a/arch/riscv/lib/Makefile > +++ b/arch/riscv/lib/Makefile > @@ -13,3 +13,14 @@ obj-$(CONFIG_CMD_GO) += boot.o > obj-y += cache.o > obj-y += interrupts.o > obj-y += setjmp.o > + > +# For building EFI apps > +CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI) > +CFLAGS_REMOVE_$(EFI_CRT0) := $(CFLAGS_NON_EFI) > + > +CFLAGS_$(EFI_RELOC) := $(CFLAGS_EFI) > +CFLAGS_REMOVE_$(EFI_RELOC) := $(CFLAGS_NON_EFI) > + > +extra-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += $(EFI_CRT0) $(EFI_RELOC) > +extra-$(CONFIG_CMD_BOOTEFI_SELFTEST) += $(EFI_CRT0) $(EFI_RELOC) > +extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC) > diff --git a/arch/riscv/lib/elf_riscv32_efi.lds > b/arch/riscv/lib/elf_riscv32_efi.lds > new file mode 100644 > index 00..96d11985b0 > --- /dev/null > +++ b/arch/riscv/lib/elf_riscv32_efi.lds > @@ -0,0 +1,70 @@ > +/* > + * U-Boot riscv32 EFI linker script > + * > + * SPDX-License-Identifier:BSD-2-Clause > + * > + * Modified from arch/arm/lib/elf_aarch64_efi.lds */ > + > +OUTPUT_FORMAT("elf32-littleriscv", "elf32-littleriscv", > +"elf32-littleriscv") > +OUTPUT_ARCH(riscv) > +ENTRY(_start) > +SECTIONS > +{ > + .text 0x0 : { > + _text = .; > + *(.text.head) > + *(.text) > + *(.text.*) > + *(.gnu.linkonce.t.*) > + *(.srodata) > + *(.rodata*) > + . = ALIGN(16); > + } > + _etext = .; > + _text_size = . - _text; > + .dynamic : { *(.dynamic) } > + .data : { > + _data = .; > + *(.sdata) > + *(.data) > + *(.data1) > + *(.data.*) > + *(.got.plt) > + *(.got) > + > + /* > +* The EFI loader doesn't seem to like a .bss section, so we > +* stick it all into .data: > +*/ > + . = ALIGN(16); > + _bss = .; > + *(.sbss) > + *(.scommon) > + *(.dynbss) > + *(.bss) > + *(.bss.*) > + *(COMMON) > + . = ALIGN(16); > + _bss_end = .; > + _edata = .; > + } > + .rela.dyn : { *(.rela.dyn) } > + .rela.plt : { *(.rela.plt) } > + .rela.got : { *(.rela.got) } > + .rela.data : { *(.rela.data) *(.rela.data*) } > + _data_size = . - _etext; > + > + . = ALIGN(4096); > + .dynsym : { *(.dynsym) } > + . = ALIGN(4096); > + .dynstr : { *(.dynstr) } > + . = ALIGN(4096); > + .note.gnu.build-id : { *(.note.gnu.build-id) } > + /DISCARD/ : { > + *(.rel.reloc) > + *(.eh_frame) > + *(.note.GNU-stack) > + } > + .comment 0 : { *(.comment) } > +} > diff --git a/arch/riscv/lib/elf_riscv64_efi.lds > b/arch/riscv/lib/elf_riscv64_efi.lds > new file mode 100644 > index 00..25c863de8a > --- /dev/null > +++ b/arch/ris
Re: [U-Boot] [PATCH] DW SPI: invert wait condition in dw_spi_xfer
On Thu, Apr 19, 2018 at 8:17 PM, Eugeniy Paltsev wrote: > While switching to readl_poll_timeout macros from custom code > the waiting condition was accidently inverted, so it was pure > luck that this code works at least in some conditions. > > Fix that by inverting exit condition for readl_poll_timeout. > > Fixes: c6b4f031d9 ("DW SPI: fix tx data loss on FIFO flush") > > Signed-off-by: Eugeniy Paltsev > --- Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] syscon: add Linux-compatible syscon API
Hi Simon, 2018-04-23 5:11 GMT+09:00 Simon Glass : > Hi Masahiro, > > On 17 April 2018 at 20:38, Masahiro Yamada > wrote: >> The syscon implementation in U-Boot is different from that in Linux. >> Thus, DT files imported from Linux do not work for U-Boot. >> >> In U-Boot driver model, each node is bound to a dedicated driver >> that is the most compatible to it. This design gets along with the >> concept of DT, and the syscon in Linux originally worked like that. >> >> However, Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon >> interface from platform devices") changed the behavior because it is >> useful to let a device bind to another driver, but still works as a >> syscon provider. >> >> That change had happened before U-Boot initially supported the syscon >> driver by commit 6f98b7504f70 ("dm: Add support for generic system >> controllers (syscon)"). So, the U-Boot's syscon works differently >> from the beginning. I'd say this is mis-implementation given that >> DT is not oriented to a particular project, but Linux is the canon >> of DT in practice. >> >> The problem typically arises in the combination of "syscon" and >> "simple-mfd" compatibles. >> >> In Linux, they are orthogonal, i.e., the order between "syscon" and >> "simple-mfd" does not matter at all. >> >> Assume the following compatible. >> >>compatible = "foo,bar-syscon", "syscon", "simple-mfd"; >> >> In U-Boot, this device node is bound to the syscon driver >> (driver/core/syscon-uclass.c) since the "syscon" is found to be the >> most compatible. Then, syscon_get_regmap() succeeds. >> >> However, >> >>compatible = "foo,bar-syscon", "simple-mfd", "syscon"; >> >> does not work because this node is bound to the simple-bus driver >> (drivers/core/simple-bus.c) in the favor of "simple-mfd" compatible. >> The compatible string "syscon" is just dismissed. >> >> Moreover, >> >>compatible = "foo,bar-syscon", "syscon"; >> >> works like the first case because the syscon driver populates the >> child devices. This is wrong because populating children is the job >> of "simple-mfd" (or "simple-bus"). >> >> This commit ports syscon_node_to_regmap() from Linux. This API >> does not require the given node to be bound to a driver in any way. >> >> Reported-by: Kunihiko Hayashi >> Signed-off-by: Masahiro Yamada >> --- >> >> drivers/core/syscon-uclass.c | 63 > >> include/syscon.h | 8 ++ >> 2 files changed, 71 insertions(+) > > I was not aware of this change in how Linux worked, but it makes sense. > > Please can you add a test for this? I do not believe a missing test would block this patch, but I volunteered to add it (as a separate patch). http://patchwork.ozlabs.org/patch/902733/ -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] regmap: change regmap_init_mem() to take ofnode instead udevice
Hi Simon, 2018-04-23 5:10 GMT+09:00 Simon Glass : > Hi Masahiro, > > On 17 April 2018 at 20:38, Masahiro Yamada > wrote: >> Currently, regmap_init_mem() takes udevice. This requires the node >> has already been associated with a device. It prevents syscon/regmap >> from behaving like those in Linux. >> >> Change the first argumenet to take the device node. >> >> Signed-off-by: Masahiro Yamada >> --- >> >> arch/arm/mach-aspeed/ast2500/sdram_ast2500.c | 2 +- >> drivers/core/regmap.c| 11 +-- >> drivers/core/syscon-uclass.c | 2 +- >> drivers/phy/meson-gxl-usb2.c | 2 +- >> drivers/phy/meson-gxl-usb3.c | 2 +- >> drivers/ram/rockchip/dmc-rk3368.c| 2 +- >> drivers/ram/rockchip/sdram_rk3188.c | 2 +- >> drivers/ram/rockchip/sdram_rk322x.c | 2 +- >> drivers/ram/rockchip/sdram_rk3288.c | 2 +- >> drivers/ram/rockchip/sdram_rk3399.c | 2 +- >> drivers/ram/stm32mp1/stm32mp1_ram.c | 2 +- >> drivers/reset/reset-meson.c | 2 +- >> include/regmap.h | 4 ++-- >> 13 files changed, 18 insertions(+), 19 deletions(-) > > Can you please add a simple test for regmap on sandbox? > No. Please stop this boiler-plate response. Simple tests for regmap already exist in test/dm/regmap.c regmap_init_mem() is not a new function, and it is tested through other function tests. You block patches several times before by making the contributors say "Sorry, I am busy". I am really busy, but I need to fix the misimplementation of syscon for Socionext drivers. Why should I be annoyed by additional work to fix the problem? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] dm: ofnode: add ofnode_device_is_compatible() helper
2018-04-23 5:11 GMT+09:00 Simon Glass : > Hi Masahiro, > > On 17 April 2018 at 20:38, Masahiro Yamada > wrote: >> device_is_compatible() takes udevice, but there is no such a helper >> that takes ofnode. >> >> Signed-off-by: Masahiro Yamada >> --- >> >> drivers/core/device.c | 8 +--- >> drivers/core/ofnode.c | 11 +++ >> include/dm/ofnode.h | 11 +++ >> 3 files changed, 23 insertions(+), 7 deletions(-) > > Please can you add a call to this to a test? > No. I do not see any ofnode helper test in test/dm/. You are requesting additional work beyond this patch. It is unfair. This helper is tested indirectly by other tests. Of course, you (and anybody) are free to add per-helper grained tests, but this is not a good reason to block this patch. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] regmap: clean up regmap allocation
2018-04-19 12:14 GMT+09:00 Masahiro Yamada : > Putting zero length array at the end of struct is a common technique > to embed arbitrary length of members. There is no good reason to let > regmap_alloc_count() branch by "if (count <= 1)". > > As far as I understood the code, regmap->base is an alias of > regmap->ranges[0].start, but it is not helpful but make the code > just ugly. > > Rename regmap_alloc_count() to regmap_alloc() because the _count > suffix seems pointless. > > Signed-off-by: Masahiro Yamada > --- Simon gave r-b to v1. Copy-pasting it to v2. Reviewed-by: Simon Glass -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] test: regmap: test Linux-compatible syscon_node_to_regmap()
Like Linux, syscon_node_to_regmap() allows a node to work as a syscon provider without binding it to a syscon driver. Test this. Requested-by: Simon Glass Signed-off-by: Masahiro Yamada --- arch/sandbox/dts/test.dts | 8 test/dm/regmap.c | 17 + 2 files changed, 25 insertions(+) diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts index 06d0e8c..3c25cb7 100644 --- a/arch/sandbox/dts/test.dts +++ b/arch/sandbox/dts/test.dts @@ -393,6 +393,14 @@ 0x38 8>; }; + syscon@2 { + compatible = "simple-mfd", "syscon"; + reg = <0x40 5 + 0x48 6 + 0x50 7 + 0x58 8>; + }; + timer { compatible = "sandbox,timer"; clock-frequency = <100>; diff --git a/test/dm/regmap.c b/test/dm/regmap.c index 8125345..698a013 100644 --- a/test/dm/regmap.c +++ b/test/dm/regmap.c @@ -20,6 +20,7 @@ static int dm_test_regmap_base(struct unit_test_state *uts) { struct udevice *dev; struct regmap *map; + ofnode node; int i; ut_assertok(uclass_get_device(UCLASS_SYSCON, 0, &dev)); @@ -48,6 +49,22 @@ static int dm_test_regmap_base(struct unit_test_state *uts) map = syscon_get_regmap(dev); ut_asserteq_ptr(ERR_PTR(-ENOEXEC), map); + /* A different device can be a syscon by using Linux-compat API */ + node = ofnode_path("/syscon@2"); + ut_assert(ofnode_valid(node)); + + map = syscon_node_to_regmap(node); + ut_assertok_ptr(map); + ut_asserteq(4, map->range_count); + ut_asserteq(0x40, map->ranges[0].start); + for (i = 0; i < 4; i++) { + const unsigned long addr = 0x40 + 8 * i; + + ut_asserteq(addr, map->ranges[i].start); + ut_asserteq(5 + i, map->ranges[i].size); + ut_asserteq(addr, map_to_sysmem(regmap_get_range(map, i))); + } + return 0; } DM_TEST(dm_test_regmap_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT); -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: Add minimal support for Cortex-R5
On Friday 20 April 2018 07:21 PM, Michal Simek wrote: > This minimal support will be used by Xilinx ZynqMP R5 cpu. > > Signed-off-by: Michal Simek > --- > > arch/arm/Kconfig | 6 ++ > arch/arm/cpu/armv7r/Makefile | 4 > arch/arm/cpu/armv7r/config.mk | 3 +++ > arch/arm/cpu/armv7r/cpu.c | 24 > arch/arm/cpu/armv7r/start.S | 17 + > 5 files changed, 54 insertions(+) > create mode 100644 arch/arm/cpu/armv7r/Makefile > create mode 100644 arch/arm/cpu/armv7r/config.mk > create mode 100644 arch/arm/cpu/armv7r/cpu.c > create mode 100644 arch/arm/cpu/armv7r/start.S > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index b5fbce03667d..b10804f55224 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -192,6 +192,10 @@ config CPU_V7M > select THUMB2_KERNEL > select SYS_CACHE_SHIFT_5 > > +config CPU_V7R > + bool > + select SYS_CACHE_SHIFT_6 select HAS_THUMB2 might be a good option? > + > config CPU_PXA > bool > select SYS_CACHE_SHIFT_5 > @@ -209,6 +213,7 @@ config SYS_CPU > default "arm1176" if CPU_ARM1176 > default "armv7" if CPU_V7 > default "armv7m" if CPU_V7M > + default "armv7r" if CPU_V7R > default "pxa" if CPU_PXA > default "sa1100" if CPU_SA1100 > default "armv8" if ARM64 > @@ -223,6 +228,7 @@ config SYS_ARM_ARCH > default 6 if CPU_ARM1176 > default 7 if CPU_V7 > default 7 if CPU_V7M > + default 7 if CPU_V7R > default 5 if CPU_PXA > default 4 if CPU_SA1100 > default 8 if ARM64 I did a grep of CPU_V7, and you might want to update for CPU_V7R in the following places: diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 4fa8b38397..f4bc1f250d 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -18,6 +18,7 @@ arch-$(CONFIG_CPU_ARM1136)=-march=armv5 arch-$(CONFIG_CPU_ARM1176) =-march=armv5t arch-$(CONFIG_CPU_V7) =$(call cc-option, -march=armv7-a, \ $(call cc-option, -march=armv7, -march=armv5)) +arch-$(CONFIG_CPU_V7R) =-march=armv7-r arch-$(CONFIG_ARM64) =-march=armv8-a # On Tegra systems we must build SPL for the armv4 core on the device @@ -41,6 +42,7 @@ tune-$(CONFIG_CPU_PXA)=-mcpu=xscale tune-$(CONFIG_CPU_ARM1136) = tune-$(CONFIG_CPU_ARM1176) = tune-$(CONFIG_CPU_V7) = +tune-$(CONFIG_CPU_V7R) = tune-$(CONFIG_ARM64) = # Evaluate tune cc-option calls now > diff --git a/arch/arm/cpu/armv7r/Makefile b/arch/arm/cpu/armv7r/Makefile > new file mode 100644 > index ..3c66976dfa62 > --- /dev/null > +++ b/arch/arm/cpu/armv7r/Makefile hmm..do we really need to create a separate folder? IIUC, the main difference between V7 and V7R is MMU vs MPU. IMHO, we should be able to get it using Kconfigs. Thanks and regards, Lokesh > @@ -0,0 +1,4 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > +extra-y := start.o > +obj-y += cpu.o > diff --git a/arch/arm/cpu/armv7r/config.mk b/arch/arm/cpu/armv7r/config.mk > new file mode 100644 > index ..224d191ff846 > --- /dev/null > +++ b/arch/arm/cpu/armv7r/config.mk > @@ -0,0 +1,3 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > +PLATFORM_CPPFLAGS += -mcpu=cortex-r5 -DARMR5 > diff --git a/arch/arm/cpu/armv7r/cpu.c b/arch/arm/cpu/armv7r/cpu.c > new file mode 100644 > index ..e384a530c5e0 > --- /dev/null > +++ b/arch/arm/cpu/armv7r/cpu.c > @@ -0,0 +1,24 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * (C) Copyright 2018 Xilinx, Inc. (Michal Simek) > + */ > + > +#include > + > +/* > + * This is called right before passing control to > + * the Linux kernel point. > + */ > +int cleanup_before_linux(void) > +{ > + return 0; > +} > + > +/* > + * Perform the low-level reset. > + */ > +void reset_cpu(ulong addr) > +{ > + while (1) > + ; > +} > diff --git a/arch/arm/cpu/armv7r/start.S b/arch/arm/cpu/armv7r/start.S > new file mode 100644 > index ..d6e8eecf54b7 > --- /dev/null > +++ b/arch/arm/cpu/armv7r/start.S > @@ -0,0 +1,17 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * (C) Copyright 2015 > + * Kamil Lulko, > + * > + */ > + > +#include > + > +.globl reset > +.type reset, %function > +reset: > + W(b)_main > + > +.globl c_runtime_cpu_setup > +c_runtime_cpu_setup: > + mov pc, lr > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 13/16] arm: socfpga: stratix10: Add timer support for Stratix10 SoC
On 04/23/2018 03:54 AM, Ley Foon Tan wrote: > On Thu, Apr 19, 2018 at 4:21 PM, Marek Vasut wrote: >> On 04/19/2018 07:26 AM, See, Chin Liang wrote: >>> On Thu, 2018-04-19 at 04:59 +0200, Marek Vasut wrote: On 04/19/2018 11:50 AM, Ley Foon Tan wrote: > > Add timer support for Stratix SoC Is this really custom timer or is that some armv8 thing you're adding here ? Don't we already have a generic implementation for that ? If not, that's what we should do here. >>> >>> Yes but not the init function. It's left with platform specific code to >>> init it. >> >> Where is the common part ? >> >> -- >> Best regards, >> Marek Vasut > > timer_init weak function is in lib/time.c and common code is in this > file as well. > > int __weak timer_init(void) > { > return 0; > } Oh, that's what you use, I see. I suspect having a timer_gen5. and timer_gen10.c would be a bit cleaner than the ifdef. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 3/3] Adding wget
>From: Simon Glass >To: Duncan Hare >Sent: Sunday, April 22, 2018 1:10 PM >Subject: Re: [PATCH v10 3/3] Adding wget > >Hi Duncan, >On 17 April 2018 at 15:58, Duncan Hare wrote: >> From: Simon Glass >> It has been through patman, and the only errors flagged a packed structures, >> necessary for packed headers. >It should be possible in the Python test to enable an http server on localhost >with a few lines of code, and then connect to it in the test? Yes server at port 80. The server can be tested with the wget command which can be installed on linux.I doubt that loop-back like this will produce the scrambling of packet order which is a feature of push down stacks for packet queuesin the internet. The pi is easy to overrun when testing on a low latency network, because the TCP send window size is defined by the number ofnet_rx_buffers, which is controlled the CONFIG_SYS_RX_ETH_BUFFER in include.net.h, which sets PKTBUFSRX at the beginning of include/net.h, which in-turn defines a buffer pool in net/net.c, array named net_pkt_buf. Hence my comment in a different thread about buffering on the pi. Few of the socs appear to use net_pkt_buf buffers for net traffic. If there are too many transmission errors the sending tcp drops the connection. My solution to this is to halve the size of CONFIG_SYS_RX_ETH_BUFFER until transmission works. If I was thinking about a buffer pool for in the drivers, I'd implement it in net/net.c. Interface "getbuffer," returns a pointer, and increments an index to the next net_rx_buffer with no protection for overrun. Overrun is managed by ack numbers in TCPand timeout in UDP. Possibly CONFIG_SYS_RX_ETH_BUFFER could come under Kconfig. >Regards, >Simon RegardsDuncan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Network Packet Buffers: raspberrypi: variable uchar *net_rx_packets[PKTBUFSRX] in net/net.c
From: Simon Glass To: Duncan Hare Cc: Joe Hershberger ; U-Boot Mailing List Sent: Sunday, April 22, 2018 1:15 PM Subject: Re: Network Packet Buffers: raspberrypi: variable uchar *net_rx_packets[PKTBUFSRX] in net/net.c Hi Duncan, >On 17 April 2018 at 12:59, Duncan Hare wrote: >> Simon >> >> Is it possible to modify the network driver for the raspberry pi to use >> the buffer pool defined in net.c? >> >> It appears to have a single buffer, defined in the driver. >> >> In addition the buffer pool should be defined in memory outside the >> u-boot image. With the current definition is the buffer pool a >> part of the u-boot image? >Are you referring to the USB driver? If so, which one? Normally the buffers >are in BSS if they are not allocated with malloc(). So the buffers are not in >the U-Boot image in flash, >but do take up space in RAM at run-time after >relocation. Do not recall the filename of the driver. >Regards, >Simon Hi Simon Ethernet driver. But it might also be the usb driver . I don't know the detail at that level of the raspberry soc. Duncan Hare 714 931 7952 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 10/16] arm: dts: Add dts for Stratix10 SoC
On Thu, Apr 19, 2018 at 10:54 AM, Marek Vasut wrote: > On 04/19/2018 11:50 AM, Ley Foon Tan wrote: >> Device tree for Stratix10 SoC >> >> Signed-off-by: Chin Liang See >> Signed-off-by: Ley Foon Tan > > > Is this pulled from mainline Linux or not ? > > -- > Best regards, > Marek Vasut Will remove this patch and uses commit 81577a3b044645 from Dinh. Regards Ley Foon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 13/16] arm: socfpga: stratix10: Add timer support for Stratix10 SoC
On Thu, Apr 19, 2018 at 4:21 PM, Marek Vasut wrote: > On 04/19/2018 07:26 AM, See, Chin Liang wrote: >> On Thu, 2018-04-19 at 04:59 +0200, Marek Vasut wrote: >>> On 04/19/2018 11:50 AM, Ley Foon Tan wrote: Add timer support for Stratix SoC >>> Is this really custom timer or is that some armv8 thing you're adding >>> here ? Don't we already have a generic implementation for that ? If >>> not, >>> that's what we should do here. >> >> Yes but not the init function. It's left with platform specific code to >> init it. > > Where is the common part ? > > -- > Best regards, > Marek Vasut timer_init weak function is in lib/time.c and common code is in this file as well. int __weak timer_init(void) { return 0; } ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 05/16] arm: socfpga: misc: Add CONFIG_SYS_L2_PL310 switch
On Fri, Apr 20, 2018 at 7:00 PM, Marek Vasut wrote: > On 04/20/2018 09:49 AM, Ley Foon Tan wrote: >> On Thu, Apr 19, 2018 at 4:19 PM, Marek Vasut wrote: >>> On 04/19/2018 07:15 AM, See, Chin Liang wrote: On Thu, 2018-04-19 at 04:47 +0200, Marek Vasut wrote: > On 04/19/2018 11:50 AM, Ley Foon Tan wrote: >> >> Add CONFIG_SYS_L2_PL310 conditional build. > Why ? > In ARM64, L2 cache controller is accessed through processor registers. Hence we shall make this conditional in order this file can be shared across SOCFPGAs. >>> >>> That should be in the patch description . >>> Do you ever add the PL310 register access on S10 later in the set? >>> >>> -- >> Okay, will update description. >> No, S10 doesn't use PL310 registers. > > If this PL310 is Gen5 specific, then keep it in some Gen5 file. > > -- > Best regards, > Marek Vasut. Arria 10 needs this PL310 as well. So, we keep it in common misc. Regards Ley Foon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 06/16] arm: socfpga: misc: Move eth reset to common misc driver
On Thu, Apr 19, 2018 at 4:20 PM, Marek Vasut wrote: > On 04/19/2018 05:13 AM, Ley Foon Tan wrote: >> On Thu, Apr 19, 2018 at 10:47 AM, Marek Vasut wrote: >>> On 04/19/2018 11:50 AM, Ley Foon Tan wrote: Move eth reset to common misc driver so can used by other device families. Signed-off-by: Chin Liang See Signed-off-by: Ley Foon Tan >>> >>> Shouldn't this use the reset framework instead ? >>> >> What reset framework you refer to? drivers/reset? > > I think so, there were patches from Dinh earlier this month > 2ac718821a | Dinh Nguyen | reset: socfpga: add reset driver for > SoCFPGA platform > Noted, will remove this change. Regards Ley Foon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] rules for SPDX-License-Identifier
Hi Tom, On Sat, Apr 14, 2018 at 10:57 AM, Tom Rini wrote: > Ugh. It also looks like it wouldn't be easy to make it a relaxed check. > So we can either ignore SPDX_LICENSE_TAG in .checkpatch.conf (and be no > worse but not better than before) or a coccinelle script to whack all of > our current tags into kernel-style tags? I like more the coccinelle script idea to make U-Boot to match the SPDX notation used in the kernel. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] HACK: Some further clang support for ARM
- Have logic in one place for -ffixed-r9 or -ffixed-x18 as clang -target aarch64-linux-gnu will warn about being passed an invalid arugment, -ffixed-r9. I should submit this on its own as a cleanup. - clang does NOT like: str8w r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f and makes it a fatal error. Work-around this by expanding the macro by hand in 3 places. Not included in here is that clang does not at all care for the EFI loader saving / restoring gd in C as it does. This is already documented in doc/README.clang, but I'm spelling it out here. Cc: Alexander Graf Signed-off-by: Tom Rini --- arch/arm/config.mk | 10 -- arch/arm/cpu/armv8/config.mk | 1 - arch/arm/lib/memcpy.S| 4 ++-- 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index b448ed0b3ebd..f42aa35f4e59 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -13,12 +13,18 @@ CONFIG_STANDALONE_LOAD_ADDR = 0xc10 endif endif -CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections -fdata-sections +ifeq ($(CONFIG_ARM64),y) +FIXED_GD_REG := -ffixed-x18 +else +FIXED_GD_REG := -ffixed-r9 +endif + +CFLAGS_NON_EFI := -fno-pic $(FIXED_GD_REG) -ffunction-sections -fdata-sections CFLAGS_EFI := -fpic -fshort-wchar LDFLAGS_FINAL += --gc-sections PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \ --fno-common -ffixed-r9 +-fno-common $(FIXED_GD_REG) PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \ $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk index 27b66d41b1a8..2b6ced6648ec 100644 --- a/arch/arm/cpu/armv8/config.mk +++ b/arch/arm/cpu/armv8/config.mk @@ -4,7 +4,6 @@ # # SPDX-License-Identifier: GPL-2.0+ # -PLATFORM_RELFLAGS += -fno-common -ffixed-x18 PF_NO_UNALIGNED := $(call cc-option, -mstrict-align) PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED) diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S index 588b3f8971ae..307c3bbc1472 100644 --- a/arch/arm/lib/memcpy.S +++ b/arch/arm/lib/memcpy.S @@ -96,7 +96,7 @@ ENTRY(memcpy) 3: PLD(pld [r1, #124] ) 4: ldr8w r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f subsr2, r2, #32 - str8w r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f + stmia r0!, {r3, r4, r5, r6, r7, r8, ip, lr} bge 3b PLD(cmn r2, #96 ) PLD(bge 4b ) @@ -212,7 +212,7 @@ ENTRY(memcpy) orr r9, r9, ip, lspush #\push mov ip, ip, lspull #\pull orr ip, ip, lr, lspush #\push - str8w r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f + stmia r0!, {r3, r4, r5, r6, r7, r8, r9, ip} bge 12b PLD(cmn r2, #96 ) PLD(bge 13b ) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] clang: Update documentation
As of clang-5.0, things have changed a bit. First, we cannot automatically guess -target values as if we do not pass one with CC then cc-option will fail. Second, to disable movt/movw relocations the argument has become -mno-movt. Related to the target part, we cannot use arm-none-eabi as that ends up being too generic of an ARM target for things like say rpi_3_32b to work. Signed-off-by: Tom Rini --- arch/arm/config.mk | 5 ++--- doc/README.clang | 18 +++--- 2 files changed, 9 insertions(+), 14 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 9c213b897cd5..b448ed0b3ebd 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -23,9 +23,8 @@ PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \ $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) # LLVM support -LLVMS_RELFLAGS := $(call cc-option,-mllvm,) \ - $(call cc-option,-target arm-none-eabi,) \ - $(call cc-option,-arm-use-movt=0,) +LLVM_RELFLAGS := $(call cc-option,-mllvm,) \ + $(call cc-option,-mno-movt,) PLATFORM_RELFLAGS += $(LLVM_RELFLAGS) PLATFORM_CPPFLAGS += -D__ARM__ diff --git a/doc/README.clang b/doc/README.clang index e0491b2d7e6b..475bb1e2ed8b 100644 --- a/doc/README.clang +++ b/doc/README.clang @@ -10,16 +10,11 @@ used to get its value. This does lead to larger code then strictly necessary, but at least works. NOTE: target compilation only work for _some_ ARM boards at the moment. -Also Aarch64 is not supported: Most notably boards which aren't using -the generic board will fail to compile, but since those are expected -to be converted this will solve itself. Boards which reassign gd in c -will also fail to compile, but there is in no strict reason to do so -in the ARM world, since crt0.S takes care of this. These assignments -can be avoided by changing the init calls but this is not in mainline yet. - -NOTE: without the -mllvm -arm-use-movt=0 flags U-Boot will compile -fine, but llvm might hardcode addresses in movw / movt pairs, which -cannot be relocated and U-Boot will fail at runtime. +Also AArch64 is not supported currently due to a lack of private libgcc +support. Boards which reassign gd in c will also fail to compile, but there is +in no strict reason to do so in the ARM world, since crt0.S takes care of this. +These assignments can be avoided by changing the init calls but this is not in +mainline yet. Debian (based) -- @@ -29,7 +24,8 @@ sudo apt-get install clang Note that we still use binutils for some tools so we must continue to set CROSS_COMPILE. To compile U-Boot with clang on linux without IAS use e.g.: make HOSTCC=clang rpi_2_defconfig -make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- CC=clang -j8 +make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \ +CC="clang -target arm-linux-gnueabi" -j8 It can also be used to compile sandbox: make HOSTCC=clang sandbox_defconfig -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On Sun, Apr 22, 2018 at 05:29:25AM +0200, Marek Vasut wrote: > The following changes since commit a35747b5e1261adfb27ab87575dea4b17e247da2: > > Merge git://git.denx.de/u-boot-uniphier (2018-04-18 16:24:26 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to f7aa3cd4a81c7a1ef480e39a1b979483452325cb: > > ARM: rmobile: Update E2 Silk (2018-04-21 18:33:31 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Sun, Apr 22, 2018 at 05:29:46AM +0200, Marek Vasut wrote: > The following changes since commit a35747b5e1261adfb27ab87575dea4b17e247da2: > > Merge git://git.denx.de/u-boot-uniphier (2018-04-18 16:24:26 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to 38276090ee7fda6b31cac638d8c5f4fb61f57b0b: > > usb: dwc3-of-simple: fix error check of clk_get_bulk when disabled > (2018-04-21 18:38:56 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Migrate IMAGE_FORMAT_LEGACY to Kconfig
On Fri, Apr 20, 2018 at 09:25:38PM +, Alex Kiernan wrote: > This converts IMAGE_FORMAT_LEGACY to Kconfig > > Signed-off-by: Alex Kiernan Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Network Packet Buffers: raspberrypi: variable uchar *net_rx_packets[PKTBUFSRX] in net/net.c
Hi Duncan, On 17 April 2018 at 12:59, Duncan Hare wrote: > Simon > > Is it possible to modify the network driver for the raspberry pi to use > the buffer pool defined in net.c? > > It appears to have a single buffer, defined in the driver. > > In addition the buffer pool should be defined in memory outside the > u-boot image. With the current definition is the buffer pool a > part of the u-boot image? Are you referring to the USB driver? If so, which one? Normally the buffers are in BSS if they are not allocated with malloc(). So the buffers are not in the U-Boot image in flash, but do take up space in RAM at run-time after relocation. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] rockchip: rk3036: add ofdata_to_platdata() callback for driver
Hi Kever, On 18 April 2018 at 02:05, Kever Yang wrote: > Parse of data in dedicate api instead of in probe(). dedicated Also please can you call it a 'method' rather than a 'callback'? I feel that a callback is something provided by subsystem A which calls subsystem B, to allow B to call back into A. In this case, the driver is not the caller - it is just a driver. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] video_display: Add power_on function
Hi Mario, On 18 April 2018 at 02:30, Mario Six wrote: > Hi Simon, > > On Thu, Apr 12, 2018 at 6:36 PM, Simon Glass wrote: >> Hi Mario, >> >> On 11 April 2018 at 00:35, Mario Six wrote: >>> Hi Simon, >>> >>> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: Hi Mario, On 28 March 2018 at 20:40, Mario Six wrote: > Add a power_on function to the display uclass to allow devices to be > probed and powered-on separately. Is this different from the 'enable' method? >>> >>> I was thinking that this is more low-level than the enable method, which also >>> sets display parameters. I could also use the enable method if it's alright to >>> disregard the panel_bpp and timing parameters. >> >> Yes it's fine to ignore those. I'm just trying to use existing API >> calls where possible (without being silly about it!) >> > > OK, I'll switch to that function then. > >>> Also note that we have a panel uclass that might be useful. >>> >>> The Logicore driver is probably more low-level than that, but I'll take a look. >> >> OK. Conceptually a panel is just a display panel, so could be of any >> type, I think. >> > > Took another look: The panel uclass is still a bit thin, but the only operation > (enable_backlight) sounds more that it's supposed to contain drivers for "real" > panels (i.e. physical display devices). The Logicore TX really just generates a > DP signal and does not display it itself (the upcoming board has no display > capability at all, actually). So it probably better fits in the display uclass. OK I see. Please be sure to mention this info in your patches. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] core: Add function to get device for ofnode
Hi Mario, On 18 April 2018 at 02:20, Mario Six wrote: > Hi Simon, > > On Thu, Apr 12, 2018 at 6:42 PM, Simon Glass wrote: >> Hi Mario, >> >> On 10 April 2018 at 05:34, Mario Six wrote: >>> Hi Simon, >>> >>> On Fri, Mar 30, 2018 at 12:43 AM, Simon Glass wrote: Hi Mario, On 28 March 2018 at 20:37, Mario Six wrote: > It's sometimes useful to get the device associated with a given ofnode. > Implement a function to implement this lookup operation. Where would you use this? Can you not use phandles to find the device? Or uclass_get_device_by_ofnode() ? >>> >>> The function is used with the dev_{enable,disable}_by_path in the next patch: >>> If I used any of the uclass_* functions or similar, the device would be probed, >>> which is not what I want, since the device may not actually be physically >>> present. >> >> So how about using uclass_find_device_by_ofnode() ? >> > > That would work for the disabling, true, but not for the enabling (which is > what is used in the upcoming board): Since the node is declared as disabled in > the DT, the device is not even bound (so uclass_find_device_by_ofnode) won't > return it. > > A more elegant solution would be to have device_probe check again if the > underlying ofnode is disabled, and stop the probing if that's the case. In this > scenario the disabled devices would still be displayed in the tree, but never > probed, which is probably OK (I don't know if there would be any side effects > with iterating through devices, for example). But changing the behavior of such > elementary API functions is probably not a good idea. That seems to be a different topic. Fundamentally I don't see the difference between uclass_find_device_by_ofnode() and your ofnode_dev(). If you want to enable something after probing you will have to call device_bind() or similar. If that is your intent, I think you need a different function from ofnode_dev(), since it also relies on the device already being bound. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Use Android DT image format for TI boards
Hi, On 17 April 2018 at 14:57, Andrew F. Davis wrote: > On 04/16/2018 03:32 PM, Sam Protsenko wrote: >> Android documentation recommends using new image format for storing dtb >> and dtbo files: [1]. Using that format, we can pack several dtb files to >> dtb.img, and also pack several dtbo files to dtbo.img. Then those images >> should be flashed to eMMC partitions, called "dtb" and "dtbo" >> respectively. >> > > > I'm not convinced adding yet another one-off Android specific partition > format is what we need right now. With FIT images this is a solved > problem, why does Android need to go down a different path here? Agreed. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] dm: ofnode: add ofnode_device_is_compatible() helper
Hi Masahiro, On 17 April 2018 at 20:38, Masahiro Yamada wrote: > device_is_compatible() takes udevice, but there is no such a helper > that takes ofnode. > > Signed-off-by: Masahiro Yamada > --- > > drivers/core/device.c | 8 +--- > drivers/core/ofnode.c | 11 +++ > include/dm/ofnode.h | 11 +++ > 3 files changed, 23 insertions(+), 7 deletions(-) Please can you add a call to this to a test? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] syscon: add Linux-compatible syscon API
Hi Masahiro, On 17 April 2018 at 20:38, Masahiro Yamada wrote: > The syscon implementation in U-Boot is different from that in Linux. > Thus, DT files imported from Linux do not work for U-Boot. > > In U-Boot driver model, each node is bound to a dedicated driver > that is the most compatible to it. This design gets along with the > concept of DT, and the syscon in Linux originally worked like that. > > However, Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon > interface from platform devices") changed the behavior because it is > useful to let a device bind to another driver, but still works as a > syscon provider. > > That change had happened before U-Boot initially supported the syscon > driver by commit 6f98b7504f70 ("dm: Add support for generic system > controllers (syscon)"). So, the U-Boot's syscon works differently > from the beginning. I'd say this is mis-implementation given that > DT is not oriented to a particular project, but Linux is the canon > of DT in practice. > > The problem typically arises in the combination of "syscon" and > "simple-mfd" compatibles. > > In Linux, they are orthogonal, i.e., the order between "syscon" and > "simple-mfd" does not matter at all. > > Assume the following compatible. > >compatible = "foo,bar-syscon", "syscon", "simple-mfd"; > > In U-Boot, this device node is bound to the syscon driver > (driver/core/syscon-uclass.c) since the "syscon" is found to be the > most compatible. Then, syscon_get_regmap() succeeds. > > However, > >compatible = "foo,bar-syscon", "simple-mfd", "syscon"; > > does not work because this node is bound to the simple-bus driver > (drivers/core/simple-bus.c) in the favor of "simple-mfd" compatible. > The compatible string "syscon" is just dismissed. > > Moreover, > >compatible = "foo,bar-syscon", "syscon"; > > works like the first case because the syscon driver populates the > child devices. This is wrong because populating children is the job > of "simple-mfd" (or "simple-bus"). > > This commit ports syscon_node_to_regmap() from Linux. This API > does not require the given node to be bound to a driver in any way. > > Reported-by: Kunihiko Hayashi > Signed-off-by: Masahiro Yamada > --- > > drivers/core/syscon-uclass.c | 63 > include/syscon.h | 8 ++ > 2 files changed, 71 insertions(+) I was not aware of this change in how Linux worked, but it makes sense. Please can you add a test for this? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] regmap: clean up regmap allocation
Hi Masahiro, On 17 April 2018 at 20:38, Masahiro Yamada wrote: > Putting zero length array at the end of struct is a common technique > to embed arbitrary length of members. There is no good reason to let > regmap_alloc_count() branch by "if (count <= 1)". > > As far as I understood the code, regmap->base is an alias of > regmap->ranges[0].start, but it is not helpful but make the code > just ugly. > > Rename regmap_alloc_count() to regmap_alloc() because the _count > suffix seems pointless. > > Signed-off-by: Masahiro Yamada > --- > > drivers/core/regmap.c | 31 +-- > include/regmap.h | 7 ++- > 2 files changed, 11 insertions(+), 27 deletions(-) This seems fine to me and does not increase the number of allocations. Reviewed-by: Simon Glass Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] video_display: Add Xilinx LogiCore DP TX
Hi Mario, On 18 April 2018 at 02:52, Mario Six wrote: > Hi Simon, > > On Thu, Apr 12, 2018 at 6:38 PM, Simon Glass wrote: >> Hi Mario, >> >> On 11 April 2018 at 01:27, Mario Six wrote: >>> Hi Simon, >>> >>> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: Hi Mario, On 28 March 2018 at 20:40, Mario Six wrote: > Add a driver for the Xilinx LogiCORE DisplayPort IP core. > > Signed-off-by: Mario Six > --- > drivers/video/Kconfig|8 + > drivers/video/Makefile |1 + > drivers/video/logicore_dp_dpcd.h | 342 ++ > drivers/video/logicore_dp_tx.c | 1974 ++ > drivers/video/logicore_dp_tx.h | 40 + > drivers/video/logicore_dp_tx_regif.h | 365 +++ > 6 files changed, 2730 insertions(+) > create mode 100644 drivers/video/logicore_dp_dpcd.h > create mode 100644 drivers/video/logicore_dp_tx.c > create mode 100644 drivers/video/logicore_dp_tx.h > create mode 100644 drivers/video/logicore_dp_tx_regif.h Is it possible to have common code with the other DP drivers? >>> >>> While the DP transmitters, of course, all do similar things (e.g. they all >>> eventually set a lane count), the implementation details differ greatly, and I >>> think trying to merge them would only make things more confusing, since the >>> drivers tend to be pretty elaborate (looking at the exynos driver, for >>> example). >> >> OK. Are they merged in Linux? >> > > The Linux DP drivers don't share a common code base either (grepping > "lane_count" in drivers/gpu shows different implementations of lane setting and > link training). OK, well that is suggestive. Perhaps duplicating the code is best. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pinctrl: do not set_state for device without valid ofnode
On 18 April 2018 at 03:54, Kever Yang wrote: > Not all the udevice have a available DT node, eg. rksd...@ff50.blk > which add by mmc_bind(), these device do not have/need set pinctrl > state. > > Signed-off-by: Kever Yang > --- > > drivers/pinctrl/pinctrl-uclass.c | 6 ++ > 1 file changed, 6 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] regmap: change regmap_init_mem() to take ofnode instead udevice
Hi Masahiro, On 17 April 2018 at 20:38, Masahiro Yamada wrote: > Currently, regmap_init_mem() takes udevice. This requires the node > has already been associated with a device. It prevents syscon/regmap > from behaving like those in Linux. > > Change the first argumenet to take the device node. > > Signed-off-by: Masahiro Yamada > --- > > arch/arm/mach-aspeed/ast2500/sdram_ast2500.c | 2 +- > drivers/core/regmap.c| 11 +-- > drivers/core/syscon-uclass.c | 2 +- > drivers/phy/meson-gxl-usb2.c | 2 +- > drivers/phy/meson-gxl-usb3.c | 2 +- > drivers/ram/rockchip/dmc-rk3368.c| 2 +- > drivers/ram/rockchip/sdram_rk3188.c | 2 +- > drivers/ram/rockchip/sdram_rk322x.c | 2 +- > drivers/ram/rockchip/sdram_rk3288.c | 2 +- > drivers/ram/rockchip/sdram_rk3399.c | 2 +- > drivers/ram/stm32mp1/stm32mp1_ram.c | 2 +- > drivers/reset/reset-meson.c | 2 +- > include/regmap.h | 4 ++-- > 13 files changed, 18 insertions(+), 19 deletions(-) Can you please add a simple test for regmap on sandbox? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rpi: Adjust fdt_addr_r to a sane address
On Fri, 20 Apr 2018 13:03:47 +0300 Tuomas Tynkkynen wrote: > Hi Alexander, > > What do you think of these patches? I haven't done testing with the > big kernels / DTBs yet, just that my previously-working kernel still > boots. > I've now verified that these two patches work as expected. I tested: - RPi 1 running mainline kernel - RPi 1 running downstream kernel - RPi 3 running mainline kernel in 64-bit mode - RPi 3 running mainline kernel in 32-bit mode - RPi 3 running downstream kernel in 32-bit mode - RPi 3B+ running downstream kernel in 32-bit mode This was with the extlinux.conf distro boot. I don't know to what extent these variables affect EFI boot. > Tuomas Tynkkynen (2): > rpi: Fix fdt_high & initrd_high for 64-bit builds > rpi: Change load addresses to make more room for the kernel & DTB > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Makefile: Update clang warning disables from Linux
Re-sync the logic about which clang warnings to disable from v4.17-rc1. Note that we don't disable all of the same ones as for now we haven't run into any cases of warnings from clang in code from upstream Linux. Signed-off-by: Tom Rini --- Makefile | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Makefile b/Makefile index 64351eb769e2..143644c98759 100644 --- a/Makefile +++ b/Makefile @@ -610,6 +610,13 @@ endif endif KBUILD_CFLAGS += $(call cc-option,-Wno-format-nonliteral) +ifeq ($(cc-name),clang) +KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,) +KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier) +KBUILD_CFLAGS += $(call cc-disable-warning, gnu) +KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member) +KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior) +endif # turn jbsr into jsr for m68k ifeq ($(ARCH),m68k) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] video-uclass: Fix logical-not-parentheses warning
With clang-4.0 and later we see: warning: logical not is only applied to the left hand side of this bitwise operator [-Wlogical-not-parentheses] if ((!gd->flags & GD_FLG_RELOC)) ^ ~ And while the compiler suggests adding parenthesis around gd->flags, a reading of the code says that we want to know when GD_FLG_RELOC is not set and then return. Cc: Simon Glass Cc: Anatolij Gustschin Signed-off-by: Tom Rini --- drivers/video/video-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c index b5bb8e0efde5..93fdc6828b1e 100644 --- a/drivers/video/video-uclass.c +++ b/drivers/video/video-uclass.c @@ -272,7 +272,7 @@ static int video_post_bind(struct udevice *dev) ulong size; /* Before relocation there is nothing to do here */ - if ((!gd->flags & GD_FLG_RELOC)) + if (!(gd->flags & GD_FLG_RELOC)) return 0; size = alloc_fb(dev, &addr); if (addr < gd->video_bottom) { -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation
On 04/20/2018 09:07 PM, Ramon Fried wrote: Actually, I already verified that. the driver probes twice, once before and once after relocation. In case of serial, it's not a big deal to re-initialize the hardware, but I agree it's worthless. Ok. just checked, it's first probed before relocation. ah of course, the db820 - what I was using to validate- doesnt probe early despite the change because the uart node doesnt use the clock. cool, looks good to me. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot