Re: [U-Boot] [PATCH v2 1/5] microblaze: Move architecture to use generic board init
Hi Michal, On 3 February 2015 at 02:26, Michal Simek wrote: > Hi Simon, > > On 02/03/2015 12:58 AM, Simon Glass wrote: >> Hi Michal, >> >> On 2 February 2015 at 08:46, Michal Simek wrote: >>> Compile code with -fPIC to get GOT. Do not build SPL >>> with fPIC because it increasing SPL size for nothing. >>> >>> Signed-off-by: Michal Simek >>> --- >>> >>> Changes in v2: >>> - Use dram_init instead of init_func_ram() >>> Suggested by Simon >>> >>> This code requires >>> "common/board_r: manual relocation for cmd table" >>> http://lists.denx.de/pipermail/u-boot/2015-January/201965.html >>> >>> Not fully happy about it because compare to previous solution adds >>> almost +60k on size for doing the same thing as before. >>> >>> 15: microblaze: Move architecture to use generic board init >>> microblaze: (for 1/1 boards) all +52268.0 bss -4.0 data +11724.0 >>> rodata -2676.0 spl/u-boot-spl:all +36.0 spl/u-boot-spl:data +36.0 >>> text +43224.0 >>> microblaze-generic: all +52268 bss -4 data +11724 rodata >>> -2676 spl/u-boot-spl:all +36 spl/u-boot-spl:data +36 text +43224 >>> >>> Depends on: >>> http://lists.denx.de/pipermail/u-boot/2015-January/203277.html >> >> Yes that seems crazy. >> >> You can use -B to see what code is added. Can you figure it out? > > I was checking this with our toolchain guy and expectation with fPIC/fPIE > is 20% bigger code and I am below that. > > I was checking -B output too and it is adding bytes to every function > that's why the sum is that big. OK, that's unfortunate but sounds like it is a feature of the architecture, so nothing wrong with U-Boot per se. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: at91: at91sam9rlek: add hush parser to defconfig
On 2/4/2015 1:10 PM, Bo Shen wrote: Hi Josh, On 02/03/2015 06:19 PM, Josh Wu wrote: HUSH parser will handle the variable easier. That will be helpful for write a complicated U-Boot commands or varaibles. You are on the way to Kconfig. :) Yep. Seems a long way to go ;-) Thanks. Signed-off-by: Josh Wu Acked-by: Bo Shen --- configs/at91sam9rlek_dataflash_defconfig | 1 + configs/at91sam9rlek_mmc_defconfig | 1 + configs/at91sam9rlek_nandflash_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/at91sam9rlek_dataflash_defconfig b/configs/at91sam9rlek_dataflash_defconfig index 90516e0..c811ad5 100644 --- a/configs/at91sam9rlek_dataflash_defconfig +++ b/configs/at91sam9rlek_dataflash_defconfig @@ -1,3 +1,4 @@ CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9RL,SYS_USE_DATAFLASH" CONFIG_ARM=y CONFIG_TARGET_AT91SAM9RLEK=y +CONFIG_HUSH_PARSER=y diff --git a/configs/at91sam9rlek_mmc_defconfig b/configs/at91sam9rlek_mmc_defconfig index b93c881..8704140 100644 --- a/configs/at91sam9rlek_mmc_defconfig +++ b/configs/at91sam9rlek_mmc_defconfig @@ -1,3 +1,4 @@ CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9RL,SYS_USE_MMC" CONFIG_ARM=y CONFIG_TARGET_AT91SAM9RLEK=y +CONFIG_HUSH_PARSER=y diff --git a/configs/at91sam9rlek_nandflash_defconfig b/configs/at91sam9rlek_nandflash_defconfig index 0e2edfd..e3de043 100644 --- a/configs/at91sam9rlek_nandflash_defconfig +++ b/configs/at91sam9rlek_nandflash_defconfig @@ -1,3 +1,4 @@ CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9RL,SYS_USE_NANDFLASH" CONFIG_ARM=y CONFIG_TARGET_AT91SAM9RLEK=y +CONFIG_HUSH_PARSER=y Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] arm: spl: Provide for a board-specific loader
Some boards have a special way of loading U-Boot that does not fit with
the existing SPL code. For example sunxi uses an 'FEL' mode where U-Boot
is loaded over USB. Add a CONFIG option and boot mode for this.
Signed-off-by: Simon Glass
---
arch/arm/include/asm/spl.h | 4
common/spl/spl.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/spl.h b/arch/arm/include/asm/spl.h
index 8acd7cd..17b6f54 100644
--- a/arch/arm/include/asm/spl.h
+++ b/arch/arm/include/asm/spl.h
@@ -26,10 +26,14 @@ enum {
BOOT_DEVICE_SPI,
BOOT_DEVICE_SATA,
BOOT_DEVICE_I2C,
+ BOOT_DEVICE_BOARD,
BOOT_DEVICE_NONE
};
#endif
+/* Board-specific load method */
+void spl_board_load_image(void);
+
/* Linker symbols. */
extern char __bss_start[], __bss_end[];
diff --git a/common/spl/spl.c b/common/spl/spl.c
index daaeb50..ded0f30 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -229,6 +229,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_sata_load_image();
break;
#endif
+#ifdef CONFIG_SPL_BOARD_LOAD_IMAGE
+ case BOOT_DEVICE_BOARD:
+ spl_board_load_image();
+ break;
+#endif
default:
#if defined(CONFIG_SPL_SERIAL_SUPPORT) && defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
puts("SPL: Unsupported Boot Device!\n");
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] RFC: sunxi: WIP FEL support
(What does FEL stand for?)
This is an attempt to make sunxi's FEL code fit with the normal U-Boot
boot sequence instead of creating its own.
Most of the FEL special-case code is removed, although I may have gone too
far with my changes to generate a u-boot-sunxi-with-spl.bin file even when
FEL is enabled. This may not be possible since the MMC stack makes SPL
too large for FEL anyway, although it may be possible for other boot
mediums.
This series is available at u-boot-dm, branch sunxi-working.
Signed-off-by: Simon Glass
---
arch/arm/cpu/armv7/sunxi/Makefile | 4 +-
arch/arm/cpu/armv7/sunxi/board.c| 21
arch/arm/cpu/armv7/sunxi/config.mk | 2 -
arch/arm/cpu/armv7/sunxi/fel_utils.S| 26 +
arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds | 82 -
arch/arm/include/asm/arch-sunxi/sys_proto.h | 10
board/sunxi/Kconfig | 10
include/configs/sunxi-common.h | 6 +--
scripts/Makefile.spl| 2 -
9 files changed, 70 insertions(+), 93 deletions(-)
create mode 100644 arch/arm/cpu/armv7/sunxi/fel_utils.S
delete mode 100644 arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index 48db744..c1b975a 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -38,7 +38,5 @@ obj-$(CONFIG_MACH_SUN5I) += dram_sun4i.o
obj-$(CONFIG_MACH_SUN6I) += dram_sun6i.o
obj-$(CONFIG_MACH_SUN7I) += dram_sun4i.o
obj-$(CONFIG_MACH_SUN8I) += dram_sun8i.o
-ifdef CONFIG_SPL_FEL
-obj-y += start.o
-endif
+obj-y += fel_utils.o
endif
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 6e28bcd..b7492ac 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -27,6 +27,13 @@
#include
+struct fel_stash {
+ uint32_t sp;
+ uint32_t lr;
+};
+
+struct fel_stash fel_stash __attribute__((section(".data")));
+
static int gpio_init(void)
{
#if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
@@ -65,6 +72,12 @@ static int gpio_init(void)
return 0;
}
+void spl_board_load_image(void)
+{
+ debug("Returning to FEL sp=%x, lr=%x\n", fel_stash.sp, fel_stash.lr);
+ return_to_fel(fel_stash.sp, fel_stash.lr);
+}
+
void s_init(void)
{
#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I
@@ -95,6 +108,14 @@ void s_init(void)
*/
u32 spl_boot_device(void)
{
+ /*
+* Have we been asked to return to the FEL portion of the boot ROM?
+* TODO: We need a more robust test here, or bracket this with
+* #ifdef CONFIG_SPL_FEL.
+*/
+ if (fel_stash.lr >= 0x && fel_stash.lr < 0x4000)
+ return BOOT_DEVICE_BOARD;
+
return BOOT_DEVICE_MMC1;
}
diff --git a/arch/arm/cpu/armv7/sunxi/config.mk
b/arch/arm/cpu/armv7/sunxi/config.mk
index 00f5ffc..76ffec9 100644
--- a/arch/arm/cpu/armv7/sunxi/config.mk
+++ b/arch/arm/cpu/armv7/sunxi/config.mk
@@ -1,8 +1,6 @@
# Build a combined spl + u-boot image
ifdef CONFIG_SPL
ifndef CONFIG_SPL_BUILD
-ifndef CONFIG_SPL_FEL
ALL-y += u-boot-sunxi-with-spl.bin
endif
endif
-endif
diff --git a/arch/arm/cpu/armv7/sunxi/fel_utils.S
b/arch/arm/cpu/armv7/sunxi/fel_utils.S
new file mode 100644
index 000..42739df
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/fel_utils.S
@@ -0,0 +1,26 @@
+/*
+ * Utility functions for FEL mode.
+ *
+ * Copyright (c) 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+
+ENTRY(save_boot_params)
+ ldr r0, =fel_stash
+ str sp, [r0, #0]
+ str r4, [r0, #4]/* Store lr */
+ mov r0, #RESET_SKIP_VBVAR | RESET_SKIP_CP15
+ bx lr
+ENDPROC(save_boot_params)
+
+ENTRY(return_to_fel)
+ mov sp, r0
+ mov lr, r1
+ bx lr
+ENDPROC(return_to_fel)
diff --git a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
deleted file mode 100644
index 928b7c1..000
--- a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
+++ /dev/null
@@ -1,82 +0,0 @@
-/*
- * (C) Copyright 2013
- * Henrik Nordstrom
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
-OUTPUT_ARCH(arm)
-ENTRY(s_init)
-SECTIONS
-{
- . = 0x2000;
-
- . = ALIGN(4);
- .text :
- {
- *(.text.s_init)
- *(.text*)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- . = ALIGN(4);
- .data : {
- *(.data*)
- }
-
- . = ALIGN(4);
- .u_boot_list : {
- KEEP(*(SORT(.u_boot_list*)));
- }
-
- . = ALIGN(4);
- . = .;
-
- . = ALIGN(4);
- .rel.dyn : {
- __rel_dyn_start =
[U-Boot] [PATCH] ARM: at91: sama5d4: display the U-Boot version on LCD
This patch will display the U-Boot version on LCD.
Signed-off-by: Josh Wu
---
board/atmel/sama5d4_xplained/sama5d4_xplained.c | 2 ++
board/atmel/sama5d4ek/sama5d4ek.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/board/atmel/sama5d4_xplained/sama5d4_xplained.c
b/board/atmel/sama5d4_xplained/sama5d4_xplained.c
index 1c5b92c..a8c476b 100644
--- a/board/atmel/sama5d4_xplained/sama5d4_xplained.c
+++ b/board/atmel/sama5d4_xplained/sama5d4_xplained.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -178,6 +179,7 @@ void lcd_show_board_info(void)
int i;
char temp[32];
+ lcd_printf("%s\n", U_BOOT_VERSION);
lcd_printf("2014 ATMEL Corp\n");
lcd_printf("%s CPU at %s MHz\n", get_cpu_name(),
strmhz(temp, get_cpu_clk_rate()));
diff --git a/board/atmel/sama5d4ek/sama5d4ek.c
b/board/atmel/sama5d4ek/sama5d4ek.c
index d8ff648..b55db06 100644
--- a/board/atmel/sama5d4ek/sama5d4ek.c
+++ b/board/atmel/sama5d4ek/sama5d4ek.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -173,6 +174,7 @@ void lcd_show_board_info(void)
int i;
char temp[32];
+ lcd_printf("%s\n", U_BOOT_VERSION);
lcd_printf("2014 ATMEL Corp\n");
lcd_printf("a...@atmel.com\n");
lcd_printf("%s CPU at %s MHz\n", get_cpu_name(),
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: at91: at91sam9rlek: add hush parser to defconfig
Hi Josh, On 02/03/2015 06:19 PM, Josh Wu wrote: HUSH parser will handle the variable easier. That will be helpful for write a complicated U-Boot commands or varaibles. You are on the way to Kconfig. :) Thanks. Signed-off-by: Josh Wu Acked-by: Bo Shen --- configs/at91sam9rlek_dataflash_defconfig | 1 + configs/at91sam9rlek_mmc_defconfig | 1 + configs/at91sam9rlek_nandflash_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/at91sam9rlek_dataflash_defconfig b/configs/at91sam9rlek_dataflash_defconfig index 90516e0..c811ad5 100644 --- a/configs/at91sam9rlek_dataflash_defconfig +++ b/configs/at91sam9rlek_dataflash_defconfig @@ -1,3 +1,4 @@ CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9RL,SYS_USE_DATAFLASH" CONFIG_ARM=y CONFIG_TARGET_AT91SAM9RLEK=y +CONFIG_HUSH_PARSER=y diff --git a/configs/at91sam9rlek_mmc_defconfig b/configs/at91sam9rlek_mmc_defconfig index b93c881..8704140 100644 --- a/configs/at91sam9rlek_mmc_defconfig +++ b/configs/at91sam9rlek_mmc_defconfig @@ -1,3 +1,4 @@ CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9RL,SYS_USE_MMC" CONFIG_ARM=y CONFIG_TARGET_AT91SAM9RLEK=y +CONFIG_HUSH_PARSER=y diff --git a/configs/at91sam9rlek_nandflash_defconfig b/configs/at91sam9rlek_nandflash_defconfig index 0e2edfd..e3de043 100644 --- a/configs/at91sam9rlek_nandflash_defconfig +++ b/configs/at91sam9rlek_nandflash_defconfig @@ -1,3 +1,4 @@ CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9RL,SYS_USE_NANDFLASH" CONFIG_ARM=y CONFIG_TARGET_AT91SAM9RLEK=y +CONFIG_HUSH_PARSER=y Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: at91: sama5d4: display the U-Boot version on LCD
Hi Josh,
On 02/04/2015 11:03 AM, Josh Wu wrote:
This patch will display the U-Boot version on LCD.
To be frankly, I have no idea what should be put on LCD to display. No
objection for this patch.
Signed-off-by: Josh Wu
Acked-by: Bo Shen
---
board/atmel/sama5d4_xplained/sama5d4_xplained.c | 2 ++
board/atmel/sama5d4ek/sama5d4ek.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/board/atmel/sama5d4_xplained/sama5d4_xplained.c
b/board/atmel/sama5d4_xplained/sama5d4_xplained.c
index 1c5b92c..a8c476b 100644
--- a/board/atmel/sama5d4_xplained/sama5d4_xplained.c
+++ b/board/atmel/sama5d4_xplained/sama5d4_xplained.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -178,6 +179,7 @@ void lcd_show_board_info(void)
int i;
char temp[32];
+ lcd_printf("%s\n", U_BOOT_VERSION);
lcd_printf("2014 ATMEL Corp\n");
lcd_printf("%s CPU at %s MHz\n", get_cpu_name(),
strmhz(temp, get_cpu_clk_rate()));
diff --git a/board/atmel/sama5d4ek/sama5d4ek.c
b/board/atmel/sama5d4ek/sama5d4ek.c
index d8ff648..b55db06 100644
--- a/board/atmel/sama5d4ek/sama5d4ek.c
+++ b/board/atmel/sama5d4ek/sama5d4ek.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -173,6 +174,7 @@ void lcd_show_board_info(void)
int i;
char temp[32];
+ lcd_printf("%s\n", U_BOOT_VERSION);
lcd_printf("2014 ATMEL Corp\n");
lcd_printf("a...@atmel.com\n");
lcd_printf("%s CPU at %s MHz\n", get_cpu_name(),
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] cmd_fdt: Print the control fdt in terms of virtual memory
If you want to inspect the control device tree using the fdt command,
the "fdt address -c" command previously unhelpfully printed the phys
memory address of the device tree. That address could not then be used
to set the fdt address for inspection. Changed the resulting print to
one that can be copied directly to the 'fdt address ' command.
Signed-off-by: Joe Hershberger
---
Changes in v2:
-Reworded commit message
common/cmd_fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index 4e9bc6b..b213105 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -111,7 +111,7 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (!blob || !fdt_valid(&blob))
return 1;
printf("The address of the fdt is %#08lx\n",
- control ? (ulong)blob :
+ control ? (ulong)map_to_sysmem(blob) :
getenv_hex("fdtaddr", 0));
return 0;
}
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 7/7] Exynos: Clock: Cleanup soc_get_periph_rate
Hi Akshay,
On 02/03/2015 05:27 PM, Akshay Saraswat wrote:
> Cleaning up soc_get_periph_rate to make the logic easy to
> comprehend.
>
Could you give more detailed description?
> Signed-off-by: Akshay Saraswat
> ---
> Changes since v4:
> - New patch.
>
> arch/arm/cpu/armv7/exynos/clock.c | 76
> +--
> 1 file changed, 33 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/clock.c
> b/arch/arm/cpu/armv7/exynos/clock.c
> index 3884d4b..8724bc7 100644
> --- a/arch/arm/cpu/armv7/exynos/clock.c
> +++ b/arch/arm/cpu/armv7/exynos/clock.c
> @@ -366,8 +366,8 @@ static struct clk_bit_info *get_clk_bit_info(int
> peripheral)
> static unsigned long exynos5_get_periph_rate(int peripheral)
> {
> struct clk_bit_info *bit_info = get_clk_bit_info(peripheral);
> - unsigned long sclk, sub_clk = 0;
> - unsigned int src, div, sub_div = 0;
> + unsigned long sclk = 0;
> + unsigned int src = 0, div = 0, sub_div = 0;
> struct exynos5_clock *clk =
> (struct exynos5_clock *)samsung_get_base_clock();
>
> @@ -389,30 +389,30 @@ static unsigned long exynos5_get_periph_rate(int
> peripheral)
> break;
> case PERIPH_ID_I2S0:
> src = readl(&clk->src_mau);
> - div = readl(&clk->div_mau);
> + div = sub_div = readl(&clk->div_mau);
> case PERIPH_ID_SPI0:
> case PERIPH_ID_SPI1:
> src = readl(&clk->src_peric1);
> - div = readl(&clk->div_peric1);
> + div = sub_div = readl(&clk->div_peric1);
> break;
> case PERIPH_ID_SPI2:
> src = readl(&clk->src_peric1);
> - div = readl(&clk->div_peric2);
> + div = sub_div = readl(&clk->div_peric2);
> break;
> case PERIPH_ID_SPI3:
> case PERIPH_ID_SPI4:
> src = readl(&clk->sclk_src_isp);
> - div = readl(&clk->sclk_div_isp);
> + div = sub_div = readl(&clk->sclk_div_isp);
> break;
> case PERIPH_ID_SDMMC0:
> case PERIPH_ID_SDMMC1:
> src = readl(&clk->src_fsys);
> - div = readl(&clk->div_fsys1);
> + div = sub_div = readl(&clk->div_fsys1);
> break;
> case PERIPH_ID_SDMMC2:
> case PERIPH_ID_SDMMC3:
> src = readl(&clk->src_fsys);
> - div = readl(&clk->div_fsys2);
> + div = sub_div = readl(&clk->div_fsys2);
> break;
> case PERIPH_ID_I2C0:
> case PERIPH_ID_I2C1:
> @@ -422,12 +422,10 @@ static unsigned long exynos5_get_periph_rate(int
> peripheral)
> case PERIPH_ID_I2C5:
> case PERIPH_ID_I2C6:
> case PERIPH_ID_I2C7:
> - sclk = exynos5_get_pll_clk(MPLL);
> - sub_div = ((readl(&clk->div_top1) >> bit_info->div_bit)
> - & bit_info->div_mask) + 1;
> - div = ((readl(&clk->div_top0) >> bit_info->prediv_bit)
> - & bit_info->prediv_mask) + 1;
> - return (sclk / sub_div) / div;
> + src = EXYNOS_SRC_MPLL;
> + div = readl(&clk->div_top0);
> + sub_div = readl(&clk->div_top1);
> + break;
> default:
> debug("%s: invalid peripheral %d", __func__, peripheral);
> return -1;
> @@ -446,29 +444,26 @@ static unsigned long exynos5_get_periph_rate(int
> peripheral)
> case EXYNOS_SRC_VPLL:
> sclk = exynos5_get_pll_clk(VPLL);
> break;
> - default:
> - return 0;
Why remove? I think it's better to use default label and also how about
add debug log?
> }
>
> - /* Ratio clock division for this peripheral */
> - if (bit_info->div_bit >= 0) {
> - sub_div = (div >> bit_info->div_bit) & bit_info->div_mask;
> - sub_clk = sclk / (sub_div + 1);
> - }
> + /* Clock divider ratio for this peripheral */
> + if (bit_info->div_bit >= 0)
> + div = (div >> bit_info->div_bit) & bit_info->div_mask;
>
> - if (bit_info->prediv_bit >= 0) {
> - div = (div >> bit_info->prediv_bit) & bit_info->prediv_mask;
> - return sub_clk / (div + 1);
> - }
> + /* Clock pre-divider ratio for this peripheral */
> + if (bit_info->prediv_bit >= 0)
> + sub_div = (sub_div >> bit_info->prediv_bit)
> + & bit_info->prediv_mask;
>
> - return sub_clk;
> + /* Calculate and return required clock rate */
> + return (sclk / (div + 1)) / (sub_div + 1);
> }
>
> static unsigned long exynos542x_get_periph_rate(int peripheral)
> {
> struct clk_bit_info *bit_info = get_clk_bit_info(peripheral);
> - unsigned long sclk, sub_clk = 0;
> - unsigned int src, div, sub_div = 0;
> + unsigned long sclk = 0;
> + unsigned int src = 0, div = 0, sub_div = 0;
> struct exynos5420_clock *clk =
>
Re: [U-Boot] [PATCH v5 0/7] Exynos5: Fix warnings and enrich clock_get_periph_rate
Hi, On 02/03/2015 05:26 PM, Akshay Saraswat wrote: > This patch series does following changes - > 1. Removing compiler warnings for clock_get_periph_rate. > 2. Adding and enabling support for Exynos542x in >clock_get_periph_rate. > 3. Replacing peripheral specific function calls with >clock_get_periph_rate. > 4. Remove code from clocks file which became useless due to >introduction of clock_get_periph_rate. > > Changes since v4: > - Added Reviewed-by in patches 3 and 5. > - Split patch 6 of version 4 into two patches 6 and 7. > > Changes since v3: > - Added Reviewed-by & Tested-by in patches 1, 2 and 4. > - Patch-3: Handled SPLL case in exynos542x_get_periph_rate. > - Patch-3: Changed EXYNOS542x -> EXYNOS542X in pll_src_bit enum. > - Merged pathces 5 and 6 of version 3. > - Patch-6: New patch for dealing with variety of mask bits. > > Changes since v2: > - Patch-1: Added debug message for unknown periph IDs. > - Patch-2: Changed exynos5420 -> exynos542x in comment. > - Patch-3: Fixed enum and soc_get_periph_rate switch. > - Patch-3: Added checks for negative values in soc_get_periph_rate. > - Patch-4: Added checks for negative values in soc_get_periph_rate. > > Changes since v1: > - Added 2 new patches. > > > Akshay Saraswat (7): > Exynos5: Fix compiler warnings due to clock_get_periph_rate > Exynos542x: Move exynos5420_get_pll_clk up and rename > Exynos542x: Add and enable get_periph_rate support > Exynos5: Fix exynos5_get_periph_rate calculations > Exynos5: Use clock_get_periph_rate generic API > Exynos: clock: change mask bits as per peripheral > Exynos: Clock: Cleanup soc_get_periph_rate > > arch/arm/cpu/armv7/exynos/clock.c | 619 > - > arch/arm/include/asm/arch-exynos/clk.h | 4 + > 2 files changed, 296 insertions(+), 327 deletions(-) > I have minor comments about patch 7/7. Apart from that, this patchset is Acked-by: Joonyoung Shim Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/13] common lcd refactor
Hi, Nikita On 2/3/2015 7:32 PM, Nikita Kiryanov wrote: This series is part of my ongoing efforts to cleanup common/lcd code (and at some point merge it with the CONFIG_VIDEO code). This series focuses on eliminating platform specific #defines from lcd.c code, and then adds a few platform independent code refactors and cleanups on top of that. A small note on the series: - The patch "lcd: split configuration_get_cmap" turned out to be a little problematic: the goal was to move all platform specific code to the appropriate lcd/fb drivers, and keep the generic case in lcd.c as a weak function. This was not possible to do for configuration_get_cmap(), because the weak version still has to compile even if it is overridden, and unfortunately the generic case references panel_info, which is a struct that varies depending on the configuration, and does not always have a cmap field. This demonstrated that the visibility of panel_info should be reviewed, and that there might be a need for some kind of lcd_generic driver. Since this may warrant a series of its own, I opted to tentatively implement the generic configuration_get_cmap() function in lcd.h as static function, and plan to revisit it in the next series. The end result was compile tested on arm and powerpc, and tested on cm_t35 (splash screen feature). Rebased on current mainline. Changes in V2: - Minor commit message changes (such as s/platform specific/platform-specific/, s/Raspberry Pi config file is updated to compile the new file/Raspberry Pi is updated to accommodate the changes/) - patch 2: define configuration_get_cmap() prototype only once. Cc: Bo Shen Cc: Simon Glass Cc: Anatolij Gustschin Nikita Kiryanov (13): lcd: move platform-specific structs to their own headers lcd: split configuration_get_cmap lcd: atmel: move atmel-specific fb_put_word to atmel_lcdfb lcd: mpc8xx: move mpc823-specific fb_put_byte to mpc8xx_lcd.c lcd: atmel: introduce lcd_logo_set_cmap lcd: mpc823: move mpc823-specific lcd_logo_set_cmap code to mpc8xx_lcd.c lcd: logo: move generic cmap setting to lcd_logo_set_cmap() lcd: introduce lcd_set_cmap lcd: remove unused includes lcd: various cleanups lcd: rename bitmap_plot to better represent its functionality lcd: dt: extract simplefb support lcd: split splash code into its own function board/raspberrypi/rpi/rpi.c | 1 + common/Makefile | 1 + common/lcd.c | 358 ++- common/lcd_simplefb.c| 59 +++ common/splash.c | 16 ++ drivers/video/atmel_hlcdfb.c | 13 ++ drivers/video/atmel_lcdfb.c | 51 ++ drivers/video/exynos_fb.c| 9 ++ drivers/video/mpc8xx_lcd.c | 29 drivers/video/pxa_lcd.c | 6 + include/atmel_lcd.h | 38 + include/exynos_lcd.h | 81 ++ include/fdt_simplefb.h | 14 ++ include/lcd.h| 311 ++--- include/mpc823_lcd.h | 43 ++ include/pxa_lcd.h| 80 ++ include/splash.h | 11 +- 17 files changed, 574 insertions(+), 547 deletions(-) create mode 100644 common/lcd_simplefb.c create mode 100644 include/atmel_lcd.h create mode 100644 include/exynos_lcd.h create mode 100644 include/fdt_simplefb.h create mode 100644 include/mpc823_lcd.h create mode 100644 include/pxa_lcd.h For this whole series, I tested the Atmel lcd & hlcd part, you can add my tested-by: Tested-by: Josh Wu Thanks. Best Regards, Josh Wu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] RSA depends on DM
Of course there is the meta question of why RSA sig is still being used rather than ECDSA. As a crypto plumber, I occationally wonder why we perpetuate need of large, slow RSA keys over ECC. Perhaps the patent concerns even with RFC 6090. I will shut up and let you to your important work of getting all this wonderful support working in uboot. On 02/03/2015 08:01 PM, Simon Glass wrote: Hi Chris, On 3 February 2015 at 17:57, Chris Kuethe wrote: On Tue, Feb 3, 2015 at 4:38 PM, Simon Glass wrote: +Masahiro Hi Chris, On 3 February 2015 at 00:42, Chris Kuethe wrote: Discovered while experimenting with signature checking on vexpress which doesn't typically use DM. Rather than complaining about unmet dependencies it might be better to enable those them. --- lib/rsa/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig index 1268a1b..4db5da4 100644 --- a/lib/rsa/Kconfig +++ b/lib/rsa/Kconfig @@ -2,6 +2,7 @@ config RSA bool "Use RSA Library" select RSA_FREESCALE_EXP if FSL_CAAM select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP + select DM help RSA support. This enables the RSA algorithm used for FIT image verification in U-Boot. I wonder whether 'depends on DM' might be better? It seems odd to have the tail wagging the dog. Regards, Simon No, that would not be better because a few lines down, RSA_SOFTWARE_EXP and RSA_FREESCALE_EXP both say "depends on DM" but they don't actually enable it if they need it. As a user, my expectation is that when I turn on some high level feature, that will enable all of its lower level dependencies. Would it be less strange to make FIT_SIGNATURE turn on DM instead of RSA? We certainly must avoid the build break. My concern is that CONFIG_DM may introduce a run-time break. For example if you don't have pre-relocation malloc() available the board may not boot. Driver model is a fundamental core feature, and we are working to move everything over to it, but I'm not quite comfortable with forcing it on when someone changes a feature. It feel it would be better to not offer it. I'm interested to hear other viewpoints though. Perhaps soon we can enable CONFIG_DM globally but we are not there yet. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Hi Michal, On Tue, 3 Feb 2015 10:11:39 +0100 Michal Simek wrote: > Hi Simon, > > On 02/03/2015 03:02 AM, Masahiro Yamada wrote: > > Hi. > > > > > > On Mon, 2 Feb 2015 16:57:15 -0700 > > Simon Glass wrote: > > > >> Hi Michal, > >> > >> On 2 February 2015 at 08:31, Michal Simek wrote: > >>> Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA > >>> relocation (mostly only GOT) where functions aray are not > >>> updated. This patch is fixing function pointers for DM core > >>> and serial-uclass to ensure that relocated functions are called. > >>> > >>> Signed-off-by: Michal Simek > >>> --- > >>> > >>> drivers/core/root.c| 64 > >>> ++ > >>> drivers/serial/serial-uclass.c | 16 +++ > >>> 2 files changed, 80 insertions(+) > >> > >> How long will we have to carry this patch? It seems that if we add any > >> new driver we will have to add more code like this? > > > > > > > > This patch is unfortunate. > > Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day? > > This patch (or similar one) has to be alive when we have platform > which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. > There is an option to move to REL/RELA but the question is if > all platforms have it/support it. Unfortunately I think that > it will be in the tree for a long time. > > > > > If we use SPL, we do not have to relocate code, I think. > > SPL doesn't have relocation that's why this code is not used there. > It is not what I meant. If SPL can directly load the main u-boot image to the DRAM address where it is linked, we do not relocate the code in the main image. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Hi Simon, Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it? A quick grep yields a global define of CONFIG_NEEDS_MANUAL_RELOC for avr32, m68k, nds32, and sparc Next question is - which of these platforms have toolchains which lack the ability to generate the relocation tables that we need? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] arm: Allow reset init to be controlled
Some boards want to skip the normal reset init. For example OMAP4 SPL
does not want to touch VBAR and many boards don't want to set up
CP15.
Provide a return value from save_boot_params() which allows the board
to indicate what reset processing should be done.
Signed-off-by: Simon Glass
---
arch/arm/cpu/armv7/exynos/spl_boot.c | 5 -
arch/arm/cpu/armv7/start.S | 11 ---
arch/arm/include/asm/system.h| 15 +++
3 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c
b/arch/arm/cpu/armv7/exynos/spl_boot.c
index bc237c9..6e249f1 100644
--- a/arch/arm/cpu/armv7/exynos/spl_boot.c
+++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
@@ -309,4 +309,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
while (1)
;
}
-void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3) {}
+u32 save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
+{
+ return 0;
+}
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index c5f94ef..0ba26f7 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -52,6 +52,9 @@ reset:
* Continue to use ROM code vector only in OMAP4 spl)
*/
#if !(defined(CONFIG_OMAP44XX) && defined(CONFIG_SPL_BUILD))
+ teq r0, #RESET_SKIP_VBVAR
+ bne vbar_done
+
/* Set V=0 in CP15 SCTLR register - for VBAR to point to vector */
mrc p15, 0, r2, c1, c0, 0 @ Read CP15 SCTLR Register
bic r2, #CR_V @ V = 0
@@ -61,10 +64,11 @@ reset:
ldr r2, =_start
mcr p15, 0, r2, c12, c0, 0 @Set VBAR
#endif
-
+vbar_done:
/* the mask ROM code should have PLL and others stable */
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
- bl cpu_init_cp15
+ teq r0, #RESET_SKIP_CP15
+ bleqcpu_init_cp15
bl cpu_init_crit
#endif
@@ -88,11 +92,12 @@ ENDPROC(c_runtime_cpu_setup)
/*
*
- * void save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
+ * u32 save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
* __attribute__((weak));
*
* Stack pointer is not yet initialized at this moment
* Don't save anything to stack even if compiled with -O0
+ * Return flags - see RESET_... in system.h
*
*/
ENTRY(save_boot_params)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 89f2294..98e49a7 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -140,8 +140,23 @@ void flush_l3_cache(void);
*/
#define __asmeq(x, y) ".ifnc " x "," y " ; .err ; .endif\n\t"
+/* Control bits for reset processing */
+#define RESET_SKIP_VBVAR (1 << 0)/* Skip vector address setup */
+#define RESET_SKIP_CP15(1 << 1)/* Skip CP15 setup */
+
#ifndef __ASSEMBLY__
+/**
+ * save_boot_params() - Save boot parameters before starting reset sequence
+ *
+ * @r0:Value of r0
+ * @r1:Value of r1
+ * @r2:Value of r2
+ * @r3:Value of r3
+ * @return reset flags (see RESET_... above)
+ */
+u32 save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3);
+
#define isb() __asm__ __volatile__ ("" : : : "memory")
#define nop() __asm__ __volatile__("mov\tr0,r0\t@ nop\n\t");
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] sunxi: Move SPL s_init() code to board_init_f()
On Tue, 3 Feb 2015 17:55:52 -0700 Simon Glass wrote: > Hi, > > On 2 February 2015 at 22:29, Simon Glass wrote: > > Hi, > > > > On 2 February 2015 at 01:07, Hans de Goede wrote: > >> Hi Simon, Siarhei, > >> > >> On 01-02-15 21:59, Simon Glass wrote: > >>> > >>> Hi Siarhei, > >>> > >>> On 1 February 2015 at 11:37, Siarhei Siamashka > >>> > >> > >> > >> > >> > A comprehensive FEL usage guide is supposed to be in the linux-sunxi > wiki. But it might be not very up to date with the mainline u-boot > usage. > > Anyway, first just clone the https://github.com/linux-sunxi/sunxi-tools > repository and build it. This will provide you with the x86 binary of > the 'fel' tool, which is used on your desktop PC to talk with the > device. > > Then connect the device to your PC using a "USB A to USB mini/micro B" > cable. And reset the board while keeping the "FEL" button pressed. The > button might be labelled as "UPGRADE" on your pcduino3 board: > http://linux-sunxi.org/LinkSprite_pcDuino_V3#FEL_mode > > Then just run "fel ver" command: > http://linux-sunxi.org/FEL#Running_the_fel_tool > > If everything is fine, it should respond with something like this: > AWUSBFEX soc=00162500(A13) 0001 ver=0001 44 08 scratchpad=7e00 > > > Now you can use "write" commands to upload data to SRAM. And "exe" > command to execute functions on the device (works as some kind of RPC): > http://linux-sunxi.org/FEL/USBBoot#Manual_loading > > As a simple test, you can upload just a single "bx lr" instruction > (compiled in ARM mode) to the address 0x2000 and try to execute it. > In the case if your code screws up something and does not return > control to the BROM correctly, then the "fel" tool can't communicate > over USB anymore and just timeouts. Regarding the address space, you > can use SRAM addresses starting from 0x2000 up to something like 0x5E00 > (that's where the stack pointer is set). This was a description of a > "bare metal" FEL usage. > > Now as for the u-boot support. You can compile and run u-boot in the FEL > mode configuration on pcduino3 in the following way: > > make CROSS_COMPILE=arm-none-gnueabi- Linksprite_pcDuino3_felconfig > make CROSS_COMPILE=arm-none-gnueabi- -j2 > > fel write 0x2000 spl/u-boot-spl.bin > fel exe 0x2000 > > sleep 1 # Wait for DRAM initialization to complete > >>> > >>> > >>> i.e. wait for U-Boot SPL to return to the BROM? > >>> > > fel write 0x4a00 u-boot.bin > fel exe 0x4a00 > > Please note the use of '*_felconfig' instead of '*_defconfig'. > And also right now the FEL mode support is broken. That's why the > http://lists.denx.de/pipermail/u-boot/2015-January/203282.html > patchset tried to address this problem. > > >>> > >>> OK that looks like an excellent guide, thank you. I will make some time to > >>> take a more detailed look at this as soon as I can, but definitely in the > >>> next few days. > >> > >> > >> I've been reading all threads on this, thank you both for looking into > >> this, > >> since you're on it I'm going to leave this be (and not review / apply > >> Siarhei's patches for this), and we can revisit this later, with hopefully > >> a > >> better fix. > > > > Thanks to Siarhei's instructions I have a working setup with pcduino3. > > One less board where I have to swap SD cards. Can I suggest that it > > would be really nice to have a README.sunxi that covers all of this? > > > > Anyway I will fiddle around and see what I can come up with. > > The problem seems to be the start.S code 'Setup vector' and > cpu_init_cp15. If I remove these then FEL boots OK without all the > gdata/r9 stuff and with the rest of the boot flow normal. I don't quite follow this brief explanation. Could you perhaps attach/paste a patch or provide a link to some test branch with the code? > I would quite like FEL to be an option you enable, but we can detect > whether it is actually being used (as with Tegra and Exynos). FEL is already a Kconfig option, which can be enabled/disabled in menuconfig. Currently it also disables certain parts of code (MMC support) in order to reduce the SPL size. If these parts are all included (but deactivated via a runtime check), then the SPL binary becomes too large. > Perhaps checking the value of lr will allow this to work. Or by peeking into some of the MUSB hardware registers after the start of SPL. MUSB must be already initialized for FEL to work. However I'm still curious about how the SPL size problem is going to be addressed. > I'm not sure of the best way to skip the vector/cp15 setup. For now I > can do an #ifdef but I'm wondering if we should allow > save_boot_params() to return some flags indicating what should be > skipped? -- Best regards, Siarhei Siam
[U-Boot] [PATCH 3/5] arm: Allow lr to be saved by board code
The link register value can be required on some boards (e.g. FEL mode on sunxi) so stash it to r4 before jumping to save_boot_params(). Signed-off-by: Simon Glass --- arch/arm/cpu/armv7/start.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 0ba26f7..8207d66 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -33,6 +33,7 @@ .globl reset reset: + mov r4, lr bl save_boot_params /* * disable interrupts (FIQ and IRQ), also set the cpu to SVC32 mode, -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] sunxi: Move SPL s_init() code to board_init_f()
Hi Siarhei, On 3 February 2015 at 18:58, Siarhei Siamashka wrote: > On Tue, 3 Feb 2015 17:55:52 -0700 > Simon Glass wrote: > >> Hi, >> >> On 2 February 2015 at 22:29, Simon Glass wrote: >> > Hi, >> > >> > On 2 February 2015 at 01:07, Hans de Goede wrote: >> >> Hi Simon, Siarhei, >> >> >> >> On 01-02-15 21:59, Simon Glass wrote: >> >>> >> >>> Hi Siarhei, >> >>> >> >>> On 1 February 2015 at 11:37, Siarhei Siamashka >> >>> >> >> >> >> >> >> >> >> >> A comprehensive FEL usage guide is supposed to be in the linux-sunxi >> wiki. But it might be not very up to date with the mainline u-boot >> usage. >> >> Anyway, first just clone the https://github.com/linux-sunxi/sunxi-tools >> repository and build it. This will provide you with the x86 binary of >> the 'fel' tool, which is used on your desktop PC to talk with the >> device. >> >> Then connect the device to your PC using a "USB A to USB mini/micro B" >> cable. And reset the board while keeping the "FEL" button pressed. The >> button might be labelled as "UPGRADE" on your pcduino3 board: >> http://linux-sunxi.org/LinkSprite_pcDuino_V3#FEL_mode >> >> Then just run "fel ver" command: >> http://linux-sunxi.org/FEL#Running_the_fel_tool >> >> If everything is fine, it should respond with something like this: >> AWUSBFEX soc=00162500(A13) 0001 ver=0001 44 08 scratchpad=7e00 >> >> >> Now you can use "write" commands to upload data to SRAM. And "exe" >> command to execute functions on the device (works as some kind of RPC): >> http://linux-sunxi.org/FEL/USBBoot#Manual_loading >> >> As a simple test, you can upload just a single "bx lr" instruction >> (compiled in ARM mode) to the address 0x2000 and try to execute it. >> In the case if your code screws up something and does not return >> control to the BROM correctly, then the "fel" tool can't communicate >> over USB anymore and just timeouts. Regarding the address space, you >> can use SRAM addresses starting from 0x2000 up to something like 0x5E00 >> (that's where the stack pointer is set). This was a description of a >> "bare metal" FEL usage. >> >> Now as for the u-boot support. You can compile and run u-boot in the FEL >> mode configuration on pcduino3 in the following way: >> >> make CROSS_COMPILE=arm-none-gnueabi- Linksprite_pcDuino3_felconfig >> make CROSS_COMPILE=arm-none-gnueabi- -j2 >> >> fel write 0x2000 spl/u-boot-spl.bin >> fel exe 0x2000 >> >> sleep 1 # Wait for DRAM initialization to complete >> >>> >> >>> >> >>> i.e. wait for U-Boot SPL to return to the BROM? >> >>> >> >> fel write 0x4a00 u-boot.bin >> fel exe 0x4a00 >> >> Please note the use of '*_felconfig' instead of '*_defconfig'. >> And also right now the FEL mode support is broken. That's why the >> http://lists.denx.de/pipermail/u-boot/2015-January/203282.html >> patchset tried to address this problem. >> >> >>> >> >>> OK that looks like an excellent guide, thank you. I will make some time >> >>> to >> >>> take a more detailed look at this as soon as I can, but definitely in the >> >>> next few days. >> >> >> >> >> >> I've been reading all threads on this, thank you both for looking into >> >> this, >> >> since you're on it I'm going to leave this be (and not review / apply >> >> Siarhei's patches for this), and we can revisit this later, with >> >> hopefully a >> >> better fix. >> > >> > Thanks to Siarhei's instructions I have a working setup with pcduino3. >> > One less board where I have to swap SD cards. Can I suggest that it >> > would be really nice to have a README.sunxi that covers all of this? >> > >> > Anyway I will fiddle around and see what I can come up with. >> >> The problem seems to be the start.S code 'Setup vector' and >> cpu_init_cp15. If I remove these then FEL boots OK without all the >> gdata/r9 stuff and with the rest of the boot flow normal. > > I don't quite follow this brief explanation. Could you perhaps > attach/paste a patch or provide a link to some test branch with > the code? If you look at code in start.S it fiddles with cp15 and this seems to stuff up FEL. I'm not exactly sure what is breaking it, but we seem to need to skip that code. I will push what I have to a branch - I am just trying to tidy it up a bit. > >> I would quite like FEL to be an option you enable, but we can detect >> whether it is actually being used (as with Tegra and Exynos). > > FEL is already a Kconfig option, which can be enabled/disabled > in menuconfig. Currently it also disables certain parts of code > (MMC support) in order to reduce the SPL size. If these parts are > all included (but deactivated via a runtime check), then the SPL > binary becomes too large. OK. My point is that FEL support should not be such a pervasive option,
Re: [U-Boot] [PATCH v5 7/7] Exynos: Clock: Cleanup soc_get_periph_rate
Hi,
On 02/04/2015 03:30 PM, Akshay Saraswat wrote:
> Hi,
>
>> Hi Akshay,
>>
>> On 02/03/2015 05:27 PM, Akshay Saraswat wrote:
>>> Cleaning up soc_get_periph_rate to make the logic easy to
>>> comprehend.
>>>
>>
>> Could you give more detailed description?
>
> We did just a cleanup here by removing I2C sepecific calculations
> because we can now have a generic div and pre-div calculation.
> Only intention of doing it is making code clean and easily understandable.
> I don't know what else to write for that. Please suggest. :)
>
I mean you should write commit messages in detail about how is this
more easier logic?
>>
>>> Signed-off-by: Akshay Saraswat
>>> ---
>>> Changes since v4:
>>> - New patch.
>>>
>>> arch/arm/cpu/armv7/exynos/clock.c | 76
>>> +--
>>> 1 file changed, 33 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv7/exynos/clock.c
>>> b/arch/arm/cpu/armv7/exynos/clock.c
>>> index 3884d4b..8724bc7 100644
>>> --- a/arch/arm/cpu/armv7/exynos/clock.c
>>> +++ b/arch/arm/cpu/armv7/exynos/clock.c
>>> @@ -366,8 +366,8 @@ static struct clk_bit_info *get_clk_bit_info(int
>>> peripheral)
>>> static unsigned long exynos5_get_periph_rate(int peripheral)
>>> {
>>> struct clk_bit_info *bit_info = get_clk_bit_info(peripheral);
>>> - unsigned long sclk, sub_clk = 0;
>>> - unsigned int src, div, sub_div = 0;
>>> + unsigned long sclk = 0;
>>> + unsigned int src = 0, div = 0, sub_div = 0;
>>> struct exynos5_clock *clk =
>>> (struct exynos5_clock *)samsung_get_base_clock();
>>>
>>> @@ -389,30 +389,30 @@ static unsigned long exynos5_get_periph_rate(int
>>> peripheral)
>>> break;
>>> case PERIPH_ID_I2S0:
>>> src = readl(&clk->src_mau);
>>> - div = readl(&clk->div_mau);
>>> + div = sub_div = readl(&clk->div_mau);
>>> case PERIPH_ID_SPI0:
>>> case PERIPH_ID_SPI1:
>>> src = readl(&clk->src_peric1);
>>> - div = readl(&clk->div_peric1);
>>> + div = sub_div = readl(&clk->div_peric1);
>>> break;
>>> case PERIPH_ID_SPI2:
>>> src = readl(&clk->src_peric1);
>>> - div = readl(&clk->div_peric2);
>>> + div = sub_div = readl(&clk->div_peric2);
>>> break;
>>> case PERIPH_ID_SPI3:
>>> case PERIPH_ID_SPI4:
>>> src = readl(&clk->sclk_src_isp);
>>> - div = readl(&clk->sclk_div_isp);
>>> + div = sub_div = readl(&clk->sclk_div_isp);
>>> break;
>>> case PERIPH_ID_SDMMC0:
>>> case PERIPH_ID_SDMMC1:
>>> src = readl(&clk->src_fsys);
>>> - div = readl(&clk->div_fsys1);
>>> + div = sub_div = readl(&clk->div_fsys1);
>>> break;
>>> case PERIPH_ID_SDMMC2:
>>> case PERIPH_ID_SDMMC3:
>>> src = readl(&clk->src_fsys);
>>> - div = readl(&clk->div_fsys2);
>>> + div = sub_div = readl(&clk->div_fsys2);
>>> break;
>>> case PERIPH_ID_I2C0:
>>> case PERIPH_ID_I2C1:
>>> @@ -422,12 +422,10 @@ static unsigned long exynos5_get_periph_rate(int
>>> peripheral)
>>> case PERIPH_ID_I2C5:
>>> case PERIPH_ID_I2C6:
>>> case PERIPH_ID_I2C7:
>>> - sclk = exynos5_get_pll_clk(MPLL);
>>> - sub_div = ((readl(&clk->div_top1) >> bit_info->div_bit)
>>> - & bit_info->div_mask) + 1;
>>> - div = ((readl(&clk->div_top0) >> bit_info->prediv_bit)
>>> - & bit_info->prediv_mask) + 1;
>>> - return (sclk / sub_div) / div;
>>> + src = EXYNOS_SRC_MPLL;
>>> + div = readl(&clk->div_top0);
>>> + sub_div = readl(&clk->div_top1);
>>> + break;
>>> default:
>>> debug("%s: invalid peripheral %d", __func__, peripheral);
>>> return -1;
>>> @@ -446,29 +444,26 @@ static unsigned long exynos5_get_periph_rate(int
>>> peripheral)
>>> case EXYNOS_SRC_VPLL:
>>> sclk = exynos5_get_pll_clk(VPLL);
>>> break;
>>> - default:
>>> - return 0;
>>
>> Why remove? I think it's better to use default label and also how about
>> add debug log?
>
> Removing because anyways we are going to calculate & return 0 for non-existent
> src or sclk. I have initialized src and sclk above with value zero.
>
I think it's good coding style to use default case, later we can detect
wrong src cases when wrong any codes or read wrong values from register.
Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 7/7] Exynos: Clock: Cleanup soc_get_periph_rate
Hi,
>Hi Akshay,
>
>On 02/03/2015 05:27 PM, Akshay Saraswat wrote:
>> Cleaning up soc_get_periph_rate to make the logic easy to
>> comprehend.
>>
>
>Could you give more detailed description?
We did just a cleanup here by removing I2C sepecific calculations
because we can now have a generic div and pre-div calculation.
Only intention of doing it is making code clean and easily understandable.
I don't know what else to write for that. Please suggest. :)
>
>> Signed-off-by: Akshay Saraswat
>> ---
>> Changes since v4:
>> - New patch.
>>
>> arch/arm/cpu/armv7/exynos/clock.c | 76
>> +--
>> 1 file changed, 33 insertions(+), 43 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/exynos/clock.c
>> b/arch/arm/cpu/armv7/exynos/clock.c
>> index 3884d4b..8724bc7 100644
>> --- a/arch/arm/cpu/armv7/exynos/clock.c
>> +++ b/arch/arm/cpu/armv7/exynos/clock.c
>> @@ -366,8 +366,8 @@ static struct clk_bit_info *get_clk_bit_info(int
>> peripheral)
>> static unsigned long exynos5_get_periph_rate(int peripheral)
>> {
>> struct clk_bit_info *bit_info = get_clk_bit_info(peripheral);
>> -unsigned long sclk, sub_clk = 0;
>> -unsigned int src, div, sub_div = 0;
>> +unsigned long sclk = 0;
>> +unsigned int src = 0, div = 0, sub_div = 0;
>> struct exynos5_clock *clk =
>> (struct exynos5_clock *)samsung_get_base_clock();
>>
>> @@ -389,30 +389,30 @@ static unsigned long exynos5_get_periph_rate(int
>> peripheral)
>> break;
>> case PERIPH_ID_I2S0:
>> src = readl(&clk->src_mau);
>> -div = readl(&clk->div_mau);
>> +div = sub_div = readl(&clk->div_mau);
>> case PERIPH_ID_SPI0:
>> case PERIPH_ID_SPI1:
>> src = readl(&clk->src_peric1);
>> -div = readl(&clk->div_peric1);
>> +div = sub_div = readl(&clk->div_peric1);
>> break;
>> case PERIPH_ID_SPI2:
>> src = readl(&clk->src_peric1);
>> -div = readl(&clk->div_peric2);
>> +div = sub_div = readl(&clk->div_peric2);
>> break;
>> case PERIPH_ID_SPI3:
>> case PERIPH_ID_SPI4:
>> src = readl(&clk->sclk_src_isp);
>> -div = readl(&clk->sclk_div_isp);
>> +div = sub_div = readl(&clk->sclk_div_isp);
>> break;
>> case PERIPH_ID_SDMMC0:
>> case PERIPH_ID_SDMMC1:
>> src = readl(&clk->src_fsys);
>> -div = readl(&clk->div_fsys1);
>> +div = sub_div = readl(&clk->div_fsys1);
>> break;
>> case PERIPH_ID_SDMMC2:
>> case PERIPH_ID_SDMMC3:
>> src = readl(&clk->src_fsys);
>> -div = readl(&clk->div_fsys2);
>> +div = sub_div = readl(&clk->div_fsys2);
>> break;
>> case PERIPH_ID_I2C0:
>> case PERIPH_ID_I2C1:
>> @@ -422,12 +422,10 @@ static unsigned long exynos5_get_periph_rate(int
>> peripheral)
>> case PERIPH_ID_I2C5:
>> case PERIPH_ID_I2C6:
>> case PERIPH_ID_I2C7:
>> -sclk = exynos5_get_pll_clk(MPLL);
>> -sub_div = ((readl(&clk->div_top1) >> bit_info->div_bit)
>> -& bit_info->div_mask) + 1;
>> -div = ((readl(&clk->div_top0) >> bit_info->prediv_bit)
>> -& bit_info->prediv_mask) + 1;
>> -return (sclk / sub_div) / div;
>> +src = EXYNOS_SRC_MPLL;
>> +div = readl(&clk->div_top0);
>> +sub_div = readl(&clk->div_top1);
>> +break;
>> default:
>> debug("%s: invalid peripheral %d", __func__, peripheral);
>> return -1;
>> @@ -446,29 +444,26 @@ static unsigned long exynos5_get_periph_rate(int
>> peripheral)
>> case EXYNOS_SRC_VPLL:
>> sclk = exynos5_get_pll_clk(VPLL);
>> break;
>> -default:
>> -return 0;
>
>Why remove? I think it's better to use default label and also how about
>add debug log?
Removing because anyways we are going to calculate & return 0 for non-existent
src or sclk. I have initialized src and sclk above with value zero.
>
>> }
>>
>> -/* Ratio clock division for this peripheral */
>> -if (bit_info->div_bit >= 0) {
>> -sub_div = (div >> bit_info->div_bit) & bit_info->div_mask;
>> -sub_clk = sclk / (sub_div + 1);
>> -}
>> +/* Clock divider ratio for this peripheral */
>> +if (bit_info->div_bit >= 0)
>> +div = (div >> bit_info->div_bit) & bit_info->div_mask;
>>
>> -if (bit_info->prediv_bit >= 0) {
>> -div = (div >> bit_info->prediv_bit) & bit_info->prediv_mask;
>> -return sub_clk / (div + 1);
>> -}
>> +/* Clock pre-divider ratio for this peripheral */
>> +if (bit_info->prediv_bit >= 0)
>> +sub_div = (sub_div >> bit_info->prediv_bit)
>> + & bit_info->prediv_mask;
>>
>> -return sub_clk;
>> +/*
[U-Boot] [PATCH 1/3] mmc: dw_mmc: fixed the wrong bit control
If mode is not DDR-mode, then it needs to clear it. Signed-off-by: Jaehoon Chung --- drivers/mmc/dw_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c index b18c75d..76fa0b0 100644 --- a/drivers/mmc/dw_mmc.c +++ b/drivers/mmc/dw_mmc.c @@ -321,7 +321,7 @@ static void dwmci_set_ios(struct mmc *mmc) if (mmc->ddr_mode) regs |= DWMCI_DDR_MODE; else - regs &= DWMCI_DDR_MODE; + regs &= ~DWMCI_DDR_MODE; dwmci_writel(host, DWMCI_UHS_REG, regs); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] mmc: dw_mmc: fixed minor problems
This patchset fixed minor problems.
Included the previous patch("mmc: dw_mmc: fixed the wrong bit control")
Jaehoon Chung (3):
mmc: dw_mmc: fixed the wrong bit control
mmc: exynos_dw_mmc: set to clksel_val into board-init function
mmc: exynos_dw_mmc: use the exynos specific data structure
drivers/mmc/dw_mmc.c| 2 +-
drivers/mmc/exynos_dw_mmc.c | 60 -
include/dwmmc.h | 2 +-
3 files changed, 51 insertions(+), 13 deletions(-)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] mmc: exynos_dw_mmc: use the exynos specific data structure
Clksel value is exynos specific value.
It removed "clksel_val" into dwmci_host and created the
"dwmci_exynos_priv_data" structure for exynos specific data.
Signed-off-by: Jaehoon Chung
---
drivers/mmc/exynos_dw_mmc.c | 60 +++--
include/dwmmc.h | 2 +-
2 files changed, 48 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 3936660..c66c0b0 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -19,8 +19,13 @@
#defineDWMMC_MAX_CH_NUM4
#defineDWMMC_MAX_FREQ 5200
#defineDWMMC_MIN_FREQ 40
-#defineDWMMC_MMC0_CLKSEL_VAL 0x03030001
-#defineDWMMC_MMC2_CLKSEL_VAL 0x03020001
+#defineDWMMC_MMC0_SDR_TIMING_VAL 0x03030001
+#defineDWMMC_MMC2_SDR_TIMING_VAL 0x03020001
+
+/* Exynos implmentation specific drver private data */
+struct dwmci_exynos_priv_data {
+ u32 sdr_timing;
+};
/*
* Function used as callback function to initialise the
@@ -28,7 +33,9 @@
*/
static void exynos_dwmci_clksel(struct dwmci_host *host)
{
- dwmci_writel(host, DWMCI_CLKSEL, host->clksel_val);
+ struct dwmci_exynos_priv_data *priv = host->priv;
+
+ dwmci_writel(host, DWMCI_CLKSEL, priv->sdr_timing);
}
unsigned int exynos_dwmci_get_clk(struct dwmci_host *host)
@@ -55,6 +62,8 @@ unsigned int exynos_dwmci_get_clk(struct dwmci_host *host)
static void exynos_dwmci_board_init(struct dwmci_host *host)
{
+ struct dwmci_exynos_priv_data *priv = host->priv;
+
if (host->quirks & DWMCI_QUIRK_DISABLE_SMU) {
dwmci_writel(host, EMMCP_MPSBEGIN0, 0);
dwmci_writel(host, EMMCP_SEND0, 0);
@@ -65,8 +74,8 @@ static void exynos_dwmci_board_init(struct dwmci_host *host)
MPSCTRL_NON_SECURE_WRITE_BIT | MPSCTRL_VALID);
}
- /* Set to clksel_val at initial time */
- if (host->clksel_val)
+ /* Set to timing value at initial time */
+ if (priv->sdr_timing)
exynos_dwmci_clksel(host);
}
@@ -74,6 +83,7 @@ static int exynos_dwmci_core_init(struct dwmci_host *host,
int index)
{
unsigned int div;
unsigned long freq, sclk;
+ struct dwmci_exynos_priv_data *priv = host->priv;
if (host->bus_hz)
freq = host->bus_hz;
@@ -92,11 +102,11 @@ static int exynos_dwmci_core_init(struct dwmci_host *host,
int index)
#endif
host->board_init = exynos_dwmci_board_init;
- if (!host->clksel_val) {
+ if (!priv->sdr_timing) {
if (index == 0)
- host->clksel_val = DWMMC_MMC0_CLKSEL_VAL;
+ priv->sdr_timing = DWMMC_MMC0_SDR_TIMING_VAL;
else if (index == 2)
- host->clksel_val = DWMMC_MMC2_CLKSEL_VAL;
+ priv->sdr_timing = DWMMC_MMC2_SDR_TIMING_VAL;
}
host->caps = MMC_MODE_DDR_52MHz;
@@ -122,6 +132,7 @@ static int exynos_dwmci_core_init(struct dwmci_host *host,
int index)
int exynos_dwmci_add_port(int index, u32 regbase, int bus_width, u32 clksel)
{
struct dwmci_host *host = NULL;
+ struct dwmci_exynos_priv_data *priv;
host = malloc(sizeof(struct dwmci_host));
if (!host) {
@@ -129,11 +140,19 @@ int exynos_dwmci_add_port(int index, u32 regbase, int
bus_width, u32 clksel)
return -ENOMEM;
}
+ priv = malloc(sizeof(struct dwmci_exynos_priv_data));
+ if (!priv) {
+ error("dwmci_exynos_priv_data malloc fail!\n");
+ return -ENOMEM;
+ }
+
host->ioaddr = (void *)regbase;
host->buswidth = bus_width;
if (clksel)
- host->clksel_val = clksel;
+ priv->sdr_timing = clksel;
+
+ host->priv = priv;
return exynos_dwmci_core_init(host, index);
}
@@ -161,7 +180,14 @@ static int exynos_dwmci_get_config(const void *blob, int
node,
struct dwmci_host *host)
{
int err = 0;
- u32 base, clksel_val, timing[3];
+ u32 base, timing[3];
+ struct dwmci_exynos_priv_data *priv;
+
+ priv = malloc(sizeof(struct dwmci_exynos_priv_data));
+ if (!priv) {
+ error("dwmci_exynos_priv_data malloc fail!\n");
+ return -ENOMEM;
+ }
/* Extract device id for each mmc channel */
host->dev_id = pinmux_decode_periph_id(blob, node);
@@ -194,16 +220,24 @@ static int exynos_dwmci_get_config(const void *blob, int
node,
return -EINVAL;
}
- clksel_val = (DWMCI_SET_SAMPLE_CLK(timing[0]) |
+ priv->sdr_timing = (DWMCI_SET_SAMPLE_CLK(timing[0]) |
DWMCI_SET_DRV_CLK(timing[1]) |
DWMCI_SET_DIV_RATIO(timing[2]));
- if (clksel_val)
Re: [U-Boot] [PATCH v2] intern: Add copy scripts and target specific helpers
Heiko, what a great tool :-) This makes the whole thing much easier and will produce (hopefully) less noise from me :-) But i 've a further questions: 1st) patman prints out some errors, looks like for me that something is wrong with the first line of my commit message - but no idea what. " Traceback (most recent call last): File "tools/patman/patman", line 149, in options.add_maintainers) File "/home/petermaierh/work/u-boot/tools/patman/series.py", line 227, in MakeCcFile raise_on_error=raise_on_error) File "/home/petermaierh/work/u-boot/tools/patman/gitutil.py", line 321, in BuildEmailList raw += LookupEmail(item, alias, raise_on_error=raise_on_error) File "/home/petermaierh/work/u-boot/tools/patman/gitutil.py", line 490, in LookupEmail raise ValueError, msg ValueError: Alias 'drivers/video/am335x-fb' not found " maybe you've or somebody else has an idea how to fix this ? 2nd) How to achieve "not breaking threading" ? How the right "in-reply-to" is added to git-send-email ? from where comes this information. I've seen at my last V2 that i don't have reached the goal. many thanks and best regards, Hannes Heiko Schocher schrieb am 03.02.2015 13:47:02: > From: Heiko Schocher > To: Hannes Petermaier > Cc: Hannes Petermaier , u-boot@lists.denx.de, U-Boot boun...@lists.denx.de> > Date: 03.02.2015 13:47 > Subject: Re: [U-Boot] [PATCH v2] intern: Add copy scripts and target specific helpers > > Hello Hannes, > > Am 03.02.2015 13:37, schrieb Hannes Petermaier: > > Hi all, > > > > please ignore this "internal" patch. > > This is was an accident. > > Maybe it is worth to look into patman, see: > u-boot:/tools/patman/README ? > > bye, > Heiko > > > > best regards, > > Hannes > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > > > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 01/13] lcd: move platform-specific structs to their own headers
On 02/03/2015 07:32 PM, Nikita Kiryanov wrote:
common/lcd code is full of platform-specific code and definitions, which
ideally should reside with the respective driver code. Take a step towards that
goal by moving platform-specific structs from lcd.h to their own header files.
The structs for the generic case (the #else for all the platform-specific
cases) is retained in lcd.h as the default case.
Signed-off-by: Nikita Kiryanov
Reviewed-by: Simon Glass
Cc: Bo Shen
Cc: Simon Glass
Cc: Anatolij Gustschin
For Atmel part, tested ok on at91sam9g35ek.
Tested-by: Bo Shen
---
Changes in V2:
- Minor commit message update
include/atmel_lcd.h | 38 ++
include/exynos_lcd.h | 81 +
include/lcd.h| 201 ++-
include/mpc823_lcd.h | 43 +++
include/pxa_lcd.h| 80
5 files changed, 247 insertions(+), 196 deletions(-)
create mode 100644 include/atmel_lcd.h
create mode 100644 include/exynos_lcd.h
create mode 100644 include/mpc823_lcd.h
create mode 100644 include/pxa_lcd.h
diff --git a/include/atmel_lcd.h b/include/atmel_lcd.h
new file mode 100644
index 000..fa8aa29
--- /dev/null
+++ b/include/atmel_lcd.h
@@ -0,0 +1,38 @@
+/*
+ * atmel_lcd.h - Atmel LCD Controller structures
+ *
+ * (C) Copyright 2001
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _ATMEL_LCD_H_
+#define _ATMEL_LCD_H_
+
+typedef struct vidinfo {
+ ushort vl_col; /* Number of columns (i.e. 640) */
+ ushort vl_row; /* Number of rows (i.e. 480) */
+ u_long vl_clk; /* pixel clock in ps*/
+
+ /* LCD configuration register */
+ u_long vl_sync; /* Horizontal / vertical sync */
+ u_long vl_bpix; /* Bits per pixel, 0 = 1, 1 = 2, 2 = 4, 3 = 8, 4 = 16 */
+ u_long vl_tft; /* 0 = passive, 1 = TFT */
+ u_long vl_cont_pol_low; /* contrast polarity is low */
+ u_long vl_clk_pol; /* clock polarity */
+
+ /* Horizontal control register. */
+ u_long vl_hsync_len;/* Length of horizontal sync */
+ u_long vl_left_margin; /* Time from sync to picture */
+ u_long vl_right_margin; /* Time from picture to sync */
+
+ /* Vertical control register. */
+ u_long vl_vsync_len;/* Length of vertical sync */
+ u_long vl_upper_margin; /* Time from sync to picture */
+ u_long vl_lower_margin; /* Time from picture to sync */
+
+ u_long mmio; /* Memory mapped registers */
+} vidinfo_t;
+
+#endif
diff --git a/include/exynos_lcd.h b/include/exynos_lcd.h
new file mode 100644
index 000..cf389da
--- /dev/null
+++ b/include/exynos_lcd.h
@@ -0,0 +1,81 @@
+/*
+ * exynos_lcd.h - Exynos LCD Controller structures
+ *
+ * (C) Copyright 2001
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _EXYNOS_LCD_H_
+#define _EXYNOS_LCD_H_
+
+enum {
+ FIMD_RGB_INTERFACE = 1,
+ FIMD_CPU_INTERFACE = 2,
+};
+
+enum exynos_fb_rgb_mode_t {
+ MODE_RGB_P = 0,
+ MODE_BGR_P = 1,
+ MODE_RGB_S = 2,
+ MODE_BGR_S = 3,
+};
+
+typedef struct vidinfo {
+ ushort vl_col; /* Number of columns (i.e. 640) */
+ ushort vl_row; /* Number of rows (i.e. 480) */
+ ushort vl_width;/* Width of display area in millimeters */
+ ushort vl_height; /* Height of display area in millimeters */
+
+ /* LCD configuration register */
+ u_char vl_freq; /* Frequency */
+ u_char vl_clkp; /* Clock polarity */
+ u_char vl_oep; /* Output Enable polarity */
+ u_char vl_hsp; /* Horizontal Sync polarity */
+ u_char vl_vsp; /* Vertical Sync polarity */
+ u_char vl_dp; /* Data polarity */
+ u_char vl_bpix; /* Bits per pixel */
+
+ /* Horizontal control register. Timing from data sheet */
+ u_char vl_hspw; /* Horz sync pulse width */
+ u_char vl_hfpd; /* Wait before of line */
+ u_char vl_hbpd; /* Wait end of line */
+
+ /* Vertical control register. */
+ u_char vl_vspw;/* Vertical sync pulse width */
+ u_char vl_vfpd;/* Wait before of frame */
+ u_char vl_vbpd;/* Wait end of frame */
+ u_char vl_cmd_allow_len; /* Wait end of frame */
+
+ unsigned int win_id;
+ unsigned int init_delay;
+ unsigned int power_on_delay;
+ unsigned int reset_delay;
+ unsigned int interface_mode;
+ unsigned int mipi_enabled;
+ unsigned int dp_enabled;
+ unsigned int cs_setup;
+ unsigned int wr_setup;
+ unsigned int wr_act;
+ unsigned int wr_hold;
+ unsigned int logo_on;
+ unsigned int logo_width;
+ unsigned int logo_height;
+ in
[U-Boot] [PATCH 2/3] mmc: exynos_dw_mmc: set to clksel_val into board-init function
"clksel_val" is assigned to property of mmc or defined value. But it doesn't write at initial sequence. There is a reason that get the wrong source-clock value. This patch fixed it. Signed-off-by: Jaehoon Chung --- drivers/mmc/exynos_dw_mmc.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c index dfa209b..3936660 100644 --- a/drivers/mmc/exynos_dw_mmc.c +++ b/drivers/mmc/exynos_dw_mmc.c @@ -64,6 +64,10 @@ static void exynos_dwmci_board_init(struct dwmci_host *host) MPSCTRL_NON_SECURE_READ_BIT | MPSCTRL_NON_SECURE_WRITE_BIT | MPSCTRL_VALID); } + + /* Set to clksel_val at initial time */ + if (host->clksel_val) + exynos_dwmci_clksel(host); } static int exynos_dwmci_core_init(struct dwmci_host *host, int index) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Let's bury CONFIG_NEEDS_MANUAL_RELOC
Hi Guys, Since I did the initial 'full relocation' for x86 way back when (http://git.denx.de/?p=u-boot.git;a=commit;h=1c409bc7101a24ecd47a13a4e851845d66dc23ce), there has been a lot of chatter about the ongoing need for CONFIG_NEEDS_MANUAL_RELOC. I think it's about time we looked really hard at this define and come to a definitive conclusion as to IF and HOW we can get rid of it for the remaining architectures that use it (being avr32, m68k, nds32, and sparc). First, a bit of a primer on why and how I finally killed off CONFIG_NEEDS_MANUAL_RELOC for x86... Despite the best intentions of the 'manual' relocation performed by U-Boot, there were still instances where the U-Boot binary referenced the 'unrelocated' image which typically resides in flash (NOR flash in the case of the x86 board I was using). I only finally tracked this down through some arduous debugging of random crashes during the writing of a new U-Boot image to the NOR flash. After a lot of digging around, I managed to get a good understanding of the ELF binary format for x86 and compiler/linker flags needed in order to generate a binary image that could be relocated. It turns out that for x86, it was the -pic and --emit-relocs ld flags (Oddly, I cannot find the -pic flag in the gnu ld documentation maybe it's depricated?) The --emit-relocs flags leaves the relocation sections (for x86 the section of interest is .rela.dyn) in the final image. These sections list all the locations in the final binary that need to be adjusted if the image is loaded at a different address than the one it is compiled for. You can see the processing in do_elf_reloc_fixups() in arch/x86/lib/relocate.c Keep in mind that the relocation sections are NOT copied to RAM - they are only used once after U-Boot is copied to RAM to locate the memory locations that need to be adjusted. So the crux of generic relocation is to generate a stripped binary with all necessary ELF relocation information located AFTER the text and data sections which are copied to RAM So the first question that we need to answer is: Do the avr32, m68k, nds32, and sparc toolchains support the generation of the relevant sections needed to perform relocation in a manner similar to x86 (i.e generation of relocation references into sections of the final U-Boot binary)? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] RSA depends on DM
On Tue, Feb 3, 2015 at 5:01 PM, Simon Glass wrote: > We certainly must avoid the build break. > > My concern is that CONFIG_DM may introduce a run-time break. For > example if you don't have pre-relocation malloc() available the board > may not boot. Driver model is a fundamental core feature, and we are > working to move everything over to it, but I'm not quite comfortable > with forcing it on when someone changes a feature. It feel it would be > better to not offer it. > > I'm interested to hear other viewpoints though. > > Perhaps soon we can enable CONFIG_DM globally but we are not there yet. I appreciate the caution. For now, vexpress works with qemu which means I can get back to playing with verified boot. I haven't checked to see if it's possible to make RSA not always require DM - I defer to those who know the code better than I do. -C -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 02/13] lcd: split configuration_get_cmap
Hi Nikita Kiryanov,
On 02/03/2015 07:32 PM, Nikita Kiryanov wrote:
configuration_get_cmap() is multiple platform-specific functions stuffed into
one function. Split it into multiple versions, and move each version to the
appropriate driver to reduce the #ifdef complexity.
Signed-off-by: Nikita Kiryanov
Reviewed-by: Simon Glass
Cc: Bo Shen
Cc: Simon Glass
Cc: Anatolij Gustschin
---
Changes in V2:
- Minor commit message update
- ushort *configuration_get_cmap(void) prototype is defined only once
instead of for each #ifdef CONFIG_*
common/lcd.c | 19 ---
drivers/video/atmel_hlcdfb.c | 13 +
drivers/video/atmel_lcdfb.c | 5 +
drivers/video/exynos_fb.c| 9 +
drivers/video/mpc8xx_lcd.c | 7 +++
drivers/video/pxa_lcd.c | 6 ++
include/lcd.h| 7 +++
7 files changed, 47 insertions(+), 19 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 1195a54..0f6c2e4 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -383,25 +383,6 @@ int lcd_getbgcolor(void)
//
/* ** Chipset depending Bitmap / Logo stuff... */
//
-static inline ushort *configuration_get_cmap(void)
-{
-#if defined CONFIG_CPU_PXA
- struct pxafb_info *fbi = &panel_info.pxa;
- return (ushort *)fbi->palette;
-#elif defined(CONFIG_MPC823)
- immap_t *immr = (immap_t *) CONFIG_SYS_IMMR;
- cpm8xx_t *cp = &(immr->im_cpm);
- return (ushort *)&(cp->lcd_cmap[255 * sizeof(ushort)]);
-#elif defined(CONFIG_ATMEL_LCD)
- return (ushort *)(panel_info.mmio + ATMEL_LCDC_LUT(0));
-#elif !defined(CONFIG_ATMEL_HLCD) && !defined(CONFIG_EXYNOS_FB)
- return panel_info.cmap;
-#elif defined(CONFIG_LCD_LOGO)
- return bmp_logo_palette;
-#else
- return NULL;
-#endif
-}
#ifdef CONFIG_LCD_LOGO
void bitmap_plot(int x, int y)
diff --git a/drivers/video/atmel_hlcdfb.c b/drivers/video/atmel_hlcdfb.c
index 935ae42..0ce2370 100644
--- a/drivers/video/atmel_hlcdfb.c
+++ b/drivers/video/atmel_hlcdfb.c
@@ -13,6 +13,10 @@
#include
#include
+#if defined(CONFIG_LCD_LOGO)
+#include
+#endif
I think we can include this file directly.
/* configurable parameters */
#define ATMEL_LCDC_CVAL_DEFAULT 0xc8
#define ATMEL_LCDC_DMA_BURST_LEN 8
@@ -37,6 +41,15 @@ void lcd_setcolreg(ushort regno, ushort red, ushort green,
ushort blue)
panel_info.mmio + ATMEL_LCDC_LUT(regno));
}
+ushort *configuration_get_cmap(void)
+{
+#if defined(CONFIG_LCD_LOGO)
+ return bmp_logo_palette;
+#else
+ return NULL;
+#endif
+}
Here, I think no need to do the CONFIG_LCD_LOGO check, return
bmp_logo_palette directly, as it will be used when use bmp command in 8
bit mode. However, no hardware to test LCDC work or not in 8 bit mode :(
void lcd_ctrl_init(void *lcdbase)
{
unsigned long value;
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 3cf008c..fa6a82c 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -29,6 +29,11 @@
#define lcdc_readl(mmio, reg) __raw_readl((mmio)+(reg))
#define lcdc_writel(mmio, reg, val) __raw_writel((val), (mmio)+(reg))
+ushort *configuration_get_cmap(void)
+{
+ return (ushort *)(panel_info.mmio + ATMEL_LCDC_LUT(0));
+}
+
void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
{
#if defined(CONFIG_ATMEL_LCD_BGR555)
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index be35b98..c5d7330 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -37,6 +37,15 @@ vidinfo_t panel_info = {
};
#endif
+ushort *configuration_get_cmap(void)
+{
+#if defined(CONFIG_LCD_LOGO)
+ return bmp_logo_palette;
+#else
+ return NULL;
+#endif
+}
+
static void exynos_lcd_init_mem(void *lcdbase, vidinfo_t *vid)
{
unsigned long palette_size;
diff --git a/drivers/video/mpc8xx_lcd.c b/drivers/video/mpc8xx_lcd.c
index add7215..9d2e5ed 100644
--- a/drivers/video/mpc8xx_lcd.c
+++ b/drivers/video/mpc8xx_lcd.c
@@ -357,6 +357,13 @@ lcd_setcolreg (ushort regno, ushort red, ushort green,
ushort blue)
/*--*/
+ushort *configuration_get_cmap(void)
+{
+ immap_t *immr = (immap_t *)CONFIG_SYS_IMMR;
+ cpm8xx_t *cp = &(immr->im_cpm);
+ return (ushort *)&(cp->lcd_cmap[255 * sizeof(ushort)]);
+}
+
void lcd_enable (void)
{
volatile immap_t *immr = (immap_t *) CONFIG_SYS_IMMR;
diff --git a/drivers/video/pxa_lcd.c b/drivers/video/pxa_lcd.c
index f66f615..04105d4 100644
--- a/drivers/video/pxa_lcd.c
+++ b/drivers/video/pxa_lcd.c
@@ -342,6 +342,12 @@ static int pxafb_init (vidinfo_t *vid);
/* --- PXA chipset specific functions
Re: [U-Boot] [PATCH v2] intern: Add copy scripts and target specific helpers
Hello Hannes, Am 04.02.2015 08:10, schrieb Hannes Petermaier: Heiko, what a great tool :-) Yep, definitely... Thanks to Simon! This makes the whole thing much easier and will produce (hopefully) less noise from me :-) ;-) But i 've a further questions: 1st) patman prints out some errors, looks like for me that something is wrong with the first line of my commit message - but no idea what. " Traceback (most recent call last): File "tools/patman/patman", line 149, in options.add_maintainers) File "/home/petermaierh/work/u-boot/tools/patman/series.py", line 227, in MakeCcFile raise_on_error=raise_on_error) File "/home/petermaierh/work/u-boot/tools/patman/gitutil.py", line 321, in BuildEmailList raw += LookupEmail(item, alias, raise_on_error=raise_on_error) File "/home/petermaierh/work/u-boot/tools/patman/gitutil.py", line 490, in LookupEmail raise ValueError, msg ValueError: Alias 'drivers/video/am335x-fb' not found " maybe you've or somebody else has an idea how to fix this ? I am not really a python coder ... and I do not see such an error, if I create a commit with changes in "drivers/video/am335x-fb.c" I got not this error ... my first thought it was the "drivers/video/am335x-fb:" in your subject line... but I used the same subject for a test commit ... please try another subject line: "drivers, video, am335x: ..." ? How does your patman config file looks like? 2nd) How to achieve "not breaking threading" ? How the right "in-reply-to" is added to git-send-email ? from where comes this information. I've seen at my last V2 that i don't have reached the goal. Hmm... I am not sure, maybe this is a ToDo? Simon? Could you help here? Thanks! bye, Heiko many thanks and best regards, Hannes Heiko Schocher schrieb am 03.02.2015 13:47:02: From: Heiko Schocher To: Hannes Petermaier Cc: Hannes Petermaier , u-boot@lists.denx.de, U-Boot boun...@lists.denx.de> Date: 03.02.2015 13:47 Subject: Re: [U-Boot] [PATCH v2] intern: Add copy scripts and target specific helpers Hello Hannes, Am 03.02.2015 13:37, schrieb Hannes Petermaier: Hi all, please ignore this "internal" patch. This is was an accident. Maybe it is worth to look into patman, see: u-boot:/tools/patman/README ? bye, Heiko best regards, Hannes ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] RSA depends on DM
Hello Simon, On Tue, 3 Feb 2015 18:01:49 -0700, Simon Glass wrote: > Hi Chris, > > On 3 February 2015 at 17:57, Chris Kuethe wrote: > > On Tue, Feb 3, 2015 at 4:38 PM, Simon Glass wrote: > >> +Masahiro > >> > >> Hi Chris, > >> > >> On 3 February 2015 at 00:42, Chris Kuethe wrote: > >>> Discovered while experimenting with signature checking on vexpress > >>> which doesn't typically use DM. Rather than complaining about unmet > >>> dependencies it might be better to enable those them. > >>> > >>> --- > >>> lib/rsa/Kconfig | 1 + > >>> 1 file changed, 1 insertion(+) > >>> > >>> diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig > >>> index 1268a1b..4db5da4 100644 > >>> --- a/lib/rsa/Kconfig > >>> +++ b/lib/rsa/Kconfig > >>> @@ -2,6 +2,7 @@ config RSA > >>> bool "Use RSA Library" > >>> select RSA_FREESCALE_EXP if FSL_CAAM > >>> select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP > >>> + select DM > >>> help > >>>RSA support. This enables the RSA algorithm used for FIT image > >>>verification in U-Boot. > >> > >> I wonder whether 'depends on DM' might be better? It seems odd to have > >> the tail wagging the dog. > >> > >> Regards, > >> Simon > > > > No, that would not be better because a few lines down, > > RSA_SOFTWARE_EXP and RSA_FREESCALE_EXP both say "depends on DM" but > > they don't actually enable it if they need it. > > > > As a user, my expectation is that when I turn on some high level > > feature, that will enable all of its lower level dependencies. Would > > it be less strange to make FIT_SIGNATURE turn on DM instead of RSA? > > We certainly must avoid the build break. > > My concern is that CONFIG_DM may introduce a run-time break. I can tell it does. :) > For example if you don't have pre-relocation malloc() available the > board may not boot. Driver model is a fundamental core feature, and we > are working to move everything over to it, but I'm not quite comfortable > with forcing it on when someone changes a feature. It feel it would be > better to not offer it. > > I'm interested to hear other viewpoints though. Agreed for me: no board should have DM enabled 'behind its back'. If RSA depends on DM, then the make menuconfig user should be unable to select RSA unless and until (s)he has selected DM (and the RSA help should make it clear that the board must support DM, and that just enabling CONFIG_DM probably won't be enough). > Perhaps soon we can enable CONFIG_DM globally but we are not there yet. > > Regards, > Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 03/13] lcd: atmel: move atmel-specific fb_put_word to atmel_lcdfb
On 02/03/2015 07:32 PM, Nikita Kiryanov wrote:
Reduce the amount of platform-specific code in common/lcd.c by moving Atmel
implementation of fb_put_word() to atmel_lcdfb.c. Since we must also have a
default implementation for everybody else, make the remainder of the code
into a weak function.
Signed-off-by: Nikita Kiryanov
Reviewed-by: Simon Glass
Cc: Bo Shen
Cc: Simon Glass
Cc: Anatolij Gustschin
Acked-by: Bo Shen
---
Changes in V2:
- Minor commit message update
common/lcd.c| 11 +--
drivers/video/atmel_lcdfb.c | 9 +
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 0f6c2e4..f17b35b 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -642,20 +642,11 @@ static void lcd_display_rle8_bitmap(bmp_image_t *bmp,
ushort *cmap, uchar *fb,
#endif
#if defined(CONFIG_BMP_16BPP)
-#if defined(CONFIG_ATMEL_LCD_BGR555)
-static inline void fb_put_word(uchar **fb, uchar **from)
-{
- *(*fb)++ = (((*from)[0] & 0x1f) << 2) | ((*from)[1] & 0x03);
- *(*fb)++ = ((*from)[0] & 0xe0) | (((*from)[1] & 0x7c) >> 2);
- *from += 2;
-}
-#else
-static inline void fb_put_word(uchar **fb, uchar **from)
+__weak void fb_put_word(uchar **fb, uchar **from)
{
*(*fb)++ = *(*from)++;
*(*fb)++ = *(*from)++;
}
-#endif
#endif /* CONFIG_BMP_16BPP */
int lcd_display_bitmap(ulong bmp_image, int x, int y)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index fa6a82c..c7991cd 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -34,6 +34,15 @@ ushort *configuration_get_cmap(void)
return (ushort *)(panel_info.mmio + ATMEL_LCDC_LUT(0));
}
+#if defined(CONFIG_BMP_16BPP) && defined(CONFIG_ATMEL_LCD_BGR555)
+void fb_put_word(uchar **fb, uchar **from)
+{
+ *(*fb)++ = (((*from)[0] & 0x1f) << 2) | ((*from)[1] & 0x03);
+ *(*fb)++ = ((*from)[0] & 0xe0) | (((*from)[1] & 0x7c) >> 2);
+ *from += 2;
+}
+#endif
+
void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
{
#if defined(CONFIG_ATMEL_LCD_BGR555)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] ARM: atmel: arm9: switch to use common timer functions
Signed-off-by: Bo Shen
---
Changes in v2: None
arch/arm/cpu/arm926ejs/at91/timer.c | 59
arch/arm/include/asm/arch-at91/at91sam9260.h | 3 ++
arch/arm/include/asm/arch-at91/at91sam9261.h | 3 ++
arch/arm/include/asm/arch-at91/at91sam9263.h | 3 ++
arch/arm/include/asm/arch-at91/at91sam9g45.h | 3 ++
arch/arm/include/asm/arch-at91/at91sam9rl.h | 3 ++
arch/arm/include/asm/arch-at91/at91sam9x5.h | 3 ++
7 files changed, 18 insertions(+), 59 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/timer.c
b/arch/arm/cpu/arm926ejs/at91/timer.c
index b0b7fb9..31ce646 100644
--- a/arch/arm/cpu/arm926ejs/at91/timer.c
+++ b/arch/arm/cpu/arm926ejs/at91/timer.c
@@ -33,22 +33,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define TIMER_LOAD_VAL 0xf
-static inline unsigned long long tick_to_time(unsigned long long tick)
-{
- tick *= CONFIG_SYS_HZ;
- do_div(tick, gd->arch.timer_rate_hz);
-
- return tick;
-}
-
-static inline unsigned long long usec_to_tick(unsigned long long usec)
-{
- usec *= gd->arch.timer_rate_hz;
- do_div(usec, 100);
-
- return usec;
-}
-
/*
* Use the PITC in full 32 bit incrementing mode
*/
@@ -64,54 +48,11 @@ int timer_init(void)
writel(TIMER_LOAD_VAL | AT91_PIT_MR_EN , &pit->mr);
gd->arch.timer_rate_hz = gd->arch.mck_rate_hz / 16;
- gd->arch.tbu = gd->arch.tbl = 0;
return 0;
}
/*
- * Get the current 64 bit timer tick count
- */
-unsigned long long get_ticks(void)
-{
- at91_pit_t *pit = (at91_pit_t *) ATMEL_BASE_PIT;
-
- ulong now = readl(&pit->piir);
-
- /* increment tbu if tbl has rolled over */
- if (now < gd->arch.tbl)
- gd->arch.tbu++;
- gd->arch.tbl = now;
- return (((unsigned long long)gd->arch.tbu) << 32) | gd->arch.tbl;
-}
-
-void __udelay(unsigned long usec)
-{
- unsigned long long start;
- ulong tmo;
-
- start = get_ticks();/* get current timestamp */
- tmo = usec_to_tick(usec); /* convert usecs to ticks */
- while ((get_ticks() - start) < tmo)
- ; /* loop till time has passed */
-}
-
-/*
- * get_timer(base) can be used to check for timeouts or
- * to measure elasped time relative to an event:
- *
- * ulong start_time = get_timer(0) sets start_time to the current
- * time value.
- * get_timer(start_time) returns the time elapsed since then.
- *
- * The time is used in CONFIG_SYS_HZ units!
- */
-ulong get_timer(ulong base)
-{
- return tick_to_time(get_ticks()) - base;
-}
-
-/*
* Return the number of timer ticks per second.
*/
ulong get_tbclk(void)
diff --git a/arch/arm/include/asm/arch-at91/at91sam9260.h
b/arch/arm/include/asm/arch-at91/at91sam9260.h
index 8950d67..1a4e84b 100644
--- a/arch/arm/include/asm/arch-at91/at91sam9260.h
+++ b/arch/arm/include/asm/arch-at91/at91sam9260.h
@@ -133,6 +133,9 @@
#define ATMEL_BASE_CS6 0x7000
#define ATMEL_BASE_CS7 0x8000
+/* Timer */
+#define CONFIG_SYS_TIMER_COUNTER 0xfd3c
+
/*
* Other misc defines
*/
diff --git a/arch/arm/include/asm/arch-at91/at91sam9261.h
b/arch/arm/include/asm/arch-at91/at91sam9261.h
index 6dfcf4c..914a3b0 100644
--- a/arch/arm/include/asm/arch-at91/at91sam9261.h
+++ b/arch/arm/include/asm/arch-at91/at91sam9261.h
@@ -117,6 +117,9 @@
#define ATMEL_BASE_CS6 0x7000
#define ATMEL_BASE_CS7 0x8000
+/* Timer */
+#define CONFIG_SYS_TIMER_COUNTER 0xfd3c
+
/*
* Other misc defines
*/
diff --git a/arch/arm/include/asm/arch-at91/at91sam9263.h
b/arch/arm/include/asm/arch-at91/at91sam9263.h
index 64a3888..71675ab 100644
--- a/arch/arm/include/asm/arch-at91/at91sam9263.h
+++ b/arch/arm/include/asm/arch-at91/at91sam9263.h
@@ -132,6 +132,9 @@
#define ATMEL_BASE_CS6 0x7000
#define ATMEL_BASE_CS7 0x8000
+/* Timer */
+#define CONFIG_SYS_TIMER_COUNTER 0xfd3c
+
/*
* Other misc defines
*/
diff --git a/arch/arm/include/asm/arch-at91/at91sam9g45.h
b/arch/arm/include/asm/arch-at91/at91sam9g45.h
index 6df8cdb..cf1c73f 100644
--- a/arch/arm/include/asm/arch-at91/at91sam9g45.h
+++ b/arch/arm/include/asm/arch-at91/at91sam9g45.h
@@ -136,6 +136,9 @@
#define ATMEL_BASE_CS6 0x7000
#define ATMEL_BASE_CS7 0x8000
+/* Timer */
+#define CONFIG_SYS_TIMER_COUNTER 0xfd3c
+
/*
* Other misc defines
*/
diff --git a/arch/arm/include/asm/arch-at91/at91sam9rl.h
b/arch/arm/include/asm/arch-at91/at91sam9rl.h
index 3a8e6d6..70bbf4e 100644
--- a/arch/arm/include/asm/arch-at91/at91sam9rl.h
+++ b/arch/arm/include/asm/arch-at91/at91sam9rl.h
@@ -116,6 +116,9 @@
#define ATMEL_BASE_CS4 0x5000 /* Compact Flash Slot 0 */
#define ATMEL_BASE_CS5 0x6000 /* Compact Flash Slot 1 */
+/* Timer */
+#define CONFIG_SYS_TIMER_COUNTER 0xfd3c
+
/*
* Other misc defines
*/
diff --git a/arch/arm/include/asm/arch-at
Re: [U-Boot] [PATCH V2 00/13] common lcd refactor
Hi Nikita Kiryanov, On 02/03/2015 07:32 PM, Nikita Kiryanov wrote: This series is part of my ongoing efforts to cleanup common/lcd code (and at some point merge it with the CONFIG_VIDEO code). This series focuses on eliminating platform specific #defines from lcd.c code, and then adds a few platform independent code refactors and cleanups on top of that. A small note on the series: - The patch "lcd: split configuration_get_cmap" turned out to be a little problematic: the goal was to move all platform specific code to the appropriate lcd/fb drivers, and keep the generic case in lcd.c as a weak function. This was not possible to do for configuration_get_cmap(), because the weak version still has to compile even if it is overridden, and unfortunately the generic case references panel_info, which is a struct that varies depending on the configuration, and does not always have a cmap field. This demonstrated that the visibility of panel_info should be reviewed, and that there might be a need for some kind of lcd_generic driver. Since this may warrant a series of its own, I opted to tentatively implement the generic configuration_get_cmap() function in lcd.h as static function, and plan to revisit it in the next series. The end result was compile tested on arm and powerpc, and tested on cm_t35 (splash screen feature). Rebased on current mainline. Changes in V2: - Minor commit message changes (such as s/platform specific/platform-specific/, s/Raspberry Pi config file is updated to compile the new file/Raspberry Pi is updated to accommodate the changes/) - patch 2: define configuration_get_cmap() prototype only once. Cc: Bo Shen Cc: Simon Glass Cc: Anatolij Gustschin Nikita Kiryanov (13): lcd: move platform-specific structs to their own headers lcd: split configuration_get_cmap lcd: atmel: move atmel-specific fb_put_word to atmel_lcdfb lcd: mpc8xx: move mpc823-specific fb_put_byte to mpc8xx_lcd.c lcd: atmel: introduce lcd_logo_set_cmap lcd: mpc823: move mpc823-specific lcd_logo_set_cmap code to mpc8xx_lcd.c lcd: logo: move generic cmap setting to lcd_logo_set_cmap() lcd: introduce lcd_set_cmap lcd: remove unused includes lcd: various cleanups lcd: rename bitmap_plot to better represent its functionality lcd: dt: extract simplefb support lcd: split splash code into its own function Tested OK on at91sam9g10ek, at91sam9x5ek boards. Tested-by: Bo Shen board/raspberrypi/rpi/rpi.c | 1 + common/Makefile | 1 + common/lcd.c | 358 ++- common/lcd_simplefb.c| 59 +++ common/splash.c | 16 ++ drivers/video/atmel_hlcdfb.c | 13 ++ drivers/video/atmel_lcdfb.c | 51 ++ drivers/video/exynos_fb.c| 9 ++ drivers/video/mpc8xx_lcd.c | 29 drivers/video/pxa_lcd.c | 6 + include/atmel_lcd.h | 38 + include/exynos_lcd.h | 81 ++ include/fdt_simplefb.h | 14 ++ include/lcd.h| 311 ++--- include/mpc823_lcd.h | 43 ++ include/pxa_lcd.h| 80 ++ include/splash.h | 11 +- 17 files changed, 574 insertions(+), 547 deletions(-) create mode 100644 common/lcd_simplefb.c create mode 100644 include/atmel_lcd.h create mode 100644 include/exynos_lcd.h create mode 100644 include/fdt_simplefb.h create mode 100644 include/mpc823_lcd.h create mode 100644 include/pxa_lcd.h Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] intern: Add copy scripts and target specific helpers
On 2015-02-04 08:33, Heiko Schocher wrote: Hello Hannes, 1st) patman prints out some errors, looks like for me that something is wrong with the first line of my commit message - but no idea what. " Traceback (most recent call last): File "tools/patman/patman", line 149, in options.add_maintainers) File "/home/petermaierh/work/u-boot/tools/patman/series.py", line 227, in MakeCcFile raise_on_error=raise_on_error) File "/home/petermaierh/work/u-boot/tools/patman/gitutil.py", line 321, in BuildEmailList raw += LookupEmail(item, alias, raise_on_error=raise_on_error) File "/home/petermaierh/work/u-boot/tools/patman/gitutil.py", line 490, in LookupEmail raise ValueError, msg ValueError: Alias 'drivers/video/am335x-fb' not found " maybe you've or somebody else has an idea how to fix this ? I am not really a python coder ... and I do not see such an error, if I create a commit with changes in "drivers/video/am335x-fb.c" I got not this error ... my first thought it was the "drivers/video/am335x-fb:" in your subject line... but I used the same subject for a test commit ... please try another subject line: "drivers, video, am335x: ..." ? How does your patman config file looks like? I've tried to add --no-tags Don't process subject tags as aliaes to cmdline, this works ... so it is definitely a problem with the subject line of the commit. 2nd) How to achieve "not breaking threading" ? How the right "in-reply-to" is added to git-send-email ? from where comes this information. I've seen at my last V2 that i don't have reached the goal. Hmm... I am not sure, maybe this is a ToDo? Simon? Could you help here? An idea is to use the -r IN_REPLY_TO in the commandline, the value may be taken from patchwork, here is a messageid like <1422966166-3973-21-git-send-email-oe5...@oevsv.at> displayed. Thanks! bye, Heiko best regards, Hannes many thanks and best regards, Hannes Heiko Schocher schrieb am 03.02.2015 13:47:02: From: Heiko Schocher To: Hannes Petermaier Cc: Hannes Petermaier , u-boot@lists.denx.de, U-Boot boun...@lists.denx.de> Date: 03.02.2015 13:47 Subject: Re: [U-Boot] [PATCH v2] intern: Add copy scripts and target specific helpers Hello Hannes, Am 03.02.2015 13:37, schrieb Hannes Petermaier: Hi all, please ignore this "internal" patch. This is was an accident. Maybe it is worth to look into patman, see: u-boot:/tools/patman/README ? bye, Heiko best regards, Hannes ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] ARM: atmel: armv7: switch to use common timer functions
The commit 8dfafdd (Introduce common timer functions), add common
timer functions, we can use them directly.
Signed-off-by: Bo Shen
---
Changes in v2:
- correct the timer register for sama5d4.
arch/arm/cpu/armv7/at91/timer.c | 61
arch/arm/include/asm/arch-at91/sama5d3.h | 3 ++
arch/arm/include/asm/arch-at91/sama5d4.h | 3 ++
3 files changed, 6 insertions(+), 61 deletions(-)
diff --git a/arch/arm/cpu/armv7/at91/timer.c b/arch/arm/cpu/armv7/at91/timer.c
index 19bf80b..a4a3817 100644
--- a/arch/arm/cpu/armv7/at91/timer.c
+++ b/arch/arm/cpu/armv7/at91/timer.c
@@ -36,22 +36,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define TIMER_LOAD_VAL 0xf
-static inline unsigned long long tick_to_time(unsigned long long tick)
-{
- tick *= CONFIG_SYS_HZ;
- do_div(tick, gd->arch.timer_rate_hz);
-
- return tick;
-}
-
-static inline unsigned long long usec_to_tick(unsigned long long usec)
-{
- usec *= gd->arch.timer_rate_hz;
- do_div(usec, 100);
-
- return usec;
-}
-
/*
* Use the PITC in full 32 bit incrementing mode
*/
@@ -67,55 +51,10 @@ int timer_init(void)
gd->arch.timer_rate_hz = get_pit_clk_rate() / 16;
- gd->arch.tbu = 0;
- gd->arch.tbl = 0;
-
return 0;
}
/*
- * Get the current 64 bit timer tick count
- */
-unsigned long long get_ticks(void)
-{
- at91_pit_t *pit = (at91_pit_t *)ATMEL_BASE_PIT;
-
- ulong now = readl(&pit->piir);
-
- /* increment tbu if tbl has rolled over */
- if (now < gd->arch.tbl)
- gd->arch.tbu++;
- gd->arch.tbl = now;
- return (((unsigned long long)gd->arch.tbu) << 32) | gd->arch.tbl;
-}
-
-void __udelay(unsigned long usec)
-{
- unsigned long long start;
- ulong tmo;
-
- start = get_ticks();/* get current timestamp */
- tmo = usec_to_tick(usec); /* convert usecs to ticks */
- while ((get_ticks() - start) < tmo)
- ; /* loop till time has passed */
-}
-
-/*
- * get_timer(base) can be used to check for timeouts or
- * to measure elasped time relative to an event:
- *
- * ulong start_time = get_timer(0) sets start_time to the current
- * time value.
- * get_timer(start_time) returns the time elapsed since then.
- *
- * The time is used in CONFIG_SYS_HZ units!
- */
-ulong get_timer(ulong base)
-{
- return tick_to_time(get_ticks()) - base;
-}
-
-/*
* Return the number of timer ticks per second.
*/
ulong get_tbclk(void)
diff --git a/arch/arm/include/asm/arch-at91/sama5d3.h
b/arch/arm/include/asm/arch-at91/sama5d3.h
index 227ba80..b749cb3 100644
--- a/arch/arm/include/asm/arch-at91/sama5d3.h
+++ b/arch/arm/include/asm/arch-at91/sama5d3.h
@@ -189,6 +189,9 @@
#define PIO_SCDR_DIV 0x3fff
#define CPU_HAS_PCR
+/* Timer */
+#define CONFIG_SYS_TIMER_COUNTER 0xfe3c
+
/*
* PMECC table in ROM
*/
diff --git a/arch/arm/include/asm/arch-at91/sama5d4.h
b/arch/arm/include/asm/arch-at91/sama5d4.h
index d851568..716b253 100644
--- a/arch/arm/include/asm/arch-at91/sama5d4.h
+++ b/arch/arm/include/asm/arch-at91/sama5d4.h
@@ -191,6 +191,9 @@
#define cpu_is_sama5d44() (cpu_is_sama5d4() && \
(get_extension_chip_id() == ARCH_EXID_SAMA5D44))
+/* Timer */
+#define CONFIG_SYS_TIMER_COUNTER 0xfc06863c
+
/*
* No PMECC Galois table in ROM
*/
--
2.3.0.rc0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] x86: Add SPI support to quark/galileo
The Quark SoC contains a legacy SPI controller in the legacy bridge
which is ICH7 compatible. Like Tunnel Creek and BayTrail, the BIOS
control register offset in the ICH SPI driver is wrong for the Quark
SoC too, unprotect_spi_flash() is added to enable the flash write.
Signed-off-by: Bin Meng
---
arch/x86/cpu/quark/quark.c | 17 +
arch/x86/dts/galileo.dts | 13 +
drivers/spi/ich.c | 3 ++-
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/x86/cpu/quark/quark.c b/arch/x86/cpu/quark/quark.c
index cf596e4..0d593d9 100644
--- a/arch/x86/cpu/quark/quark.c
+++ b/arch/x86/cpu/quark/quark.c
@@ -13,6 +13,21 @@
#include
#include
+/*
+ * TODO:
+ *
+ * This whole routine should be removed until we fully convert the ICH SPI
+ * driver to DM and make use of DT to pass the bios control register offset
+ */
+static void unprotect_spi_flash(void)
+{
+ u32 bc;
+
+ bc = pci_read_config32(QUARK_LEGACY_BRIDGE, 0xd8);
+ bc |= 0x1; /* unprotect the flash */
+ pci_write_config32(QUARK_LEGACY_BRIDGE, 0xd8, bc);
+}
+
static void quark_setup_bars(void)
{
/* GPIO - D31:F0:R44h */
@@ -74,6 +89,8 @@ int arch_cpu_init(void)
*/
quark_setup_bars();
+ unprotect_spi_flash();
+
return 0;
}
diff --git a/arch/x86/dts/galileo.dts b/arch/x86/dts/galileo.dts
index 2f60aeb..66af64a 100644
--- a/arch/x86/dts/galileo.dts
+++ b/arch/x86/dts/galileo.dts
@@ -79,4 +79,17 @@
bank-name = "B";
};
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "intel,ich-spi";
+ spi-flash@0 {
+ #size-cells = <1>;
+ #address-cells = <1>;
+ reg = <0>;
+ compatible = "winbond,w25q64", "spi-flash";
+ memory-map = <0xff80 0x0080>;
+ };
+ };
+
};
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index da85779..194e882 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -177,7 +177,8 @@ void spi_free_slave(struct spi_slave *slave)
static int get_ich_version(uint16_t device_id)
{
if (device_id == PCI_DEVICE_ID_INTEL_TGP_LPC ||
- device_id == PCI_DEVICE_ID_INTEL_ITC_LPC)
+ device_id == PCI_DEVICE_ID_INTEL_ITC_LPC ||
+ device_id == PCI_DEVICE_ID_INTEL_QRK_ILB)
return 7;
if ((device_id >= PCI_DEVICE_ID_INTEL_COUGARPOINT_LPC_MIN &&
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] x86: Add SD/MMC support to quark/galileo
Intel Galileo board has a microSD slot which is routed from Quark SoC
SDIO controller. Enable SD/MMC support so that we can use an SD card.
Signed-off-by: Bin Meng
---
arch/x86/cpu/quark/quark.c | 11 +++
include/configs/galileo.h | 7 +++
2 files changed, 18 insertions(+)
diff --git a/arch/x86/cpu/quark/quark.c b/arch/x86/cpu/quark/quark.c
index 0d593d9..dccf7ac 100644
--- a/arch/x86/cpu/quark/quark.c
+++ b/arch/x86/cpu/quark/quark.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
#include
@@ -13,6 +14,10 @@
#include
#include
+static struct pci_device_id mmc_supported[] = {
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_QRK_SDIO },
+};
+
/*
* TODO:
*
@@ -105,3 +110,9 @@ void reset_cpu(ulong addr)
/* cold reset */
outb(0x08, PORT_RESET);
}
+
+int cpu_mmc_init(bd_t *bis)
+{
+ return pci_mmc_init("Quark SDHCI", mmc_supported,
+ ARRAY_SIZE(mmc_supported));
+}
diff --git a/include/configs/galileo.h b/include/configs/galileo.h
index bead2fc..d745f4e 100644
--- a/include/configs/galileo.h
+++ b/include/configs/galileo.h
@@ -50,4 +50,11 @@
#undef CONFIG_VIDEO
#undef CONFIG_CFB_CONSOLE
+/* SD/MMC support */
+#define CONFIG_MMC
+#define CONFIG_SDHCI
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MMC_SDMA
+#define CONFIG_CMD_MMC
+
#endif /* __CONFIG_H */
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] x86: pci: Add pci ids for Quark SoC
Add pci ids for Intel Quark SoC. Signed-off-by: Bin Meng --- include/pci_ids.h | 4 1 file changed, 4 insertions(+) diff --git a/include/pci_ids.h b/include/pci_ids.h index 1012abe..dc2ca21 100644 --- a/include/pci_ids.h +++ b/include/pci_ids.h @@ -2592,6 +2592,10 @@ #define PCI_DEVICE_ID_INTEL_MFD_EMMC0 0x0823 #define PCI_DEVICE_ID_INTEL_MFD_EMMC1 0x0824 #define PCI_DEVICE_ID_INTEL_MRST_SD2 0x084F +#define PCI_DEVICE_ID_INTEL_QRK_SDIO 0x08A7 +#define PCI_DEVICE_ID_INTEL_QRK_UART 0x0936 +#define PCI_DEVICE_ID_INTEL_QRK_EMAC 0x0937 +#define PCI_DEVICE_ID_INTEL_QRK_ILB0x095E #define PCI_DEVICE_ID_INTEL_I960 0x0960 #define PCI_DEVICE_ID_INTEL_I960RM 0x0962 #define PCI_DEVICE_ID_INTEL_CENTERTON_ILB 0x0c60 -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] x86: quark: Initialize non-standard BARs
Quark SoC has some non-standard BARs (excluding PCI standard BARs)
which need be initialized with suggested values. This includes GPIO,
WDT, RCBA, PCIe ECAM and some ACPI register block base addresses.
Signed-off-by: Bin Meng
---
arch/x86/cpu/quark/quark.c | 46 +
arch/x86/include/asm/arch-quark/quark.h | 32 +++
2 files changed, 78 insertions(+)
diff --git a/arch/x86/cpu/quark/quark.c b/arch/x86/cpu/quark/quark.c
index 47ba152..cf596e4 100644
--- a/arch/x86/cpu/quark/quark.c
+++ b/arch/x86/cpu/quark/quark.c
@@ -9,6 +9,46 @@
#include
#include
#include
+#include
+#include
+#include
+
+static void quark_setup_bars(void)
+{
+ /* GPIO - D31:F0:R44h */
+ pci_write_config_dword(QUARK_LEGACY_BRIDGE, LB_GBA,
+ CONFIG_GPIO_BASE | IO_BAR_EN);
+
+ /* ACPI PM1 Block - D31:F0:R48h */
+ pci_write_config_dword(QUARK_LEGACY_BRIDGE, LB_PM1BLK,
+ CONFIG_ACPI_PM1_BASE | IO_BAR_EN);
+
+ /* GPE0 - D31:F0:R4Ch */
+ pci_write_config_dword(QUARK_LEGACY_BRIDGE, LB_GPE0BLK,
+ CONFIG_ACPI_GPE0_BASE | IO_BAR_EN);
+
+ /* WDT - D31:F0:R84h */
+ pci_write_config_dword(QUARK_LEGACY_BRIDGE, LB_WDTBA,
+ CONFIG_WDT_BASE | IO_BAR_EN);
+
+ /* RCBA - D31:F0:RF0h */
+ pci_write_config_dword(QUARK_LEGACY_BRIDGE, LB_RCBA,
+ CONFIG_RCBA_BASE | MEM_BAR_EN);
+
+ /* ACPI P Block - Msg Port 04:R70h */
+ msg_port_write(MSG_PORT_RMU, PBLK_BA,
+ CONFIG_ACPI_PBLK_BASE | IO_BAR_EN);
+
+ /* SPI DMA - Msg Port 04:R7Ah */
+ msg_port_write(MSG_PORT_RMU, SPI_DMA_BA,
+ CONFIG_SPI_DMA_BASE | IO_BAR_EN);
+
+ /* PCIe ECAM */
+ msg_port_write(MSG_PORT_MEM_ARBITER, AEC_CTRL,
+ CONFIG_PCIE_ECAM_BASE | MEM_BAR_EN);
+ msg_port_write(MSG_PORT_HOST_BRIDGE, HEC_REG,
+ CONFIG_PCIE_ECAM_BASE | MEM_BAR_EN);
+}
int arch_cpu_init(void)
{
@@ -28,6 +68,12 @@ int arch_cpu_init(void)
if (ret)
return ret;
+ /*
+* Quark SoC has some non-standard BARs (excluding PCI standard BARs)
+* which need be initialized with suggested values
+*/
+ quark_setup_bars();
+
return 0;
}
diff --git a/arch/x86/include/asm/arch-quark/quark.h
b/arch/x86/include/asm/arch-quark/quark.h
index ebbcf77..ceb583e 100644
--- a/arch/x86/include/asm/arch-quark/quark.h
+++ b/arch/x86/include/asm/arch-quark/quark.h
@@ -14,9 +14,29 @@
#define MSG_PORT_MEM_MGR 0x05
#define MSG_PORT_SOC_UNIT 0x31
+/* Port 0x00: Memory Arbiter Message Port Registers */
+
+/* Enhanced Configuration Space */
+#define AEC_CTRL 0x00
+
+/* Port 0x03: Host Bridge Message Port Registers */
+
/* Host Memory I/O Boundary */
#define HM_BOUND 0x08
+/* Extended Configuration Space */
+#define HEC_REG0x09
+
+/* Port 0x04: Remote Management Unit Message Port Registers */
+
+/* ACPI PBLK Base Address Register */
+#define PBLK_BA0x70
+
+/* SPI DMA Base Address Register */
+#define SPI_DMA_BA 0x7a
+
+/* Port 0x05: Memory Manager Message Port Registers */
+
/* eSRAM Block Page Control */
#define ESRAM_BLK_CTRL 0x82
#define ESRAM_BLOCK_MODE 0x1000
@@ -37,4 +57,16 @@
/* 64KiB of RMU binary in flash */
#define RMU_BINARY_SIZE0x1
+/* Legacy Bridge PCI Configuration Registers */
+#define LB_GBA 0x44
+#define LB_PM1BLK 0x48
+#define LB_GPE0BLK 0x4c
+#define LB_ACTL0x58
+#define LB_PABCDRC 0x60
+#define LB_PEFGHRC 0x64
+#define LB_WDTBA 0x84
+#define LB_BCE 0xd4
+#define LB_BC 0xd8
+#define LB_RCBA0xf0
+
#endif /* _QUARK_H_ */
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] x86: Add Intel Galileo instructions in README.x86
Add some instructions about building U-Boot for Intel Galileo board. Signed-off-by: Bin Meng --- doc/README.x86 | 24 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/doc/README.x86 b/doc/README.x86 index c699b79..fb87682 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -18,8 +18,8 @@ U-Boot supports running as a coreboot [1] payload on x86. So far only Link on other x86 boards since coreboot deals with most of the low-level details. U-Boot also supports booting directly from x86 reset vector without coreboot, -aka raw support or bare support. Currently Link, Intel Crown Bay and Intel -Minnowboard Max support running U-Boot 'bare metal'. +aka raw support or bare support. Currently Link, Intel Crown Bay, Intel +Minnowboard Max and Intel Galileo support running U-Boot 'bare metal'. As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit Linux kernel as part of a FIT image. It also supports a compressed zImage. @@ -110,7 +110,6 @@ Now you can build U-Boot and obtain u-boot.rom $ make crownbay_defconfig $ make all - Intel Minnowboard Max instructions: This uses as FSP as with Crown Bay, except it is for the Atom E3800 series. @@ -136,6 +135,24 @@ Now you can build U-Boot and obtain u-boot.rom $ make minnowmax_defconfig $ make all +Intel Galileo instructions: + +Only one binary blob is needed for Remote Management Unit (RMU) within Intel +Quark SoC. Not like FSP, U-Boot does not call into the binary. The binary is +needed by the Quark SoC itself. + +You can get the binary blob from Quark Board Support Package from Intel website: + +* ./QuarkSocPkg/QuarkNorthCluster/Binary/QuarkMicrocode/RMU.bin + +Rename the file and put it to the board directory by: + + $ cp RMU.bin board/intel/galileo/rmu.bin + +Now you can build U-Boot and obtain u-boot.rom + +$ make galileo_defconfig +$ make all Test with coreboot -- @@ -203,7 +220,6 @@ mtrr - List and set the Memory Type Range Registers (MTRR). These are used to Development Flow - These notes are for those who want to port U-Boot to a new x86 platform. Since x86 CPUs boot from SPI flash, a SPI flash emulator is a good investment. -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] x86: Add some peripherals support to Intel Galileo
This series adds GPIO, SPI and SD/MMC support to Intel Galileo board. Intel's chipset controllers are normally compatible so that we can easily add peripherals support via existing drivers with minor modification. Note this series depends on previous two series: series#1: http://patchwork.ozlabs.org/patch/435526/ series#2: http://patchwork.ozlabs.org/patch/435816/ With this patch series, the only left interfaces on Galileo board to be enabled are USB, 10/100M Ethernet and mini-PCIe. Bin Meng (6): x86: quark: Initialize non-standard BARs x86: galileo: Add GPIO support x86: pci: Add pci ids for Quark SoC x86: Add SPI support to quark/galileo x86: Add SD/MMC support to quark/galileo x86: Add Intel Galileo instructions in README.x86 arch/x86/cpu/quark/quark.c | 74 + arch/x86/dts/galileo.dts| 27 arch/x86/include/asm/arch-quark/quark.h | 32 ++ doc/README.x86 | 24 +-- drivers/spi/ich.c | 3 +- include/configs/galileo.h | 7 include/pci_ids.h | 4 ++ 7 files changed, 166 insertions(+), 5 deletions(-) -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] x86: galileo: Add GPIO support
Quark SoC has a legacy GPIO block in the legacy bridge (D0:F31),
which is just the same one found in other x86 chipset. Since we
programmed the GPIO register block base address, we should be
able to enable the GPIO support on Intel Galileo board.
Signed-off-by: Bin Meng
---
arch/x86/dts/galileo.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/dts/galileo.dts b/arch/x86/dts/galileo.dts
index d462221..2f60aeb 100644
--- a/arch/x86/dts/galileo.dts
+++ b/arch/x86/dts/galileo.dts
@@ -65,4 +65,18 @@
};
};
+ gpioa {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0 0x20>;
+ bank-name = "A";
+ };
+
+ gpiob {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0x20 0x20>;
+ bank-name = "B";
+ };
+
};
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: configs/sunxi-common.h: Enable CONFIG_CMD_PART
Hi, On 04-02-15 09:27, Ian Campbell wrote: On Wed, 2015-02-04 at 00:43 +0100, Hans de Goede wrote: The recent changes to config_distro_bootcmd.h require CONFIG_CMD_PART to be defined, as the default bootcmd not uses the "part" command. ^w Shouldn't config_distro_bootcmd.h (or perhaps config_distro_defaults.h) enable CMD_PART then? (adding some relevant CCs) I was thinking the same myself, but I was not sure, so I thought lets go with a quick fix for now and discuss this further on the list :) A quick grep shows that config_distro_bootcmd.h is only included from headers under include/configs/*.h, so enabling it there should get it defined early enough for it to be properly picked up, so from my pov yes that is a better solution. Regards, Hans p.s. Have you seen my reply to your review of "[PATCH 1/2] sunxi: video: Do not use CONFIG_SYS_MEM_TOP_HIDE for the framebuffer" ? I'm waiting on input from you there on the fdt_fixup_memory_banks() thingie, which I would prefer to keep as is. An "Acked-by" under the condition that I fix up the Linux specific comments would be welcome :) Ian. This fixes sunxi boards not booting with v2015.04-rc1. Signed-off-by: Hans de Goede --- include/configs/sunxi-common.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index bf60dcb..9e145f0 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -144,6 +144,9 @@ #define CONFIG_CMD_MEMORY #define CONFIG_CMD_SETEXPR +#define CONFIG_PARTITION_UUIDS +#define CONFIG_CMD_PART + #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_CMDLINE_TAG #define CONFIG_INITRD_TAG ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] arm: Allow lr to be saved by board code
Hello Simon, On Tue, 3 Feb 2015 21:18:52 -0700, Simon Glass wrote: > The link register value can be required on some boards (e.g. FEL mode on > sunxi) so stash it to r4 before jumping to save_boot_params(). I'd rather not make this there; I would like save_boot_params to start with as unmodified a core state as possible, because r4 might actually, now or in the future, contain important data. I'd even go as far as saying that save_boot_params should be branched into rather than called, and should branch back to a fixed label right after reset, so that even lr is preserved. For SoCs which do not need to save any boot parameters, a weak version of save_boot_params would just do the branching back. (this should help merging all start.S instances into a singe one, which I still want to achieve one day) > Signed-off-by: Simon Glass > --- Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: configs/sunxi-common.h: Enable CONFIG_CMD_PART
On Wed, 2015-02-04 at 00:43 +0100, Hans de Goede wrote: > The recent changes to config_distro_bootcmd.h require CONFIG_CMD_PART to be > defined, as the default bootcmd not uses the "part" command. ^w Shouldn't config_distro_bootcmd.h (or perhaps config_distro_defaults.h) enable CMD_PART then? (adding some relevant CCs) Ian. > This fixes sunxi boards not booting with v2015.04-rc1. > > Signed-off-by: Hans de Goede > --- > include/configs/sunxi-common.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index bf60dcb..9e145f0 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -144,6 +144,9 @@ > #define CONFIG_CMD_MEMORY > #define CONFIG_CMD_SETEXPR > > +#define CONFIG_PARTITION_UUIDS > +#define CONFIG_CMD_PART > + > #define CONFIG_SETUP_MEMORY_TAGS > #define CONFIG_CMDLINE_TAG > #define CONFIG_INITRD_TAG ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: Add support for CONFIG_LCD_NOSTDOUT
On 2014-08-11 15:52, Anatolij Gustschin wrote:
Hi,
Hi,
sorry for my late response because i've been working on some other
project for a couple of months.
On Thu, 6 Mar 2014 15:26:11 +0100
Hannes Petermaier wrote:
...
+ CONFIG_LCD_NOSTDOUT
+ Normally 'stdout' is redirected to LCD-screen after
+ initialization. Define CONFIG_LCD_NOSTDOUT to avoid this.
+ Useful in case where only lcd_puts(...), lcd_printf(...)
+ functions of the framework are used and 'normal' u-boot
+ console remains e.g. on serial-line.
+
this console redirection to lcd can be disabled by defining
#define CONFIG_SYS_CONSOLE_IS_IN_ENV
#define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
in the board config file and adding below function to
the board code:
int overwrite_console(void)
{
return 1;
}
Can you please try it instead of this patch?
Yes - that works for me - so we can close the case.
Many thanks.
I will create some patch for the B&R boards.
Best regards,
Anatolij
best regards,
Hannes
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] RFC: sunxi: WIP FEL support
Hi,
On 04-02-15 05:18, Simon Glass wrote:
(What does FEL stand for?)
This is an attempt to make sunxi's FEL code fit with the normal U-Boot
boot sequence instead of creating its own.
Most of the FEL special-case code is removed, although I may have gone too
far with my changes to generate a u-boot-sunxi-with-spl.bin file even when
FEL is enabled. This may not be possible since the MMC stack makes SPL
too large for FEL anyway, although it may be possible for other boot
mediums.
This series is available at u-boot-dm, branch sunxi-working.
Thanks for working on this, I like the direction where this is heading,
if Albert is ok with the start.S changes this would be an excellent way
to fix FEL mode for v2015.04.
WRT you going to far when also building a u-boot-sunxi-with-spl.bin when
FEL is enabled, your right, AFAIK that binary will not work when written
to sdcard because FEL mode has a CONFIG_SPL_TEXT_BASE of 0x2000 where
as non FEL has CONFIG_SPL_TEXT_BASE set to 0x0020.
But we've discussed in the past to use 0x2000 everywhere, this would mean
moving the stack pointer to 0x2000 instead of 0x8000, and then making
the normal SPL fit between 0x2000 - 0x8000.
All you need to change then AFAIK is tools/mksunxiboot.c so that the jump
instruction which is the first 32 bit word of the header it generates jumps
to 0x2000 rather then 0x0020, and then we may be able to have a unified
build which does both FEL and regular SPL for sdcard boot.
Regards,
Hans
Signed-off-by: Simon Glass
---
arch/arm/cpu/armv7/sunxi/Makefile | 4 +-
arch/arm/cpu/armv7/sunxi/board.c| 21
arch/arm/cpu/armv7/sunxi/config.mk | 2 -
arch/arm/cpu/armv7/sunxi/fel_utils.S| 26 +
arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds | 82 -
arch/arm/include/asm/arch-sunxi/sys_proto.h | 10
board/sunxi/Kconfig | 10
include/configs/sunxi-common.h | 6 +--
scripts/Makefile.spl| 2 -
9 files changed, 70 insertions(+), 93 deletions(-)
create mode 100644 arch/arm/cpu/armv7/sunxi/fel_utils.S
delete mode 100644 arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index 48db744..c1b975a 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -38,7 +38,5 @@ obj-$(CONFIG_MACH_SUN5I) += dram_sun4i.o
obj-$(CONFIG_MACH_SUN6I) += dram_sun6i.o
obj-$(CONFIG_MACH_SUN7I) += dram_sun4i.o
obj-$(CONFIG_MACH_SUN8I) += dram_sun8i.o
-ifdef CONFIG_SPL_FEL
-obj-y += start.o
-endif
+obj-y += fel_utils.o
endif
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 6e28bcd..b7492ac 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -27,6 +27,13 @@
#include
+struct fel_stash {
+ uint32_t sp;
+ uint32_t lr;
+};
+
+struct fel_stash fel_stash __attribute__((section(".data")));
+
static int gpio_init(void)
{
#if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
@@ -65,6 +72,12 @@ static int gpio_init(void)
return 0;
}
+void spl_board_load_image(void)
+{
+ debug("Returning to FEL sp=%x, lr=%x\n", fel_stash.sp, fel_stash.lr);
+ return_to_fel(fel_stash.sp, fel_stash.lr);
+}
+
void s_init(void)
{
#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I
@@ -95,6 +108,14 @@ void s_init(void)
*/
u32 spl_boot_device(void)
{
+ /*
+* Have we been asked to return to the FEL portion of the boot ROM?
+* TODO: We need a more robust test here, or bracket this with
+* #ifdef CONFIG_SPL_FEL.
+*/
+ if (fel_stash.lr >= 0x && fel_stash.lr < 0x4000)
+ return BOOT_DEVICE_BOARD;
+
return BOOT_DEVICE_MMC1;
}
diff --git a/arch/arm/cpu/armv7/sunxi/config.mk
b/arch/arm/cpu/armv7/sunxi/config.mk
index 00f5ffc..76ffec9 100644
--- a/arch/arm/cpu/armv7/sunxi/config.mk
+++ b/arch/arm/cpu/armv7/sunxi/config.mk
@@ -1,8 +1,6 @@
# Build a combined spl + u-boot image
ifdef CONFIG_SPL
ifndef CONFIG_SPL_BUILD
-ifndef CONFIG_SPL_FEL
ALL-y += u-boot-sunxi-with-spl.bin
endif
endif
-endif
diff --git a/arch/arm/cpu/armv7/sunxi/fel_utils.S
b/arch/arm/cpu/armv7/sunxi/fel_utils.S
new file mode 100644
index 000..42739df
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/fel_utils.S
@@ -0,0 +1,26 @@
+/*
+ * Utility functions for FEL mode.
+ *
+ * Copyright (c) 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+
+ENTRY(save_boot_params)
+ ldr r0, =fel_stash
+ str sp, [r0, #0]
+ str r4, [r0, #4]/* Store lr */
+ mov r0, #RESET_SKIP_VBVAR | RESET_SKIP_CP15
+ bx lr
+ENDPROC(save_boot_params)
+
+ENTRY(return_to_fel)
+ mov sp, r0
+ mov lr, r1
+ bx lr
+
Re: [U-Boot] [PATCH 1/2] sunxi: video: Do not use CONFIG_SYS_MEM_TOP_HIDE for the framebuffer
On Tue, 2015-02-03 at 18:59 +0100, Hans de Goede wrote: > Then we need to keep track of if that callback succeeded, because without > the reservation we should not enable simplefb. I would prefer to just > keep this bit as is. OK then. With the comment fixed up: Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] dfu: nand: Verify writes
Hi Peter,
> Previously NAND writes were not verified and could fail silently. Add
> a verification step after all writes to NAND.
>
> Signed-off-by: Peter Tyser
> ---
> I don't have a board with DFU support, so this change is untested.
>
> drivers/dfu/dfu_nand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
> index f9ee189..a975492 100644
> --- a/drivers/dfu/dfu_nand.c
> +++ b/drivers/dfu/dfu_nand.c
> @@ -64,7 +64,7 @@ static int nand_block_op(enum dfu_op op, struct
> dfu_entity *dfu, return ret;
> /* then write */
> ret = nand_write_skip_bad(nand, start, &count,
> &actual,
> - lim, buf, 0);
> + lim, buf, WITH_WR_VERIFY);
> }
>
> if (ret != 0) {
Reviewed-by: Lukasz Majewski
I think that Heiko or Tom, who are active users of DFU NAND, should
check this patch too.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] arm: Use r2 instead of r0 in start.S
Hello Simon, (sorry for the dupe) On Tue, 3 Feb 2015 21:18:50 -0700, Simon Glass wrote: > Allow r0 to be used for other purposes in this file. These purposes should be made clear -- possibly even, merged with the code that actually needs it. > Signed-off-by: Simon Glass > --- Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] RFC: sunxi: WIP FEL support
Hello Hans, On Wed, 04 Feb 2015 09:47:41 +0100, Hans de Goede wrote: > Hi, > > On 04-02-15 05:18, Simon Glass wrote: > > (What does FEL stand for?) > > > > This is an attempt to make sunxi's FEL code fit with the normal U-Boot > > boot sequence instead of creating its own. > > > > Most of the FEL special-case code is removed, although I may have gone too > > far with my changes to generate a u-boot-sunxi-with-spl.bin file even when > > FEL is enabled. This may not be possible since the MMC stack makes SPL > > too large for FEL anyway, although it may be possible for other boot > > mediums. > > > > This series is available at u-boot-dm, branch sunxi-working. > > Thanks for working on this, I like the direction where this is heading, > if Albert is ok with the start.S changes this would be an excellent way > to fix FEL mode for v2015.04. Even though the series came in after window close and after -rc1, I'm fine with considering it for 2015.04. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] arm: Use r2 instead of r0 in start.S
Allow r0 to be used for other purposes in this file. Signed-off-by: Simon Glass --- arch/arm/cpu/armv7/start.S | 88 +++--- 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 70048c1..c5f94ef 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -38,13 +38,13 @@ reset: * disable interrupts (FIQ and IRQ), also set the cpu to SVC32 mode, * except if in HYP mode already */ - mrs r0, cpsr - and r1, r0, #0x1f @ mask mode bits + mrs r2, cpsr + and r1, r2, #0x1f @ mask mode bits teq r1, #0x1a @ test for HYP mode - bicne r0, r0, #0x1f @ clear all mode bits - orrne r0, r0, #0x13 @ set SVC mode - orr r0, r0, #0xc0 @ disable FIQ and IRQ - msr cpsr,r0 + bicne r2, r2, #0x1f @ clear all mode bits + orrne r2, r2, #0x13 @ set SVC mode + orr r2, r2, #0xc0 @ disable FIQ and IRQ + msr cpsr, r2 /* * Setup vector: @@ -53,13 +53,13 @@ reset: */ #if !(defined(CONFIG_OMAP44XX) && defined(CONFIG_SPL_BUILD)) /* Set V=0 in CP15 SCTLR register - for VBAR to point to vector */ - mrc p15, 0, r0, c1, c0, 0 @ Read CP15 SCTLR Register - bic r0, #CR_V @ V = 0 - mcr p15, 0, r0, c1, c0, 0 @ Write CP15 SCTLR Register + mrc p15, 0, r2, c1, c0, 0 @ Read CP15 SCTLR Register + bic r2, #CR_V @ V = 0 + mcr p15, 0, r2, c1, c0, 0 @ Write CP15 SCTLR Register /* Set vector address in CP15 VBAR register */ - ldr r0, =_start - mcr p15, 0, r0, c12, c0, 0 @Set VBAR + ldr r2, =_start + mcr p15, 0, r2, c12, c0, 0 @Set VBAR #endif /* the mask ROM code should have PLL and others stable */ @@ -77,9 +77,9 @@ ENTRY(c_runtime_cpu_setup) * If I-cache is enabled invalidate it */ #ifndef CONFIG_SYS_ICACHE_OFF - mcr p15, 0, r0, c7, c5, 0 @ invalidate icache - mcr p15, 0, r0, c7, c10, 4 @ DSB - mcr p15, 0, r0, c7, c5, 4 @ ISB + mcr p15, 0, r2, c7, c5, 0 @ invalidate icache + mcr p15, 0, r2, c7, c10, 4 @ DSB + mcr p15, 0, r2, c7, c5, 4 @ ISB #endif bx lr @@ -88,7 +88,7 @@ ENDPROC(c_runtime_cpu_setup) /* * - * void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3) + * void save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3) * __attribute__((weak)); * * Stack pointer is not yet initialized at this moment @@ -112,55 +112,55 @@ ENTRY(cpu_init_cp15) /* * Invalidate L1 I/D */ - mov r0, #0 @ set up for MCR - mcr p15, 0, r0, c8, c7, 0 @ invalidate TLBs - mcr p15, 0, r0, c7, c5, 0 @ invalidate icache - mcr p15, 0, r0, c7, c5, 6 @ invalidate BP array - mcr p15, 0, r0, c7, c10, 4 @ DSB - mcr p15, 0, r0, c7, c5, 4 @ ISB + mov r2, #0 @ set up for MCR + mcr p15, 0, r2, c8, c7, 0 @ invalidate TLBs + mcr p15, 0, r2, c7, c5, 0 @ invalidate icache + mcr p15, 0, r2, c7, c5, 6 @ invalidate BP array + mcr p15, 0, r2, c7, c10, 4 @ DSB + mcr p15, 0, r2, c7, c5, 4 @ ISB /* * disable MMU stuff and caches */ - mrc p15, 0, r0, c1, c0, 0 - bic r0, r0, #0x2000 @ clear bits 13 (--V-) - bic r0, r0, #0x0007 @ clear bits 2:0 (-CAM) - orr r0, r0, #0x0002 @ set bit 1 (--A-) Align - orr r0, r0, #0x0800 @ set bit 11 (Z---) BTB + mrc p15, 0, r2, c1, c0, 0 + bic r2, r2, #0x2000 @ clear bits 13 (--V-) + bic r2, r2, #0x0007 @ clear bits 2:0 (-CAM) + orr r2, r2, #0x0002 @ set bit 1 (--A-) Align + orr r2, r2, #0x0800 @ set bit 11 (Z---) BTB #ifdef CONFIG_SYS_ICACHE_OFF - bic r0, r0, #0x1000 @ clear bit 12 (I) I-cache + bic r2, r2, #0x1000 @ clear bit 12 (I) I-cache #else - orr r0, r0, #0x1000 @ set bit 12 (I) I-cache + orr r2, r2, #0x1000 @ set bit 12 (I) I-cache #endif - mcr p15, 0, r0, c1, c0, 0 + mcr p15, 0, r2, c1, c0, 0 #ifdef CONFIG_ARM_ERRATA_716044 - mrc p15, 0, r0, c1, c0, 0 @ read system control register - orr r0, r0, #1 << 11@ set bit #11 - mcr p15, 0, r0, c1, c0, 0 @ write system control register + mrc p15, 0, r2, c1, c0, 0 @ read system control register + orr r2, r2, #1 << 11@ set bit #11 + mcr p15, 0, r2, c1, c0, 0 @
Re: [U-Boot] [PATCH 2/9] sunxi: Move SPL s_init() code to board_init_f()
Hi Siarhei, On 3 February 2015 at 20:23, Simon Glass wrote: > Hi Siarhei, > > On 3 February 2015 at 18:58, Siarhei Siamashka > wrote: >> On Tue, 3 Feb 2015 17:55:52 -0700 >> Simon Glass wrote: >> >>> Hi, >>> >>> On 2 February 2015 at 22:29, Simon Glass wrote: >>> > Hi, >>> > >>> > On 2 February 2015 at 01:07, Hans de Goede wrote: >>> >> Hi Simon, Siarhei, >>> >> >>> >> On 01-02-15 21:59, Simon Glass wrote: >>> >>> >>> >>> Hi Siarhei, >>> >>> >>> >>> On 1 February 2015 at 11:37, Siarhei Siamashka >>> >>> >>> >> >>> >> >>> >> >>> >> >>> A comprehensive FEL usage guide is supposed to be in the linux-sunxi >>> wiki. But it might be not very up to date with the mainline u-boot >>> usage. >>> >>> Anyway, first just clone the https://github.com/linux-sunxi/sunxi-tools >>> repository and build it. This will provide you with the x86 binary of >>> the 'fel' tool, which is used on your desktop PC to talk with the >>> device. >>> >>> Then connect the device to your PC using a "USB A to USB mini/micro B" >>> cable. And reset the board while keeping the "FEL" button pressed. The >>> button might be labelled as "UPGRADE" on your pcduino3 board: >>> http://linux-sunxi.org/LinkSprite_pcDuino_V3#FEL_mode >>> >>> Then just run "fel ver" command: >>> http://linux-sunxi.org/FEL#Running_the_fel_tool >>> >>> If everything is fine, it should respond with something like this: >>> AWUSBFEX soc=00162500(A13) 0001 ver=0001 44 08 scratchpad=7e00 >>> >>> >>> Now you can use "write" commands to upload data to SRAM. And "exe" >>> command to execute functions on the device (works as some kind of RPC): >>> http://linux-sunxi.org/FEL/USBBoot#Manual_loading >>> >>> As a simple test, you can upload just a single "bx lr" instruction >>> (compiled in ARM mode) to the address 0x2000 and try to execute it. >>> In the case if your code screws up something and does not return >>> control to the BROM correctly, then the "fel" tool can't communicate >>> over USB anymore and just timeouts. Regarding the address space, you >>> can use SRAM addresses starting from 0x2000 up to something like 0x5E00 >>> (that's where the stack pointer is set). This was a description of a >>> "bare metal" FEL usage. >>> >>> Now as for the u-boot support. You can compile and run u-boot in the >>> FEL >>> mode configuration on pcduino3 in the following way: >>> >>> make CROSS_COMPILE=arm-none-gnueabi- Linksprite_pcDuino3_felconfig >>> make CROSS_COMPILE=arm-none-gnueabi- -j2 >>> >>> fel write 0x2000 spl/u-boot-spl.bin >>> fel exe 0x2000 >>> >>> sleep 1 # Wait for DRAM initialization to complete >>> >>> >>> >>> >>> >>> i.e. wait for U-Boot SPL to return to the BROM? >>> >>> >>> >>> fel write 0x4a00 u-boot.bin >>> fel exe 0x4a00 >>> >>> Please note the use of '*_felconfig' instead of '*_defconfig'. >>> And also right now the FEL mode support is broken. That's why the >>> http://lists.denx.de/pipermail/u-boot/2015-January/203282.html >>> patchset tried to address this problem. >>> >>> >>> >>> >>> OK that looks like an excellent guide, thank you. I will make some time >>> >>> to >>> >>> take a more detailed look at this as soon as I can, but definitely in >>> >>> the >>> >>> next few days. >>> >> >>> >> >>> >> I've been reading all threads on this, thank you both for looking into >>> >> this, >>> >> since you're on it I'm going to leave this be (and not review / apply >>> >> Siarhei's patches for this), and we can revisit this later, with >>> >> hopefully a >>> >> better fix. >>> > >>> > Thanks to Siarhei's instructions I have a working setup with pcduino3. >>> > One less board where I have to swap SD cards. Can I suggest that it >>> > would be really nice to have a README.sunxi that covers all of this? >>> > >>> > Anyway I will fiddle around and see what I can come up with. >>> >>> The problem seems to be the start.S code 'Setup vector' and >>> cpu_init_cp15. If I remove these then FEL boots OK without all the >>> gdata/r9 stuff and with the rest of the boot flow normal. >> >> I don't quite follow this brief explanation. Could you perhaps >> attach/paste a patch or provide a link to some test branch with >> the code? > > If you look at code in start.S it fiddles with cp15 and this seems to > stuff up FEL. I'm not exactly sure what is breaking it, but we seem to > need to skip that code. > > I will push what I have to a branch - I am just trying to tidy it up a bit. > >> >>> I would quite like FEL to be an option you enable, but we can detect >>> whether it is actually being used (as with Tegra and Exynos). >> >> FEL is already a Kconfig option, which can be enabled/disabled >> in menuconfig. Currently it also disables certain parts of code >> (MMC support) in order
Re: [U-Boot] [PATCH 2/5] arm: Allow reset init to be controlled
Hello Simon,
On Tue, 3 Feb 2015 21:18:51 -0700, Simon Glass
wrote:
> Some boards want to skip the normal reset init. For example OMAP4 SPL
> does not want to touch VBAR and many boards don't want to set up
> CP15.
>
> Provide a return value from save_boot_params() which allows the board
> to indicate what reset processing should be done.
Does this have to be at run-time? I'd rather it were a build-time
config option.
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/cpu/armv7/exynos/spl_boot.c | 5 -
> arch/arm/cpu/armv7/start.S | 11 ---
> arch/arm/include/asm/system.h| 15 +++
> 3 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c
> b/arch/arm/cpu/armv7/exynos/spl_boot.c
> index bc237c9..6e249f1 100644
> --- a/arch/arm/cpu/armv7/exynos/spl_boot.c
> +++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
> @@ -309,4 +309,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
> while (1)
> ;
> }
> -void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3) {}
> +u32 save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
> +{
> + return 0;
> +}
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index c5f94ef..0ba26f7 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -52,6 +52,9 @@ reset:
> * Continue to use ROM code vector only in OMAP4 spl)
> */
> #if !(defined(CONFIG_OMAP44XX) && defined(CONFIG_SPL_BUILD))
> + teq r0, #RESET_SKIP_VBVAR
> + bne vbar_done
> +
> /* Set V=0 in CP15 SCTLR register - for VBAR to point to vector */
> mrc p15, 0, r2, c1, c0, 0 @ Read CP15 SCTLR Register
> bic r2, #CR_V @ V = 0
> @@ -61,10 +64,11 @@ reset:
> ldr r2, =_start
> mcr p15, 0, r2, c12, c0, 0 @Set VBAR
> #endif
> -
> +vbar_done:
> /* the mask ROM code should have PLL and others stable */
> #ifndef CONFIG_SKIP_LOWLEVEL_INIT
> - bl cpu_init_cp15
> + teq r0, #RESET_SKIP_CP15
> + bleqcpu_init_cp15
> bl cpu_init_crit
> #endif
>
> @@ -88,11 +92,12 @@ ENDPROC(c_runtime_cpu_setup)
>
> /*
> *
> - * void save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
> + * u32 save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
> * __attribute__((weak));
> *
> * Stack pointer is not yet initialized at this moment
> * Don't save anything to stack even if compiled with -O0
> + * Return flags - see RESET_... in system.h
> *
> */
> ENTRY(save_boot_params)
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> index 89f2294..98e49a7 100644
> --- a/arch/arm/include/asm/system.h
> +++ b/arch/arm/include/asm/system.h
> @@ -140,8 +140,23 @@ void flush_l3_cache(void);
> */
> #define __asmeq(x, y) ".ifnc " x "," y " ; .err ; .endif\n\t"
>
> +/* Control bits for reset processing */
> +#define RESET_SKIP_VBVAR (1 << 0)/* Skip vector address setup */
> +#define RESET_SKIP_CP15 (1 << 1)/* Skip CP15 setup */
> +
> #ifndef __ASSEMBLY__
>
> +/**
> + * save_boot_params() - Save boot parameters before starting reset sequence
> + *
> + * @r0: Value of r0
> + * @r1: Value of r1
> + * @r2: Value of r2
> + * @r3: Value of r3
> + * @return reset flags (see RESET_... above)
> + */
> +u32 save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3);
> +
> #define isb() __asm__ __volatile__ ("" : : : "memory")
>
> #define nop() __asm__ __volatile__("mov\tr0,r0\t@ nop\n\t");
> --
> 2.2.0.rc0.207.ga3a616c
>
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARmv7: Add a soc_init hook to start.S
Hello Tom,
On Mon, 2 Feb 2015 13:56:57 -0500, Tom Rini wrote:
> And (and this is being split into
> different email threads, sigh), it would be good, possibly, if we have
> something that means "very early init things, but we can be written in
> C".
"Very early" -- and "early" too, BTW -- is way too vague for me to be
sure we're talking about the same thing, so let's find out what various
earlinesses mean to us. My own view:
"Starting early": the 'start', or 'reset', entry point, can't get
earlier than that. This is where U-Boot resets the target to a known
state (cache disable and invalidate, for instance). For some SoCs, at
this point core registers have to be saved somewhere because they
contain informative values that we want to keep, so we need to be able
to hook this stage. There is no C environment.
"Flipping early": after the entry point but before the DDR is usable.
That's where PLLs/clocks are set up minimaly to get going and have
access to the needed resources including DDR. Still no C environment.
"Effing early": after the DDR was made usable but before relocation.
That's when board_init_f() starts. It's there to get the relocation
right. We have a C environment of sorts, with a stack but without
writable data and without BSS; only GD is writable. That's because
the current *running* address may be in Flash, hence the "_f".
Code called from board_init_f() may set up some more PLLs/clocks,
devices, peripherals, etc. as long as it's needed for relocation
(e.g. querying a display's characteristics in order to compute how
much memory it will reserve from top).
"Erring early": after relocation. That's board_init_r. We have a
full C environment and we're running entirely from RAM ("_r").
There, U-Boot does whatever initializations are still needed to
get the payload running.
The actual setting up of environments between stages is supposed
to happen in some architecture code -- for ARM it would all be in
arch/arm/lib/crt0.S.
(if more official names were needed -- and my point sort of *is*
that they /are/ needed, to replace all these "early something"
names we've been using so far -- I'd suggest "reset", "init",
"layout" and "run" respectively.)
So... for me, Tom, your "very early but written in C" maps to my
"effing early" / "layout"; something that has to run first in that
stage should just be first in init_sequence_f[]. OTOH, it /cannot/
be something needed to reset or initialize the target.
Now, /some/ SoCs might be able to set up a C environment of sorts in
place between the "reset" and "init" phases - SRAM, locked cache...
This could be invoked before calling the "init" stage. Generic init
code would not assume any C env, but SoC init code would be able to
use it.
Comments?
> --
> Tom
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
On 02/04/2015 04:11 AM, Masahiro Yamada wrote: > Hi Michal, > > > On Tue, 3 Feb 2015 10:11:39 +0100 > Michal Simek wrote: > >> Hi Simon, >> >> On 02/03/2015 03:02 AM, Masahiro Yamada wrote: >>> Hi. >>> >>> >>> On Mon, 2 Feb 2015 16:57:15 -0700 >>> Simon Glass wrote: >>> Hi Michal, On 2 February 2015 at 08:31, Michal Simek wrote: > Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA > relocation (mostly only GOT) where functions aray are not > updated. This patch is fixing function pointers for DM core > and serial-uclass to ensure that relocated functions are called. > > Signed-off-by: Michal Simek > --- > > drivers/core/root.c| 64 > ++ > drivers/serial/serial-uclass.c | 16 +++ > 2 files changed, 80 insertions(+) How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this? >>> >>> >>> >>> This patch is unfortunate. >>> Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day? >> >> This patch (or similar one) has to be alive when we have platform >> which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. >> There is an option to move to REL/RELA but the question is if >> all platforms have it/support it. Unfortunately I think that >> it will be in the tree for a long time. >> >>> >>> If we use SPL, we do not have to relocate code, I think. >> >> SPL doesn't have relocation that's why this code is not used there. >> > > It is not what I meant. > > > If SPL can directly load the main u-boot image > to the DRAM address where it is linked, > we do not relocate the code in the main image. Current behavior is that SPL is reading u-boot.img entry point which can be in any location and jump to it and u-boot self relocate to the end of memory. If SPL adds u-boot directly to the location where it should run after relocation then relocation is not needed. To ensure this capability (based on my poor GOT/REL/RELA) experience it means that SPL loads u-boot to that location and patch REL/RELA section based on this location and internal relocation should be skipped. This is definitely doable for REL/RELA case and it can also speedup boot process (I don't think there is easy way how to solve this with just GOT relocation because of that MANUAL_RELOC code which is patching arrays with function pointers). Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Hi, On 02/04/2015 06:48 AM, Graeme Russ wrote: > Hi Simon, > >> Maybe I asked this before, but when can we remove >> CONFIG_NEEDS_MANUAL_RELOC? What platforms need it? > > A quick grep yields a global define of CONFIG_NEEDS_MANUAL_RELOC for avr32, > m68k, nds32, and sparc + Microblaze to move to generic board support now. > > Next question is - which of these platforms have toolchains which lack the > ability to generate the relocation tables that we need? Microblaze have the option to generate relocation tables without need to use CONFIG_NEEDS_MANUAL_RELOC. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv1 08/22] arm: socfpga: spl: Add call to timer_init
On 1/14/15 5:45 PM, Marek Vasut wrote: > On Wednesday, January 14, 2015 at 05:40:48 PM, dingu...@opensource.altera.com > wrote: >> From: Dinh Nguyen >> >> Signed-off-by: Dinh Nguyen > > You might want to check common/spl/spl.c , which implements most of the > standard > SPL init procedure. It even includes the call to timer_init() there in > board_init_r() . I wonder if you really need to call it here one more time. > Do you ? > Your logic makes sense, but I think this timer_init() call in spl_board_init() is needed. The reason is that we are releasing the timer from reset in spl_board_init, and timer_init is getting called before spl_board_init. If I take out this timer_init, the SPL doesn't work so well. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: spear: Move to generic board support
On 3 February 2015 at 12:57, Stefan Roese wrote: > Without this change the board support for these SPEAr boards would > be dropped soon. Generic board support seems to work just fine. > > Signed-off-by: Stefan Roese > Cc: Viresh Kumar > Cc: Vipin Kumar > --- > Unfortunately I missed the merge window by one day. I totally forget to > check here. But I'm currently busy with updating U-Boot on at least > the x600 board. Including updated SPL support (which is quite outdated). > So I really would like to not have these SPEAr board dropped from > mainline for now. > > Thanks, > Stefan > > include/configs/spear-common.h | 2 ++ > include/configs/x600.h | 1 + > 2 files changed, 3 insertions(+) > > diff --git a/include/configs/spear-common.h b/include/configs/spear-common.h > index a11f4ed..16281f5 100644 > --- a/include/configs/spear-common.h > +++ b/include/configs/spear-common.h > @@ -11,6 +11,8 @@ > * Common configurations used for both spear3xx as well as spear6xx > */ > > +#define CONFIG_SYS_GENERIC_BOARD > + > /* U-boot Load Address */ > #define CONFIG_SYS_TEXT_BASE 0x0070 > > diff --git a/include/configs/x600.h b/include/configs/x600.h > index 04187c0..241bf65 100644 > --- a/include/configs/x600.h > +++ b/include/configs/x600.h > @@ -16,6 +16,7 @@ > */ > #define CONFIG_SPEAR600/* SPEAr600 SoC */ > #define CONFIG_X600/* on X600 board */ > +#define CONFIG_SYS_GENERIC_BOARD > > #include Looks fine to me.. Acked-by: Viresh Kumar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] cmd_fdt: Actually fix fdt command in sandbox
Commit 90bac29a76bc8d649b41a55f2786c0abef9bb2c1 claims to fix this bug
that was introduced in commit a92fd6577ea17751ead9b50243e3c562125cf581
but doesn't actually make the change that the commit message describes.
Actually fix the bug this time.
Signed-off-by: Joe Hershberger
---
Changes in v2:
-Changed the prototype of set_working_fdt_addr() to ulong instead of void *
common/bootm.c| 2 +-
common/cmd_fdt.c | 8
common/image-fdt.c| 2 +-
include/fdt_support.h | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index e2dc164..34f60bb 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -233,7 +233,7 @@ static int bootm_find_fdt(int flag, int argc, char * const
argv[])
return 1;
}
- set_working_fdt_addr(images.ft_addr);
+ set_working_fdt_addr((ulong)images.ft_addr);
return 0;
}
diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index dc59fab..4e9bc6b 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -38,13 +38,13 @@ static int is_printable_string(const void *data, int len);
*/
struct fdt_header *working_fdt;
-void set_working_fdt_addr(void *addr)
+void set_working_fdt_addr(ulong addr)
{
void *buf;
- buf = map_sysmem((ulong)addr, 0);
+ buf = map_sysmem(addr, 0);
working_fdt = buf;
- setenv_addr("fdtaddr", addr);
+ setenv_addr("fdtaddr", (void *)addr);
}
/*
@@ -123,7 +123,7 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (control)
gd->fdt_blob = blob;
else
- set_working_fdt_addr((void *)blob);
+ set_working_fdt_addr(addr);
if (argc >= 2) {
int len;
diff --git a/common/image-fdt.c b/common/image-fdt.c
index e3f06cd..d9e4728 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -190,7 +190,7 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree,
ulong *of_size)
*of_flat_tree = of_start;
*of_size = of_len;
- set_working_fdt_addr(*of_flat_tree);
+ set_working_fdt_addr((ulong)*of_flat_tree);
return 0;
error:
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 1f19fe4..ae5e8a3 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -100,7 +100,7 @@ void ft_pci_setup(void *blob, bd_t *bd);
*/
int ft_system_setup(void *blob, bd_t *bd);
-void set_working_fdt_addr(void *addr);
+void set_working_fdt_addr(ulong addr);
int fdt_shrink_to_minimum(void *blob);
int fdt_increase_size(void *fdt, int add_len);
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: HYP/non-sec: relocation before enable secondary cores
If CONFIG_ARMV7_PSCI is not defined and CONFIG_ARMV7_SECURE_BASE is defined, smp_kicl_all_cpus may enable secondary cores and runs into secure_ram_addr( _smp_pen), before code is relocated to secure ram. So need relocation to secure ram before enable secondary cores. Signed-off-by: Peng Fan --- arch/arm/cpu/armv7/virt-v7.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c index b69fd37..4cb8806 100644 --- a/arch/arm/cpu/armv7/virt-v7.c +++ b/arch/arm/cpu/armv7/virt-v7.c @@ -112,13 +112,20 @@ int armv7_init_nonsec(void) for (i = 1; i <= itlinesnr; i++) writel((unsigned)-1, gic_dist_addr + GICD_IGROUPRn + 4 * i); + /* +* Relocate secure section before any cpu runs in secure ram. +* smp_kick_all_cpus may enable other cores and runs into secure +* ram, so need to relocate secure section before enabling other +* cores. +*/ + relocate_secure_section(); + #ifndef CONFIG_ARMV7_PSCI smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), -1); smp_kick_all_cpus(); #endif /* call the non-sec switching code on this CPU also */ - relocate_secure_section(); secure_ram_addr(_nonsec_init)(); return 0; } -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 0/7] Exynos5: Fix warnings and enrich clock_get_periph_rate
This patch series does following changes - 1. Removing compiler warnings for clock_get_periph_rate. 2. Adding and enabling support for Exynos542x in clock_get_periph_rate. 3. Replacing peripheral specific function calls with clock_get_periph_rate. 4. Remove code from clocks file which became useless due to introduction of clock_get_periph_rate. Changes since v5: - Elaborated commit message and fixed a nit. Changes since v4: - Added Reviewed-by in patches 3 and 5. - Split patch 6 of version 4 into two patches 6 and 7. Changes since v3: - Added Reviewed-by & Tested-by in patches 1, 2 and 4. - Patch-3: Handled SPLL case in exynos542x_get_periph_rate. - Patch-3: Changed EXYNOS542x -> EXYNOS542X in pll_src_bit enum. - Merged pathces 5 and 6 of version 3. - Patch-6: New patch for dealing with variety of mask bits. Changes since v2: - Patch-1: Added debug message for unknown periph IDs. - Patch-2: Changed exynos5420 -> exynos542x in comment. - Patch-3: Fixed enum and soc_get_periph_rate switch. - Patch-3: Added checks for negative values in soc_get_periph_rate. - Patch-4: Added checks for negative values in soc_get_periph_rate. Changes since v1: - Added 2 new patches. Akshay Saraswat (7): Exynos5: Fix compiler warnings due to clock_get_periph_rate Exynos542x: Move exynos5420_get_pll_clk up and rename Exynos542x: Add and enable get_periph_rate support Exynos5: Fix exynos5_get_periph_rate calculations Exynos5: Use clock_get_periph_rate generic API Exynos: clock: change mask bits as per peripheral Exynos: Clock: Cleanup soc_get_periph_rate arch/arm/cpu/armv7/exynos/clock.c | 617 - arch/arm/include/asm/arch-exynos/clk.h | 4 + 2 files changed, 298 insertions(+), 323 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 1/7] Exynos5: Fix compiler warnings due to clock_get_periph_rate
Apparently, members of clk_bit_info array do not map correctly
to the members of enum periph_id. This mapping got broken after
we changed periph_id(s) to reflect interrupt number instead of
their position in a sequence. This patch intends to fix above
mentioned issue.
Signed-off-by: Akshay Saraswat
Reviewed-by: Simon Glass
Tested-by: Simon Glass
---
Changes since v5:
- No Change.
Changes since v4:
- No Change.
Changes since v3:
- Added Reviewed-by & Tested-by.
Changes since v2:
- Added debug message for unknown periph IDs.
Changes since v1:
- Removed exynos5_bit_info array name.
arch/arm/cpu/armv7/exynos/clock.c | 80 ---
1 file changed, 49 insertions(+), 31 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index b31c13b..6f20c81 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -20,42 +20,45 @@
* positions of the peripheral clocks of the src and div registers
*/
struct clk_bit_info {
+ enum periph_id id;
int8_t src_bit;
int8_t div_bit;
int8_t prediv_bit;
};
-/* src_bit div_bit prediv_bit */
+/* periph_id src_bit div_bit prediv_bit */
static struct clk_bit_info clk_bit_info[] = {
- {0, 0, -1},
- {4, 4, -1},
- {8, 8, -1},
- {12,12, -1},
- {0, 0, 8},
- {4, 16, 24},
- {8, 0, 8},
- {12,16, 24},
- {-1,-1, -1},
- {16,0, 8},
- {20,16, 24},
- {24,0, 8},
- {0, 0, 4},
- {4, 12, 16},
- {-1,-1, -1},
- {-1,-1, -1},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {24,0, -1},
- {24,0, -1},
- {24,0, -1},
- {24,0, -1},
- {24,0, -1},
+ {PERIPH_ID_UART0, 0, 0, -1},
+ {PERIPH_ID_UART1, 4, 4, -1},
+ {PERIPH_ID_UART2, 8, 8, -1},
+ {PERIPH_ID_UART3, 12, 12, -1},
+ {PERIPH_ID_I2C0,-1, 24, 0},
+ {PERIPH_ID_I2C1,-1, 24, 0},
+ {PERIPH_ID_I2C2,-1, 24, 0},
+ {PERIPH_ID_I2C3,-1, 24, 0},
+ {PERIPH_ID_I2C4,-1, 24, 0},
+ {PERIPH_ID_I2C5,-1, 24, 0},
+ {PERIPH_ID_I2C6,-1, 24, 0},
+ {PERIPH_ID_I2C7,-1, 24, 0},
+ {PERIPH_ID_SPI0,16, 0, 8},
+ {PERIPH_ID_SPI1,20, 16, 24},
+ {PERIPH_ID_SPI2,24, 0, 8},
+ {PERIPH_ID_SDMMC0, 0, 0, 8},
+ {PERIPH_ID_SDMMC1, 4, 16, 24},
+ {PERIPH_ID_SDMMC2, 8, 0, 8},
+ {PERIPH_ID_SDMMC3, 12, 16, 24},
+ {PERIPH_ID_I2S0,0, 0, 4},
+ {PERIPH_ID_I2S1,4, 12, 16},
+ {PERIPH_ID_SPI3,0, 0, 4},
+ {PERIPH_ID_SPI4,4, 12, 16},
+ {PERIPH_ID_SDMMC4, 16, 0, 8},
+ {PERIPH_ID_PWM0,24, 0, -1},
+ {PERIPH_ID_PWM1,24, 0, -1},
+ {PERIPH_ID_PWM2,24, 0, -1},
+ {PERIPH_ID_PWM3,24, 0, -1},
+ {PERIPH_ID_PWM4,24, 0, -1},
+
+ {PERIPH_ID_NONE,-1, -1, -1},
};
/* Epll Clock division values to achive different frequency output */
@@ -260,9 +263,24 @@ static unsigned long exynos5_get_pll_clk(int pllreg)
return fout;
}
+static struct clk_bit_info *get_clk_bit_info(int peripheral)
+{
+ int i;
+
+ for (i = 0; clk_bit_info[i].id != PERIPH_ID_NONE; i++) {
+ if (clk_bit_info[i].id == peripheral)
+ break;
+ }
+
+ if (clk_bit_info[i].id == PERIPH_ID_NONE)
+ debug("ERROR: Peripheral ID %d not found\n", peripheral);
+
+ return &clk_bit_info[i];
+}
+
static unsigned long exynos5_get_periph_rate(int peripheral)
{
- struct clk_bit_info *bit_info = &clk_bit_info[peripheral];
+ struct clk_bit_info *bit_info = get_clk_bit_info(peripheral);
unsigned long sclk, sub_clk;
unsigned int src, div, sub_div;
struct exynos5_clock *clk =
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/7] Exynos542x: Move exynos5420_get_pll_clk up and rename
Moving exynos5420_get_pll_clk function definition up in the
code to keep it together with rest of SoC_get_pll_clk functions.
This makes code more legible and also removes the need of
declaration when called before the position of definition in
code. Also, renaming exynos5420_get_pll_clk to
exynos542x_get_pll_clk because it is being used for both Exynos
5420 and 5800.
Signed-off-by: Akshay Saraswat
Reviewed-by: Simon Glass
Tested-by: Simon Glass
---
Changes since v5:
- No Change.
Changes since v4:
- No Change.
Changes since v3:
- Added Reviewed-by & Tested-by.
Changes since v2:
- Changed exynos5420 -> exynos542x in line 33.
Changes since v1:
- New patch.
arch/arm/cpu/armv7/exynos/clock.c | 82 +++
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 6f20c81..5dc9ed2 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -263,6 +263,46 @@ static unsigned long exynos5_get_pll_clk(int pllreg)
return fout;
}
+/* exynos542x: return pll clock frequency */
+static unsigned long exynos542x_get_pll_clk(int pllreg)
+{
+ struct exynos5420_clock *clk =
+ (struct exynos5420_clock *)samsung_get_base_clock();
+ unsigned long r, k = 0;
+
+ switch (pllreg) {
+ case APLL:
+ r = readl(&clk->apll_con0);
+ break;
+ case MPLL:
+ r = readl(&clk->mpll_con0);
+ break;
+ case EPLL:
+ r = readl(&clk->epll_con0);
+ k = readl(&clk->epll_con1);
+ break;
+ case VPLL:
+ r = readl(&clk->vpll_con0);
+ k = readl(&clk->vpll_con1);
+ break;
+ case BPLL:
+ r = readl(&clk->bpll_con0);
+ break;
+ case RPLL:
+ r = readl(&clk->rpll_con0);
+ k = readl(&clk->rpll_con1);
+ break;
+ case SPLL:
+ r = readl(&clk->spll_con0);
+ break;
+ default:
+ printf("Unsupported PLL (%d)\n", pllreg);
+ return 0;
+ }
+
+ return exynos_get_pll_clk(pllreg, r, k);
+}
+
static struct clk_bit_info *get_clk_bit_info(int peripheral)
{
int i;
@@ -382,46 +422,6 @@ unsigned long clock_get_periph_rate(int peripheral)
return 0;
}
-/* exynos5420: return pll clock frequency */
-static unsigned long exynos5420_get_pll_clk(int pllreg)
-{
- struct exynos5420_clock *clk =
- (struct exynos5420_clock *)samsung_get_base_clock();
- unsigned long r, k = 0;
-
- switch (pllreg) {
- case APLL:
- r = readl(&clk->apll_con0);
- break;
- case MPLL:
- r = readl(&clk->mpll_con0);
- break;
- case EPLL:
- r = readl(&clk->epll_con0);
- k = readl(&clk->epll_con1);
- break;
- case VPLL:
- r = readl(&clk->vpll_con0);
- k = readl(&clk->vpll_con1);
- break;
- case BPLL:
- r = readl(&clk->bpll_con0);
- break;
- case RPLL:
- r = readl(&clk->rpll_con0);
- k = readl(&clk->rpll_con1);
- break;
- case SPLL:
- r = readl(&clk->spll_con0);
- break;
- default:
- printf("Unsupported PLL (%d)\n", pllreg);
- return 0;
- }
-
- return exynos_get_pll_clk(pllreg, r, k);
-}
-
/* exynos4: return ARM clock frequency */
static unsigned long exynos4_get_arm_clk(void)
{
@@ -1603,7 +1603,7 @@ unsigned long get_pll_clk(int pllreg)
{
if (cpu_is_exynos5()) {
if (proid_is_exynos5420() || proid_is_exynos5800())
- return exynos5420_get_pll_clk(pllreg);
+ return exynos542x_get_pll_clk(pllreg);
return exynos5_get_pll_clk(pllreg);
} else {
if (proid_is_exynos4412())
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 3/7] Exynos542x: Add and enable get_periph_rate support
We planned to fetch peripheral rate through one generic API per
peripheral. These generic peripheral functions are in turn
expected to fetch apt values from a function refactored as
per SoC versions. This patch adds support for fetching peripheral
rates for Exynos5420 and Exynos5800.
Signed-off-by: Akshay Saraswat
Reviewed-by: Simon Glass
---
Changes since v5:
- No Change.
Changes since v4:
- Added Reviewed-by.
Changes since v3:
- Added a case for SPLL in exynos542x_get_periph_rate.
- Changed EXYNOS542x -> EXYNOS542X.
Changes since v2:
- Fixed enum and exynos542x_get_periph_rate switch.
- Added checks for negative values in exynos542x_get_periph_rate.
Changes since v1:
- Changes suuport -> support in commit message.
- Removed position change of exynos5420_get_pll_clk.
- Removed #ifdef.
arch/arm/cpu/armv7/exynos/clock.c | 153 +++--
arch/arm/include/asm/arch-exynos/clk.h | 4 +
2 files changed, 150 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 5dc9ed2..16900cc 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -27,7 +27,7 @@ struct clk_bit_info {
};
/* periph_id src_bit div_bit prediv_bit */
-static struct clk_bit_info clk_bit_info[] = {
+static struct clk_bit_info exynos5_bit_info[] = {
{PERIPH_ID_UART0, 0, 0, -1},
{PERIPH_ID_UART1, 4, 4, -1},
{PERIPH_ID_UART2, 8, 8, -1},
@@ -61,6 +61,41 @@ static struct clk_bit_info clk_bit_info[] = {
{PERIPH_ID_NONE,-1, -1, -1},
};
+static struct clk_bit_info exynos542x_bit_info[] = {
+ {PERIPH_ID_UART0, 4, 8, -1},
+ {PERIPH_ID_UART1, 8, 12, -1},
+ {PERIPH_ID_UART2, 12, 16, -1},
+ {PERIPH_ID_UART3, 16, 20, -1},
+ {PERIPH_ID_I2C0,-1, 8, -1},
+ {PERIPH_ID_I2C1,-1, 8, -1},
+ {PERIPH_ID_I2C2,-1, 8, -1},
+ {PERIPH_ID_I2C3,-1, 8, -1},
+ {PERIPH_ID_I2C4,-1, 8, -1},
+ {PERIPH_ID_I2C5,-1, 8, -1},
+ {PERIPH_ID_I2C6,-1, 8, -1},
+ {PERIPH_ID_I2C7,-1, 8, -1},
+ {PERIPH_ID_SPI0,20, 20, 8},
+ {PERIPH_ID_SPI1,24, 24, 16},
+ {PERIPH_ID_SPI2,28, 28, 24},
+ {PERIPH_ID_SDMMC0, 8, 0, -1},
+ {PERIPH_ID_SDMMC1, 12, 10, -1},
+ {PERIPH_ID_SDMMC2, 16, 20, -1},
+ {PERIPH_ID_I2C8,-1, 8, -1},
+ {PERIPH_ID_I2C9,-1, 8, -1},
+ {PERIPH_ID_I2S0,0, 0, 4},
+ {PERIPH_ID_I2S1,4, 12, 16},
+ {PERIPH_ID_SPI3,12, 16, 0},
+ {PERIPH_ID_SPI4,16, 20, 8},
+ {PERIPH_ID_PWM0,24, 28, -1},
+ {PERIPH_ID_PWM1,24, 28, -1},
+ {PERIPH_ID_PWM2,24, 28, -1},
+ {PERIPH_ID_PWM3,24, 28, -1},
+ {PERIPH_ID_PWM4,24, 28, -1},
+ {PERIPH_ID_I2C10, -1, 8, -1},
+
+ {PERIPH_ID_NONE,-1, -1, -1},
+};
+
/* Epll Clock division values to achive different frequency output */
static struct set_epll_con_val exynos5_epll_div[] = {
{ 19200, 0, 48, 3, 1, 0 },
@@ -306,16 +341,22 @@ static unsigned long exynos542x_get_pll_clk(int pllreg)
static struct clk_bit_info *get_clk_bit_info(int peripheral)
{
int i;
+ struct clk_bit_info *info;
+
+ if (proid_is_exynos5420() || proid_is_exynos5800())
+ info = exynos542x_bit_info;
+ else
+ info = exynos5_bit_info;
- for (i = 0; clk_bit_info[i].id != PERIPH_ID_NONE; i++) {
- if (clk_bit_info[i].id == peripheral)
+ for (i = 0; info[i].id != PERIPH_ID_NONE; i++) {
+ if (info[i].id == peripheral)
break;
}
- if (clk_bit_info[i].id == PERIPH_ID_NONE)
+ if (info[i].id == PERIPH_ID_NONE)
debug("ERROR: Peripheral ID %d not found\n", peripheral);
- return &clk_bit_info[i];
+ return &info[i];
}
static unsigned long exynos5_get_periph_rate(int peripheral)
@@ -414,12 +455,110 @@ static unsigned long exynos5_get_periph_rate(int
peripheral)
return sub_clk;
}
+static unsigned long exynos542x_get_periph_rate(int peripheral)
+{
+ struct clk_bit_info *bit_info = get_clk_bit_info(peripheral);
+ unsigned long sclk, sub_clk = 0;
+ unsigned int src, div, sub_div = 0;
+ struct exynos5420_clock *clk =
+ (struct exynos5420_clock *)samsung_get_base_clock();
+
+ switch (peripheral) {
+ case
[U-Boot] [PATCH v6 4/7] Exynos5: Fix exynos5_get_periph_rate calculations
exynos5_get_periph_rate function reads incorrect div for
SDMMC2 & 3. It also reads prediv and does division only for
SDMMC0 & 2 when actually various other peripherals need that.
Adding changes to fix these mistakes in periph rate calculation.
Signed-off-by: Akshay Saraswat
Reviewed-by: Simon Glass
Tested-by: Simon Glass
---
Changes since v5:
- No Change.
Changes since v4:
- No Change.
Changes since v3:
- Added Reviewed-by & Tested-by.
Changes since v2:
- Added checks for negative values in exynos5_get_periph_rate.
Changes since v1:
- New patch.
arch/arm/cpu/armv7/exynos/clock.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 16900cc..78f784a 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -362,8 +362,8 @@ static struct clk_bit_info *get_clk_bit_info(int peripheral)
static unsigned long exynos5_get_periph_rate(int peripheral)
{
struct clk_bit_info *bit_info = get_clk_bit_info(peripheral);
- unsigned long sclk, sub_clk;
- unsigned int src, div, sub_div;
+ unsigned long sclk, sub_clk = 0;
+ unsigned int src, div, sub_div = 0;
struct exynos5_clock *clk =
(struct exynos5_clock *)samsung_get_base_clock();
@@ -402,10 +402,13 @@ static unsigned long exynos5_get_periph_rate(int
peripheral)
break;
case PERIPH_ID_SDMMC0:
case PERIPH_ID_SDMMC1:
+ src = readl(&clk->src_fsys);
+ div = readl(&clk->div_fsys1);
+ break;
case PERIPH_ID_SDMMC2:
case PERIPH_ID_SDMMC3:
src = readl(&clk->src_fsys);
- div = readl(&clk->div_fsys1);
+ div = readl(&clk->div_fsys2);
break;
case PERIPH_ID_I2C0:
case PERIPH_ID_I2C1:
@@ -426,7 +429,8 @@ static unsigned long exynos5_get_periph_rate(int peripheral)
return -1;
};
- src = (src >> bit_info->src_bit) & 0xf;
+ if (bit_info->src_bit >= 0)
+ src = (src >> bit_info->src_bit) & 0xf;
switch (src) {
case EXYNOS_SRC_MPLL:
@@ -443,11 +447,12 @@ static unsigned long exynos5_get_periph_rate(int
peripheral)
}
/* Ratio clock division for this peripheral */
- sub_div = (div >> bit_info->div_bit) & 0xf;
- sub_clk = sclk / (sub_div + 1);
+ if (bit_info->div_bit >= 0) {
+ sub_div = (div >> bit_info->div_bit) & 0xf;
+ sub_clk = sclk / (sub_div + 1);
+ }
- /* Pre-ratio clock division for SDMMC0 and 2 */
- if (peripheral == PERIPH_ID_SDMMC0 || peripheral == PERIPH_ID_SDMMC2) {
+ if (bit_info->prediv_bit >= 0) {
div = (div >> bit_info->prediv_bit) & 0xff;
return sub_clk / (div + 1);
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 6/7] Exynos: clock: change mask bits as per peripheral
We have assumed and kept mask bits for divider and pre-divider
as 0xf and 0xff, respectively. But these mask bits change from
one peripheral to another, and hence, need to be specified in
accordance with the peripherals.
Signed-off-by: Akshay Saraswat
---
Changes since v5:
- No Change.
Changes since v4:
- Isolated maskbit changes.
Changes since v3:
- New patch.
arch/arm/cpu/armv7/exynos/clock.c | 151 --
1 file changed, 78 insertions(+), 73 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index f19fb5c..3884d4b 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -21,79 +21,83 @@
*/
struct clk_bit_info {
enum periph_id id;
+ int32_t src_mask;
+ int32_t div_mask;
+ int32_t prediv_mask;
int8_t src_bit;
int8_t div_bit;
int8_t prediv_bit;
};
-/* periph_id src_bit div_bit prediv_bit */
static struct clk_bit_info exynos5_bit_info[] = {
- {PERIPH_ID_UART0, 0, 0, -1},
- {PERIPH_ID_UART1, 4, 4, -1},
- {PERIPH_ID_UART2, 8, 8, -1},
- {PERIPH_ID_UART3, 12, 12, -1},
- {PERIPH_ID_I2C0,-1, 24, 0},
- {PERIPH_ID_I2C1,-1, 24, 0},
- {PERIPH_ID_I2C2,-1, 24, 0},
- {PERIPH_ID_I2C3,-1, 24, 0},
- {PERIPH_ID_I2C4,-1, 24, 0},
- {PERIPH_ID_I2C5,-1, 24, 0},
- {PERIPH_ID_I2C6,-1, 24, 0},
- {PERIPH_ID_I2C7,-1, 24, 0},
- {PERIPH_ID_SPI0,16, 0, 8},
- {PERIPH_ID_SPI1,20, 16, 24},
- {PERIPH_ID_SPI2,24, 0, 8},
- {PERIPH_ID_SDMMC0, 0, 0, 8},
- {PERIPH_ID_SDMMC1, 4, 16, 24},
- {PERIPH_ID_SDMMC2, 8, 0, 8},
- {PERIPH_ID_SDMMC3, 12, 16, 24},
- {PERIPH_ID_I2S0,0, 0, 4},
- {PERIPH_ID_I2S1,4, 12, 16},
- {PERIPH_ID_SPI3,0, 0, 4},
- {PERIPH_ID_SPI4,4, 12, 16},
- {PERIPH_ID_SDMMC4, 16, 0, 8},
- {PERIPH_ID_PWM0,24, 0, -1},
- {PERIPH_ID_PWM1,24, 0, -1},
- {PERIPH_ID_PWM2,24, 0, -1},
- {PERIPH_ID_PWM3,24, 0, -1},
- {PERIPH_ID_PWM4,24, 0, -1},
-
- {PERIPH_ID_NONE,-1, -1, -1},
+ /* periph ids_mask d_mask p_mask s_bit d_bit p_bit */
+ {PERIPH_ID_UART0, 0xf,0xf,-1, 0, 0, -1},
+ {PERIPH_ID_UART1, 0xf,0xf,-1, 4, 4, -1},
+ {PERIPH_ID_UART2, 0xf,0xf,-1, 8, 8, -1},
+ {PERIPH_ID_UART3, 0xf,0xf,-1, 12, 12, -1},
+ {PERIPH_ID_I2C0,-1, 0x7,0x7,-1, 24, 0},
+ {PERIPH_ID_I2C1,-1, 0x7,0x7,-1, 24, 0},
+ {PERIPH_ID_I2C2,-1, 0x7,0x7,-1, 24, 0},
+ {PERIPH_ID_I2C3,-1, 0x7,0x7,-1, 24, 0},
+ {PERIPH_ID_I2C4,-1, 0x7,0x7,-1, 24, 0},
+ {PERIPH_ID_I2C5,-1, 0x7,0x7,-1, 24, 0},
+ {PERIPH_ID_I2C6,-1, 0x7,0x7,-1, 24, 0},
+ {PERIPH_ID_I2C7,-1, 0x7,0x7,-1, 24, 0},
+ {PERIPH_ID_SPI0,0xf,0xf,0xff, 16, 0, 8},
+ {PERIPH_ID_SPI1,0xf,0xf,0xff, 20, 16, 24},
+ {PERIPH_ID_SPI2,0xf,0xf,0xff, 24, 0, 8},
+ {PERIPH_ID_SDMMC0, 0xf,0xf,0xff, 0, 0, 8},
+ {PERIPH_ID_SDMMC1, 0xf,0xf,0xff, 4, 16, 24},
+ {PERIPH_ID_SDMMC2, 0xf,0xf,0xff, 8, 0, 8},
+ {PERIPH_ID_SDMMC3, 0xf,0xf,0xff, 12, 16, 24},
+ {PERIPH_ID_I2S0,0xf,0xf,0xff, 0, 0, 4},
+ {PERIPH_ID_I2S1,0xf,0xf,0xff, 4, 12, 16},
+ {PERIPH_ID_SPI3,0xf,0xf,0xff, 0, 0, 4},
+ {PERIPH_ID_SPI4,0xf,0xf,0xff, 4, 12, 16},
+ {PERIPH_ID_SDMMC4, 0xf,0xf,0xff, 16, 0, 8},
+ {PERIPH_ID_PWM0,0xf,0xf,-1, 24, 0, -1},
+ {PERIPH_ID_PWM1,0xf,0xf,-1, 24, 0, -1},
+ {PERIPH_ID_PWM2,0xf,0xf,-1, 24, 0, -1},
+ {PERIPH_ID_PWM3,0xf,0xf,-1, 24, 0, -1},
+ {PERIPH_ID_PWM4,0xf,0xf,-1, 24, 0, -1},
+
+ {PERIPH_ID_NONE,-1, -1, -1, -1, -1,
[U-Boot] [PATCH v6 5/7] Exynos5: Use clock_get_periph_rate generic API
Replacing SoC and peripheral specific function calls with generic
clock_get_periph_rate calls to get the peripheral clocks.
Also, removing dead code of peripheral and SoC specific function
implementations which was used earlier for fetching peripheral clocks.
This code is not being used anymore because of the introduction
of generic clock_get_periph_rate function.
Signed-off-by: Akshay Saraswat
Reviewed-by: Simon Glass
---
Changes since v5:
- No Change.
Changes since v4:
- Added Reviewed-by.
Changes since v3:
- Merged patches 5 and 6 of version 3 to fix build errors.
Changes since v2:
- No change.
Changes since v1:
- Separated exynos5_get_periph_rate fixes into another patch.
arch/arm/cpu/armv7/exynos/clock.c | 278 ++
1 file changed, 43 insertions(+), 235 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 78f784a..f19fb5c 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -689,27 +689,6 @@ static unsigned long exynos4x12_get_pwm_clk(void)
return pclk;
}
-/* exynos5420: return pwm clock frequency */
-static unsigned long exynos5420_get_pwm_clk(void)
-{
- struct exynos5420_clock *clk =
- (struct exynos5420_clock *)samsung_get_base_clock();
- unsigned long pclk, sclk;
- unsigned int ratio;
-
- /*
-* CLK_DIV_PERIC0
-* PWM_RATIO [31:28]
-*/
- ratio = readl(&clk->div_peric0);
- ratio = (ratio >> 28) & 0xf;
- sclk = get_pll_clk(MPLL);
-
- pclk = sclk / (ratio + 1);
-
- return pclk;
-}
-
/* exynos4: return uart clock frequency */
static unsigned long exynos4_get_uart_clk(int dev_index)
{
@@ -802,100 +781,6 @@ static unsigned long exynos4x12_get_uart_clk(int
dev_index)
return uclk;
}
-/* exynos5: return uart clock frequency */
-static unsigned long exynos5_get_uart_clk(int dev_index)
-{
- struct exynos5_clock *clk =
- (struct exynos5_clock *)samsung_get_base_clock();
- unsigned long uclk, sclk;
- unsigned int sel;
- unsigned int ratio;
-
- /*
-* CLK_SRC_PERIC0
-* UART0_SEL [3:0]
-* UART1_SEL [7:4]
-* UART2_SEL [8:11]
-* UART3_SEL [12:15]
-* UART4_SEL [16:19]
-* UART5_SEL [23:20]
-*/
- sel = readl(&clk->src_peric0);
- sel = (sel >> (dev_index << 2)) & 0xf;
-
- if (sel == 0x6)
- sclk = get_pll_clk(MPLL);
- else if (sel == 0x7)
- sclk = get_pll_clk(EPLL);
- else if (sel == 0x8)
- sclk = get_pll_clk(VPLL);
- else
- return 0;
-
- /*
-* CLK_DIV_PERIC0
-* UART0_RATIO [3:0]
-* UART1_RATIO [7:4]
-* UART2_RATIO [8:11]
-* UART3_RATIO [12:15]
-* UART4_RATIO [16:19]
-* UART5_RATIO [23:20]
-*/
- ratio = readl(&clk->div_peric0);
- ratio = (ratio >> (dev_index << 2)) & 0xf;
-
- uclk = sclk / (ratio + 1);
-
- return uclk;
-}
-
-/* exynos5420: return uart clock frequency */
-static unsigned long exynos5420_get_uart_clk(int dev_index)
-{
- struct exynos5420_clock *clk =
- (struct exynos5420_clock *)samsung_get_base_clock();
- unsigned long uclk, sclk;
- unsigned int sel;
- unsigned int ratio;
-
- /*
-* CLK_SRC_PERIC0
-* UART0_SEL [6:4]
-* UART1_SEL [10:8]
-* UART2_SEL [14:12]
-* UART3_SEL [18:16]
-* generalised calculation as follows
-* sel = (sel >> ((dev_index * 4) + 4)) & mask;
-*/
- sel = readl(&clk->src_peric0);
- sel = (sel >> ((dev_index * 4) + 4)) & 0x7;
-
- if (sel == 0x3)
- sclk = get_pll_clk(MPLL);
- else if (sel == 0x6)
- sclk = get_pll_clk(EPLL);
- else if (sel == 0x7)
- sclk = get_pll_clk(RPLL);
- else
- return 0;
-
- /*
-* CLK_DIV_PERIC0
-* UART0_RATIO [11:8]
-* UART1_RATIO [15:12]
-* UART2_RATIO [19:16]
-* UART3_RATIO [23:20]
-* generalised calculation as follows
-* ratio = (ratio >> ((dev_index * 4) + 8)) & mask;
-*/
- ratio = readl(&clk->div_peric0);
- ratio = (ratio >> ((dev_index * 4) + 8)) & 0xf;
-
- uclk = sclk / (ratio + 1);
-
- return uclk;
-}
-
static unsigned long exynos4_get_mmc_clk(int dev_index)
{
struct exynos4_clock *clk =
@@ -945,94 +830,6 @@ static unsigned long exynos4_get_mmc_clk(int dev_index)
return uclk;
}
-static unsigned long exynos5_get_mmc_clk(int dev_index)
-{
- struct exynos5_clock *clk =
- (struct exynos5_clock *)samsung_get_base_clock();
- unsigned long uclk, sclk;
- unsigned int sel, ratio, pre_ratio;
- int shift = 0;
-
- sel = readl(&clk->src_fsys);
-
[U-Boot] [PATCH v6 7/7] Exynos: Clock: Cleanup soc_get_periph_rate
Since we have src, div and pre-div mask bits defined corresponding
to peripherals, calculation of clock specific to I2C appears
redundant and confusing. Using clk_bit_info struct we can write
calculations generic to all peripherals which makes code easy to
understand and free from peripheral specific exceptions.
Signed-off-by: Akshay Saraswat
---
Changes since v5:
- Elaborated Commit message and fixed a nit.
Changes since v4:
- New patch.
arch/arm/cpu/armv7/exynos/clock.c | 74 ++-
1 file changed, 35 insertions(+), 39 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 3884d4b..5777490 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -366,8 +366,8 @@ static struct clk_bit_info *get_clk_bit_info(int peripheral)
static unsigned long exynos5_get_periph_rate(int peripheral)
{
struct clk_bit_info *bit_info = get_clk_bit_info(peripheral);
- unsigned long sclk, sub_clk = 0;
- unsigned int src, div, sub_div = 0;
+ unsigned long sclk = 0;
+ unsigned int src = 0, div = 0, sub_div = 0;
struct exynos5_clock *clk =
(struct exynos5_clock *)samsung_get_base_clock();
@@ -389,30 +389,30 @@ static unsigned long exynos5_get_periph_rate(int
peripheral)
break;
case PERIPH_ID_I2S0:
src = readl(&clk->src_mau);
- div = readl(&clk->div_mau);
+ div = sub_div = readl(&clk->div_mau);
case PERIPH_ID_SPI0:
case PERIPH_ID_SPI1:
src = readl(&clk->src_peric1);
- div = readl(&clk->div_peric1);
+ div = sub_div = readl(&clk->div_peric1);
break;
case PERIPH_ID_SPI2:
src = readl(&clk->src_peric1);
- div = readl(&clk->div_peric2);
+ div = sub_div = readl(&clk->div_peric2);
break;
case PERIPH_ID_SPI3:
case PERIPH_ID_SPI4:
src = readl(&clk->sclk_src_isp);
- div = readl(&clk->sclk_div_isp);
+ div = sub_div = readl(&clk->sclk_div_isp);
break;
case PERIPH_ID_SDMMC0:
case PERIPH_ID_SDMMC1:
src = readl(&clk->src_fsys);
- div = readl(&clk->div_fsys1);
+ div = sub_div = readl(&clk->div_fsys1);
break;
case PERIPH_ID_SDMMC2:
case PERIPH_ID_SDMMC3:
src = readl(&clk->src_fsys);
- div = readl(&clk->div_fsys2);
+ div = sub_div = readl(&clk->div_fsys2);
break;
case PERIPH_ID_I2C0:
case PERIPH_ID_I2C1:
@@ -422,12 +422,10 @@ static unsigned long exynos5_get_periph_rate(int
peripheral)
case PERIPH_ID_I2C5:
case PERIPH_ID_I2C6:
case PERIPH_ID_I2C7:
- sclk = exynos5_get_pll_clk(MPLL);
- sub_div = ((readl(&clk->div_top1) >> bit_info->div_bit)
- & bit_info->div_mask) + 1;
- div = ((readl(&clk->div_top0) >> bit_info->prediv_bit)
- & bit_info->prediv_mask) + 1;
- return (sclk / sub_div) / div;
+ src = EXYNOS_SRC_MPLL;
+ div = readl(&clk->div_top0);
+ sub_div = readl(&clk->div_top1);
+ break;
default:
debug("%s: invalid peripheral %d", __func__, peripheral);
return -1;
@@ -447,28 +445,28 @@ static unsigned long exynos5_get_periph_rate(int
peripheral)
sclk = exynos5_get_pll_clk(VPLL);
break;
default:
+ debug("%s: EXYNOS_SRC %d not supported\n", __func__, src);
return 0;
}
- /* Ratio clock division for this peripheral */
- if (bit_info->div_bit >= 0) {
- sub_div = (div >> bit_info->div_bit) & bit_info->div_mask;
- sub_clk = sclk / (sub_div + 1);
- }
+ /* Clock divider ratio for this peripheral */
+ if (bit_info->div_bit >= 0)
+ div = (div >> bit_info->div_bit) & bit_info->div_mask;
- if (bit_info->prediv_bit >= 0) {
- div = (div >> bit_info->prediv_bit) & bit_info->prediv_mask;
- return sub_clk / (div + 1);
- }
+ /* Clock pre-divider ratio for this peripheral */
+ if (bit_info->prediv_bit >= 0)
+ sub_div = (sub_div >> bit_info->prediv_bit)
+ & bit_info->prediv_mask;
- return sub_clk;
+ /* Calculate and return required clock rate */
+ return (sclk / (div + 1)) / (sub_div + 1);
}
static unsigned long exynos542x_get_periph_rate(int peripheral)
{
struct clk_bit_info *bit_info = get_clk_bit_info(peripheral);
- unsigned long sclk, sub_clk = 0;
- unsigned int src, div, sub_div = 0;
+ unsigned long sclk = 0
Re: [U-Boot] Let's bury CONFIG_NEEDS_MANUAL_RELOC
Hello Graeme, On Wed, 04 Feb 2015 18:14:22 +1100, Graeme Russ wrote: > Hi Guys, > > Since I did the initial 'full relocation' for x86 way back when > (http://git.denx.de/?p=u-boot.git;a=commit;h=1c409bc7101a24ecd47a13a4e851845d66dc23ce), > > there has been a lot of chatter about the ongoing need for > CONFIG_NEEDS_MANUAL_RELOC. I think it's about time we looked really hard > at this define and come to a definitive conclusion as to IF and HOW we > can get rid of it for the remaining architectures that use it (being > avr32, m68k, nds32, and sparc). I second that. > First, a bit of a primer on why and how I finally killed off > CONFIG_NEEDS_MANUAL_RELOC for x86... > > Despite the best intentions of the 'manual' relocation performed by > U-Boot, there were still instances where the U-Boot binary referenced > the 'unrelocated' image which typically resides in flash (NOR flash in > the case of the x86 board I was using). I only finally tracked this down > through some arduous debugging of random crashes during the writing of a > new U-Boot image to the NOR flash. > > After a lot of digging around, I managed to get a good understanding of > the ELF binary format for x86 and compiler/linker flags needed in order > to generate a binary image that could be relocated. It turns out that > for x86, it was the -pic and --emit-relocs ld flags (Oddly, I cannot > find the -pic flag in the gnu ld documentation maybe it's depricated?) When I did the ELF relocation for ARM, only -pie existed for ld; but it has an alias, --pic-executable. Maybe -pic is short for -pic-executable? > The --emit-relocs flags leaves the relocation sections (for x86 the > section of interest is .rela.dyn) in the final image. These sections > list all the locations in the final binary that need to be adjusted if > the image is loaded at a different address than the one it is compiled > for. You can see the processing in do_elf_reloc_fixups() in > arch/x86/lib/relocate.c For ARM I just specified the placement of relocation sections in the linker script; I'm surprised that x86 needs this --emit-relocs. Maybe that's needed when one does not provide a custom linker script? > Keep in mind that the relocation sections are NOT copied to RAM - they > are only used once after U-Boot is copied to RAM to locate the memory > locations that need to be adjusted. > > So the crux of generic relocation is to generate a stripped binary with > all necessary ELF relocation information located AFTER the text and data > sections which are copied to RAM > > So the first question that we need to answer is: Do the avr32, m68k, > nds32, and sparc toolchains support the generation of the relevant > sections needed to perform relocation in a manner similar to x86 (i.e > generation of relocation references into sections of the final U-Boot > binary)? Those arches which use GCC should be able to use -pie / -pic-executable and possibly --emit-relocs, as none of these is arch-specific. Then, each arch might have to look into what GCC options are needed. For the record, on ARM, I did not need any gcc option, but actually had one -fPIC option /removed/. > Regards, > > Graeme Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Hello Michal, On Wed, 4 Feb 2015 10:56:02 +0100, Michal Simek wrote: > On 02/04/2015 04:11 AM, Masahiro Yamada wrote: > > Hi Michal, > > > > > > On Tue, 3 Feb 2015 10:11:39 +0100 > > Michal Simek wrote: > > > >> Hi Simon, > >> > >> On 02/03/2015 03:02 AM, Masahiro Yamada wrote: > >>> Hi. > >>> > >>> > >>> On Mon, 2 Feb 2015 16:57:15 -0700 > >>> Simon Glass wrote: > >>> > Hi Michal, > > On 2 February 2015 at 08:31, Michal Simek > wrote: > > Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA > > relocation (mostly only GOT) where functions aray are not > > updated. This patch is fixing function pointers for DM core > > and serial-uclass to ensure that relocated functions are called. > > > > Signed-off-by: Michal Simek > > --- > > > > drivers/core/root.c| 64 > > ++ > > drivers/serial/serial-uclass.c | 16 +++ > > 2 files changed, 80 insertions(+) > > How long will we have to carry this patch? It seems that if we add any > new driver we will have to add more code like this? > >>> > >>> > >>> > >>> This patch is unfortunate. > >>> Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day? > >> > >> This patch (or similar one) has to be alive when we have platform > >> which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. > >> There is an option to move to REL/RELA but the question is if > >> all platforms have it/support it. Unfortunately I think that > >> it will be in the tree for a long time. > >> > >>> > >>> If we use SPL, we do not have to relocate code, I think. > >> > >> SPL doesn't have relocation that's why this code is not used there. > >> > > > > It is not what I meant. > > > > > > If SPL can directly load the main u-boot image > > to the DRAM address where it is linked, > > we do not relocate the code in the main image. > > Current behavior is that SPL is reading u-boot.img entry point which > can be in any location and jump to it and u-boot self relocate to the end of > memory. > If SPL adds u-boot directly to the location where it should run after > relocation > then relocation is not needed. > To ensure this capability (based on my poor GOT/REL/RELA) experience it means > that SPL loads u-boot to that location and patch REL/RELA section based on > this location > and internal relocation should be skipped. IOW, that SPL perform the work of relocate_code() in U-Boot -- at least, on ARM, where REL/RELA is used. > This is definitely doable for REL/RELA case and it can also speedup boot > process Not sure about the speed-up, but never mind. > (I don't think there is easy way how to solve this with just GOT relocation > because > of that MANUAL_RELOC code which is patching arrays with function pointers). Even without importing SPL in the equation, switching from GOT to REL/RELA has enourmous advantages. > Thanks, > Michal Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] odroid: update link to X2/U3 proprietary binaries
Hello Tobias, You should use git send-email (or better yet, patman) for sending patches; this one was attached instead of inline. That being said, it did not seem to worry patchwork, so you don't need to repost this one. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hang when enabling DCache on a iMX6 board
Hi Anatolij, On Tue, 3 Feb 2015 20:17:36 +0100 Anatolij Gustschin wrote: > Hello Boris, > > On Tue, 3 Feb 2015 19:39:16 +0100 > Boris Brezillon wrote: > > > Hello, > > > > I'm currently porting the SECO iMX6 uQ7 board to mainline, but I'm > > facing a hang when enabling DCache (CONFIG_SYS_DCACHE_OFF undefined). > > Last week I asked on the #u-boot chan if anybody already encountered > > such a bug, and someone (named malik) suggested to check my DDR timings. > > > > After a few more tests and checks I decided to port my changes to an > > older version (2014.04), and it apparently works. > > I haven't bisected to find the exact commit that makes it fails yet, > > but before doing that I'd like to know if anyone else already > > experienced this kind of problem, or has any idea of what could cause > > this. > > I've seen similar problem when porting to v2014.04. The problem > disappeared after including the mx6_common.h in the board config > file. This header file contains some errata configs, so please try > with > > #include "mx6_common.h" > > in your board config file. Indeed, it works! \o/ I don't know how, but I somehow included this header when backporting my work to v2014.04, which explains why it was working on this version. Anyway, thanks a lot for your answer (I owe you one). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: HYP/non-sec: relocation before enable secondary cores
On 04/02/15 10:15, Peng Fan wrote: > If CONFIG_ARMV7_PSCI is not defined and CONFIG_ARMV7_SECURE_BASE is defined, > smp_kicl_all_cpus may enable secondary cores and runs into secure_ram_addr( > _smp_pen), before code is relocated to secure ram. > So need relocation to secure ram before enable secondary cores. > > Signed-off-by: Peng Fan > --- > arch/arm/cpu/armv7/virt-v7.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c > index b69fd37..4cb8806 100644 > --- a/arch/arm/cpu/armv7/virt-v7.c > +++ b/arch/arm/cpu/armv7/virt-v7.c > @@ -112,13 +112,20 @@ int armv7_init_nonsec(void) > for (i = 1; i <= itlinesnr; i++) > writel((unsigned)-1, gic_dist_addr + GICD_IGROUPRn + 4 * i); > > + /* > + * Relocate secure section before any cpu runs in secure ram. > + * smp_kick_all_cpus may enable other cores and runs into secure > + * ram, so need to relocate secure section before enabling other > + * cores. > + */ > + relocate_secure_section(); > + > #ifndef CONFIG_ARMV7_PSCI > smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), -1); > smp_kick_all_cpus(); > #endif > > /* call the non-sec switching code on this CPU also */ > - relocate_secure_section(); > secure_ram_addr(_nonsec_init)(); > return 0; > } > Seems like a sensible thing to do. FWIW: Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Hi Albert, On 02/04/2015 11:34 AM, Albert ARIBAUD wrote: > Hello Michal, > > On Wed, 4 Feb 2015 10:56:02 +0100, Michal Simek > wrote: >> On 02/04/2015 04:11 AM, Masahiro Yamada wrote: >>> Hi Michal, >>> >>> >>> On Tue, 3 Feb 2015 10:11:39 +0100 >>> Michal Simek wrote: >>> Hi Simon, On 02/03/2015 03:02 AM, Masahiro Yamada wrote: > Hi. > > > On Mon, 2 Feb 2015 16:57:15 -0700 > Simon Glass wrote: > >> Hi Michal, >> >> On 2 February 2015 at 08:31, Michal Simek >> wrote: >>> Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA >>> relocation (mostly only GOT) where functions aray are not >>> updated. This patch is fixing function pointers for DM core >>> and serial-uclass to ensure that relocated functions are called. >>> >>> Signed-off-by: Michal Simek >>> --- >>> >>> drivers/core/root.c| 64 >>> ++ >>> drivers/serial/serial-uclass.c | 16 +++ >>> 2 files changed, 80 insertions(+) >> >> How long will we have to carry this patch? It seems that if we add any >> new driver we will have to add more code like this? > > > > This patch is unfortunate. > Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day? This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time. > > If we use SPL, we do not have to relocate code, I think. SPL doesn't have relocation that's why this code is not used there. >>> >>> It is not what I meant. >>> >>> >>> If SPL can directly load the main u-boot image >>> to the DRAM address where it is linked, >>> we do not relocate the code in the main image. >> >> Current behavior is that SPL is reading u-boot.img entry point which >> can be in any location and jump to it and u-boot self relocate to the end of >> memory. >> If SPL adds u-boot directly to the location where it should run after >> relocation >> then relocation is not needed. >> To ensure this capability (based on my poor GOT/REL/RELA) experience it means >> that SPL loads u-boot to that location and patch REL/RELA section based on >> this location >> and internal relocation should be skipped. > > IOW, that SPL perform the work of relocate_code() in U-Boot -- at least, > on ARM, where REL/RELA is used. Maybe we don't understand each other. SPL is not relocate self to any other location. It just copies full u-boot to memory and jump to it and then full U-Boot relocate self to the end of memory. > >> This is definitely doable for REL/RELA case and it can also speedup boot >> process > > Not sure about the speed-up, but never mind. What I wanted to describe is that imagine case that SPL will does a little bit more steps when full u-boot should be loaded. It loads full u-boot to the end of memory and fix rel/rela section before passing control to it. IMHO (and not expert) removes one u-boot copy which current full u-boot does. (On the other hand if you want speedup boot you can boot OS directly). > >> (I don't think there is easy way how to solve this with just GOT relocation >> because >> of that MANUAL_RELOC code which is patching arrays with function pointers). > > Even without importing SPL in the equation, switching from GOT to > REL/RELA has enourmous advantages. I believe you - I haven't finish this on Microblaze as we talked on IRC some time ago. I have to do what arm64 is doing in tools/relocate-rela.c. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] sunxi: SPL size reduction patches
Hi All, Inspired by Simon's work to make the FEL SPL and regular SPL builds more similar I've been looking into reducing the size of the SPL, resulting in the following patch series. This all seems quite safe, but we are past rc1, so may be best to keep this on a branch for now, or not ... Simon, I think the malloc_simple changes should go through your tree, once those are merged I'll add the sunxi patch enabling malloc_simple usage in the SPL. With this series we're already quite close to getting a full-blown SPL to fit in 16K, I've looked at removing CONFIG_SPL_LIBCOMMON_SUPPORT but that won't fly well I think. We could however add a CONFIG_SPL_NO_PRINTF, which automatically gets set when CONFIG_SPL_LIBCOMMON_SUPPORT is not set, and use that on sunxi, assuming that you (Simon) are ok with not being able to use printf in the device-model code which gets used in the SPL. Things already almost built when not setting CONFIG_SPL_LIBCOMMON_SUPPORT since there are already a lot of places checking for that before calling printf. We could change all the CONFIG_SPL_LIBCOMMON_SUPPORT to CONFIG_SPL_NO_PRINTF checks and define CONFIG_SPL_NO_PRINTF on sunxi to win another "large" chunk of RAM. Something else to look at is at the memory map of the first 32k of SRAM when in FEL mode. The only documentation we've is: https://github.com/hno/Allwinner-Info/blob/master/FEL-usb/USB-protocol.txt Which is reverse engineered and not 100% clear on the memory map. We could add a memset to 0xaa for 0x6000 - 0x8000 to the fel spl as a test, as I've the feeling that what hno has found there are just scratch buffers and that using that in the SPL will be save, if that is the case we could use 0x2000 - 0x (growing downwards) as stack, and always use a text-base of 0x2000 for the SPL, with the SPL code / data segments living at 0x2000 - 0x8000 and then everything should fit as is, and we can have one unified SPL binary for both FEL and sdcard booting. I don't have the time to look into this further atm, so I hope that one of you (Simon or Siarhei) has time to look into this further. I see that we also never merged this related fix: http://lists.denx.de/pipermail/u-boot/2014-July/183986.html We should probably merge a version of that when Simon's patches for fixing FEL have landed. I think it may be best to just always set the L2EN bit on sun4i/sun5i, without detecting whether we're in fel mode or not, setting it when it is already said should be a nop, and thus harmless. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] malloc_simple: Return NULL on malloc failure rather then calling panic()
All callers of malloc should already do error checking, and may even be able
to continue without the alloc succeeding.
Moreover, common/malloc_simple.c is the only user of .rodata.str1.1 in
common/built-in.o when building the SPL, triggering this gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303
Causing .rodata to grow with e.g. 0xc21 bytes, nullifying all benefits of
using malloc_simple in the first place.
Signed-off-by: Hans de Goede
---
common/malloc_simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/malloc_simple.c b/common/malloc_simple.c
index afdacff..64ae036 100644
--- a/common/malloc_simple.c
+++ b/common/malloc_simple.c
@@ -19,7 +19,7 @@ void *malloc_simple(size_t bytes)
new_ptr = gd->malloc_ptr + bytes;
if (new_ptr > gd->malloc_limit)
- panic("Out of pre-reloc memory");
+ return NULL;
ptr = map_sysmem(gd->malloc_base + gd->malloc_ptr, bytes);
gd->malloc_ptr = ALIGN(new_ptr, sizeof(new_ptr));
return ptr;
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] malloc_simple: Allow malloc_simple to be used with non stack RAM
Before this patch malloc_simple would always allocate a chunk of RAM from
the stack. This commit adds a CONFIG_SYS_MALLOC_F_BASE define, which when
set directly specifies the memory address to use for the heap with
malloc_simple.
Signed-off-by: Hans de Goede
---
arch/arm/lib/crt0.S | 2 +-
common/board_f.c| 4
common/spl/spl.c| 3 +++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 22df3e5..a80dbf7 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -78,7 +78,7 @@ clr_gd:
strlo r0, [r1]/* clear 32-bit GD word */
addlo r1, r1, #4 /* move to next */
blo clr_gd
-#if defined(CONFIG_SYS_MALLOC_F_LEN)
+#if defined(CONFIG_SYS_MALLOC_F_LEN) && !defined(CONFIG_SYS_MALLOC_F_BASE)
sub sp, sp, #CONFIG_SYS_MALLOC_F_LEN
str sp, [r9, #GD_MALLOC_BASE]
#endif
diff --git a/common/board_f.c b/common/board_f.c
index 7953137..504dc1c 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -786,7 +786,11 @@ static int mark_bootstage(void)
static int initf_malloc(void)
{
#ifdef CONFIG_SYS_MALLOC_F_LEN
+#if defined(CONFIG_SYS_MALLOC_F_BASE)
+ gd->malloc_base = CONFIG_SYS_MALLOC_F_BASE;
+#else
assert(gd->malloc_base);/* Set up by crt0.S */
+#endif
gd->malloc_limit = gd->malloc_base + CONFIG_SYS_MALLOC_F_LEN;
gd->malloc_ptr = 0;
#endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index daaeb50..f751fcc 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -146,6 +146,9 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
CONFIG_SYS_SPL_MALLOC_SIZE);
gd->flags |= GD_FLG_FULL_MALLOC_INIT;
#elif defined(CONFIG_SYS_MALLOC_F_LEN)
+#if defined(CONFIG_SYS_MALLOC_F_BASE)
+ gd->malloc_base = CONFIG_SYS_MALLOC_F_BASE;
+#endif
gd->malloc_limit = gd->malloc_base + CONFIG_SYS_MALLOC_F_LEN;
gd->malloc_ptr = 0;
#endif
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] sunxi: Switch to using malloc_simple for the spl
common/dlmalloc.c is quite big, both in .text and .data usage. E.g. for a Mele_M9 sun6i board build this reduces .text from 0x4214 to 0x3b94 bytes, and .data from 0x54c to 0x144 bytes. Signed-off-by: Hans de Goede --- include/configs/sunxi-common.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 33c0614..b0a360e 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -18,6 +18,7 @@ */ #define CONFIG_SUNXI /* sunxi family */ #ifdef CONFIG_SPL_BUILD +#define CONFIG_SYS_MALLOC_SIMPLE #ifndef CONFIG_SPL_FEL #define CONFIG_SYS_THUMB_BUILD /* Thumbs mode to save space in SPL */ #endif @@ -180,8 +181,8 @@ /* end of 32 KiB in sram */ #define LOW_LEVEL_SRAM_STACK 0x8000 /* End of sram */ #define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK -#define CONFIG_SYS_SPL_MALLOC_START0x4ff0 -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0008 /* 512 KiB */ +#define CONFIG_SYS_MALLOC_F_BASE 0x4ff0 +#define CONFIG_SYS_MALLOC_F_LEN0x0008 /* 512 KiB */ /* I2C */ #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] sunxi: dram: Un-inline dram helper functions
Move the dram helper functions to a separate C file, rather then having them
as inline helpers in dram.h. This saves 144 bytes in the .text segment for
sun6i builds.
Signed-off-by: Hans de Goede
---
arch/arm/cpu/armv7/sunxi/Makefile | 1 +
arch/arm/cpu/armv7/sunxi/dram_helpers.c | 37 +
arch/arm/include/asm/arch-sunxi/dram.h | 28 ++---
3 files changed, 40 insertions(+), 26 deletions(-)
create mode 100644 arch/arm/cpu/armv7/sunxi/dram_helpers.c
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index f8a6bea..bf95928 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -12,6 +12,7 @@ obj-y += timer.o
obj-y += board.o
obj-y += clock.o
obj-y += cpu_info.o
+obj-y += dram_helpers.o
obj-y += pinmux.o
ifndef CONFIG_MACH_SUN9I
obj-y += usbc.o
diff --git a/arch/arm/cpu/armv7/sunxi/dram_helpers.c
b/arch/arm/cpu/armv7/sunxi/dram_helpers.c
new file mode 100644
index 000..9a94e1b
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/dram_helpers.c
@@ -0,0 +1,37 @@
+/*
+ * DRAM init helper functions
+ *
+ * (C) Copyright 2015 Hans de Goede
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+
+/*
+ * Wait up to 1s for value to be set in given part of reg.
+ */
+void mctl_await_completion(u32 *reg, u32 mask, u32 val)
+{
+ unsigned long tmo = timer_get_us() + 100;
+
+ while ((readl(reg) & mask) != val) {
+ if (timer_get_us() > tmo)
+ panic("Timeout initialising DRAM\n");
+ }
+}
+
+/*
+ * Test if memory at offset offset matches memory at begin of DRAM
+ */
+bool mctl_mem_matches(u32 offset)
+{
+ /* Try to write different values to RAM at two addresses */
+ writel(0, CONFIG_SYS_SDRAM_BASE);
+ writel(0xaa55aa55, CONFIG_SYS_SDRAM_BASE + offset);
+ /* Check if the same value is actually observed when reading back */
+ return readl(CONFIG_SYS_SDRAM_BASE) ==
+ readl(CONFIG_SYS_SDRAM_BASE + offset);
+}
diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
b/arch/arm/include/asm/arch-sunxi/dram.h
index 7ff43e6..aedd194 100644
--- a/arch/arm/include/asm/arch-sunxi/dram.h
+++ b/arch/arm/include/asm/arch-sunxi/dram.h
@@ -25,31 +25,7 @@
#endif
unsigned long sunxi_dram_init(void);
-
-/*
- * Wait up to 1s for value to be set in given part of reg.
- */
-static inline void mctl_await_completion(u32 *reg, u32 mask, u32 val)
-{
- unsigned long tmo = timer_get_us() + 100;
-
- while ((readl(reg) & mask) != val) {
- if (timer_get_us() > tmo)
- panic("Timeout initialising DRAM\n");
- }
-}
-
-/*
- * Test if memory at offset offset matches memory at begin of DRAM
- */
-static inline bool mctl_mem_matches(u32 offset)
-{
- /* Try to write different values to RAM at two addresses */
- writel(0, CONFIG_SYS_SDRAM_BASE);
- writel(0xaa55aa55, CONFIG_SYS_SDRAM_BASE + offset);
- /* Check if the same value is actually observed when reading back */
- return readl(CONFIG_SYS_SDRAM_BASE) ==
- readl(CONFIG_SYS_SDRAM_BASE + offset);
-}
+void mctl_await_completion(u32 *reg, u32 mask, u32 val);
+bool mctl_mem_matches(u32 offset);
#endif /* _SUNXI_DRAM_H */
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Hi Albert, If we use SPL, we do not have to relocate code, I think. SPL doesn't have relocation that's why this code is not used there. It is not what I meant. If SPL can directly load the main u-boot image to the DRAM address where it is linked, we do not relocate the code in the main image. Current behavior is that SPL is reading u-boot.img entry point which can be in any location and jump to it and u-boot self relocate to the end of memory. If SPL adds u-boot directly to the location where it should run after relocation then relocation is not needed. To ensure this capability (based on my poor GOT/REL/RELA) experience it means that SPL loads u-boot to that location and patch REL/RELA section based on this location and internal relocation should be skipped. I've always thought the logical approach would be for SPL to calculate where U-Boot would end up in RAM, copy it from wherever (NAND, NOR, MMC, whatever) to the final location, perform the relocation fixups, then jump straight into U-Boot. It's pretty much what the Dynamic Loader does (particularly with address space layout randomization) IOW, that SPL perform the work of relocate_code() in U-Boot -- at least, on ARM, where REL/RELA is used. This is definitely doable for REL/RELA case and it can also speedup boot process Not sure about the speed-up, but never mind. It will save a RAM to RAM copy of u-boot's text and data sections. However, running the relocation code in SPL may be even slower (depending on configuration of caches). (I don't think there is easy way how to solve this with just GOT relocation because of that MANUAL_RELOC code which is patching arrays with function pointers). Even without importing SPL in the equation, switching from GOT to REL/RELA has enourmous advantages. I must admit, I'm really rusty with GOT vs REL/RELA - anyone care to give me a refresher? But yes, only having to deal with REL/RELA sections will make the relocation procedures much simpler Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Let's bury CONFIG_NEEDS_MANUAL_RELOC
Hi Albert, On 04/02/15 21:29, Albert ARIBAUD wrote: Hello Graeme, On Wed, 04 Feb 2015 18:14:22 +1100, Graeme Russ wrote: So the first question that we need to answer is: Do the avr32, m68k, nds32, and sparc toolchains support the generation of the relevant sections needed to perform relocation in a manner similar to x86 (i.e generation of relocation references into sections of the final U-Boot binary)? Those arches which use GCC should be able to use -pie / -pic-executable and possibly --emit-relocs, as none of these is arch-specific. That was my understanding too - it's a function of ELF, not the architecture. Then, each arch might have to look into what GCC options are needed. For the record, on ARM, I did not need any gcc option, but actually had one -fPIC option /removed/. Yes, I vaguely remember this. The difference is that -fPIC is used for relocatable LIBRARIES whereas -fPIE is used for relocatable EXECUTABLES. Since U-Boot is a monolithic executable, -fPIC makes no sense Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv1 01/22] arm: socfpga: spl: Add main sdram code
On Sat 2015-01-17 03:39:46, Marek Vasut wrote:
> On Friday, January 16, 2015 at 08:04:20 PM, Pavel Machek wrote:
> > Hi!
>
> Hi!
>
> > > > +void wait_di_buffer(void)
> > > > +{
> > > > + if (debug_data->di_report.cur_samples == NUM_DI_SAMPLE) {
> > > > + debug_data->di_report.flags |= DI_REPORT_FLAGS_READY;
> > > > + while (debug_data->di_report.cur_samples != 0)
> > > > + ;
> > >
> > > Please get rid of such endless loops, since the platform might get stuck
> > > forever in them.
> >
> > What would you propose in case of timeout? Message on serial console
> > and reboot?
>
> Yes, reboot and try again would work I suspect.
>
> > Endless loop should trigger watchdog, anyway, no?
>
> If and only if the WDT is enabled, which is not necessarily the case.
Reasonable solution for SPL woul be "always enable the wdt",
then. Probably less overhead than adding timeouts to all the loops...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 06/10] arm: socfpga: Zap checkboard()
On Fri 2015-01-30 23:08:46, Marek Vasut wrote: > Since all boards now have a DT, instead of hard-coding the board > name into the U-Boot binary, read the board name from DT "model" > property. > > Signed-off-by: Marek Vasut > Cc: Chin Liang See > Cc: Dinh Nguyen Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] falcon mode for signed FIT images
Hi all, is it possible to start FIT signed kernel from SPL (falcon mode)? Thanks, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] odroid: update link to X2/U3 proprietary binaries
Hello! On 2015-02-04 11:42, Albert ARIBAUD wrote: Hello Tobias, You should use git send-email (or better yet, patman) for sending patches; this one was attached instead of inline. Sorry, I normally do that, but I didn't have access to my Odroid system when I sent the patch. That being said, it did not seem to worry patchwork, so you don't need to repost this one. OK! With best wishes, Tobias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/21] ARM: start to move SoC code into arch/arm/mach-*
On Mon 2015-02-02 10:18:23, Stephen Warren wrote: > On 01/31/2015 08:20 PM, Simon Glass wrote: > >Hi Albert, > > > >On 31 January 2015 at 20:02, Albert ARIBAUD > >wrote: > >>Hello Masahiro, > >> > >>On Sun, 25 Jan 2015 15:11:02 +0900, Masahiro Yamada > >> wrote: > >>> > >>>This series can be applied on the current u-boot/master > >>>(commit 37b608a52dcb133) > >> > >>I'd rather not have all mach-* directories just below arch/arm/. Can't > >>they be created under arch/arm/soc/ instead? That would give a cleaner > >>structure IMO. > > > >It does save a level and I am forever typing cpu/armv7 to get what > >feels like nowhere...this is what the kernel does and it does seem > >convenient. > > Do note that arch/arm/mach* doesn't/won't entirely match what the Linux > kernel does. > > In Linux, arch/arm64 doesn't have mach-* sub-directories, and the arm/arm64 > architectures are different so don't share the code in arch/arm/mach-tegra, > so there's work underway to move stuff out of arch/arm/mach-tegra and into > either appropriate subsystem directories or drivers/soc/tegra. > > Given all that, I suspect we should decide the directory layout of U-Boot > based on what's best for U-Boot, not by trying to chase the changing target > of the Linux kernel. Well, I'd say that best directory layout is the one we are familiar with ... from Linux. And we don't need to chase that target. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] armv8/vexpress64: make multientry conditional
hi Linus, The following is some advice about the multi entry patch. > While the Freescale ARMv8 board LS2085A will enter U-Boot both > on a master and a secondary (slave) CPU, this is not the common > behaviour on ARMv8 platforms. The norm is that U-Boot is entered > from the master CPU only, while the other CPUs are kept in > WFI (wait for interrupt) state. > > The code determining which CPU we are running on is using the > MPIDR register, but the definition of that register varies with > platform to some extent, and handling multi-cluster platforms > (such as the Juno) will become cumbersome. It is better to only > enable the multiple entry code on machines that actually need > it and disable it by default. > > Make the single entry default and add a special > ARMV8_MULTIENTRY KConfig option to be used by the > platforms that need multientry and set it for the LS2085A. > Delete all use of the CPU_RELEASE_ADDR from the Vexpress64 > boards as it is just totally unused and misleading, and > make it conditional in the generic start.S code. > > This makes the Juno platform start U-Boot properly. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Move configuration of ARMV8_MULTIENTRY over to Kconfig > as requested by Tom Rini. > > This patch applied on top of the other patch series send, > ending with > [PATCH 4/4] vexpress64: support the Juno Development Platform > Please apply it on top of these if the patch seems OK. > --- > arch/arm/Kconfig | 4 > arch/arm/cpu/armv8/Kconfig | 6 ++ > arch/arm/cpu/armv8/start.S | 8 > arch/arm/include/asm/macro.h | 8 > board/armltd/vexpress64/vexpress64.c | 6 -- > include/configs/vexpress_aemv8a.h| 8 > 6 files changed, 22 insertions(+), 18 deletions(-) > create mode 100644 arch/arm/cpu/armv8/Kconfig > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 986b4c5d81db..75dd9bb60d6b 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -743,10 +743,12 @@ config TARGET_VEXPRESS64_JUNO > config TARGET_LS2085A_EMU > bool "Support ls2085a_emu" > select ARM64 > + select ARMV8_MULTIENTRY > > config TARGET_LS2085A_SIMU > bool "Support ls2085a_simu" > select ARM64 > + select ARMV8_MULTIENTRY > VEXPRESS_AEMV8A and VEXPRESS_AEMV8A_SEMI are defaultly single entry? That means we always has ATF exist. > config TARGET_LS1021AQDS > bool "Support ls1021aqds" > @@ -855,6 +857,8 @@ source "arch/arm/cpu/armv7/zynq/Kconfig" > > source "arch/arm/cpu/armv7/Kconfig" > > +source "arch/arm/cpu/armv8/Kconfig" > + > source "board/aristainetos/Kconfig" > source "board/BuR/kwb/Kconfig" > source "board/BuR/tseries/Kconfig" > diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig > new file mode 100644 > index ..4cd84b031114 > --- /dev/null > +++ b/arch/arm/cpu/armv8/Kconfig > @@ -0,0 +1,6 @@ > +if ARM64 > + > +config ARMV8_MULTIENTRY > +boolean "Enable multiple CPUs to enter into U-boot" > + > +endif > diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S > index 4b11aa4f2227..9b439f30b779 100644 > --- a/arch/arm/cpu/armv8/start.S > +++ b/arch/arm/cpu/armv8/start.S > @@ -77,6 +77,7 @@ reset: > /* Processor specific initialization */ > bl lowlevel_init > > +#ifdef CONFIG_ARMV8_MULTIENTRY > branch_if_master x0, x1, master_cpu > > /* > @@ -88,11 +89,10 @@ slave_cpu: > ldr x0, [x1] > cbz x0, slave_cpu > br x0 /* branch to the given address */ > - > - /* > - * Master CPU > - */ > master_cpu: > + /* On the master CPU */ > +#endif /* CONFIG_ARMV8_MULTIENTRY */ > + > bl _main > How about put the slave part of lowlevel_init in CONFIG_ARMV8_MULTIENTRY? although it still works with modified branch_if_master macro. > /*---*/ > diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h > index 1c8c4251ee0c..3b3146ab2239 100644 > --- a/arch/arm/include/asm/macro.h > +++ b/arch/arm/include/asm/macro.h > @@ -78,6 +78,8 @@ lr .reqx30 > * choose processor with all zero affinity value as the master. > */ > .macro branch_if_slave, xreg, slave_label > +#ifdef CONFIG_ARMV8_MULTIENTRY > + /* NOTE: MPIDR handling will be erroneous on multi-cluster machines */ > mrs \xreg, mpidr_el1 > tst \xreg, #0xff/* Test Affinity 0 */ > b.ne\slave_label > @@ -90,6 +92,7 @@ lr .reqx30 > lsr \xreg, \xreg, #16 > tst \xreg, #0xff/* Test Affinity 3 */ > b.ne\slave_label > +#endif > .endm > > /* > @@ -97,12 +100,17 @@ lr .reqx30 > * choose processor with all zero affinity value as the master. > */ > .macro branch_if_master, xreg1, xreg2, master_label > +#ifdef CONFIG_ARMV8_
Re: [U-Boot] [PATCH v2 02/11] Exynos542x: CPU: Power down all secondary cores
On 3 February 2015 at 01:18, Akshay Saraswat wrote: > This patch adds code to shutdown secondary cores. > When U-boot comes up, all secondary cores appear powered on, > which is undesirable and causes side effects while > initializing these cores in kernel. > > Secondary core power down happens in following steps: > > Step-1: After Exynos power-on, primary core starts executing first. > Step-2: In iROM code every core has to check 2 flags i.e. > addresses 0x02020028 & 0x02020004. > Step-3: Initially 0x02020028 is 0 for all cores and 0x02020004 has a > jump address for primary core and 0 for all secondary cores. > Step-4: Therefore, primary core follows normal iROM execution and jumps > to BL1 eventually, whereas all secondary cores enter WFE. > Step-5: When primary core comes into function secondary_cores_configure, > it puts pointer to function power_down_core into 0x02020004 > and provides DSB and SEV for all cores so that they may come out > of WFE and jump to power_down_core function. > Step-6: And ultimately because of power_down_core all > secondary cores shut-down. > > Signed-off-by: Kimoon Kim > Signed-off-by: Akshay Saraswat > --- > Changes since v1: > - Removed unnecessary macros. > - Changed names of few macros for better understanding. > - Added MPIDR bit assignment info comment in power_down_core. > > arch/arm/cpu/armv7/exynos/exynos5_setup.h | 3 ++ > arch/arm/cpu/armv7/exynos/lowlevel_init.c | 69 > arch/arm/include/asm/arch-exynos/cpu.h| 5 ++ > arch/arm/include/asm/arch-exynos/system.h | 87 > +++ > 4 files changed, 164 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] Exynos: Fix L2 cache timings on Exynos5420 and Exynos5800
On 3 February 2015 at 01:19, Akshay Saraswat wrote: > From: Doug Anderson > > It was found that the L2 cache timings that we had before could cause > freezes and hangs. We should make things more robust with better > timings. Currently the production ChromeOS kernel applies these > timings, but it's nice to fixup firmware too (and upstream probably > won't take our kernel hacks). > > This also provides a big cleanup of the L2 cache init code avoiding > some duplication. The way things used to work: > * low_power_start() was installed by the SPL (both at boot and resume > time) and left resident in iRAM for the kernel to use when bringing > up additional CPUs. It used configure_l2_ctlr() and > configure_l2_actlr() when it detected it was on an A15. This was > needed (despite the L2 cache registers being shared among all A15s) > because we might have been the first man in after the whole A15 > cluster was shutdown. > * secondary_cores_configure() was called on at boot time and at resume > time. Strangely this called configure_l2_ctlr() but not > configure_l2_actlr() which was almost certainly wrong. Given that > we'll call both (see next bullet) later in the boot process it > didn't matter for normal boot, but I guess this is how L2 cache > settings got set on 5420/5800 (but not 5250?) at resume time. > * exynos5_set_l2cache_params() was called as part of cache enablement. > This should happen at boot time (normally in the SPL except for USB > boot where it happens in main U-Boot). > > Note that the old code wasn't setting ECC/parity in the cache > enablement code but we happened to get it anyway because we'd call > secondary_cores_configure() at boot time. For resume time we'd get it > anyway when the 2nd A15 core came up. > > Let's make this a whole lot simpler. Now we always set these > parameters in the same place for all boots and use the same code for > setting up secondary CPUs. > > Intended net effects of this change (other than cleanup): > * Timings go from before: > data: 0 cycle setup, 3 cycles (0x2) latency > tag: 0 cycle setup, 3 cycles (0x2) latency > after: > data: 1 cycle setup, 4 cycles (0x3) latency > tag: 1 cycle setup, 4 cycles (0x3) latency > * L2ACTLR is properly initted on 5420/5800 in all cases. > > One note is that we're still relying on luck to keep low_power_start() > working. The compiler is being nice and not storing anything on the > stack. > > Another note is that on its own this patch won't help to fix cache > settings in an RW U-Boot update where we still have the RO SPL. The > plan for that is: > * Have RW U-Boot re-init the cache right before calling the kernel > (after it has turned the L2 cache off). This is why the functions > are in a header file instead of lowlevel_init.c. > > * Have the kernel save the L2 cache settings of the boot CPU and apply > them to all other CPUs. We get a little lucky here because the old > code was using "|=" to modify the registers and all of the bits that > it's setting are also present in the new settings (!). That means > that when the 2nd CPU in the A15 cluster comes up it doesn't > actually mess up the settings of the 1st CPU in the A15 cluster. An > alternative option is to have the kernel write its own > low_power_start() code. > > Signed-off-by: Doug Anderson > Signed-off-by: Akshay Saraswat > --- > Changes since v1: > - Fixed compilation error for snow build. > > arch/arm/cpu/armv7/exynos/common_setup.h | 55 > +++ > arch/arm/cpu/armv7/exynos/lowlevel_init.c | 55 > +-- > arch/arm/cpu/armv7/exynos/soc.c | 51 > arch/arm/include/asm/arch-exynos/system.h | 2 -- > 4 files changed, 70 insertions(+), 93 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 6/7] Exynos: clock: change mask bits as per peripheral
On 3 February 2015 at 01:27, Akshay Saraswat wrote: > We have assumed and kept mask bits for divider and pre-divider > as 0xf and 0xff, respectively. But these mask bits change from > one peripheral to another, and hence, need to be specified in > accordance with the peripherals. > > Signed-off-by: Akshay Saraswat > --- > Changes since v4: > - Isolated maskbit changes. > > Changes since v3: > - New patch. > > arch/arm/cpu/armv7/exynos/clock.c | 151 > -- > 1 file changed, 78 insertions(+), 73 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 1/7] x86: Add header files for Intel Quark SoC defines
On 2 February 2015 at 07:35, Bin Meng wrote: > device.h for integrated pci devices' bdf on Quark SoC and quark.h for > various memory-mapped and i/o-mapped base addresses within SoC. > > Signed-off-by: Bin Meng > > --- > > Changes in v3: > - Add several macros for message bus port and registers > > Changes in v2: > - Move vairous components' base addresses within Quark SoC to Kconfig > > arch/x86/include/asm/arch-quark/device.h | 28 ++ > arch/x86/include/asm/arch-quark/quark.h | 40 > > 2 files changed, 68 insertions(+) > create mode 100644 arch/x86/include/asm/arch-quark/device.h > create mode 100644 arch/x86/include/asm/arch-quark/quark.h Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 3/7] x86: Define macros for pci configuration space access
On 2 February 2015 at 07:35, Bin Meng wrote: > Move PCI_REG_ADDR and PCI_REG_DATA from arch/x86/lib/pci_type1.c to > arch/x86/include/asm/pci.h, also define PCI_CFG_EN so that these > macros can be used for pci configuration space access. > > Signed-off-by: Bin Meng > > --- > > Changes in v3: > - New patch to define macros for pci configuration space access > > Changes in v2: None > > arch/x86/include/asm/pci.h | 13 +++-- > arch/x86/lib/pci_type1.c | 7 ++- > 2 files changed, 13 insertions(+), 7 deletions(-) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 4/7] x86: quark: Add Cache-As-RAM initialization
On 2 February 2015 at 07:35, Bin Meng wrote: > Quark SoC contains an embedded 512KiB SRAM (eSRAM) that is > initialized by hardware. eSRAM is the ideal place to be used > for Cache-As-RAM (CAR) before system memory is available. > > Signed-off-by: Bin Meng > > --- > > Changes in v3: > - Use macros from and > > Changes in v2: > - Replace upper case register names (EAX etc.) with lower case > - Use some macros from and > > arch/x86/cpu/quark/car.S | 105 > +++ > 1 file changed, 105 insertions(+) > create mode 100644 arch/x86/cpu/quark/car.S Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 5/7] x86: Add basic Intel Quark processor support
On 2 February 2015 at 07:35, Bin Meng wrote: > Add minimum codes to support Intel Quark SoC. DRAM initialization > is not ready yet so a hardcoded gd->ram_size is assigned. > > Signed-off-by: Bin Meng > > --- > > Changes in v3: > - Add simple help for ACPI PM1, PBLK and GEP0 > > Changes in v2: > - Use machine-specific > - Move vairous components' base addresses within Quark SoC to Kconfig > - Rebase to u-boot-86/master > > arch/x86/cpu/quark/Kconfig | 121 > + > arch/x86/cpu/quark/Makefile| 8 +++ > arch/x86/cpu/quark/dram.c | 39 +++ > arch/x86/cpu/quark/pci.c | 70 +++ > arch/x86/cpu/quark/quark.c | 44 > arch/x86/include/asm/arch-quark/gpio.h | 13 > 6 files changed, 295 insertions(+) > create mode 100644 arch/x86/cpu/quark/Kconfig > create mode 100644 arch/x86/cpu/quark/Makefile > create mode 100644 arch/x86/cpu/quark/dram.c > create mode 100644 arch/x86/cpu/quark/pci.c > create mode 100644 arch/x86/cpu/quark/quark.c > create mode 100644 arch/x86/include/asm/arch-quark/gpio.h Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to have U-boot loading U-boot
Dear all, I have already used u-boot several times on various ARM-based platforms but I need to go to unknown territories this time. On an ARM-based platform again, we have a u-boot port (v2010.09) available loaded by a ROM bootloader into the internal RAM. For some reasons, the ROM bootloader limits the size of the loaded code to 128kB which is a bit short for the functionality needed. What I'd like to do is have the already available u-boot (say Level-1) to load a second u-boot (say Level-2) into DDR where size is not an issue which will then load Linux. For the Level-1, I haven't changed anything for now. I'm still using the Linux kernel load address. For the Level-2, I have found the following interesting configuration flags: CONFIG_SKIP_LOWLEVEL_INIT -> to suppress the CPU & external RAM initialization that is already done by Level-1 CONFIG_SKIP_RELOCATE_UBOOT -> to avoid the relocation that was not looking interesting in the scope of a Level-2 but is that correct? TEXT_BASE -> modified to match the kernel load address used in Level-1 I have constructed my Level-2 U-boot image using the same kind of commands as for my kernel but specifying Firmware type ./u-boot/tools/mkimage -A arm -O U-boot -T Firmware -C none -a 70008000 -e 70008000 -n 'u-boot L2' -d ./u-boot/u-boot.bin ./u-boot/u-boot.uImage When I try to run the loaded Level-2, my board freezes. I've also tried to hack the bootm command so that my Firmware image is seen as a stand-alone application so that it runs it directly without the cleanup stuff but that does not work either. Before I go on debug this intensively, I just want to make sure I've not missed something very obvious in the process? Thanks in advance, JC ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AM335x ChiliSOM support
Hello; I just started working with the ChiliSOM module [1] -- in my particular case it is part of the Chiliboard [2]. The ChiliSOM is a nice little module based on the TI AM335x ARM SoC. I already started porting the mainline U-boot for it. The DRAM and serial console seem to work so far. I hope the rest (Ethernet, USB) won't be that painful. When implementing the support for this SOM I copy-pasted a lot of code (almost all of it) from the ti/am335x/board.c. I had to copy the linker script and include/configs/am335x_evm.h (which has reference to the particular linkerscript) as well. Not only I know this is very wrong, I do not like it. One possibility would be to modify the ti/am335x/board.c to be able to work with this SOM, although the code reading the board identification (from serial EEPROM) at the beginning of many functions seem to be an issue. Not very elegant solution would be to #ifndef them for all the other boards with the exception of the ChiliSOM. Another possibility would be to have an extra board.c, however the include/configs/am335x_evm.h will be used as a configuration file with the CONFIG_SYS_LDSCRIPT somehow (how?) pointing to some generic am335x linker script. Is there an interest in ChiliSOM U-boot support? What is the most elegant way resulting in the least code duplication? I will appreciate your help. Best regards; Rostislav Lisovy [1] http://www.grinn.pl/en/som [2] http://test.chiliboard.org/ http://chiliboard.org/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 7/9] fdtdec: Add compatible id and string for Intel Quark MRC
On 3 February 2015 at 04:45, Bin Meng wrote: > Add COMPAT_INTEL_QRK_MRC and "intel,quark-mrc" so that fdtdec can > decode Intel Quark MRC node. > > Signed-off-by: Bin Meng > --- > > include/fdtdec.h | 1 + > lib/fdtdec.c | 1 + > 2 files changed, 2 insertions(+) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 6/9] x86: quark: Enable the Memory Reference Code build
Hi Bin, On 3 February 2015 at 04:45, Bin Meng wrote: > Turn on the Memory Reference code build in the quark Makefile. > > Signed-off-by: Bin Meng > --- > > arch/x86/cpu/quark/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/cpu/quark/Makefile b/arch/x86/cpu/quark/Makefile > index 168c1e6..e87b424 100644 > --- a/arch/x86/cpu/quark/Makefile > +++ b/arch/x86/cpu/quark/Makefile > @@ -5,4 +5,5 @@ > # > > obj-y += car.o dram.o msg_port.o quark.o > +obj-y += mrc.o mrc_util.o hte.o smc.o > obj-$(CONFIG_PCI) += pci.o Would prefer that you do this as you add each file (i.e. in the patch that adds the file). Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
