[U-Boot] [PATCH] Kconfig: set default BUILD_TARGET for kirkwood
Now that BUILD_TARGET is in Kconfig we can define a default for boards using the Kirkwood SoC. Signed-off-by: Chris Packham Cc: Jagan Teki --- This is based on http://patchwork.ozlabs.org/patch/1026858/ Kconfig| 1 + configs/SBx81LIFKW_defconfig | 1 - configs/SBx81LIFXCAT_defconfig | 1 - configs/dreamplug_defconfig| 1 - configs/ds109_defconfig| 1 - configs/guruplug_defconfig | 1 - configs/ib62x0_defconfig | 1 - configs/nsa310s_defconfig | 1 - configs/sheevaplug_defconfig | 1 - 9 files changed, 1 insertion(+), 8 deletions(-) diff --git a/Kconfig b/Kconfig index 3a3a8d4d5bd6..e8fc5e7e727e 100644 --- a/Kconfig +++ b/Kconfig @@ -230,6 +230,7 @@ config BUILD_TARGET default "u-boot-spl.kwb" if ARCH_MVEBU && SPL_BUILD default "u-boot-elf.srec" if RCAR_GEN3 default "u-boot.itb" if ARCH_SUNXI && ARM64 + default "u-boot.kwb" if KIRKWOOD help Some SoCs need special image types (e.g. U-Boot binary with a special header) as build targets. By defining diff --git a/configs/SBx81LIFKW_defconfig b/configs/SBx81LIFKW_defconfig index 52bb70ae8c09..e0ce1595c5ee 100644 --- a/configs/SBx81LIFKW_defconfig +++ b/configs/SBx81LIFKW_defconfig @@ -5,7 +5,6 @@ CONFIG_TARGET_SBx81LIFKW=y CONFIG_IDENT_STRING="\nSBx81LIFKW" # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 -CONFIG_BUILD_TARGET="u-boot.kwb" CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y CONFIG_MISC_INIT_R=y diff --git a/configs/SBx81LIFXCAT_defconfig b/configs/SBx81LIFXCAT_defconfig index b322ab0959db..4a6e05844fec 100644 --- a/configs/SBx81LIFXCAT_defconfig +++ b/configs/SBx81LIFXCAT_defconfig @@ -5,7 +5,6 @@ CONFIG_TARGET_SBx81LIFXCAT=y CONFIG_IDENT_STRING="\nSBx81LIFXCAT" # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 -CONFIG_BUILD_TARGET="u-boot.kwb" CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y CONFIG_MISC_INIT_R=y diff --git a/configs/dreamplug_defconfig b/configs/dreamplug_defconfig index 762521f97d7c..d3263cf9cd3f 100644 --- a/configs/dreamplug_defconfig +++ b/configs/dreamplug_defconfig @@ -6,7 +6,6 @@ CONFIG_IDENT_STRING="\nMarvell-DreamPlug" CONFIG_NR_DRAM_BANKS=2 # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 -CONFIG_BUILD_TARGET="u-boot.kwb" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_HUSH_PARSER=y # CONFIG_CMD_FLASH is not set diff --git a/configs/ds109_defconfig b/configs/ds109_defconfig index b72174eada3c..352403e57385 100644 --- a/configs/ds109_defconfig +++ b/configs/ds109_defconfig @@ -5,7 +5,6 @@ CONFIG_TARGET_DS109=y CONFIG_NR_DRAM_BANKS=2 # CONFIG_SYS_MALLOC_F is not set CONFIG_HUSH_PARSER=y -CONFIG_BUILD_TARGET="u-boot.kwb" # CONFIG_CMD_FLASH is not set CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y diff --git a/configs/guruplug_defconfig b/configs/guruplug_defconfig index 7726f9a76990..9998e48ab9c2 100644 --- a/configs/guruplug_defconfig +++ b/configs/guruplug_defconfig @@ -6,7 +6,6 @@ CONFIG_IDENT_STRING="\nMarvell-GuruPlug" CONFIG_NR_DRAM_BANKS=2 # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 -CONFIG_BUILD_TARGET="u-boot.kwb" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y diff --git a/configs/ib62x0_defconfig b/configs/ib62x0_defconfig index 03987a4ff192..985d85e02746 100644 --- a/configs/ib62x0_defconfig +++ b/configs/ib62x0_defconfig @@ -5,7 +5,6 @@ CONFIG_TARGET_IB62X0=y CONFIG_IDENT_STRING=" RaidSonic ICY BOX IB-NAS62x0" CONFIG_NR_DRAM_BANKS=2 CONFIG_BOOTDELAY=3 -CONFIG_BUILD_TARGET="u-boot.kwb" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="ib62x0 => " diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig index 971d33b33dd2..eb29a70157c9 100644 --- a/configs/nsa310s_defconfig +++ b/configs/nsa310s_defconfig @@ -4,7 +4,6 @@ CONFIG_SYS_TEXT_BASE=0x60 CONFIG_TARGET_NSA310S=y CONFIG_NR_DRAM_BANKS=2 CONFIG_BOOTDELAY=3 -CONFIG_BUILD_TARGET="u-boot.kwb" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="nsa310s => " diff --git a/configs/sheevaplug_defconfig b/configs/sheevaplug_defconfig index 33cced9c48db..04b00cdea9d4 100644 --- a/configs/sheevaplug_defconfig +++ b/configs/sheevaplug_defconfig @@ -7,7 +7,6 @@ CONFIG_IDENT_STRING="\nMarvell-Sheevaplug" CONFIG_NR_DRAM_BANKS=2 # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 -CONFIG_BUILD_TARGET="u-boot.kwb" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] buildman: fix typo
Fix a typo in the error message from CheckOutputDir().
Signed-off-by: Chris Packham
---
tools/buildman/control.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 27916d3c355d..fcf531c5f143 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -99,7 +99,7 @@ def CheckOutputDir(output_dir):
cwd_path = os.path.realpath('.')
while True:
if os.path.realpath(path) == cwd_path:
-Print("Cannot use output directory '%s' since it is within the
current directtory '%s'" %
+Print("Cannot use output directory '%s' since it is within the
current directory '%s'" %
(path, cwd_path))
sys.exit(1)
parent = os.path.dirname(path)
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] Kconfig: Migrate CONFIG_BUILD_TARGET
Migrate CONFIG_BUILD_TARGET into Kconfig. Signed-off-by: Jagan Teki --- Changes for v2: - build target type 'u-boot.itb' when SPL_LOAD_FIT being used Kconfig | 13 + README| 7 --- arch/arm/mach-mvebu/include/mach/config.h | 5 - configs/SBx81LIFKW_defconfig | 1 + configs/SBx81LIFXCAT_defconfig| 1 + configs/dreamplug_defconfig | 1 + configs/ds109_defconfig | 1 + configs/guruplug_defconfig| 1 + configs/ib62x0_defconfig | 1 + configs/nsa310s_defconfig | 1 + configs/sheevaplug_defconfig | 1 + include/configs/SBx81LIFKW.h | 1 - include/configs/SBx81LIFXCAT.h| 1 - include/configs/ib62x0.h | 3 --- include/configs/mv-plug-common.h | 3 --- include/configs/nsa310s.h | 3 --- include/configs/rcar-gen3-common.h| 1 - include/configs/socfpga_common.h | 3 --- include/configs/sunxi-common.h| 1 - scripts/config_whitelist.txt | 1 - 20 files changed, 21 insertions(+), 29 deletions(-) diff --git a/Kconfig b/Kconfig index aff7b2e00a..15b79259a8 100644 --- a/Kconfig +++ b/Kconfig @@ -224,6 +224,19 @@ config BUILD_ROM which are not shipped in the U-Boot source tree. Please, see doc/README.x86 for details. +config BUILD_TARGET + string "Build target special images" + default "u-boot-with-spl.sfp" if ARCH_SOCFPGA + default "u-boot-spl.kwb" if ARCH_MVEBU && SPL_BUILD + default "u-boot-elf.srec" if RCAR_GEN3 + default "u-boot.itb" if SPL_LOAD_FIT && ARCH_SUNXI + help + Some SoCs need special image types (e.g. U-Boot binary + with a special header) as build targets. By defining + CONFIG_BUILD_TARGET in the SoC / board header, this + special image will be automatically built upon calling + make / buildman. + endmenu# General setup menu "Boot images" diff --git a/README b/README index 17d56b8034..01ad69e926 100644 --- a/README +++ b/README @@ -1998,13 +1998,6 @@ The following options need to be configured: 200 ms. - Configuration Management: - CONFIG_BUILD_TARGET - - Some SoCs need special image types (e.g. U-Boot binary - with a special header) as build targets. By defining - CONFIG_BUILD_TARGET in the SoC / board header, this - special image will be automatically built upon calling - make / buildman. CONFIG_IDENT_STRING diff --git a/arch/arm/mach-mvebu/include/mach/config.h b/arch/arm/mach-mvebu/include/mach/config.h index f165d10018..e3235fc67e 100644 --- a/arch/arm/mach-mvebu/include/mach/config.h +++ b/arch/arm/mach-mvebu/include/mach/config.h @@ -40,11 +40,6 @@ #defineCONFIG_SYS_KWD_CONFIG arch/arm/mach-mvebu/kwbimage.cfg #endif /* CONFIG_SYS_KWD_CONFIG */ -/* Add target to build it automatically upon "make" */ -#ifdef CONFIG_SPL -#define CONFIG_BUILD_TARGET"u-boot-spl.kwb" -#endif - /* end of 16M scrubbed by training in bootrom */ #define CONFIG_SYS_INIT_SP_ADDR0x00FF diff --git a/configs/SBx81LIFKW_defconfig b/configs/SBx81LIFKW_defconfig index e0ce1595c5..52bb70ae8c 100644 --- a/configs/SBx81LIFKW_defconfig +++ b/configs/SBx81LIFKW_defconfig @@ -5,6 +5,7 @@ CONFIG_TARGET_SBx81LIFKW=y CONFIG_IDENT_STRING="\nSBx81LIFKW" # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 +CONFIG_BUILD_TARGET="u-boot.kwb" CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y CONFIG_MISC_INIT_R=y diff --git a/configs/SBx81LIFXCAT_defconfig b/configs/SBx81LIFXCAT_defconfig index 4a6e05844f..b322ab0959 100644 --- a/configs/SBx81LIFXCAT_defconfig +++ b/configs/SBx81LIFXCAT_defconfig @@ -5,6 +5,7 @@ CONFIG_TARGET_SBx81LIFXCAT=y CONFIG_IDENT_STRING="\nSBx81LIFXCAT" # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 +CONFIG_BUILD_TARGET="u-boot.kwb" CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y CONFIG_MISC_INIT_R=y diff --git a/configs/dreamplug_defconfig b/configs/dreamplug_defconfig index d3263cf9cd..762521f97d 100644 --- a/configs/dreamplug_defconfig +++ b/configs/dreamplug_defconfig @@ -6,6 +6,7 @@ CONFIG_IDENT_STRING="\nMarvell-DreamPlug" CONFIG_NR_DRAM_BANKS=2 # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 +CONFIG_BUILD_TARGET="u-boot.kwb" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_HUSH_PARSER=y # CONFIG_CMD_FLASH is not set diff --git a/configs/ds109_defconfig b/configs/ds109_defconfig index 352403e573..b72174eada 100644 --- a/configs/ds109_defconfig +++ b/configs/ds109_defconfig @@ -5,6 +5,7 @@ CONFIG_TARGET_DS109=y CONFIG_NR_DRAM_BANKS=2 # CONFIG_SYS_MALLOC_F is not set CONFIG_HUSH_PARSER=y +CONFIG_BUILD_TARGET="u-boot.kwb" # CONFIG_CMD_FLASH is not set CONFIG_CMD_IDE=y
[U-Boot] [PATCH v2 2/2] Kconfig: Add u-boot.itb BUILD_TARGET for Rockchip
Add u-boot.itb BUILD_TARGET for Rockchip platform when SPL_LOAD_FIT is being used. This can get rid of building itb explicitly with 'make u-boot.itb' all required images will now build just by make. Signed-off-by: Jagan Teki --- Changes for v2: - build target type 'u-boot.itb' when SPL_LOAD_FIT being used Kconfig| 2 +- board/rockchip/evb_rk3399/README | 1 - board/theobroma-systems/lion_rk3368/README | 9 ++--- board/theobroma-systems/puma_rk3399/README | 1 - board/vamrs/rock960_rk3399/README | 1 - 5 files changed, 3 insertions(+), 11 deletions(-) diff --git a/Kconfig b/Kconfig index 15b79259a8..cf175ef33f 100644 --- a/Kconfig +++ b/Kconfig @@ -229,7 +229,7 @@ config BUILD_TARGET default "u-boot-with-spl.sfp" if ARCH_SOCFPGA default "u-boot-spl.kwb" if ARCH_MVEBU && SPL_BUILD default "u-boot-elf.srec" if RCAR_GEN3 - default "u-boot.itb" if SPL_LOAD_FIT && ARCH_SUNXI + default "u-boot.itb" if SPL_LOAD_FIT && (ARCH_ROCKCHIP || ARCH_SUNXI) help Some SoCs need special image types (e.g. U-Boot binary with a special header) as build targets. By defining diff --git a/board/rockchip/evb_rk3399/README b/board/rockchip/evb_rk3399/README index 8321467046..c388f269c1 100644 --- a/board/rockchip/evb_rk3399/README +++ b/board/rockchip/evb_rk3399/README @@ -58,7 +58,6 @@ Compile the U-Boot for firefly-rk3399, use below instead: > make firefly-rk3399_defconfig > make - > make u-boot.itb Get spl/u-boot-spl.bin and u-boot.itb in this step. diff --git a/board/theobroma-systems/lion_rk3368/README b/board/theobroma-systems/lion_rk3368/README index 83e4332984..241d4d9ec8 100644 --- a/board/theobroma-systems/lion_rk3368/README +++ b/board/theobroma-systems/lion_rk3368/README @@ -14,18 +14,13 @@ Configure U-Boot > cd ../u-boot > make lion-rk3368_defconfig -Build the TPL/SPL stage -=== +Build the TPL/SPL, U-Boot proper and a FIT image including the ATF +== > make CROSS_COMPILE=aarch64-unknown-elf- ARCH=arm > tools/mkimage -n rk3368 -T rksd -d tpl/u-boot-tpl.bin spl-3368.img > cat spl/u-boot-spl-dtb.bin >> spl-3368.img -Build the full U-Boot and a FIT image including the ATF -=== - - > make CROSS_COMPILE=aarch64-unknown-elf- ARCH=arm u-boot.itb - Flash the image === diff --git a/board/theobroma-systems/puma_rk3399/README b/board/theobroma-systems/puma_rk3399/README index f67dfb451f..c06c9650b8 100644 --- a/board/theobroma-systems/puma_rk3399/README +++ b/board/theobroma-systems/puma_rk3399/README @@ -60,7 +60,6 @@ Creating a SPL image for SD-Card/eMMC 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 === diff --git a/board/vamrs/rock960_rk3399/README b/board/vamrs/rock960_rk3399/README index d14399090e..c5c675c4ea 100644 --- a/board/vamrs/rock960_rk3399/README +++ b/board/vamrs/rock960_rk3399/README @@ -61,7 +61,6 @@ Compile the U-Boot > export CROSS_COMPILE=aarch64-linux-gnu- > make rock960-rk3399_defconfig > make - > make u-boot.itb Compile the rkdeveloptool = -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fs: fat: dynamically allocate memory for temporary buffer
On 1/17/19 7:52 AM, tien.fong.c...@intel.com wrote:
> From: Stefan Agner
>
> Drop the statically allocated get_contents_vfatname_block and
> dynamically allocate a buffer only if required. This saves
> 64KiB of memory.
>
> Signed-off-by: Stefan Agner
> Signed-off-by: Tien Fong Chee
> ---
> fs/fat/fat.c | 19 +--
> 1 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index 8803fb4..aa4636d 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -307,9 +307,6 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
> unsigned long size)
> * into 'buffer'.
> * Update the number of bytes read in *gotsize or return -1 on fatal errors.
> */
> -__u8 get_contents_vfatname_block[MAX_CLUSTSIZE]
> - __aligned(ARCH_DMA_MINALIGN);
> -
> static int get_contents(fsdata *mydata, dir_entry *dentptr, loff_t pos,
> __u8 *buffer, loff_t maxsize, loff_t *gotsize)
> {
> @@ -320,7 +317,7 @@ static int get_contents(fsdata *mydata, dir_entry
> *dentptr, loff_t pos,
> loff_t actsize;
>
> *gotsize = 0;
> - debug("Filesize: %llu bytes\n", filesize);
> + debug("Filesize: %llu bytes, starting at pos %llu\n", filesize, pos);
This looks like a separate change.
> if (pos >= filesize) {
> debug("Read position past EOF: %llu\n", pos);
> @@ -352,15 +349,25 @@ static int get_contents(fsdata *mydata, dir_entry
> *dentptr, loff_t pos,
>
> /* align to beginning of next cluster if any */
> if (pos) {
> + __u8 *tmp_buffer;
> +
> + tmp_buffer = malloc_cache_aligned(MAX_CLUSTSIZE);
Don't you know the cluster size by now ?
> + if (!tmp_buffer) {
> + debug("Error: allocating buffer\n");
> + return -ENOMEM;
> + }
> +
> actsize = min(filesize, (loff_t)bytesperclust);
> - if (get_cluster(mydata, curclust, get_contents_vfatname_block,
> + if (get_cluster(mydata, curclust, tmp_buffer,
> (int)actsize) != 0) {
> printf("Error reading cluster\n");
> + free(tmp_buffer);
> return -1;
> }
> filesize -= actsize;
> actsize -= pos;
> - memcpy(buffer, get_contents_vfatname_block + pos, actsize);
> + memcpy(buffer, tmp_buffer + pos, actsize);
> + free(tmp_buffer);
How many times is this malloc()/free() called ? I wonder how much this
slows things down and how much it fragments the heap. Maybe the amount
of calls to this can be reduced somehow.
> *gotsize += actsize;
> if (!filesize)
> return 0;
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL
On 1/17/19 7:57 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee > > This is minimum memory pool size required to get SPL booting to U-Boot, > such as FPGA program and loading U-Boot image from FAT. Rather, this is the minimal size needed for FAT to work ? But then , maybe you should just set the malloc area size a bit bigger to have some headroom available. How did you come to the number 0x12000 ? Did you do some measurements ? > Signed-off-by: Tien Fong Chee > --- > include/configs/socfpga_common.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index bd8f5c8..93273a8 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -258,7 +258,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void); > #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > /* SPL memory allocation configuration, this is for FAT implementation */ > #ifndef CONFIG_SYS_SPL_MALLOC_START > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00012000 > #define CONFIG_SYS_SPL_MALLOC_START (CONFIG_SYS_INIT_RAM_SIZE - \ >CONFIG_SYS_SPL_MALLOC_SIZE + \ >CONFIG_SYS_INIT_RAM_ADDR) > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Kconfig: Migrate CONFIG_BUILD_TARGET
On Fri, 18 Jan 2019, 8:03 PM Jagan Teki On Fri, Jan 18, 2019 at 12:18 PM Chris Packham > wrote: > > > > > > > > On Fri, 18 Jan 2019, 6:57 AM Jagan Teki wrote: > >> > >> Migrate CONFIG_BUILD_TARGET into Kconfig. > >> > >> Signed-off-by: Jagan Teki > >> --- > >> Kconfig | 13 + > >> README| 7 --- > >> arch/arm/mach-mvebu/include/mach/config.h | 5 - > >> configs/SBx81LIFKW_defconfig | 1 + > >> configs/SBx81LIFXCAT_defconfig| 1 + > >> configs/dreamplug_defconfig | 1 + > >> configs/ds109_defconfig | 1 + > >> configs/guruplug_defconfig| 1 + > >> configs/ib62x0_defconfig | 1 + > >> configs/nsa310s_defconfig | 1 + > >> configs/sheevaplug_defconfig | 1 + > >> include/configs/SBx81LIFKW.h | 1 - > >> include/configs/SBx81LIFXCAT.h| 1 - > >> include/configs/ib62x0.h | 3 --- > >> include/configs/mv-plug-common.h | 3 --- > >> include/configs/nsa310s.h | 3 --- > >> include/configs/rcar-gen3-common.h| 1 - > >> include/configs/socfpga_common.h | 3 --- > >> include/configs/sunxi-common.h| 1 - > >> scripts/config_whitelist.txt | 1 - > >> 20 files changed, 21 insertions(+), 29 deletions(-) > >> > >> diff --git a/Kconfig b/Kconfig > >> index aff7b2e00a..3a3a8d4d5b 100644 > >> --- a/Kconfig > >> +++ b/Kconfig > >> @@ -224,6 +224,19 @@ config BUILD_ROM > >> which are not shipped in the U-Boot source tree. > >> Please, see doc/README.x86 for details. > >> > >> +config BUILD_TARGET > >> + string "Build target special images" > >> + default "u-boot-with-spl.sfp" if ARCH_SOCFPGA > >> + default "u-boot-spl.kwb" if ARCH_MVEBU && SPL_BUILD > >> + default "u-boot-elf.srec" if RCAR_GEN3 > >> + default "u-boot.itb" if ARCH_SUNXI && ARM64 > > > > > > default "u-boot.kwb" if KIRKWOOD would also be good to add. I can do it > if you don't send a v2. > > Is it new change, if yes prepare another patch? if not let me know > where do we need to change I mean which ARCH in above definition. > Yeah it'd be new to this Kconfig but it would have saved you having to update some of the defconfigs. Since you've already done the defconfig changes I can send a patch on top of this that adds a default and removes some of the defconfig changes. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Kconfig: Migrate CONFIG_BUILD_TARGET
On Fri, Jan 18, 2019 at 12:18 PM Chris Packham wrote: > > > > On Fri, 18 Jan 2019, 6:57 AM Jagan Teki > >> Migrate CONFIG_BUILD_TARGET into Kconfig. >> >> Signed-off-by: Jagan Teki >> --- >> Kconfig | 13 + >> README| 7 --- >> arch/arm/mach-mvebu/include/mach/config.h | 5 - >> configs/SBx81LIFKW_defconfig | 1 + >> configs/SBx81LIFXCAT_defconfig| 1 + >> configs/dreamplug_defconfig | 1 + >> configs/ds109_defconfig | 1 + >> configs/guruplug_defconfig| 1 + >> configs/ib62x0_defconfig | 1 + >> configs/nsa310s_defconfig | 1 + >> configs/sheevaplug_defconfig | 1 + >> include/configs/SBx81LIFKW.h | 1 - >> include/configs/SBx81LIFXCAT.h| 1 - >> include/configs/ib62x0.h | 3 --- >> include/configs/mv-plug-common.h | 3 --- >> include/configs/nsa310s.h | 3 --- >> include/configs/rcar-gen3-common.h| 1 - >> include/configs/socfpga_common.h | 3 --- >> include/configs/sunxi-common.h| 1 - >> scripts/config_whitelist.txt | 1 - >> 20 files changed, 21 insertions(+), 29 deletions(-) >> >> diff --git a/Kconfig b/Kconfig >> index aff7b2e00a..3a3a8d4d5b 100644 >> --- a/Kconfig >> +++ b/Kconfig >> @@ -224,6 +224,19 @@ config BUILD_ROM >> which are not shipped in the U-Boot source tree. >> Please, see doc/README.x86 for details. >> >> +config BUILD_TARGET >> + string "Build target special images" >> + default "u-boot-with-spl.sfp" if ARCH_SOCFPGA >> + default "u-boot-spl.kwb" if ARCH_MVEBU && SPL_BUILD >> + default "u-boot-elf.srec" if RCAR_GEN3 >> + default "u-boot.itb" if ARCH_SUNXI && ARM64 > > > default "u-boot.kwb" if KIRKWOOD would also be good to add. I can do it if > you don't send a v2. Is it new change, if yes prepare another patch? if not let me know where do we need to change I mean which ARCH in above definition. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Kconfig: Migrate CONFIG_BUILD_TARGET
On Fri, 18 Jan 2019, 6:57 AM Jagan Teki Migrate CONFIG_BUILD_TARGET into Kconfig. > > Signed-off-by: Jagan Teki > --- > Kconfig | 13 + > README| 7 --- > arch/arm/mach-mvebu/include/mach/config.h | 5 - > configs/SBx81LIFKW_defconfig | 1 + > configs/SBx81LIFXCAT_defconfig| 1 + > configs/dreamplug_defconfig | 1 + > configs/ds109_defconfig | 1 + > configs/guruplug_defconfig| 1 + > configs/ib62x0_defconfig | 1 + > configs/nsa310s_defconfig | 1 + > configs/sheevaplug_defconfig | 1 + > include/configs/SBx81LIFKW.h | 1 - > include/configs/SBx81LIFXCAT.h| 1 - > include/configs/ib62x0.h | 3 --- > include/configs/mv-plug-common.h | 3 --- > include/configs/nsa310s.h | 3 --- > include/configs/rcar-gen3-common.h| 1 - > include/configs/socfpga_common.h | 3 --- > include/configs/sunxi-common.h| 1 - > scripts/config_whitelist.txt | 1 - > 20 files changed, 21 insertions(+), 29 deletions(-) > > diff --git a/Kconfig b/Kconfig > index aff7b2e00a..3a3a8d4d5b 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -224,6 +224,19 @@ config BUILD_ROM > which are not shipped in the U-Boot source tree. > Please, see doc/README.x86 for details. > > +config BUILD_TARGET > + string "Build target special images" > + default "u-boot-with-spl.sfp" if ARCH_SOCFPGA > + default "u-boot-spl.kwb" if ARCH_MVEBU && SPL_BUILD > + default "u-boot-elf.srec" if RCAR_GEN3 > + default "u-boot.itb" if ARCH_SUNXI && ARM64 > default "u-boot.kwb" if KIRKWOOD would also be good to add. I can do it if you don't send a v2. + help > + Some SoCs need special image types (e.g. U-Boot binary > + with a special header) as build targets. By defining > + CONFIG_BUILD_TARGET in the SoC / board header, this > + special image will be automatically built upon calling > + make / buildman. > + > endmenu# General setup > > menu "Boot images" > diff --git a/README b/README > index 17d56b8034..01ad69e926 100644 > --- a/README > +++ b/README > @@ -1998,13 +1998,6 @@ The following options need to be configured: > 200 ms. > > - Configuration Management: > - CONFIG_BUILD_TARGET > - > - Some SoCs need special image types (e.g. U-Boot binary > - with a special header) as build targets. By defining > - CONFIG_BUILD_TARGET in the SoC / board header, this > - special image will be automatically built upon calling > - make / buildman. > > CONFIG_IDENT_STRING > > diff --git a/arch/arm/mach-mvebu/include/mach/config.h > b/arch/arm/mach-mvebu/include/mach/config.h > index f165d10018..e3235fc67e 100644 > --- a/arch/arm/mach-mvebu/include/mach/config.h > +++ b/arch/arm/mach-mvebu/include/mach/config.h > @@ -40,11 +40,6 @@ > #defineCONFIG_SYS_KWD_CONFIG arch/arm/mach-mvebu/kwbimage.cfg > #endif /* CONFIG_SYS_KWD_CONFIG */ > > -/* Add target to build it automatically upon "make" */ > -#ifdef CONFIG_SPL > -#define CONFIG_BUILD_TARGET"u-boot-spl.kwb" > -#endif > - > /* end of 16M scrubbed by training in bootrom */ > #define CONFIG_SYS_INIT_SP_ADDR0x00FF > > diff --git a/configs/SBx81LIFKW_defconfig b/configs/SBx81LIFKW_defconfig > index e0ce1595c5..52bb70ae8c 100644 > --- a/configs/SBx81LIFKW_defconfig > +++ b/configs/SBx81LIFKW_defconfig > @@ -5,6 +5,7 @@ CONFIG_TARGET_SBx81LIFKW=y > CONFIG_IDENT_STRING="\nSBx81LIFKW" > # CONFIG_SYS_MALLOC_F is not set > CONFIG_BOOTDELAY=3 > +CONFIG_BUILD_TARGET="u-boot.kwb" > CONFIG_SILENT_CONSOLE=y > CONFIG_SILENT_U_BOOT_ONLY=y > CONFIG_MISC_INIT_R=y > diff --git a/configs/SBx81LIFXCAT_defconfig > b/configs/SBx81LIFXCAT_defconfig > index 4a6e05844f..b322ab0959 100644 > --- a/configs/SBx81LIFXCAT_defconfig > +++ b/configs/SBx81LIFXCAT_defconfig > @@ -5,6 +5,7 @@ CONFIG_TARGET_SBx81LIFXCAT=y > CONFIG_IDENT_STRING="\nSBx81LIFXCAT" > # CONFIG_SYS_MALLOC_F is not set > CONFIG_BOOTDELAY=3 > +CONFIG_BUILD_TARGET="u-boot.kwb" > CONFIG_SILENT_CONSOLE=y > CONFIG_SILENT_U_BOOT_ONLY=y > CONFIG_MISC_INIT_R=y > diff --git a/configs/dreamplug_defconfig b/configs/dreamplug_defconfig > index d3263cf9cd..762521f97d 100644 > --- a/configs/dreamplug_defconfig > +++ b/configs/dreamplug_defconfig > @@ -6,6 +6,7 @@ CONFIG_IDENT_STRING="\nMarvell-DreamPlug" > CONFIG_NR_DRAM_BANKS=2 > # CONFIG_SYS_MALLOC_F is not set > CONFIG_BOOTDELAY=3 > +CONFIG_BUILD_TARGET="u-boot.kwb" > # CONFIG_DISPLAY_BOARDINFO is not set > CONFIG_HUSH_PARSER=y > # CONFIG_CMD_FLASH is not set > diff --git a/configs/ds109_defconfig b/configs/ds109_defconfig > index
Re: [U-Boot] [PATCH 2/2] arm: mvebu: armada-xp/37x/38x: Enable PCIe DT node
On Fri, 18 Jan 2019, 7:15 PM Stefan Roese Hi Chris, > > On 17.01.19 20:57, Chris Packham wrote: > > Hi Stefan, > > > > On Fri, Jan 18, 2019 at 2:35 AM Stefan Roese wrote: > >> > >> This patch enables the DT PCIe nodes for the Armada XP/37x/38x boards. > >> This is needed for the new DM_PCI support in the MVEBU PCIe driver. > >> > >> Signed-off-by: Stefan Roese > >> Cc: Dirk Eibach > >> Cc: Mario Six > >> Cc: Chris Packham > >> Cc: Phil Sutter > >> Cc: Marek Behún > >> Cc: VlaoMao > >> --- > >> arch/arm/dts/armada-375.dtsi| 2 +- > >> arch/arm/dts/armada-380.dtsi| 2 +- > >> arch/arm/dts/armada-385.dtsi| 2 +- > >> arch/arm/dts/armada-xp-mv78230.dtsi | 2 +- > >> arch/arm/dts/armada-xp-mv78260.dtsi | 2 +- > >> arch/arm/dts/armada-xp-mv78460.dtsi | 2 +- > >> 6 files changed, 6 insertions(+), 6 deletions(-) > > > > I think this should be at the board level instead of the SoC. > I agree (please see below). > > > There > > are boards that don't use the pcie controller even though it's in the > > SoC. > > This use case is handled by enabling the PCI_MVEBU driver on a board > per board case in U-Boot. But nevertheless I agree in general. > > > Another good reason is that this deviates from the dtsi files in > > Linux > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-375.dtsi#n548 > > Yes, my first version did not change the dtsi file but the board dts > file (theadorable in this case). My motivation was to not change anything > in the configuration for these Armada XP/38x boards and to enable the > PCIe DT node in general for all boards (frankly I was too lazy to do these > DT changes for all those boards). But I agree that this approach is > cumbersome and I'll follow-up with a v2 patch moving this "okay" to the > board DT files. > You could do theodorable an leave the others for the board maintainers. Even the defconfig changes should be innocuous without the dts change. Anyways, it would be great if you (and others) could test the new > DM PCI driver on your board(s). > Yes I was planning to do that this weekend. > Thanks, > Stefan > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push
On 1/17/19 6:15 PM, Tom Rini wrote: > On Thu, Jan 17, 2019 at 05:50:27PM -0700, Stephen Warren wrote: >> On 1/17/19 5:42 PM, Tom Rini wrote: >>> On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote: >>> Tom, The recent set of patches pushed to u-boot/master cause DFU failures on both Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) with the following in the log: host: dfu-util -a 0 -U /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin -p 3-2.3 target: ** Reading file would overwrite reserved memory ** dfu: Read error! dfu_read: Failed to fill buffer Tegra124 (Jetson TK1) # I noticed some lmb fixes in the list, so I guess it's due to that. >>> >>> So.. intentional! Adding in Simon here, but I think the short answer is >>> that you need to change where you're saying the file goes in memory. >>> FWIW I run the DFU test on my dra7xx_evm and it's passing. >> >> You applied a change which intentionally broke functionality??? That sounds >> pretty bad... > > So, yes. A design decision / feature of "don't check where we're > loading payloads to" is also a security vulnerability to bypass secure > boot. So we now have changes in that make a good attempt at keeping us > from loading a payload that can in turn overwrite ourself. And I merged > it super early in the merge window to try and catch the unintended > consequences. > >> Looking at the precise test that failed, we don't actually specify where the >> data goes in memory; it's written to the filesystem and all memmory >> locations are internally allocated by U-Boot. So when you say "you need to >> change where you're saying the file goes in memory", do you mean via the DFU >> altinfo variable (which does not specify a memory location in this case, so >> I can't), or by modifying some board-/SoC-specific config file or code to >> specify where DFU buffers data (in which case, I'd argue that a >> backwards-compatible default should have been put in place to prevent >> breaking functionality)? >> >> The DFU altinfo values that are tested on both boards are: >> >> Fails: >> >> Device mmc 1 (which is an SD card): >> "alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1", "test_sizes": ( 64 - 1, 64, 64 + 1, 4096 - 1, ), }, >> All pass: >> >> Device mmc 1 (which is an SD card): >> "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1", "test_sizes": ( 128 - 1, 128, 128 + 1, 4096, ), >> Device mmc 1 (which is an SD card): >> "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1", "test_sizes": ( 960 - 1, 960, 960 + 1, 4096 + 1, ), >> Device ram >> "alt_info": "alt0 ram 8000 0100;alt1 ram 8100 0100", "test_sizes": ( 1024 * 1024 - 1, 1024 * 1024, 8 * 1024 * 1024, ), > So that's interesting. How big is dfu_test.bin? Checking my config, I > don't have SD card only RAM. If you do RAM only tests does it pass (as > that might narrow down where maybe something is wrong) ? Yes, that RAM-only test passes. The tests are run in the order listed above. test_dfu.py iterates over a bunch of different file sizes; I listed them below the DFU configs above. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Kconfig: Migrate CONFIG_BUILD_TARGET
On 17.01.19 18:56, Jagan Teki wrote: Migrate CONFIG_BUILD_TARGET into Kconfig. Signed-off-by: Jagan Teki --- Kconfig | 13 + README| 7 --- arch/arm/mach-mvebu/include/mach/config.h | 5 - configs/SBx81LIFKW_defconfig | 1 + configs/SBx81LIFXCAT_defconfig| 1 + configs/dreamplug_defconfig | 1 + configs/ds109_defconfig | 1 + configs/guruplug_defconfig| 1 + configs/ib62x0_defconfig | 1 + configs/nsa310s_defconfig | 1 + configs/sheevaplug_defconfig | 1 + include/configs/SBx81LIFKW.h | 1 - include/configs/SBx81LIFXCAT.h| 1 - include/configs/ib62x0.h | 3 --- include/configs/mv-plug-common.h | 3 --- include/configs/nsa310s.h | 3 --- include/configs/rcar-gen3-common.h| 1 - include/configs/socfpga_common.h | 3 --- include/configs/sunxi-common.h| 1 - scripts/config_whitelist.txt | 1 - 20 files changed, 21 insertions(+), 29 deletions(-) Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: mvebu: armada-xp/37x/38x: Enable PCIe DT node
Hi Chris, On 17.01.19 20:57, Chris Packham wrote: Hi Stefan, On Fri, Jan 18, 2019 at 2:35 AM Stefan Roese wrote: This patch enables the DT PCIe nodes for the Armada XP/37x/38x boards. This is needed for the new DM_PCI support in the MVEBU PCIe driver. Signed-off-by: Stefan Roese Cc: Dirk Eibach Cc: Mario Six Cc: Chris Packham Cc: Phil Sutter Cc: Marek Behún Cc: VlaoMao --- arch/arm/dts/armada-375.dtsi| 2 +- arch/arm/dts/armada-380.dtsi| 2 +- arch/arm/dts/armada-385.dtsi| 2 +- arch/arm/dts/armada-xp-mv78230.dtsi | 2 +- arch/arm/dts/armada-xp-mv78260.dtsi | 2 +- arch/arm/dts/armada-xp-mv78460.dtsi | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) I think this should be at the board level instead of the SoC. I agree (please see below). There are boards that don't use the pcie controller even though it's in the SoC. This use case is handled by enabling the PCI_MVEBU driver on a board per board case in U-Boot. But nevertheless I agree in general. Another good reason is that this deviates from the dtsi files in Linux https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-375.dtsi#n548 Yes, my first version did not change the dtsi file but the board dts file (theadorable in this case). My motivation was to not change anything in the configuration for these Armada XP/38x boards and to enable the PCIe DT node in general for all boards (frankly I was too lazy to do these DT changes for all those boards). But I agree that this approach is cumbersome and I'll follow-up with a v2 patch moving this "okay" to the board DT files. Anyways, it would be great if you (and others) could test the new DM PCI driver on your board(s). Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/11] clk: Add fixed-factor clock driver
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, January 17, 2019 11:51 PM
> To: Anup Patel ; Rick Chen ;
> Bin Meng ; Joe Hershberger
> ; Lukas Auer ;
> Masahiro Yamada ; Simon Glass
>
> Cc: Palmer Dabbelt ; Paul Walmsley
> ; Atish Patra ;
> Christoph Hellwig ; U-Boot Mailing List b...@lists.denx.de>
> Subject: Re: [PATCH 07/11] clk: Add fixed-factor clock driver
>
> On 01/17/2019 11:39 AM, Anup Patel wrote:
> > This patch adds fixed-factor clock driver which derives clock rate by
> > dividing (div) and multiplying (mult) fixed factors to a parent clock.
> >
> > Signed-off-by: Anup Patel
> > Signed-off-by: Atish Patra
> > ---
> > drivers/clk/Makefile | 4 +-
> > drivers/clk/clk_fixed_factor.c | 74
> ++
> > 2 files changed, 77 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/clk/clk_fixed_factor.c
> >
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
> > 2f4446568c..fa59259ea3 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -4,7 +4,9 @@
> > # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> > #
> >
> > -obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o clk_fixed_rate.o
> > +obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o
> > +obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o
> > +obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
> >
> > obj-y += imx/
> > obj-y += tegra/
> > diff --git a/drivers/clk/clk_fixed_factor.c
> > b/drivers/clk/clk_fixed_factor.c new file mode 100644 index
> > 00..eab1724c26
> > --- /dev/null
> > +++ b/drivers/clk/clk_fixed_factor.c
> > @@ -0,0 +1,74 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> > + *
> > + * Author: Anup Patel */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct clk_fixed_factor {
> > + struct clk parent;
> > + unsigned int div;
> > + unsigned int mult;
> > +};
> > +
> > +#define to_clk_fixed_factor(dev) \
> > + ((struct clk_fixed_factor *)dev_get_platdata(dev))
> > +
> > +static ulong clk_fixed_factor_get_rate(struct clk *clk) {
> > + int ret;
> > + struct clk_fixed_factor *ff = to_clk_fixed_factor(clk->dev);
> > +
> > + if (clk->id != 0)
> > + return -EINVAL;
> > +
> > + ret = clk_get_rate(>parent);
> > + if (IS_ERR_VALUE(ret))
> > + return ret;
> > +
> > + do_div(ret, ff->div);
> > +
> > + return ret * ff->mult;
> > +}
> > +
> > +const struct clk_ops clk_fixed_factor_ops = {
> > + .get_rate = clk_fixed_factor_get_rate, };
> > +
> > +static int clk_fixed_factor_ofdata_to_platdata(struct udevice *dev) {
> > +#if !CONFIG_IS_ENABLED(OF_PLATDATA)
>
> Why do you need this?
This is for boards/configuration where OF_PLATDATA is not enabled. For such
boards, the board support code will provide platdata.
I saw similar thing in clk_fixed_rate.c too hence kept it here. Do you want me
to drop this "#if"?
>
> Alex
>
> > + int err;
> > + struct clk_fixed_factor *ff = to_clk_fixed_factor(dev);
> > +
> > + err = clk_get_by_index(dev, 0, >parent);
> > + if (err)
> > + return err;
> > +
> > + ff->div = dev_read_u32_default(dev, "clock-div", 1);
> > + ff->mult = dev_read_u32_default(dev, "clock-mult", 1); #endif
> > +
> > + return 0;
> > +}
> > +
> > +static const struct udevice_id clk_fixed_factor_match[] = {
> > + {
> > + .compatible = "fixed-factor-clock",
> > + },
> > + { /* sentinel */ }
> > +};
> > +
> > +U_BOOT_DRIVER(clk_fixed_factor) = {
> > + .name = "fixed_factor_clock",
> > + .id = UCLASS_CLK,
> > + .of_match = clk_fixed_factor_match,
> > + .ofdata_to_platdata = clk_fixed_factor_ofdata_to_platdata,
> > + .platdata_auto_alloc_size = sizeof(struct clk_fixed_factor),
> > + .ops = _fixed_factor_ops,
> > +};
Regards,
Anup
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/11] net: macb: Fix clk API usage for RISC-V systems
> -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Thursday, January 17, 2019 11:37 PM > To: Anup Patel ; Rick Chen ; > Bin Meng ; Joe Hershberger > ; Lukas Auer ; > Masahiro Yamada ; Simon Glass > > Cc: Palmer Dabbelt ; Paul Walmsley > ; Atish Patra ; > Christoph Hellwig ; U-Boot Mailing List b...@lists.denx.de> > Subject: Re: [PATCH 04/11] net: macb: Fix clk API usage for RISC-V systems > > On 01/17/2019 11:38 AM, Anup Patel wrote: > > This patch does following fixes in MACB ethernet driver for using it > > on RISC-V systems (particularly QEMU sifive_u > > machine): > > 1. asm/arch/clk.h is not available on RISC-V port so include > > it only for non-RISC-V systems. > > 2. Don't fail in macb_enable_clk() if clk_enable() returns > > -ENOSYS because we get -ENOSYS for fixed-rate clocks. > > > > Signed-off-by: Anup Patel > > Reviewed-by: Bin Meng > > --- > > drivers/net/macb.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/macb.c b/drivers/net/macb.c index > > 94c89c762b..9a06b523cc 100644 > > --- a/drivers/net/macb.c > > +++ b/drivers/net/macb.c > > @@ -38,7 +38,9 @@ > > #include > > #include > > #include > > +#ifndef CONFIG_RISCV > > #include > > +#endif > > #include > > > > #include "macb.h" > > @@ -1066,7 +1068,7 @@ static int macb_enable_clk(struct udevice *dev) > > */ > > #ifndef CONFIG_MACB_ZYNQ > > ret = clk_enable(); > > If clk.h is not available, who exports clk_enable() then; and why is the > included needed in the first place? For some of the ARM boards, clk instances are provided directly by arch/arm/mach-xyz sources. For such boards, asm/arch/clk.h is required. I think these boards should move to DT based clk drivers. In all other cases, we use generic which provides clk instances using DT based clk drivers. Regards, Anup ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/11] SiFive FU540 Support
> -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Friday, January 18, 2019 4:39 AM > To: Anup Patel ; Rick Chen ; > Bin Meng ; Joe Hershberger > ; Lukas Auer ; > Masahiro Yamada ; Simon Glass > > Cc: Palmer Dabbelt ; Paul Walmsley > ; Atish Patra ; > Christoph Hellwig ; U-Boot Mailing List b...@lists.denx.de> > Subject: Re: [PATCH 00/11] SiFive FU540 Support > > > > On 17.01.19 11:38, Anup Patel wrote: > > This patchset adds SiFive Freedom Unleashed (FU540) support to RISC-V > > U-Boot. > > > > The patches are based upon latest RISC-V U-Boot tree > > (git://git.denx.de/u-boot-riscv.git) at commit id > > 91882c472d8c0aef4db699d3f2de55bf43d4ae4b > > > > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance MACB > > Ethernet work fine on actual SiFive Unleashed board and QEMU sifive_u > > machine. > > Great job, looks very clean to me! Thanks. > > Slight nitpick on the SoB lines though. Usually your SoB should always come > at the end if it went through your fingers last. > > I saw a few patches where Atish was either the sole person in SoB or is listed > after you in the SoB order. This is slightly incorrect, as you as the sender > of > the patch set should always occur at the end of the SoB list. Sure, I will fix ordering of SoB > > Thanks a lot for cooking up this patch set, I'm looking very much forward to a > world where running new kernels is easy on RISC-V :). Regards, Anup ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] drivers: ifc: restore the legacy flow for IFC config
> -Original Message- > From: York Sun > Sent: Friday, January 18, 2019 2:43 AM > To: Rajesh Bhagat ; u-boot@lists.denx.de > Cc: Prabhakar Kushwaha ; Pankit Garg > > Subject: Re: [PATCH 2/7] drivers: ifc: restore the legacy flow for IFC config > > On 12/26/18 8:37 PM, Rajesh Bhagat wrote: > > Restore the legacy flow along with TFABOOT flow for IFC configuration. > > What's the reason to go back to old flow? > Hi York, IFC configuration was made dynamic instead of static in previous patch in TF-A and non TF-A mode. Though dynamic configuration works fine for all the platforms in TF-A mode, it is broken for non TF-A mode on some of the platforms like ls1021atwr, ls1021aqds, ls1043ardb and ls1046aqds. This patch adds the static configuration back for non TF-A mode to support above platforms. Regards, Rajesh Bhagat > York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/11] riscv: Add SiFive FU540 board support
On 1/17/19 8:58 AM, Troy Benjegerdes wrote: So I take it I could use my version of U-boot to load BBL, then your S-mode U-boot? No need of your version of U-boot to load BBL. This patchset intend to follow the standard boot flow. ZSBL->FSBL->BBL/OpenSBI->U-boot->Linux. (From ROM)--(M Mode)(S Mode)-(S Mode) Couple of Methods to boot Linux: 1. Create a combined image of u-boot and Linux. Give that combined image as a payload to BBL/OpenSBI. U-boot prompt should appear. 2. Just provide U-boot image as a payload to BBL/OpenSBI. U-boot prompt should appear. Use TFTP to load Linux. bootm can be used to boot Linux afterwards. As of now, there is no SMP support in u-boot. So you may want to bringup one cpu and test non-smp configuration. Once we have SPI driver support in U-boot, we should be load images from MMC as well. I've been holding off on refactoring or submitting anything from the MicroSemi U-boot that runs in M-mode and inits the DRAM until I have some decent method to regression test the whole system (bootloader, kernel, userspace). I also want to make sure we don't break any other RiscV platforms when we add new code. I am hoping AndesTech guys will give a go at the patchset ;). It looks HiFive unleashed boards are available for purchase again, is there any place to get an AndesTech board? I am not aware of any AndesTech Dev boards. (fyi, the *proof of concept* hacks for regression testing that work for me based on MicroSemi patches are at https://github.com/tmagik/freedom-u-sdk/tree/regression/kernel4.15 ) cool. Regards, Atish On Thu, Jan 17, 2019 at 10:39:27AM +, Anup Patel wrote: This patch adds SiFive FU540 board support. For now, only SiFive serial, SiFive PRCI, and Cadance MACB drivers are only enabled. The SiFive FU540 defconfig by default builds U-Boot for S-Mode because U-Boot on SiFive FU540 will run in S-Mode as payload of BBL or OpenSBI. Signed-off-by: Anup Patel Signed-off-by: Atish Patra --- arch/riscv/Kconfig | 4 board/sifive/fu540/Kconfig | 42 + board/sifive/fu540/MAINTAINERS | 9 +++ board/sifive/fu540/Makefile| 5 board/sifive/fu540/fu540.c | 17 ++ configs/sifive_fu540_defconfig | 11 + include/configs/sifive-fu540.h | 43 ++ 7 files changed, 131 insertions(+) create mode 100644 board/sifive/fu540/Kconfig create mode 100644 board/sifive/fu540/MAINTAINERS create mode 100644 board/sifive/fu540/Makefile create mode 100644 board/sifive/fu540/fu540.c create mode 100644 configs/sifive_fu540_defconfig create mode 100644 include/configs/sifive-fu540.h diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 6879047ff7..36512a8995 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -14,11 +14,15 @@ config TARGET_AX25_AE350 config TARGET_QEMU_VIRT bool "Support QEMU Virt Board" +config TARGET_SIFIVE_FU540 + bool "Support SiFive FU540 Board" + endchoice # board-specific options below source "board/AndesTech/ax25-ae350/Kconfig" source "board/emulation/qemu-riscv/Kconfig" +source "board/sifive/fu540/Kconfig" # platform-specific options below source "arch/riscv/cpu/ax25/Kconfig" diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig new file mode 100644 index 00..6be3d88144 --- /dev/null +++ b/board/sifive/fu540/Kconfig @@ -0,0 +1,42 @@ +if TARGET_SIFIVE_FU540 + +config SYS_BOARD + default "fu540" + +config SYS_VENDOR + default "sifive" + +config SYS_CPU + default "generic" + +config SYS_CONFIG_NAME + default "sifive-fu540" + +config SYS_TEXT_BASE + default 0x8000 if !RISCV_SMODE + default 0x8020 if RISCV_SMODE + +config BOARD_SPECIFIC_OPTIONS # dummy + def_bool y + select GENERIC_RISCV + imply CMD_DHCP + imply CMD_EXT2 + imply CMD_EXT4 + imply CMD_FAT + imply CMD_FS_GENERIC + imply CMD_NET + imply CMD_PING + imply CLK_SIFIVE + imply CLK_SIFIVE_FU540_PRCI + imply DOS_PARTITION + imply EFI_PARTITION + imply IP_DYN + imply ISO_PARTITION + imply MACB + imply MII + imply NET_RANDOM_ETHADDR + imply PHY_LIB + imply PHY_MSCC + imply SIFIVE_SERIAL + +endif diff --git a/board/sifive/fu540/MAINTAINERS b/board/sifive/fu540/MAINTAINERS new file mode 100644 index 00..702d803ad8 --- /dev/null +++ b/board/sifive/fu540/MAINTAINERS @@ -0,0 +1,9 @@ +SiFive FU540 BOARD +M: Paul Walmsley +M: Palmer Dabbelt +M: Anup Patel +M: Atish Patra +S: Maintained +F: board/sifive/fu540/ +F: include/configs/sifive-fu540.h +F: configs/sifive_fu540_defconfig diff --git a/board/sifive/fu540/Makefile b/board/sifive/fu540/Makefile new file mode 100644 index 00..6e1862c475 --- /dev/null +++ b/board/sifive/fu540/Makefile @@ -0,0 +1,5 @@ +#
Re: [U-Boot] [PATCH] spl: fat/fs: Add control to build FS EXT4 in SPL
On Thu, 2019-01-17 at 07:23 -0500, Tom Rini wrote:
> On Thu, Jan 17, 2019 at 03:01:49PM +0800, tien.fong.c...@intel.com
> wrote:
>
> >
> > From: Tien Fong Chee
> >
> > CONFIG_SPL_EXT_SUPPORT can be used to include/exclude the FS EXT4
> > from
> > SPL build. Excluding the FS EXT4 from SPL build can help to save
> > 20KiB
> > memory.
> >
> > Signed-off-by: Tien Fong Chee
> > ---
> > fs/fs.c |4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/fs/fs.c b/fs/fs.c
> > index 0b8088b..252e2f5 100644
> > --- a/fs/fs.c
> > +++ b/fs/fs.c
> > @@ -184,7 +184,9 @@ static struct fstype_info fstypes[] = {
> > .closedir = fat_closedir,
> > },
> > #endif
> > -#ifdef CONFIG_FS_EXT4
> > +/* #ifdef CONFIG_FS_EXT4 */
> > +#if (!defined(CONFIG_SPL_BUILD) && defined(CONFIG_FS_EXT4)) || \
> > + (defined(CONFIG_SPL_BUILD) &&
> > defined(CONFIG_SPL_EXT_SUPPORT))
> > {
> > .fstype = FS_TYPE_EXT,
> > .name = "ext4",
> This should be CONFIG_IS_ENABLED(FS_EXT4) in a 2/2 patch with a 1/2
> patch renaming SPL_EXT_SUPPORT TO SPL_FS_EXT4, thanks!
Okay.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: fat/fs: Add option to include/exclude FAT write build in SPL
On Thu, 2019-01-17 at 07:25 -0500, Tom Rini wrote: > On Thu, Jan 17, 2019 at 08:54:48AM +0100, Simon Goldschmidt wrote: > > > > On Thu, Jan 17, 2019 at 8:10 AM wrote: > > > > > > > > > From: Tien Fong Chee > > > > > > Most of the time SPL only needs very simple FAT reading, so > > > having > > > CONFIG_SPL_FAT_WRITE to exclude or undefined would help to save > > > 64KiB > > > default max clustersize from memory. > > > > > > Signed-off-by: Tien Fong Chee > > > --- > > > common/spl/Kconfig |7 +++ > > > fs/fat/Makefile|7 ++- > > > fs/fat/fat.c |4 +++- > > > fs/fs.c|3 ++- > > > 4 files changed, 18 insertions(+), 3 deletions(-) > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > > index 0ddbffc..dad4c11 100644 > > > --- a/common/spl/Kconfig > > > +++ b/common/spl/Kconfig > > > @@ -403,6 +403,13 @@ config SPL_FAT_SUPPORT > > > filesystem from within SPL. Support for the underlying > > > block > > > device (e.g. MMC or USB) must be enabled separately. > > > > > > +config SPL_FAT_WRITE > > > + bool "Support write for FAT filesystems" > > > + help > > > + Enable write support for FAT and VFAT filesystems with > > > SPL. > > > + Support for the underlying block device (e.g. MMC or > > > USB) must be > > > + enabled separately. > > > + > > > config SPL_FPGA_SUPPORT > > > bool "Support FPGAs" > > > help > > > diff --git a/fs/fat/Makefile b/fs/fat/Makefile > > > index e64b61a..654b8c3 100644 > > > --- a/fs/fat/Makefile > > > +++ b/fs/fat/Makefile > > > @@ -1,5 +1,10 @@ > > > # SPDX-License-Identifier: GPL-2.0+ > > > # > > > > > > +ifdef CONFIG_SPL_BUILD > > > obj-$(CONFIG_FS_FAT) := fat.o > > > -obj-$(CONFIG_FAT_WRITE):= fat_write.o > > > +obj-$(CONFIG_SPL_FAT_WRITE) = fat_write.o > > > +else > > > +obj-$(CONFIG_FS_FAT) := fat.o > > > +obj-$(CONFIG_FAT_WRITE) = fat_write.o > Like the ext4 one, we need a patch to rename SPL_FAT_SUPPORT to > SPL_FS_FAT and then: > > obj-$(CONFIG_$(SPL_)FS_FAT) += fat.o > obj-$(CONFIG_$(SPL_)FAT_WRITE) += fat_write.o Okay. > > > > > > > > > +endif > > > diff --git a/fs/fat/fat.c b/fs/fat/fat.c > > > index ac8913e..8803fb4 100644 > > > --- a/fs/fat/fat.c > > > +++ b/fs/fat/fat.c > > > @@ -145,7 +145,9 @@ static void get_name(dir_entry *dirent, char > > > *s_name) > > > } > > > > > > static int flush_dirty_fat_buffer(fsdata *mydata); > > > -#if !defined(CONFIG_FAT_WRITE) > > > + > > > +#if (!defined(CONFIG_SPL_BUILD) && !defined(CONFIG_FAT_WRITE)) > > > || \ > > > + (defined(CONFIG_SPL_BUILD) && > > > !defined(CONFIG_SPL_FAT_WRITE)) > > What about 'CONFIG_IS_ENABLED(FAT_WRITE)' ? > Yes, CONFIG_IS_ENABLED(FAT_WRITE) please. Okay. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] arm: actions: Add common framework for Actions Semi SoCs
On Thu, Jan 17, 2019 at 09:16:26PM +, André Przywara wrote: > On Thu, 17 Jan 2019 21:09:45 +0530 > Manivannan Sadhasivam wrote: > > Hi, > > > [On top of Andre's review] > > > > On Mon, Jan 14, 2019 at 06:11:03PM +0530, Amit Singh Tomar wrote: > > > This adds common arch owl support that can drive, 64-bits SoCs > > > from Actions Semi. > > > > > > > Could be, "This commit adds common arch support for Actions Semi Owl > > series SoCs and removes the Bubblegum96 board files." > > > > > It also removes the Bubblegum specific board files. > > > > > > Signed-off-by: Amit Singh Tomar > > > --- > > > Changes since v1: > > > * Moved S700 specific changes to patch 4 of 9. > > > * Moved couple of symbols from defconfig to > > > arch/arm/Kconfig and platform owl Kconfig. > > > --- > > > arch/arm/Kconfig | 3 +- > > > arch/arm/mach-owl/Kconfig| 29 ++ > > > arch/arm/mach-owl/Makefile | 1 + > > > arch/arm/mach-owl/soc.c | 56 > > > > > > board/ucRobotics/bubblegum_96/Kconfig| 15 > > > board/ucRobotics/bubblegum_96/MAINTAINERS| 6 --- > > > board/ucRobotics/bubblegum_96/Makefile | 3 -- > > > board/ucRobotics/bubblegum_96/bubblegum_96.c | 56 > > > > > > configs/bubblegum_96_defconfig | 4 +- > > > include/configs/bubblegum_96.h | 42 > > > - include/configs/owl-common.h > > > | 42 + > > > include/configs/s900.h | 18 + 12 > > > files changed, 131 insertions(+), 144 deletions(-) create mode > > > 100644 arch/arm/mach-owl/soc.c delete mode 100644 > > > board/ucRobotics/bubblegum_96/Kconfig delete mode 100644 > > > board/ucRobotics/bubblegum_96/MAINTAINERS delete mode 100644 > > > board/ucRobotics/bubblegum_96/Makefile delete mode 100644 > > > board/ucRobotics/bubblegum_96/bubblegum_96.c delete mode 100644 > > > include/configs/bubblegum_96.h create mode 100644 > > > include/configs/owl-common.h create mode 100644 > > > include/configs/s900.h > > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > > index d6b1629..1a2e561 100644 > > > --- a/arch/arm/Kconfig > > > +++ b/arch/arm/Kconfig > > > @@ -761,9 +761,9 @@ config ARCH_MX5 > > > > > > config ARCH_OWL > > > bool "Actions Semi OWL SoCs" > > > - select ARM64 > > > select DM > > > select DM_SERIAL > > > + select OWL_SERIAL > > > select OF_CONTROL > > > imply CMD_DM > > > > > > @@ -1555,7 +1555,6 @@ source "board/spear/spear600/Kconfig" > > > source "board/spear/x600/Kconfig" > > > source "board/st/stv0991/Kconfig" > > > source "board/tcl/sl50/Kconfig" > > > -source "board/ucRobotics/bubblegum_96/Kconfig" > > > source "board/birdland/bav335x/Kconfig" > > > source "board/toradex/colibri_pxa270/Kconfig" > > > source "board/vscom/baltos/Kconfig" > > > diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig > > > index 199e772..5eb93c9 100644 > > > --- a/arch/arm/mach-owl/Kconfig > > > +++ b/arch/arm/mach-owl/Kconfig > > > @@ -1,27 +1,22 @@ > > > if ARCH_OWL > > > > > > -config SYS_SOC > > > - default "owl" > > > - > > > choice > > > -prompt "Actions Semi OWL SoCs board select" > > > +prompt "Actions Semi SoC Variant" > > > > We should explicitly say "Owl" series SoCs here. > > > > > optional > > > > > > -config TARGET_BUBBLEGUM_96 > > > - bool "96Boards Bubblegum-96" > > > - help > > > - Support for 96Boards Bubblegum-96. This board complies > > > with > > > - 96Board Consumer Edition Specification. Features: > > > - - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 > > > GPU) > > > - - 2GiB RAM > > > - - 8GiB eMMC, uSD slot > > > - - WiFi, Bluetooth and GPS module > > > - - 2x Host, 1x Device USB port > > > - - HDMI > > > - - 20-pin low speed and 40-pin high speed expanders, 6 > > > LED, 3 buttons +config MACH_S900 > > > +bool "Actionss Semi S900" > > > +select ARM64 > > > > > > endchoice > > > > > > -source "board/ucRobotics/bubblegum_96/Kconfig" > > > +config SYS_CONFIG_NAME > > > +default "s900" if MACH_S900 > > > + > > > +config SYS_SOC > > > +default "s900" if MACH_S900 > > > + > > > +config SYS_TEXT_BASE > > > +default 0x1100 > > > > > > > Move the above config symbols before MACH_S900. > > > > > endif > > > diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile > > > index 1b43dc2..0b181c6 100644 > > > --- a/arch/arm/mach-owl/Makefile > > > +++ b/arch/arm/mach-owl/Makefile > > > @@ -1,3 +1,4 @@ > > > # SPDX-License-Identifier: GPL-2.0+ > > > > > > +obj-y += soc.o > > > obj-y += sysmap-s900.o > > > diff --git a/arch/arm/mach-owl/soc.c b/arch/arm/mach-owl/soc.c > > > new file mode 100644 > > > index 000..d0630d2 > > > --- /dev/null > > > +++ b/arch/arm/mach-owl/soc.c > > > @@ -0,0 +1,56
Re: [U-Boot] [PATCH 1/3] poplar: sync up device tree with kernel 4.20
Hi Shawn, On Fri, Jan 18, 2019 at 08:57:03AM +0800, Shawn Guo wrote: > Hi Manivannan, > > On Thu, Jan 17, 2019 at 08:23:08PM +0530, Manivannan Sadhasivam wrote: > > Hi Shawn, > > > > On Thu, Jan 17, 2019 at 12:09:50PM +0800, Shawn Guo wrote: > > > It adds missing pinctrl headers, updates clock header and sync up Poplar > > > device tree with kernel 4.20 release. > > > > > > Signed-off-by: Shawn Guo > > > --- > > > arch/arm/dts/hi3798cv200-poplar.dts | 68 ++-- > > > arch/arm/dts/hi3798cv200.dtsi | 221 +++- > > > arch/arm/dts/poplar-pinctrl.dtsi| 98 +++ > > > include/dt-bindings/clock/histb-clock.h | 56 +++--- > > > include/dt-bindings/pinctrl/hisi.h | 74 > > > 5 files changed, 482 insertions(+), 35 deletions(-) > > > create mode 100644 arch/arm/dts/poplar-pinctrl.dtsi > > > create mode 100644 include/dt-bindings/pinctrl/hisi.h > > > > > > diff --git a/arch/arm/dts/hi3798cv200-poplar.dts > > > b/arch/arm/dts/hi3798cv200-poplar.dts > > > index 964326eae89b..d30f6eb8a5ee 100644 > > > --- a/arch/arm/dts/hi3798cv200-poplar.dts > > > +++ b/arch/arm/dts/hi3798cv200-poplar.dts > > > @@ -1,14 +1,17 @@ > > > -// SPDX-License-Identifier: GPL-2.0 > > > /* > > > * DTS File for HiSilicon Poplar Development Board > > > * > > > * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd. > > > + * > > > + * Released under the GPLv2 only. > > > + * SPDX-License-Identifier: GPL-2.0 > > > > This is a malformed license identifier. Eventhough it is being imported > > from Linux kernel, we need to fix this (on both). > > Yes, I'm aware of it. But the approach I would rather take is that we > only practically maintain u-boot specific changes with > hi3798cv200-u-boot.dtsi, and for changes maintained in kernel, we should > push to kernel and sync them down to u-boot. > > I just sent a patch [1] to fix this in kernel, and next time we sync > from kernel, everything should be fine then. > Sounds good! Thanks, Mani > Shawn > > [1] https://patchwork.kernel.org/patch/10769237/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push
On Thu, Jan 17, 2019 at 05:50:27PM -0700, Stephen Warren wrote: > On 1/17/19 5:42 PM, Tom Rini wrote: > >On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote: > > > >>Tom, > >> > >>The recent set of patches pushed to u-boot/master cause DFU failures on both > >>Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) with > >>the following in the log: > >> > >>host: > >>dfu-util -a 0 -U > >>/var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin > >>-p 3-2.3 > >> > >>target: > >>** Reading file would overwrite reserved memory ** > >>dfu: Read error! > >>dfu_read: Failed to fill buffer > >>Tegra124 (Jetson TK1) # > >> > >>I noticed some lmb fixes in the list, so I guess it's due to that. > > > >So.. intentional! Adding in Simon here, but I think the short answer is > >that you need to change where you're saying the file goes in memory. > >FWIW I run the DFU test on my dra7xx_evm and it's passing. > > You applied a change which intentionally broke functionality??? That sounds > pretty bad... So, yes. A design decision / feature of "don't check where we're loading payloads to" is also a security vulnerability to bypass secure boot. So we now have changes in that make a good attempt at keeping us from loading a payload that can in turn overwrite ourself. And I merged it super early in the merge window to try and catch the unintended consequences. > Looking at the precise test that failed, we don't actually specify where the > data goes in memory; it's written to the filesystem and all memmory > locations are internally allocated by U-Boot. So when you say "you need to > change where you're saying the file goes in memory", do you mean via the DFU > altinfo variable (which does not specify a memory location in this case, so > I can't), or by modifying some board-/SoC-specific config file or code to > specify where DFU buffers data (in which case, I'd argue that a > backwards-compatible default should have been put in place to prevent > breaking functionality)? > > The DFU altinfo values that are tested on both boards are: > > Fails: > > Device mmc 1 (which is an SD card): > "alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1", > > All pass: > > Device mmc 1 (which is an SD card): > "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1", > > Device mmc 1 (which is an SD card): > "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1", > > Device ram > "alt_info": "alt0 ram 8000 0100;alt1 ram 8100 0100", So that's interesting. How big is dfu_test.bin? Checking my config, I don't have SD card only RAM. If you do RAM only tests does it pass (as that might narrow down where maybe something is wrong) ? -- 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 2/2] Kconfig: Add u-boot.itb BUILD_TARGET for RK3368/3399
Hi Jagan, This is the patch I'm looking for, I try to enable u-boot.itb build but I failed with modify the legacy Makefile, thanks. On 01/18/2019 01:57 AM, Jagan Teki wrote: > Add u-boot.itb BUILD_TARGET for Rockchip RK3368 and RK3399 > SoC, this can get rid of building itb explicitly with > 'make u-boot.itb' all required images will now build just > by make. > > Signed-off-by: Jagan Teki > --- > Kconfig| 1 + > board/rockchip/evb_rk3399/README | 1 - > board/theobroma-systems/lion_rk3368/README | 9 ++--- > board/theobroma-systems/puma_rk3399/README | 1 - > board/vamrs/rock960_rk3399/README | 1 - > 5 files changed, 3 insertions(+), 10 deletions(-) > > diff --git a/Kconfig b/Kconfig > index 3a3a8d4d5b..247ace3ce0 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -230,6 +230,7 @@ config BUILD_TARGET > default "u-boot-spl.kwb" if ARCH_MVEBU && SPL_BUILD > default "u-boot-elf.srec" if RCAR_GEN3 > default "u-boot.itb" if ARCH_SUNXI && ARM64 > + default "u-boot.itb" if ROCKCHIP_RK3368 || ROCKCHIP_RK3399 Can we use ARCH_ROCKCHIP && CONFIG_SPL_LOAD_FIT instead, so that we don't limit to these two SoCs, eg. rk3229 also need u-boot.itb while it's loads OP-TEE instead of ATF. Thanks, - Kever > help > Some SoCs need special image types (e.g. U-Boot binary > with a special header) as build targets. By defining > diff --git a/board/rockchip/evb_rk3399/README > b/board/rockchip/evb_rk3399/README > index 8321467046..c388f269c1 100644 > --- a/board/rockchip/evb_rk3399/README > +++ b/board/rockchip/evb_rk3399/README > @@ -58,7 +58,6 @@ Compile the U-Boot >for firefly-rk3399, use below instead: >> make firefly-rk3399_defconfig >> make > - > make u-boot.itb > >Get spl/u-boot-spl.bin and u-boot.itb in this step. > > diff --git a/board/theobroma-systems/lion_rk3368/README > b/board/theobroma-systems/lion_rk3368/README > index 83e4332984..241d4d9ec8 100644 > --- a/board/theobroma-systems/lion_rk3368/README > +++ b/board/theobroma-systems/lion_rk3368/README > @@ -14,18 +14,13 @@ Configure U-Boot >> cd ../u-boot >> make lion-rk3368_defconfig > > -Build the TPL/SPL stage > -=== > +Build the TPL/SPL, U-Boot proper and a FIT image including the ATF > +== > >> make CROSS_COMPILE=aarch64-unknown-elf- ARCH=arm >> tools/mkimage -n rk3368 -T rksd -d tpl/u-boot-tpl.bin spl-3368.img >> cat spl/u-boot-spl-dtb.bin >> spl-3368.img > > -Build the full U-Boot and a FIT image including the ATF > -=== > - > - > make CROSS_COMPILE=aarch64-unknown-elf- ARCH=arm u-boot.itb > - > Flash the image > === > > diff --git a/board/theobroma-systems/puma_rk3399/README > b/board/theobroma-systems/puma_rk3399/README > index f67dfb451f..c06c9650b8 100644 > --- a/board/theobroma-systems/puma_rk3399/README > +++ b/board/theobroma-systems/puma_rk3399/README > @@ -60,7 +60,6 @@ Creating a SPL image for SD-Card/eMMC > 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 > === > diff --git a/board/vamrs/rock960_rk3399/README > b/board/vamrs/rock960_rk3399/README > index d14399090e..c5c675c4ea 100644 > --- a/board/vamrs/rock960_rk3399/README > +++ b/board/vamrs/rock960_rk3399/README > @@ -61,7 +61,6 @@ Compile the U-Boot >> export CROSS_COMPILE=aarch64-linux-gnu- >> make rock960-rk3399_defconfig >> make > - > make u-boot.itb > > Compile the rkdeveloptool > = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/1] arm64: dt: poplar: add optee node
Hi Igor,
On Thu, Jan 17, 2019 at 04:37:40PM +0200, Igor Opaniuk wrote:
> As Poplar supports running TF-A with OP-TEE as BL32
> payload, add op-tee node in DT, which enables usage of
> OP-TEE driver (which provides an interface for requesting services
> from OP-TEE).
>
> Signed-off-by: Igor Opaniuk
I'm fine with the change. But rather than pushing changes to u-boot,
can you please push it to kernel repository, which is the DTS upstream
right now? We sync DTS changes from kernel when needed, and only
maintains u-boot specific changes in hi3798cv200-u-boot.dtsi.
Shawn
> ---
> arch/arm/dts/hi3798cv200-poplar.dts | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/dts/hi3798cv200-poplar.dts
> b/arch/arm/dts/hi3798cv200-poplar.dts
> index 964326e..6bc2a23 100644
> --- a/arch/arm/dts/hi3798cv200-poplar.dts
> +++ b/arch/arm/dts/hi3798cv200-poplar.dts
> @@ -28,6 +28,13 @@
> reg = <0x0 0x0 0x0 0x8000>;
> };
>
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> + };
> +
> leds {
> compatible = "gpio-leds";
>
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] poplar: sync up device tree with kernel 4.20
Hi Manivannan, On Thu, Jan 17, 2019 at 08:23:08PM +0530, Manivannan Sadhasivam wrote: > Hi Shawn, > > On Thu, Jan 17, 2019 at 12:09:50PM +0800, Shawn Guo wrote: > > It adds missing pinctrl headers, updates clock header and sync up Poplar > > device tree with kernel 4.20 release. > > > > Signed-off-by: Shawn Guo > > --- > > arch/arm/dts/hi3798cv200-poplar.dts | 68 ++-- > > arch/arm/dts/hi3798cv200.dtsi | 221 +++- > > arch/arm/dts/poplar-pinctrl.dtsi| 98 +++ > > include/dt-bindings/clock/histb-clock.h | 56 +++--- > > include/dt-bindings/pinctrl/hisi.h | 74 > > 5 files changed, 482 insertions(+), 35 deletions(-) > > create mode 100644 arch/arm/dts/poplar-pinctrl.dtsi > > create mode 100644 include/dt-bindings/pinctrl/hisi.h > > > > diff --git a/arch/arm/dts/hi3798cv200-poplar.dts > > b/arch/arm/dts/hi3798cv200-poplar.dts > > index 964326eae89b..d30f6eb8a5ee 100644 > > --- a/arch/arm/dts/hi3798cv200-poplar.dts > > +++ b/arch/arm/dts/hi3798cv200-poplar.dts > > @@ -1,14 +1,17 @@ > > -// SPDX-License-Identifier: GPL-2.0 > > /* > > * DTS File for HiSilicon Poplar Development Board > > * > > * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd. > > + * > > + * Released under the GPLv2 only. > > + * SPDX-License-Identifier: GPL-2.0 > > This is a malformed license identifier. Eventhough it is being imported > from Linux kernel, we need to fix this (on both). Yes, I'm aware of it. But the approach I would rather take is that we only practically maintain u-boot specific changes with hi3798cv200-u-boot.dtsi, and for changes maintained in kernel, we should push to kernel and sync them down to u-boot. I just sent a patch [1] to fix this in kernel, and next time we sync from kernel, everything should be fine then. Shawn [1] https://patchwork.kernel.org/patch/10769237/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push
On 1/17/19 5:42 PM, Tom Rini wrote: On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote: Tom, The recent set of patches pushed to u-boot/master cause DFU failures on both Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) with the following in the log: host: dfu-util -a 0 -U /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin -p 3-2.3 target: ** Reading file would overwrite reserved memory ** dfu: Read error! dfu_read: Failed to fill buffer Tegra124 (Jetson TK1) # I noticed some lmb fixes in the list, so I guess it's due to that. So.. intentional! Adding in Simon here, but I think the short answer is that you need to change where you're saying the file goes in memory. FWIW I run the DFU test on my dra7xx_evm and it's passing. You applied a change which intentionally broke functionality??? That sounds pretty bad... Looking at the precise test that failed, we don't actually specify where the data goes in memory; it's written to the filesystem and all memmory locations are internally allocated by U-Boot. So when you say "you need to change where you're saying the file goes in memory", do you mean via the DFU altinfo variable (which does not specify a memory location in this case, so I can't), or by modifying some board-/SoC-specific config file or code to specify where DFU buffers data (in which case, I'd argue that a backwards-compatible default should have been put in place to prevent breaking functionality)? The DFU altinfo values that are tested on both boards are: Fails: Device mmc 1 (which is an SD card): "alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1", All pass: Device mmc 1 (which is an SD card): "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1", Device mmc 1 (which is an SD card): "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1", Device ram "alt_info": "alt0 ram 8000 0100;alt1 ram 8100 0100", ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push
On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote: > Tom, > > The recent set of patches pushed to u-boot/master cause DFU failures on both > Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) with > the following in the log: > > host: > dfu-util -a 0 -U > /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin > -p 3-2.3 > > target: > ** Reading file would overwrite reserved memory ** > dfu: Read error! > dfu_read: Failed to fill buffer > Tegra124 (Jetson TK1) # > > I noticed some lmb fixes in the list, so I guess it's due to that. So.. intentional! Adding in Simon here, but I think the short answer is that you need to change where you're saying the file goes in memory. FWIW I run the DFU test on my dra7xx_evm and it's passing. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push
Tom, The recent set of patches pushed to u-boot/master cause DFU failures on both Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) with the following in the log: host: dfu-util -a 0 -U /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin -p 3-2.3 target: ** Reading file would overwrite reserved memory ** dfu: Read error! dfu_read: Failed to fill buffer Tegra124 (Jetson TK1) # I noticed some lmb fixes in the list, so I guess it's due to that. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/11] SiFive FU540 Support
On 17.01.19 11:38, Anup Patel wrote: > This patchset adds SiFive Freedom Unleashed (FU540) support > to RISC-V U-Boot. > > The patches are based upon latest RISC-V U-Boot tree > (git://git.denx.de/u-boot-riscv.git) at commit id > 91882c472d8c0aef4db699d3f2de55bf43d4ae4b > > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance > MACB Ethernet work fine on actual SiFive Unleashed board and > QEMU sifive_u machine. Great job, looks very clean to me! Slight nitpick on the SoB lines though. Usually your SoB should always come at the end if it went through your fingers last. I saw a few patches where Atish was either the sole person in SoB or is listed after you in the SoB order. This is slightly incorrect, as you as the sender of the patch set should always occur at the end of the SoB list. Thanks a lot for cooking up this patch set, I'm looking very much forward to a world where running new kernels is easy on RISC-V :). Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/11] riscv: Add SiFive FU540 board support
On 17.01.19 11:39, Anup Patel wrote: > This patch adds SiFive FU540 board support. For now, only > SiFive serial, SiFive PRCI, and Cadance MACB drivers are > only enabled. The SiFive FU540 defconfig by default builds > U-Boot for S-Mode because U-Boot on SiFive FU540 will run > in S-Mode as payload of BBL or OpenSBI. > > Signed-off-by: Anup Patel > Signed-off-by: Atish Patra Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 05/10] lib: lmb: extend lmb for checks at load time
On Mon, Jan 14, 2019 at 10:38:18PM +0100, Simon Goldschmidt wrote: > This adds two new functions, lmb_alloc_addr and > lmb_get_unreserved_size. > > lmb_alloc_addr behaves like lmb_alloc, but it tries to allocate a > pre-specified address range. Unlike lmb_reserve, this address range > must be inside one of the memory ranges that has been set up with > lmb_add. > > lmb_get_unreserved_size returns the number of bytes that can be > used up to the next reserved region or the end of valid ram. This > can be 0 if the address passed is reserved. > > Added test for these new functions. > > Signed-off-by: Simon Goldschmidt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 04/10] fdt: parse "reserved-memory" for memory reservation
On Mon, Jan 14, 2019 at 10:38:17PM +0100, Simon Goldschmidt wrote: > boot_fdt_add_mem_rsv_regions() adds reserved memory sections to an lmb > struct. Currently, it only parses regions described by /memreserve/ > entries. > > Extend this to the more commonly used scheme of the "reserved-memory" > node. > > Signed-off-by: Simon Goldschmidt > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 06/10] fs: prevent overwriting reserved memory
On Mon, Jan 14, 2019 at 10:38:19PM +0100, Simon Goldschmidt wrote:
> This fixes CVE-2018-18440 ("insufficient boundary checks in filesystem
> image load") by using lmb to check the load size of a file against
> reserved memory addresses.
>
> Signed-off-by: Simon Goldschmidt
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 02/10] lmb: fix allocation at end of address range
On Mon, Jan 14, 2019 at 10:38:15PM +0100, Simon Goldschmidt wrote: > The lmb code fails if base + size of RAM overflows to zero. > > Fix this by calculating end as 'base + size - 1' instead of 'base + size' > where appropriate. > > Added tests to assert this is fixed. > > Signed-off-by: Simon Goldschmidt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 09/10] tftp: prevent overwriting reserved memory
On Mon, Jan 14, 2019 at 10:38:22PM +0100, Simon Goldschmidt wrote:
> This fixes CVE-2018-18439 ("insufficient boundary checks in network
> image boot") by using lmb to check for a valid range to store
> received blocks.
>
> Signed-off-by: Simon Goldschmidt
> Acked-by: Joe Hershberger
With some lib/Makefile tweaks for the odd SPL+network use cases:
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 08/10] lmb: remove unused extern declaration
On Mon, Jan 14, 2019 at 10:38:21PM +0100, Simon Goldschmidt wrote: > lmb.h includes an extern declaration of "struct lmb lmb;" which > is not used anywhere, so remove it. > > Signed-off-by: Simon Goldschmidt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 10/10] arm: bootm: fix sp detection at end of address range
On Mon, Jan 14, 2019 at 10:38:23PM +0100, Simon Goldschmidt wrote:
> This fixes 'arch_lmb_reserve()' for ARM that tries to detect in which
> DRAM bank 'sp' is in.
>
> This code failed if a bank was at the end of physical address range
> (i.e. size + length overflowed to 0).
>
> To fix this, calculate 'bank_end' as 'size + length - 1' so that such
> banks end at 0x, not 0.
>
> Fixes: 15751403b6 ("ARM: bootm: don't assume sp is in DRAM bank 0")
> Reported-by: Frank Wunderlich
> Signed-off-by: Simon Goldschmidt
> Reviewed-by: Stephen Warren
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 07/10] bootm: use new common function lmb_init_and_reserve
On Mon, Jan 14, 2019 at 10:38:20PM +0100, Simon Goldschmidt wrote: > This reduces duplicate code only. > > Signed-off-by: Simon Goldschmidt > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 03/10] lib: lmb: reserving overlapping regions should fail
On Mon, Jan 14, 2019 at 10:38:16PM +0100, Simon Goldschmidt wrote: > lmb_add_region handles overlapping regions wrong: instead of merging > or rejecting to add a new reserved region that overlaps an existing > one, it just adds the new region. > > Since internally the same function is used for lmb_alloc, change > lmb_add_region to reject overlapping regions. > > Also, to keep reserved memory correct after 'free', reserved entries > created by allocating memory must not set their size to a multiple > of alignment but to the original size. This ensures the reserved > region is completely removed when the caller calls 'lmb_free', as > this one takes the same size as passed to 'lmb_alloc' etc. > > Add test to assert this. > > Signed-off-by: Simon Goldschmidt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v10,01/10] test: add test for lib/lmb.c
On Mon, Jan 14, 2019 at 10:38:14PM +0100, Simon Goldschmidt wrote: > Add basic tests for the lmb memory allocation code used to reserve and > allocate memory during boot. > > Signed-off-by: Simon Goldschmidt > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] env: add spi_flash_read_env function
On Tue, Dec 11, 2018 at 10:13:56AM +0100, Horatiu Vultur wrote: > The spi_flash_read_env function is a wrapper over spi_flash_read, which > enables the env to read multiple flash page size from flash until '\0\0' > is read or the end of env partition is reached. Instead of reading the > entire env size. When it reads '\0\0', it stops reading further the env > and assumes that the rest of env is '\0'. > > This is an optimization for large environments that contain few bytes > environment variables. In this case it doesn't need to read the entire > environment and only few pages. > > Signed-off-by: Horatiu Vultur Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1] mtd: nand: raw: allow to disable unneeded ECC layouts
On Thu, Dec 06, 2018 at 02:57:09PM +0100, Stefan Agner wrote: > From: Stefan Agner > > Each ECC layout consumes about 2984 bytes in the .data section. Allow > to disable the default ECC layouts if a driver is known to provide its > own ECC layout. > > Signed-off-by: Stefan Agner > Reviewed-by: Lukasz Majewski > Reviewed-by: Miquel Raynal 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] dts: am335x-pdu001: Fix polarity of card detection input
On Thu, Jan 17, 2019 at 12:20:32PM +0100, Felix Brack wrote:
> Hi Tom,
>
> On 29.11.2018 21:27, Tom Rini wrote:
> > On Thu, Nov 29, 2018 at 05:07:47PM +0100, Felix Brack wrote:
> >> On 29.11.2018 16:52, Tom Rini wrote:
> >>> On Thu, Nov 29, 2018 at 04:33:36PM +0100, Felix Brack wrote:
> On 29.11.2018 16:25, Tom Rini wrote:
> > On Thu, Nov 29, 2018 at 01:45:06PM +0100, Felix Brack wrote:
> >
> >> When a micro SD card is inserted in the PDU001 card cage, the card
> >> detection switch is opened and the corresponding GPIO input is driven
> >> by a pull-up. Hence change the active level of the card detection
> >> input from low to high.
> >>
> >> Signed-off-by: Felix Brack
> >> ---
> >>
> >> arch/arm/dts/am335x-pdu001.dts | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/dts/am335x-pdu001.dts
> >> b/arch/arm/dts/am335x-pdu001.dts
> >> index 121e2c6207..3a5e952663 100644
> >> --- a/arch/arm/dts/am335x-pdu001.dts
> >> +++ b/arch/arm/dts/am335x-pdu001.dts
> >> @@ -576,7 +576,7 @@
> >>bus-width = <4>;
> >>pinctrl-names = "default";
> >>pinctrl-0 = <_pins>;
> >> - cd-gpios = < 2 GPIO_ACTIVE_LOW>;
> >> + cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
> >> };
> >>
> >> {
> >
> > Is this in upstream Linux as well? If so what tag/hash? Thanks!
> >
> Not yet. I will send the Linux patch within a few days.
> The fix appears for U-Boot first as it is required for the upcoming
> patch that enables CONFIG_BLK and CONFIG_DM_MMC for this board.
> >>>
> >>> Please reply to the thread with a ML link there so we can track and make
> >>> sure it doesn't get out of sync, thanks!
> >>> I'm not sure if I got that correctly. What is an 'ML link'?
> >> Was there something wrong with my last post or would you like me to post
> >> a message in this thread once the patch is in upstream Linux?
> >
> > The general preference is that when we touch the dts files that aren't
> > U-Boot centric the commit message references the Linux githash/tag it's
> > taken from, for easier future re-syncs. Since you're in progress on
> > fixing this in Linux too, you can just reply here so it's at least
> > tracked on the ML and archives that the change _is_ going upstream so we
> > aren't likely to overwrite it by accident later (and since you'd be the
> > one pushing a future re-sync, you'd also notice, so it's really not
> > likely to happen). Thanks!
> >
>
> FYI: with patch https://patchwork.ozlabs.org/patch/1026522/ DTS for this
> board is now in identical in U-Boot and Linux.
Thanks for the follow-up!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] USB: musb-new: omap2430: Prep driver for Peripheral support.
On Mon, Dec 17, 2018 at 2:35 PM Adam Ford wrote:
>
> The omap2430 driver only currently supports host only. In
> preparation for supporting peripheral mode, this patch makes
> the driver support only the host by creating a ofdata_to_platdata
> function host/peripheral agnostic with a host helper version.
>
> Signed-off-by: Adam Ford
>
With the merge window and the pending DM_USB requirements, is there
anything I need to do differently to this series, or it is ok as-is?
adam
> diff --git a/drivers/usb/musb-new/omap2430.c b/drivers/usb/musb-new/omap2430.c
> index 32743aa72c..b6e1320538 100644
> --- a/drivers/usb/musb-new/omap2430.c
> +++ b/drivers/usb/musb-new/omap2430.c
> @@ -137,6 +137,12 @@ const struct musb_platform_ops omap2430_ops = {
>
> #if CONFIG_IS_ENABLED(DM_USB)
>
> +static const struct udevice_id omap2430_musb_ids[] = {
> + { .compatible = "ti,omap3-musb" },
> + { .compatible = "ti,omap4-musb" },
> + { }
> +};
> +
> struct omap2430_musb_platdata {
> void *base;
> void *ctrl_mod_base;
> @@ -190,20 +196,6 @@ static int omap2430_musb_ofdata_to_platdata(struct
> udevice *dev)
> return -ENOENT;
> }
>
> -#if 0 /* In a perfect world, mode would be set to OTG, mode 3 from DT */
> - platdata->plat.mode = fdtdec_get_int(fdt, node,
> -
> "mode", -1);
> - if (platdata->plat.mode < 0) {
> - pr_err("MUSB mode DT entry missing\n");
> - return -ENOENT;
> - }
> -#else /* MUSB_OTG, it doesn't work */
> -#ifdef CONFIG_USB_MUSB_HOST /* Host seems to be the only option that works */
> - platdata->plat.mode = MUSB_HOST;
> -#else /* For that matter, MUSB_PERIPHERAL doesn't either */
> - platdata->plat.mode = MUSB_PERIPHERAL;
> -#endif
> -#endif
> platdata->otg_board_data.dev = dev;
> platdata->plat.config = >musb_config;
> platdata->plat.platform_ops = _ops;
> @@ -211,11 +203,10 @@ static int omap2430_musb_ofdata_to_platdata(struct
> udevice *dev)
> return 0;
> }
>
> +#ifdef CONFIG_USB_MUSB_HOST
> static int omap2430_musb_probe(struct udevice *dev)
> {
> -#ifdef CONFIG_USB_MUSB_HOST
> struct musb_host_data *host = dev_get_priv(dev);
> -#endif
> struct omap2430_musb_platdata *platdata = dev_get_platdata(dev);
> struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
> struct omap_musb_board_data *otg_board_data;
> @@ -226,7 +217,6 @@ static int omap2430_musb_probe(struct udevice *dev)
>
> otg_board_data = >otg_board_data;
>
> -#ifdef CONFIG_USB_MUSB_HOST
> host->host = musb_init_controller(>plat,
> (struct device *)otg_board_data,
> platdata->base);
> @@ -235,11 +225,7 @@ static int omap2430_musb_probe(struct udevice *dev)
> }
>
> ret = musb_lowlevel_init(host);
> -#else
> - ret = musb_register(>plat,
> - (struct device *)otg_board_data,
> - platdata->base);
> -#endif
> +
> return ret;
> }
>
> @@ -252,28 +238,40 @@ static int omap2430_musb_remove(struct udevice *dev)
> return 0;
> }
>
> -static const struct udevice_id omap2430_musb_ids[] = {
> - { .compatible = "ti,omap3-musb" },
> - { .compatible = "ti,omap4-musb" },
> - { }
> -};
> +#if CONFIG_IS_ENABLED(OF_CONTROL)
> +static int omap2430_musb_host_ofdata_to_platdata(struct udevice *dev)
> +{
> + struct ti_musb_platdata *platdata = dev_get_platdata(dev);
> + const void *fdt = gd->fdt_blob;
> + int node = dev_of_offset(dev);
> + int ret;
> +
> + ret = omap2430_musb_ofdata_to_platdata(dev);
> + if (ret) {
> + pr_err("platdata dt parse error\n");
> + return ret;
> + }
> +
> + platdata->plat.mode = MUSB_HOST;
> +
> + return 0;
> +}
> +#endif
>
> U_BOOT_DRIVER(omap2430_musb) = {
> .name = "omap2430-musb",
> -#ifdef CONFIG_USB_MUSB_HOST
> .id = UCLASS_USB,
> -#else
> - .id = UCLASS_USB_GADGET_GENERIC,
> -#endif
> .of_match = omap2430_musb_ids,
> - .ofdata_to_platdata = omap2430_musb_ofdata_to_platdata,
> +#if CONFIG_IS_ENABLED(OF_CONTROL)
> + .ofdata_to_platdata = omap2430_musb_host_ofdata_to_platdata,
> +#endif
> .probe = omap2430_musb_probe,
> .remove = omap2430_musb_remove,
> -#ifdef CONFIG_USB_MUSB_HOST
> .ops = _usb_ops,
> -#endif
> .platdata_auto_alloc_size = sizeof(struct omap2430_musb_platdata),
> .priv_auto_alloc_size = sizeof(struct musb_host_data),
> };
>
> +#endif
> +
> #endif /* CONFIG_IS_ENABLED(DM_USB) */
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: mvebu: armada-xp/37x/38x: Enable PCIe DT node
On Fri, Jan 18, 2019 at 08:57:43AM +1300, Chris Packham wrote: > Hi Stefan, > > On Fri, Jan 18, 2019 at 2:35 AM Stefan Roese wrote: > > > > This patch enables the DT PCIe nodes for the Armada XP/37x/38x boards. > > This is needed for the new DM_PCI support in the MVEBU PCIe driver. > > > > Signed-off-by: Stefan Roese > > Cc: Dirk Eibach > > Cc: Mario Six > > Cc: Chris Packham > > Cc: Phil Sutter > > Cc: Marek Behún > > Cc: VlaoMao > > --- > > arch/arm/dts/armada-375.dtsi| 2 +- > > arch/arm/dts/armada-380.dtsi| 2 +- > > arch/arm/dts/armada-385.dtsi| 2 +- > > arch/arm/dts/armada-xp-mv78230.dtsi | 2 +- > > arch/arm/dts/armada-xp-mv78260.dtsi | 2 +- > > arch/arm/dts/armada-xp-mv78460.dtsi | 2 +- > > 6 files changed, 6 insertions(+), 6 deletions(-) > > I think this should be at the board level instead of the SoC. There > are boards that don't use the pcie controller even though it's in the > SoC. Another good reason is that this deviates from the dtsi files in > Linux > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-375.dtsi#n548 Yes, we should keep these files in-sync with Linux and use -u-boot.dtsi files (see scripts/Makefile.lib for the search logic) to change / add properties as needed. -- 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] no DTB with nand SPL on sama5d3
Follow up question: I notice that u-boot-spl-pad.bin is empty even though CONFIG_SPL_PAD_TO = CONFIG_SPL_MAX_SIZE = 0x18000. Is that why it isn’t find the dtb because it isn’t padded properly? Dan > On Jan 17, 2019, at 2:09 AM, eugen.hris...@microchip.com wrote: > > > > On 17.01.2019 11:05, Simon Goldschmidt wrote: >> On Thu, Jan 17, 2019 at 10:02 AM wrote: >>> >>> >>> >>> On 16.01.2019 21:05, Daniel Evans wrote: Hello, Yes, I am trying to load the U-boot SPL What I posted previously was a custom board. I switched over to the sama5d3_xplained and all I get with sama5d3_xplained_nandflash_defconfig is ROMBOOT. >>> >>> This is definitely weird. Are you using vanilla u-boot and no changes on >>> top with the sama5d3_xplained? Looks like not even your console works in >>> spl, or, you have a bad binary . >> >> With debug uart enabled it shows the DTB is missing. So when using the >> mainline defconfig (where debug uart is disabled) it fails to find a console >> as >> the DTB is missing. That's unfortunate, but expected behaviour with >> DM_SERIAL, >> I guess. >> >> I don't know the hardware, but the real problem seems to me that the binary >> being flashed is somehow missing the DTB? > > Yes that can happen, I suggested that some parts of the SPL are missing > - either the binary flashed is smaller than the real size (and the DTB, > being at the end is not copied...), > > or the value inside the 6th vector is wrong, and the first stage > bootloader is not copying enough data from NAND to RAM when executing > the SPL binary. The first stage BL only copies the number of bytes given > by 6th vector value > >> >> Regards, >> Simon >> >>> AT91bootstrap works fine. I know there was the issue with the nand_header showing up for the SD card but that shouldn’t effect the nand. Some other patch I am missing to get a non-modified boot.bin nand working? >>> >>> How are you writing your nandflash ? are you using our sam-ba tool to >>> write it ? do you use writeboot applet ? >>> The size of the 6th reset vector looks correct, with the assumption that it does not include the 208 bytes of nand_header? >>> >>> Yes it should not include it. And if you write using sam-ba the nand >>> header will be written by sam-ba, so your binary should not include it >>> already. >>> >>> I also suggest you open up a support ticket on support.microchip.com as >>> our FAE have a lot of experience to assist with such situations. >>> >>> Hope this helps, >>> Eugen >>> Dan > On Jan 16, 2019, at 6:02 AM, eugen.hris...@microchip.com wrote: > > > > > On 16.01.2019 03:13, Daniel Evans wrote: >> After flashing my boot.bin to nand I get the following output: >> >> RomBOOT >> Missing DTB >> ### ERROR ### Please RESET the board ### >> >> I found the error message in fdtdec.c, but not sure what I am missing. >> I have checked that my DTB is included in the boot.bin output. Any >> insight on what I am missing? > > Hello Daniel, > > Which defconfig are you using when building u-boot ? > > You are trying to load the U-boot SPL right ? > > It doesn't look like you even get to the point when you get to load the > u-boot proper, so maybe there are missing parts from your SPL, or the > size inside the 6th reset vector is not correctly calculated > > Did you try with our at91bootstrap proprietary second level bootloader > and get the same issue when booting the proper u-boot with it ? > > Hope this helps, > > Eugen > >> >> Dan >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot >> >>> ___ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/9] clk: actions: Add common clock driver
On Thu, 17 Jan 2019 20:45:44 +0530 Manivannan Sadhasivam wrote: Hi, > On Tue, Jan 15, 2019 at 12:43:36AM +, André Przywara wrote: > > On 14/01/2019 12:41, Amit Singh Tomar wrote: > > > > Hi, > > > > > CMU block on most of the actions SoC seems to be > > > identical(at-least, S900 and S700). > > > > Actually they are not. Not even for the small subset that we > > implement here. Try "diff -wu > > arch/arm/include/asm/arch-owl/regs_s*.h" for a start, plus the > > differences in the #ifdefs below. > > > This patch converts S900 clock driver to something common that can > > > be used for other SoCs, for instance S700(most of clk registres > > > are same). > > > > I am not sure this is a viable approach, really. > > The driver claims to support both SoC's via their compatible > > strings, but in fact is just implementing the one configured via > > Kconfig. While we should be able to easily replace the #ifdefs with > > something checking the .data member associated with the > > respective .compatible string, it gets hairy with the #defines in > > regs_s[79]00.h. So either it's two different .c files, with the > > register definitions in there, or we change the CMU_* defines to > > CMU_S[79]00_* and include both. > > > > Maybe you could try this and report how it looks like? > > If half of the file is within if-else statements, separating is > > problem more worthwhile. > > Mani, you mentioned the S500, I guess this is even more different, > > right? Which would point into the "separate files" direction. > > > > S500 is different in terms of the clock initializations. Ideally we > should have a minimal set of common clk driver like in Linux which I > authored. Otherwise, we should move forward with individual clk files > for each SoC. Having #ifdef's will definitely make the code look > messy. Yeah, that is probably the right way to go, especially when it comes to clocks like MMC, which are probably similar in their internal workings, but are at different addresses or use different offsets. Problem is we don't know this yet for sure, and Amit has a point that the files are indeed very similar right now. So as a quick measure to ensure correctness, but still keep it simple, I was thinking about keeping most of the patch as it is (still addressing my previous comments) and just protect the compatible strings below with MACH_S[79]00 ifdefs, so that both SoCs share the file, but compile to different drivers supporting only one compatible (due to the different reg_sx00.h and the #ifdef protected parts). This would arguably be the only difference between the s700 and s900 U-Boot binaries, but it's still a good start to get this SoC supported in the first place. We can always rework the clocks once we get more users (both clock-wise and SoC wise) and see what we really need and how much we can share. Cheers, Andre. > > > > > > Signed-off-by: Amit Singh Tomar > > > --- > > > Changes since v1: > > > * Moved CLK and CLK_OWL symbols from defconfig to > > > arch/arm/Kconfig. --- > > > arch/arm/Kconfig | 2 + > > > arch/arm/include/asm/arch-owl/clk_owl.h | 61 + > > > arch/arm/include/asm/arch-owl/clk_s900.h | 57 - > > > arch/arm/include/asm/arch-owl/regs_s700.h | 56 > > > > This file doesn't define an interface, so should live in the > > drivers/clk/owl directory. Same with the regs_s900.h. > > > > > configs/bubblegum_96_defconfig| 3 - > > > drivers/clk/owl/Kconfig | 10 +-- > > > drivers/clk/owl/Makefile | 2 +- > > > drivers/clk/owl/clk_owl.c | 132 > > > > > > drivers/clk/owl/clk_s900.c| 137 > > > -- 9 files changed, 255 > > > insertions(+), 205 deletions(-) create mode 100644 > > > arch/arm/include/asm/arch-owl/clk_owl.h delete mode 100644 > > > arch/arm/include/asm/arch-owl/clk_s900.h create mode 100644 > > > arch/arm/include/asm/arch-owl/regs_s700.h create mode 100644 > > > drivers/clk/owl/clk_owl.c delete mode 100644 > > > drivers/clk/owl/clk_s900.c > > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > > index 1a2e561..1daf3bf 100644 > > > --- a/arch/arm/Kconfig > > > +++ b/arch/arm/Kconfig > > > @@ -764,6 +764,8 @@ config ARCH_OWL > > > select DM > > > select DM_SERIAL > > > select OWL_SERIAL > > > + select CLK > > > + select CLK_OWL > > > select OF_CONTROL > > > imply CMD_DM > > > > > > diff --git a/arch/arm/include/asm/arch-owl/clk_owl.h > > > b/arch/arm/include/asm/arch-owl/clk_owl.h new file mode 100644 > > > index 000..962badd > > > --- /dev/null > > > +++ b/arch/arm/include/asm/arch-owl/clk_owl.h > > > @@ -0,0 +1,61 @@ > > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > > +/* > > > + * Actions Semi SoCs Clock Definitions > > > + * > > > + * Copyright (C) 2015 Actions Semi Co., Ltd. > > > + * Copyright (C) 2018 Manivannan Sadhasivam > > >
Re: [U-Boot] [PATCH v2 1/9] arm: actions: Add common framework for Actions Semi SoCs
On Thu, 17 Jan 2019 21:09:45 +0530 Manivannan Sadhasivam wrote: Hi, > [On top of Andre's review] > > On Mon, Jan 14, 2019 at 06:11:03PM +0530, Amit Singh Tomar wrote: > > This adds common arch owl support that can drive, 64-bits SoCs > > from Actions Semi. > > > > Could be, "This commit adds common arch support for Actions Semi Owl > series SoCs and removes the Bubblegum96 board files." > > > It also removes the Bubblegum specific board files. > > > > Signed-off-by: Amit Singh Tomar > > --- > > Changes since v1: > > * Moved S700 specific changes to patch 4 of 9. > > * Moved couple of symbols from defconfig to > > arch/arm/Kconfig and platform owl Kconfig. > > --- > > arch/arm/Kconfig | 3 +- > > arch/arm/mach-owl/Kconfig| 29 ++ > > arch/arm/mach-owl/Makefile | 1 + > > arch/arm/mach-owl/soc.c | 56 > > > > board/ucRobotics/bubblegum_96/Kconfig| 15 > > board/ucRobotics/bubblegum_96/MAINTAINERS| 6 --- > > board/ucRobotics/bubblegum_96/Makefile | 3 -- > > board/ucRobotics/bubblegum_96/bubblegum_96.c | 56 > > > > configs/bubblegum_96_defconfig | 4 +- > > include/configs/bubblegum_96.h | 42 > > - include/configs/owl-common.h > > | 42 + > > include/configs/s900.h | 18 + 12 > > files changed, 131 insertions(+), 144 deletions(-) create mode > > 100644 arch/arm/mach-owl/soc.c delete mode 100644 > > board/ucRobotics/bubblegum_96/Kconfig delete mode 100644 > > board/ucRobotics/bubblegum_96/MAINTAINERS delete mode 100644 > > board/ucRobotics/bubblegum_96/Makefile delete mode 100644 > > board/ucRobotics/bubblegum_96/bubblegum_96.c delete mode 100644 > > include/configs/bubblegum_96.h create mode 100644 > > include/configs/owl-common.h create mode 100644 > > include/configs/s900.h > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index d6b1629..1a2e561 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -761,9 +761,9 @@ config ARCH_MX5 > > > > config ARCH_OWL > > bool "Actions Semi OWL SoCs" > > - select ARM64 > > select DM > > select DM_SERIAL > > + select OWL_SERIAL > > select OF_CONTROL > > imply CMD_DM > > > > @@ -1555,7 +1555,6 @@ source "board/spear/spear600/Kconfig" > > source "board/spear/x600/Kconfig" > > source "board/st/stv0991/Kconfig" > > source "board/tcl/sl50/Kconfig" > > -source "board/ucRobotics/bubblegum_96/Kconfig" > > source "board/birdland/bav335x/Kconfig" > > source "board/toradex/colibri_pxa270/Kconfig" > > source "board/vscom/baltos/Kconfig" > > diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig > > index 199e772..5eb93c9 100644 > > --- a/arch/arm/mach-owl/Kconfig > > +++ b/arch/arm/mach-owl/Kconfig > > @@ -1,27 +1,22 @@ > > if ARCH_OWL > > > > -config SYS_SOC > > - default "owl" > > - > > choice > > -prompt "Actions Semi OWL SoCs board select" > > +prompt "Actions Semi SoC Variant" > > We should explicitly say "Owl" series SoCs here. > > > optional > > > > -config TARGET_BUBBLEGUM_96 > > - bool "96Boards Bubblegum-96" > > - help > > - Support for 96Boards Bubblegum-96. This board complies > > with > > - 96Board Consumer Edition Specification. Features: > > - - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 > > GPU) > > - - 2GiB RAM > > - - 8GiB eMMC, uSD slot > > - - WiFi, Bluetooth and GPS module > > - - 2x Host, 1x Device USB port > > - - HDMI > > - - 20-pin low speed and 40-pin high speed expanders, 6 > > LED, 3 buttons +config MACH_S900 > > +bool "Actionss Semi S900" > > +select ARM64 > > > > endchoice > > > > -source "board/ucRobotics/bubblegum_96/Kconfig" > > +config SYS_CONFIG_NAME > > +default "s900" if MACH_S900 > > + > > +config SYS_SOC > > +default "s900" if MACH_S900 > > + > > +config SYS_TEXT_BASE > > +default 0x1100 > > > > Move the above config symbols before MACH_S900. > > > endif > > diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile > > index 1b43dc2..0b181c6 100644 > > --- a/arch/arm/mach-owl/Makefile > > +++ b/arch/arm/mach-owl/Makefile > > @@ -1,3 +1,4 @@ > > # SPDX-License-Identifier: GPL-2.0+ > > > > +obj-y += soc.o > > obj-y += sysmap-s900.o > > diff --git a/arch/arm/mach-owl/soc.c b/arch/arm/mach-owl/soc.c > > new file mode 100644 > > index 000..d0630d2 > > --- /dev/null > > +++ b/arch/arm/mach-owl/soc.c > > @@ -0,0 +1,56 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * Actions Semi SoCs Boards Support. > > Owl SoCs... Good point, but to avoid misunderstandings, you mean: * Actions Semi Owl SoCs boards support right? I just want to make sure that we keep "Actions Semi" somewhere, as many people might not know that
Re: [U-Boot] [PATCH 2/7] drivers: ifc: restore the legacy flow for IFC config
On 12/26/18 8:37 PM, Rajesh Bhagat wrote: > Restore the legacy flow along with TFABOOT flow for > IFC configuration. What's the reason to go back to old flow? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/7] ARM: mach-omap2: Kconfig: Allow OMAP5 devices to set entry point
On 1/17/19 9:11 AM, Andrew F. Davis wrote: > On 1/17/19 8:15 AM, Tom Rini wrote: >> On Thu, Jan 17, 2019 at 08:13:21AM -0600, Andrew F. Davis wrote: >>> On 1/16/19 3:14 PM, Tom Rini wrote: On Wed, Dec 05, 2018 at 11:51:33AM -0600, Andrew F. Davis wrote: > Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to > have an non-standard boot address in memory. This may be due > to the device being a high security variant, which place the > Initial SoftWare (ISW) after certificates and secure software. > > Allow these devices to set this from Kconfig. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini > --- > arch/arm/mach-omap2/Kconfig| 13 + > arch/arm/mach-omap2/am33xx/Kconfig | 15 --- > include/configs/ti_omap5_common.h | 2 +- > 3 files changed, 14 insertions(+), 16 deletions(-) Turns out this breaks OMAP3 among others as the question is asked there now and we have no default value (nor I suspect a reasonable one). >>> >>> The only thing changed is ti_omap5_common.h, the default provided in >>> that file is 0x40301350, would it be okay to just make that the default >>> for ISW_ENTRY_ADDR for all platforms that included that file? >> >> Well, ISW_ENTRY_ADDR doesn't make sense for OMAP3, right? I suspect the >> problem is that in moving it from mach-omap2/am33xx/Kconfig to >> mach-omap2/Kconfig you need to update the depends on guards so that it >> doesn't show up where it's not used. >> > > CONFIG_SPL_TEXT_BASE should be converted to Kconfig, but cannot be right > now due to some other platforms using strange methods for setting it in > header files. So we have ISW_ENTRY_ADDR in Kconfig that is used to set > CONFIG_SPL_TEXT_BASE. ISW_ENTRY_ADDR can be defined for any platform, I > just may not be used depending on what headers it includes and whether > they use it to set CONFIG_SPL_TEXT_BASE. > > The change here is using it in ti_omap5_common.h, which a lot more > platforms use is seems than I noticed. So all these platforms now need > ISW_ENTRY_ADDR set to what the header to set them as (0x40301350). > > Again, all this goes away when CONFIG_SPL_TEXT_BASE gets converted to > Kconfig. Scratch that, it's not SPL_TEXT_BASE converted to Kconfig (that's done for some platforms) it looks to be us overwriting it still in many places. Anyway posted v3 with fix for above. Andrew > > Andrew > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: mvebu: armada-xp/37x/38x: Enable PCIe DT node
Hi Stefan,
On Fri, Jan 18, 2019 at 2:35 AM Stefan Roese wrote:
>
> This patch enables the DT PCIe nodes for the Armada XP/37x/38x boards.
> This is needed for the new DM_PCI support in the MVEBU PCIe driver.
>
> Signed-off-by: Stefan Roese
> Cc: Dirk Eibach
> Cc: Mario Six
> Cc: Chris Packham
> Cc: Phil Sutter
> Cc: Marek Behún
> Cc: VlaoMao
> ---
> arch/arm/dts/armada-375.dtsi| 2 +-
> arch/arm/dts/armada-380.dtsi| 2 +-
> arch/arm/dts/armada-385.dtsi| 2 +-
> arch/arm/dts/armada-xp-mv78230.dtsi | 2 +-
> arch/arm/dts/armada-xp-mv78260.dtsi | 2 +-
> arch/arm/dts/armada-xp-mv78460.dtsi | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
I think this should be at the board level instead of the SoC. There
are boards that don't use the pcie controller even though it's in the
SoC. Another good reason is that this deviates from the dtsi files in
Linux
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-375.dtsi#n548
>
> diff --git a/arch/arm/dts/armada-375.dtsi b/arch/arm/dts/armada-375.dtsi
> index 249c41c757..7b2723cdf2 100644
> --- a/arch/arm/dts/armada-375.dtsi
> +++ b/arch/arm/dts/armada-375.dtsi
> @@ -584,7 +584,7 @@
>
> pcie-controller {
> compatible = "marvell,armada-370-pcie";
> - status = "disabled";
> + status = "okay";
> device_type = "pci";
>
> #address-cells = <3>;
> diff --git a/arch/arm/dts/armada-380.dtsi b/arch/arm/dts/armada-380.dtsi
> index 5102d19cc8..95c8a1bae0 100644
> --- a/arch/arm/dts/armada-380.dtsi
> +++ b/arch/arm/dts/armada-380.dtsi
> @@ -73,7 +73,7 @@
>
> pcie-controller {
> compatible = "marvell,armada-370-pcie";
> - status = "disabled";
> + status = "okay";
> device_type = "pci";
>
> #address-cells = <3>;
> diff --git a/arch/arm/dts/armada-385.dtsi b/arch/arm/dts/armada-385.dtsi
> index 8e67d2c083..d1d277e165 100644
> --- a/arch/arm/dts/armada-385.dtsi
> +++ b/arch/arm/dts/armada-385.dtsi
> @@ -78,7 +78,7 @@
>
> pcie-controller {
> compatible = "marvell,armada-370-pcie";
> - status = "disabled";
> + status = "enabled";
> device_type = "pci";
>
> #address-cells = <3>;
> diff --git a/arch/arm/dts/armada-xp-mv78230.dtsi
> b/arch/arm/dts/armada-xp-mv78230.dtsi
> index 6e6d0f04bf..d750ac1f6f 100644
> --- a/arch/arm/dts/armada-xp-mv78230.dtsi
> +++ b/arch/arm/dts/armada-xp-mv78230.dtsi
> @@ -88,7 +88,7 @@
> */
> pcie-controller {
> compatible = "marvell,armada-xp-pcie";
> - status = "disabled";
> + status = "okay";
> device_type = "pci";
>
> #address-cells = <3>;
> diff --git a/arch/arm/dts/armada-xp-mv78260.dtsi
> b/arch/arm/dts/armada-xp-mv78260.dtsi
> index c5fdc99f0d..50d3716b96 100644
> --- a/arch/arm/dts/armada-xp-mv78260.dtsi
> +++ b/arch/arm/dts/armada-xp-mv78260.dtsi
> @@ -89,7 +89,7 @@
> */
> pcie-controller {
> compatible = "marvell,armada-xp-pcie";
> - status = "disabled";
> + status = "okay";
> device_type = "pci";
>
> #address-cells = <3>;
> diff --git a/arch/arm/dts/armada-xp-mv78460.dtsi
> b/arch/arm/dts/armada-xp-mv78460.dtsi
> index 0e24f1a385..5921f41264 100644
> --- a/arch/arm/dts/armada-xp-mv78460.dtsi
> +++ b/arch/arm/dts/armada-xp-mv78460.dtsi
> @@ -106,7 +106,7 @@
> */
> pcie-controller {
> compatible = "marvell,armada-xp-pcie";
> - status = "disabled";
> + status = "okay";
> device_type = "pci";
>
> #address-cells = <3>;
> --
> 2.20.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 6/7] defconfigs: Add config for AM57xx High Security EVM with USB/UART Boot support
Add a new defconfig file for the AM57xx High Security EVM. This config
is specific for the case of USB/UART booting.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
---
MAINTAINERS | 1 +
configs/am57xx_hs_evm_usb_defconfig | 92 +
2 files changed, 93 insertions(+)
create mode 100644 configs/am57xx_hs_evm_usb_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 2da1a22e6c..fd5b2282f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -675,6 +675,7 @@ F: configs/am335x_hs_evm_defconfig
F: configs/am335x_hs_evm_uart_defconfig
F: configs/am43xx_hs_evm_defconfig
F: configs/am57xx_hs_evm_defconfig
+F: configs/am57xx_hs_evm_usb_defconfig
F: configs/dra7xx_hs_evm_defconfig
F: configs/dra7xx_hs_evm_usb_defconfig
F: configs/k2hk_hs_evm_defconfig
diff --git a/configs/am57xx_hs_evm_usb_defconfig
b/configs/am57xx_hs_evm_usb_defconfig
new file mode 100644
index 00..a0c42387ec
--- /dev/null
+++ b/configs/am57xx_hs_evm_usb_defconfig
@@ -0,0 +1,92 @@
+CONFIG_ARM=y
+CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TI_COMMON_CMD_OPTIONS=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_EMIF_REGION_START=0xbdb0
+CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE=0x0200
+CONFIG_TI_SECURE_EMIF_PROTECTED_REGION_SIZE=0x01c0
+CONFIG_ISW_ENTRY_ADDR=0x40306d50
+CONFIG_TARGET_AM57XX_EVM=y
+CONFIG_SPL=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_ARMV7_LPAE=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS2,115200
androidboot.console=ttyS2 androidboot.hardware=beagle_x15board"
+# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_MISC_INIT_R is not set
+CONFIG_VERSION_VARIABLE=y
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_DMA_SUPPORT=y
+# CONFIG_SPL_NAND_SUPPORT is not set
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_DFU=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15"
+CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1
am57xx-beagle-x15-revc am572x-idk am571x-idk am574x-idk"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SCSI_AHCI=y
+# CONFIG_BLK is not set
+CONFIG_DFU_MMC=y
+CONFIG_DFU_RAM=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0x8200
+CONFIG_FASTBOOT_BUF_SIZE=0x2F00
+CONFIG_FASTBOOT_USB_DEV=1
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=1
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_OMAP_HS=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
+CONFIG_MII=y
+CONFIG_DRIVER_TI_CPSW=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_PALMAS=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_PALMAS=y
+CONFIG_DM_SERIAL=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_TI_QSPI=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_DWC3_OMAP=y
+CONFIG_USB_DWC3_PHY_OMAP=y
+CONFIG_OMAP_USB_PHY=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0451
+CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/7] ARM: mach-omap2: Kconfig: Allow OMAP5 devices to set entry point
Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to have an non-standard boot address in memory. This may be due to the device being a high security variant, which place the Initial SoftWare (ISW) after certificates and secure software. Allow these devices to set this from Kconfig. Signed-off-by: Andrew F. Davis --- arch/arm/mach-omap2/Kconfig| 15 +++ arch/arm/mach-omap2/am33xx/Kconfig | 15 --- include/configs/ti_omap5_common.h | 2 +- 3 files changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 58e545a45b..d9bdcb355a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -167,6 +167,21 @@ config TI_SECURE_EMIF_PROTECTED_REGION_SIZE using hardware memory firewalls. This value must be smaller than the TI_SECURE_EMIF_TOTAL_REGION_SIZE value. +if AM43XX || AM33XX || OMAP54XX +config ISW_ENTRY_ADDR + hex "Address in memory or XIP address of bootloader entry point" + default 0x402F4000 if AM43XX + default 0x402F0400 if AM33XX + default 0x40301350 if OMAP54XX + help + After any reset, the boot ROM searches the boot media for a valid + boot image. For non-XIP devices, the ROM then copies the image into + internal memory. For all boot modes, after the ROM processes the + boot image it eventually computes the entry point address depending + on the device type (secure/non-secure), boot media (xip/non-xip) and + image headers. +endif + source "arch/arm/mach-omap2/omap3/Kconfig" source "arch/arm/mach-omap2/omap4/Kconfig" diff --git a/arch/arm/mach-omap2/am33xx/Kconfig b/arch/arm/mach-omap2/am33xx/Kconfig index 57284c4ae1..4f15346c86 100644 --- a/arch/arm/mach-omap2/am33xx/Kconfig +++ b/arch/arm/mach-omap2/am33xx/Kconfig @@ -275,21 +275,6 @@ config SPL_RTC_DDR_SUPPORT endif if AM43XX || AM33XX -config ISW_ENTRY_ADDR - hex "Address in memory or XIP flash of bootloader entry point" - default 0x402F4000 if AM43XX - default 0x402F0400 if AM33XX - help - After any reset, the boot ROM on the AM43XX SOC - searches the boot media for a valid boot image. - For non-XIP devices, the ROM then copies the - image into internal memory. - For all boot modes, after the ROM processes the - boot image it eventually computes the entry - point address depending on the device type - (secure/non-secure), boot media (xip/non-xip) and - image headers. - config PUB_ROM_DATA_SIZE hex "Size in bytes of the L3 SRAM reserved by ROM to store data" default 0x8400 diff --git a/include/configs/ti_omap5_common.h b/include/configs/ti_omap5_common.h index 8bf4a6b7e9..ba57c40182 100644 --- a/include/configs/ti_omap5_common.h +++ b/include/configs/ti_omap5_common.h @@ -81,7 +81,7 @@ * RAM from address 0x40301350 (0x4030+0x1000(reserved)+0x350(cert)). */ #define TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ 0x1000 -#define CONFIG_SPL_TEXT_BASE 0x40301350 +#define CONFIG_SPL_TEXT_BASE CONFIG_ISW_ENTRY_ADDR /* If no specific start address is specified then the secure EMIF * region will be placed at the end of the DDR space. In order to prevent * the main u-boot relocation from clobbering that memory and causing a -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 7/7] doc: ti-secure: Add ULO info for AM57xx/DRA7xx secure devices from TI
Booting from UART and USB on HS devices is now supported for this platform. Update documentation for the same. Signed-off-by: Andrew F. Davis Reviewed-by: Tom Rini --- doc/README.ti-secure | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/doc/README.ti-secure b/doc/README.ti-secure index 4b5380c0f3..76950253ac 100644 --- a/doc/README.ti-secure +++ b/doc/README.ti-secure @@ -108,7 +108,8 @@ Booting of U-Boot SPL Invoking the script for DRA7xx/AM57xx Secure Devices - create-boot-image.sh + create-boot-image.sh \ + is a value that specifies the type of the image to generate OR the action the image generation tool will take. Valid @@ -116,7 +117,6 @@ Booting of U-Boot SPL X-LOADER - Generates an image for NOR or QSPI boot modes MLO - Generates an image for SD/MMC/eMMC boot modes ULO - Generates an image for USB/UART peripheral boot modes - Note: ULO is not yet used by the u-boot build process is the full path and filename of the public world boot loader binary file (for this platform, this is always u-boot-spl.bin). @@ -130,9 +130,13 @@ Booting of U-Boot SPL the device ROM bootloader requires for loading from the FAT partition of an SD card (same as on non-secure devices) + u-boot-spl_HS_ULO - boot image for USB/UART peripheral boot modes u-boot-spl_HS_X-LOADER - boot image for all other flash memories including QSPI and NOR flash +is the address at which SOC ROM should load the + + Invoking the script for Keystone2 Secure Devices = -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 5/7] defconfigs: Add config for DRA7xx High Security EVM with USB Boot support
Add a new defconfig file for the DRA7xx High Security EVM. This config
is specific for the case of USB booting.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
---
MAINTAINERS | 1 +
configs/dra7xx_hs_evm_usb_defconfig | 106
2 files changed, 107 insertions(+)
create mode 100644 configs/dra7xx_hs_evm_usb_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index e192db0754..2da1a22e6c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -676,6 +676,7 @@ F: configs/am335x_hs_evm_uart_defconfig
F: configs/am43xx_hs_evm_defconfig
F: configs/am57xx_hs_evm_defconfig
F: configs/dra7xx_hs_evm_defconfig
+F: configs/dra7xx_hs_evm_usb_defconfig
F: configs/k2hk_hs_evm_defconfig
F: configs/k2e_hs_evm_defconfig
F: configs/k2g_hs_evm_defconfig
diff --git a/configs/dra7xx_hs_evm_usb_defconfig
b/configs/dra7xx_hs_evm_usb_defconfig
new file mode 100644
index 00..7842851491
--- /dev/null
+++ b/configs/dra7xx_hs_evm_usb_defconfig
@@ -0,0 +1,106 @@
+CONFIG_ARM=y
+CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TI_COMMON_CMD_OPTIONS=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_EMIF_REGION_START=0xbdb0
+CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE=0x0200
+CONFIG_TI_SECURE_EMIF_PROTECTED_REGION_SIZE=0x01c0
+CONFIG_ISW_ENTRY_ADDR=0x40306d50
+CONFIG_TARGET_DRA7XX_EVM=y
+CONFIG_SPL=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_ARMV7_LPAE=y
+CONFIG_AHCI=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS0,115200
androidboot.console=ttyS0 androidboot.hardware=jacinto6evmboard"
+# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_MISC_INIT_R is not set
+CONFIG_VERSION_VARIABLE=y
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_DMA_SUPPORT=y
+# CONFIG_SPL_NAND_SUPPORT is not set
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_DFU=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="dra7-evm"
+CONFIG_OF_LIST="dra7-evm dra72-evm dra72-evm-revc dra71-evm dra76-evm"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_DWC_AHCI=y
+CONFIG_DFU_MMC=y
+CONFIG_DFU_RAM=y
+CONFIG_DFU_SF=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0x8200
+CONFIG_FASTBOOT_BUF_SIZE=0x2F00
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=1
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_DM_GPIO=y
+CONFIG_PCF8575_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_OMAP_HS=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_DM_ETH=y
+CONFIG_PHY_GIGE=y
+CONFIG_MII=y
+CONFIG_DRIVER_TI_CPSW=y
+CONFIG_SPL_PHY=y
+CONFIG_PIPE3_PHY=y
+CONFIG_PMIC_PALMAS=y
+CONFIG_PMIC_LP873X=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_REGULATOR_PALMAS=y
+CONFIG_DM_REGULATOR_LP873X=y
+CONFIG_DM_SCSI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_TI_QSPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_XHCI_DRA7XX_INDEX=1
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_DWC3_OMAP=y
+CONFIG_USB_DWC3_PHY_OMAP=y
+CONFIG_OMAP_USB_PHY=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0451
+CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/7] dfu: Remove dependency on HUSH parser in SPL
CLI support with the HUSH parser is not currently SPL safe due to it's
use of realloc. That function is not defined for SPLs that use
SYS_MALLOC_SIMPLE. CLI support can be built in to SPL and some functions
do work, but use of some like run_command() will cause build to fail.
When no SPL code calls this function build works as the compiler removes
this unreachable code so the unresolved symbols are ignored.
If DFU support is enabled in SPL then MMU DFU support may get brought in
also, this code does make a call to run_command() causing build to fail
if the HUSH parser is not built-in. To break this odd and unneeded
dependency chain we use CONFIG_IS_ENABLED where appropriate to prevent
calls into HUSH code from SPL. This also removes our need to pull in the
rather unrelated source file when SPL_DFU is defined.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
---
common/Makefile | 1 -
common/cli.c| 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/common/Makefile b/common/Makefile
index 3711016505..ad390d083a 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -67,7 +67,6 @@ ifdef CONFIG_SPL_BUILD
ifdef CONFIG_SPL_DFU
obj-$(CONFIG_DFU_OVER_USB) += dfu.o
endif
-obj-$(CONFIG_SPL_DFU) += cli_hush.o
obj-$(CONFIG_SPL_HASH_SUPPORT) += hash.o
obj-$(CONFIG_TPL_HASH_SUPPORT) += hash.o
obj-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o
diff --git a/common/cli.c b/common/cli.c
index 51b8d5f85c..fea8f8004c 100644
--- a/common/cli.c
+++ b/common/cli.c
@@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
*/
int run_command(const char *cmd, int flag)
{
-#ifndef CONFIG_HUSH_PARSER
+#if !CONFIG_IS_ENABLED(HUSH_PARSER)
/*
* cli_run_command can return 0 or 1 for success, so clean up
* its result.
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/7] Add USB boot to HS DRA7xx/AM57xx
Hello all, This series adds USB boot support to HS DRA7xx/AM57xx platforms. We start by cleaning up DFU boot in SPL support. What is done in the first patch for DFU, if acceptable, should be done to the other boot modes. The 4th patch is needed as on HS devices a header is added to the boot image that tells the ROM where to load this image. This only works for block device booting as the ROM can read the header and move the image into memory in steps. For streaming boot modes USB/ UART/NET the image is placed in memory as it is received from the media live. This means the header is ignored and the image has a fixed offset in memory. For AM47xx we align the boot modes by making the offset for block device booting the same as the fixed offset for streaming boot modes, in this way only one defconfig is needed. For DRA7xx/AM57xx the signing tools will need to be updated to support specifying this address, when this is done the offset in the base HS defconfig can be moved to match the new offset and the defconfigs added here in patch 5 and 6 can be unified back into the base HS defconfig. The last patch updates the docs for the same above. Thanks, Andrew Changes from v2: - Only use ISW_ENTRY_ADDR for system with a set default Changes from v1: - Drop explicit UART boot support from DRA7xx as this cannot be tested Andrew F. Davis (7): spl: Kconfig: Drop the _SUPPORT postfix from SPL_DFU dfu: Make DFU support more SPL friendly dfu: Remove dependency on HUSH parser in SPL ARM: mach-omap2: Kconfig: Allow OMAP5 devices to set entry point defconfigs: Add config for DRA7xx High Security EVM with USB Boot support defconfigs: Add config for AM57xx High Security EVM with USB/UART Boot support doc: ti-secure: Add ULO info for AM57xx/DRA7xx secure devices from TI MAINTAINERS | 2 + arch/arm/cpu/armv8/zynqmp/spl.c | 2 +- arch/arm/mach-omap2/Kconfig | 15 arch/arm/mach-omap2/am33xx/Kconfig | 15 arch/arm/mach-omap2/boot-common.c | 2 +- common/Makefile | 3 +- common/cli.c| 2 +- common/spl/Kconfig | 6 +- common/spl/Makefile | 2 +- common/spl/spl_ram.c| 4 +- configs/am57xx_hs_evm_usb_defconfig | 92 configs/dra7xx_hs_evm_usb_defconfig | 106 doc/README.ti-secure| 8 ++- drivers/Makefile| 3 +- drivers/dfu/Makefile| 12 ++-- drivers/usb/gadget/Makefile | 2 +- include/configs/dra7xx_evm.h| 2 +- include/configs/ti_omap5_common.h | 2 +- include/configs/xilinx_zynqmp.h | 4 +- include/dfu.h | 10 +-- 20 files changed, 248 insertions(+), 46 deletions(-) create mode 100644 configs/am57xx_hs_evm_usb_defconfig create mode 100644 configs/dra7xx_hs_evm_usb_defconfig -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/7] dfu: Make DFU support more SPL friendly
Do this by using $(SPL_) in Makefiles and CONFIG_IS_ENABLED in C code. This ensures the files and features are only built into the right build for which they are enabled. Using the macros to simplify this patch was made possible by the config symbol rename done in the last patch. Signed-off-by: Andrew F. Davis Reviewed-by: Tom Rini --- drivers/Makefile | 3 +-- drivers/dfu/Makefile | 12 ++-- include/dfu.h| 10 +- 3 files changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/Makefile b/drivers/Makefile index 14543c7d6c..eca023ac04 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -2,6 +2,7 @@ obj-$(CONFIG_$(SPL_TPL_)CLK) += clk/ obj-$(CONFIG_$(SPL_TPL_)DM) += core/ +obj-$(CONFIG_$(SPL_TPL_)DFU) += dfu/ obj-$(CONFIG_$(SPL_TPL_)GPIO_SUPPORT) += gpio/ obj-$(CONFIG_$(SPL_TPL_)DRIVERS_MISC_SUPPORT) += misc/ sysreset/ firmware/ obj-$(CONFIG_$(SPL_TPL_)I2C_SUPPORT) += i2c/ @@ -50,7 +51,6 @@ obj-$(CONFIG_SPL_MUSB_NEW_SUPPORT) += usb/musb-new/ obj-$(CONFIG_SPL_USB_GADGET) += usb/gadget/ obj-$(CONFIG_SPL_USB_GADGET) += usb/common/ obj-$(CONFIG_SPL_USB_GADGET) += usb/gadget/udc/ -obj-$(CONFIG_SPL_DFU) += dfu/ obj-$(CONFIG_SPL_WATCHDOG_SUPPORT) += watchdog/ obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += usb/host/ obj-$(CONFIG_OMAP_USB_PHY) += usb/phy/ @@ -86,7 +86,6 @@ obj-y += misc/ obj-$(CONFIG_MMC) += mmc/ obj-$(CONFIG_NVME) += nvme/ obj-y += pcmcia/ -obj-y += dfu/ obj-$(CONFIG_X86) += pch/ obj-y += phy/allwinner/ obj-y += phy/marvell/ diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile index 56f9b0c5f4..4164f342ac 100644 --- a/drivers/dfu/Makefile +++ b/drivers/dfu/Makefile @@ -3,9 +3,9 @@ # Copyright (C) 2012 Samsung Electronics # Lukasz Majewski -obj-$(CONFIG_DFU) += dfu.o -obj-$(CONFIG_DFU_MMC) += dfu_mmc.o -obj-$(CONFIG_DFU_NAND) += dfu_nand.o -obj-$(CONFIG_DFU_RAM) += dfu_ram.o -obj-$(CONFIG_DFU_SF) += dfu_sf.o -obj-$(CONFIG_DFU_TFTP) += dfu_tftp.o +obj-$(CONFIG_$(SPL_)DFU) += dfu.o +obj-$(CONFIG_$(SPL_)DFU_MMC) += dfu_mmc.o +obj-$(CONFIG_$(SPL_)DFU_NAND) += dfu_nand.o +obj-$(CONFIG_$(SPL_)DFU_RAM) += dfu_ram.o +obj-$(CONFIG_$(SPL_)DFU_SF) += dfu_sf.o +obj-$(CONFIG_$(SPL_)DFU_TFTP) += dfu_tftp.o diff --git a/include/dfu.h b/include/dfu.h index fbe978abdc..9340a900a2 100644 --- a/include/dfu.h +++ b/include/dfu.h @@ -202,7 +202,7 @@ static inline void dfu_set_defer_flush(struct dfu_entity *dfu) int dfu_write_from_mem_addr(struct dfu_entity *dfu, void *buf, int size); /* Device specific */ -#ifdef CONFIG_DFU_MMC +#if CONFIG_IS_ENABLED(DFU_MMC) extern int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *devstr, char *s); #else static inline int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *devstr, @@ -213,7 +213,7 @@ static inline int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *devstr, } #endif -#ifdef CONFIG_DFU_NAND +#if CONFIG_IS_ENABLED(DFU_NAND) extern int dfu_fill_entity_nand(struct dfu_entity *dfu, char *devstr, char *s); #else static inline int dfu_fill_entity_nand(struct dfu_entity *dfu, char *devstr, @@ -224,7 +224,7 @@ static inline int dfu_fill_entity_nand(struct dfu_entity *dfu, char *devstr, } #endif -#ifdef CONFIG_DFU_RAM +#if CONFIG_IS_ENABLED(DFU_RAM) extern int dfu_fill_entity_ram(struct dfu_entity *dfu, char *devstr, char *s); #else static inline int dfu_fill_entity_ram(struct dfu_entity *dfu, char *devstr, @@ -235,7 +235,7 @@ static inline int dfu_fill_entity_ram(struct dfu_entity *dfu, char *devstr, } #endif -#ifdef CONFIG_DFU_SF +#if CONFIG_IS_ENABLED(DFU_SF) extern int dfu_fill_entity_sf(struct dfu_entity *dfu, char *devstr, char *s); #else static inline int dfu_fill_entity_sf(struct dfu_entity *dfu, char *devstr, @@ -259,7 +259,7 @@ static inline int dfu_fill_entity_sf(struct dfu_entity *dfu, char *devstr, * * @return 0 on success, otherwise error code */ -#ifdef CONFIG_DFU_TFTP +#if CONFIG_IS_ENABLED(DFU_TFTP) int dfu_tftp_write(char *dfu_entity_name, unsigned int addr, unsigned int len, char *interface, char *devstring); #else -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/7] spl: Kconfig: Drop the _SUPPORT postfix from SPL_DFU
The symbol CONFIG_SPL_DFU_SUPPORT in SPL build has the same
meaning as CONFIG_DFU in regular U-Boot. Drop the _SUPPORT
to allow for cleaner use in code.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
---
arch/arm/cpu/armv8/zynqmp/spl.c | 2 +-
arch/arm/mach-omap2/boot-common.c | 2 +-
common/Makefile | 4 ++--
common/spl/Kconfig| 6 +++---
common/spl/Makefile | 2 +-
common/spl/spl_ram.c | 4 ++--
drivers/Makefile | 2 +-
drivers/usb/gadget/Makefile | 2 +-
include/configs/dra7xx_evm.h | 2 +-
include/configs/xilinx_zynqmp.h | 4 ++--
10 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/cpu/armv8/zynqmp/spl.c b/arch/arm/cpu/armv8/zynqmp/spl.c
index 01f31d0f0e..fb3955c93f 100644
--- a/arch/arm/cpu/armv8/zynqmp/spl.c
+++ b/arch/arm/cpu/armv8/zynqmp/spl.c
@@ -93,7 +93,7 @@ u32 spl_boot_device(void)
case EMMC_MODE:
return BOOT_DEVICE_MMC1;
#endif
-#ifdef CONFIG_SPL_DFU_SUPPORT
+#ifdef CONFIG_SPL_DFU
case USB_MODE:
return BOOT_DEVICE_DFU;
#endif
diff --git a/arch/arm/mach-omap2/boot-common.c
b/arch/arm/mach-omap2/boot-common.c
index 176d4f67cb..2db19227b9 100644
--- a/arch/arm/mach-omap2/boot-common.c
+++ b/arch/arm/mach-omap2/boot-common.c
@@ -108,7 +108,7 @@ void save_omap_boot_params(void)
sys_boot_device = 1;
break;
#endif
-#if defined(BOOT_DEVICE_DFU) && !defined(CONFIG_SPL_DFU_SUPPORT)
+#if defined(BOOT_DEVICE_DFU) && !defined(CONFIG_SPL_DFU)
case BOOT_DEVICE_DFU:
sys_boot_device = 1;
break;
diff --git a/common/Makefile b/common/Makefile
index 0de60b3ced..3711016505 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -64,10 +64,10 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTAGE) += bootstage.o
obj-$(CONFIG_$(SPL_TPL_)BLOBLIST) += bloblist.o
ifdef CONFIG_SPL_BUILD
-ifdef CONFIG_SPL_DFU_SUPPORT
+ifdef CONFIG_SPL_DFU
obj-$(CONFIG_DFU_OVER_USB) += dfu.o
endif
-obj-$(CONFIG_SPL_DFU_SUPPORT) += cli_hush.o
+obj-$(CONFIG_SPL_DFU) += cli_hush.o
obj-$(CONFIG_SPL_HASH_SUPPORT) += hash.o
obj-$(CONFIG_TPL_HASH_SUPPORT) += hash.o
obj-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 37ecbc6b1c..ce76dcfe2f 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -794,7 +794,7 @@ config SPL_USB_ETHER
since the network stack uses a number of environment variables.
See also SPL_NET_SUPPORT and SPL_ETH_SUPPORT.
-config SPL_DFU_SUPPORT
+config SPL_DFU
bool "Support DFU (Device Firmware Upgrade)"
select SPL_HASH_SUPPORT
select SPL_DFU_NO_RESET
@@ -809,11 +809,11 @@ config SPL_DFU_SUPPORT
choice
bool "DFU device selection"
- depends on SPL_DFU_SUPPORT
+ depends on SPL_DFU
config SPL_DFU_RAM
bool "RAM device"
- depends on SPL_DFU_SUPPORT && SPL_RAM_SUPPORT
+ depends on SPL_DFU && SPL_RAM_SUPPORT
help
select RAM/DDR memory device for loading binary images
(u-boot/kernel) to the selected device partition using
diff --git a/common/spl/Makefile b/common/spl/Makefile
index a130a5be4b..6f8d7599ae 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_$(SPL_TPL_)USB_SUPPORT) += spl_usb.o
obj-$(CONFIG_$(SPL_TPL_)FAT_SUPPORT) += spl_fat.o
obj-$(CONFIG_$(SPL_TPL_)EXT_SUPPORT) += spl_ext.o
obj-$(CONFIG_$(SPL_TPL_)SATA_SUPPORT) += spl_sata.o
-obj-$(CONFIG_$(SPL_TPL_)DFU_SUPPORT) += spl_dfu.o
+obj-$(CONFIG_$(SPL_TPL_)DFU) += spl_dfu.o
obj-$(CONFIG_$(SPL_TPL_)SPI_LOAD) += spl_spi.o
obj-$(CONFIG_$(SPL_TPL_)RAM_SUPPORT) += spl_ram.o
obj-$(CONFIG_$(SPL_TPL_)USB_SDP_SUPPORT) += spl_sdp.o
diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c
index 5fcc3b1504..954e91a004 100644
--- a/common/spl/spl_ram.c
+++ b/common/spl/spl_ram.c
@@ -35,7 +35,7 @@ static int spl_ram_load_image(struct spl_image_info
*spl_image,
header = (struct image_header *)CONFIG_SPL_LOAD_FIT_ADDRESS;
-#if CONFIG_IS_ENABLED(DFU_SUPPORT)
+#if CONFIG_IS_ENABLED(DFU)
if (bootdev->boot_device == BOOT_DEVICE_DFU)
spl_dfu_cmd(0, "dfu_alt_info_ram", "ram", "0");
#endif
@@ -76,7 +76,7 @@ static int spl_ram_load_image(struct spl_image_info
*spl_image,
#if CONFIG_IS_ENABLED(RAM_DEVICE)
SPL_LOAD_IMAGE_METHOD("RAM", 0, BOOT_DEVICE_RAM, spl_ram_load_image);
#endif
-#if CONFIG_IS_ENABLED(DFU_SUPPORT)
+#if CONFIG_IS_ENABLED(DFU)
SPL_LOAD_IMAGE_METHOD("DFU", 0, BOOT_DEVICE_DFU, spl_ram_load_image);
#endif
diff --git a/drivers/Makefile b/drivers/Makefile
index 4105864e2b..14543c7d6c 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -50,7 +50,7 @@ obj-$(CONFIG_SPL_MUSB_NEW_SUPPORT) += usb/musb-new/
obj-$(CONFIG_SPL_USB_GADGET) += usb/gadget/
obj-$(CONFIG_SPL_USB_GADGET) += usb/common/
obj-$(CONFIG_SPL_USB_GADGET) += usb/gadget/udc/
Re: [U-Boot] no DTB with nand SPL on sama5d3
So I did a fresh clone of Uboot and got the same result: RomBOOT Missing DTB ### ERROR ### Please RESET the board ### To create the boot.bin I ran the following: make mrproper make sama5d3_xplained_nandflash_defconfig I would then use an SD card to boot linux and then copy the boot.bin and other files with flash_erase and hand_write: flash_erase /dev/mtd0 0 0 nandwrite -p /dev/mtd0 boot.bin And here is the size of mtd0: dev:size erasesize name mtd0: 0004 0002 “uboot_spl" And you can see in the boot.bin file the following hex values: 000 2405 c090 2405 c090 2405 c090 2405 c090 * 0d0 000f ea00 f014 e59f f014 e59f f014 e59f 0e0 f014 e59f c51e f014 e59f f014 e59f Which does correspond to the size once you remove the 208 header bytes.: -rw-r--r-- 1 nelson nelson 50670 Jan 17 11:15 boot.bin And it does appear to include the DTB since boot.bin without the nandheader (tail -C+209) is identical to spl/u-boot-spl.bin (except for the 6th vector), which is identical to spl/u-boot-spl-dtb.bin. Can you get it to work? For completeness my cross compiler is gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf Thanks, Dan > On Jan 17, 2019, at 2:09 AM, eugen.hris...@microchip.com wrote: > > > > On 17.01.2019 11:05, Simon Goldschmidt wrote: >> On Thu, Jan 17, 2019 at 10:02 AM wrote: >>> >>> >>> >>> On 16.01.2019 21:05, Daniel Evans wrote: Hello, Yes, I am trying to load the U-boot SPL What I posted previously was a custom board. I switched over to the sama5d3_xplained and all I get with sama5d3_xplained_nandflash_defconfig is ROMBOOT. >>> >>> This is definitely weird. Are you using vanilla u-boot and no changes on >>> top with the sama5d3_xplained? Looks like not even your console works in >>> spl, or, you have a bad binary . >> >> With debug uart enabled it shows the DTB is missing. So when using the >> mainline defconfig (where debug uart is disabled) it fails to find a console >> as >> the DTB is missing. That's unfortunate, but expected behaviour with >> DM_SERIAL, >> I guess. >> >> I don't know the hardware, but the real problem seems to me that the binary >> being flashed is somehow missing the DTB? > > Yes that can happen, I suggested that some parts of the SPL are missing > - either the binary flashed is smaller than the real size (and the DTB, > being at the end is not copied...), > > or the value inside the 6th vector is wrong, and the first stage > bootloader is not copying enough data from NAND to RAM when executing > the SPL binary. The first stage BL only copies the number of bytes given > by 6th vector value > >> >> Regards, >> Simon >> >>> AT91bootstrap works fine. I know there was the issue with the nand_header showing up for the SD card but that shouldn’t effect the nand. Some other patch I am missing to get a non-modified boot.bin nand working? >>> >>> How are you writing your nandflash ? are you using our sam-ba tool to >>> write it ? do you use writeboot applet ? >>> The size of the 6th reset vector looks correct, with the assumption that it does not include the 208 bytes of nand_header? >>> >>> Yes it should not include it. And if you write using sam-ba the nand >>> header will be written by sam-ba, so your binary should not include it >>> already. >>> >>> I also suggest you open up a support ticket on support.microchip.com as >>> our FAE have a lot of experience to assist with such situations. >>> >>> Hope this helps, >>> Eugen >>> Dan > On Jan 16, 2019, at 6:02 AM, eugen.hris...@microchip.com wrote: > > > > > On 16.01.2019 03:13, Daniel Evans wrote: >> After flashing my boot.bin to nand I get the following output: >> >> RomBOOT >> Missing DTB >> ### ERROR ### Please RESET the board ### >> >> I found the error message in fdtdec.c, but not sure what I am missing. >> I have checked that my DTB is included in the boot.bin output. Any >> insight on what I am missing? > > Hello Daniel, > > Which defconfig are you using when building u-boot ? > > You are trying to load the U-boot SPL right ? > > It doesn't look like you even get to the point when you get to load the > u-boot proper, so maybe there are missing parts from your SPL, or the > size inside the 6th reset vector is not correctly calculated > > Did you try with our at91bootstrap proprietary second level bootloader > and get the same issue when booting the proper u-boot with it ? > > Hope this helps, > > Eugen > >> >> Dan >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot >> >>> ___ >>> U-Boot mailing list >>>
Re: [U-Boot] [PATCH 10/11] cpu: Bind timer driver for boot hart
On 01/17/2019 11:39 AM, Anup Patel wrote: From: Atish Patra Currently, timer driver is bound only for hart0. There is no mandatory requirement that hart0 should always come up. In fact, HiFive Unleashed SoC hart0 doesn't boot in S-mode because it only has M-mode. The timer driver should be bound for boot hart. Signed-off-by: Atish Patra Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/11] drivers: serial: serial_sifive: Skip baudrate config if no input clock
On 01/17/2019 11:39 AM, Anup Patel wrote: From: Atish Patra It is possible that input clock is not available because clk device was not available and 'clock-frequency' DT property is also not available. In this case, instead of failing we should just skip baudrate config by returning zero. Signed-off-by: Atish Patra Signed-off-by: Anup Patel Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/11] drivers: serial_sifive: Fix baud rate calculation
On 01/17/2019 11:39 AM, Anup Patel wrote: From: Atish Patra Compute the baud rate multipler with more precision. Signed-off-by: Atish Patra Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/11] clk: Add fixed-factor clock driver
On 01/17/2019 11:39 AM, Anup Patel wrote:
This patch adds fixed-factor clock driver which derives clock
rate by dividing (div) and multiplying (mult) fixed factors
to a parent clock.
Signed-off-by: Anup Patel
Signed-off-by: Atish Patra
---
drivers/clk/Makefile | 4 +-
drivers/clk/clk_fixed_factor.c | 74 ++
2 files changed, 77 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/clk_fixed_factor.c
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 2f4446568c..fa59259ea3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -4,7 +4,9 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
#
-obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o clk_fixed_rate.o
+obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o
+obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o
+obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
obj-y += imx/
obj-y += tegra/
diff --git a/drivers/clk/clk_fixed_factor.c b/drivers/clk/clk_fixed_factor.c
new file mode 100644
index 00..eab1724c26
--- /dev/null
+++ b/drivers/clk/clk_fixed_factor.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Author: Anup Patel
+ */
+
+#include
+#include
+#include
+#include
+
+struct clk_fixed_factor {
+ struct clk parent;
+ unsigned int div;
+ unsigned int mult;
+};
+
+#define to_clk_fixed_factor(dev) \
+ ((struct clk_fixed_factor *)dev_get_platdata(dev))
+
+static ulong clk_fixed_factor_get_rate(struct clk *clk)
+{
+ int ret;
+ struct clk_fixed_factor *ff = to_clk_fixed_factor(clk->dev);
+
+ if (clk->id != 0)
+ return -EINVAL;
+
+ ret = clk_get_rate(>parent);
+ if (IS_ERR_VALUE(ret))
+ return ret;
+
+ do_div(ret, ff->div);
+
+ return ret * ff->mult;
+}
+
+const struct clk_ops clk_fixed_factor_ops = {
+ .get_rate = clk_fixed_factor_get_rate,
+};
+
+static int clk_fixed_factor_ofdata_to_platdata(struct udevice *dev)
+{
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
Why do you need this?
Alex
+ int err;
+ struct clk_fixed_factor *ff = to_clk_fixed_factor(dev);
+
+ err = clk_get_by_index(dev, 0, >parent);
+ if (err)
+ return err;
+
+ ff->div = dev_read_u32_default(dev, "clock-div", 1);
+ ff->mult = dev_read_u32_default(dev, "clock-mult", 1);
+#endif
+
+ return 0;
+}
+
+static const struct udevice_id clk_fixed_factor_match[] = {
+ {
+ .compatible = "fixed-factor-clock",
+ },
+ { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(clk_fixed_factor) = {
+ .name = "fixed_factor_clock",
+ .id = UCLASS_CLK,
+ .of_match = clk_fixed_factor_match,
+ .ofdata_to_platdata = clk_fixed_factor_ofdata_to_platdata,
+ .platdata_auto_alloc_size = sizeof(struct clk_fixed_factor),
+ .ops = _fixed_factor_ops,
+};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] clk: Add SiFive FU540 PRCI clock driver
On 01/17/2019 11:39 AM, Anup Patel wrote: Add driver code for the SiFive FU540 PRCI IP block. This IP block handles reset and clock control for the SiFive FU540 device and implements SoC-level clock tree controls and dividers. Based on code written by Wesley Terpstra found in commit 999529edf517ed75b56659d456d221b2ee56bb60 of: https://github.com/riscv/riscv-linux Boot and PLL rate change were tested on a SiFive HiFive Unleashed board. Signed-off-by: Paul Walmsley Signed-off-by: Atish Patra Signed-off-by: Anup Patel Can't say much about how the device works or whether this is in 100% compliance to the U-Boot clk framework, but I didn't see anything obviously wrong :). Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] net: macb: Fix GEM hardware detection
On 01/17/2019 11:38 AM, Anup Patel wrote: From: Atish Patra Fix MID bit field check to correctly identify all GEM hardwares. The check is updated as per macb driver in Linux location: /drivers/net/ethernet/cadence/macb_main.c:259 Signed-off-by: Atish Patra I found the respective Linux commit: 361918970b7426bba97a64678ef2b2679c37199b. Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [uboot-snps-arc] [PATCH v3 2/5] dts: switch spi-flash to jedec, spi-nor compatible
Hi Neil,
On Tue, 2019-01-15 at 13:59 +0100, Neil Armstrong wrote:
> There is no reason not to use the Linux "jedec,spi-nor" binding in U-Boot
> dts files. This compatible has been added in sf_probe, let use it.
>
> This patch switches to jedec,spi-nor when spi-flash is used in the DTS
> and DTSI files, and removed spi-flash when jedec,spi-nor is already
> present.
>
> The x86 dts are switched in a separate commit since it depends on a change
> in fdtdec.
>
> Signed-off-by: Neil Armstrong
> Acked-by: Stefan Roese
> Reviewed-by: Simon Goldschmidt
> ---
For the ARC part:
> arch/arc/dts/axs10x_mb.dtsi | 2 +-
> arch/arc/dts/hsdk.dts | 2 +-
Reviewed-by: Evgeniy Paltsev
> diff --git a/arch/arc/dts/axs10x_mb.dtsi b/arch/arc/dts/axs10x_mb.dtsi
> index dfc03810ca..b5aacd5170 100644
> --- a/arch/arc/dts/axs10x_mb.dtsi
> +++ b/arch/arc/dts/axs10x_mb.dtsi
> @@ -71,7 +71,7 @@
> clock-names = "spi_clk";
> cs-gpio = <_gpio 0>;
> spi_flash@0 {
> - compatible = "spi-flash";
> + compatible = "jedec,spi-nor";
> reg = <0>;
> spi-max-frequency = <400>;
> };
> diff --git a/arch/arc/dts/hsdk.dts b/arch/arc/dts/hsdk.dts
> index f024b96925..5e9ba054a4 100644
> --- a/arch/arc/dts/hsdk.dts
> +++ b/arch/arc/dts/hsdk.dts
> @@ -96,7 +96,7 @@
> clock-names = "spi_clk";
> cs-gpio = <_gpio 0>;
> spi_flash@0 {
> - compatible = "spi-flash";
> + compatible = "jedec,spi-nor";
> reg = <0>;
> spi-max-frequency = <400>;
> };
>
--
Eugeniy Paltsev
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/11] net: macb: Fix clk API usage for RISC-V systems
On 01/17/2019 11:38 AM, Anup Patel wrote: This patch does following fixes in MACB ethernet driver for using it on RISC-V systems (particularly QEMU sifive_u machine): 1. asm/arch/clk.h is not available on RISC-V port so include it only for non-RISC-V systems. 2. Don't fail in macb_enable_clk() if clk_enable() returns -ENOSYS because we get -ENOSYS for fixed-rate clocks. Signed-off-by: Anup Patel Reviewed-by: Bin Meng --- drivers/net/macb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 94c89c762b..9a06b523cc 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -38,7 +38,9 @@ #include #include #include +#ifndef CONFIG_RISCV #include +#endif #include #include "macb.h" @@ -1066,7 +1068,7 @@ static int macb_enable_clk(struct udevice *dev) */ #ifndef CONFIG_MACB_ZYNQ ret = clk_enable(); If clk.h is not available, who exports clk_enable() then; and why is the included needed in the first place? Alex - if (ret) + if (ret && ret != -ENOSYS) return ret; #endif ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems
On 01/17/2019 11:38 AM, Anup Patel wrote: On 64bit systems, the DRAM top can be easily beyond 4GB and U-Boot DMA mapping APIs will generate DMA addresses beyond 4GB. This breaks DMA programming in 32bit DMA capable devices (such as Cadence MACB ethernet). For example, If DRAM is more then 2GB on QEMU sifive_u machine then Cadence MACB ethernet stops working for U-Boot because it is a 32bit DMA capable device. To handle 32bit DMA capable devices on 64bit systems, we provide custom implementation of board_get_usable_ram_top() which ensures that usable ram top is not more then 4GB. This in-turn ensures that U-Boot always runs within 4GB hence DMA addresses generated by DMA mapping APIs will be within 4GB too. Signed-off-by: Anup Patel Signed-off-by: Atish Patra You could probably write that with MIN() more easily, but this way works fine too. Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/11] riscv: Add asm/dma-mapping.h for DMA mappings
On 01/17/2019 11:38 AM, Anup Patel wrote: This patch adds asm/dma-mapping.h for Linux-like DMA mappings APIs required by some of the drivers (such as, Cadance MACB Ethernet driver). Signed-off-by: Anup Patel Reviewed-by: Bin Meng Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] riscv: Rename cpu/qemu to cpu/generic
On 01/17/2019 11:38 AM, Anup Patel wrote: The QEMU CPU support under arch/riscv is pretty much generic and works fine for SiFive Unleashed as well. In fact, there will be quite a few RISC-V SOCs for which QEMU CPU support will work fine. This patch renames cpu/qemu to cpu/generic to indicate the above fact. If there are SOC specific errata workarounds required in cpu/generic then those can be done at runtime in cpu/generic based on CPU vendor specific DT compatible string. Signed-off-by: Anup Patel Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] Kconfig: Add u-boot.itb BUILD_TARGET for RK3368/3399
Add u-boot.itb BUILD_TARGET for Rockchip RK3368 and RK3399 SoC, this can get rid of building itb explicitly with 'make u-boot.itb' all required images will now build just by make. Signed-off-by: Jagan Teki --- Kconfig| 1 + board/rockchip/evb_rk3399/README | 1 - board/theobroma-systems/lion_rk3368/README | 9 ++--- board/theobroma-systems/puma_rk3399/README | 1 - board/vamrs/rock960_rk3399/README | 1 - 5 files changed, 3 insertions(+), 10 deletions(-) diff --git a/Kconfig b/Kconfig index 3a3a8d4d5b..247ace3ce0 100644 --- a/Kconfig +++ b/Kconfig @@ -230,6 +230,7 @@ config BUILD_TARGET default "u-boot-spl.kwb" if ARCH_MVEBU && SPL_BUILD default "u-boot-elf.srec" if RCAR_GEN3 default "u-boot.itb" if ARCH_SUNXI && ARM64 + default "u-boot.itb" if ROCKCHIP_RK3368 || ROCKCHIP_RK3399 help Some SoCs need special image types (e.g. U-Boot binary with a special header) as build targets. By defining diff --git a/board/rockchip/evb_rk3399/README b/board/rockchip/evb_rk3399/README index 8321467046..c388f269c1 100644 --- a/board/rockchip/evb_rk3399/README +++ b/board/rockchip/evb_rk3399/README @@ -58,7 +58,6 @@ Compile the U-Boot for firefly-rk3399, use below instead: > make firefly-rk3399_defconfig > make - > make u-boot.itb Get spl/u-boot-spl.bin and u-boot.itb in this step. diff --git a/board/theobroma-systems/lion_rk3368/README b/board/theobroma-systems/lion_rk3368/README index 83e4332984..241d4d9ec8 100644 --- a/board/theobroma-systems/lion_rk3368/README +++ b/board/theobroma-systems/lion_rk3368/README @@ -14,18 +14,13 @@ Configure U-Boot > cd ../u-boot > make lion-rk3368_defconfig -Build the TPL/SPL stage -=== +Build the TPL/SPL, U-Boot proper and a FIT image including the ATF +== > make CROSS_COMPILE=aarch64-unknown-elf- ARCH=arm > tools/mkimage -n rk3368 -T rksd -d tpl/u-boot-tpl.bin spl-3368.img > cat spl/u-boot-spl-dtb.bin >> spl-3368.img -Build the full U-Boot and a FIT image including the ATF -=== - - > make CROSS_COMPILE=aarch64-unknown-elf- ARCH=arm u-boot.itb - Flash the image === diff --git a/board/theobroma-systems/puma_rk3399/README b/board/theobroma-systems/puma_rk3399/README index f67dfb451f..c06c9650b8 100644 --- a/board/theobroma-systems/puma_rk3399/README +++ b/board/theobroma-systems/puma_rk3399/README @@ -60,7 +60,6 @@ Creating a SPL image for SD-Card/eMMC 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 === diff --git a/board/vamrs/rock960_rk3399/README b/board/vamrs/rock960_rk3399/README index d14399090e..c5c675c4ea 100644 --- a/board/vamrs/rock960_rk3399/README +++ b/board/vamrs/rock960_rk3399/README @@ -61,7 +61,6 @@ Compile the U-Boot > export CROSS_COMPILE=aarch64-linux-gnu- > make rock960-rk3399_defconfig > make - > make u-boot.itb Compile the rkdeveloptool = -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] Kconfig: Migrate CONFIG_BUILD_TARGET
Migrate CONFIG_BUILD_TARGET into Kconfig. Signed-off-by: Jagan Teki --- Kconfig | 13 + README| 7 --- arch/arm/mach-mvebu/include/mach/config.h | 5 - configs/SBx81LIFKW_defconfig | 1 + configs/SBx81LIFXCAT_defconfig| 1 + configs/dreamplug_defconfig | 1 + configs/ds109_defconfig | 1 + configs/guruplug_defconfig| 1 + configs/ib62x0_defconfig | 1 + configs/nsa310s_defconfig | 1 + configs/sheevaplug_defconfig | 1 + include/configs/SBx81LIFKW.h | 1 - include/configs/SBx81LIFXCAT.h| 1 - include/configs/ib62x0.h | 3 --- include/configs/mv-plug-common.h | 3 --- include/configs/nsa310s.h | 3 --- include/configs/rcar-gen3-common.h| 1 - include/configs/socfpga_common.h | 3 --- include/configs/sunxi-common.h| 1 - scripts/config_whitelist.txt | 1 - 20 files changed, 21 insertions(+), 29 deletions(-) diff --git a/Kconfig b/Kconfig index aff7b2e00a..3a3a8d4d5b 100644 --- a/Kconfig +++ b/Kconfig @@ -224,6 +224,19 @@ config BUILD_ROM which are not shipped in the U-Boot source tree. Please, see doc/README.x86 for details. +config BUILD_TARGET + string "Build target special images" + default "u-boot-with-spl.sfp" if ARCH_SOCFPGA + default "u-boot-spl.kwb" if ARCH_MVEBU && SPL_BUILD + default "u-boot-elf.srec" if RCAR_GEN3 + default "u-boot.itb" if ARCH_SUNXI && ARM64 + help + Some SoCs need special image types (e.g. U-Boot binary + with a special header) as build targets. By defining + CONFIG_BUILD_TARGET in the SoC / board header, this + special image will be automatically built upon calling + make / buildman. + endmenu# General setup menu "Boot images" diff --git a/README b/README index 17d56b8034..01ad69e926 100644 --- a/README +++ b/README @@ -1998,13 +1998,6 @@ The following options need to be configured: 200 ms. - Configuration Management: - CONFIG_BUILD_TARGET - - Some SoCs need special image types (e.g. U-Boot binary - with a special header) as build targets. By defining - CONFIG_BUILD_TARGET in the SoC / board header, this - special image will be automatically built upon calling - make / buildman. CONFIG_IDENT_STRING diff --git a/arch/arm/mach-mvebu/include/mach/config.h b/arch/arm/mach-mvebu/include/mach/config.h index f165d10018..e3235fc67e 100644 --- a/arch/arm/mach-mvebu/include/mach/config.h +++ b/arch/arm/mach-mvebu/include/mach/config.h @@ -40,11 +40,6 @@ #defineCONFIG_SYS_KWD_CONFIG arch/arm/mach-mvebu/kwbimage.cfg #endif /* CONFIG_SYS_KWD_CONFIG */ -/* Add target to build it automatically upon "make" */ -#ifdef CONFIG_SPL -#define CONFIG_BUILD_TARGET"u-boot-spl.kwb" -#endif - /* end of 16M scrubbed by training in bootrom */ #define CONFIG_SYS_INIT_SP_ADDR0x00FF diff --git a/configs/SBx81LIFKW_defconfig b/configs/SBx81LIFKW_defconfig index e0ce1595c5..52bb70ae8c 100644 --- a/configs/SBx81LIFKW_defconfig +++ b/configs/SBx81LIFKW_defconfig @@ -5,6 +5,7 @@ CONFIG_TARGET_SBx81LIFKW=y CONFIG_IDENT_STRING="\nSBx81LIFKW" # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 +CONFIG_BUILD_TARGET="u-boot.kwb" CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y CONFIG_MISC_INIT_R=y diff --git a/configs/SBx81LIFXCAT_defconfig b/configs/SBx81LIFXCAT_defconfig index 4a6e05844f..b322ab0959 100644 --- a/configs/SBx81LIFXCAT_defconfig +++ b/configs/SBx81LIFXCAT_defconfig @@ -5,6 +5,7 @@ CONFIG_TARGET_SBx81LIFXCAT=y CONFIG_IDENT_STRING="\nSBx81LIFXCAT" # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 +CONFIG_BUILD_TARGET="u-boot.kwb" CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y CONFIG_MISC_INIT_R=y diff --git a/configs/dreamplug_defconfig b/configs/dreamplug_defconfig index d3263cf9cd..762521f97d 100644 --- a/configs/dreamplug_defconfig +++ b/configs/dreamplug_defconfig @@ -6,6 +6,7 @@ CONFIG_IDENT_STRING="\nMarvell-DreamPlug" CONFIG_NR_DRAM_BANKS=2 # CONFIG_SYS_MALLOC_F is not set CONFIG_BOOTDELAY=3 +CONFIG_BUILD_TARGET="u-boot.kwb" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_HUSH_PARSER=y # CONFIG_CMD_FLASH is not set diff --git a/configs/ds109_defconfig b/configs/ds109_defconfig index 352403e573..b72174eada 100644 --- a/configs/ds109_defconfig +++ b/configs/ds109_defconfig @@ -5,6 +5,7 @@ CONFIG_TARGET_DS109=y CONFIG_NR_DRAM_BANKS=2 # CONFIG_SYS_MALLOC_F is not set CONFIG_HUSH_PARSER=y +CONFIG_BUILD_TARGET="u-boot.kwb" # CONFIG_CMD_FLASH is not set CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y diff --git a/configs/guruplug_defconfig b/configs/guruplug_defconfig index
[U-Boot] [PATCH v2 7/7] arm: dts: sunxi: Enumerate MMC2 as MMC1
Environment and fastboot MMC devices are configured based number
of mmc slots defined on particular board in sunxi platform.
If number of slots are not more than 1, it assigns 0 which usually mmc
device on SD slot. With DM_MMC it is detected as 0 since mmc0 node always
be an mmc device.
If number of slots are more than 1, it assigns 1 which assumes 0 is mmc
device and 1 is emmc device. But with DM_MMC there is chance of detecting
emmc as device 2 since mmc1 is SDIO as per devicetree definition.
So override mmc2 to mmc1 in sunxi dtsi, this will eventually detect mmc2
as mmc 1 device even if the board dts has mmc0, mmc1, mmc2.
Some platforms like A20 has mmc0...mmc3, but there is no usecases now for
enabling all mmc controllers in any of A20 board dts files.
Signed-off-by: Jagan Teki
---
arch/arm/dts/sunxi-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index 8a9f2a6417..fdd4c80aa4 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -1,6 +1,10 @@
#include
/ {
+ aliases {
+ mmc1 =
+ };
+
binman {
filename = "u-boot-sunxi-with-spl.bin";
pad-byte = <0xff>;
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] mmc: sunxi: Add DM_MMC support for H6
Unlike other Allwinner SoC's, H6 comes with different
clock and reset control offset values. So support them
via driver data.
Signed-off-by: Jagan Teki
---
.../arm/include/asm/arch-sunxi/clock_sun50i_h6.h | 3 +++
drivers/mmc/sunxi_mmc.c | 16
2 files changed, 19 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
index e36937059b..baf9b2e6e2 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
@@ -301,6 +301,9 @@ struct sunxi_ccm_reg {
#define DRAM_CLK_SRC_PLL5 (0 << 24)
#define DRAM_CLK_M(m) (((m)-1) << 0)
+/* MMC ahb clock bit field */
+#define AHB_GATE_OFFSET_MMC(n) ((n))
+
/* MMC clock bit field */
#define CCM_MMC_CTRL_M(x) ((x) - 1)
#define CCM_MMC_CTRL_N(x) ((x) << 8)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index b1c177bba3..5b9ac5f82c 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -697,6 +697,14 @@ static const struct sunxi_mmc_variant sun7i_a20_variant = {
.reset_start_bit = 8,
};
+static const struct sunxi_mmc_variant sun50i_h6_variant = {
+ .has_reset = true,
+ .gate_offset = 0x84c,
+ .mclk_offset = 0x830,
+ .reset_offset = 0x84c,
+ .reset_start_bit = 16,
+};
+
static const struct udevice_id sunxi_mmc_ids[] = {
{
.compatible = "allwinner,sun4i-a10-mmc",
@@ -722,6 +730,14 @@ static const struct udevice_id sunxi_mmc_ids[] = {
.compatible = "allwinner,sun50i-a64-emmc",
.data = (ulong)_a20_variant,
},
+ {
+ .compatible = "allwinner,sun50i-h6-mmc",
+ .data = (ulong)_h6_variant,
+ },
+ {
+ .compatible = "allwinner,sun50i-h6-emmc",
+ .data = (ulong)_h6_variant,
+ },
{ /* sentinel */ }
};
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/7] mmc: sunxi: Add mmc, emmc H5/A64 compatible
Added H5, A64 compatible for mmc and emmc.
Signed-off-by: Jagan Teki
---
drivers/mmc/sunxi_mmc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index c25967afd1..b1c177bba3 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -714,6 +714,14 @@ static const struct udevice_id sunxi_mmc_ids[] = {
.compatible = "allwinner,sun8i-a83t-emmc",
.data = (ulong)_a20_variant,
},
+ {
+ .compatible = "allwinner,sun50i-a64-mmc",
+ .data = (ulong)_a20_variant,
+ },
+ {
+ .compatible = "allwinner,sun50i-a64-emmc",
+ .data = (ulong)_a20_variant,
+ },
{ /* sentinel */ }
};
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/7] arm: sunxi: Enable DM_MMC
Enable DM_MMC for all Allwinner SoCs, this will eventually enable BLK. Also removed DM_MMC enablement in few parts of sunxi configurations. Signed-off-by: Jagan Teki --- arch/arm/Kconfig | 1 + arch/arm/mach-sunxi/Kconfig | 1 - configs/Linksprite_pcDuino3_defconfig | 1 - 3 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index a23cbd5719..075c3dfe81 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -851,6 +851,7 @@ config ARCH_SUNXI select DM_ETH select DM_GPIO select DM_KEYBOARD + select DM_MMC if MMC select DM_SERIAL select DM_USB if DISTRO_DEFAULTS select OF_BOARD_SETUP diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 3c54f5106d..74e234cded 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -154,7 +154,6 @@ config MACH_SUN4I bool "sun4i (Allwinner A10)" select CPU_V7A select ARM_CORTEX_CPU_IS_UP - select DM_MMC if MMC select DM_SCSI if SCSI select PHY_SUN4I_USB select DRAM_SUN4I diff --git a/configs/Linksprite_pcDuino3_defconfig b/configs/Linksprite_pcDuino3_defconfig index 9156f132d1..18f658e96b 100644 --- a/configs/Linksprite_pcDuino3_defconfig +++ b/configs/Linksprite_pcDuino3_defconfig @@ -14,7 +14,6 @@ CONFIG_SPL_I2C_SUPPORT=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-pcduino3" CONFIG_SCSI_AHCI=y -CONFIG_DM_MMC=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y CONFIG_SUN7I_GMAC=y -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/7] mmc: sunxi: Add DM_MMC support for A80
Unlike other Allwinner SoC's, A80 comes with different ahb
gate clock offset values and also has mmc common controller.
So support them via driver data.
Cc: Rask Ingemann Lambertsen
Signed-off-by: Jagan Teki
---
drivers/mmc/sunxi_mmc.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 5b9ac5f82c..7fab88c47f 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -22,6 +22,7 @@
#ifdef CONFIG_DM_MMC
struct sunxi_mmc_variant {
bool has_reset;
+ bool has_mmc_common;
u16 gate_offset;
u16 mclk_offset;
u16 reset_offset;
@@ -653,6 +654,19 @@ static int sunxi_mmc_probe(struct udevice *dev)
priv->variant->reset_start_bit));
}
+ if (priv->variant->has_mmc_common) {
+ u32 *mmc_config_clk, *mmc_common_base;
+
+ ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells",
0,
+ 0, );
+ if (ret)
+ return ret;
+ mmc_config_clk = (u32 *)ofnode_get_addr(args.node);
+
+ mmc_common_base = (void *)mmc_config_clk + (priv->mmc_no * 4);
+ setbits_le32(mmc_common_base, BIT(18) | BIT(16));
+ }
+
ret = mmc_set_mod_clk(priv, 2400);
if (ret)
return ret;
@@ -697,6 +711,12 @@ static const struct sunxi_mmc_variant sun7i_a20_variant = {
.reset_start_bit = 8,
};
+static const struct sunxi_mmc_variant sun9i_a80_variant = {
+ .has_mmc_common = true,
+ .gate_offset = 0x580,
+ .mclk_offset = 0x410,
+};
+
static const struct sunxi_mmc_variant sun50i_h6_variant = {
.has_reset = true,
.gate_offset = 0x84c,
@@ -722,6 +742,10 @@ static const struct udevice_id sunxi_mmc_ids[] = {
.compatible = "allwinner,sun8i-a83t-emmc",
.data = (ulong)_a20_variant,
},
+ {
+ .compatible = "allwinner,sun9i-a80-mmc",
+ .data = (ulong)_a80_variant,
+ },
{
.compatible = "allwinner,sun50i-a64-mmc",
.data = (ulong)_a20_variant,
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] mmc: sunxi: Configure reset support for DM_MMC
Start with Allwinner A31, mmc controllers do support reset
control bit. This code add support to enable the reset control
start from SUN6I even though it share same compatible between
SUN4I and SUN6I.
Signed-off-by: Jagan Teki
---
drivers/mmc/sunxi_mmc.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 302332bf97..0e53701c5b 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -21,8 +21,11 @@
#ifdef CONFIG_DM_MMC
struct sunxi_mmc_variant {
+ bool has_reset;
u16 gate_offset;
u16 mclk_offset;
+ u16 reset_offset;
+ u8 reset_start_bit;
};
#endif
@@ -609,7 +612,7 @@ static int sunxi_mmc_probe(struct udevice *dev)
struct sunxi_mmc_priv *priv = dev_get_priv(dev);
struct mmc_config *cfg = >cfg;
struct ofnode_phandle_args args;
- u32 *gate_reg, *ccu_reg;
+ u32 *gate_reg, *reset_reg, *ccu_reg;
int bus_width, ret;
cfg->name = dev->name;
@@ -644,6 +647,12 @@ static int sunxi_mmc_probe(struct udevice *dev)
gate_reg = (void *)ccu_reg + priv->variant->gate_offset;
setbits_le32(gate_reg, BIT(AHB_GATE_OFFSET_MMC(priv->mmc_no)));
+ if ((!IS_ENABLED(CONFIG_MACH_SUN7I)) && priv->variant->has_reset) {
+ reset_reg = (void *)ccu_reg + priv->variant->reset_offset;
+ setbits_le32(reset_reg, BIT(priv->mmc_no +
+priv->variant->reset_start_bit));
+ }
+
ret = mmc_set_mod_clk(priv, 2400);
if (ret)
return ret;
@@ -680,6 +689,14 @@ static const struct sunxi_mmc_variant sun4i_a10_variant = {
.mclk_offset = 0x88,
};
+static const struct sunxi_mmc_variant sun7i_a20_variant = {
+ .has_reset = true,
+ .gate_offset = 0x60,
+ .mclk_offset = 0x88,
+ .reset_offset = 0x2c0,
+ .reset_start_bit = 8,
+};
+
static const struct udevice_id sunxi_mmc_ids[] = {
{
.compatible = "allwinner,sun4i-a10-mmc",
@@ -691,7 +708,7 @@ static const struct udevice_id sunxi_mmc_ids[] = {
},
{
.compatible = "allwinner,sun7i-a20-mmc",
- .data = (ulong)_a10_variant,
+ .data = (ulong)_a20_variant,
},
{ /* sentinel */ }
};
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] mmc: sunxi: Add A83T emmc compatible
Add emmc compatible for A83T SoC.
Signed-off-by: Jagan Teki
---
drivers/mmc/sunxi_mmc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 0e53701c5b..c25967afd1 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -710,6 +710,10 @@ static const struct udevice_id sunxi_mmc_ids[] = {
.compatible = "allwinner,sun7i-a20-mmc",
.data = (ulong)_a20_variant,
},
+ {
+ .compatible = "allwinner,sun8i-a83t-emmc",
+ .data = (ulong)_a20_variant,
+ },
{ /* sentinel */ }
};
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC
V2 for previous version[1] changes, for enabling DM_MMC on Allwinner platform. Changes for v2: - update the 'reset enablement' logic to do required SoC's Note: All changes available at u-boot-sunxi/next [1] https://patchwork.ozlabs.org/cover/1023710/ Any comments? Jagan. Jagan Teki (7): mmc: sunxi: Configure reset support for DM_MMC mmc: sunxi: Add A83T emmc compatible mmc: sunxi: Add mmc, emmc H5/A64 compatible mmc: sunxi: Add DM_MMC support for H6 mmc: sunxi: Add DM_MMC support for A80 arm: sunxi: Enable DM_MMC arm: dts: sunxi: Enumerate MMC2 as MMC1 arch/arm/Kconfig | 1 + arch/arm/dts/sunxi-u-boot.dtsi| 4 + .../include/asm/arch-sunxi/clock_sun50i_h6.h | 3 + arch/arm/mach-sunxi/Kconfig | 1 - configs/Linksprite_pcDuino3_defconfig | 1 - drivers/mmc/sunxi_mmc.c | 73 ++- 6 files changed, 79 insertions(+), 4 deletions(-) -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] mmc: mtk-sd: fix SPL compilation when GPIO=y and SPL_GPIO=n
It is not possible to link the SPL image when CONFIG_GPIO is enabled
but CONFIG_SPL_GPIO is not. Use the IS_ENABLED macro instead to
correctly check whether CONFIG_{SPL_}GPIO is enabled.
This commit fixes the following errors:
* undefined reference to `dm_gpio_get_value
* undefined reference to `gpio_request_by_name'
Signed-off-by: Fabien Parent
---
drivers/mmc/mtk-sd.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
index e668df7017..4c997977d7 100644
--- a/drivers/mmc/mtk-sd.c
+++ b/drivers/mmc/mtk-sd.c
@@ -269,7 +269,7 @@ struct msdc_host {
bool builtin_cd;
/* card detection / write protection GPIOs */
-#ifdef CONFIG_DM_GPIO
+#if IS_ENABLED(DM_GPIO)
struct gpio_desc gpio_wp;
struct gpio_desc gpio_cd;
#endif
@@ -849,7 +849,7 @@ static int msdc_ops_get_cd(struct udevice *dev)
return !(val & MSDC_PS_CDSTS);
}
-#ifdef CONFIG_DM_GPIO
+#if IS_ENABLED(DM_GPIO)
if (!host->gpio_cd.dev)
return 1;
@@ -863,7 +863,7 @@ static int msdc_ops_get_wp(struct udevice *dev)
{
struct msdc_host *host = dev_get_priv(dev);
-#ifdef CONFIG_DM_GPIO
+#if IS_ENABLED(DM_GPIO)
if (!host->gpio_wp.dev)
return 0;
@@ -1332,7 +1332,7 @@ static int msdc_ofdata_to_platdata(struct udevice *dev)
if (ret < 0)
return ret;
-#ifdef CONFIG_DM_GPIO
+#if IS_ENABLED(DM_GPIO)
gpio_request_by_name(dev, "wp-gpios", 0, >gpio_wp, GPIOD_IS_IN);
gpio_request_by_name(dev, "cd-gpios", 0, >gpio_cd, GPIOD_IS_IN);
#endif
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] mmc: mtk-sd: fix possible incomplete read ops
The code is checking for incomplete read when it see the INT_XFER_COMPL
flag, but it forget to first check whether there is anything left in the
FIFO to copy to the RX buffer. This means that sometimes we will get
errors because of erroneous incomplete read operation.
This commit fixes the driver re-ordering the code so that we first
check for data inside the RX fifo and only after check the status
of the INT_XFER_COMPL flag.
Signed-off-by: Fabien Parent
---
drivers/mmc/mtk-sd.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
index 0741a525c0..e668df7017 100644
--- a/drivers/mmc/mtk-sd.c
+++ b/drivers/mmc/mtk-sd.c
@@ -554,6 +554,14 @@ static int msdc_pio_read(struct msdc_host *host, u8 *ptr,
u32 size)
break;
}
+ chksz = min(size, (u32)MSDC_FIFO_SIZE);
+
+ if (msdc_fifo_rx_bytes(host) >= chksz) {
+ msdc_fifo_read(host, ptr, chksz);
+ ptr += chksz;
+ size -= chksz;
+ }
+
if (status & MSDC_INT_XFER_COMPL) {
if (size) {
pr_err("data not fully read\n");
@@ -562,15 +570,7 @@ static int msdc_pio_read(struct msdc_host *host, u8 *ptr,
u32 size)
break;
}
-
- chksz = min(size, (u32)MSDC_FIFO_SIZE);
-
- if (msdc_fifo_rx_bytes(host) >= chksz) {
- msdc_fifo_read(host, ptr, chksz);
- ptr += chksz;
- size -= chksz;
- }
- }
+}
return ret;
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/11] riscv: Add SiFive FU540 board support
So I take it I could use my version of U-boot to load BBL,
then your S-mode U-boot?
I've been holding off on refactoring or submitting anything
from the MicroSemi U-boot that runs in M-mode and inits the
DRAM until I have some decent method to regression test the
whole system (bootloader, kernel, userspace). I also want
to make sure we don't break any other RiscV platforms when
we add new code.
It looks HiFive unleashed boards are available for purchase
again, is there any place to get an AndesTech board?
(fyi, the *proof of concept* hacks for regression testing
that work for me based on MicroSemi patches are at
https://github.com/tmagik/freedom-u-sdk/tree/regression/kernel4.15 )
On Thu, Jan 17, 2019 at 10:39:27AM +, Anup Patel wrote:
> This patch adds SiFive FU540 board support. For now, only
> SiFive serial, SiFive PRCI, and Cadance MACB drivers are
> only enabled. The SiFive FU540 defconfig by default builds
> U-Boot for S-Mode because U-Boot on SiFive FU540 will run
> in S-Mode as payload of BBL or OpenSBI.
>
> Signed-off-by: Anup Patel
> Signed-off-by: Atish Patra
> ---
> arch/riscv/Kconfig | 4
> board/sifive/fu540/Kconfig | 42 +
> board/sifive/fu540/MAINTAINERS | 9 +++
> board/sifive/fu540/Makefile| 5
> board/sifive/fu540/fu540.c | 17 ++
> configs/sifive_fu540_defconfig | 11 +
> include/configs/sifive-fu540.h | 43 ++
> 7 files changed, 131 insertions(+)
> create mode 100644 board/sifive/fu540/Kconfig
> create mode 100644 board/sifive/fu540/MAINTAINERS
> create mode 100644 board/sifive/fu540/Makefile
> create mode 100644 board/sifive/fu540/fu540.c
> create mode 100644 configs/sifive_fu540_defconfig
> create mode 100644 include/configs/sifive-fu540.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 6879047ff7..36512a8995 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -14,11 +14,15 @@ config TARGET_AX25_AE350
> config TARGET_QEMU_VIRT
> bool "Support QEMU Virt Board"
>
> +config TARGET_SIFIVE_FU540
> + bool "Support SiFive FU540 Board"
> +
> endchoice
>
> # board-specific options below
> source "board/AndesTech/ax25-ae350/Kconfig"
> source "board/emulation/qemu-riscv/Kconfig"
> +source "board/sifive/fu540/Kconfig"
>
> # platform-specific options below
> source "arch/riscv/cpu/ax25/Kconfig"
> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
> new file mode 100644
> index 00..6be3d88144
> --- /dev/null
> +++ b/board/sifive/fu540/Kconfig
> @@ -0,0 +1,42 @@
> +if TARGET_SIFIVE_FU540
> +
> +config SYS_BOARD
> + default "fu540"
> +
> +config SYS_VENDOR
> + default "sifive"
> +
> +config SYS_CPU
> + default "generic"
> +
> +config SYS_CONFIG_NAME
> + default "sifive-fu540"
> +
> +config SYS_TEXT_BASE
> + default 0x8000 if !RISCV_SMODE
> + default 0x8020 if RISCV_SMODE
> +
> +config BOARD_SPECIFIC_OPTIONS # dummy
> + def_bool y
> + select GENERIC_RISCV
> + imply CMD_DHCP
> + imply CMD_EXT2
> + imply CMD_EXT4
> + imply CMD_FAT
> + imply CMD_FS_GENERIC
> + imply CMD_NET
> + imply CMD_PING
> + imply CLK_SIFIVE
> + imply CLK_SIFIVE_FU540_PRCI
> + imply DOS_PARTITION
> + imply EFI_PARTITION
> + imply IP_DYN
> + imply ISO_PARTITION
> + imply MACB
> + imply MII
> + imply NET_RANDOM_ETHADDR
> + imply PHY_LIB
> + imply PHY_MSCC
> + imply SIFIVE_SERIAL
> +
> +endif
> diff --git a/board/sifive/fu540/MAINTAINERS b/board/sifive/fu540/MAINTAINERS
> new file mode 100644
> index 00..702d803ad8
> --- /dev/null
> +++ b/board/sifive/fu540/MAINTAINERS
> @@ -0,0 +1,9 @@
> +SiFive FU540 BOARD
> +M: Paul Walmsley
> +M: Palmer Dabbelt
> +M: Anup Patel
> +M: Atish Patra
> +S: Maintained
> +F: board/sifive/fu540/
> +F: include/configs/sifive-fu540.h
> +F: configs/sifive_fu540_defconfig
> diff --git a/board/sifive/fu540/Makefile b/board/sifive/fu540/Makefile
> new file mode 100644
> index 00..6e1862c475
> --- /dev/null
> +++ b/board/sifive/fu540/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (c) 2019 Western Digital Corporation or its affiliates.
> +
> +obj-y+= fu540.o
> diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
> new file mode 100644
> index 00..5adc4a3d4a
> --- /dev/null
> +++ b/board/sifive/fu540/fu540.c
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + *
> + * Authors:
> + * Anup Patel
> + */
> +
> +#include
> +#include
> +
> +int board_init(void)
> +{
> + /* For now nothing to do here. */
> +
> + return 0;
> +}
> diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
> new file mode 100644
> index 00..2f8cca9de0
> --- /dev/null
> +++
Re: [U-Boot] [PATCH v2 7/9] actions:s700: add u-boot specific dts file
On Mon, Jan 14, 2019 at 06:11:09PM +0530, Amit Singh Tomar wrote:
> Devices like uart and clk are needed to be enabled before relocation.
> this patch adds u-boot.dtsi file that mark these device as dm-pre-reloc.
>
> Signed-off-by: Amit Singh Tomar
> ---
> Changes since v1:
> * This is newly added file that was *not* present in v1 and
> contains u-boot specific changes.
> ---
> arch/arm/dts/s700-u-boot.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
> create mode 100644 arch/arm/dts/s700-u-boot.dtsi
>
> diff --git a/arch/arm/dts/s700-u-boot.dtsi b/arch/arm/dts/s700-u-boot.dtsi
> new file mode 100644
> index 000..46e98de
> --- /dev/null
> +++ b/arch/arm/dts/s700-u-boot.dtsi
> @@ -0,0 +1,14 @@
> +/{
Missing License and description.
Regards,
Mani
> + soc {
> + u-boot,dm-pre-reloc;
> + };
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/9] arm: add support Actions Semi S700
On Mon, Jan 14, 2019 at 06:11:06PM +0530, Amit Singh Tomar wrote: > This patch adds basic support for Actions Semi based S700 > SoC, which is driven by common owl framework. > > Signed-off-by: Amit Singh Tomar > --- > Changes since v1: > * S700 specific changes are factored out here > from patch 1 of 9. > --- > arch/arm/mach-owl/Kconfig | 6 ++ > include/configs/s700.h| 15 +++ > 2 files changed, 21 insertions(+) > create mode 100644 include/configs/s700.h > > diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig > index 5eb93c9..d05cc68 100644 > --- a/arch/arm/mach-owl/Kconfig > +++ b/arch/arm/mach-owl/Kconfig > @@ -8,13 +8,19 @@ config MACH_S900 > bool "Actionss Semi S900" > select ARM64 > > +config MACH_S700 > +bool "Actions Semi S700" > +select ARM64 > + > endchoice > > config SYS_CONFIG_NAME > default "s900" if MACH_S900 > +default "s700" if MACH_S700 > > config SYS_SOC > default "s900" if MACH_S900 > +default "s700" if MACH_S700 > > config SYS_TEXT_BASE > default 0x1100 > diff --git a/include/configs/s700.h b/include/configs/s700.h > new file mode 100644 > index 000..84f9174 > --- /dev/null > +++ b/include/configs/s700.h > @@ -0,0 +1,15 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Board configuration file for Action semi s700 Please be consistent with naming conventions... Actions Semi S700 SoC. Thanks, Mani > + * > + */ > + > +#ifndef _CONFIG_S700_H_ > +#define _CONFIG_S700_H_ > + > +/* > + * Include common owl configuration where most the settings are > + */ > +#include > + > +#endif > -- > 2.7.4 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] arm: add Cubieboard7 board support
On Mon, Jan 14, 2019 at 06:11:08PM +0530, Amit Singh Tomar wrote:
> The Cubieboard is a single board computer containing a
> Actions S700 SoC(with 4 ARMv8 Cortex-A53 cores).
>
> This patch adds respective defconfig alongwith device tree(sync with
> Linux 4.20).
>
> Signed-off-by: Amit Singh Tomar
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> Changes since v1:
> * No changes.
> ---
> arch/arm/dts/s700-cubieboard7.dts | 39
> +++
> configs/cubieboard7_defconfig | 16
> 2 files changed, 55 insertions(+)
> create mode 100644 arch/arm/dts/s700-cubieboard7.dts
> create mode 100644 configs/cubieboard7_defconfig
>
> diff --git a/arch/arm/dts/s700-cubieboard7.dts
> b/arch/arm/dts/s700-cubieboard7.dts
> new file mode 100644
> index 000..28f3f4a
> --- /dev/null
> +++ b/arch/arm/dts/s700-cubieboard7.dts
> @@ -0,0 +1,39 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 Andreas Färber
> + */
> +
> +/dts-v1/;
> +
> +#include "s700.dtsi"
> +
> +/ {
> + compatible = "cubietech,cubieboard7", "actions,s700";
> + model = "CubieBoard7";
> +
> + aliases {
> + serial3 =
> + };
> +
> + chosen {
> + stdout-path = "serial3:115200n8";
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x8000>;
> + };
> +
> + memory@1,e000 {
> + device_type = "memory";
> + reg = <0x1 0xe000 0x0 0x0>;
> + };
> +};
> +
> + {
> + clocks = <>;
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/configs/cubieboard7_defconfig b/configs/cubieboard7_defconfig
> new file mode 100644
> index 000..0459997
> --- /dev/null
> +++ b/configs/cubieboard7_defconfig
> @@ -0,0 +1,16 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_OWL=y
> +CONFIG_MACH_S700=y
> +CONFIG_IDENT_STRING="\ncubieboard7"
> +CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_BOOTDELAY=5
> +CONFIG_USE_BOOTARGS=y
> +CONFIG_BOOTARGS="console=ttyOWL3,115200n8"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +# CONFIG_DISPLAY_BOARDINFO is not set
> +CONFIG_SYS_PROMPT="U-Boot => "
> +CONFIG_CMD_MD5SUM=y
> +CONFIG_CMD_MEMINFO=y
> +CONFIG_CMD_TIMER=y
> +CONFIG_DEFAULT_DEVICE_TREE="s700-cubieboard7"
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] arm: add Cubieboard7 board support
On Mon, Jan 14, 2019 at 10:57:47PM +, André Przywara wrote:
> On 14/01/2019 12:41, Amit Singh Tomar wrote:
> > The Cubieboard is a single board computer containing a
> > Actions S700 SoC(with 4 ARMv8 Cortex-A53 cores).
> >
> > This patch adds respective defconfig alongwith device tree(sync with
> > Linux 4.20).
>
> This should come later in the series, as patch 8/9, just _after_
> everything works. It compiles at this point, but you still need the next
> two patches for it to work.
>
Usually, DTS patches comes before driver bits.
Regards,
Mani
> The _defconfig is still a bit too crowded, but so is the S900 version, so:
>
> > Signed-off-by: Amit Singh Tomar
>
> Reviewed-by: Andre Przywara
>
> Cheers,
> Andre.
>
> > ---
> > Changes since v1:
> > * No changes.
> > ---
> > arch/arm/dts/s700-cubieboard7.dts | 39
> > +++
> > configs/cubieboard7_defconfig | 16
> > 2 files changed, 55 insertions(+)
> > create mode 100644 arch/arm/dts/s700-cubieboard7.dts
> > create mode 100644 configs/cubieboard7_defconfig
> >
> > diff --git a/arch/arm/dts/s700-cubieboard7.dts
> > b/arch/arm/dts/s700-cubieboard7.dts
> > new file mode 100644
> > index 000..28f3f4a
> > --- /dev/null
> > +++ b/arch/arm/dts/s700-cubieboard7.dts
> > @@ -0,0 +1,39 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright (c) 2017 Andreas Färber
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "s700.dtsi"
> > +
> > +/ {
> > + compatible = "cubietech,cubieboard7", "actions,s700";
> > + model = "CubieBoard7";
> > +
> > + aliases {
> > + serial3 =
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial3:115200n8";
> > + };
> > +
> > + memory@0 {
> > + device_type = "memory";
> > + reg = <0x0 0x0 0x0 0x8000>;
> > + };
> > +
> > + memory@1,e000 {
> > + device_type = "memory";
> > + reg = <0x1 0xe000 0x0 0x0>;
> > + };
> > +};
> > +
> > + {
> > + clocks = <>;
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > diff --git a/configs/cubieboard7_defconfig b/configs/cubieboard7_defconfig
> > new file mode 100644
> > index 000..0459997
> > --- /dev/null
> > +++ b/configs/cubieboard7_defconfig
> > @@ -0,0 +1,16 @@
> > +CONFIG_ARM=y
> > +CONFIG_ARCH_OWL=y
> > +CONFIG_MACH_S700=y
> > +CONFIG_IDENT_STRING="\ncubieboard7"
> > +CONFIG_DISTRO_DEFAULTS=y
> > +CONFIG_NR_DRAM_BANKS=1
> > +CONFIG_BOOTDELAY=5
> > +CONFIG_USE_BOOTARGS=y
> > +CONFIG_BOOTARGS="console=ttyOWL3,115200n8"
> > +# CONFIG_DISPLAY_CPUINFO is not set
> > +# CONFIG_DISPLAY_BOARDINFO is not set
> > +CONFIG_SYS_PROMPT="U-Boot => "
> > +CONFIG_CMD_MD5SUM=y
> > +CONFIG_CMD_MEMINFO=y
> > +CONFIG_CMD_TIMER=y
> > +CONFIG_DEFAULT_DEVICE_TREE="s700-cubieboard7"
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] arm: actions: Add owl memory map regions
On Mon, Jan 14, 2019 at 06:11:04PM +0530, Amit Singh Tomar wrote:
> This adds memory regions needed to setup MMU for actions
> S900 and S700 SoCs.
>
> Signed-off-by: Amit Singh Tomar
> ---
> Changes since v1:
> * compile sysmap-owl.c against CONFIG_ARM64 now.
> ---
> arch/arm/mach-owl/Makefile | 3 ++-
> arch/arm/mach-owl/sysmap-owl.c | 32
> arch/arm/mach-owl/sysmap-s900.c | 32
> 3 files changed, 34 insertions(+), 33 deletions(-)
> create mode 100644 arch/arm/mach-owl/sysmap-owl.c
> delete mode 100644 arch/arm/mach-owl/sysmap-s900.c
>
> diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
> index 0b181c6..b17fc14 100644
> --- a/arch/arm/mach-owl/Makefile
> +++ b/arch/arm/mach-owl/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0+
>
> obj-y += soc.o
> -obj-y += sysmap-s900.o
> +obj-$(CONFIG_ARM64) += sysmap-owl.o
> +
> diff --git a/arch/arm/mach-owl/sysmap-owl.c b/arch/arm/mach-owl/sysmap-owl.c
> new file mode 100644
> index 000..9d30759
> --- /dev/null
> +++ b/arch/arm/mach-owl/sysmap-owl.c
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Memory map for Actions Semi S900/S700 based SoCs.
Actions Semi Owl series SoCs?
With this,
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> + *
> + * Copyright (C) 2015 Actions Semi Co., Ltd.
> + * Copyright (C) 2018 Manivannan Sadhasivam
>
> + */
> +
> +#include
> +#include
> +
> +static struct mm_region owl_mem_map[] = {
> + {
> + .virt = 0x0UL, /* DDR */
> + .phys = 0x0UL, /* DDR */
> + .size = 0x8000UL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> + PTE_BLOCK_INNER_SHARE
> + }, {
> + .virt = 0xE000UL, /* Peripheral block */
> + .phys = 0xE000UL, /* Peripheral block */
> + .size = 0x0800UL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* List terminator */
> + 0,
> + }
> +};
> +
> +struct mm_region *mem_map = owl_mem_map;
> diff --git a/arch/arm/mach-owl/sysmap-s900.c b/arch/arm/mach-owl/sysmap-s900.c
> deleted file mode 100644
> index f78b639..000
> --- a/arch/arm/mach-owl/sysmap-s900.c
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Actions Semi S900 Memory map
> - *
> - * Copyright (C) 2015 Actions Semi Co., Ltd.
> - * Copyright (C) 2018 Manivannan Sadhasivam
>
> - */
> -
> -#include
> -#include
> -
> -static struct mm_region s900_mem_map[] = {
> - {
> - .virt = 0x0UL, /* DDR */
> - .phys = 0x0UL, /* DDR */
> - .size = 0x8000UL,
> - .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> - PTE_BLOCK_INNER_SHARE
> - }, {
> - .virt = 0xE000UL, /* Peripheral block */
> - .phys = 0xE000UL, /* Peripheral block */
> - .size = 0x0800UL,
> - .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> - PTE_BLOCK_NON_SHARE |
> - PTE_BLOCK_PXN | PTE_BLOCK_UXN
> - }, {
> - /* List terminator */
> - 0,
> - }
> -};
> -
> -struct mm_region *mem_map = s900_mem_map;
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] net: add MSCC Ocelot switch support
This patch adds support for the Microsemi Ethernet switch present on Ocelot SoCs. Signed-off-by: Gregory CLEMENT --- MAINTAINERS | 1 + drivers/net/Kconfig | 7 + drivers/net/Makefile| 1 + drivers/net/ocelot_switch.c | 765 4 files changed, 774 insertions(+) create mode 100644 drivers/net/ocelot_switch.c diff --git a/MAINTAINERS b/MAINTAINERS index 3fa5d3e96f..af44e19eae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -529,6 +529,7 @@ F: drivers/gpio/mscc_sgpio.c F: drivers/spi/mscc_bb_spi.c F: include/configs/vcoreiii.h F: drivers/pinctrl/mscc/ +F: drivers/net/ocelot_switch.c MIPS JZ4780 M: Ezequiel Garcia diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 7044c6adf3..10ac15cc6c 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -432,6 +432,13 @@ config SNI_AVE This driver implements support for the Socionext AVE Ethernet controller, as found on the Socionext UniPhier family. +config MSCC_OCELOT_SWITCH + bool "Ocelot switch driver" + depends on DM_ETH && ARCH_MSCC + select PHYLIB + help + This driver supports the Ocelot network switch device. + config ETHER_ON_FEC1 bool "FEC1" depends on MPC8XX_FEC diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 0dbfa03306..bd108c21d1 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -74,3 +74,4 @@ obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o obj-$(CONFIG_FSL_PFE) += pfe_eth/ obj-$(CONFIG_SNI_AVE) += sni_ave.o obj-y += ti/ +obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o diff --git a/drivers/net/ocelot_switch.c b/drivers/net/ocelot_switch.c new file mode 100644 index 00..9fed26cd94 --- /dev/null +++ b/drivers/net/ocelot_switch.c @@ -0,0 +1,765 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (c) 2018 Microsemi Corporation + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define MIIM_STATUS0x0 +#defineMIIM_STAT_BUSY BIT(3) +#define MIIM_CMD 0x8 +#defineMIIM_CMD_SCAN BIT(0) +#defineMIIM_CMD_OPR_WRITE BIT(1) +#defineMIIM_CMD_OPR_READ BIT(2) +#defineMIIM_CMD_SINGLE_SCANBIT(3) +#defineMIIM_CMD_WRDATA(x) ((x) << 4) +#defineMIIM_CMD_REGAD(x) ((x) << 20) +#defineMIIM_CMD_PHYAD(x) ((x) << 25) +#defineMIIM_CMD_VLDBIT(31) +#define MIIM_DATA 0xC +#defineMIIM_DATA_ERROR (0x2 << 16) + +#define PHY_CFG0x0 +#define PHY_CFG_ENA0xF +#define PHY_CFG_COMMON_RST BIT(4) +#define PHY_CFG_RST(0xF << 5) +#define PHY_STAT 0x4 +#define PHY_STAT_SUPERVISOR_COMPLETE BIT(0) + +#define ANA_PORT_VLAN_CFG(x) (0x7000 + 0x100 * (x)) +#defineANA_PORT_VLAN_CFG_AWARE_ENA BIT(20) +#defineANA_PORT_VLAN_CFG_POP_CNT(x)((x) << 18) +#define ANA_PORT_PORT_CFG(x) (0x7070 + 0x100 * (x)) +#defineANA_PORT_PORT_CFG_RECV_ENA BIT(6) +#defineANA_TABLES_MACHDATA 0x8b34 +#defineANA_TABLES_MACLDATA 0x8b38 +#define ANA_TABLES_MACACCESS 0x8b3c +#defineANA_TABLES_MACACCESS_VALID BIT(11) +#defineANA_TABLES_MACACCESS_ENTRYTYPE(x) ((x) << 9) +#defineANA_TABLES_MACACCESS_DEST_IDX(x)((x) << 3) +#defineANA_TABLES_MACACCESS_MAC_TABLE_CMD(x) (x) +#defineANA_TABLES_MACACCESS_MAC_TABLE_CMD_MGENMASK(2, 0) +#defineMACACCESS_CMD_IDLE 0 +#defineMACACCESS_CMD_LEARN1 +#defineMACACCESS_CMD_GET_NEXT 4 +#define ANA_PGID(x)(0x8c00 + 4 * (x)) + +#define SYS_FRM_AGING 0x574 +#defineSYS_FRM_AGING_ENA BIT(20) + +#define SYS_SYSTEM_RST_CFG 0x508 +#defineSYS_SYSTEM_RST_MEM_INIT BIT(0) +#defineSYS_SYSTEM_RST_MEM_ENA BIT(1) +#defineSYS_SYSTEM_RST_CORE_ENA BIT(2) +#define SYS_PORT_MODE(x) (0x514 + 0x4 * (x)) +#defineSYS_PORT_MODE_INCL_INJ_HDR(x) ((x) << 3) +#defineSYS_PORT_MODE_INCL_INJ_HDR_MGENMASK(4, 3) +#defineSYS_PORT_MODE_INCL_XTR_HDR(x) ((x) << 1) +#defineSYS_PORT_MODE_INCL_XTR_HDR_MGENMASK(2, 1) +#defineSYS_PAUSE_CFG(x)(0x608 + 0x4 * (x)) +#defineSYS_PAUSE_CFG_PAUSE_ENA
[U-Boot] [PATCH v3 3/4] MIPS: mscc: ocelot: add switch reset support
On some ocelots platform a workaround is needed in order to be able to
reset the switch without resetting the DDR.
Signed-off-by: Gregory CLEMENT
---
board/mscc/ocelot/ocelot.c | 24
1 file changed, 24 insertions(+)
diff --git a/board/mscc/ocelot/ocelot.c b/board/mscc/ocelot/ocelot.c
index 0f7a532158..532d06f000 100644
--- a/board/mscc/ocelot/ocelot.c
+++ b/board/mscc/ocelot/ocelot.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -18,6 +19,29 @@ enum {
BOARD_TYPE_PCB123,
};
+void mscc_switch_reset(bool enter)
+{
+ /* Nasty workaround to avoid GPIO19 (DDR!) being reset */
+ mscc_gpio_set_alternate(19, 2);
+
+ debug("applying SwC reset\n");
+
+ writel(ICPU_RESET_CORE_RST_PROTECT, BASE_CFG + ICPU_RESET);
+ writel(PERF_SOFT_RST_SOFT_CHIP_RST, BASE_DEVCPU_GCB + PERF_SOFT_RST);
+
+ if (wait_for_bit_le32(BASE_DEVCPU_GCB + PERF_SOFT_RST,
+ PERF_SOFT_RST_SOFT_CHIP_RST, false, 5000, false))
+ pr_err("Tiemout while waiting for switch reset\n");
+
+ /*
+* Reset GPIO19 mode back as regular GPIO, output, high (DDR
+* not reset) (Order is important)
+*/
+ setbits_le32(BASE_DEVCPU_GCB + PERF_GPIO_OE, BIT(19));
+ writel(BIT(19), BASE_DEVCPU_GCB + PERF_GPIO_OUT_SET);
+ mscc_gpio_set_alternate(19, 0);
+}
+
void board_debug_uart_init(void)
{
/* too early for the pinctrl driver, so configure the UART pins here */
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] configs: mscc_ocelot: add network support
Now that network support is added for the ocelot platform, let's add it in the default configuration. Signed-off-by: Gregory CLEMENT --- configs/mscc_ocelot_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/mscc_ocelot_defconfig b/configs/mscc_ocelot_defconfig index fb6a5bdc31..792d00e646 100644 --- a/configs/mscc_ocelot_defconfig +++ b/configs/mscc_ocelot_defconfig @@ -60,6 +60,7 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_SPI_FLASH_MTD=y CONFIG_DM_ETH=y +CONFIG_MSCC_OCELOT_SWITCH=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_DM_SERIAL=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] MIPS: mscc: ocelot: Add ethernet nodes for Ocelot
Import Ethernet related nodes from Linux
Signed-off-by: Gregory CLEMENT
---
arch/mips/dts/mscc,ocelot.dtsi | 97 +
arch/mips/dts/ocelot_pcb123.dts | 20 +++
2 files changed, 117 insertions(+)
diff --git a/arch/mips/dts/mscc,ocelot.dtsi b/arch/mips/dts/mscc,ocelot.dtsi
index 2592003103..4f3fe356c4 100644
--- a/arch/mips/dts/mscc,ocelot.dtsi
+++ b/arch/mips/dts/mscc,ocelot.dtsi
@@ -112,6 +112,98 @@
status = "disabled";
};
+ switch@101 {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ compatible = "mscc,vsc7514-switch";
+ reg = <0x101 0x1>, /* VTSS_TO_SYS */
+ <0x103 0x1>, /* VTSS_TO_REW */
+ <0x108 0x100>, /* VTSS_TO_DEVCPU_QS */
+ <0x10d 0x1>, /* VTSS_TO_HSIO */
+ <0x11e 0x100>, /* VTSS_TO_DEV_0 */
+ <0x11f 0x100>, /* VTSS_TO_DEV_1 */
+ <0x120 0x100>, /* VTSS_TO_DEV_2 */
+ <0x121 0x100>, /* VTSS_TO_DEV_3 */
+ <0x122 0x100>, /* VTSS_TO_DEV_4 */
+ <0x123 0x100>, /* VTSS_TO_DEV_5 */
+ <0x124 0x100>, /* VTSS_TO_DEV_6 */
+ <0x125 0x100>, /* VTSS_TO_DEV_7 */
+ <0x126 0x100>, /* VTSS_TO_DEV_8 */
+ <0x127 0x100>, /* NA */
+ <0x128 0x100>, /* NA */
+ <0x180 0x8>, /* VTSS_TO_QSYS */
+ <0x188 0x1>; /* VTSS_TO_ANA */
+ reg-names = "sys", "rew", "qs", "hsio", "port0",
+ "port1", "port2", "port3", "port4", "port5",
+ "port6", "port7", "port8", "port9",
+ "port10", "qsys", "ana";
+ interrupts = <21 22>;
+ interrupt-names = "xtr", "inj";
+ status = "okay";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port0: port@0 {
+ reg = <0>;
+ };
+ port1: port@1 {
+ reg = <1>;
+ };
+ port2: port@2 {
+ reg = <2>;
+ };
+ port3: port@3 {
+ reg = <3>;
+ };
+ port4: port@4 {
+ reg = <4>;
+ };
+ port5: port@5 {
+ reg = <5>;
+ };
+ port6: port@6 {
+ reg = <6>;
+ };
+ port7: port@7 {
+ reg = <7>;
+ };
+ port8: port@8 {
+ reg = <8>;
+ };
+ port9: port@9 {
+ reg = <9>;
+ };
+ port10: port@10 {
+ reg = <10>;
+ };
+ };
+ };
+
+ mdio0: mdio@107009c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "mscc,ocelot-miim";
+ reg = <0x107009c 0x24>, <0x10700f0 0x8>;
+ interrupts = <14>;
+ status = "disabled";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ phy2: ethernet-phy@2 {
+ reg = <2>;
+ };
+ phy3: ethernet-phy@3 {
+ reg = <3>;
+ };
+ };
+
reset@1070008 {
compatible = "mscc,ocelot-chip-reset";
reg = <0x1070008 0x4>;
@@ -144,6 +236,11 @@
function =
[U-Boot] [PATCH v3 0/4] Add network support for Ocelots SoCs
Hello, this the third version of a series allowing to use the switch component of the Ocelots SoC as a network interface. The binding used is exactly the same of the one already used by Linux. There is also a patch adding a workaround needed on the Ocelot based boards: indeed the pin connected to the DDR reset is part of the switch subsystem. So we need ensure that the DDR is not reset during the switch reset. Gregory Changelog: v2 -> v3: - Use wait_for_bit_le32() whenever it is possible instead of timer_get_us() (Suggested by Daniel Schwierzeck) - Remove ocelot_ofdata_to_platdata() and get the resources directly from the probe function (Suggested by Daniel Schwierzeck) - Use dev_remap_addr_name() to simplify the address mapping (Suggested by Daniel Schwierzeck) - Simplify the mdio initialization by only manage the internal PHY for now v1 -> v2: - Use wait_for_bit_le32() (suggested by Stefan Roese) - Use debug() instead of printf() for the debug messages in mscc_switch_reset. Gregory CLEMENT (4): MIPS: mscc: ocelot: Add ethernet nodes for Ocelot net: add MSCC Ocelot switch support MIPS: mscc: ocelot: add switch reset support configs: mscc_ocelot: add network support MAINTAINERS | 1 + arch/mips/dts/mscc,ocelot.dtsi | 97 arch/mips/dts/ocelot_pcb123.dts | 20 + board/mscc/ocelot/ocelot.c | 24 + configs/mscc_ocelot_defconfig | 1 + drivers/net/Kconfig | 7 + drivers/net/Makefile| 1 + drivers/net/ocelot_switch.c | 765 8 files changed, 916 insertions(+) create mode 100644 drivers/net/ocelot_switch.c -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] arm: actions: Add common framework for Actions Semi SoCs
Hi,
[On top of Andre's review]
On Mon, Jan 14, 2019 at 06:11:03PM +0530, Amit Singh Tomar wrote:
> This adds common arch owl support that can drive, 64-bits SoCs
> from Actions Semi.
>
Could be, "This commit adds common arch support for Actions Semi Owl
series SoCs and removes the Bubblegum96 board files."
> It also removes the Bubblegum specific board files.
>
> Signed-off-by: Amit Singh Tomar
> ---
> Changes since v1:
> * Moved S700 specific changes to patch 4 of 9.
> * Moved couple of symbols from defconfig to arch/arm/Kconfig
> and platform owl Kconfig.
> ---
> arch/arm/Kconfig | 3 +-
> arch/arm/mach-owl/Kconfig| 29 ++
> arch/arm/mach-owl/Makefile | 1 +
> arch/arm/mach-owl/soc.c | 56
>
> board/ucRobotics/bubblegum_96/Kconfig| 15
> board/ucRobotics/bubblegum_96/MAINTAINERS| 6 ---
> board/ucRobotics/bubblegum_96/Makefile | 3 --
> board/ucRobotics/bubblegum_96/bubblegum_96.c | 56
>
> configs/bubblegum_96_defconfig | 4 +-
> include/configs/bubblegum_96.h | 42 -
> include/configs/owl-common.h | 42 +
> include/configs/s900.h | 18 +
> 12 files changed, 131 insertions(+), 144 deletions(-)
> create mode 100644 arch/arm/mach-owl/soc.c
> delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig
> delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS
> delete mode 100644 board/ucRobotics/bubblegum_96/Makefile
> delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c
> delete mode 100644 include/configs/bubblegum_96.h
> create mode 100644 include/configs/owl-common.h
> create mode 100644 include/configs/s900.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d6b1629..1a2e561 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -761,9 +761,9 @@ config ARCH_MX5
>
> config ARCH_OWL
> bool "Actions Semi OWL SoCs"
> - select ARM64
> select DM
> select DM_SERIAL
> + select OWL_SERIAL
> select OF_CONTROL
> imply CMD_DM
>
> @@ -1555,7 +1555,6 @@ source "board/spear/spear600/Kconfig"
> source "board/spear/x600/Kconfig"
> source "board/st/stv0991/Kconfig"
> source "board/tcl/sl50/Kconfig"
> -source "board/ucRobotics/bubblegum_96/Kconfig"
> source "board/birdland/bav335x/Kconfig"
> source "board/toradex/colibri_pxa270/Kconfig"
> source "board/vscom/baltos/Kconfig"
> diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig
> index 199e772..5eb93c9 100644
> --- a/arch/arm/mach-owl/Kconfig
> +++ b/arch/arm/mach-owl/Kconfig
> @@ -1,27 +1,22 @@
> if ARCH_OWL
>
> -config SYS_SOC
> - default "owl"
> -
> choice
> -prompt "Actions Semi OWL SoCs board select"
> +prompt "Actions Semi SoC Variant"
We should explicitly say "Owl" series SoCs here.
> optional
>
> -config TARGET_BUBBLEGUM_96
> - bool "96Boards Bubblegum-96"
> - help
> - Support for 96Boards Bubblegum-96. This board complies with
> - 96Board Consumer Edition Specification. Features:
> - - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
> - - 2GiB RAM
> - - 8GiB eMMC, uSD slot
> - - WiFi, Bluetooth and GPS module
> - - 2x Host, 1x Device USB port
> - - HDMI
> - - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
> +config MACH_S900
> +bool "Actionss Semi S900"
> +select ARM64
>
> endchoice
>
> -source "board/ucRobotics/bubblegum_96/Kconfig"
> +config SYS_CONFIG_NAME
> +default "s900" if MACH_S900
> +
> +config SYS_SOC
> +default "s900" if MACH_S900
> +
> +config SYS_TEXT_BASE
> +default 0x1100
>
Move the above config symbols before MACH_S900.
> endif
> diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
> index 1b43dc2..0b181c6 100644
> --- a/arch/arm/mach-owl/Makefile
> +++ b/arch/arm/mach-owl/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0+
>
> +obj-y += soc.o
> obj-y += sysmap-s900.o
> diff --git a/arch/arm/mach-owl/soc.c b/arch/arm/mach-owl/soc.c
> new file mode 100644
> index 000..d0630d2
> --- /dev/null
> +++ b/arch/arm/mach-owl/soc.c
> @@ -0,0 +1,56 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Actions Semi SoCs Boards Support.
Owl SoCs...
> + *
> + * Copyright (C) 2018 Manivannan Sadhasivam
>
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/*
> + * dram_init - sets uboots idea of sdram size
> + */
> +int dram_init(void)
> +{
> + gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
> + return 0;
> +}
> +
> +/* This is called after dram_init() so use get_ram_size result */
> +int dram_init_banksize(void)
> +{
> +
Re: [U-Boot] [PATCH v3 3/9] clk: actions: Add common clock driver
Hi,
On Tue, Jan 15, 2019 at 12:43:36AM +, André Przywara wrote:
> On 14/01/2019 12:41, Amit Singh Tomar wrote:
>
> Hi,
>
> > CMU block on most of the actions SoC seems to be identical(at-least, S900
> > and S700).
>
> Actually they are not. Not even for the small subset that we implement
> here. Try "diff -wu arch/arm/include/asm/arch-owl/regs_s*.h" for a
> start, plus the differences in the #ifdefs below.
>
> > This patch converts S900 clock driver to something common that can
> > be used for other SoCs, for instance S700(most of clk registres are same).
>
> I am not sure this is a viable approach, really.
> The driver claims to support both SoC's via their compatible strings,
> but in fact is just implementing the one configured via Kconfig.
> While we should be able to easily replace the #ifdefs with something
> checking the .data member associated with the respective .compatible
> string, it gets hairy with the #defines in regs_s[79]00.h.
> So either it's two different .c files, with the register definitions in
> there, or we change the CMU_* defines to CMU_S[79]00_* and include both.
>
> Maybe you could try this and report how it looks like?
> If half of the file is within if-else statements, separating is problem
> more worthwhile.
> Mani, you mentioned the S500, I guess this is even more different,
> right? Which would point into the "separate files" direction.
>
S500 is different in terms of the clock initializations. Ideally we should
have a minimal set of common clk driver like in Linux which I authored.
Otherwise, we should move forward with individual clk files for each
SoC. Having #ifdef's will definitely make the code look messy.
Thanks,
Mani
> >
> > Signed-off-by: Amit Singh Tomar
> > ---
> > Changes since v1:
> > * Moved CLK and CLK_OWL symbols from defconfig to arch/arm/Kconfig.
> > ---
> > arch/arm/Kconfig | 2 +
> > arch/arm/include/asm/arch-owl/clk_owl.h | 61 +
> > arch/arm/include/asm/arch-owl/clk_s900.h | 57 -
> > arch/arm/include/asm/arch-owl/regs_s700.h | 56
>
> This file doesn't define an interface, so should live in the
> drivers/clk/owl directory. Same with the regs_s900.h.
>
> > configs/bubblegum_96_defconfig| 3 -
> > drivers/clk/owl/Kconfig | 10 +--
> > drivers/clk/owl/Makefile | 2 +-
> > drivers/clk/owl/clk_owl.c | 132
> >
> > drivers/clk/owl/clk_s900.c| 137
> > --
> > 9 files changed, 255 insertions(+), 205 deletions(-)
> > create mode 100644 arch/arm/include/asm/arch-owl/clk_owl.h
> > delete mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
> > create mode 100644 arch/arm/include/asm/arch-owl/regs_s700.h
> > create mode 100644 drivers/clk/owl/clk_owl.c
> > delete mode 100644 drivers/clk/owl/clk_s900.c
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 1a2e561..1daf3bf 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -764,6 +764,8 @@ config ARCH_OWL
> > select DM
> > select DM_SERIAL
> > select OWL_SERIAL
> > + select CLK
> > + select CLK_OWL
> > select OF_CONTROL
> > imply CMD_DM
> >
> > diff --git a/arch/arm/include/asm/arch-owl/clk_owl.h
> > b/arch/arm/include/asm/arch-owl/clk_owl.h
> > new file mode 100644
> > index 000..962badd
> > --- /dev/null
> > +++ b/arch/arm/include/asm/arch-owl/clk_owl.h
> > @@ -0,0 +1,61 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Actions Semi SoCs Clock Definitions
> > + *
> > + * Copyright (C) 2015 Actions Semi Co., Ltd.
> > + * Copyright (C) 2018 Manivannan Sadhasivam
> >
> > + *
> > + */
> > +
> > +#ifndef _OWL_CLK_H_
> > +#define _OWL_CLK_H_
> > +
> > +#include
> > +
> > +struct owl_clk_priv {
> > + phys_addr_t base;
> > +};
> > +
> > +/* BUSCLK register definitions */
> > +#define CMU_PDBGDIV_8 7
> > +#define CMU_PDBGDIV_SHIFT 26
> > +#define CMU_PDBGDIV_DIV(CMU_PDBGDIV_8 << CMU_PDBGDIV_SHIFT)
> > +#define CMU_PERDIV_8 7
> > +#define CMU_PERDIV_SHIFT 20
> > +#define CMU_PERDIV_DIV (CMU_PERDIV_8 << CMU_PERDIV_SHIFT)
> > +#define CMU_NOCDIV_2 1
> > +#define CMU_NOCDIV_SHIFT 19
> > +#define CMU_NOCDIV_DIV (CMU_NOCDIV_2 << CMU_NOCDIV_SHIFT)
> > +#define CMU_DMMCLK_SRC_APLL2
> > +#define CMU_DMMCLK_SRC_SHIFT 10
> > +#define CMU_DMMCLK_SRC (CMU_DMMCLK_SRC_APLL <<
> > CMU_DMMCLK_SRC_SHIFT)
> > +#define CMU_APBCLK_DIV BIT(8)
> > +#define CMU_NOCCLK_SRC BIT(7)
> > +#define CMU_AHBCLK_DIV BIT(4)
> > +#define CMU_CORECLK_MASK 3
> > +#define CMU_CORECLK_CPLL BIT(1)
> > +#define CMU_CORECLK_HOSC BIT(0)
> > +
> > +/* COREPLL register definitions */
> > +#define CMU_COREPLL_EN BIT(9)
> > +#define CMU_COREPLL_HOSC_ENBIT(8)
> > +#define
Re: [U-Boot] [U-Boot, v2, 4/7] ARM: mach-omap2: Kconfig: Allow OMAP5 devices to set entry point
On 1/17/19 8:15 AM, Tom Rini wrote: > On Thu, Jan 17, 2019 at 08:13:21AM -0600, Andrew F. Davis wrote: >> On 1/16/19 3:14 PM, Tom Rini wrote: >>> On Wed, Dec 05, 2018 at 11:51:33AM -0600, Andrew F. Davis wrote: >>> Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to have an non-standard boot address in memory. This may be due to the device being a high security variant, which place the Initial SoftWare (ISW) after certificates and secure software. Allow these devices to set this from Kconfig. Signed-off-by: Andrew F. Davis Reviewed-by: Tom Rini --- arch/arm/mach-omap2/Kconfig| 13 + arch/arm/mach-omap2/am33xx/Kconfig | 15 --- include/configs/ti_omap5_common.h | 2 +- 3 files changed, 14 insertions(+), 16 deletions(-) >>> >>> Turns out this breaks OMAP3 among others as the question is asked there >>> now and we have no default value (nor I suspect a reasonable one). >> >> The only thing changed is ti_omap5_common.h, the default provided in >> that file is 0x40301350, would it be okay to just make that the default >> for ISW_ENTRY_ADDR for all platforms that included that file? > > Well, ISW_ENTRY_ADDR doesn't make sense for OMAP3, right? I suspect the > problem is that in moving it from mach-omap2/am33xx/Kconfig to > mach-omap2/Kconfig you need to update the depends on guards so that it > doesn't show up where it's not used. > CONFIG_SPL_TEXT_BASE should be converted to Kconfig, but cannot be right now due to some other platforms using strange methods for setting it in header files. So we have ISW_ENTRY_ADDR in Kconfig that is used to set CONFIG_SPL_TEXT_BASE. ISW_ENTRY_ADDR can be defined for any platform, I just may not be used depending on what headers it includes and whether they use it to set CONFIG_SPL_TEXT_BASE. The change here is using it in ti_omap5_common.h, which a lot more platforms use is seems than I noticed. So all these platforms now need ISW_ENTRY_ADDR set to what the header to set them as (0x40301350). Again, all this goes away when CONFIG_SPL_TEXT_BASE gets converted to Kconfig. Andrew ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] MSCC: Add board support for Servalt SoC family
Add board support, configuration and DTS for Servalt SoC
family. Currently there is one board in this family.
Reviewed-by: Daniel Schwierzeck
Signed-off-by: Horatiu Vultur
---
arch/mips/dts/Makefile | 1 +
arch/mips/dts/mscc,servalt.dtsi | 149 +++
arch/mips/dts/servalt_pcb116.dts | 56 +++
board/mscc/servalt/Kconfig | 14
board/mscc/servalt/Makefile | 3 +
board/mscc/servalt/servalt.c | 52 ++
configs/mscc_servalt_defconfig | 60
7 files changed, 335 insertions(+)
create mode 100644 arch/mips/dts/mscc,servalt.dtsi
create mode 100644 arch/mips/dts/servalt_pcb116.dts
create mode 100644 board/mscc/servalt/Kconfig
create mode 100644 board/mscc/servalt/Makefile
create mode 100644 board/mscc/servalt/servalt.c
create mode 100644 configs/mscc_servalt_defconfig
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index 1484db9..af264ff 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -20,6 +20,7 @@ dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
dtb-$(CONFIG_SOC_JR2) += jr2_pcb110.dtb jr2_pcb111.dtb serval2_pcb112.dtb
+dtb-$(CONFIG_SOC_SERVALT) += servalt_pcb116.dtb
targets += $(dtb-y)
diff --git a/arch/mips/dts/mscc,servalt.dtsi b/arch/mips/dts/mscc,servalt.dtsi
new file mode 100644
index 000..4beb7a3
--- /dev/null
+++ b/arch/mips/dts/mscc,servalt.dtsi
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "mscc,servalt";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "mips,mips24KEc";
+ device_type = "cpu";
+ clocks = <_clk>;
+ reg = <0>;
+ };
+ };
+
+ aliases {
+ serial0 =
+ };
+
+ cpuintc: interrupt-controller@0 {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "mti,cpu-interrupt-controller";
+ };
+
+ cpu_clk: cpu-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5>;
+ };
+
+ sys_clk: sys-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000>;
+ };
+
+ ahb_clk: ahb-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000>;
+ };
+
+ ahb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x7000 0x200>;
+
+ interrupt-parent = <>;
+
+ cpu_ctrl: syscon@0 {
+ compatible = "mscc,servalt-cpu-syscon", "syscon";
+ reg = <0x0 0x2c>;
+ };
+
+ intc: interrupt-controller@70 {
+ compatible = "mscc,servalt-icpu-intr";
+ reg = <0x70 0x74>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupt-parent = <>;
+ interrupts = <2>;
+ };
+
+ uart0: serial@10 {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ compatible = "ns16550a";
+ reg = <0x10 0x20>;
+ interrupts = <6>;
+ clocks = <_clk>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
+
+ status = "disabled";
+ };
+
+ uart2: serial@100800 {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ compatible = "ns16550a";
+ reg = <0x100800 0x20>;
+ interrupts = <7>;
+ clocks = <_clk>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
+
+ status = "disabled";
+ };
+
+ reset@1010008 {
+ compatible = "mscc,servalt-chip-reset";
+ reg = <0x1010008 0x4>;
+ };
+
+ gpio: pinctrl@1010034 {
+ compatible = "mscc,servalt-pinctrl";
+ reg = <0x1010034 0x90>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
[U-Boot] [PATCH v2 2/3] MSCC: Add support for Servalt SoC family.
As Ocelot, Luton and Jaguar2, this family of SoCs are found
in Microsemi Switches solution.
Reviewed-by: Daniel Schwierzeck
Signed-off-by: Horatiu Vultur
---
arch/mips/mach-mscc/Kconfig| 8 +
arch/mips/mach-mscc/cpu.c | 2 +-
arch/mips/mach-mscc/dram.c | 3 +-
arch/mips/mach-mscc/include/mach/common.h | 5 +
arch/mips/mach-mscc/include/mach/ddr.h | 22 +-
arch/mips/mach-mscc/include/mach/servalt/servalt.h | 24 ++
.../include/mach/servalt/servalt_devcpu_gcb.h | 20 ++
.../mach/servalt/servalt_devcpu_gcb_miim_regs.h| 25 ++
.../include/mach/servalt/servalt_icpu_cfg.h| 319 +
arch/mips/mach-mscc/reset.c| 2 +-
10 files changed, 419 insertions(+), 11 deletions(-)
create mode 100644 arch/mips/mach-mscc/include/mach/servalt/servalt.h
create mode 100644
arch/mips/mach-mscc/include/mach/servalt/servalt_devcpu_gcb.h
create mode 100644
arch/mips/mach-mscc/include/mach/servalt/servalt_devcpu_gcb_miim_regs.h
create mode 100644 arch/mips/mach-mscc/include/mach/servalt/servalt_icpu_cfg.h
diff --git a/arch/mips/mach-mscc/Kconfig b/arch/mips/mach-mscc/Kconfig
index fc6aa03..80e4b44 100644
--- a/arch/mips/mach-mscc/Kconfig
+++ b/arch/mips/mach-mscc/Kconfig
@@ -40,6 +40,13 @@ config SOC_JR2
help
This supports MSCC Jaguar2 family of SOCs.
+config SOC_SERVALT
+ bool "Servalt SOC Family"
+ select SOC_VCOREIII
+ select MSCC_BB_SPI
+ help
+ This supports MSCC Servalt family of SOCs.
+
endchoice
config SYS_CONFIG_NAME
@@ -74,4 +81,5 @@ source "board/mscc/luton/Kconfig"
source "board/mscc/jr2/Kconfig"
+source "board/mscc/servalt/Kconfig"
endmenu
diff --git a/arch/mips/mach-mscc/cpu.c b/arch/mips/mach-mscc/cpu.c
index 4729b7a..1bfd636 100644
--- a/arch/mips/mach-mscc/cpu.c
+++ b/arch/mips/mach-mscc/cpu.c
@@ -91,7 +91,7 @@ int mach_cpu_init(void)
writel(ICPU_SPI_MST_CFG_CS_DESELECT_TIME(0x19) +
ICPU_SPI_MST_CFG_CLK_DIV(9), BASE_CFG + ICPU_SPI_MST_CFG);
#endif
-#ifdef CONFIG_SOC_JR2
+#if defined(CONFIG_SOC_JR2) || defined(CONFIG_SOC_SERVALT)
writel(ICPU_SPI_MST_CFG_FAST_READ_ENA +
ICPU_SPI_MST_CFG_CS_DESELECT_TIME(0x19) +
ICPU_SPI_MST_CFG_CLK_DIV(14), BASE_CFG + ICPU_SPI_MST_CFG);
diff --git a/arch/mips/mach-mscc/dram.c b/arch/mips/mach-mscc/dram.c
index 8002e07..2073821 100644
--- a/arch/mips/mach-mscc/dram.c
+++ b/arch/mips/mach-mscc/dram.c
@@ -19,7 +19,8 @@ static inline int vcoreiii_train_bytelane(void)
ret = hal_vcoreiii_train_bytelane(0);
-#if defined(CONFIG_SOC_OCELOT) || defined(CONFIG_SOC_JR2)
+#if defined(CONFIG_SOC_OCELOT) || defined(CONFIG_SOC_JR2) || \
+ defined(CONFIG_SOC_SERVALT)
if (ret)
return ret;
ret = hal_vcoreiii_train_bytelane(1);
diff --git a/arch/mips/mach-mscc/include/mach/common.h
b/arch/mips/mach-mscc/include/mach/common.h
index b9e0939..97b3f82 100644
--- a/arch/mips/mach-mscc/include/mach/common.h
+++ b/arch/mips/mach-mscc/include/mach/common.h
@@ -21,6 +21,11 @@
#include
#include
#include
+#elif defined(CONFIG_SOC_SERVALT)
+#include
+#include
+#include
+#include
#else
#error Unsupported platform
#endif
diff --git a/arch/mips/mach-mscc/include/mach/ddr.h
b/arch/mips/mach-mscc/include/mach/ddr.h
index 7552acb..ff32f22 100644
--- a/arch/mips/mach-mscc/include/mach/ddr.h
+++ b/arch/mips/mach-mscc/include/mach/ddr.h
@@ -161,7 +161,8 @@
#endif
-#if defined(CONFIG_SOC_OCELOT) || defined(CONFIG_SOC_JR2)
+#if defined(CONFIG_SOC_OCELOT) || defined(CONFIG_SOC_JR2) || \
+ defined(CONFIG_SOC_SERVALT)
#define MIPS_VCOREIII_MEMORY_16BIT 1
#endif
@@ -239,7 +240,8 @@
ICPU_MEMCTRL_CFG_MSB_ROW_ADDR(VC3_MPAR_row_addr_cnt - 1) | \
ICPU_MEMCTRL_CFG_MSB_COL_ADDR(VC3_MPAR_col_addr_cnt - 1)
-#if defined(CONFIG_SOC_OCELOT) || defined(CONFIG_SOC_JR2)
+#if defined(CONFIG_SOC_OCELOT) || defined(CONFIG_SOC_JR2) || \
+ defined(CONFIG_SOC_SERVALT)
#define MSCC_MEMPARM_PERIOD\
ICPU_MEMCTRL_REF_PERIOD_MAX_PEND_REF(8) | \
ICPU_MEMCTRL_REF_PERIOD_REF_PERIOD(VC3_MPAR_tREFI)
@@ -378,7 +380,8 @@ static inline void memphy_soft_reset(void)
PAUSE();
}
-#if defined(CONFIG_SOC_OCELOT) || defined(CONFIG_SOC_JR2)
+#if defined(CONFIG_SOC_OCELOT) || defined(CONFIG_SOC_JR2) || \
+ defined(CONFIG_SOC_SERVALT)
static u8 training_data[] = { 0xfe, 0x11, 0x33, 0x55, 0x77, 0x99, 0xbb, 0xdd };
static inline void sleep_100ns(u32 val)
@@ -449,7 +452,7 @@ static inline void hal_vcoreiii_ddr_failed(void)
panic("DDR init failed\n");
}
-#else /* JR2 */
+#else /* JR2 || ServalT */
static inline void hal_vcoreiii_ddr_reset_assert(void)
{
/* Ensure the memory controller physical iface is forced reset */
