Re: [U-Boot] [PATCH v3 22/30] ARM: cache_v7: Various minor cleanups
Hello Simon,
I've actually applied v2 of this patch and PRed it to u-boot/master)
and accidentally not acked it.
Apologies.
On Wed, 12 Nov 2014 18:27:08 -0700, Simon Glass s...@chromium.org
wrote:
From: Thierry Reding tred...@nvidia.com
Remove two gratuituous blank lines, uses u32 (instead of int) as the
type for values that will be written to a register, moves the beginning
of the variable declaration section to a separate line (rather than the
one with the opening brace) and keeps the function signature on a single
line where possible.
Signed-off-by: Thierry Reding tred...@nvidia.com
Acked-by: Simon Glass s...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
arch/arm/cpu/armv7/cache_v7.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index a2c4032..0f9d837 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -21,7 +21,8 @@
* to get size details from Current Cache Size ID Register(CCSIDR)
*/
static void set_csselr(u32 level, u32 type)
-{u32 csselr = level 1 | type;
+{
+ u32 csselr = level 1 | type;
/* Write to Cache Size Selection Register(CSSELR) */
asm volatile (mcr p15, 2, %0, c0, c0, 0 : : r (csselr));
@@ -49,7 +50,8 @@ static void v7_inval_dcache_level_setway(u32 level, u32
num_sets,
u32 num_ways, u32 way_shift,
u32 log2_line_len)
{
- int way, set, setway;
+ int way, set;
+ u32 setway;
/*
* For optimal assembly code:
@@ -73,7 +75,8 @@ static void v7_clean_inval_dcache_level_setway(u32 level,
u32 num_sets,
u32 num_ways, u32 way_shift,
u32 log2_line_len)
{
- int way, set, setway;
+ int way, set;
+ u32 setway;
/*
* For optimal assembly code:
@@ -134,7 +137,6 @@ static void v7_maint_dcache_level_setway(u32 level, u32
operation)
static void v7_maint_dcache_all(u32 operation)
{
u32 level, cache_type, level_start_bit = 0;
-
u32 clidr = get_clidr();
for (level = 0; level 7; level++) {
@@ -147,8 +149,7 @@ static void v7_maint_dcache_all(u32 operation)
}
}
-static void v7_dcache_clean_inval_range(u32 start,
- u32 stop, u32 line_len)
+static void v7_dcache_clean_inval_range(u32 start, u32 stop, u32 line_len)
{
u32 mva;
@@ -256,7 +257,6 @@ void flush_dcache_all(void)
*/
void invalidate_dcache_range(unsigned long start, unsigned long stop)
{
-
v7_dcache_maint_range(start, stop, ARMV7_DCACHE_INVAL_RANGE);
v7_outer_cache_inval_range(start, stop);
--
2.1.0.rc2.206.gedb03e5
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 23/30] ARM: cache-cp15: Use more accurate types
Hello Simon,
I've actually applied v2 of this patch and PRed it to u-boot/master)
and accidentally not acked it.
Apologies.
On Wed, 12 Nov 2014 18:27:09 -0700, Simon Glass s...@chromium.org
wrote:
From: Thierry Reding tred...@nvidia.com
size_t is the canonical type to represent variables that contain a size.
Use it instead of signed integer. Physical addresses can be larger than
32-bit, so use a more appropriate type for them as well. phys_addr_t is
a type that is 32-bit on systems that use 32-bit addresses and 64-bit if
the system is 64-bit or uses a form of physical address extension to use
a larger address space on 32-bit systems. Using these types the same API
can be implemented on a wider range of systems.
Signed-off-by: Thierry Reding tred...@nvidia.com
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
arch/arm/include/asm/system.h | 2 +-
arch/arm/lib/cache-cp15.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index ca2d44f..61e2914 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -201,7 +201,7 @@ enum {
* \param size size of memory region to change
* \param option dcache option to select
*/
-void mmu_set_region_dcache_behaviour(u32 start, int size,
+void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
enum dcache_option option);
/**
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index 2155fe8..0291afa 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -47,15 +47,15 @@ __weak void mmu_page_table_flush(unsigned long start,
unsigned long stop)
debug(%s: Warning: not implemented\n, __func__);
}
-void mmu_set_region_dcache_behaviour(u32 start, int size,
+void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
enum dcache_option option)
{
u32 *page_table = (u32 *)gd-arch.tlb_addr;
- u32 upto, end;
+ unsigned long upto, end;
end = ALIGN(start + size, MMU_SECTION_SIZE) MMU_SECTION_SHIFT;
start = start MMU_SECTION_SHIFT;
- debug(%s: start=%x, size=%x, option=%d\n, __func__, start, size,
+ debug(%s: start=%pa, size=%zu, option=%d\n, __func__, start, size,
option);
for (upto = start; upto end; upto++)
set_section_dcache(upto, option);
--
2.1.0.rc2.206.gedb03e5
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6sabresd: Move the DCD settings to spl code
Hi Fabio, On 14/11/2014 00:24, Fabio Estevam wrote: On Thu, Nov 13, 2014 at 9:16 PM, Stefano Babic sba...@denx.de wrote: mkimage is called with the .cfg file, and if it is removed, no imx image file is generated. I think that then the i.MX cannot boot, because the resulting image will miss the magic number in the headers as described in manuals. So I think that a minimal .cfg is required (without DCD and register setting) to let U-Boot build system to generate an imx image file. Got it, so we can keep this minimal .cfg then. After this patch the spl .cfg it will only contain IMAGE_VERSION 2 BOOT_FROM sd Perfect ! I think that other boards can use this minimal setup as well. What do you think to move it into imx-common ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] ARM: bootm: Allow booting in secure mode on hyp capable systems
Hi,
On 11/14/2014 08:33 AM, Albert ARIBAUD wrote:
Hello Hans,
On Thu, 13 Nov 2014 20:37:42 +0100, Hans de Goede hdego...@redhat.com
wrote:
Older Linux kernels will not properly boot in hyp mode, add support for a
bootm_boot_mode environment variable, which can be set to sec or nonsec
to force booting in secure or non-secure mode when build with non-sec
support.
The default behavior can be selected through CONFIG_ARMV7_BOOT_SEC_DEFAULT,
when this is set booting in secure mode is the default. The default setting
for this Kconfig option is N, preserving the current behavior of booting in
non-secure mode by default when non-secure mode is supported.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Marc Zyngier marc.zyng...@arm.com
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Changes in v2:
-Allow changing the default boot mode to secure through defining
CONFIG_ARMV7_BOOT_SEC_DEFAULT, this is useful for archs which have a Kconfig
option for compatibility with older kernels
Changes in v3:
-Add an else at the end of the #ifdef NONSEC block so that if do_nonsec_entry
fails we do not end up re-trying in secure mode
Changes in v4:
-Add a Kconfig option to select to boot in secure or non-secure mode by
default
---
arch/arm/cpu/armv7/Kconfig | 11 +++
arch/arm/lib/bootm.c | 31 ++-
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index 15c5155..6ee5ff8 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -13,6 +13,17 @@ config ARMV7_NONSEC
---help---
Say Y here to enable support for booting in non-secure / SVC mode.
+config ARMV7_BOOT_SEC_DEFAULT
+boolean Boot in secure mode by default if EXPERT
+depends on ARMV7_NONSEC
+default n
+---help---
+Say Y here to boot in secure mode by default even if non-secure mode
+is supported. This option is useful to boot kernels which do not
+suppport booting in secure mode. Only set this if you need it.
+This can be overriden at run-time by setting the bootm_boot_mode env.
+variable to sec or nonsec.
Not sure I'm getting this right, but it seems to me that forcing secure
boot mode for kernels that don't support secure boot mode is kind of
contradictory. Did you mean ... for kernels which do not suport
booting in *non*-secure mode... ?
Yes, my bad will fix in v5.
config ARMV7_VIRT
boolean Enable support for hardware virtualization if EXPERT
depends on CPU_V7_HAS_VIRT ARMV7_NONSEC
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 4949d57..a7f7c67 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -237,6 +237,26 @@ static void boot_prep_linux(bootm_headers_t *images)
}
}
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+static bool boot_nonsec(void)
+{
+char *s = getenv(bootm_boot_mode);
+#ifdef CONFIG_ARMV7_BOOT_SEC_DEFAULT
+bool nonsec = false;
+#else
+bool nonsec = true;
+#endif
+
+if (s !strcmp(s, sec))
+nonsec = false;
+
+if (s !strcmp(s, nonsec))
+nonsec = true;
+
+return nonsec;
+}
+#endif
+
/* Subcommand: GO */
static void boot_jump_linux(bootm_headers_t *images, int flag)
{
@@ -285,12 +305,13 @@ static void boot_jump_linux(bootm_headers_t *images,
int flag)
if (!fake) {
#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
-armv7_init_nonsec();
-secure_ram_addr(_do_nonsec_entry)(kernel_entry,
- 0, machid, r2);
-#else
-kernel_entry(0, machid, r2);
+if (boot_nonsec()) {
+armv7_init_nonsec();
+secure_ram_addr(_do_nonsec_entry)(kernel_entry,
+ 0, machid, r2);
+} else
#endif
+kernel_entry(0, machid, r2);
}
#endif
}
--
2.1.0
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Hello Dave, On Thu, 13 Nov 2014 15:19:20 -0700 (MST), DaveKucharczyk david.kucharc...@gmail.com wrote: We have 2GB’s of RAM starting at 0x7000 on our Freescale MX53 based board. With old U-Boot we defined TEXT_BASE at the bottom of RAM at 0x7060 and CONFIG_SKIP_RELOCATE_UBOOT, presumably so that we can run memory tests all the way to the top of RAM (this was brought over from the mx53loco board and precedes me). Why else would CONFIG_SKIP_RELOCATE_UBOOT be set? CONFIG_SKIP_RELOCATE_UBOOT is not used in U-Boot nowadays [but is still defined by target snapper9260, which means either that target is utterly broken, or it does not actually need the option]. In new U-Boot we are not skipping relocation. I define CONFIG_SYS_TEXT_BASE = 0xeff89000 so that relocation offset is 0x. Baaad, bad. The first time you change something in your code, your relocation offset might change and this will make U-Boot crash and burn in interesting ways. Just define CONFIG_SYS_TEXT_BASE to some low address and let relocation happen. You can find your actual relocation address in the global data structure. I run with DEBUG on to doublecheck where things get setup… (typically, builds with and without DEBUG will have differing relocation addresses) I run a memory test from 0x7000 to 0xefe88cb0, but I get a mismatch fail at 0xefe88aa4. Shouldn’t I be able to run mem test all the way to the stack? I don’t see anything else being setup under the stack. How do you know the lowest address used by your stack during your memory test? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] Kconfig: Add EXPERT option
Hello Masahiro, On Fri, 14 Nov 2014 16:15:01 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Albert, On Fri, 14 Nov 2014 08:08:05 +0100 Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Masahiro, I prefer describing the patch dependency in the cover letter to resending the same patch. Ditto -- but since patch numbers won't matter once applied and since Tom is properly attributed, it won't matter much whether Tom applies his own patch or I apply it as part of this series. I'll apply the series. Yup, it won't make much of difference, although I issued my Acked-by to Tom's one and it is missing from Hans's. Fair point. I'll make sure I add your Acked-by if I'm the one applying this patch. Best Regards Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/3] ARM: Add armv7/Kconfig and allow booting in secure mode on non-secure boot capable systems
Hi Albert, Here is v5 of my patchset to allow booting in secure mode on non-secure boot capable systems. Changes in v2: -ARM: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options: -Drop all the FIXME-s, use proper CPU_V7 and CPU_V7_HAS_foo checks instead Changes in v5: -Jump patch-set version to v5 to match the revision level of the patch with the highest revision in the set -Kconfig: Add EXPERT option -Add Masahiro Yamada's Acked-by -ARM: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options: -Fix the commit message to refer to the right Kconfig option -ARM: bootm: Allow booting in secure mode on hyp capable systems -Fix ARMV7_BOOT_SEC_DEFAULT Kconfig help text mixing up secure and non-secure modes Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/3] ARM: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options
Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options, this is a preparation patch for adding an env variable to choose between secure / non-secure boot on non-secure boot capable systems, specifically this prepares for adding CONFIG_ARMV7_BOOT_SEC_DEFAULT as a proper Kconfig option. Signed-off-by: Hans de Goede hdego...@redhat.com -- Changes in v2: -Drop all the FIXME-s, use proper CPU_V7 and CPU_V7_HAS_foo checks instead Changes in v5: -Fix the commit message to refer to the right Kconfig option --- arch/arm/Kconfig| 4 arch/arm/cpu/armv7/Kconfig | 23 +++ arch/arm/cpu/armv7/exynos/Kconfig | 2 ++ board/sunxi/Kconfig | 2 ++ include/configs/arndale.h | 2 -- include/configs/sun7i.h | 2 -- include/configs/vexpress_ca15_tc2.h | 2 -- 7 files changed, 31 insertions(+), 6 deletions(-) create mode 100644 arch/arm/cpu/armv7/Kconfig diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 79ccc06..43ace2c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -410,6 +410,8 @@ config TARGET_INTEGRATORCP_CM946ES config TARGET_VEXPRESS_CA15_TC2 bool Support vexpress_ca15_tc2 select CPU_V7 + select CPU_V7_HAS_NONSEC + select CPU_V7_HAS_VIRT config TARGET_VEXPRESS_CA5X2 bool Support vexpress_ca5x2 @@ -809,6 +811,8 @@ source arch/arm/cpu/arm926ejs/versatile/Kconfig source arch/arm/cpu/armv7/zynq/Kconfig +source arch/arm/cpu/armv7/Kconfig + source board/aristainetos/Kconfig source board/BuR/kwb/Kconfig source board/BuR/tseries/Kconfig diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig new file mode 100644 index 000..15c5155 --- /dev/null +++ b/arch/arm/cpu/armv7/Kconfig @@ -0,0 +1,23 @@ +if CPU_V7 + +config CPU_V7_HAS_NONSEC +bool + +config CPU_V7_HAS_VIRT +bool + +config ARMV7_NONSEC + boolean Enable support for booting in non-secure mode if EXPERT + depends on CPU_V7_HAS_NONSEC + default y + ---help--- + Say Y here to enable support for booting in non-secure / SVC mode. + +config ARMV7_VIRT + boolean Enable support for hardware virtualization if EXPERT + depends on CPU_V7_HAS_VIRT ARMV7_NONSEC + default y + ---help--- + Say Y here to boot in hypervisor (HYP) mode when booting non-secure. + +endif diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 090be93..e9a102c 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -26,6 +26,8 @@ config TARGET_ODROID config TARGET_ARNDALE bool Exynos5250 Arndale board + select CPU_V7_HAS_NONSEC + select CPU_V7_HAS_VIRT select SUPPORT_SPL select OF_CONTROL if !SPL_BUILD diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index c3f865d..7555896 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -21,6 +21,8 @@ config MACH_SUN6I config MACH_SUN7I bool sun7i (Allwinner A20) select CPU_V7 + select CPU_V7_HAS_NONSEC + select CPU_V7_HAS_VIRT select SUPPORT_SPL config MACH_SUN8I diff --git a/include/configs/arndale.h b/include/configs/arndale.h index f9ee40f..aa6b631 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -60,6 +60,4 @@ /* The PERIPHBASE in the CBAR register is wrong on the Arndale, so override it */ #define CONFIG_ARM_GIC_BASE_ADDRESS0x1048 -#define CONFIG_ARMV7_VIRT - #endif /* __CONFIG_H */ diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h index ea40790..3629587 100644 --- a/include/configs/sun7i.h +++ b/include/configs/sun7i.h @@ -22,8 +22,6 @@ #define CONFIG_USB_MAX_CONTROLLER_COUNT2 #endif -#define CONFIG_ARMV7_VIRT 1 -#define CONFIG_ARMV7_NONSEC1 #define CONFIG_ARMV7_PSCI 1 #define CONFIG_ARMV7_PSCI_NR_CPUS 2 #define CONFIG_ARMV7_SECURE_BASE SUNXI_SRAM_B_BASE diff --git a/include/configs/vexpress_ca15_tc2.h b/include/configs/vexpress_ca15_tc2.h index 982f4a7..b43afa2 100644 --- a/include/configs/vexpress_ca15_tc2.h +++ b/include/configs/vexpress_ca15_tc2.h @@ -18,6 +18,4 @@ #define CONFIG_SYSFLAGS_ADDR 0x1c010030 #define CONFIG_SMP_PEN_ADDRCONFIG_SYSFLAGS_ADDR -#define CONFIG_ARMV7_VIRT - #endif -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/3] ARM: bootm: Allow booting in secure mode on hyp capable systems
Older Linux kernels will not properly boot in hyp mode, add support for a
bootm_boot_mode environment variable, which can be set to sec or nonsec
to force booting in secure or non-secure mode when build with non-sec support.
The default behavior can be selected through CONFIG_ARMV7_BOOT_SEC_DEFAULT,
when this is set booting in secure mode is the default. The default setting
for this Kconfig option is N, preserving the current behavior of booting in
non-secure mode by default when non-secure mode is supported.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Marc Zyngier marc.zyng...@arm.com
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Changes in v2:
-Allow changing the default boot mode to secure through defining
CONFIG_ARMV7_BOOT_SEC_DEFAULT, this is useful for archs which have a Kconfig
option for compatibility with older kernels
Changes in v3:
-Add an else at the end of the #ifdef NONSEC block so that if do_nonsec_entry
fails we do not end up re-trying in secure mode
Changes in v4:
-Add a Kconfig option to select to boot in secure or non-secure mode by default
Changes in v5:
-Fix ARMV7_BOOT_SEC_DEFAULT Kconfig help text mixing up secure and non-secure
modes
---
arch/arm/cpu/armv7/Kconfig | 11 +++
arch/arm/lib/bootm.c | 31 ++-
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index 15c5155..61e7c82 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -13,6 +13,17 @@ config ARMV7_NONSEC
---help---
Say Y here to enable support for booting in non-secure / SVC mode.
+config ARMV7_BOOT_SEC_DEFAULT
+ boolean Boot in secure mode by default if EXPERT
+ depends on ARMV7_NONSEC
+ default n
+ ---help---
+ Say Y here to boot in secure mode by default even if non-secure mode
+ is supported. This option is useful to boot kernels which do not
+ suppport booting in non-secure mode. Only set this if you need it.
+ This can be overriden at run-time by setting the bootm_boot_mode env.
+ variable to sec or nonsec.
+
config ARMV7_VIRT
boolean Enable support for hardware virtualization if EXPERT
depends on CPU_V7_HAS_VIRT ARMV7_NONSEC
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 4949d57..a7f7c67 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -237,6 +237,26 @@ static void boot_prep_linux(bootm_headers_t *images)
}
}
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+static bool boot_nonsec(void)
+{
+ char *s = getenv(bootm_boot_mode);
+#ifdef CONFIG_ARMV7_BOOT_SEC_DEFAULT
+ bool nonsec = false;
+#else
+ bool nonsec = true;
+#endif
+
+ if (s !strcmp(s, sec))
+ nonsec = false;
+
+ if (s !strcmp(s, nonsec))
+ nonsec = true;
+
+ return nonsec;
+}
+#endif
+
/* Subcommand: GO */
static void boot_jump_linux(bootm_headers_t *images, int flag)
{
@@ -285,12 +305,13 @@ static void boot_jump_linux(bootm_headers_t *images, int
flag)
if (!fake) {
#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
- armv7_init_nonsec();
- secure_ram_addr(_do_nonsec_entry)(kernel_entry,
- 0, machid, r2);
-#else
- kernel_entry(0, machid, r2);
+ if (boot_nonsec()) {
+ armv7_init_nonsec();
+ secure_ram_addr(_do_nonsec_entry)(kernel_entry,
+ 0, machid, r2);
+ } else
#endif
+ kernel_entry(0, machid, r2);
}
#endif
}
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/3] Kconfig: Add EXPERT option
From: Tom Rini tr...@ti.com For similar reasons to why the Linux Kernel has an EXPERT option, we too want an option to allow for tweaking of some options that while normally should remain hidden, may need to be changed in some cases. Signed-off-by: Tom Rini tr...@ti.com Acked-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Hans de Goede hdego...@redhat.com Signed-off-by: Hans de Goede hdego...@redhat.com --- Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/Kconfig b/Kconfig index f34f341..405b7a6 100644 --- a/Kconfig +++ b/Kconfig @@ -58,6 +58,14 @@ config CC_OPTIMIZE_FOR_SIZE endmenu# General setup +menuconfig EXPERT +bool Configure standard U-Boot features (expert users) +help + This option allows certain base U-Boot options and settings + to be disabled or tweaked. This is for specialized + environments which can tolerate a non-standard U-Boot. + Only use this if you really know what you are doing. + menu Boot images config SPL_BUILD -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] ARM: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options
Hi, On 11/14/2014 08:29 AM, Albert ARIBAUD wrote: Hello Hans, On Thu, 13 Nov 2014 20:37:41 +0100, Hans de Goede hdego...@redhat.com wrote: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options, this is a preparation patch for adding an env variable to choose between secure / non-secure boot on non-secure boot capable systems, specifically this prepares for adding CONFIG_CPU_V7_SEC_BY_DEFAULT as a proper Kconfig option. Does not seem like CONFIG_CPU_V7_SEC_BY_DEFAULT is ever defined once all three patches are applied. OTOH, patch 3/3 defines CONFIG_ARMV7_BOOT_SEC_DEFAULT (but see my comments on it) Yes, my bad, I'll fix up the commit message. Signed-off-by: Hans de Goede hdego...@redhat.com -- Changes in v2: -Drop all the FIXME-s, use proper CPU_V7 and CPU_V7_HAS_foo checks instead --- arch/arm/Kconfig| 4 arch/arm/cpu/armv7/Kconfig | 23 +++ arch/arm/cpu/armv7/exynos/Kconfig | 2 ++ board/sunxi/Kconfig | 2 ++ include/configs/arndale.h | 2 -- include/configs/sun7i.h | 2 -- include/configs/vexpress_ca15_tc2.h | 2 -- 7 files changed, 31 insertions(+), 6 deletions(-) create mode 100644 arch/arm/cpu/armv7/Kconfig diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 79ccc06..43ace2c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -410,6 +410,8 @@ config TARGET_INTEGRATORCP_CM946ES config TARGET_VEXPRESS_CA15_TC2 bool Support vexpress_ca15_tc2 select CPU_V7 +select CPU_V7_HAS_NONSEC +select CPU_V7_HAS_VIRT config TARGET_VEXPRESS_CA5X2 bool Support vexpress_ca5x2 @@ -809,6 +811,8 @@ source arch/arm/cpu/arm926ejs/versatile/Kconfig source arch/arm/cpu/armv7/zynq/Kconfig +source arch/arm/cpu/armv7/Kconfig + source board/aristainetos/Kconfig source board/BuR/kwb/Kconfig source board/BuR/tseries/Kconfig diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig new file mode 100644 index 000..15c5155 --- /dev/null +++ b/arch/arm/cpu/armv7/Kconfig @@ -0,0 +1,23 @@ +if CPU_V7 + +config CPU_V7_HAS_NONSEC +bool + +config CPU_V7_HAS_VIRT +bool + +config ARMV7_NONSEC +boolean Enable support for booting in non-secure mode if EXPERT +depends on CPU_V7_HAS_NONSEC +default y I'm not a Kconfig expert, but doesn't this y here mean that support for non-secure mode is enabled by default? It does. And should'nt it be more logical / secure that the default b n to avoid accidentally building a non-secure-capable U-Boot? This is preserving the current default behavior, where all non-secure boot capable platforms default to building with non-secure boot enabled. +---help--- +Say Y here to enable support for booting in non-secure / SVC mode. + +config ARMV7_VIRT +boolean Enable support for hardware virtualization if EXPERT +depends on CPU_V7_HAS_VIRT ARMV7_NONSEC +default y Same here. Same. +---help--- +Say Y here to boot in hypervisor (HYP) mode when booting non-secure. + +endif diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 090be93..e9a102c 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -26,6 +26,8 @@ config TARGET_ODROID config TARGET_ARNDALE bool Exynos5250 Arndale board +select CPU_V7_HAS_NONSEC +select CPU_V7_HAS_VIRT select SUPPORT_SPL select OF_CONTROL if !SPL_BUILD diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 0bab31b..e20ea1b 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -21,6 +21,8 @@ config MACH_SUN6I config MACH_SUN7I bool sun7i (Allwinner A20) select CPU_V7 +select CPU_V7_HAS_NONSEC +select CPU_V7_HAS_VIRT select SUPPORT_SPL config MACH_SUN8I diff --git a/include/configs/arndale.h b/include/configs/arndale.h index f9ee40f..aa6b631 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -60,6 +60,4 @@ /* The PERIPHBASE in the CBAR register is wrong on the Arndale, so override it */ #define CONFIG_ARM_GIC_BASE_ADDRESS 0x1048 -#define CONFIG_ARMV7_VIRT - #endif /* __CONFIG_H */ diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h index ea40790..3629587 100644 --- a/include/configs/sun7i.h +++ b/include/configs/sun7i.h @@ -22,8 +22,6 @@ #define CONFIG_USB_MAX_CONTROLLER_COUNT 2 #endif -#define CONFIG_ARMV7_VIRT 1 -#define CONFIG_ARMV7_NONSEC 1 #define CONFIG_ARMV7_PSCI 1 #define CONFIG_ARMV7_PSCI_NR_CPUS 2 #define CONFIG_ARMV7_SECURE_BASESUNXI_SRAM_B_BASE diff --git a/include/configs/vexpress_ca15_tc2.h b/include/configs/vexpress_ca15_tc2.h index 982f4a7..b43afa2 100644 --- a/include/configs/vexpress_ca15_tc2.h +++ b/include/configs/vexpress_ca15_tc2.h @@ -18,6 +18,4 @@ #define
Re: [U-Boot] [PATCH v5 1/3] Kconfig: Add EXPERT option
Hello Hans, On Fri, 14 Nov 2014 09:34:29 +0100, Hans de Goede hdego...@redhat.com wrote: From: Tom Rini tr...@ti.com For similar reasons to why the Linux Kernel has an EXPERT option, we too want an option to allow for tweaking of some options that while normally should remain hidden, may need to be changed in some cases. Signed-off-by: Tom Rini tr...@ti.com Acked-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Hans de Goede hdego...@redhat.com Signed-off-by: Hans de Goede hdego...@redhat.com --- As you're just resending Tom's patch, should it have your own Signed-off-by? No need to post v6 if you think this should be corrected, I would do it when applying. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] imx: fix exception vectors relocation in imx27
Hi Albert,
firstly I can tell you that patch fixes the issue. I tested on magnesium
board. Board boots flawless with your patch.
On 13/11/2014 17:59, Albert ARIBAUD wrote:
Commit 3ff46cc4 fixed exception vectors setting in
the general ARM case, by either copying the exception
and indirect vector tables to normal (0x) or
high (0x) vectors address, or setting VBAR to
U-Boot's base if applicable.
i.MX27 SoC is ARM926E-JS, thus has only normal and
high options, but does not provide RAM at 0x
and has only ROM at 0x; it is therefore not
possible to move or change its exception vectors.
Besides, i.MX27 ROM code does provide an indirect
vectors table but at a non-standard address and with
the reset and reserved vectors missing.
Turn the current vector relocation code into a weak
routine called after relocate_code from crt0, and add
strong version for i.MX27.
Series-Cc: Heiko Schocher h...@denx.de
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v3:
- Fixed AGAIN wrong i.MX27 vector relocation code
Changes in v2:
- Fixed wrong i.MX27 vector relocation code
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++
arch/arm/cpu/arm926ejs/mx27/relocate.S | 51 +
arch/arm/lib/crt0.S| 5 +++
arch/arm/lib/relocate.S| 69
--
4 files changed, 101 insertions(+), 28 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/mx27/relocate.S
diff --git a/arch/arm/cpu/arm926ejs/mx27/Makefile
b/arch/arm/cpu/arm926ejs/mx27/Makefile
index 4976bbb..0edf144 100644
--- a/arch/arm/cpu/arm926ejs/mx27/Makefile
+++ b/arch/arm/cpu/arm926ejs/mx27/Makefile
@@ -5,3 +5,7 @@
# SPDX-License-Identifier: GPL-2.0+
obj-y= generic.o reset.o timer.o
+
+ifndef CONFIG_SPL_BUILD
+obj-y+= relocate.o
+endif
diff --git a/arch/arm/cpu/arm926ejs/mx27/relocate.S
b/arch/arm/cpu/arm926ejs/mx27/relocate.S
new file mode 100644
index 000..0c4b272
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mx27/relocate.S
@@ -0,0 +1,51 @@
+/*
+ * relocate - i.MX27-specific vector relocation
+ *
+ * Copyright (c) 2013 Albert ARIBAUD albert.u.b...@aribaud.net
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include asm-offsets.h
+#include config.h
+#include linux/linkage.h
+
+/*
+ * The i.MX27 SoC is very specific with respect to exceptions: it
+ * does not provide RAM at the high vectors address (0x),
+ * thus only the low address (0x) is useable; but that is
+ * in ROM. Therefore, vectors cannot be changed at all.
+ *
+ * However, these ROM-based vectors actually just perform indirect
+ * calls through pointers located in RAM at SoC-specific addresses,
+ * as follows:
+ *
+ * Offset Exception Use by ROM code
+ * 0x reset indirect branch to [0x0014]
+ * 0x0004 undefined instruction indirect branch to [0xfef0]
+ * 0x0008 software interrupt indirect branch to [0xfef4]
+ * 0x000c prefetch abort indirect branch to [0xfef8]
+ * 0x0010 data abort indirect branch to [0xfefc]
+ * 0x0014 (reserved in ARMv5)vector to ROM reset: 0xc000
+ * 0x0018 IRQindirect branch to [0xff00]
+ * 0x001c FIQindirect branch to [0xff04]
+ *
+ * In order to initialize exceptions on i.MX27, we must copy U-Boot's
+ * indirect (not exception!) vector table into 0xfef0..0xff04
+ * taking care not to copy vectors number 5 (reserved exception).
+ */
+
+ .section.text.relocate_vectors,ax,%progbits
+
+ENTRY(relocate_vectors)
+
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ ldr r1, =32 /* size of vector table */
+ add r0, r0, r1 /* skip to indirect table */
+ ldr r1, =0xFEF0 /* i.MX27 indirect table */
+ ldmia r0!, {r2-r8}/* load indirect vectors 1..7 */
+ stmia r1!, {r2-r5, r7,r8} /* write all but vector 5 */
+
+ bx lr
+
+ENDPROC(relocate_vectors)
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 29cdad0..a33ad3e 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -104,6 +104,11 @@ clr_gd:
ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
b relocate_code
here:
+/*
+ * now relocate vectors
+ */
+
+ bl relocate_vectors
/* Set up final (full) environment */
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 6ede41c..92f5314 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -11,6 +11,47 @@
#include linux/linkage.h
/*
+ * Default/weak exception vectors relocation routine
+ *
+ * This routine covers the standard ARM cases: normal (0x),
+ * high (0x) and VBAR.
Re: [U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hi Albert,
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+/* Setting the address at which secondary cores start from.*/
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
+ out_be32(gur-scratchrw[0], addr);
+ out_be32(gur-brrl, 0x2);
+}
This function does not exactly [set] the address at which secondary
cores start from; it sets *a* secondary core's boot address, and then
it *boots* it.
Okay, I will fix it later.
Why does this version of smp_set_core_boot_addr() need to boot the core
in addition to setting the address, whereas the existing ones in
virt_v7, vexpress_common and arndale don't boot the cores?
Yes, they don't doing the release operation.
For Low Power Management requirement, maybe only one core will be used, and then
We also make sure that the secondary core must be in low power and deep sleep
mode(using wfi). So I just release it here, to make sure that the wfi
instruction
will be executed as early as possible.
Thanks,
BRs,
Xiubo
+#endif
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
b/arch/arm/include/asm/arch-ls102xa/config.h
index ed78c33..4856388 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -11,6 +11,8 @@
#define OCRAM_BASE_ADDR0x1000
#define OCRAM_SIZE 0x0002
+#define OCRAM_BASE_S_ADDR 0x1001
+#define OCRAM_S_SIZE 0x0001
#define CONFIG_SYS_IMMR0x0100
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..0bac353 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -17,6 +17,9 @@
#define SOC_VER_LS1021 0x11
#define SOC_VER_LS1022 0x12
+#define CCSR_BRR_OFFSET0xe4
+#define CCSR_SCRATCHRW1_OFFSET 0x200
+
#define RCWSR0_SYS_PLL_RAT_SHIFT 25
#define RCWSR0_SYS_PLL_RAT_MASK0x1f
#define RCWSR0_MEM_PLL_RAT_SHIFT 16
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 657e3b6..6976cfa 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -324,6 +324,13 @@ unsigned long get_board_ddr_clk(void);
#define CONFIG_CMDLINE_EDITING
#define CONFIG_CMD_IMLS
+#define CONFIG_ARMV7_NONSEC
+#define CONFIG_ARMV7_VIRT
+#define CONFIG_PEN_ADDR_BIG_ENDIAN
+#define CONFIG_SMP_PEN_ADDR0x01ee0200
+#define CONFIG_TIMER_CLK_FREQ 1250
+#define CONFIG_ARMV7_SECURE_BASE OCRAM_BASE_S_ADDR
+
#define CONFIG_HWCONFIG
#define HWCONFIG_BUFFER_SIZE 128
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 45b2272..655b39a 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -227,6 +227,13 @@
#define CONFIG_CMDLINE_EDITING
#define CONFIG_CMD_IMLS
+#define CONFIG_ARMV7_NONSEC
+#define CONFIG_ARMV7_VIRT
+#define CONFIG_PEN_ADDR_BIG_ENDIAN
+#define CONFIG_SMP_PEN_ADDR0x01ee0200
+#define CONFIG_TIMER_CLK_FREQ 1250
+#define CONFIG_ARMV7_SECURE_BASE OCRAM_BASE_S_ADDR
+
#define CONFIG_HWCONFIG
#define HWCONFIG_BUFFER_SIZE 128
--
2.1.0.27.g96db324
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6sabresd: Move the DCD settings to spl code
On Thu, Nov 13, 2014 at 8:30 PM, Fabio Estevam feste...@gmail.com wrote: On Thu, Nov 13, 2014 at 8:25 PM, Nikolay Dimitrov picmas...@mail.bg wrote: Do you know which kernel versions are compatible with this CCM_CCOSR change? Since commit a94f8ecb2f778f92 (ARM: imx6q: remove board specific CLKO setup), which appeared in 3.12, there is no need to set the CCM_CCOSR register in U-boot. Is this also included in 3.10.17-1.0.x GA BSP? Otherwise we should keep it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: set skew settings for ethernet phy
On Thu 2014-11-13 11:23:41, dingu...@opensource.altera.com wrote:
From: Dinh Nguyen dingu...@opensource.altera.com
Set the PHY skew settings for the ethernet phy on the SOCFPGA Cyclone5
hardware.
Is it to need similar settings for all ksz9021 phys? Should this go to
drivers/ as I suggested with a patch?
Thanks,
Pavel
Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
Cc: Vince Bridgers vbrid...@opensource.altera.com
Cc: Pavel Machek pa...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Wolfgang Denk w...@denx.de
---
v2: Added comments on why it is necessary for setting the skew values.
---
board/altera/socfpga/socfpga_cyclone5.c | 16
1 file changed, 16 insertions(+)
diff --git a/board/altera/socfpga/socfpga_cyclone5.c
b/board/altera/socfpga/socfpga_cyclone5.c
index 0f81d89..543a143 100644
--- a/board/altera/socfpga/socfpga_cyclone5.c
+++ b/board/altera/socfpga/socfpga_cyclone5.c
@@ -8,7 +8,9 @@
#include asm/arch/reset_manager.h
#include asm/io.h
+#include micrel.h
#include netdev.h
+#include phy.h
DECLARE_GLOBAL_DATA_PTR;
@@ -39,3 +41,17 @@ int board_init(void)
return 0;
}
+
+int board_phy_config(struct phy_device *phydev)
+{
+ /*
+ * These skew settings for the KSZ9021 ethernet phy is required for
ethernet
+ * to work reliably on most flavors of cyclone5 boards.
+ */
+ ksz9021_phy_extended_write(phydev, MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW,
+0x0);
+ ksz9021_phy_extended_write(phydev, MII_KSZ9021_EXT_RGMII_TX_DATA_SKEW,
+0x0);
+ ksz9021_phy_extended_write(phydev, MII_KSZ9021_EXT_RGMII_CLOCK_SKEW,
+0xf0f0);
+}
--
(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] arm: socfpga: dts: Move to SPDX license identifiers
On Fri 2014-11-14 08:10:44, Stefan Roese wrote: The socfpga dts files are copied from the Rocketboards.org repository. In U-Boot we usually replace the full-blown license header text with the SPDX license identifiers. Lets do this for these new dts files as well. I just forgot to do this while adding the DT support for socfpga. Signed-off-by: Stefan Roese s...@denx.de Cc: Marek Vasut ma...@denx.de Acked-by: Pavel Machek pa...@denx.de -- (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] mx6sabresd: Move the DCD settings to spl code
Hi Otavio, On Fri, Nov 14, 2014 at 8:17 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Nov 13, 2014 at 8:30 PM, Fabio Estevam feste...@gmail.com wrote: On Thu, Nov 13, 2014 at 8:25 PM, Nikolay Dimitrov picmas...@mail.bg wrote: Do you know which kernel versions are compatible with this CCM_CCOSR change? Since commit a94f8ecb2f778f92 (ARM: imx6q: remove board specific CLKO setup), which appeared in 3.12, there is no need to set the CCM_CCOSR register in U-boot. Is this also included in 3.10.17-1.0.x GA BSP? Otherwise we should keep it. Please check FSL U-boot: http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/mx6qsabresd/mx6dl_4x_mt41j128.cfg?h=imx_v2013.04_3.10.17_1.0.0_ga It does not have the CCM_CCOSR settings there as well. It was only mainline kernel that needed this sometime ago. Currently it is not needed to have CCM_CCOSR configured in U-boot anymore, which makes a lot more sense. Now we can safely remove such hack. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Add myself as maintainer for the SoCrates board
On Fri 2014-11-14 08:45:36, Stefan Roese wrote: Signed-off-by: Stefan Roese s...@denx.de Cc: Marek Vasut ma...@denx.de Acked-by: Pavel Machek pa...@denx.de -- (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] dfu: thor: fix: Modify dfu_get_alt() function to support absolute paths
Hi Lukasz,
Recently the ext4 file system imposed passing absolute path with its
file name parameter.
As a result dfu_alt_info env variable has been modified to provide
absolute path when ext4 file system is accessed (e.g. /uImage ext4 0
2;).
Unfortunately, lthor flashing program provides plain file name (like
uImage) and hence those two file names do not match anymore.
Presented commit also allows lthor to write files to sub directories
(like /boot/bin/uImage).
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Marek Vasut ma...@denx.de
---
Changes for v2:
- Fix patch to path in comment
---
drivers/dfu/dfu.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 55e6a83..deafda2 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -544,10 +544,35 @@ struct dfu_entity *dfu_get_entity(int alt)
int dfu_get_alt(char *name)
{
struct dfu_entity *dfu;
+ char *str;
list_for_each_entry(dfu, dfu_list, list) {
- if (!strncmp(dfu-name, name, strlen(dfu-name)))
- return dfu-alt;
+ if (dfu-name[0] != '/') {
+ if (!strncmp(dfu-name, name,
strlen(dfu-name)))
+ return dfu-alt;
+ } else {
+ /*
+ * One must also consider absolute path
+ * (/boot/bin/uImage) available at dfu-name
when
+ * compared plain file name (uImage)
+ *
+ * It is the case for e.g. thor gadget where
lthor SW
+ * sends only the file name, so only the
very last part
+ * of path must be checked for equality
+ */
+
+ str = strstr(dfu-name, name);
+ if (!str)
+ continue;
+
+ /*
+ * Check if matching substring is the last
element of
+ * dfu-name (uImage)
+ */
+ if (strlen(dfu-name) ==
+ ((str - dfu-name) + strlen(name)))
+ return dfu-alt;
+ }
}
return -ENODEV;
Applied to u-boot-dfu repository. Thanks
--
Best regards,
Lukasz Majewski
Samsung RD 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 v2] test: ums: Add sleep before unmount directory
Hi Lukasz, On Wed, 12 Nov 2014 11:11:33 -0700 Stephen Warren swar...@wwwdotorg.org wrote: On 11/12/2014 09:45 AM, Wolfgang Denk wrote: Dear Lukasz, In message 20141112152949.1fe6ce3c@amdc2363 you wrote: But this is a bug. Papering over is not a good idea. It should be analyzed, reported, and finally fixed. I've debugged the script with strace. Thanks a lot for that! The problem is with umount() syscall: ... I need to debug the syscall in the kernel. I have a gut feeling that this might be a problem somewhere with the USB stuff that is involved here. Maybe enabling some degug messages for the USB subsystem gives some more information? If this really is related to USB only, it may be worth asking on the linux-usb mailing list to see if anyone already unerstands the issue. Frankly speaking, I'm personally curious why such things happen. I may look into the issue in my spare :-) time. In spite of this, I agree with Stephen: Irrespective of all this though, even if there is a kernel issue and it can be fixed, I still think we should apply this patch, because the issue currently affects people. At the very least it will until some kernel fix is rolled out to everyone's distro, which will be a while no matter what. +1 The problem seems to be with long time running linux. The error seems to be orthogonal to our u-boot's UMS work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Best regards, Lukasz Majewski Applied to u-boot-dfu tree. Thanks. -- Best regards, Lukasz Majewski Samsung RD 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] [ANN] U-Boot v2015.01-rc1 released
Hi Tom, On 11/10/2014 10:29 PM, Tom Rini wrote: Hey all, I've pushed v2015.01-rc1 out to the repository and tarballs should exist soon. The merge window is now closed. Per both the min-summit and the follow up emails, I'm going to try and get into the every 2 week RC tagging groove. And, I'm going to be relying on everyones best judgement about what level of changes they're going to put into a pull request to me. When I do a buildman of most things I see: blackfin: + ip04 arm: + Ippo_q8h_v5 novena openrd_base maxbcm openrd_ultimate openrd_client tricorder db-mv784mp-gp Linksprite_pcDuino3_fdt tricorder_flash cm_t3517 powerpc: + kmcoge4 taishan kmlion1 dlvision And I'd really like to see those sorted out, one way or another for -rc2. For both kmcoge4 and kmlion1, the error is fixed by [1]. Hopefully York will be able to review this, also with the 2 patches for the migration of the keymile powerpc board to generic board, for -rc2. Best Regards Valentin [1] http://patchwork.ozlabs.org/patch/403232/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] gw_ventana: Move the DCD settings to spl code
From: Fabio Estevam fabio.este...@freescale.com
mx6sabresd_spl.cfg configures CCM registers, GPR registers and CCM_CCOSR.
Move the configuration to the spl code.
CCM_CCOSR setting is no longer required to get audio functionality in the
kernel, so remove such setting.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Newly introduced on this series
board/gateworks/gw_ventana/clocks.cfg | 42 -
board/gateworks/gw_ventana/gw_ventana.cfg | 6 -
board/gateworks/gw_ventana/gw_ventana_spl.c | 28 +++
3 files changed, 28 insertions(+), 48 deletions(-)
delete mode 100644 board/gateworks/gw_ventana/clocks.cfg
diff --git a/board/gateworks/gw_ventana/clocks.cfg
b/board/gateworks/gw_ventana/clocks.cfg
deleted file mode 100644
index a8118a2..000
--- a/board/gateworks/gw_ventana/clocks.cfg
+++ /dev/null
@@ -1,42 +0,0 @@
-/*
- * Copyright (C) 2013 Boundary Devices
- * Copyright (C) 2013 Gateworks Corporation
- *
- * SPDX-License-Identifier: GPL-2.0+
- *
- * Device Configuration Data (DCD)
- *
- * Each entry must have the format:
- * Addr-type AddressValue
- *
- * where:
- * Addr-type register length (1,2 or 4 bytes)
- * Address absolute address of the register
- * value value to be stored in the register
- */
-
-/* set the default clock gate to save power */
-DATA 4, CCM_CCGR0, 0x00C03F3F
-DATA 4, CCM_CCGR1, 0x0030FC03
-DATA 4, CCM_CCGR2, 0x0FFFC000
-DATA 4, CCM_CCGR3, 0x3FF0
-DATA 4, CCM_CCGR4, 0xF300 /* enable NAND/GPMI/BCH clocks */
-DATA 4, CCM_CCGR5, 0x0FC3
-DATA 4, CCM_CCGR6, 0x03FF
-
-/* enable AXI cache for VDOA/VPU/IPU */
-DATA 4, MX6_IOMUXC_GPR4, 0xF0CF
-/* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */
-DATA 4, MX6_IOMUXC_GPR6, 0x007F007F
-DATA 4, MX6_IOMUXC_GPR7, 0x007F007F
-
-/*
- * Setup CCM_CCOSR register as follows:
- *
- * cko1_en = 1-- CKO1 enabled
- * cko1_div = 111 -- divide by 8
- * cko1_sel = 1011 -- ahb_clk_root
- *
- * This sets CKO1 at ahb_clk_root/8 = 132/8 = 16.5 MHz
- */
-DATA 4, CCM_CCOSR, 0x00fb
diff --git a/board/gateworks/gw_ventana/gw_ventana.cfg
b/board/gateworks/gw_ventana/gw_ventana.cfg
index 9ab95f5..dd8aa61 100644
--- a/board/gateworks/gw_ventana/gw_ventana.cfg
+++ b/board/gateworks/gw_ventana/gw_ventana.cfg
@@ -21,9 +21,3 @@ BOOT_FROM spi
#else
BOOT_FROM nand
#endif
-
-#define __ASSEMBLY__
-#include config.h
-#include asm/arch/iomux.h
-#include asm/arch/crm_regs.h
-#include clocks.cfg
diff --git a/board/gateworks/gw_ventana/gw_ventana_spl.c
b/board/gateworks/gw_ventana/gw_ventana_spl.c
index ca35b3c..d6a5847 100644
--- a/board/gateworks/gw_ventana/gw_ventana_spl.c
+++ b/board/gateworks/gw_ventana/gw_ventana_spl.c
@@ -8,6 +8,7 @@
#include common.h
#include i2c.h
#include asm/io.h
+#include asm/arch/crm_regs.h
#include asm/arch/iomux.h
#include asm/arch/mx6-ddr.h
#include asm/arch/mx6-pins.h
@@ -392,6 +393,30 @@ static void spl_dram_init(int width, int size_mb, int
board_model)
mx6_dram_cfg(sysinfo, calib, mem);
}
+static void ccgr_init(void)
+{
+ struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ writel(0x00C03F3F, ccm-CCGR0);
+ writel(0x0030FC03, ccm-CCGR1);
+ writel(0x0FFFC000, ccm-CCGR2);
+ writel(0x3FF0, ccm-CCGR3);
+ writel(0x00FFF300, ccm-CCGR4);
+ writel(0x0FC3, ccm-CCGR5);
+ writel(0x03FF, ccm-CCGR6);
+}
+
+static void gpr_init(void)
+{
+ struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
+
+ /* enable AXI cache for VDOA/VPU/IPU */
+ writel(0xF0CF, iomux-gpr[4]);
+ /* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */
+ writel(0x007F007F, iomux-gpr[6]);
+ writel(0x007F007F, iomux-gpr[7]);
+}
+
/*
* called from C runtime startup code (arch/arm/lib/crt0.S:_main)
* - we have a stack and a place to store GD, both in SRAM
@@ -405,6 +430,9 @@ void board_init_f(ulong dummy)
/* setup AIPS and disable watchdog */
arch_cpu_init();
+ ccgr_init();
+ gpr_init();
+
/* iomux and setup of i2c */
board_early_init_f();
i2c_setup_iomux();
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] mx6sabresd: Move the DCD settings to spl code
From: Fabio Estevam fabio.este...@freescale.com
mx6sabresd_spl.cfg configures CCM registers, GPR registers and CCM_CCOSR.
Move the configuration to the spl code.
CCM_CCOSR setting is no longer required to get audio functionality in the
kernel, so remove such setting.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- None. Send it as a series and use a common spl .cfg per Stefano's suggestion
board/freescale/mx6sabresd/mx6sabresd.c | 27 +++
board/freescale/mx6sabresd/mx6sabresd_spl.cfg | 38 ---
2 files changed, 27 insertions(+), 38 deletions(-)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 1142e8a..343c3b6 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -729,6 +729,30 @@ static struct mx6_ddr3_cfg mem_ddr = {
.trasmin = 3500,
};
+static void ccgr_init(void)
+{
+ struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ writel(0x00C03F3F, ccm-CCGR0);
+ writel(0x0030FC03, ccm-CCGR1);
+ writel(0x0FFFC000, ccm-CCGR2);
+ writel(0x3FF0, ccm-CCGR3);
+ writel(0x00FFF300, ccm-CCGR4);
+ writel(0x0FC3, ccm-CCGR5);
+ writel(0x03FF, ccm-CCGR6);
+}
+
+static void gpr_init(void)
+{
+ struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
+
+ /* enable AXI cache for VDOA/VPU/IPU */
+ writel(0xF0CF, iomux-gpr[4]);
+ /* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */
+ writel(0x007F007F, iomux-gpr[6]);
+ writel(0x007F007F, iomux-gpr[7]);
+}
+
/*
* This section require the differentiation
* between iMX6 Sabre Families.
@@ -768,6 +792,9 @@ void board_init_f(ulong dummy)
/* setup AIPS and disable watchdog */
arch_cpu_init();
+ ccgr_init();
+ gpr_init();
+
/* iomux and setup of i2c */
board_early_init_f();
diff --git a/board/freescale/mx6sabresd/mx6sabresd_spl.cfg
b/board/freescale/mx6sabresd/mx6sabresd_spl.cfg
index 2bf4817..1d031ba 100644
--- a/board/freescale/mx6sabresd/mx6sabresd_spl.cfg
+++ b/board/freescale/mx6sabresd/mx6sabresd_spl.cfg
@@ -18,41 +18,3 @@ IMAGE_VERSION 2
* spi, sd (the board has no nand neither onenand)
*/
BOOT_FROM sd
-
-/*
- * Device Configuration Data (DCD)
- *
- * Each entry must have the format:
- * Addr-type AddressValue
- *
- * where:
- * Addr-type register length (1,2 or 4 bytes)
- * Address absolute address of the register
- * value value to be stored in the register
- */
-
-/* set the default clock gate to save power */
-DATA 4 0x020c4068 0x00C03F3F
-DATA 4 0x020c406c 0x0030FC03
-DATA 4 0x020c4070 0x0FFFC000
-DATA 4 0x020c4074 0x3FF0
-DATA 4 0x020c4078 0x00FFF300
-DATA 4 0x020c407c 0x0FC3
-DATA 4 0x020c4080 0x03FF
-
-/* enable AXI cache for VDOA/VPU/IPU */
-DATA 4 0x020e0010 0xF0CF
-/* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */
-DATA 4 0x020e0018 0x007F007F
-DATA 4 0x020e001c 0x007F007F
-
-/*
- * Setup CCM_CCOSR register as follows:
- *
- * cko1_en = 1 -- CKO1 enabled
- * cko1_div = 111 -- divide by 8
- * cko1_sel = 1011 -- ahb_clk_root
- *
- * This sets CKO1 at ahb_clk_root/8 = 132/8 = 16.5 MHz
- */
-DATA 4 0x020c4060 0x00fb
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] mx6: Use a common SPL configuration file
From: Fabio Estevam fabio.este...@freescale.com Many boards use a minimal .cfg file in the SPL case. Introduce spl_sd.cfg so that we can reuse it. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v1: - Newly introduced on this series arch/arm/imx-common/spl_sd.cfg| 8 board/compulab/cm_fx6/imximage.cfg| 8 board/freescale/mx6sabresd/mx6sabresd_spl.cfg | 20 board/kosagi/novena/setup.cfg | 16 configs/cm_fx6_defconfig | 2 +- configs/mx6sabresd_spl_defconfig | 2 +- configs/novena_defconfig | 2 +- 7 files changed, 11 insertions(+), 47 deletions(-) create mode 100644 arch/arm/imx-common/spl_sd.cfg delete mode 100644 board/compulab/cm_fx6/imximage.cfg delete mode 100644 board/freescale/mx6sabresd/mx6sabresd_spl.cfg delete mode 100644 board/kosagi/novena/setup.cfg diff --git a/arch/arm/imx-common/spl_sd.cfg b/arch/arm/imx-common/spl_sd.cfg new file mode 100644 index 000..5fc3e8a --- /dev/null +++ b/arch/arm/imx-common/spl_sd.cfg @@ -0,0 +1,8 @@ +/* + * Copyright (C) 2014, Compulab Ltd - http://compulab.co.il/ + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +IMAGE_VERSION 2 +BOOT_FROM sd diff --git a/board/compulab/cm_fx6/imximage.cfg b/board/compulab/cm_fx6/imximage.cfg deleted file mode 100644 index 420947e..000 --- a/board/compulab/cm_fx6/imximage.cfg +++ /dev/null @@ -1,8 +0,0 @@ -/* - * Copyright (C) 2014, Compulab Ltd - http://compulab.co.il/ - * - * SPDX-License-Identifier:GPL-2.0+ - */ - -IMAGE_VERSION 2 -BOOT_FROM sd diff --git a/board/freescale/mx6sabresd/mx6sabresd_spl.cfg b/board/freescale/mx6sabresd/mx6sabresd_spl.cfg deleted file mode 100644 index 1d031ba..000 --- a/board/freescale/mx6sabresd/mx6sabresd_spl.cfg +++ /dev/null @@ -1,20 +0,0 @@ -/* - * Copyright (C) 2011 Freescale Semiconductor, Inc. - * Jason Liu r64...@freescale.com - * - * SPDX-License-Identifier:GPL-2.0+ - * - * Refer doc/README.imximage for more details about how-to configure - * and create imximage boot image - * - * The syntax is taken as close as possible with the kwbimage - */ - -/* image version */ -IMAGE_VERSION 2 - -/* - * Boot Device : one of - * spi, sd (the board has no nand neither onenand) - */ -BOOT_FROM sd diff --git a/board/kosagi/novena/setup.cfg b/board/kosagi/novena/setup.cfg deleted file mode 100644 index a79d1f7..000 --- a/board/kosagi/novena/setup.cfg +++ /dev/null @@ -1,16 +0,0 @@ -/* - * Copyright (C) 2014 Marek Vasut ma...@denx.de - * - * SPDX-License-Identifier:GPL-2.0+ - * - * Refer docs/README.imxmage for more details about how-to configure - * and create imximage boot image - * - * The syntax is taken as close as possible with the kwbimage - */ - -/* image version */ -IMAGE_VERSION 2 - -/* Boot Device : sd */ -BOOT_FROM sd diff --git a/configs/cm_fx6_defconfig b/configs/cm_fx6_defconfig index 50c06f7..3c0d64f 100644 --- a/configs/cm_fx6_defconfig +++ b/configs/cm_fx6_defconfig @@ -1,4 +1,4 @@ CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/compulab/cm_fx6/imximage.cfg,MX6QDL,SPL +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,MX6QDL,SPL +S:CONFIG_ARM=y +S:CONFIG_TARGET_CM_FX6=y diff --git a/configs/mx6sabresd_spl_defconfig b/configs/mx6sabresd_spl_defconfig index b7b26df..12e7844 100644 --- a/configs/mx6sabresd_spl_defconfig +++ b/configs/mx6sabresd_spl_defconfig @@ -1,5 +1,5 @@ CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/mx6sabresd/mx6sabresd_spl.cfg,SPL,MX6Q +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6Q +S:CONFIG_ARM=y +S:CONFIG_TARGET_MX6SABRESD=y diff --git a/configs/novena_defconfig b/configs/novena_defconfig index a560afb..d28dbd7 100644 --- a/configs/novena_defconfig +++ b/configs/novena_defconfig @@ -1,4 +1,4 @@ CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/kosagi/novena/setup.cfg,MX6Q,SPL +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,MX6Q,SPL +S:CONFIG_ARM=y +S:CONFIG_TARGET_KOSAGI_NOVENA=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] novena: Move the DCD settings to spl code
From: Fabio Estevam fabio.este...@freescale.com
mx6sabresd_spl.cfg configures CCM registers, GPR registers and CCM_CCOSR.
Move the configuration to the spl code.
CCM_CCOSR setting is no longer required to get audio functionality in the
kernel, so remove such setting.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Newly introduced on this series
board/kosagi/novena/novena_spl.c | 27 +++
board/kosagi/novena/setup.cfg| 31 ---
2 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/board/kosagi/novena/novena_spl.c b/board/kosagi/novena/novena_spl.c
index c4155dd..9cf3979 100644
--- a/board/kosagi/novena/novena_spl.c
+++ b/board/kosagi/novena/novena_spl.c
@@ -533,6 +533,30 @@ static struct mx6_ddr3_cfg elpida_4gib_1600 = {
.trasmin= 3590,
};
+static void ccgr_init(void)
+{
+ struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ writel(0x00C03F3F, ccm-CCGR0);
+ writel(0x0030FC03, ccm-CCGR1);
+ writel(0x0FFFC000, ccm-CCGR2);
+ writel(0x3FF0, ccm-CCGR3);
+ writel(0xF300, ccm-CCGR4);
+ writel(0x0FC3, ccm-CCGR5);
+ writel(0x03FF, ccm-CCGR6);
+}
+
+static void gpr_init(void)
+{
+ struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
+
+ /* enable AXI cache for VDOA/VPU/IPU */
+ writel(0xF0CF, iomux-gpr[4]);
+ /* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */
+ writel(0x007F007F, iomux-gpr[6]);
+ writel(0x007F007F, iomux-gpr[7]);
+}
+
/*
* called from C runtime startup code (arch/arm/lib/crt0.S:_main)
* - we have a stack and a place to store GD, both in SRAM
@@ -543,6 +567,9 @@ void board_init_f(ulong dummy)
/* setup AIPS and disable watchdog */
arch_cpu_init();
+ ccgr_init();
+ gpr_init();
+
/* setup GP timer */
timer_init();
diff --git a/board/kosagi/novena/setup.cfg b/board/kosagi/novena/setup.cfg
index 18d139c..a79d1f7 100644
--- a/board/kosagi/novena/setup.cfg
+++ b/board/kosagi/novena/setup.cfg
@@ -14,34 +14,3 @@ IMAGE_VERSION 2
/* Boot Device : sd */
BOOT_FROM sd
-
-#define __ASSEMBLY__
-#include config.h
-#include asm/arch/iomux.h
-#include asm/arch/crm_regs.h
-
-/* set the default clock gate to save power */
-DATA 4, CCM_CCGR0, 0x00C03F3F
-DATA 4, CCM_CCGR1, 0x0030FC03
-DATA 4, CCM_CCGR2, 0x0FFFC000
-DATA 4, CCM_CCGR3, 0x3FF0
-DATA 4, CCM_CCGR4, 0xF300 /* enable NAND/GPMI/BCH clocks */
-DATA 4, CCM_CCGR5, 0x0FC3
-DATA 4, CCM_CCGR6, 0x03FF
-
-/* enable AXI cache for VDOA/VPU/IPU */
-DATA 4, MX6_IOMUXC_GPR4, 0xF0CF
-/* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */
-DATA 4, MX6_IOMUXC_GPR6, 0x007F007F
-DATA 4, MX6_IOMUXC_GPR7, 0x007F007F
-
-/*
- * Setup CCM_CCOSR register as follows:
- *
- * cko1_en = 1-- CKO1 enabled
- * cko1_div = 111 -- divide by 8
- * cko1_sel = 1011 -- ahb_clk_root
- *
- * This sets CKO1 at ahb_clk_root/8 = 132/8 = 16.5 MHz
- */
-DATA 4, CCM_CCOSR, 0x00fb
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hello li.xi...@freescale.com,
On Fri, 14 Nov 2014 09:06:13 +, li.xi...@freescale.com
li.xi...@freescale.com wrote:
Hi Albert,
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+/* Setting the address at which secondary cores start from.*/
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ /*
+ * After setting the secondary cores start address,
+ * just release them to boot.
+ */
+ out_be32(gur-scratchrw[0], addr);
+ out_be32(gur-brrl, 0x2);
+}
This function does not exactly [set] the address at which secondary
cores start from; it sets *a* secondary core's boot address, and then
it *boots* it.
Okay, I will fix it later.
Why does this version of smp_set_core_boot_addr() need to boot the core
in addition to setting the address, whereas the existing ones in
virt_v7, vexpress_common and arndale don't boot the cores?
Yes, they don't doing the release operation.
For Low Power Management requirement, maybe only one core will be used, and
then
We also make sure that the secondary core must be in low power and deep sleep
mode(using wfi). So I just release it here, to make sure that the wfi
instruction
will be executed as early as possible.
Right after smp_set_core_boot_addr() is called, kick_all_cpus() isgoing
to be called. Wouldn't that boot your CPUs just as well?
Thanks,
BRs,
Xiubo
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6sabresd: Move the DCD settings to spl code
Hi Fabio, On 11/13/2014 11:58 PM, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com mx6sabresd_spl.cfg configures CCM registers, GPR registers and CCM_CCOSR. Move the configuration to the spl code. I forgot to asker earlier, but what are the benefits of going from DCD to SPL code to provide HW initialization? Regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] imx: fix exception vectors relocation in imx27
Hello Stefano, I don't currently know if the same issue happens on other i.MXes. Dropped the new ones, the other test cases are MX25 and MX31/35 (but last two are arm1136 (arm6) - is the issue also for this cpu type ?). It is surely worth to run current u-boot on these boards. I don't have i.MX based boards myself to test. ARM1136 does not have VBAR -- if it had, we could just set the VBAR to the base of the monitor and the issue would be solved. I'll have a look at the i.MX25, i.MX31 and i.MX35 reference manuals, but at most that will only tell me if they have the same problem as i.MX27 has about ROM/RAM and low/high vectors; it probably won't tell me how their ROM code handles exceptions. Best regards, Stefano Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6sabresd: Move the DCD settings to spl code
Hi Nikolay, On Fri, Nov 14, 2014 at 9:48 AM, Nikolay Dimitrov picmas...@mail.bg wrote: Hi Fabio, On 11/13/2014 11:58 PM, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com mx6sabresd_spl.cfg configures CCM registers, GPR registers and CCM_CCOSR. Move the configuration to the spl code. I forgot to asker earlier, but what are the benefits of going from DCD to SPL code to provide HW initialization? We already went through the hard part of removing the DDR settings from DCD in the SPL case. Now all is left is a few register writes that could be better placed into SPL code. Some advantages: - Shorter and cleaner code - see the stat diff of this series. This will avoid lots of duplication of the same spl DCD settings for several boards. - Do all the register settings in C rather than in a static DCD table. Easier to maintain and provide future changes. - We really don't need to do such simple register settings from DCD ;-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] imx: fix exception vectors relocation in imx27
I'll have a look at the i.MX25, i.MX31 and i.MX35 reference manuals, but at most that will only tell me if they have the same problem as i.MX27 has about ROM/RAM and low/high vectors; it probably won't tell me how their ROM code handles exceptions. According to the i.MX25, i.MX31 and i.MX35 RM, all three SoCs have ROM at address 0x and no RAM at address 0x, so they most certainly have the same kind of issue as i.MX27, but there is no indication that the indirect vectors table is always the same, and it is quite probable that it is located at a different place for each SoC. So in order to solve the issue, we would need a dump (or better yet a disassembly) of ROM addresses 0x to 0x001F for each of the three SoCs. Best regards, Stefano Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6sabresd: Move the DCD settings to spl code
Hi Fabio, On 11/14/2014 01:57 PM, Fabio Estevam wrote: Hi Nikolay, On Fri, Nov 14, 2014 at 9:48 AM, Nikolay Dimitrov picmas...@mail.bg wrote: Hi Fabio, On 11/13/2014 11:58 PM, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com mx6sabresd_spl.cfg configures CCM registers, GPR registers and CCM_CCOSR. Move the configuration to the spl code. I forgot to asker earlier, but what are the benefits of going from DCD to SPL code to provide HW initialization? We already went through the hard part of removing the DDR settings from DCD in the SPL case. Now all is left is a few register writes that could be better placed into SPL code. Some advantages: - Shorter and cleaner code - see the stat diff of this series. This will avoid lots of duplication of the same spl DCD settings for several boards. - Do all the register settings in C rather than in a static DCD table. Easier to maintain and provide future changes. - We really don't need to do such simple register settings from DCD ;-) OK, understood. Thanks, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mcf: Fix cppcheck errors about uninitialized variables
Hello Alison, On Fri, 14 Nov 2014 14:56:12 +0800, Alison Wang b18...@freescale.com wrote: This patch will initialize the variables to fix the cppcheck errors as follows. [arch/m68k/cpu/mcf5227x/speed.c:89]: (error) Uninitialized variable: bootmode [arch/m68k/cpu/mcf532x/speed.c:248]: (error) Uninitialized variable: fout [arch/m68k/cpu/mcf5445x/speed.c:194]: (error) Uninitialized variable: bootmode Signed-off-by: Alison Wang alison.w...@freescale.com --- arch/m68k/cpu/mcf5227x/speed.c | 2 +- arch/m68k/cpu/mcf532x/speed.c | 3 ++- arch/m68k/cpu/mcf5445x/speed.c | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/m68k/cpu/mcf5227x/speed.c b/arch/m68k/cpu/mcf5227x/speed.c index 44de4a6..e991cd1 100644 --- a/arch/m68k/cpu/mcf5227x/speed.c +++ b/arch/m68k/cpu/mcf5227x/speed.c @@ -74,7 +74,7 @@ int get_clocks(void) ccm_t *ccm = (ccm_t *)MMAP_CCM; pll_t *pll = (pll_t *)MMAP_PLL; int vco, temp, pcrvalue, pfdr; - u8 bootmode; + u8 bootmode = 0; If you set bootmode to the default 0 value at declaration, then the code that follows in the source file can be simplified: u8 bootmode = 0; ---8--- pcrvalue = in_be32(pll-pcr) 0xFF0F0FFF; pfdr = pcrvalue 24; if (pfdr == 0x1E) bootmode = 0; /* Normal Mode */ ---8--- The part between scissors is useless now, and in turn, pfdr becomes unneeded. pcrvalue = in_be32(pll-pcr) 0xFF0F0FFF; pfdr = pcrvalue 24; diff --git a/arch/m68k/cpu/mcf532x/speed.c b/arch/m68k/cpu/mcf532x/speed.c index a440bbb..0495b16 100644 --- a/arch/m68k/cpu/mcf532x/speed.c +++ b/arch/m68k/cpu/mcf532x/speed.c @@ -143,7 +143,8 @@ int clock_pll(int fsys, int flags) #endif sdram_t *sdram = (sdram_t *)(MMAP_SDRAM); pll_t *pll = (pll_t *)(MMAP_PLL); - int fref, temp, fout, mfd; + int fref, temp, mfd; + int fout = 0; u32 i; (haven't checked if similar reductions can be done) fref = FREF; diff --git a/arch/m68k/cpu/mcf5445x/speed.c b/arch/m68k/cpu/mcf5445x/speed.c index 4e363a4..a166dcc 100644 --- a/arch/m68k/cpu/mcf5445x/speed.c +++ b/arch/m68k/cpu/mcf5445x/speed.c @@ -141,7 +141,7 @@ void setup_5445x_clocks(void) #ifdef CONFIG_M54455EVB u8 *cpld = (u8 *)(CONFIG_SYS_CS2_BASE + 3); #endif - u8 bootmode; + u8 bootmode = 0; (ditto) /* To determine PCI is present or not */ if (((in_be16(ccm-ccr) CCM_CCR_360_FBCONFIG_MASK) == 0x00e0) || -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Enable I2C5 operation
Unlike regular OMAP5, on the DRA7xx SoCs the I2C5 module belongs to
the IPU clock domain. This patch takes care of the appropriate clock
preparation and makes I2C5 operational - it fixes the 'data abort'
exception that otherwise happened upon accessing the I2C5 controller.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
arch/arm/cpu/armv7/omap5/hw_data.c |9 +
arch/arm/cpu/armv7/omap5/prcm-regs.c |4
arch/arm/include/asm/omap_common.h |4
3 files changed, 17 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 0257383..5f7b392 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -515,6 +515,10 @@ void enable_basic_clocks(void)
void enable_basic_uboot_clocks(void)
{
u32 const clk_domains_essential[] = {
+#ifdef CONFIG_DRA7XX
+ /* Needed for I2C5 operation */
+ (*prcm)-cm_ipu_clkstctrl,
+#endif
0
};
@@ -528,7 +532,12 @@ void enable_basic_uboot_clocks(void)
(*prcm)-cm_l4per_i2c2_clkctrl,
(*prcm)-cm_l4per_i2c3_clkctrl,
(*prcm)-cm_l4per_i2c4_clkctrl,
+#ifdef CONFIG_DRA7XX
+ /* I2C5 is in the IPU clock domain on the DRA7xx */
+ (*prcm)-cm_ipu_i2c5_clkctrl,
+#else
(*prcm)-cm_l4per_i2c5_clkctrl,
+#endif
(*prcm)-cm_l3init_hsusbhost_clkctrl,
(*prcm)-cm_l3init_fsusb_clkctrl,
0
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index ff08ef4..1337198 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -808,6 +808,10 @@ struct prcm_regs const dra7xx_prcm = {
/* cm1.dsp */
.cm_dsp_clkstctrl = 0x4a005400,
.cm_dsp_dsp_clkctrl = 0x4a005420,
+
+ /* cm1.ipu */
+ .cm_ipu_clkstctrl = 0x4a005540,
+ .cm_ipu_i2c5_clkctrl= 0x4a005578,
/* prm irqstatus regs */
.prm_irqstatus_mpu_2= 0x4ae06014,
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 1838234..962c8a5 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -80,6 +80,10 @@ struct prcm_regs {
u32 cm_dsp_clkstctrl;
u32 cm_dsp_dsp_clkctrl;
+ /* cm1.ipu */
+ u32 cm_ipu_clkstctrl;
+ u32 cm_ipu_i2c5_clkctrl;
+
/* cm1.abe */
u32 cm1_abe_clkstctrl;
u32 cm1_abe_l4abe_clkctrl;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Enable I2C4 and I2C5 usage on the J6Eco EVM
On the J6Eco EVM we have two on-board devices on the I2C5 bus; this
bus is also routed to the camera and expansion connectors. I2C4 is
routed to one of the expansion connectors. This patch enables usage
of these two buses.
For I2C5 to work, the 'ARM: OMAP5: DRA7xx: Enable I2C5 operation'
patch is required as a prerequisite.
Tested on a J6 ECO EVM rev.B with a DRA726 ES1.0.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
board/ti/dra7xx/evm.c |7 +++
board/ti/dra7xx/mux_data.h |8
2 files changed, 15 insertions(+)
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 37df7b2..25dae8e 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -124,6 +124,13 @@ void set_muxconf_regs_essential(void)
core_padconf_array_essential,
sizeof(core_padconf_array_essential) /
sizeof(struct pad_conf_entry));
+
+ if (omap_revision() == DRA722_ES1_0) {
+ do_set_mux32((*ctrl)-control_padconf_core_base,
+core_padconf_array_j6ecoevm,
+sizeof(core_padconf_array_j6ecoevm) /
+sizeof(struct pad_conf_entry));
+ }
}
#if !defined(CONFIG_SPL_BUILD) defined(CONFIG_GENERIC_MMC)
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 4824077..f155f65 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -141,4 +141,12 @@ const struct pad_conf_entry core_padconf_array_essential[]
= {
{USB2_DRVVBUS, (M0 | IEN | FSC) },
{SPI1_CS1, (PEN | IDIS | M14) },
};
+
+const struct pad_conf_entry core_padconf_array_j6ecoevm[] = {
+ {MCASP1_AXR0, (IEN | PTU | PDIS | M10)},/* I2C5_SDA */
+ {MCASP1_AXR1, (IEN | PTU | PDIS | M10)},/* I2C5_SCL */
+
+ {MCASP4_ACLKX, (IEN | PTU | PDIS | M4)},/* I2C4_SDA */
+ {MCASP4_FSX, (IEN | PTU | PDIS | M4)}, /* I2C4_SCL */
+};
#endif /* _MUX_DATA_DRA7XX_H_ */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6sabresd: Move the DCD settings to spl code
Hi Nikolay, On 14/11/2014 13:22, Nikolay Dimitrov wrote: Hi Fabio, On 11/14/2014 01:57 PM, Fabio Estevam wrote: Hi Nikolay, On Fri, Nov 14, 2014 at 9:48 AM, Nikolay Dimitrov picmas...@mail.bg wrote: Hi Fabio, On 11/13/2014 11:58 PM, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com mx6sabresd_spl.cfg configures CCM registers, GPR registers and CCM_CCOSR. Move the configuration to the spl code. I forgot to asker earlier, but what are the benefits of going from DCD to SPL code to provide HW initialization? We already went through the hard part of removing the DDR settings from DCD in the SPL case. Now all is left is a few register writes that could be better placed into SPL code. Some advantages: - Shorter and cleaner code - see the stat diff of this series. This will avoid lots of duplication of the same spl DCD settings for several boards. - Do all the register settings in C rather than in a static DCD table. Easier to maintain and provide future changes. - We really don't need to do such simple register settings from DCD ;-) There is another advantage: it is possible to provide a single binary for boards that can mount different processor,sucs as MX6Q or MX6DL. Due to different layout, the registers are not the same, and the DCD is, of course, fix. With SPL we are able to detect at runtime the SOC and set the registers consequently. With DCD, we need to rebuild U-Boot and deliver different binaries - that is also confusing for the end customer. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mcf: Fix cppcheck errors about uninitialized variables
Dear Albert, In message 20141114134733.01c82023@lilith you wrote: - u8 bootmode; + u8 bootmode = 0; If you set bootmode to the default 0 value at declaration, then the code that follows in the source file can be simplified: u8 bootmode = 0; ---8--- pcrvalue = in_be32(pll-pcr) 0xFF0F0FFF; pfdr = pcrvalue 24; if (pfdr == 0x1E) bootmode = 0; /* Normal Mode */ ---8--- The part between scissors is useless now, and in turn, pfdr becomes unneeded. Exactly. This was my concern, too - otherwise I had provided auch a trivial fix. But I think here some deeper understanding of the intended logic is needed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Brain: an apparatus with which we think we think.- Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] imx: fix exception vectors relocation in imx27
Hi Albert, On 14/11/2014 13:10, Albert ARIBAUD wrote: I'll have a look at the i.MX25, i.MX31 and i.MX35 reference manuals, but at most that will only tell me if they have the same problem as i.MX27 has about ROM/RAM and low/high vectors; it probably won't tell me how their ROM code handles exceptions. According to the i.MX25, i.MX31 and i.MX35 RM, all three SoCs have ROM at address 0x and no RAM at address 0x, so they most certainly have the same kind of issue as i.MX27, but there is no indication that the indirect vectors table is always the same, and it is quite probable that it is located at a different place for each SoC. So in order to solve the issue, we would need a dump (or better yet a disassembly) of ROM addresses 0x to 0x001F for each of the three SoCs. ok - I have a MX35 based board, and I can do some tests, maybe in the week-end. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] exynos: Enable config_distro_defaults.h
Hi, I successfully tested it on my arndale board. Tested-by: Guillaume GARDET guillaume.gar...@free.fr Guillaume Le 09/11/2014 11:44, Ian Campbell a écrit : From: Ian Campbell ian.campb...@citrix.com ...and remove explicit setting of things which this implies. This is done for all exynos platforms (4 5) so it is added to exynos-common.h I'm mainly interested in CONFIG_CMD_BOOTZ and CONFIG_SUPPORT_RAW_INITRD I have build tested on all exynos platforms (MAKEALL -s exynos), but only boot tested on arndale. Signed-off-by: Ian Campbell ian.campb...@citrix.com Reviewed-by: Simon Glass s...@chromium.org --- include/configs/arndale.h| 2 -- include/configs/exynos-common.h | 13 ++--- include/configs/exynos5-common.h | 11 --- 3 files changed, 2 insertions(+), 24 deletions(-) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index f9ee40f..a87806d 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -17,8 +17,6 @@ /* allow to overwrite serial and ethaddr */ #define CONFIG_ENV_OVERWRITE -#define CONFIG_CMD_EXT2 - /* USB */ #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_EXYNOS diff --git a/include/configs/exynos-common.h b/include/configs/exynos-common.h index b258cb9..1246305 100644 --- a/include/configs/exynos-common.h +++ b/include/configs/exynos-common.h @@ -30,9 +30,6 @@ #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_BOARD_EARLY_INIT_F -/* Enable fdt support */ -#define CONFIG_OF_LIBFDT - /* Keep L2 Cache Disabled */ #define CONFIG_CMD_CACHE @@ -42,7 +39,6 @@ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_CMDLINE_TAG #define CONFIG_INITRD_TAG -#define CONFIG_CMDLINE_EDITING #define CONFIG_ENV_OVERWRITE /* Size of malloc() pool before and after relocation */ @@ -61,7 +57,6 @@ #define CONFIG_EXYNOS_DWMMC #define CONFIG_BOUNCE_BUFFER -#define CONFIG_BOOTDELAY 3 #define CONFIG_ZERO_BOOTDELAY_CHECK /* PWM */ @@ -71,20 +66,14 @@ #include config_cmd_default.h #define CONFIG_CMD_MMC -#define CONFIG_CMD_EXT4 #define CONFIG_CMD_EXT4_WRITE -#define CONFIG_CMD_FAT #define CONFIG_FAT_WRITE #define CONFIG_CMD_FS_GENERIC -#define CONFIG_DOS_PARTITION -#define CONFIG_EFI_PARTITION #define CONFIG_CMD_PART #define CONFIG_PARTITION_UUIDS /* Miscellaneous configurable options */ -#define CONFIG_SYS_LONGHELP/* undef to save memory */ -#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */ #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ #define CONFIG_SYS_PBSIZE 384 /* Print Buffer Size */ #define CONFIG_SYS_MAXARGS16 /* max number of command args */ @@ -96,4 +85,6 @@ #define CONFIG_SYS_NO_FLASH #undef CONFIG_CMD_IMLS +#include config_distro_defaults.h + #endif/* __CONFIG_H */ diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index ba591e7..b03966d 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -55,9 +55,6 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ EXYNOS_DEVICE_SETTINGS -#define CONFIG_CMD_PING -#define CONFIG_CMD_ELF -#define CONFIG_CMD_NET #define CONFIG_CMD_HASH /* Thermal Management Unit */ @@ -174,12 +171,6 @@ #define CONFIG_ENV_SROM_BANK 1 #endif /*CONFIG_CMD_NET*/ -/* Enable PXE Support */ -#ifdef CONFIG_CMD_NET -#define CONFIG_CMD_PXE -#define CONFIG_MENU -#endif - /* SHA hashing */ #define CONFIG_CMD_HASH #define CONFIG_HASH_VERIFY @@ -189,8 +180,6 @@ /* Enable Time Command */ #define CONFIG_CMD_TIME -#define CONFIG_CMD_BOOTZ - #define CONFIG_CMD_GPIO /* USB boot mode */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] imx: consolidate set_chipselect_size function
From: Fabio Estevam fabio.este...@freescale.com
Move MX5 specific set_chipselect_size function into generic i.MX part,
such that MX6 based boards are able to use this function as well.
While doing this the iomuxc gpr member needed to be consolidated between
MX5 and MX6.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/cpu/armv7/mx5/soc.c | 31 ---
arch/arm/imx-common/cpu.c | 31 +++
arch/arm/include/asm/arch-imx/cpu.h | 5 +
arch/arm/include/asm/arch-mx5/imx-regs.h | 12 ++--
arch/arm/include/asm/arch-mx6/sys_proto.h | 1 +
5 files changed, 39 insertions(+), 41 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx5/soc.c b/arch/arm/cpu/armv7/mx5/soc.c
index 2d53669..3753c14 100644
--- a/arch/arm/cpu/armv7/mx5/soc.c
+++ b/arch/arm/cpu/armv7/mx5/soc.c
@@ -85,37 +85,6 @@ void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
}
#endif
-void set_chipselect_size(int const cs_size)
-{
- unsigned int reg;
- struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
- reg = readl(iomuxc_regs-gpr1);
-
- switch (cs_size) {
- case CS0_128:
- reg = ~0x7;/* CS0=128MB, CS1=0, CS2=0, CS3=0 */
- reg |= 0x5;
- break;
- case CS0_64M_CS1_64M:
- reg = ~0x3F; /* CS0=64MB, CS1=64MB, CS2=0, CS3=0 */
- reg |= 0x1B;
- break;
- case CS0_64M_CS1_32M_CS2_32M:
- reg = ~0x1FF; /* CS0=64MB, CS1=32MB, CS2=32MB, CS3=0 */
- reg |= 0x4B;
- break;
- case CS0_32M_CS1_32M_CS2_32M_CS3_32M:
- reg = ~0xFFF; /* CS0=32MB, CS1=32MB, CS2=32MB, CS3=32MB */
- reg |= 0x249;
- break;
- default:
- printf(Unknown chip select size: %d\n, cs_size);
- break;
- }
-
- writel(reg, iomuxc_regs-gpr1);
-}
-
#ifdef CONFIG_MX53
void boot_mode_apply(unsigned cfg_val)
{
diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index 09fc227..24740b8 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -187,3 +187,34 @@ void arch_preboot_os(void)
ipuv3_fb_shutdown();
}
#endif
+
+void set_chipselect_size(int const cs_size)
+{
+ unsigned int reg;
+ struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
+ reg = readl(iomuxc_regs-gpr[1]);
+
+ switch (cs_size) {
+ case CS0_128:
+ reg = ~0x7;/* CS0=128MB, CS1=0, CS2=0, CS3=0 */
+ reg |= 0x5;
+ break;
+ case CS0_64M_CS1_64M:
+ reg = ~0x3F; /* CS0=64MB, CS1=64MB, CS2=0, CS3=0 */
+ reg |= 0x1B;
+ break;
+ case CS0_64M_CS1_32M_CS2_32M:
+ reg = ~0x1FF; /* CS0=64MB, CS1=32MB, CS2=32MB, CS3=0 */
+ reg |= 0x4B;
+ break;
+ case CS0_32M_CS1_32M_CS2_32M_CS3_32M:
+ reg = ~0xFFF; /* CS0=32MB, CS1=32MB, CS2=32MB, CS3=32MB */
+ reg |= 0x249;
+ break;
+ default:
+ printf(Unknown chip select size: %d\n, cs_size);
+ break;
+ }
+
+ writel(reg, iomuxc_regs-gpr[1]);
+}
diff --git a/arch/arm/include/asm/arch-imx/cpu.h
b/arch/arm/include/asm/arch-imx/cpu.h
index a3cc96f..254136e 100644
--- a/arch/arm/include/asm/arch-imx/cpu.h
+++ b/arch/arm/include/asm/arch-imx/cpu.h
@@ -12,3 +12,8 @@
#define MXC_CPU_MX6Q 0x63
#define MXC_CPU_MX6D 0x64
#define MXC_CPU_MX6SOLO0x65 /* dummy ID */
+
+#define CS0_1280
+#define CS0_64M_CS1_64M1
+#define CS0_64M_CS1_32M_CS2_32M2
+#define CS0_32M_CS1_32M_CS2_32M_CS3_32M3
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 054c680..f059d0f 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -202,11 +202,6 @@
*/
#define WBED 1
-#define CS0_1280
-#define CS0_64M_CS1_64M1
-#define CS0_64M_CS1_32M_CS2_32M2
-#define CS0_32M_CS1_32M_CS2_32M_CS3_32M3
-
/*
* CSPI register definitions
*/
@@ -414,8 +409,7 @@ struct weim {
#if defined(CONFIG_MX51)
struct iomuxc {
- u32 gpr0;
- u32 gpr1;
+ u32 gpr[2];
u32 omux0;
u32 omux1;
u32 omux2;
@@ -424,9 +418,7 @@ struct iomuxc {
};
#elif defined(CONFIG_MX53)
struct iomuxc {
- u32 gpr0;
- u32 gpr1;
- u32 gpr2;
+ u32 gpr[3];
u32 omux0;
u32 omux1;
u32 omux2;
diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h
Re: [U-Boot] [PATCH v3 2/3] exynos5: Use config_distro_bootcmd.h
Hi, I successfully tested it on my arndale board. Tested-by: Guillaume GARDET guillaume.gar...@free.fr Guillaume Le 09/11/2014 11:44, Ian Campbell a écrit : From: Ian Campbell ian.campb...@citrix.com This replaces the existing CONFIG_BOOTCOMMAND for exynos5250 and 5420. exynos4 platforms seem to have existing complex extra env configuration for booting and so are excluded here. Hence the bootcmd.h is added to exynos5-common.h. I have build tested on all exynos platforms (MAKEALL -s exynos), but only boot tested on arndale. Signed-off-by: Ian Campbell ian.campb...@citrix.com Reviewed-by: Simon Glass s...@chromium.org --- include/configs/arndale.h | 3 +++ include/configs/exynos5-common.h| 45 ++--- include/configs/exynos5-dt-common.h | 17 ++ include/configs/exynos5250-common.h | 2 -- include/configs/exynos5420-common.h | 2 -- 5 files changed, 47 insertions(+), 22 deletions(-) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index a87806d..919729d 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -9,6 +9,9 @@ #ifndef __CONFIG_ARNDALE_H #define __CONFIG_ARNDALE_H +#define EXYNOS_FDTFILE_SETTING \ + fdtfile=exynos5250-arndale.dtb\0 + #include exynos5250-common.h /* SD/MMC configuration */ diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index b03966d..8f9b780 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -47,14 +47,6 @@ #define CONFIG_SYS_CONSOLE_IS_IN_ENV #define CONFIG_CONSOLE_MUX -#define EXYNOS_DEVICE_SETTINGS \ - stdin=serial\0 \ - stdout=serial\0 \ - stderr=serial\0 - -#define CONFIG_EXTRA_ENV_SETTINGS \ - EXYNOS_DEVICE_SETTINGS - #define CONFIG_CMD_HASH /* Thermal Management Unit */ @@ -192,4 +184,41 @@ #define CONFIG_FIT #define CONFIG_FIT_BEST_MATCH + +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 1) \ + func(MMC, mmc, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) + +#include config_distro_bootcmd.h + +#ifndef MEM_LAYOUT_ENV_SETTINGS +/* 2GB RAM, bootm size of 256M, load scripts after that */ +#define MEM_LAYOUT_ENV_SETTINGS \ + bootm_size=0x1000\0 \ + kernel_addr_r=0x4200\0 \ + fdt_addr_r=0x4300\0 \ + ramdisk_addr_r=0x4330\0 \ + scriptaddr=0x5000\0 \ + pxefile_addr_r=0x5100\0 +#endif + +#ifndef EXYNOS_DEVICE_SETTINGS +#define EXYNOS_DEVICE_SETTINGS \ + stdin=serial\0 \ + stdout=serial\0 \ + stderr=serial\0 +#endif + +#ifndef EXYNOS_FDTFILE_SETTING +#define EXYNOS_FDTFILE_SETTING +#endif + +#define CONFIG_EXTRA_ENV_SETTINGS \ + EXYNOS_DEVICE_SETTINGS \ + EXYNOS_FDTFILE_SETTING \ + MEM_LAYOUT_ENV_SETTINGS \ + BOOTENV + #endif/* __CONFIG_EXYNOS5_COMMON_H */ diff --git a/include/configs/exynos5-dt-common.h b/include/configs/exynos5-dt-common.h index 66547fa..9cef0b0 100644 --- a/include/configs/exynos5-dt-common.h +++ b/include/configs/exynos5-dt-common.h @@ -9,6 +9,13 @@ #ifndef __CONFIG_EXYNOS5_DT_COMMON_H #define __CONFIG_EXYNOS5_DT_COMMON_H +/* Console configuration */ +#undef EXYNOS_DEVICE_SETTINGS +#define EXYNOS_DEVICE_SETTINGS \ + stdin=serial,cros-ec-keyb\0 \ + stdout=serial,lcd\0 \ + stderr=serial,lcd\0 + #include exynos5-common.h /* PMIC */ @@ -22,14 +29,4 @@ #define CONFIG_CMD_CROS_EC #define CONFIG_KEYBOARD -/* Console configuration */ -#undef EXYNOS_DEVICE_SETTINGS -#define EXYNOS_DEVICE_SETTINGS \ - stdin=serial,cros-ec-keyb\0 \ - stdout=serial,lcd\0 \ - stderr=serial,lcd\0 - -#define CONFIG_EXTRA_ENV_SETTINGS \ - EXYNOS_DEVICE_SETTINGS - #endif diff --git a/include/configs/exynos5250-common.h b/include/configs/exynos5250-common.h index 713614f..a0107e8 100644 --- a/include/configs/exynos5250-common.h +++ b/include/configs/exynos5250-common.h @@ -29,8 +29,6 @@ #define CONFIG_SPL_TEXT_BASE 0x02023400 -#define CONFIG_BOOTCOMMAND mmc read 40007000 451 2000; bootm 40007000 - #define CONFIG_IRAM_STACK 0x0205 #define CONFIG_SYS_INIT_SP_ADDR CONFIG_IRAM_STACK diff --git a/include/configs/exynos5420-common.h b/include/configs/exynos5420-common.h index b0f940c..3cf9f01 100644 --- a/include/configs/exynos5420-common.h +++ b/include/configs/exynos5420-common.h @@ -44,8 +44,6 @@ #define CONFIG_BOARD_REV_GPIO_COUNT 2 -#define CONFIG_BOOTCOMMAND mmc read 20007000 451 2000; bootm 20007000 - #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS2 /* ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] mx6: add weim registers
From: Fabio Estevam fabio.este...@freescale.com
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/include/asm/arch-mx6/imx-regs.h | 37
1 file changed, 37 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index a159309..5314298 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -332,6 +332,43 @@ extern void imx_get_mac_from_fuse(int dev_id, unsigned
char *mac);
#define SRC_SCR_CORE_3_ENABLE_OFFSET24
#define SRC_SCR_CORE_3_ENABLE_MASK (1SRC_SCR_CORE_3_ENABLE_OFFSET)
+/* WEIM registers */
+struct weim {
+ u32 cs0gcr1;
+ u32 cs0gcr2;
+ u32 cs0rcr1;
+ u32 cs0rcr2;
+ u32 cs0wcr1;
+ u32 cs0wcr2;
+
+ u32 cs1gcr1;
+ u32 cs1gcr2;
+ u32 cs1rcr1;
+ u32 cs1rcr2;
+ u32 cs1wcr1;
+ u32 cs1wcr2;
+
+ u32 cs2gcr1;
+ u32 cs2gcr2;
+ u32 cs2rcr1;
+ u32 cs2rcr2;
+ u32 cs2wcr1;
+ u32 cs2wcr2;
+
+ u32 cs3gcr1;
+ u32 cs3gcr2;
+ u32 cs3rcr1;
+ u32 cs3rcr2;
+ u32 cs3wcr1;
+ u32 cs3wcr2;
+
+ u32 unused[12];
+
+ u32 wcr;
+ u32 wiar;
+ u32 ear;
+};
+
/* System Reset Controller (SRC) */
struct src {
u32 scr;
--
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] mx6qsabreauto: Add parallel NOR flash support
From: Fabio Estevam fabio.este...@freescale.com
mx6sabreauto boards come with 32 MiB of parallel NOR flash.
Add support for it:
U-Boot 2015.01-rc1-18107-g1543636-dirty (Nov 14 2014 - 11:11:04)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: MX6Q-Sabreauto revA
I2C: ready
DRAM: 2 GiB
Flash: 32 MiB
NAND: 0 MiB
Due to pin conflict with I2C3, only define configure I2C3 IOMUX when flash is
not used.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6qsabreauto/mx6qsabreauto.c | 80 ++-
include/configs/mx6qsabreauto.h | 10
2 files changed, 89 insertions(+), 1 deletion(-)
diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
index c35dcaf..15df171 100644
--- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
+++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
@@ -53,6 +53,10 @@ DECLARE_GLOBAL_DATA_PTR;
#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+#define WEIM_NOR_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
+ PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+
int dram_init(void)
{
gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -97,6 +101,7 @@ static struct i2c_pads_info i2c_pad_info1 = {
}
};
+#ifndef CONFIG_SYS_FLASH_CFI
/*
* I2C3 MLB, Port Expanders (A, B, C), Video ADC, Light Sensor,
* Compass Sensor, Accelerometer, Res Touch
@@ -113,6 +118,7 @@ static struct i2c_pads_info i2c_pad_info2 = {
.gp = IMX_GPIO_NR(3, 18)
}
};
+#endif
static iomux_v3_cfg_t const i2c3_pads[] = {
MX6_PAD_EIM_A24__GPIO5_IO04 | MUX_PAD_CTRL(NO_PAD_CTRL),
@@ -160,6 +166,75 @@ static int port_exp_direction_output(unsigned gpio, int
value)
return 0;
}
+static iomux_v3_cfg_t const eimnor_pads[] = {
+ MX6_PAD_EIM_D16__EIM_DATA16 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D17__EIM_DATA17 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D18__EIM_DATA18 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D19__EIM_DATA19 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D20__EIM_DATA20 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D21__EIM_DATA21 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D22__EIM_DATA22 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D23__EIM_DATA23 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D24__EIM_DATA24 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D25__EIM_DATA25 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D26__EIM_DATA26 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D27__EIM_DATA27 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D28__EIM_DATA28 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D29__EIM_DATA29 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D30__EIM_DATA30 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_D31__EIM_DATA31 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA0__EIM_AD00 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA1__EIM_AD01 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA2__EIM_AD02 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA3__EIM_AD03 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA4__EIM_AD04 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA5__EIM_AD05 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA6__EIM_AD06 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA7__EIM_AD07 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA8__EIM_AD08 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA9__EIM_AD09 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA10__EIM_AD10 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA11__EIM_AD11 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL) ,
+ MX6_PAD_EIM_DA12__EIM_AD12 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA13__EIM_AD13 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA14__EIM_AD14 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_DA15__EIM_AD15 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_A16__EIM_ADDR16 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+ MX6_PAD_EIM_A17__EIM_ADDR17 | MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL),
+
Re: [U-Boot] [PATCH] ubi: reset relevant globals in ubi_exit()
On 11/14/2014 12:20 AM, Heiko Schocher wrote: Good catch, but wondering, why this not poped up in my tests, as I did such a test ... Are you on 2014.10? I don't think this issue existed on the 2014.07-rc3 I was using earlier. - Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] .travis.yml: build u-boot on travis-ci
---
Changes for v2:
- use latest device tree compiler (suggested by Daniel Schwierzeck)
- add sandbox (suggested by Daniel Schwierzeck)
- seperate echo and execution of TEST_CMD
- remove BUILD_NCPUS( part of script)
- introduce ${TEST_CONFIG_CMD}
- add libsdl-dev package which is required by sandbox
- use buildman (suggested by Tom Rini)
- generate ~/.buildman
- split ppc into several jobs
- install gcc-arm-linux-gnueabihf
- use --inline-suppr option for cppcheck
Signed-off-by: Roger Meier r.me...@siemens.com
Cc: Wolfgang Denk w...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
.travis.yml | 148 +++
1 file changed, 148 insertions(+)
create mode 100644 .travis.yml
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..7488a3f
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,148 @@
+# Copyright Roger Meier r.me...@siemens.com
+# SPDX-License-Identifier: GPL-2.0+
+
+# build U-Boot on Travis CI - https://travis-ci.org/
+
+language: c
+
+cache:
+ - apt
+
+install:
+ # install U-Boot build dependencies
+ - sudo apt-get install -qq cppcheck sloccount sparse bc libsdl-dev
gcc-arm-linux-gnueabi gcc-arm-linux-gnueabihf
+ # install latest device tree compiler
+ - git clone --depth=1 https://git.kernel.org/pub/scm/utils/dtc/dtc.git
/tmp/dtc
+ - make -j4 -C /tmp/dtc
+ # prepare buildman environment
+ - export BUILDMAN_ROOT=root:
+ - export BUILDMAN_MIPS=mips:
+ - export BUILDMAN_PPC=ppc:
+ - echo -e [toolchain]\\n${BUILDMAN_ROOT} /\n ~/.buildman
+ - echo -e ${BUILDMAN_MIPS}
/opt/eldk-5.4/mips/sysroots/i686-eldk-linux/usr/bin/mips32-linux/
~/.buildman
+ - echo -e ${BUILDMAN_PPC}
/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/
~/.buildman
+ - export BUILDMAN_ALIAS=x86:
+ - echo -e [toolchain-alias]\\n${BUILDMAN_ALIAS} i386 ~/.buildman
+ - cat ~/.buildman
+
+env:
+ global:
+- PATH=$PATH:/tmp/dtc
+- BUILD_DIR=build
+- CROSS_COMPILE=
+- HOSTCC=cc
+- HOSTCXX=c++
+- TEST_CONFIG_CMD=
+
+before_script:
+ # install toolchains based on INSTALL_TOOLCHAIN} variable
+ - if [[ ${INSTALL_TOOLCHAIN} == *ppc* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/powerpc/eldk-eglibc-i686-powerpc-toolchain-gmae-5.4.sh
; fi
+ - if [[ ${INSTALL_TOOLCHAIN} == *ppc* ]]; then sh
eldk-eglibc-i686-powerpc-toolchain-gmae-5.4.sh -y ; fi
+ - if [[ ${INSTALL_TOOLCHAIN} == *mips* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/mips/eldk-eglibc-i686-mips-toolchain-gmae-5.4.sh
; fi
+ - if [[ ${INSTALL_TOOLCHAIN} == *mips* ]]; then sh
eldk-eglibc-i686-mips-toolchain-gmae-5.4.sh -y ; fi
+
+script:
+ # the execution sequence for each test
+ - echo ${TEST_CONFIG_CMD}
+ - ${TEST_CONFIG_CMD}
+ - echo ${TEST_CMD}
+ - ${TEST_CMD}
+
+matrix:
+ include:
+ # we need to build by vendor due to 50min time limit for builds
+ # each env setting here is a dedicated build
+- env:
+- TEST_CMD=./MAKEALL -a arm -v atmel
+ CROSS_COMPILE=arm-linux-gnueabi-
+- env:
+- TEST_CMD=./MAKEALL -a arm -v denx
+ CROSS_COMPILE=arm-linux-gnueabi-
+- env:
+- TEST_CMD=./MAKEALL -a arm -v freescale
+ CROSS_COMPILE=arm-linux-gnueabi-
+- env:
+- TEST_CMD=./MAKEALL -a arm -v siemens
+ CROSS_COMPILE=arm-linux-gnueabi-
+- env:
+- TEST_CMD=./MAKEALL -a arm -v ti
+ CROSS_COMPILE=arm-linux-gnueabi-
+- env:
+- TEST_CONFIG_CMD=make sandbox_defconfig
+ TEST_CMD=make -j4
+ HOSTCC = gcc
+ HOSTCXX = g++
+- env:
+- TEST_CONFIG_CMD=make sandbox_defconfig
+ TEST_CMD=make -j4
+ HOSTCC = clang
+ HOSTCXX = clang++
+- env:
+- TEST_CMD=./MAKEALL -a mips
+ INSTALL_TOOLCHAIN=mips
+
CROSS_COMPILE=/opt/eldk-5.4/mips/sysroots/i686-eldk-linux/usr/bin/mips32-linux/mips-linux-
+- env:
+- TEST_CMD=tools/buildman/buildman --list-error-boards atmel
+- env:
+- TEST_CMD=tools/buildman/buildman --list-error-boards denx
+- env:
+- TEST_CMD=tools/buildman/buildman --list-error-boards freescale arm
+- env:
+- TEST_CMD=tools/buildman/buildman --list-error-boards siemens
+- env:
+- TEST_CMD=tools/buildman/buildman --list-error-boards ti
+- env:
+- TEST_CMD=tools/buildman/buildman mips
+ INSTALL_TOOLCHAIN=mips
+- env:
+- TEST_CMD=tools/buildman/buildman mpc5xx
+ INSTALL_TOOLCHAIN=ppc
+- env:
+- TEST_CMD=tools/buildman/buildman mpc8xx
+ INSTALL_TOOLCHAIN=ppc
+- env:
+- TEST_CMD=tools/buildman/buildman mpc5xxx
+ INSTALL_TOOLCHAIN=ppc
+- env:
+- TEST_CMD=tools/buildman/buildman mpc512x
+ INSTALL_TOOLCHAIN=ppc
+- env:
+- TEST_CMD=tools/buildman/buildman mpc824x
+ INSTALL_TOOLCHAIN=ppc
+- env:
+-
Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
Hi Victor,
On 13 November 2014 09:29, Victor Ascroft victorascr...@gmail.com wrote:
Hello,
I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb build
leads to a saving of almost 1 MB for my u-boot image and consequently to
faster serial downloads I have been looking at this. Currently enabling this
option leads to a hang.
After some debugging I have narrowed the place of hang to ldr pc,
=board_init_r in arch/arm/lib/crt0.S. My debugging procedure was to put a
branch to a small function which just printed a small message with puts, just
before the ldr instruction and then a printing a small message with puts just
at the start of board_init_r in common/board_r.c . For a non thumb build, the
two messages get printed and I can boot to the u-boot prompt. For a thumb
build, only the first message before the ldr instruction gets printed.
In crt0.S
bl debug_print
ldr pc, =board_init_r
In board_init_r
puts(In board_init_r\n); // Right at start
void debug_print(void)
{
// Defined in board file
puts(Debug print\n);
}
My assembly knowledge is limited and after some consultation with a senior
colleague, he told me things to check.
An object dump of the crt0.o shows a branch to an even address. For thumb,
this is expected to be odd. To just try out, I did a change as below
ldr r3, =board_init_r
add r3, #1
bx r3
No change with this. My expectation was the compiler/linker/assembler would
take care of the requirements, with the CONFIG_SYS_THUMB_BUILD. Frankly
speaking I am not sure if this is the complete issue or only a part of it. I
have seen patches with regards to OMAP send in by Aneesh V, which made
changes of the form .type fn_name, %function to all the low level assembly
functions, but, I couldn't dig up much more or variants thereof. Basically,
from what I understand, this takes care of specifying .thumb_func for a thumb
function or so to speak.
Any pointers?
I tried this on a peach_pi (Samsung Chromebook 2 13) and it worked OK
for me. The code sequence you refer to came out as below for me.
23e01e10 clbss_l:
23e01e10: e151cmp r0, r1
23e01e14: 35802000strcc r2, [r0]
23e01e18: 3284addcc r0, r0, #4
23e01e1c: 3afbbcc 23e01e10 clbss_l
23e01e20: fa000decblx 23e055d8 coloured_LED_init
23e01e24: fb000debblx 23e055da red_led_on
23e01e28: e1a9mov r0, r9
23e01e2c: e5991030ldr r1, [r9, #48] ; 0x30
23e01e30: e59ff008ldr pc, [pc, #8]; 23e01e40
clbss_l+0x30
23e01e34: 02073800.word 0x02073800
23e01e38: 23e41eb0.word 0x23e41eb0
23e01e3c: 23e77bf0.word 0x23e77bf0
23e01e40: 23e057a9.word 0x23e057a9
The 'ldr pc' line is loading from 23e01e40 which does have an odd address.
What toolchain are you using? I tried with gcc 4.8.2 - including
linaro's 2013.10 release.
In arch/arm/cpu/armv7/config.mk there is a fallback to armv5 from
armv7-a, and this may cause it to generate Thumb code instead of Thumb
2. But you should get errors if that happens.
It's hard to debug with such limited visibility. But if I put a puts()
at the start of board_init_r(), I see it on the serial console.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Hi Albert, Thanks for the great information. Albert ARIBAUD (U-Boot) wrote Baaad, bad. The first time you change something in your code, your relocation offset might change and this will make U-Boot crash and burn in interesting ways. Just define CONFIG_SYS_TEXT_BASE to some low address and let relocation happen. You can find your actual relocation address in the global data structure. If I set CONFIG_SYS_TEXT_BASE to a low address then I can't run a memory test starting at the lowest address because that's where the U-Boot code will be. I think the best thing would be to run a memory test on the full 2GB before relocation happens. Is that possible? Albert ARIBAUD (U-Boot) wrote How do you know the lowest address used by your stack during your memory test? I know the address of the stack pointer from DEBUG message... I erroneously thought that was the beginning of the stack. The stack expands down form that address, but how much? I don't see a global data stack size variable. Before, we have #define CONFIG_STACKSIZE(128 * 1024) set in the header file. Basically what is the best way to run the memory test? If I can run it before relocation then it would make things very simple. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196181.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
On Fri, Nov 14, 2014 at 12:18 PM, DaveKucharczyk david.kucharc...@gmail.com wrote: Basically what is the best way to run the memory test? If I can run it before relocation then it would make things very simple. You could boot the kernel and then run 'memtester' overnight utility for example. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Fabio Estevam-2 wrote You could boot the kernel and then run 'memtester' overnight utility for example. Let's say that it has to run in U-Boot otherwise a test fixture would have to be redesigned. Running it as early as possible, like in U-Boot, saves a lot of time in the case of bad boards. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196183.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6sabresd: Move the DCD settings to spl code
Hi Stefano, On 11/14/2014 03:23 PM, Stefano Babic wrote: Hi Nikolay, On 14/11/2014 13:22, Nikolay Dimitrov wrote: Hi Fabio, On 11/14/2014 01:57 PM, Fabio Estevam wrote: Hi Nikolay, On Fri, Nov 14, 2014 at 9:48 AM, Nikolay Dimitrov picmas...@mail.bg wrote: Hi Fabio, On 11/13/2014 11:58 PM, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com mx6sabresd_spl.cfg configures CCM registers, GPR registers and CCM_CCOSR. Move the configuration to the spl code. I forgot to asker earlier, but what are the benefits of going from DCD to SPL code to provide HW initialization? We already went through the hard part of removing the DDR settings from DCD in the SPL case. Now all is left is a few register writes that could be better placed into SPL code. Some advantages: - Shorter and cleaner code - see the stat diff of this series. This will avoid lots of duplication of the same spl DCD settings for several boards. - Do all the register settings in C rather than in a static DCD table. Easier to maintain and provide future changes. - We really don't need to do such simple register settings from DCD ;-) There is another advantage: it is possible to provide a single binary for boards that can mount different processor,sucs as MX6Q or MX6DL. Due to different layout, the registers are not the same, and the DCD is, of course, fix. With SPL we are able to detect at runtime the SOC and set the registers consequently. With DCD, we need to rebuild U-Boot and deliver different binaries - that is also confusing for the end customer. That was a good addition. Thank you guys for taking the time to explain. Regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] Please pull u-boot-imx
Hi Tom, please pull from u-boot-imx. novena is still broken, Masahiro provides the patch for fix it. The following changes since commit 63f7af9a4cfb4a3b9136674c6612c6d13957c2cd: Merge branch 'master' of git://git.denx.de/u-boot-uniphier (2014-11-11 15:49:10 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to 05d492a3235df397da6200294ea2a802749372a8: arm: mx6: add support for TBS2910 Matrix ARM miniPC (2014-11-13 18:09:23 +0100) Christian Gmeiner (2): ot1200: add support for EHCI ot1200: fix card detect for usdhc4 Fabio Estevam (4): mx28evk: README: Revision C is also supported mx53loco: Change 'fdt_file' dynamically mx6sabresd: Fix error handling in board_mmc_init() mx6sabresd: Staticize when possible John Tobias (5): imx6: add spl config for mx6sabresd imx6: add data configuration file for SPL kconfig: imx6: add SUPPORT_SPL imx6: add spl in the header file imx6: SPL support for iMX6 SabreSD Nikita Kiryanov (1): arm: imx: make bmode command work with SPL/U-Boot combo Nikolay Dimitrov (1): mx6: video_skip: Fix crash on NULL pointer Soeren Moch (1): arm: mx6: add support for TBS2910 Matrix ARM miniPC Ye.Li (2): imx: mx6q/dl sabre_common: Move MMC ENV offset to 512KB position imx: mx6q/dlsabreauto: And NAND flash support arch/arm/Kconfig | 5 + arch/arm/cpu/armv7/mx6/soc.c | 4 +- arch/arm/imx-common/spl.c | 5 +- arch/arm/imx-common/video.c | 6 +- board/bachmann/ot1200/ot1200.c| 4 +- board/freescale/mx28evk/README| 2 +- board/freescale/mx53loco/mx53loco.c | 4 + board/freescale/mx6qsabreauto/mx6qsabreauto.c | 66 + board/freescale/mx6sabresd/mx6sabresd.c | 208 +- board/freescale/mx6sabresd/mx6sabresd_spl.cfg | 58 board/tbs/tbs2910/Kconfig | 23 ++ board/tbs/tbs2910/MAINTAINERS | 6 + board/tbs/tbs2910/Makefile| 7 + board/tbs/tbs2910/tbs2910.c | 398 ++ configs/mx6sabresd_spl_defconfig | 5 + configs/tbs2910_defconfig | 3 + include/configs/mx53loco.h| 1 - include/configs/mx6qsabreauto.h | 16 ++ include/configs/mx6sabre_common.h | 2 +- include/configs/mx6sabresd.h | 6 + include/configs/ot1200.h | 7 + include/configs/tbs2910.h | 242 22 files changed, 1056 insertions(+), 22 deletions(-) create mode 100644 board/freescale/mx6sabresd/mx6sabresd_spl.cfg create mode 100644 board/tbs/tbs2910/Kconfig create mode 100644 board/tbs/tbs2910/MAINTAINERS create mode 100644 board/tbs/tbs2910/Makefile create mode 100644 board/tbs/tbs2910/tbs2910.c create mode 100644 configs/mx6sabresd_spl_defconfig create mode 100644 configs/tbs2910_defconfig create mode 100644 include/configs/tbs2910.h Thanks, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools/msximage.c: fix warning about nptr possibly uninitialized
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
tools/mxsimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/mxsimage.c b/tools/mxsimage.c
index 81c7f2d..55e61e2 100644
--- a/tools/mxsimage.c
+++ b/tools/mxsimage.c
@@ -1416,7 +1416,7 @@ static int sb_parse_line(struct sb_image_ctx *ictx,
struct sb_cmd_list *cmd)
{
char *tok;
char *line = cmd-cmd;
- char *rptr;
+ char *rptr = NULL;
int ret;
/* Analyze the identifier on this line first. */
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Hello Dave, On Fri, 14 Nov 2014 07:18:58 -0700 (MST), DaveKucharczyk david.kucharc...@gmail.com wrote: Hi Albert, Thanks for the great information. Albert ARIBAUD (U-Boot) wrote Baaad, bad. The first time you change something in your code, your relocation offset might change and this will make U-Boot crash and burn in interesting ways. Just define CONFIG_SYS_TEXT_BASE to some low address and let relocation happen. You can find your actual relocation address in the global data structure. If I set CONFIG_SYS_TEXT_BASE to a low address then I can't run a memory test starting at the lowest address because that's where the U-Boot code will be. No, that's not where it'll be; it'll relocate as high as it can. I think the best thing would be to run a memory test on the full 2GB before relocation happens. Is that possible? Not with U-Boot in DDR. :) Albert ARIBAUD (U-Boot) wrote How do you know the lowest address used by your stack during your memory test? I know the address of the stack pointer from DEBUG message... So you know it *at a given time*, but you have no assurance that it won't go further down. I erroneously thought that was the beginning of the stack. The stack expands down form that address, but how much? I don't see a global data stack size variable. There is none physically, i.e. that's just the size you reserve for it, but it could grow beyond that, although it's not likely. Still, that means you don't test all DDR. Before, we have #define CONFIG_STACKSIZE (128 * 1024) set in the header file. Basically what is the best way to run the memory test? If I can run it before relocation then it would make things very simple. If you happen to have an SPL running from some RAM and not from DDR, then you could perform the full DDR test there. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
Hello Simon,
On Fri, 14 Nov 2014 07:01:59 -0700, Simon Glass s...@chromium.org
wrote:
Hi Victor,
On 13 November 2014 09:29, Victor Ascroft victorascr...@gmail.com wrote:
Hello,
I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb
build leads to a saving of almost 1 MB for my u-boot image and consequently
to faster serial downloads I have been looking at this. Currently enabling
this option leads to a hang.
After some debugging I have narrowed the place of hang to ldr pc,
=board_init_r in arch/arm/lib/crt0.S. My debugging procedure was to put a
branch to a small function which just printed a small message with puts,
just before the ldr instruction and then a printing a small message with
puts just at the start of board_init_r in common/board_r.c . For a non
thumb build, the two messages get printed and I can boot to the u-boot
prompt. For a thumb build, only the first message before the ldr
instruction gets printed.
In crt0.S
bl debug_print
ldr pc, =board_init_r
In board_init_r
puts(In board_init_r\n); // Right at start
void debug_print(void)
{
// Defined in board file
puts(Debug print\n);
}
My assembly knowledge is limited and after some consultation with a senior
colleague, he told me things to check.
An object dump of the crt0.o shows a branch to an even address. For thumb,
this is expected to be odd. To just try out, I did a change as below
ldr r3, =board_init_r
add r3, #1
bx r3
No change with this. My expectation was the compiler/linker/assembler would
take care of the requirements, with the CONFIG_SYS_THUMB_BUILD. Frankly
speaking I am not sure if this is the complete issue or only a part of it.
I have seen patches with regards to OMAP send in by Aneesh V, which made
changes of the form .type fn_name, %function to all the low level assembly
functions, but, I couldn't dig up much more or variants thereof. Basically,
from what I understand, this takes care of specifying .thumb_func for a
thumb function or so to speak.
Any pointers?
Victor,
In addition to Simon's question below on the toolchain, I would like to
know which commit you're trying to build.
I tried this on a peach_pi (Samsung Chromebook 2 13) and it worked OK
for me. The code sequence you refer to came out as below for me.
23e01e10 clbss_l:
23e01e10: e151cmp r0, r1
23e01e14: 35802000strcc r2, [r0]
23e01e18: 3284addcc r0, r0, #4
23e01e1c: 3afbbcc 23e01e10 clbss_l
23e01e20: fa000decblx 23e055d8 coloured_LED_init
23e01e24: fb000debblx 23e055da red_led_on
23e01e28: e1a9mov r0, r9
23e01e2c: e5991030ldr r1, [r9, #48] ; 0x30
23e01e30: e59ff008ldr pc, [pc, #8]; 23e01e40
clbss_l+0x30
23e01e34: 02073800.word 0x02073800
23e01e38: 23e41eb0.word 0x23e41eb0
23e01e3c: 23e77bf0.word 0x23e77bf0
23e01e40: 23e057a9.word 0x23e057a9
The 'ldr pc' line is loading from 23e01e40 which does have an odd address.
What toolchain are you using? I tried with gcc 4.8.2 - including
linaro's 2013.10 release.
In arch/arm/cpu/armv7/config.mk there is a fallback to armv5 from
armv7-a, and this may cause it to generate Thumb code instead of Thumb
2. But you should get errors if that happens.
It's hard to debug with such limited visibility. But if I put a puts()
at the start of board_init_r(), I see it on the serial console.
Simon,
I believe you've built crt0.S for ARM, not Thumb.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: ahci: Add a delay after enabling target power
If the target power is connected through a gpio, then give the target some time to power up before continuing with ahci / sata probing, this avoids link timeouts, without penalizing other boards where there is no target power gpio. Why 500 ms ? I started with 200, that was not enough, then I went to 500 which worked, lowering it to 350 broke things again, so 500 seems the minimum my vertex2 needs to be ready to get probed. Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/ahci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/sunxi/ahci.c b/board/sunxi/ahci.c index 5e12328..b7f0dda 100644 --- a/board/sunxi/ahci.c +++ b/board/sunxi/ahci.c @@ -76,6 +76,8 @@ void scsi_init(void) #ifdef CONFIG_SATAPWR gpio_request(CONFIG_SATAPWR, satapwr); gpio_direction_output(CONFIG_SATAPWR, 1); + /* Give attached sata device time to power-up to avoid link timeouts */ + mdelay(500); #endif if (sunxi_ahci_phy_init(SUNXI_SATA_BASE) 0) -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: ahci: Add a delay after enabling target power
On Fri, 2014-11-14 at 16:30 +0100, Hans de Goede wrote: If the target power is connected through a gpio, then give the target some time to power up before continuing with ahci / sata probing, this avoids link timeouts, without penalizing other boards where there is no target power gpio. Why 500 ms ? I started with 200, that was not enough, then I went to 500 which worked, lowering it to 350 broke things again, so 500 seems the minimum my vertex2 needs to be ready to get probed. ;-) Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] tqma6: (cosmetic) remove CONFIG_FLASH_SECTOR_SIZE
From: Markus Niebel markus.nie...@tq-group.com
This is nowhere documented and only used
by two other boards. Replace it with
TQMA6_SPI_FLASH_SECTOR_SIZE.
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
include/configs/tqma6.h | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h
index c94eee1..a099687 100644
--- a/include/configs/tqma6.h
+++ b/include/configs/tqma6.h
@@ -68,6 +68,8 @@
#define CONFIG_SPI_FLASH
#define CONFIG_SPI_FLASH_STMICRO
+#define TQMA6_SPI_FLASH_SECTOR_SIZESZ_64K
+
#define CONFIG_CMD_SF
#define CONFIG_SF_DEFAULT_BUS 0
#define CONFIG_SF_DEFAULT_CS 0
@@ -275,12 +277,10 @@
#elif defined(CONFIG_TQMA6X_SPI_BOOT)
-#define CONFIG_FLASH_SECTOR_SIZE 0x1
-
#define TQMA6_UBOOT_OFFSET 0x400
#define TQMA6_UBOOT_SECTOR_START 0x0
/* max u-boot size: 512k */
-#define TQMA6_UBOOT_SECTOR_SIZECONFIG_FLASH_SECTOR_SIZE
+#define TQMA6_UBOOT_SECTOR_SIZETQMA6_SPI_FLASH_SECTOR_SIZE
#define TQMA6_UBOOT_SECTOR_COUNT 0x8
#define TQMA6_UBOOT_SIZE (TQMA6_UBOOT_SECTOR_SIZE * \
TQMA6_UBOOT_SECTOR_COUNT)
@@ -288,7 +288,7 @@
#define CONFIG_ENV_IS_IN_SPI_FLASH
#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
#define CONFIG_ENV_OFFSET (TQMA6_UBOOT_SIZE)
-#define CONFIG_ENV_SECT_SIZE CONFIG_FLASH_SECTOR_SIZE
+#define CONFIG_ENV_SECT_SIZE TQMA6_SPI_FLASH_SECTOR_SIZE
#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + \
CONFIG_ENV_SECT_SIZE)
@@ -299,7 +299,7 @@
#define TQMA6_FDT_OFFSET (CONFIG_ENV_OFFSET_REDUND + \
CONFIG_ENV_SECT_SIZE)
-#define TQMA6_FDT_SECT_SIZE(CONFIG_FLASH_SECTOR_SIZE)
+#define TQMA6_FDT_SECT_SIZE(TQMA6_SPI_FLASH_SECTOR_SIZE)
#define TQMA6_FDT_SECTOR_START 0x0a /* 8 Sector u-boot, 2 Sector env */
#define TQMA6_FDT_SECTOR_COUNT 0x01
@@ -320,7 +320,7 @@
setexpr blkc ${filesize} + \
__stringify(TQMA6_UBOOT_OFFSET) ;\
setexpr size ${uboot_sectors} * \
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
if itest ${blkc} = ${size}; then\
sf probe;\
sf erase 0 ${size}; \
@@ -332,9 +332,9 @@
update_kernel=run kernel_name; if tftp ${kernel}; then \
if itest ${filesize} 0; then \
setexpr size ${kernel_sectors} * \
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
setexpr offset ${kernel_start} * \
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
if itest ${filesize} = ${size}; then\
sf probe;\
sf erase ${offset} ${size}; \
@@ -346,9 +346,9 @@
update_fdt=if tftp ${fdt_file}; then \
if itest ${filesize} 0; then \
setexpr size ${fdt_sectors} *\
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
setexpr offset ${fdt_start} *\
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
if itest ${filesize} = ${size}; then\
sf probe;\
sf erase ${offset} ${size}; \
@@ -359,16 +359,16 @@
setenv filesize 0; setenv size ; setenv offset\0 \
loadimage=sf probe; \
setexpr size ${kernel_sectors} * \
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
setexpr offset ${kernel_start} *
[U-Boot] [PATCH 4/4] tqma6: use imx_ddr_size
From: Markus Niebel markus.nie...@tq-group.com
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
board/tqc/tqma6/tqma6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
index b7f4eb7..e480d57 100644
--- a/board/tqc/tqma6/tqma6.c
+++ b/board/tqc/tqma6/tqma6.c
@@ -51,7 +51,7 @@ DECLARE_GLOBAL_DATA_PTR;
int dram_init(void)
{
- gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
+ gd-ram_size = imx_ddr_size();
return 0;
}
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] tqma6: add warning on failed setup_i2c
From: Markus Niebel markus.nie...@tq-group.com
setup_i2c has a return value. Use it to give feedback
on error.
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
board/tqc/tqma6/tqma6.c | 10 --
board/tqc/tqma6/tqma6_mba6.c | 10 --
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
index 5e913d7..b7f4eb7 100644
--- a/board/tqc/tqma6/tqma6.c
+++ b/board/tqc/tqma6/tqma6.c
@@ -181,8 +181,14 @@ static struct i2c_pads_info tqma6_i2c3_pads = {
static void tqma6_setup_i2c(void)
{
- /* use logical index for bus, e.g. I2C1 - 0 */
- setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, tqma6_i2c3_pads);
+ int ret;
+ /*
+* use logical index for bus, e.g. I2C1 - 0
+* warn on error
+*/
+ ret = setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, tqma6_i2c3_pads);
+ if (ret)
+ printf(setup I2C3 failed: %d\n, ret);
}
int board_early_init_f(void)
diff --git a/board/tqc/tqma6/tqma6_mba6.c b/board/tqc/tqma6/tqma6_mba6.c
index fd59287..6f4cffd 100644
--- a/board/tqc/tqma6/tqma6_mba6.c
+++ b/board/tqc/tqma6/tqma6_mba6.c
@@ -224,8 +224,14 @@ static struct i2c_pads_info mba6_i2c1_pads = {
static void mba6_setup_i2c(void)
{
- /* use logical index for bus, e.g. I2C1 - 0 */
- setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, mba6_i2c1_pads);
+ int ret;
+ /*
+* use logical index for bus, e.g. I2C1 - 0
+* warn on error
+*/
+ ret = setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, mba6_i2c1_pads);
+ if (ret)
+ printf(setup I2C1 failed: %d\n, ret);
}
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] tqma6: add missing include
From: Markus Niebel markus.nie...@tq-group.com Add include needed to have prototype for board_spi_cs_gpio Signed-off-by: Markus Niebel markus.nie...@tq-group.com --- board/tqc/tqma6/tqma6.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c index fd1bd59..5e913d7 100644 --- a/board/tqc/tqma6/tqma6.c +++ b/board/tqc/tqma6/tqma6.c @@ -17,6 +17,7 @@ #include asm/gpio.h #include asm/io.h #include asm/imx-common/mxc_i2c.h +#include asm/imx-common/spi.h #include common.h #include fsl_esdhc.h #include libfdt.h -- 2.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] tqma6: improvements and cleanup
From: Markus Niebel markus.nie...@tq-group.com This series contains some cosmetic and code cleanups. No functional changes. Markus Niebel (4): tqma6: (cosmetic) remove CONFIG_FLASH_SECTOR_SIZE tqma6: add missing include tqma6: add warning on failed setup_i2c tqma6: use imx_ddr_size board/tqc/tqma6/tqma6.c | 13 ++--- board/tqc/tqma6/tqma6_mba6.c | 10 -- include/configs/tqma6.h | 28 ++-- 3 files changed, 32 insertions(+), 19 deletions(-) -- 2.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Albert ARIBAUD (U-Boot) wrote No, that's not where it'll be; it'll relocate as high as it can. I guess that's the confusing part. When I run with debug on I get the following log. Halfway down it reports Now running in RAM - U-Boot at: eff89000, but there are still initcall's to lower memory after that. So I'm thinking lower memory is still used at that point. Am I wrong? I did try a mem test starting at the lowest address and it worked, but I would like to understand why the initcall's to low-mem after relocation. The mem test essentially erases those addresses, so initcall's to those addresses are suspect at that point. Albert ARIBAUD (U-Boot) wrote If you happen to have an SPL running from some RAM and not from DDR, then you could perform the full DDR test there. . I think the mx53 has internal sram, which is why we were able to run fully from there before, since we had set CONFIG_SKIP_RELOCATE_UBOOT. I tried setting CONFIG_SKIP_LOWLEVEL_INIT, but nothing works with that set. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196196.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
btw, I'm using nabble to post, but notice my code snippets don't show up in the mailing list, which I assume most of you guys are using. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196197.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Dear DaveKucharczyk, In message 1415974738890-196181.p...@n7.nabble.com you wrote: If I set CONFIG_SYS_TEXT_BASE to a low address then I can't run a memory test starting at the lowest address because that's where the U-Boot code will be. If U-Boot is runnign from RAM there will always be areas where U-Boot is sitting and which cannot be tested. I think the best thing would be to run a memory test on the full 2GB before relocation happens. Is that possible? Not when running from RAM. This is only possible when running from NOR flash or from some other memory region. Once you loaded U-Boot to RAM, the RAM will be, well, it will be used, and you cannot test all of it. I erroneously thought that was the beginning of the stack. The stack expands down form that address, but how much? I don't see a global data stack size variable. The stack grows downward without bounds. There is no limit on the stack size. Before, we have #define CONFIG_STACKSIZE (128 * 1024) set in the header file. This does not do what you think it might be doing. Basically what is the best way to run the memory test? If I can run it before relocation then it would make things very simple. You have to make sure to use the right terms. Before relocation is only useful here for example for systems booting from NOR flash, where before relocation means that you are running from flash, and the whole RAM is actually not used by U-Boot at all. If you boot from NAND or SDCard or similar, you will probably load U-Boot to RAM - either though the ROM boot loader, or through SPL - and from this moment the RAM is used, and certain areas cannot be tested any more. If you use SPL, and the SPL is for example running from on-chip-memory or other kind of static memory, then you could try adding the memory test to SPL, i. e. perform the test before loading U-Boot to RAM at all. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can only live once, but if you do it right, once is enough. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] sunxi: Add video pll clock functions
This is a preparation patch for adding support for HDMI out.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/clock_sun4i.c| 27
arch/arm/cpu/armv7/sunxi/clock_sun6i.c| 29 +
arch/arm/include/asm/arch-sunxi/clock.h | 2 +
arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 45
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 59 ++-
5 files changed, 161 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
index a0e49d1..49f4032 100644
--- a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
+++ b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
@@ -180,6 +180,21 @@ void clock_set_pll1(unsigned int hz)
}
#endif
+void clock_set_pll3(unsigned int clk)
+{
+ struct sunxi_ccm_reg * const ccm =
+ (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+ if (clk == 0) {
+ clrbits_le32(ccm-pll3_cfg, CCM_PLL3_CTRL_EN);
+ return;
+ }
+
+ /* PLL3 rate = 300 * m */
+ writel(CCM_PLL3_CTRL_EN | CCM_PLL3_CTRL_INTEGER_MODE |
+ CCM_PLL3_CTRL_M(clk / 300), ccm-pll3_cfg);
+}
+
unsigned int clock_get_pll5p(void)
{
struct sunxi_ccm_reg *const ccm =
@@ -200,3 +215,15 @@ unsigned int clock_get_pll6(void)
int k = ((rval CCM_PLL6_CTRL_K_MASK) CCM_PLL6_CTRL_K_SHIFT) + 1;
return 2400 * n * k / 2;
}
+
+void clock_set_de_mod_clock(u32 *clk_cfg, unsigned int hz)
+{
+ int pll = clock_get_pll5p();
+ int div = 1;
+
+ while ((pll / div) hz)
+ div++;
+
+ writel(CCM_DE_CTRL_GATE | CCM_DE_CTRL_RST | CCM_DE_CTRL_PLL5P |
+ CCM_DE_CTRL_M(div), clk_cfg);
+}
diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
index 16ab6f3..8e949c6 100644
--- a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
+++ b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
@@ -127,6 +127,23 @@ void clock_set_pll1(unsigned int clk)
}
#endif
+void clock_set_pll3(unsigned int clk)
+{
+ struct sunxi_ccm_reg * const ccm =
+ (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+ const int m = 8; /* 3 MHz steps just like sun4i, sun5i and sun7i */
+
+ if (clk == 0) {
+ clrbits_le32(ccm-pll3_cfg, CCM_PLL3_CTRL_EN);
+ return;
+ }
+
+ /* PLL3 rate = 2400 * n / m */
+ writel(CCM_PLL3_CTRL_EN | CCM_PLL3_CTRL_INTEGER_MODE |
+ CCM_PLL3_CTRL_N(clk / (2400 / m)) | CCM_PLL3_CTRL_M(m),
+ ccm-pll3_cfg);
+}
+
void clock_set_pll5(unsigned int clk)
{
struct sunxi_ccm_reg * const ccm =
@@ -151,3 +168,15 @@ unsigned int clock_get_pll6(void)
int k = ((rval CCM_PLL6_CTRL_K_MASK) CCM_PLL6_CTRL_K_SHIFT) + 1;
return 2400 * n * k / 2;
}
+
+void clock_set_de_mod_clock(u32 *clk_cfg, unsigned int hz)
+{
+ int pll = clock_get_pll6() * 2;
+ int div = 1;
+
+ while ((pll / div) hz)
+ div++;
+
+ writel(CCM_DE_CTRL_GATE | CCM_DE_CTRL_PLL6_2X | CCM_DE_CTRL_M(div),
+ clk_cfg);
+}
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index b40c16b..64acff3 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -25,9 +25,11 @@
int clock_init(void);
int clock_twi_onoff(int port, int state);
void clock_set_pll1(unsigned int hz);
+void clock_set_pll3(unsigned int hz);
void clock_set_pll5(unsigned int hz);
unsigned int clock_get_pll5p(void);
unsigned int clock_get_pll6(void);
+void clock_set_de_mod_clock(u32 *clk_cfg, unsigned int hz);
void clock_init_safe(void);
void clock_init_uart(void);
#endif
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
index 6c0430c..eb88969 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
@@ -186,12 +186,20 @@ struct sunxi_ccm_reg {
/* ahb clock gate bit offset (second register) */
#define AHB_GATE_OFFSET_GMAC 17
+#define AHB_GATE_OFFSET_DE_BE0 12
+#define AHB_GATE_OFFSET_HDMI 11
+#define AHB_GATE_OFFSET_LCD1 5
+#define AHB_GATE_OFFSET_LCD0 4
#define CCM_AHB_GATE_GPS (0x1 26)
#define CCM_AHB_GATE_SDRAM (0x1 14)
#define CCM_AHB_GATE_DLL (0x1 15)
#define CCM_AHB_GATE_ACE (0x1 16)
+#define CCM_PLL3_CTRL_M(n) (((n) 0x7f) 0)
+#define CCM_PLL3_CTRL_INTEGER_MODE (0x1 15)
+#define CCM_PLL3_CTRL_EN (0x1 31)
+
#define CCM_PLL5_CTRL_M(n) (((n) 0x3) 0)
#define CCM_PLL5_CTRL_M_MASK CCM_PLL5_CTRL_M(0x3)
#define CCM_PLL5_CTRL_M_X(n) ((n) - 1)
@@ -253,6 +261,34 @@ struct sunxi_ccm_reg {
#define CCM_MMC_CTRL_ENABLE (0x1 31)
+#define CCM_DRAM_GATE_OFFSET_DE_BE026
+
+#define CCM_LCD_CH0_CTRL_PLL3 (0 24)
+#define CCM_LCD_CH0_CTRL_PLL7
[U-Boot] [PATCH 4/6] sunxi: video: Add sun6i support
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/video/sunxi_display.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 74a92b5..1058771 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -39,6 +39,9 @@ sunxi_hdmi_hpd_detect(void)
CCM_HDMI_CTRL_PLL3);
/* Set ahb gating to pass */
+#ifdef CONFIG_MACH_SUN6I
+ setbits_le32(ccm-ahb_reset1_cfg, 1 AHB_RESET_OFFSET_HDMI);
+#endif
setbits_le32(ccm-ahb_gate1, 1 AHB_GATE_OFFSET_HDMI);
/* Clock on */
@@ -56,6 +59,9 @@ sunxi_hdmi_hpd_detect(void)
clrbits_le32(hdmi-ctrl, SUNXI_HDMI_CTRL_ENABLE);
clrbits_le32(ccm-hdmi_clk_cfg, CCM_HDMI_CTRL_GATE);
clrbits_le32(ccm-ahb_gate1, 1 AHB_GATE_OFFSET_HDMI);
+#ifdef CONFIG_MACH_SUN6I
+ clrbits_le32(ccm-ahb_reset1_cfg, 1 AHB_RESET_OFFSET_HDMI);
+#endif
clock_set_pll3(0);
return 0;
@@ -74,6 +80,11 @@ sunxi_composer_init(void)
(struct sunxi_de_be_reg *)SUNXI_DE_BE0_BASE;
int i;
+#ifdef CONFIG_MACH_SUN6I
+ /* Reset off */
+ setbits_le32(ccm-ahb_reset1_cfg, 1 AHB_RESET_OFFSET_DE_BE0);
+#endif
+
/* Clocks on */
setbits_le32(ccm-ahb_gate1, 1 AHB_GATE_OFFSET_DE_BE0);
setbits_le32(ccm-dram_clk_gate, 1 CCM_DRAM_GATE_OFFSET_DE_BE0);
@@ -177,7 +188,11 @@ sunxi_lcdc_init(void)
(struct sunxi_lcdc_reg *)SUNXI_LCD0_BASE;
/* Reset off */
+#ifdef CONFIG_MACH_SUN6I
+ setbits_le32(ccm-ahb_reset1_cfg, 1 AHB_RESET_OFFSET_LCD0);
+#else
setbits_le32(ccm-lcd0_ch0_clk_cfg, CCM_LCD_CH0_CTRL_RST);
+#endif
/* Clock on */
setbits_le32(ccm-ahb_gate1, 1 AHB_GATE_OFFSET_LCD0);
@@ -232,6 +247,19 @@ sunxi_lcdc_mode_set(struct fb_videomode *mode, int
*clk_div, int *clk_double)
sunxi_lcdc_pll_set(mode-pixclock, clk_div, clk_double);
}
+#ifdef CONFIG_MACH_SUN6I
+static void
+sunxi_drc_init(void)
+{
+ struct sunxi_ccm_reg * const ccm =
+ (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+ /* On sun6i the drc must be clocked even when in pass-through mode */
+ setbits_le32(ccm-ahb_reset1_cfg, 1 AHB_RESET_OFFSET_DRC0);
+ clock_set_de_mod_clock(ccm-iep_drc0_clk_cfg, 3);
+}
+#endif
+
static void
sunxi_hdmi_mode_set(struct fb_videomode *mode, int clk_div, int clk_double)
{
@@ -283,6 +311,9 @@ sunxi_engines_init(void)
{
sunxi_composer_init();
sunxi_lcdc_init();
+#ifdef CONFIG_MACH_SUN6I
+ sunxi_drc_init();
+#endif
}
static void
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] sunxi: HDMI (cfb) console support
Hi all, Now that the simplefb devicetree binding stuff has finally been sorted out, I would like to move forward with this patch-set. Ian, can you please review the entire set, from the sunxi pov ? Anatolij, can you please review the sunxi: video: Add cfb console driver for sunxi patch from a video subsys pov, it uses the cfb stuff as is, without making any changes, so there should not be any problems, but still I would like your acked by for this. If the review goes smoothly I would still like to get this series into v2015.01, the initial version of these patches have been posted before the previous merge window, so this patch-set has been long enough in the making already. It has been in my personal tree and used when ever I have been doing sunxi work for months now, without any issues. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT] Pull request: u-boot-dfu
Hi Marek, The following changes since commit 6a559bbe2f60ab64e28662f7ab52551a2eaa7163: usb_storage: blacklist Enclosure Service Devices (2014-11-08 12:03:35 +0100) are available in the git repository at: git://git.denx.de/u-boot-dfu.git for you to fetch changes up to 8f605197a872946d0a8a5b34c0eaee38ddd52dbf: test: ums: Add sleep before unmount directory (2014-11-14 11:42:09 +0100) Łukasz Majewski (2): dfu: thor: fix: Modify dfu_get_alt() function to support absolute paths test: ums: Add sleep before unmount directory drivers/dfu/dfu.c | 29 +++-- test/ums/ums_gadget_test.sh | 10 +- 2 files changed, 36 insertions(+), 3 deletions(-) Thanks in advance. -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] sunxi: video: Add cfb console driver for sunxi
From: Luc Verhaegen l...@skynet.be
This adds a fixed mode hdmi driver for the sunxi platform. The fixed
mode is a relatively safe 1024x768, more complete EDID handling is
currently not provided. Only HDMI is supported today.
This code is enabled when HPD detects an attached monitor.
Current config is such that 8MB is shaved off at the top of the RAM.
This avoids several memory handling issues, most significant is the fact
that on linux on ARM you are not allowed to remap known RAM as IO. A
clued in display driver will be able to recycle this reserved RAM in
future though.
cfbconsole was chosen as it provides the most important functionality: a
working u-boot console, allowing for the debugging of certain issues
without the need for a UART.
Signed-off-by: Luc Verhaegen l...@skynet.be
[hdego...@redhat.com: Major cleanups and some small bugfixes]
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/include/asm/arch-sunxi/display.h | 198 +++
board/sunxi/Kconfig | 7 +
configs/Ippo_q8h_v5_defconfig | 1 +
drivers/video/Makefile| 1 +
drivers/video/sunxi_display.c | 387 ++
include/configs/sunxi-common.h| 34 +++
6 files changed, 628 insertions(+)
create mode 100644 arch/arm/include/asm/arch-sunxi/display.h
create mode 100644 drivers/video/sunxi_display.c
diff --git a/arch/arm/include/asm/arch-sunxi/display.h
b/arch/arm/include/asm/arch-sunxi/display.h
new file mode 100644
index 000..8ac7d1b
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -0,0 +1,198 @@
+/*
+ * Sunxi platform display cntroller register and constant defines
+ *
+ * (C) Copyright 2014 Hans de Goede hdego...@redhat.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_DISPLAY_H
+#define _SUNXI_DISPLAY_H
+
+struct sunxi_de_be_reg {
+ u8 res0[0x800]; /* 0x000 */
+ u32 mode; /* 0x800 */
+ u32 backcolor; /* 0x804 */
+ u32 disp_size; /* 0x808 */
+ u8 res1[0x4]; /* 0x80c */
+ u32 layer0_size;/* 0x810 */
+ u32 layer1_size;/* 0x814 */
+ u32 layer2_size;/* 0x818 */
+ u32 layer3_size;/* 0x81c */
+ u32 layer0_pos; /* 0x820 */
+ u32 layer1_pos; /* 0x824 */
+ u32 layer2_pos; /* 0x828 */
+ u32 layer3_pos; /* 0x82c */
+ u8 res2[0x10]; /* 0x830 */
+ u32 layer0_stride; /* 0x840 */
+ u32 layer1_stride; /* 0x844 */
+ u32 layer2_stride; /* 0x848 */
+ u32 layer3_stride; /* 0x84c */
+ u32 layer0_addr_low32b; /* 0x850 */
+ u32 layer1_addr_low32b; /* 0x854 */
+ u32 layer2_addr_low32b; /* 0x858 */
+ u32 layer3_addr_low32b; /* 0x85c */
+ u32 layer0_addr_high4b; /* 0x860 */
+ u32 layer1_addr_high4b; /* 0x864 */
+ u32 layer2_addr_high4b; /* 0x868 */
+ u32 layer3_addr_high4b; /* 0x86c */
+ u32 reg_ctrl; /* 0x870 */
+ u8 res3[0xc]; /* 0x874 */
+ u32 color_key_max; /* 0x880 */
+ u32 color_key_min; /* 0x884 */
+ u32 color_key_config; /* 0x888 */
+ u8 res4[0x4]; /* 0x88c */
+ u32 layer0_attr0_ctrl; /* 0x890 */
+ u32 layer1_attr0_ctrl; /* 0x894 */
+ u32 layer2_attr0_ctrl; /* 0x898 */
+ u32 layer3_attr0_ctrl; /* 0x89c */
+ u32 layer0_attr1_ctrl; /* 0x8a0 */
+ u32 layer1_attr1_ctrl; /* 0x8a4 */
+ u32 layer2_attr1_ctrl; /* 0x8a8 */
+ u32 layer3_attr1_ctrl; /* 0x8ac */
+};
+
+struct sunxi_lcdc_reg {
+ u32 ctrl; /* 0x00 */
+ u32 int0; /* 0x04 */
+ u32 int1; /* 0x08 */
+ u8 res0[0x04]; /* 0x0c */
+ u32 frame_ctrl; /* 0x10 */
+ u8 res1[0x2c]; /* 0x14 */
+ u32 tcon0_ctrl; /* 0x40 */
+ u32 tcon0_dclk; /* 0x44 */
+ u32 tcon0_basic_timing0;/* 0x48 */
+ u32 tcon0_basic_timing1;/* 0x4c */
+ u32 tcon0_basic_timing2;/* 0x50 */
+ u32 tcon0_basic_timing3;/* 0x54 */
+ u32 tcon0_hv_intf; /* 0x58 */
+ u8 res2[0x04]; /* 0x5c */
+ u32 tcon0_cpu_intf; /* 0x60 */
+ u32 tcon0_cpu_wr_dat; /* 0x64 */
+ u32 tcon0_cpu_rd_dat0; /* 0x68 */
+ u32 tcon0_cpu_rd_dat1; /* 0x6c */
+ u32 tcon0_ttl_timing0; /* 0x70 */
+ u32
[U-Boot] [PATCH 1/6] sun4i: Rename dram_clk_cfg to dram_clk_gate
The data sheet just calls it DRAM_CLK_REG, and on sun6i we've both a
dram_clk_cfg and dram_clk_gate, and the sun4i reg matches dram_clk_gate on
sun6i, so name it the same on sun4i.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/dram_sun4i.c | 4 ++--
arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
index dc9fdb9..ec8aaa7 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
@@ -428,9 +428,9 @@ static void dramc_clock_output_en(u32 on)
#ifdef CONFIG_MACH_SUN4I
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
if (on)
- setbits_le32(ccm-dram_clk_cfg, CCM_DRAM_CTRL_DCLK_OUT);
+ setbits_le32(ccm-dram_clk_gate, CCM_DRAM_CTRL_DCLK_OUT);
else
- clrbits_le32(ccm-dram_clk_cfg, CCM_DRAM_CTRL_DCLK_OUT);
+ clrbits_le32(ccm-dram_clk_gate, CCM_DRAM_CTRL_DCLK_OUT);
#endif
}
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
index 9dca800..6c0430c 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
@@ -62,7 +62,7 @@ struct sunxi_ccm_reg {
u32 gps_clk_cfg;/* 0xd0 */
u32 spi3_clk_cfg; /* 0xd4 */
u8 res5[0x28];
- u32 dram_clk_cfg; /* 0x100 */
+ u32 dram_clk_gate; /* 0x100 */
u32 be0_clk_cfg;/* 0x104 */
u32 be1_clk_cfg;/* 0x108 */
u32 fe0_clk_cfg;/* 0x10c */
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] sunxi: Add usb keyboard Kconfig option
For use together with the hdmi console. Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/Kconfig| 7 +++ configs/Ippo_q8h_v5_defconfig | 1 + include/configs/sunxi-common.h | 25 + 3 files changed, 29 insertions(+), 4 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 422033a..246cd9a 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -223,4 +223,11 @@ config VIDEO Say Y here to add support for using a cfb console on the HDMI output found on most sunxi devices. +config USB_KEYBOARD + boolean Enable USB keyboard support + default y + ---help--- + Say Y here to add support for using a USB keyboard (typically used + in combination with a graphical console on HDMI). + endif diff --git a/configs/Ippo_q8h_v5_defconfig b/configs/Ippo_q8h_v5_defconfig index 53df213..50c2f93 100644 --- a/configs/Ippo_q8h_v5_defconfig +++ b/configs/Ippo_q8h_v5_defconfig @@ -5,3 +5,4 @@ CONFIG_MACH_SUN8I=y CONFIG_TARGET_IPPO_Q8H_V5=y CONFIG_DEFAULT_DEVICE_TREE=sun8i-a23-ippo-q8h-v5.dtb CONFIG_VIDEO=n +CONFIG_USB_KEYBOARD=n diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index d7d8571..5d1b611 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -249,6 +249,12 @@ #define CONFIG_USB_STORAGE #endif +#ifdef CONFIG_USB_KEYBOARD +#define CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE +#define CONFIG_PREBOOT +#define CONFIG_SYS_STDIO_DEREGISTER +#endif + #if !defined CONFIG_ENV_IS_IN_MMC \ !defined CONFIG_ENV_IS_IN_NAND \ !defined CONFIG_ENV_IS_IN_FAT \ @@ -298,17 +304,28 @@ #include config_distro_bootcmd.h +#ifdef CONFIG_USB_KEYBOARD +#define CONSOLE_IN_SETTINGS \ + preboot=usb start\0 \ + stdin=serial,usbkbd\0 +#else +#define CONSOLE_IN_SETTINGS \ + stdin=serial\0 +#endif + #ifdef CONFIG_VIDEO -#define CONSOLE_ENV_SETTINGS \ - stdin=serial\0 \ +#define CONSOLE_OUT_SETTINGS \ stdout=serial,vga\0 \ stderr=serial,vga\0 #else -#define CONSOLE_ENV_SETTINGS +#define CONSOLE_OUT_SETTINGS \ + stdout=serial\0 \ + stderr=serial\0 #endif #define CONFIG_EXTRA_ENV_SETTINGS \ - CONSOLE_ENV_SETTINGS \ + CONSOLE_IN_SETTINGS \ + CONSOLE_OUT_SETTINGS \ MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_FDTFILE \0 \ console=ttyS0,115200\0 \ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] sunxi: video: Add simplefb support
From: Luc Verhaegen l...@skynet.be
Add simplefb support, note this depends on the kernel having support for
the clocks property which has recently been added to the simplefb devicetree
binding.
Signed-off-by: Luc Verhaegen l...@skynet.be
[hdego...@redhat.com: Use pre-populated simplefb node under /chosen as
disussed on the devicetree list]
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/include/asm/arch-sunxi/display.h | 4 ++
board/sunxi/board.c | 11 ++
drivers/video/sunxi_display.c | 66 +++
include/configs/sunxi-common.h| 8
4 files changed, 89 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/display.h
b/arch/arm/include/asm/arch-sunxi/display.h
index 8ac7d1b..e38a401 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -195,4 +195,8 @@ struct sunxi_hdmi_reg {
#define SUNXI_HDMI_PLL_DBG0_PLL3 (0 21)
#define SUNXI_HDMI_PLL_DBG0_PLL7 (1 21)
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+void sunxi_simplefb_setup(void *blob);
+#endif
+
#endif /* _SUNXI_DISPLAY_H */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index e6ec5b8..d4530e8 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -24,6 +24,7 @@
#endif
#include asm/arch/clock.h
#include asm/arch/cpu.h
+#include asm/arch/display.h
#include asm/arch/dram.h
#include asm/arch/gpio.h
#include asm/arch/mmc.h
@@ -237,3 +238,13 @@ int misc_init_r(void)
return 0;
}
#endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
+void
+ft_board_setup(void *blob, bd_t *bd)
+{
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+ sunxi_simplefb_setup(blob);
+#endif
+}
+#endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 1058771..a47f575 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -13,6 +13,7 @@
#include asm/arch/display.h
#include asm/global_data.h
#include asm/io.h
+#include fdtdec.h
#include linux/fb.h
#include video_fb.h
@@ -416,3 +417,68 @@ video_hw_init(void)
return graphic_device;
}
+
+/*
+ * Simplefb support.
+ */
+#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_VIDEO_DT_SIMPLEFB)
+void
+sunxi_simplefb_setup(void *blob)
+{
+ static GraphicDevice *graphic_device = sunxi_display.graphic_device;
+ const char *node = /chosen/framebuffer0-hdmi;
+ const char *format = x8r8g8b8;
+ const char *okay = okay;
+ char name[32];
+ fdt32_t cells[2];
+ int offset, stride, ret;
+
+ if (!sunxi_display.enabled)
+ return;
+
+ offset = fdt_path_offset(blob, node);
+ if (offset 0) {
+ eprintf(Cannot setup simplefb: %s node not found\n, node);
+ return;
+ }
+
+ snprintf(name, sizeof(name), framebuffer@%08lx, gd-fb_base);
+ ret = fdt_set_name(blob, offset, name);
+ if (ret 0)
+ goto error;
+
+ cells[0] = cpu_to_fdt32(gd-fb_base);
+ cells[1] = cpu_to_fdt32(CONFIG_SUNXI_FB_SIZE);
+ ret = fdt_setprop(blob, offset, reg, cells, sizeof(cells[0]) * 2);
+ if (ret 0)
+ goto error;
+
+ cells[0] = cpu_to_fdt32(graphic_device-winSizeX);
+ ret = fdt_setprop(blob, offset, width, cells, sizeof(cells[0]));
+ if (ret 0)
+ goto error;
+
+ cells[0] = cpu_to_fdt32(graphic_device-winSizeY);
+ ret = fdt_setprop(blob, offset, height, cells, sizeof(cells[0]));
+ if (ret 0)
+ goto error;
+
+ stride = graphic_device-winSizeX * graphic_device-gdfBytesPP;
+ cells[0] = cpu_to_fdt32(stride);
+ ret = fdt_setprop(blob, offset, stride, cells, sizeof(cells[0]));
+ if (ret 0)
+ goto error;
+
+ ret = fdt_setprop(blob, offset, format, format, strlen(format) + 1);
+ if (ret 0)
+ goto error;
+
+ ret = fdt_setprop(blob, offset, status, okay, strlen(okay) + 1);
+ if (ret 0)
+ goto error;
+
+ return;
+error:
+ eprintf(Cannot setup simplefb: Error setting properties\n);
+}
+#endif /* CONFIG_OF_BOARD_SETUP CONFIG_VIDEO_DT_SIMPLEFB */
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 532fdb7..d7d8571 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -204,6 +204,9 @@
*/
#define CONFIG_SUNXI_FB_SIZE (8 20)
+/* Do we want to initialize a simple FB? */
+#define CONFIG_VIDEO_DT_SIMPLEFB
+
#define CONFIG_VIDEO_SUNXI
#define CONFIG_CFB_CONSOLE
@@ -219,6 +222,11 @@
#define CONFIG_SYS_MEM_TOP_HIDE ((CONFIG_SUNXI_FB_SIZE + 0xFFF) ~0xFFF)
+/* To be able to hook simplefb into dt */
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+#define CONFIG_OF_BOARD_SETUP
+#endif
+
#endif /* CONFIG_VIDEO */
/* Ethernet support */
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] Memory test post relocation
Hello DaveKucharczyk, On Fri, 14 Nov 2014 09:07:50 -0700 (MST), DaveKucharczyk david.kucharc...@gmail.com wrote: btw, I'm using nabble to post, but notice my code snippets don't show up in the mailing list, which I assume most of you guys are using. Maybe it's just as well -- if you post full diffs, then our Patchwork is going to believe you're submitting a patch to U-Boot. :) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Hello DaveKucharczyk, On Fri, 14 Nov 2014 08:54:20 -0700 (MST), DaveKucharczyk david.kucharc...@gmail.com wrote: Albert ARIBAUD (U-Boot) wrote No, that's not where it'll be; it'll relocate as high as it can. I guess that's the confusing part. When I run with debug on I get the following log. Halfway down it reports Now running in RAM - U-Boot at: eff89000, but there are still initcall's to lower memory after that. So I'm thinking lower memory is still used at that point. Am I wrong? I did try a mem test starting at the lowest address and it worked, but I would like to understand why the initcall's to low-mem after relocation. The mem test essentially erases those addresses, so initcall's to those addresses are suspect at that point. You're correct that they'd be suspect; but the calls are to high addresses, only the debug printf() prints their address... minus the reloc offset (why it does that is beyond me). So false alarm here. So, no, you don't use lower mem once relocated. But you do use some memory below the stack top, and you dont exactly know how much. Albert ARIBAUD (U-Boot) wrote If you happen to have an SPL running from some RAM and not from DDR, then you could perform the full DDR test there. . I think the mx53 has internal sram, which is why we were able to run fully from there before, since we had set CONFIG_SKIP_RELOCATE_UBOOT. I tried setting CONFIG_SKIP_LOWLEVEL_INIT, but nothing works with that set. Still not sure what your config is. Can you indicate the board, commit and toolchain you're using? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] imx: fix exception vectors relocation in imx27
On 13/11/14 17:59, Albert ARIBAUD wrote:
Commit 3ff46cc4 fixed exception vectors setting in
the general ARM case, by either copying the exception
and indirect vector tables to normal (0x) or
high (0x) vectors address, or setting VBAR to
U-Boot's base if applicable.
i.MX27 SoC is ARM926E-JS, thus has only normal and
high options, but does not provide RAM at 0x
and has only ROM at 0x; it is therefore not
possible to move or change its exception vectors.
Besides, i.MX27 ROM code does provide an indirect
vectors table but at a non-standard address and with
the reset and reserved vectors missing.
Turn the current vector relocation code into a weak
routine called after relocate_code from crt0, and add
strong version for i.MX27.
Series-Cc: Heiko Schocherh...@denx.de
Tested-by: Philippe Reynes trem...@yahoo.fr
Signed-off-by: Albert ARIBAUDalbert.u.b...@aribaud.net
---
Changes in v3:
- Fixed AGAIN wrong i.MX27 vector relocation code
Changes in v2:
- Fixed wrong i.MX27 vector relocation code
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++
arch/arm/cpu/arm926ejs/mx27/relocate.S | 51 +
arch/arm/lib/crt0.S| 5 +++
arch/arm/lib/relocate.S| 69 --
4 files changed, 101 insertions(+), 28 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/mx27/relocate.S
diff --git a/arch/arm/cpu/arm926ejs/mx27/Makefile
b/arch/arm/cpu/arm926ejs/mx27/Makefile
index 4976bbb..0edf144 100644
--- a/arch/arm/cpu/arm926ejs/mx27/Makefile
+++ b/arch/arm/cpu/arm926ejs/mx27/Makefile
@@ -5,3 +5,7 @@
# SPDX-License-Identifier:GPL-2.0+
obj-y = generic.o reset.o timer.o
+
+ifndef CONFIG_SPL_BUILD
+obj-y += relocate.o
+endif
diff --git a/arch/arm/cpu/arm926ejs/mx27/relocate.S
b/arch/arm/cpu/arm926ejs/mx27/relocate.S
new file mode 100644
index 000..0c4b272
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mx27/relocate.S
@@ -0,0 +1,51 @@
+/*
+ * relocate - i.MX27-specific vector relocation
+ *
+ * Copyright (c) 2013 Albert ARIBAUDalbert.u.b...@aribaud.net
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#includeasm-offsets.h
+#includeconfig.h
+#includelinux/linkage.h
+
+/*
+ * The i.MX27 SoC is very specific with respect to exceptions: it
+ * does not provide RAM at the high vectors address (0x),
+ * thus only the low address (0x) is useable; but that is
+ * in ROM. Therefore, vectors cannot be changed at all.
+ *
+ * However, these ROM-based vectors actually just perform indirect
+ * calls through pointers located in RAM at SoC-specific addresses,
+ * as follows:
+ *
+ * Offset Exception Use by ROM code
+ * 0x reset indirect branch to [0x0014]
+ * 0x0004 undefined instruction indirect branch to [0xfef0]
+ * 0x0008 software interrupt indirect branch to [0xfef4]
+ * 0x000c prefetch abort indirect branch to [0xfef8]
+ * 0x0010 data abort indirect branch to [0xfefc]
+ * 0x0014 (reserved in ARMv5)vector to ROM reset: 0xc000
+ * 0x0018 IRQindirect branch to [0xff00]
+ * 0x001c FIQindirect branch to [0xff04]
+ *
+ * In order to initialize exceptions on i.MX27, we must copy U-Boot's
+ * indirect (not exception!) vector table into 0xfef0..0xff04
+ * taking care not to copy vectors number 5 (reserved exception).
+ */
+
+ .section.text.relocate_vectors,ax,%progbits
+
+ENTRY(relocate_vectors)
+
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ ldr r1, =32 /* size of vector table */
+ add r0, r0, r1 /* skip to indirect table */
+ ldr r1, =0xFEF0 /* i.MX27 indirect table */
+ ldmia r0!, {r2-r8}/* load indirect vectors 1..7 */
+ stmia r1!, {r2-r5, r7,r8} /* write all but vector 5 */
+
+ bx lr
+
+ENDPROC(relocate_vectors)
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 29cdad0..a33ad3e 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -104,6 +104,11 @@ clr_gd:
ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
b relocate_code
here:
+/*
+ * now relocate vectors
+ */
+
+ bl relocate_vectors
/* Set up final (full) environment */
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 6ede41c..92f5314 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -11,6 +11,47 @@
#includelinux/linkage.h
/*
+ * Default/weak exception vectors relocation routine
+ *
+ * This routine covers the standard ARM cases: normal (0x),
+ * high (0x) and VBAR. SoCs which do not comply with any of
+ * the standard cases must provide their own, strong, version.
+ */
+
+ .section.text.relocate_vectors,ax,%progbits
+ .weak relocate_vectors
+
Re: [U-Boot] iMX6 DDR Calibration Value
On Thu, Nov 13, 2014 at 11:19 PM, John Tobias john.tobias...@gmail.com wrote: Hi Fabio / Stefano, May be you could help me to get some answer regarding with calibrations value for DDR. I have a 4 custom boards based on iMX6SL (2) Micron DDR and (2) Samsung DDR. The boards has exact DDR footprints (like density, bus width and so on). In fact the uboot that I am using works on both DDR chips. I re-ran the DDR tools twice for each boards, entered the same information. The tools returned different calibration values for each boards but, the two results for each boards were the same. e.g: board1 Read DQS Gating calibration MPDGCTRL0 PHY0 (0x021b083c) = 0x412C0130 MPDGCTRL1 PHY0 (0x021b0840) = 0x01140118 Read calibration MPRDDLCTL PHY0 (0x021b0848) = 0x3E404244 Write calibration MPWRDLCTL PHY0 (0x021b0850) = 0x383C3E36 board2: Read DQS Gating calibration MPDGCTRL0 PHY0 (0x021b083c) = 0x412C0130 MPDGCTRL1 PHY0 (0x021b0840) = 0x01140118 Read calibration MPRDDLCTL PHY0 (0x021b0848) = 0x3E3E4244 Write calibration MPWRDLCTL PHY0 (0x021b0850) = 0x383C3E36 Is there any procedures or rules of thumb you follow dealing with the calibration settings?. Then you need to provide a mx6_mmdc_calibration structure for each board, right? Take a look at gw_ventana_spl.c for an example on how this is done. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Albert ARIBAUD (U-Boot) wrote Still not sure what your config is. Can you indicate the board, commit and toolchain you're using? We're using a board based on the Freescale mx53loco. u-boot-2014.07 toolchain = armv7l-timesys-linux-gnueabi Libc = ldd (GNU libc) 2.12 gcc = gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196211.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3][v2] drivers: usb: Make usb device-tree fixup code architecture independent
On 10/20/2014 04:20 AM, Nikhil Badola wrote: move usb device tree fixup code from arch/powerpc/ to drivers/usb/ so that it works independent of architecture it is running on Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com --- Changes for v2 : - Fixed compilation error for Platforms with CONFIG_USB_MAX_CONTROLLER_COUNT not defined - Depends on https://patchwork.ozlabs.org/patch/401063/ arch/powerpc/cpu/mpc8xxx/fdt.c | 104 - drivers/usb/host/ehci-fsl.c| 113 + 2 files changed, 113 insertions(+), 104 deletions(-) We have compiling error for boards MPC837XEMDS_HOST MPC837XERDB. ehci-fsl.c is not compiled for these boards. Can you check if CONFIG_USB_EHCI_FSL can be defined for them. Adding Kim. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-video/master
Hey Tom, The following changes since commit 571bdf16a78e9e116a93d46f4809c4f8a3f2adb6: arm: interrupt_init: set sp in IRQ/FIQ modes (2014-10-29 09:03:28 -0400) are available in the git repository at: git://git.denx.de/u-boot-video.git master for you to fetch changes up to d37e96ecb9886714e0b5e167a91404cde8351b19: video: speedup writing strings to fb console (2014-10-30 21:45:25 +0100) Soeren Moch (1): video: speedup writing strings to fb console drivers/video/cfb_console.c |9 + 1 file changed, 9 insertions(+) Please pull. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] iMX6 DDR Calibration Value
Hi Fabio, I think I got it and here's what I did: When the DDR stress tester generated those calibration settings, run the stress test. Once the board (with micron) passed the stress test, copy those settings and overwrite the value of those registers in the .inc file. Then, run the (ONLY) stress test again on different board (with different DDR). Once it passed, the value that the stress tester generated could use as a default value of those registers. Regards, John Tobias On Fri, Nov 14, 2014 at 10:44 AM, Fabio Estevam feste...@gmail.com wrote: On Thu, Nov 13, 2014 at 11:19 PM, John Tobias john.tobias...@gmail.com wrote: Hi Fabio / Stefano, May be you could help me to get some answer regarding with calibrations value for DDR. I have a 4 custom boards based on iMX6SL (2) Micron DDR and (2) Samsung DDR. The boards has exact DDR footprints (like density, bus width and so on). In fact the uboot that I am using works on both DDR chips. I re-ran the DDR tools twice for each boards, entered the same information. The tools returned different calibration values for each boards but, the two results for each boards were the same. e.g: board1 Read DQS Gating calibration MPDGCTRL0 PHY0 (0x021b083c) = 0x412C0130 MPDGCTRL1 PHY0 (0x021b0840) = 0x01140118 Read calibration MPRDDLCTL PHY0 (0x021b0848) = 0x3E404244 Write calibration MPWRDLCTL PHY0 (0x021b0850) = 0x383C3E36 board2: Read DQS Gating calibration MPDGCTRL0 PHY0 (0x021b083c) = 0x412C0130 MPDGCTRL1 PHY0 (0x021b0840) = 0x01140118 Read calibration MPRDDLCTL PHY0 (0x021b0848) = 0x3E3E4244 Write calibration MPWRDLCTL PHY0 (0x021b0850) = 0x383C3E36 Is there any procedures or rules of thumb you follow dealing with the calibration settings?. Then you need to provide a mx6_mmdc_calibration structure for each board, right? Take a look at gw_ventana_spl.c for an example on how this is done. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] sunxi: video: Add cfb console driver for sunxi
Hi Hans, this patch looks good, only a few minor comments below. On Fri, 14 Nov 2014 17:54:45 +0100 Hans de Goede hdego...@redhat.com wrote: ... diff --git a/arch/arm/include/asm/arch-sunxi/display.h b/arch/arm/include/asm/arch-sunxi/display.h new file mode 100644 index 000..8ac7d1b --- /dev/null +++ b/arch/arm/include/asm/arch-sunxi/display.h @@ -0,0 +1,198 @@ +/* + * Sunxi platform display cntroller register and constant defines s/cntroller/controller/ not need to resubmit the patch, this can be fixed when applying. ... +#if 1 + printf(dotclock: %dkHz = %dkHz: (%d * 3MHz * %d) / %d\n, +dotclock, (best_double + 1) * 3000 * best_n / best_m, +best_double + 1, best_n, best_m); +#endif please drop #if 1 / #endif when applying the patch. here, printf() could be replaced by debug() maybe ? ... + udelay(100 / mode-refresh + 500); + + /* Sometimes the display pipeline does not sync up properly, if +this happens the hdmi fifo underrun or overrun bits are set */ we use /* * multi-line * comment */ style. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: dts: Move to SPDX license identifiers
On Friday, November 14, 2014 at 08:10:44 AM, Stefan Roese wrote: The socfpga dts files are copied from the Rocketboards.org repository. In U-Boot we usually replace the full-blown license header text with the SPDX license identifiers. Lets do this for these new dts files as well. I just forgot to do this while adding the DT support for socfpga. Signed-off-by: Stefan Roese s...@denx.de Cc: Marek Vasut ma...@denx.de Cc: Pavel Machek pa...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Vince Bridgers vbrid...@altera.com Applied, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/3] Add board level usb support for mxsxsabresd and mx6slevk
On Monday, November 10, 2014 at 01:50:38 AM, Peng Fan wrote: Changes v4: - Take Marek's suggestions, implement usb_phy_mode function and introduce a weak function board_usb_phy_mode. - change usb_phy_enable's return value with 0. - reimplement board_usb_phy_mode in board code. - add prototype type for board_usb_phy_mode and usb_phy_mode Changes v3: - Take Marek's suggestions, replace 'return val USBPHY_CTRL_OTG_ID' with this new function like 'return board_usb_phy_mode(index);' Detailed discussion here: http://lists.denx.de/pipermail/u-boot/2014-November/194131.html Changes v2: - Introduce a new weak function to let board have a choice to decide which mode to work at. - move pinmux setting into board_init - add otg polarity setting in board_ehci_hcd_init - set pinmux struct static Applied all, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] spi: Add designware master SPI DM driver used on SoCFPGA
On Wednesday, November 12, 2014 at 06:51:42 PM, Pavel Machek wrote: Hi! You tripped my spell-checker, sorry. This patch adds the driver for the Designware master SPI controller. This IP core is integrated on the Altera SoCFPGA. This implementation is a driver model (DM) implementation. So multiple SPI drivers can be used. Thats necessary, since SoCFPGA also integrates the Cadence QSPI controller used to connect the SPI NOR flashes. Without DM, using multiple SPI driver is not possible. drivers. This driver is very loosly based on the Linux driver. Most of the loosely? driver is removed. Only the polling loop for the transfer is really used from this driver. As we don't support interrupts and DMA right now. , as + * Very loosly based on the Linux driver version which is: loosely. (And citing filename here might be useful.) I fixed the text and I placed this whole driver patchset to u-boot-socfpga:topic/drivers/spi-20141114 Can you please fix the code so I can replace that one patch ? Or just send me one which I can squash into this patch, either way works. Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Add myself as maintainer for the SoCrates board
On Friday, November 14, 2014 at 08:45:36 AM, Stefan Roese wrote: Signed-off-by: Stefan Roese s...@denx.de Cc: Marek Vasut ma...@denx.de Cc: Pavel Machek pa...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Vince Bridgers vbrid...@altera.com Cc: Masahiro Yamada yamad...@jp.panasonic.com Applied, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu
On Friday, November 14, 2014 at 05:54:42 PM, Lukasz Majewski wrote: Hi Marek, The following changes since commit 6a559bbe2f60ab64e28662f7ab52551a2eaa7163: usb_storage: blacklist Enclosure Service Devices (2014-11-08 12:03:35 +0100) are available in the git repository at: git://git.denx.de/u-boot-dfu.git Pulled, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dfu: thor: fix: Modify dfu_get_alt() function to support absolute paths
On Friday, November 14, 2014 at 11:39:48 AM, Lukasz Majewski wrote: Hi Lukasz, Recently the ext4 file system imposed passing absolute path with its file name parameter. As a result dfu_alt_info env variable has been modified to provide absolute path when ext4 file system is accessed (e.g. /uImage ext4 0 2;). Unfortunately, lthor flashing program provides plain file name (like uImage) and hence those two file names do not match anymore. Presented commit also allows lthor to write files to sub directories (like /boot/bin/uImage). Signed-off-by: Lukasz Majewski l.majew...@samsung.com Reviewed-by: Marek Vasut ma...@denx.de [...] +* dfu-name (uImage) +*/ + if (strlen(dfu-name) == + ((str - dfu-name) + strlen(name))) + return dfu-alt; + } } return -ENODEV; Applied to u-boot-dfu repository. Thanks It's nice to see that you're taking good care of your clones ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] arm: socfpga: Add Designware (DW) SPI support to config header
On Wednesday, November 12, 2014 at 06:53:54 PM, Pavel Machek wrote: On Fri 2014-11-07 13:50:34, Stefan Roese wrote: Enable support for the DW master SPI controller in the config header for the SoCFPGA. This controller can only be enabled, if DT support is enabled. Signed-off-by: Stefan Roese s...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Vince Bridgers vbrid...@altera.com Cc: Marek Vasut ma...@denx.de Cc: Pavel Machek pa...@denx.de --- include/configs/socfpga_common.h | 12 1 file changed, 12 insertions(+) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 9fc4212..830b956 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -191,6 +191,18 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_CMD_SF #endif +#ifdef CONFIG_OF_CONTROL /* DW SPI is controlled via DT */ +#define CONFIG_CMD_DM +#define CONFIG_DM +#define CONFIG_DM_SPI +#define CONFIG_DESIGNWARE_SPI +#ifndef __ASSEMBLY__ +unsigned int cm_get_spi_controller_clk_hz(void); +#define CONFIG_DW_SPI_REF_CLK cm_get_spi_controller_clk_hz() Putting prototypes into configuration file is ugly. Hiding function call into macro so that it looks like constant is evil. Is there better solution? The SPI driver should call this function directly. Or is there a reason why such a macro is used ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: set skew settings for ethernet phy
On Friday, November 14, 2014 at 11:23:27 AM, Pavel Machek wrote: On Thu 2014-11-13 11:23:41, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com Set the PHY skew settings for the ethernet phy on the SOCFPGA Cyclone5 hardware. Is it to need similar settings for all ksz9021 phys? Should this go to drivers/ as I suggested with a patch? This is board specific, but with the driver model, this should be moved into the PHY driver and the values should be passed via platform data or DT. I will apply this now, since it fixes real issue. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] novena: Move the DCD settings to spl code
On Friday, November 14, 2014 at 12:37:01 PM, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com mx6sabresd_spl.cfg configures CCM registers, GPR registers and CCM_CCOSR. Move the configuration to the spl code. CCM_CCOSR setting is no longer required to get audio functionality in the kernel, so remove such setting. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Board still works. Reviewed-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: set skew settings for ethernet phy
On Thursday, November 13, 2014 at 06:23:41 PM, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com Set the PHY skew settings for the ethernet phy on the SOCFPGA Cyclone5 hardware. Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com Cc: Vince Bridgers vbrid...@opensource.altera.com Cc: Pavel Machek pa...@denx.de Cc: Marek Vasut ma...@denx.de Cc: Tom Rini tr...@ti.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Wolfgang Denk w...@denx.de --- v2: Added comments on why it is necessary for setting the skew values. Applied, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] sunxi: video: Add sun6i support
On Fri, 14 Nov 2014 17:54:46 +0100 Hans de Goede hdego...@redhat.com wrote: Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/video/sunxi_display.c | 31 +++ 1 file changed, 31 insertions(+) Acked-by: Anatolij Gustschin ag...@denx.de Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] sunxi: video: Add cfb console driver for sunxi
On Fri, 14 Nov 2014 21:17:39 +0100 Anatolij Gustschin ag...@denx.de wrote: ... this patch looks good, only a few minor comments below. I forgot to mention that with these comments addressed, you can add Acked-by: Anatolij Gustschin ag...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Old u-boot was u-boot-2009.08. I guess the main source of frustration the last 3 weeks could be attributed to my lack of experience with u-boot and the fact that we were working with an old Freescale version of u-boot. Not to mention 5 years worth of changes between the versions. Most of the init functions seem to have moved in the boot sequence between u-boot-2009.08 and u-boot-2014.07. For instance, board_init was one of the first functions called before relocation to RAM, but now it called after relocation. I have our board almost fully working with mainline u-boot-2014.07, but now I'm just trying to understand a few how's and why's before continuing. In u-boot-2009.08 we set CONFIG_SKIP_RELOCATE_UBOOT. When I run with DEBUG on I confirm that no relocation messages are reported, but this is due to the fact that u-boot-2009.08 did not have debug messages pertaining to relocation (that I can tell). I'm not sure how to confirm that relocation didn't actually happen and where it actually runs from on the mx53, but I can confirm that memory tests ran all the way to the end of RAM without issue. We did run the test from within dram_init though, which would be before relocation. Too bad that doesn't work in u-boot-2014.07. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196228.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/4] mx6: thermal: Add i.MX6 CPU thermal sensor support
From: Nitin Garg nitin.g...@freescale.com
i.MX6 SoC has onchip temperature sensor. Add driver
for this sensor.
Signed-off-by: Nitin Garg nitin.g...@freescale.com
---
drivers/Makefile |1 +
drivers/thermal/Makefile |8 +++
drivers/thermal/imx_thermal.c | 144 +
include/imx_thermal.h | 15 +
4 files changed, 168 insertions(+)
create mode 100644 drivers/thermal/Makefile
create mode 100644 drivers/thermal/imx_thermal.c
create mode 100644 include/imx_thermal.h
diff --git a/drivers/Makefile b/drivers/Makefile
index 33227c8..7683c61 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -21,3 +21,4 @@ obj-y += pwm/
obj-y += input/
# SOC specific infrastructure drivers.
obj-y += soc/
+obj-y += thermal/
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
new file mode 100644
index 000..04ae395
--- /dev/null
+++ b/drivers/thermal/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2014 Freescale Semiconductor, Inc.
+# Author: Nitin Garg nitin.g...@freescale.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_IMX6_THERMAL) += imx_thermal.o
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
new file mode 100644
index 000..fe9dd85
--- /dev/null
+++ b/drivers/thermal/imx_thermal.c
@@ -0,0 +1,144 @@
+/*
+ * (C) Copyright 2014 Freescale Semiconductor, Inc.
+ * Author: Nitin Garg nitin.g...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include common.h
+#include div64.h
+#include fuse.h
+#include asm/io.h
+#include asm/arch/clock.h
+
+#define TEMPERATURE_MIN-40
+#define TEMPERATURE_HOT80
+#define TEMPERATURE_MAX125
+#define FACTOR01000
+#define FACTOR115976
+#define FACTOR24297157
+#define MEASURE_FREQ 327
+
+#define TEMPSENSE0_TEMP_CNT_SHIFT 8
+#define TEMPSENSE0_TEMP_CNT_MASK (0xfff TEMPSENSE0_TEMP_CNT_SHIFT)
+#define TEMPSENSE0_FINISHED(1 2)
+#define TEMPSENSE0_MEASURE_TEMP(1 1)
+#define TEMPSENSE0_POWER_DOWN (1 0)
+#define MISC0_REFTOP_SELBIASOFF(1 3)
+#define TEMPSENSE1_MEASURE_FREQ0x
+
+static int read_cpu_temperature(u32 fuse)
+{
+ int temperature;
+ unsigned int reg, n_meas;
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+ int t1, n1;
+ u32 c1, c2;
+ u64 temp64;
+
+ /* make sure pll3 is enabled for thermal sensor */
+ enable_pll3();
+
+ /*
+* Sensor data layout:
+* [31:20] - sensor value @ 25C
+* We use universal formula now and only need sensor value @ 25C
+* slope = 0.4297157 - (0.0015976 * 25C fuse)
+*/
+ n1 = fuse 20;
+ t1 = 25; /* t1 always 25C */
+
+ /*
+* Derived from linear interpolation:
+* slope = 0.4297157 - (0.0015976 * 25C fuse)
+* slope = (FACTOR2 - FACTOR1 * n1) / FACTOR0
+* (Nmeas - n1) / (Tmeas - t1) = slope
+* We want to reduce this down to the minimum computation necessary
+* for each temperature read. Also, we want Tmeas in millicelsius
+* and we don't want to lose precision from integer division. So...
+* Tmeas = (Nmeas - n1) / slope + t1
+* milli_Tmeas = 1000 * (Nmeas - n1) / slope + 1000 * t1
+* milli_Tmeas = -1000 * (n1 - Nmeas) / slope + 1000 * t1
+* Let constant c1 = (-1000 / slope)
+* milli_Tmeas = (n1 - Nmeas) * c1 + 1000 * t1
+* Let constant c2 = n1 *c1 + 1000 * t1
+* milli_Tmeas = c2 - Nmeas * c1
+*/
+ temp64 = FACTOR0;
+ temp64 *= 1000;
+ do_div(temp64, FACTOR1 * n1 - FACTOR2);
+ c1 = temp64;
+ c2 = n1 * c1 + 1000 * t1;
+
+ /*
+* now we only use single measure, every time we read
+* the temperature, we will power on/down anadig thermal
+* module
+*/
+ writel(TEMPSENSE0_POWER_DOWN, anatop-tempsense0_clr);
+ writel(MISC0_REFTOP_SELBIASOFF, anatop-ana_misc0_set);
+
+ /* setup measure freq */
+ reg = readl(anatop-tempsense1);
+ reg = ~TEMPSENSE1_MEASURE_FREQ;
+ reg |= MEASURE_FREQ;
+ writel(reg, anatop-tempsense1);
+
+ /* start the measurement process */
+ writel(TEMPSENSE0_MEASURE_TEMP, anatop-tempsense0_clr);
+ writel(TEMPSENSE0_FINISHED, anatop-tempsense0_clr);
+ writel(TEMPSENSE0_MEASURE_TEMP, anatop-tempsense0_set);
+
+ /* make sure that the latest temp is valid */
+ while ((readl(anatop-tempsense0)
+ TEMPSENSE0_FINISHED) == 0)
+ udelay(1);
+
+ /* read temperature count */
+ reg = readl(anatop-tempsense0);
+ n_meas = (reg TEMPSENSE0_TEMP_CNT_MASK)
+TEMPSENSE0_TEMP_CNT_SHIFT;
+ writel(TEMPSENSE0_FINISHED,
[U-Boot] [PATCH v6 0/5] add i.MX6 thermal sensor driver
From: Nitin Garg nitin.g...@freescale.com This patch set adds i.MX6 thermal sensor driver and enables it for mx6sabre boards. Also adds various anadig bit definitions as required for upcoming drivers. Changes in v6: -Aligned imx thermal driver macro defines with kernel Changes in v5: -Don't modify the copyright of cpu.c and crm_regs.h file Changes in v4: -Added imx6 thermal sensor as a driver -Renamed the config define to be more meaningful -Move the clock code to clock.c -Reusing ocotp driver for reading fuse -Fix check for calibration fuse not programmed -Aligned the slope computation with kernel -Added Anadig register defines as seperate commit Changes in v3: -adds the mx6 thermal driver support -adds the mx6 thermal support to mx6sabresd board. Changes in v2: -run checkpatch and fix reported issues Nitin Garg (4): mx6: clock: Add api to enable pll3 mx6: thermal: Add i.MX6 CPU thermal sensor support mx6: thermal: Check cpu temperature via thermal sensor mx6: thermal: Enable thermal sensor for mx6 sabre boards. arch/arm/cpu/armv7/mx6/clock.c| 25 ++ arch/arm/imx-common/cpu.c |6 ++ arch/arm/include/asm/arch-mx6/clock.h |1 + drivers/Makefile |1 + drivers/thermal/Makefile |8 ++ drivers/thermal/imx_thermal.c | 144 + include/configs/mx6sabre_common.h |3 +- include/imx_thermal.h | 15 8 files changed, 202 insertions(+), 1 deletion(-) create mode 100644 drivers/thermal/Makefile create mode 100644 drivers/thermal/imx_thermal.c create mode 100644 include/imx_thermal.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 3/4] mx6: thermal: Check cpu temperature via thermal sensor
From: Nitin Garg nitin.g...@freescale.com read cpu temperature using the onchip thermal sensor. Signed-off-by: Nitin Garg nitin.g...@freescale.com --- arch/arm/imx-common/cpu.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c index 09fc227..441c484 100644 --- a/arch/arm/imx-common/cpu.c +++ b/arch/arm/imx-common/cpu.c @@ -17,6 +17,7 @@ #include asm/arch/sys_proto.h #include asm/arch/crm_regs.h #include ipu_pixfmt.h +#include imx_thermal.h #ifdef CONFIG_FSL_ESDHC #include fsl_esdhc.h @@ -141,6 +142,11 @@ int print_cpuinfo(void) (cpurev 0x000F0) 4, (cpurev 0xF) 0, mxc_get_clock(MXC_ARM_CLK) / 100); + +#if defined(CONFIG_MX6) defined(CONFIG_IMX6_THERMAL) + check_cpu_temperature(); +#endif + printf(Reset cause: %s\n, get_reset_cause()); return 0; } -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 4/4] mx6: thermal: Enable thermal sensor for mx6 sabre boards.
From: Nitin Garg nitin.g...@freescale.com Add CONFIG_IMX6_THERMAL to mx6sabre_common.h file. Since thermal driver depends on ocotp, make sure to enable CONFIG_MXC_OCOTP when CONFIG_IMX6_THERMAL is slected. Signed-off-by: Nitin Garg nitin.g...@freescale.com --- include/configs/mx6sabre_common.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index c81e9e9..7db06fe 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -24,6 +24,7 @@ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG #define CONFIG_REVISION_TAG +#define CONFIG_IMX6_THERMAL #define CONFIG_SYS_GENERIC_BOARD @@ -37,7 +38,7 @@ #define CONFIG_MXC_UART #define CONFIG_CMD_FUSE -#ifdef CONFIG_CMD_FUSE +#if defined(CONFIG_CMD_FUSE) || defined(CONFIG_IMX6_THERMAL) #define CONFIG_MXC_OCOTP #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 1/4] mx6: clock: Add api to enable pll3
From: Nitin Garg nitin.g...@freescale.com
Add api to check and enable pll3 as required
for thermal sensor driver.
Signed-off-by: Nitin Garg nitin.g...@freescale.com
---
arch/arm/cpu/armv7/mx6/clock.c| 25 +
arch/arm/include/asm/arch-mx6/clock.h |1 +
2 files changed, 26 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 6c9c78c..e174b91 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -673,6 +673,31 @@ void hab_caam_clock_enable(unsigned char enable)
}
#endif
+void enable_pll3(void)
+{
+ struct anatop_regs __iomem *anatop =
+ (struct anatop_regs __iomem *)ANATOP_BASE_ADDR;
+
+ /* make sure pll3 is enabled */
+ if ((readl(anatop-usb1_pll_480_ctrl)
+ BM_ANADIG_USB1_PLL_480_CTRL_LOCK) == 0) {
+ /* enable pll's power */
+ writel(BM_ANADIG_USB1_PLL_480_CTRL_POWER,
+ anatop-usb1_pll_480_ctrl_set);
+ writel(0x80, anatop-ana_misc2_clr);
+ /* wait for pll lock */
+ while ((readl(anatop-usb1_pll_480_ctrl)
+ BM_ANADIG_USB1_PLL_480_CTRL_LOCK) == 0)
+ ;
+ /* disable bypass */
+ writel(BM_ANADIG_USB1_PLL_480_CTRL_BYPASS,
+ anatop-usb1_pll_480_ctrl_clr);
+ /* enable pll output */
+ writel(BM_ANADIG_USB1_PLL_480_CTRL_ENABLE,
+ anatop-usb1_pll_480_ctrl_set);
+ }
+}
+
unsigned int mxc_get_clock(enum mxc_clock clk)
{
switch (clk) {
diff --git a/arch/arm/include/asm/arch-mx6/clock.h
b/arch/arm/include/asm/arch-mx6/clock.h
index 3c58a0a..b42d942 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -66,4 +66,5 @@ int enable_spi_clk(unsigned char enable, unsigned spi_num);
void enable_ipu_clock(void);
int enable_fec_anatop_clock(enum enet_freq freq);
void enable_enet_clk(unsigned char enable);
+void enable_pll3(void);
#endif /* __ASM_ARCH_CLOCK_H */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 2/6] fat: prepare for API change for files greater than 2GB
Hello Simon,
On Tue, Nov 11, 2014 at 4:27 PM, Simon Glass s...@chromium.org wrote:
Hi,
On 10 November 2014 13:17, Suriyan Ramasami suriya...@gmail.com wrote:
Change the internal fat functions to use loff_t for offsets.
Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---
Changes in v7:
* Split it so that its bisectable.
A few bits below but with these fixed:
Acked-by: Simon Glass s...@chromium.org
common/cmd_fat.c | 9 ++--
common/env_fat.c | 4 +-
fs/fat/fat.c | 133
+++--
fs/fat/fat_write.c | 61 +---
fs/fat/file.c | 4 +-
include/fat.h | 13 +++---
6 files changed, 128 insertions(+), 96 deletions(-)
diff --git a/common/cmd_fat.c b/common/cmd_fat.c
index 633fbf1..c00fb28 100644
--- a/common/cmd_fat.c
+++ b/common/cmd_fat.c
@@ -100,7 +100,8 @@ U_BOOT_CMD(
static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
{
- long size;
+ loff_t size;
+ int ret;
unsigned long addr;
unsigned long count;
block_dev_desc_t *dev_desc = NULL;
@@ -127,15 +128,15 @@ static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
count = simple_strtoul(argv[5], NULL, 16);
buf = map_sysmem(addr, count);
- size = file_fat_write(argv[4], buf, count);
+ ret = file_fat_write(argv[4], buf, 0, count, size);
unmap_sysmem(buf);
- if (size == -1) {
+ if (ret 0) {
printf(\n** Unable to write \%s\ from %s %d:%d **\n,
argv[4], argv[1], dev, part);
return 1;
}
- printf(%ld bytes written\n, size);
+ printf(%llu bytes written\n, size);
return 0;
}
diff --git a/common/env_fat.c b/common/env_fat.c
index 8db0160..9a6ce63 100644
--- a/common/env_fat.c
+++ b/common/env_fat.c
@@ -41,6 +41,7 @@ int saveenv(void)
disk_partition_t info;
int dev, part;
int err;
+ loff_t size;
err = env_export(env_new);
if (err)
@@ -59,7 +60,8 @@ int saveenv(void)
return 1;
}
- err = file_fat_write(FAT_ENV_FILE, (void *)env_new, sizeof(env_t));
+ err = file_fat_write(FAT_ENV_FILE, (void *)env_new, sizeof(env_t),
+size);
if (err == -1) {
printf(\n** Unable to write \%s\ from %s%d:%d **\n,
FAT_ENV_FILE, FAT_ENV_INTERFACE, dev, part);
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 561921f..29d0825 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -317,32 +317,33 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8
*buffer, unsigned long size)
/*
* Read at most 'maxsize' bytes from 'pos' in the file associated with
'dentptr'
* into 'buffer'.
- * Return the number of bytes read or -1 on fatal errors.
+ * Update the number of bytes read in *gotsize or return -1 on fatal errors.
*/
__u8 get_contents_vfatname_block[MAX_CLUSTSIZE]
__aligned(ARCH_DMA_MINALIGN);
-static long
-get_contents(fsdata *mydata, dir_entry *dentptr, unsigned long pos,
-__u8 *buffer, unsigned long maxsize)
+static int
put this on the same line as the next
OK
+get_contents(fsdata *mydata, dir_entry *dentptr, loff_t pos,
+__u8 *buffer, loff_t maxsize, loff_t *gotsize)
{
- unsigned long filesize = FAT2CPU32(dentptr-size), gotsize = 0;
+ loff_t filesize = FAT2CPU32(dentptr-size);
unsigned int bytesperclust = mydata-clust_size * mydata-sect_size;
__u32 curclust = START(dentptr);
__u32 endclust, newclust;
- unsigned long actsize;
+ loff_t actsize;
- debug(Filesize: %ld bytes\n, filesize);
+ *gotsize = 0;
+ debug(Filesize: %llu bytes\n, filesize);
if (pos = filesize) {
- debug(Read position past EOF: %lu\n, pos);
- return gotsize;
+ debug(Read position past EOF: %llu\n, pos);
+ return 0;
}
if (maxsize 0 filesize pos + maxsize)
filesize = pos + maxsize;
- debug(%ld bytes\n, filesize);
+ debug(%llu bytes\n, filesize);
actsize = bytesperclust;
@@ -352,7 +353,7 @@ get_contents(fsdata *mydata, dir_entry *dentptr,
unsigned long pos,
if (CHECK_CLUST(curclust, mydata-fatsize)) {
debug(curclust: 0x%x\n, curclust);
debug(Invalid FAT entry\n);
- return gotsize;
+ return 0;
}
actsize += bytesperclust;
}
@@ -373,16 +374,16 @@ get_contents(fsdata *mydata, dir_entry *dentptr,
unsigned long pos,
filesize -= actsize;
actsize -= pos;
memcpy(buffer, get_contents_vfatname_block + pos, actsize);
-
