Re: [U-Boot] [PATCH] usb: dfu: add static alt num count in dfu_config_entities()
Hello Lukasz, Am 04.03.2014 12:33, schrieb Lukasz Majewski: Hi Heiko, Thanks to this multiple call of function dfu_config_entities() gives continuous dfu alt numbering until call dfu_free_entities(). This allows to store dfu entities in multiple variables. Could you test this patch on your boards, which are using DFU? Done on the dxr2 board. All works as before. Thanks in advance. Signed-off-by: Przemyslaw Marczak Acked-by: Łukasz Majewski --- drivers/dfu/dfu.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Tested on the dxr2 board. Tested-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] usb start crashing on arndale
Hi, We have recently started working on arndale and running u-boot head on it. Seems like it is crashing on our setup with a data abort on usb start. Can anyone please confirm and suggest a fix / solution U-Boot 2014.04-rc1-00486-geeb72e6 (Mar 11 2014 - 11:44:32) for ARNDALE CPU:Exynos5250@1000MHz Board: Arndale I2C: i2c_init: failed to init bus 0 for speed = 10 ready DRAM: 2 GiB trace: copying 00084f98 bytes of early data from 5000 to beff trace: enabled WARNING: Caches not enabled MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 i2c_init: failed to init bus 0 for speed = 10 In:serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 ARNDALE # usb start (Re)start USB... USB0: data abort pc : [] lr : [] sp : beb5f9c0 ip : 0003 fp : r10: r9 : beb62ecc r8 : befbcc80 r7 : befbcc84 r6 : r5 : 00ff r4 : 0001 r3 : r2 : 0001 r1 : 00ff r0 : Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... Thanks and Regards Armdev@FTM Team ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: exynos: Squash bogus warnings in pinmux
Hi
Acked-by: Rajeshwari S Shinde
Regards,
Rajeshwari
On Tue, Mar 11, 2014 at 12:56 AM, Simon Glass wrote:
> Hi Marek,
>
> On 10 March 2014 13:04, Marek Vasut wrote:
>> Squash these warnings in pinmux.c found with GCC 4.8:
>>
>> /arch/arm/cpu/armv7/exynos/pinmux.c: In function 'exynos_pinmux_config':
>> /arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'count' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> for (i = start; i < start + count; i++) {
>> ^
>> /arch/arm/cpu/armv7/exynos/pinmux.c:663:16: note: 'count' was declared here
>> int i, start, count;
>> ^
>> /arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'start' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> for (i = start; i < start + count; i++) {
>> ^
>> /arch/arm/cpu/armv7/exynos/pinmux.c:663:9: note: 'start' was declared here
>> int i, start, count;
>> ^
>> /arch/arm/cpu/armv7/exynos/pinmux.c:689:19: warning: 'bank' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
>>^
>> /arch/arm/cpu/armv7/exynos/pinmux.c:662:24: note: 'bank' was declared here
>> struct s5p_gpio_bank *bank;
>> ^
>> /arch/arm/cpu/armv7/exynos/pinmux.c: In function 'exynos_pinmux_config':
>> /arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'count' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> for (i = start; i < start + count; i++) {
>> ^
>> /arch/arm/cpu/armv7/exynos/pinmux.c:663:16: note: 'count' was declared here
>> int i, start, count;
>> ^
>> /arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'start' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> for (i = start; i < start + count; i++) {
>> ^
>> /arch/arm/cpu/armv7/exynos/pinmux.c:663:9: note: 'start' was declared here
>> int i, start, count;
>> ^
>> /arch/arm/cpu/armv7/exynos/pinmux.c:689:19: warning: 'bank' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
>>^
>> /arch/arm/cpu/armv7/exynos/pinmux.c:662:24: note: 'bank' was declared here
>> struct s5p_gpio_bank *bank;
>> ^
>>
>> Note that the warning is bogus, the function can never be called with invalid
>> 'peripheral' argument. GCC just cannot analyze this.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Naveen Krishna Chatradhi
>> Cc: Akshay Saraswat
>> Cc: Rajeshwari S Shinde
>> Cc: Simon Glass
>> Cc: Minkyu Kang
>> Cc: Tom Rini
>
> Acked-by: Simon Glass
>
> Thanks Marek, great to get that annoyance fixed.
>
> Regards,
> Simon
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
--
Regards,
Rajeshwari Shinde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] data abort on usb start, arndale
Hi, We have recently started working on arndale and running u-boot head on it. Seems like it is crashing on our setup with a data abort on usb start. Can anyone please confirm and suggest a fix / solution Our last mail was stuck in moderation, sending again U-Boot 2014.04-rc1-00486-geeb72e6 (Mar 11 2014 - 11:44:32) for ARNDALE CPU:Exynos5250@1000MHz Board: Arndale I2C: i2c_init: failed to init bus 0 for speed = 10 ready DRAM: 2 GiB trace: copying 00084f98 bytes of early data from 5000 to beff trace: enabled WARNING: Caches not enabled MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 i2c_init: failed to init bus 0 for speed = 10 In:serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 ARNDALE # usb start (Re)start USB... USB0: data abort pc : [] lr : [] sp : beb5f9c0 ip : 0003 fp : r10: r9 : beb62ecc r8 : befbcc80 r7 : befbcc84 r6 : r5 : 00ff r4 : 0001 r3 : r2 : 0001 r1 : 00ff r0 : Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... Thanks and Regards Armdev@FTM Team ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v5] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core.
So removing the invalidation from start.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM
code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house
keeping area. This configuration is to be disabled once in uboot.
Earlier this disabling of CPC as SRAM was happening in cpu_init_r.
As a result cache invalidation function was getting skipped in
case CPC is configured as SRAM.This was causing random crashes.
Signed-off-by: Aneesh Bansal
Signed-off-by: Aneesh Bansal
---
README | 4
arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++-
arch/powerpc/cpu/mpc85xx/start.S | 3 ++-
arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++
boards.cfg | 1 +
5 files changed, 35 insertions(+), 6 deletions(-)
Changes from v4:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry to
CONFIG_SYS_CPC_REINIT_F
diff --git a/README b/README
index 216f0c7..e574d68 100644
--- a/README
+++ b/README
@@ -427,6 +427,10 @@ The following options need to be configured:
In this mode, a single differential clock is used to supply
clocks to the sysclock, ddrclock and usbclock.
+ CONFIG_SYS_CPC_REINIT_F
+ This CONFIG is defined when the CPC is configured as SRAM at the
+ time of U-boot entry and is required to be re-initialized.
+
- Generic CPU options:
CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 81aeadd..570965f 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -173,17 +173,14 @@ void config_8560_ioports (volatile ccsr_cpm_t * cpm)
#endif
#ifdef CONFIG_SYS_FSL_CPC
-static void enable_cpc(void)
+#if defined(CONFIG_RAMBOOT_PBL) || defined(CONFIG_SYS_CPC_REINIT_F)
+static void disable_cpc_sram(void)
{
int i;
- u32 size = 0;
cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) {
- u32 cpccfg0 = in_be32(&cpc->cpccfg0);
- size += CPC_CFG0_SZ_K(cpccfg0);
-#ifdef CONFIG_RAMBOOT_PBL
if (in_be32(&cpc->cpcsrcr0) & CPC_SRCR0_SRAMEN) {
/* find and disable LAW of SRAM */
struct law_entry law =
find_law(CONFIG_SYS_INIT_L3_ADDR);
@@ -198,8 +195,21 @@ static void enable_cpc(void)
out_be32(&cpc->cpccsr0, 0);
out_be32(&cpc->cpcsrcr0, 0);
}
+ }
+}
#endif
+static void enable_cpc(void)
+{
+ int i;
+ u32 size = 0;
+
+ cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
+
+ for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) {
+ u32 cpccfg0 = in_be32(&cpc->cpccfg0);
+ size += CPC_CFG0_SZ_K(cpccfg0);
+
#ifdef CONFIG_SYS_FSL_ERRATUM_CPC_A002
setbits_be32(&cpc->cpchdbcr0, CPC_HDBCR0_TAG_ECC_SCRUB_DIS);
#endif
@@ -298,6 +308,10 @@ void cpu_init_f (void)
law = find_law(CONFIG_SYS_PBI_FLASH_BASE);
if (law.index != -1)
disable_law(law.index);
+
+#if defined(CONFIG_SYS_CPC_REINIT_F)
+ disable_cpc_sram();
+#endif
#endif
#ifdef CONFIG_CPM2
@@ -598,6 +612,9 @@ skip_l2:
puts("disabled\n");
#endif
+#if defined(CONFIG_RAMBOOT_PBL)
+ disable_cpc_sram();
+#endif
enable_cpc();
#ifndef CONFIG_SYS_FSL_NO_SERDES
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index dbbd8e5..4ef0985 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -115,7 +115,8 @@ _start_e500:
#endif
-#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC)
+#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC) && \
+ !defined(CONFIG_E6500)
/* ISBC uses L2 as stack.
* Disable L2 cache here so that u-boot can enable it later
* as part of it's normal flow
diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h
b/arch/powerpc/include/asm/fsl_secure_boot.h
index 4c7f0b1..8f5bf10 100644
--- a/arch/powerpc/include/asm/fsl_secure_boot.h
+++ b/arch/powerpc/include/asm/fsl_secure_boot.h
@@ -15,5 +15,11 @@
#endif
#define CONFIG_SYS_PBI_FLASH_WINDOW0xcff8
+#if defined(CONFIG_B4860QDS)
+#define CONFIG_SYS_CPC_REINIT_F
+#undef CONFIG_SYS_INIT_L3_ADDR
+#define CONFIG_SYS_INIT_L3_ADDR0xbff0
+#endif
+
#endif
#endif
diff --git a/boards.cfg b/boards.cfg
index a32f46b..cf2b1df 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -782,6 +782,7 @@ Active powerpc mpc85xx- freescale
b4860qds
Active powerpc mpc85xx- freescale
Re: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
> -Original Message- > From: Sun York-R58495 > Sent: Tuesday, March 11, 2014 5:31 AM > To: Wood Scott-B07421 > Cc: Bansal Aneesh-B39320; u-boot@lists.denx.de; Gupta Ruchika-R66431 > Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot > target for B4860QDS > > On 03/10/2014 04:55 PM, Scott Wood wrote: > > On Mon, 2014-03-10 at 08:38 -0700, York Sun wrote: > >> On 03/10/2014 02:14 AM, Bansal Aneesh-B39320 wrote: > -Original Message- > From: Sun York-R58495 > Sent: Saturday, March 08, 2014 12:01 AM > To: Bansal Aneesh-B39320; u-boot@lists.denx.de > Cc: Wood Scott-B07421 > Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure > boot target for B4860QDS > > Do you see the need to disable CPC before relocation? You are > doing > so in this patch. Does the temporary LAW or address conflict with > u-boot? > >>> Earlier we were disabling cpc in cpu_init_r. However since cache > invalidation function was getting skipped in the process, it was > causing random crashes. Skipping invalidation works in RAMBOOT > scenario, however since we don’t have valid data when CPC is > configured as cache for the secure boot scenario which is not RAMBOOT, > these crashes were occurring in few platforms. As a result we had to > move this disable code early in the sequence, so that invalidation of > cache doesn’t get skipped. > > >> > >> As I suggested, if you have to do this before relocation, a macro > >> CONFIG_SYS_CPC_REINIT_F makes more sense. > > > > How hard would it be to check the status of CPC at runtime, or just > > unconditionally reinit (for non-ramboot)? > > That's what I was suggesting. > > > > > I don't think I ever saw an answer to the question of what harm it > > does to leave CPC alone until the normal place where we init CPC. > > > > Aneesh seems to believe disabling and re-initializing CPC in > cpu_inti_r is too late for SECURE BOOT. > > York > Yes, we have seen random crashes occur during Secure Boot if CPC is not disabled before cache invalidation and re-initialization. Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v6] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core.
So removing the invalidation from start.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM
code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house
keeping area. This configuration is to be disabled once in uboot.
Earlier this disabling of CPC as SRAM was happening in cpu_init_r.
As a result cache invalidation function was getting skipped in
case CPC is configured as SRAM.This was causing random crashes.
Signed-off-by: Aneesh Bansal
Signed-off-by: Ruchika Gupta
---
README | 4
arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++-
arch/powerpc/cpu/mpc85xx/start.S | 3 ++-
arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++
boards.cfg | 1 +
5 files changed, 35 insertions(+), 6 deletions(-)
Changes from v4:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry to
CONFIG_SYS_CPC_REINIT_F
Changes from v5:
Corrected the Signed Off
diff --git a/README b/README
index 216f0c7..e574d68 100644
--- a/README
+++ b/README
@@ -427,6 +427,10 @@ The following options need to be configured:
In this mode, a single differential clock is used to supply
clocks to the sysclock, ddrclock and usbclock.
+ CONFIG_SYS_CPC_REINIT_F
+ This CONFIG is defined when the CPC is configured as SRAM at the
+ time of U-boot entry and is required to be re-initialized.
+
- Generic CPU options:
CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 81aeadd..570965f 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -173,17 +173,14 @@ void config_8560_ioports (volatile ccsr_cpm_t * cpm)
#endif
#ifdef CONFIG_SYS_FSL_CPC
-static void enable_cpc(void)
+#if defined(CONFIG_RAMBOOT_PBL) || defined(CONFIG_SYS_CPC_REINIT_F)
+static void disable_cpc_sram(void)
{
int i;
- u32 size = 0;
cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) {
- u32 cpccfg0 = in_be32(&cpc->cpccfg0);
- size += CPC_CFG0_SZ_K(cpccfg0);
-#ifdef CONFIG_RAMBOOT_PBL
if (in_be32(&cpc->cpcsrcr0) & CPC_SRCR0_SRAMEN) {
/* find and disable LAW of SRAM */
struct law_entry law =
find_law(CONFIG_SYS_INIT_L3_ADDR);
@@ -198,8 +195,21 @@ static void enable_cpc(void)
out_be32(&cpc->cpccsr0, 0);
out_be32(&cpc->cpcsrcr0, 0);
}
+ }
+}
#endif
+static void enable_cpc(void)
+{
+ int i;
+ u32 size = 0;
+
+ cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
+
+ for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) {
+ u32 cpccfg0 = in_be32(&cpc->cpccfg0);
+ size += CPC_CFG0_SZ_K(cpccfg0);
+
#ifdef CONFIG_SYS_FSL_ERRATUM_CPC_A002
setbits_be32(&cpc->cpchdbcr0, CPC_HDBCR0_TAG_ECC_SCRUB_DIS);
#endif
@@ -298,6 +308,10 @@ void cpu_init_f (void)
law = find_law(CONFIG_SYS_PBI_FLASH_BASE);
if (law.index != -1)
disable_law(law.index);
+
+#if defined(CONFIG_SYS_CPC_REINIT_F)
+ disable_cpc_sram();
+#endif
#endif
#ifdef CONFIG_CPM2
@@ -598,6 +612,9 @@ skip_l2:
puts("disabled\n");
#endif
+#if defined(CONFIG_RAMBOOT_PBL)
+ disable_cpc_sram();
+#endif
enable_cpc();
#ifndef CONFIG_SYS_FSL_NO_SERDES
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index dbbd8e5..4ef0985 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -115,7 +115,8 @@ _start_e500:
#endif
-#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC)
+#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC) && \
+ !defined(CONFIG_E6500)
/* ISBC uses L2 as stack.
* Disable L2 cache here so that u-boot can enable it later
* as part of it's normal flow
diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h
b/arch/powerpc/include/asm/fsl_secure_boot.h
index 4c7f0b1..8f5bf10 100644
--- a/arch/powerpc/include/asm/fsl_secure_boot.h
+++ b/arch/powerpc/include/asm/fsl_secure_boot.h
@@ -15,5 +15,11 @@
#endif
#define CONFIG_SYS_PBI_FLASH_WINDOW0xcff8
+#if defined(CONFIG_B4860QDS)
+#define CONFIG_SYS_CPC_REINIT_F
+#undef CONFIG_SYS_INIT_L3_ADDR
+#define CONFIG_SYS_INIT_L3_ADDR0xbff0
+#endif
+
#endif
#endif
diff --git a/boards.cfg b/boards.cfg
index a32f46b..cf2b1df 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -782,6 +782,7 @@ Active powerpc mpc85xx- freescale
b4860qds
Active power
Re: [U-Boot] [PATCH 05/12] kbuild: delete redundant LDSCRIPT definition
On 03/11/2014 03:05 AM, Masahiro Yamada wrote:
> $(SRCTREE)/$(CPUDIR)/u-boot.lds is our default location
> of arch-specific linker script.
>
> Remove redundant definitions in
> arch/{arc,microblaze,openrisc}/config.mk.
>
> Signed-off-by: Masahiro Yamada
> Cc: Alexey Brodkin
> Cc: Michal Simek
> Cc: Stefan Kristiansson
for Microblaze
Acked-by: Michal Simek
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] socfpga: Add socfpga preloader signing to mkimage
Hello Charles, Gerhard, > > > Is there any (real, technical) reason why the bzip stuff (the > > > CRC-32 calculation that has been made available separately) > > > cannot get built and used as a library, and the tools/ > > > application just gets linked against it as one would expect? > > > > From my limited understanding, lib/ is not built for the host. It is only > > built for the target. That is why we have all these ugly C files: crc32.c, > > sha1.c,... in tools/. > > With Kbuild, is the '#include "../otherdir/source.c" trick still > needed? Would a list of object files with relative path specs > work, or can object files in one output directory result from > compile units taken out of several source directories? In this case, object files with relative path such as "../lib/foo.o" does not work. If we write ../lib/foo.o in tools/Makefile, $(HOSTCC) will compile foo.o into lib/ directory. And lator it will be overwritten with the one compiled with $(CC). I thought this is a simple way to generate two objects from one source file, one is for hostprogs in tools/ and the other for the target in lib/. BTW, I sometimes see #include for "*.c" for example, drivers/usb/host/ehci-hcd.c of Linux Kernel, although I admit it is ugly. I agree we need to do something with it, but it's beyond the scope of this patch. > diff --git a/spl/Makefile b/spl/Makefile > index 346d0aa..4e0f33f 100644 > --- a/spl/Makefile > +++ b/spl/Makefile > @@ -182,6 +182,11 @@ MLO MLO.byteswap: $(obj)/u-boot-spl.bin > > ALL-y+= $(obj)/$(SPL_BIN).bin > > +$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin > + $(OBJTREE)/tools/mkimage -T socfpgaimage -d $< $@ > + > +ALL-$(CONFIG_SOCFPGA) += $(OBJTREE)/socfpga-signed-preloader.bin > + > ifdef CONFIG_SAMSUNG > ALL-y+= $(obj)/$(BOARD)-spl.bin > endif Could you re-write this part as follows, please? diff --git a/spl/Makefile b/spl/Makefile index bb3d349..9f3893e 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -184,6 +184,12 @@ MLO MLO.byteswap: $(obj)/u-boot-spl.bin ALL-y += $(obj)/$(SPL_BIN).bin +MKIMAGEFLAGS_socfpga-signed-preloader.bin := -T socfpgaimage +socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin + $(call cmd,mkimage) + +ALL-$(CONFIG_SOCFPGA) += socfpga-signed-preloader.bin + ifdef CONFIG_SAMSUNG ALL-y += $(obj)/$(BOARD)-spl.bin endif Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kbuild: delete *.pyc files by "make distclean"
The tools "buildman" and "patman" are written Python. When we run them, "*.pyc" files are created under tools/buildman, tools/patman directories. They should be cleaned up by "make distclean". Signed-off-by: Masahiro Yamada Cc: Simon Glass Cc: Tom Rini --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c8d5ccc..538c3bf 100644 --- a/Makefile +++ b/Makefile @@ -1228,7 +1228,7 @@ distclean: mrproper @find $(srctree) $(RCS_FIND_IGNORE) \ \( -name '*.orig' -o -name '*.rej' -o -name '*~' \ -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \ - -o -name '.*.rej' \ + -o -name '.*.rej' -o -name '*.pyc' \ -o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \ -type f -print | xargs rm -f -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)
Adding u-boot list since I think this is a general issue/question. On Sun, 2014-03-09 at 20:00 +0100, Olliver Schinagl wrote: > On 03/09/14 16:18, tyler.ba...@linaro.org wrote: > > On Sunday, March 9, 2014 8:06:27 AM UTC-7, tyler...@linaro.org wrote: > >> Hello, > >> > >> I am trying to boot the cubietruck with a minimal ramdisk. However, it > >> seems to hang at "Starting kernel..." whenever I pass bootz a > >> ramdisk load address. [...] > > Turl help me solve this in IRC. Needed to setenv initrd_high > > '0x' in case anyone else runs into this. > The http://linux-sunxi.org/Mainline_Kernel_Howto did mention this ;) but > thanks for helping remind people! Actually it mentions fdt_high but not initrd_high. But what is the reason for the default behaviour of bootz doing things which do not conform to linux/Documentation/arm/Booting and therefore is not going to boot? The docs recommend that DTB and initrd go just after the 128MB boundary. If either are loaded "too high" then the kernel will crash on boot, often in a tricky to diagnose way (I've chased it down more than once). It's especially annoying when one has carefully loaded everything at a suitable address in the first place ;-) Should the global default be changed to either 0x (no relocation) or to start-of-ram+256MB (which should satisfy the kernels requirements without needing logic changes to handle "just after the 128MB boundary" as a concept). Or is it intended that each board should opt-in to a sensible default via their default environment? Does bootm suffer the same? I suspect it does, at least for fdt (since initrd has a load addr in the u-boot header). Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2014.04-rc2 released
Hi Tom, On Mon, 10 Mar 2014 17:28:42 -0400, Tom Rini wrote: > Hey all, > > I've pushed v2014.04-rc2 out to the repository and tarballs should exist > soon. > > The good news this time around is Masahiro did some more updates to the > system and we're now building faster than before. This should be > noticable in both the single config build and arch/soc/vendor/etc > builds. I can confirm this. Thanks Masahiro! > As always, if anything is broken please speak up. > > Thanks all! Also, u-boot-arm/master and /next have been fast-forwarded to u-boot/master. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] boards.cfg: move boards with invalid emails to Orphan
Hi Masahiro, On Tue, 11 Mar 2014 12:19:12 +0900, Masahiro Yamada wrote: > When I cc board maintainers, some of them result in > bounce mails. > > It turned out the following do not work any more: > Yuli Barcohen > Travis Sawyer > Yusdi Santoso > David Updegraff > Sangmoon Kim > Anton Vorontsov > Blackfin Team > Bluetechnix Tinyboards > Andre Schwarz > > For the blackfin boards where Sonic Zhang is also listed > as a maintainer, dead addresses should be simply dropped. > > For all of the others, the status should be changed to "Orphan". > > We have adopted the definition of "Orphan" as: > board is not actively maintained any more but still builds, and any > address associated with it is that of the last known maintainer(s) > > Even though the emails do not work any more, they carry information. > We want to keep them. > > Besides, Orphan boards have been collected at the bottom of boards.cfg. > (This is done when we run "tools/reformat.py") > > Add separators to distinguish them from those which > were moved to Orphan 6 months ago. > I believe it will be helpful in future to find which boards are > old enough to be removed from the code base. Agreed up to and including the above. However, it seems you have not applied tools/reformat.py as requested in the file header: after I have applied your patch, running reformat.py led to some lines being reorganized in boards.cfg. Can you fix, check, and send V2? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] boards.cfg: move boards with invalid emails to Orphan
Hello Albert, > > Besides, Orphan boards have been collected at the bottom of boards.cfg. > > (This is done when we run "tools/reformat.py") > > > > Add separators to distinguish them from those which > > were moved to Orphan 6 months ago. > > I believe it will be helpful in future to find which boards are > > old enough to be removed from the code base. > > Agreed up to and including the above. However, it seems you have not > applied tools/reformat.py as requested in the file header: after > I have applied your patch, running reformat.py led to some lines being > reorganized in boards.cfg. Yes. It is intentinal. I think touching other boards is beyond the scope of this patch and obscures the purpose of this patch. I leave it for a dedicated patch. I expect Fabio Estevam will periodically post patches like commit 0876703cf and sort boards.cfg. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/12] kbuild, mxs: use short logs for MXS images
On Tuesday, March 11, 2014 at 03:05:11 AM, Masahiro Yamada wrote: > Signed-off-by: Masahiro Yamada > Cc: Marek Vasut > Cc: Fabio Estevam > Cc: Otavio Salvador > Cc: Lauri Hintsala You can drop Lauri from CC , I think this address is dead. > --- > > Hi MXS board maitainers, > > I think this commit is probably correct. > (I mean, it still generates correct "u-boot.sb" image) > > But I could not corfirm it by binary comparison. > > Every build generates a different u-boot.sb > even if no source file is changed. Note sure about that: marex@bfu:/tmp/u-boot$ make -j9 u-boot.sb CHK include/config/uboot.release CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h UPD include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h HOSTCC tools/dumpimage.o HOSTCC tools/image-host.o HOSTCC tools/mkenvimage.o HOSTCC tools/mkimage.o HOSTLD tools/envcrc HOSTLD tools/mkenvimage HOSTLD tools/dumpimage HOSTLD tools/mkimage AS arch/arm/cpu/arm926ejs/start.o CC arch/arm/lib/board.o CC drivers/video/cfb_console.o LD arch/arm/lib/built-in.o CC lib/display_options.o CC common/main.o CC common/cmd_version.o AS spl/arch/arm/cpu/arm926ejs/mxs/start.o LD lib/built-in.o CC spl/lib/display_options.o LD spl/lib/built-in.o LD spl/u-boot-spl OBJCOPY spl/u-boot-spl.bin LD common/built-in.o LD drivers/video/built-in.o LD drivers/built-in.o LD u-boot OBJCOPY u-boot.bin MXSIMAGE u-boot.sb marex@bfu:/tmp/u-boot$ sha1sum u-boot.bin a31b6fb66fab4a0f05634987585140ffe463452e u-boot.bin marex@bfu:/tmp/u-boot$ make -j9 u-boot.sb CHK include/config/uboot.release CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CHK include/generated/version_autogenerated.h HOSTCC tools/dumpimage.o HOSTCC tools/image-host.o HOSTCC tools/mkenvimage.o HOSTCC tools/mkimage.o HOSTLD tools/envcrc HOSTLD tools/mkenvimage HOSTLD tools/dumpimage HOSTLD tools/mkimage AS arch/arm/cpu/arm926ejs/start.o CC arch/arm/lib/board.o CC drivers/video/cfb_console.o LD arch/arm/lib/built-in.o CC lib/display_options.o CC common/main.o CC common/cmd_version.o AS spl/arch/arm/cpu/arm926ejs/mxs/start.o CC spl/lib/display_options.o LD lib/built-in.o LD spl/lib/built-in.o LD spl/u-boot-spl OBJCOPY spl/u-boot-spl.bin LD common/built-in.o LD drivers/video/built-in.o LD drivers/built-in.o LD u-boot OBJCOPY u-boot.bin MXSIMAGE u-boot.sb marex@bfu:/tmp/u-boot$ sha1sum u-boot.bin b5d5feab4a6974fe00272d3a3408300d8c8a473d u-boot.bin Given that u-boot.bin and spl/u-boot-spl.bin are packed into u-boot.sb , this is why you always see a different u-boot.sb . > I wish someone could do run test this patch. The patch is good, I have just a minor rant below, otherwise add my: Acked-by: Marek Vasut btw. you can check if the image was not corrupted by issuing: $ mkimage -l u-boot.sb ;-) [...] > diff --git a/arch/arm/cpu/arm926ejs/mxs/Makefile > b/arch/arm/cpu/arm926ejs/mxs/Makefile index 152546e..1eee661 100644 > --- a/arch/arm/cpu/arm926ejs/mxs/Makefile > +++ b/arch/arm/cpu/arm926ejs/mxs/Makefile > @@ -14,11 +14,12 @@ obj-y += spl_boot.o spl_lradc_init.o spl_mem_init.o > spl_power_init.o endif > > # Specify the target for use in elftosb call > -MKIMAGE_TARGET-$(CONFIG_MX23) = mx23 > -MKIMAGE_TARGET-$(CONFIG_MX28) = mx28 > +MKIMAGE_TARGET-$(CONFIG_MX23) = mxsimage.mx23.cfg > +MKIMAGE_TARGET-$(CONFIG_MX28) = mxsimage.mx28.cfg > > -$(OBJTREE)/mxsimage.cfg: > $(SRCTREE)/$(CPUDIR)/$(SOC)/mxsimage.$(MKIMAGE_TARGET-y).cfg -sed > "s@OBJTREE@$(OBJTREE)@g" $^ > $@ > +quiet_cmd_mkimage_mxs = UIMAGE $@ Why don't we use 'MKIMAGE' here to be consistent ? Or 'MXSIMAGE' if we want to differentiate ? > +cmd_mkimage_mxs = $(objtree)/tools/mkimage -n $< -T mxsimage $@ \ > + $(if $(KBUILD_VERBOSE:1=), >/dev/null) Invokation seems OK to me. Getting rid of the 'sed' call is really to my liking here :) Thank you! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] boards.cfg: move boards with invalid emails to Orphan
Hi Masahiro, On Tue, 11 Mar 2014 20:31:37 +0900, Masahiro Yamada wrote: > Hello Albert, > > > > Besides, Orphan boards have been collected at the bottom of boards.cfg. > > > (This is done when we run "tools/reformat.py") > > > > > > Add separators to distinguish them from those which > > > were moved to Orphan 6 months ago. > > > I believe it will be helpful in future to find which boards are > > > old enough to be removed from the code base. > > > > Agreed up to and including the above. However, it seems you have not > > applied tools/reformat.py as requested in the file header: after > > I have applied your patch, running reformat.py led to some lines being > > reorganized in boards.cfg. > > Yes. It is intentinal. > I think touching other boards is beyond the scope of this patch > and obscures the purpose of this patch. > > I leave it for a dedicated patch. > I expect Fabio Estevam will periodically post patches > like commit 0876703cf and sort boards.cfg. The whole point is that any modification to boards.cfg should go through tools/reformat.py so that boards.cfg is always properly ordered. There's a script to automate this, and a command is provided so that you can run it just by copy-pasting it, precisely to make sure no effort is required for keeping the list sorted. So please do keep it sorted. > Best Regards > Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] boards.cfg: move boards with invalid emails to Orphan
On Tue, Mar 11, 2014 at 08:31:37PM +0900, Masahiro Yamada wrote: > Hello Albert, > > > > Besides, Orphan boards have been collected at the bottom of boards.cfg. > > > (This is done when we run "tools/reformat.py") > > > > > > Add separators to distinguish them from those which > > > were moved to Orphan 6 months ago. > > > I believe it will be helpful in future to find which boards are > > > old enough to be removed from the code base. > > > > Agreed up to and including the above. However, it seems you have not > > applied tools/reformat.py as requested in the file header: after > > I have applied your patch, running reformat.py led to some lines being > > reorganized in boards.cfg. > > Yes. It is intentinal. > I think touching other boards is beyond the scope of this patch > and obscures the purpose of this patch. Yes, all of Masahiro's changes are correctly formatted within the file (just confirmed that). I'll do a follow-up reformat and apply on top as it's a separate change, that does need doing, but isn't part of this. Thanks guys! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] boards.cfg: move boards with invalid emails to Orphan
On Tue, Mar 11, 2014 at 12:19:12PM +0900, Masahiro Yamada wrote: > When I cc board maintainers, some of them result in > bounce mails. > > It turned out the following do not work any more: > Yuli Barcohen > Travis Sawyer > Yusdi Santoso > David Updegraff > Sangmoon Kim > Anton Vorontsov > Blackfin Team > Bluetechnix Tinyboards > Andre Schwarz > > For the blackfin boards where Sonic Zhang is also listed > as a maintainer, dead addresses should be simply dropped. > > For all of the others, the status should be changed to "Orphan". > > We have adopted the definition of "Orphan" as: > board is not actively maintained any more but still builds, and any > address associated with it is that of the last known maintainer(s) > > Even though the emails do not work any more, they carry information. > We want to keep them. > > Besides, Orphan boards have been collected at the bottom of boards.cfg. > (This is done when we run "tools/reformat.py") > > Add separators to distinguish them from those which > were moved to Orphan 6 months ago. > I believe it will be helpful in future to find which boards are > old enough to be removed from the code base. > > Signed-off-by: Masahiro Yamada > Cc: Detlev Zundel > Cc: Tom Rini > Cc: Albert ARIBAUD Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v2] powerpc/mpc8xxx: SECURE BOOT- Disable law 0 for non PBL platforms
ISBC creates a LAW 0 entry for non PBL platforms, which is not disabled before transferring the control to uboot. The LAW 0 entry has to be disabled. Signed-off-by: Aneesh Bansal --- arch/powerpc/cpu/mpc8xxx/law.c | 10 ++ 1 file changed, 10 insertions(+) Changes from v1: The LAW was being disabled in start.S in v1. As per discussion, it is moved out of start.S and done when U-boot initializes other LAW's. diff --git a/arch/powerpc/cpu/mpc8xxx/law.c b/arch/powerpc/cpu/mpc8xxx/law.c index a401083..55ee125 100644 --- a/arch/powerpc/cpu/mpc8xxx/law.c +++ b/arch/powerpc/cpu/mpc8xxx/law.c @@ -233,6 +233,16 @@ void init_laws(void) #error FSL_HW_NUM_LAWS can not be greater than 32 w/o code changes #endif +#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500) && \ + !defined(CONFIG_E500MC) + /* ISBC (Boot ROM) creates a LAW 0 entry for non PBL platforms, +* which is not disabled before transferring the control to uboot. +* Disable the LAW 0 entry here. +*/ + disable_law(0); +#endif + + /* * Any LAWs that were set up before we booted assume they are meant to * be around and mark them used. -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for BSC9132QDS
Add NOR, SPI and SD secure boot targets for BSC9132QDS. Changes: - Debug TLB entry is not required for Secure Boot Target. Signed-off-by: Aneesh Bansal --- arch/powerpc/cpu/mpc85xx/start.S | 9 ++--- arch/powerpc/include/asm/fsl_secure_boot.h | 2 ++ boards.cfg | 6 ++ include/configs/BSC9132QDS.h | 2 ++ 4 files changed, 12 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 4ef0985..c692ba6 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -461,7 +461,8 @@ nexti: mflrr1 /* R1 = our PC */ 2: cmpwr3, r4 blt 1b -#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) && !defined(MINIMAL_SPL) +#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) && !defined(MINIMAL_SPL) && \ + !defined(CONFIG_SECURE_BOOT) /* * TLB entry for debuggging in AS1 * Create temporary TLB entry in AS0 to handle debug exception @@ -482,12 +483,6 @@ nexti: mflrr1 /* R1 = our PC */ 0xffc0, MAS3_SX|MAS3_SW|MAS3_SR, \ 0, r6 -#elif !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT) - create_tlb1_entry CONFIG_SYS_PPC_E500_DEBUG_TLB, \ - 0, BOOKE_PAGESZ_1M, \ - CONFIG_SYS_MONITOR_BASE, MAS2_I|MAS2_G, \ - CONFIG_SYS_PBI_FLASH_WINDOW, MAS3_SX|MAS3_SW|MAS3_SR, \ - 0, r6 #else /* * TLB entry is created for IVPR + IVOR15 to map on valid OP code address diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h b/arch/powerpc/include/asm/fsl_secure_boot.h index 8f5bf10..c705d5a 100644 --- a/arch/powerpc/include/asm/fsl_secure_boot.h +++ b/arch/powerpc/include/asm/fsl_secure_boot.h @@ -10,6 +10,8 @@ #ifdef CONFIG_SECURE_BOOT #if defined(CONFIG_FSL_CORENET) #define CONFIG_SYS_PBI_FLASH_BASE 0xc000 +#elif defined(CONFIG_BSC9132QDS) +#define CONFIG_SYS_PBI_FLASH_BASE 0xc800 #else #define CONFIG_SYS_PBI_FLASH_BASE 0xce00 #endif diff --git a/boards.cfg b/boards.cfg index cf2b1df..3e73d7e 100644 --- a/boards.cfg +++ b/boards.cfg @@ -798,6 +798,12 @@ Active powerpc mpc85xx- freescale bsc9132qds Active powerpc mpc85xx- freescale bsc9132qds BSC9132QDS_SDCARD_DDRCLK133 BSC9132QDS:BSC9132QDS,SDCARD,SYS_CLK_100_DDR_133 Naveen Burmi Active powerpc mpc85xx- freescale bsc9132qds BSC9132QDS_SPIFLASH_DDRCLK100 BSC9132QDS:BSC9132QDS,SPIFLASH,SYS_CLK_100_DDR_100 Naveen Burmi Active powerpc mpc85xx- freescale bsc9132qds BSC9132QDS_SPIFLASH_DDRCLK133 BSC9132QDS:BSC9132QDS,SPIFLASH,SYS_CLK_100_DDR_133 Naveen Burmi +Active powerpc mpc85xx- freescale bsc9132qds BSC9132QDS_NOR_DDRCLK100_SECURE BSC9132QDS:BSC9132QDS,SYS_CLK_100_DDR_100,SECURE_BOOT Aneesh Bansal +Active powerpc mpc85xx- freescale bsc9132qds BSC9132QDS_NOR_DDRCLK133_SECURE BSC9132QDS:BSC9132QDS,SYS_CLK_100_DDR_133,SECURE_BOOT Aneesh Bansal +Active powerpc mpc85xx- freescale bsc9132qds BSC9132QDS_SDCARD_DDRCLK100_SECURE BSC9132QDS:BSC9132QDS,SDCARD,SYS_CLK_100_DDR_100,SECURE_BOOT Aneesh Bansal +Active powerpc mpc85xx- freescale bsc9132qds BSC9132QDS_SDCARD_DDRCLK133_SECURE BSC9132QDS:BSC9132QDS,SDCARD,SYS_CLK_100_DDR_133,SECURE_BOOT Aneesh Bansal +Active powerpc mpc85xx- freescale bsc9132qds BSC9132QDS_SPIFLASH_DDRCLK100_SECURE BSC9132QDS:BSC9132QDS,SPIFLASH,SYS_CLK_100_DDR_100,SECURE_BOOT Aneesh Bansal +Active powerpc mpc85xx- freescale bsc9132qds BSC9132QDS_SPIFLASH_DDRCLK133_SECURE BSC9132QDS:BSC9132QDS,SPIFLASH,SYS_CLK_100_DDR_133,SECURE_BOOT Aneesh Bansal Active powerpc mpc85xx- freescale c29xpcie C29XPCIE C29XPCIE:C29XPCIE,36BIT Po Liu Active
Re: [U-Boot] Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)
On Tue, Mar 11, 2014 at 10:38:05AM +, Ian Campbell wrote: > Adding u-boot list since I think this is a general issue/question. > > On Sun, 2014-03-09 at 20:00 +0100, Olliver Schinagl wrote: > > On 03/09/14 16:18, tyler.ba...@linaro.org wrote: > > > On Sunday, March 9, 2014 8:06:27 AM UTC-7, tyler...@linaro.org wrote: > > >> Hello, > > >> > > >> I am trying to boot the cubietruck with a minimal ramdisk. However, it > > >> seems to hang at "Starting kernel..." whenever I pass bootz a > > >> ramdisk load address. > [...] > > > Turl help me solve this in IRC. Needed to setenv initrd_high > > > '0x' in case anyone else runs into this. > > > The http://linux-sunxi.org/Mainline_Kernel_Howto did mention this ;) but > > thanks for helping remind people! > > Actually it mentions fdt_high but not initrd_high. > > But what is the reason for the default behaviour of bootz doing things > which do not conform to linux/Documentation/arm/Booting and therefore is > not going to boot? Because U-Boot is more than just ARM, and ARM boards not enforcing / getting the correct behavour via fdt_high / initrd_high or bootm_low / bootm_mapsize / bootm_size / CONFIG_SYS_BOOTMAPSZ. > The docs recommend that DTB and initrd go just after the 128MB boundary. > If either are loaded "too high" then the kernel will crash on boot, > often in a tricky to diagnose way (I've chased it down more than once). > It's especially annoying when one has carefully loaded everything at a > suitable address in the first place ;-) I have as well, sadly. > Should the global default be changed to either 0x (no > relocation) or to start-of-ram+256MB (which should satisfy the kernels > requirements without needing logic changes to handle "just after the > 128MB boundary" as a concept). > > Or is it intended that each board should opt-in to a sensible default > via their default environment? > > Does bootm suffer the same? I suspect it does, at least for fdt (since > initrd has a load addr in the u-boot header). SoCs should set a sane and correct set of values, using either of the available mechanisms. I think Tegra gets this all correct via CONFIG_SYS_BOOTMAPSZ and I've been meaning to whack the various TI parts as part of the generic distro work. And keep in mind that when we set fdt/initrd_high to a non-0x value we're setting a maximum that's still checked vs how much we have, so setting base+512MB is probably a best default for cases where we may run on boards with varying amounts of DDR. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb start crashing on arndale
Adding Inderpal singh and Trini. Please help On 11-Mar-2014, at 12:27 pm, armdev wrote: > Hi, > > We have recently started working on arndale and running u-boot head on it. > Seems like it is crashing on our setup with a data abort on usb start. Can > anyone please confirm and suggest a fix / solution > > U-Boot 2014.04-rc1-00486-geeb72e6 (Mar 11 2014 - 11:44:32) for ARNDALE > > > CPU:Exynos5250@1000MHz > > Board: Arndale > I2C: i2c_init: failed to init bus 0 for speed = 10 > ready > DRAM: 2 GiB > trace: copying 00084f98 bytes of early data from 5000 to beff > trace: enabled > WARNING: Caches not enabled > MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 > i2c_init: failed to init bus 0 for speed = 10 > In:serial > Out: serial > Err: serial > Net: Net Initialization Skipped > No ethernet found. > Hit any key to stop autoboot: 0 > ARNDALE # usb start > (Re)start USB... > USB0: data abort > pc : [] lr : [] > sp : beb5f9c0 ip : 0003 fp : > r10: r9 : beb62ecc r8 : befbcc80 > r7 : befbcc84 r6 : r5 : 00ff r4 : 0001 > r3 : r2 : 0001 r1 : 00ff r0 : > Flags: nzCv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... > > > Thanks and Regards > Armdev@FTM Team > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)
On Tue, 2014-03-11 at 09:48 -0400, Tom Rini wrote: > On Tue, Mar 11, 2014 at 10:38:05AM +, Ian Campbell wrote: > > But what is the reason for the default behaviour of bootz doing things > > which do not conform to linux/Documentation/arm/Booting and therefore is > > not going to boot? > > Because U-Boot is more than just ARM, and ARM boards not enforcing / > getting the correct behavour via fdt_high / initrd_high or bootm_low / > bootm_mapsize / bootm_size / CONFIG_SYS_BOOTMAPSZ. So you consider this to be a board level problem, rather than an arch level one? (IOW we can't just fix this for all arm boards at once) [...] > > Should the global default be changed to either 0x (no > > relocation) or to start-of-ram+256MB (which should satisfy the kernels > > requirements without needing logic changes to handle "just after the > > 128MB boundary" as a concept). > > > > Or is it intended that each board should opt-in to a sensible default > > via their default environment? > > > > Does bootm suffer the same? I suspect it does, at least for fdt (since > > initrd has a load addr in the u-boot header). > > SoCs should set a sane and correct set of values, using either of the > available mechanisms. I think Tegra gets this all correct via > CONFIG_SYS_BOOTMAPSZ and I've been meaning to whack the various TI parts > as part of the generic distro work. I took a look at BOOTMAPSZ on sunxi and it is using (16 << 20) which seems sensible, if a bit small, so perhaps something else is going wrong. Tegra uses 256MB, might be worth giving that a go I guess. > And keep in mind that when we set fdt/initrd_high to a non-0x > value we're setting a maximum that's still checked vs how much we have, > so setting base+512MB is probably a best default for cases where we may > run on boards with varying amounts of DDR. I'm not sure I follow -- why is +512MB best? Thanks, Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot
On 03/10/2014 04:58 PM, Scott Wood wrote: > On Mon, 2014-03-10 at 04:14 -0500, Bansal Aneesh-B39320 wrote: >>> -Original Message- >>> From: Sun York-R58495 >>> Sent: Saturday, March 08, 2014 12:31 AM >>> To: Bansal Aneesh-B39320 >>> Cc: Wood Scott-B07421; Wolfgang Denk; u-boot@lists.denx.de; Gupta >>> Ruchika-R66431 >>> Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- >>> define CONFIG_SYS_RAMBOOT for NAND boot >>> >>> On 03/07/2014 10:57 AM, Scott Wood wrote: On Thu, 2014-03-06 at 03:24 -0600, Bansal Aneesh-B39320 wrote: >> -Original Message- >> From: Wood Scott-B07421 >> Sent: Wednesday, March 05, 2014 11:30 PM >> To: Bansal Aneesh-B39320 >> Cc: Sun York-R58495; Wolfgang Denk; u-boot@lists.denx.de; Gupta >> Ruchika-R66431 >> Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- >> define CONFIG_SYS_RAMBOOT for NAND boot >> >> On Tue, 2014-03-04 at 23:30 -0600, Bansal Aneesh-B39320 wrote: >>> Yes, in case of secure boot from NAND, the DRAM is initialized by >> the >>> BootROM and complete u-boot image is copied from NAND to DRAM by >>> the >> BootROM. >>> So, it should be called RAMBOOT. >> >> DRAM or SRAM? Having ROM initialize DDR is a bit scary. >> >> -Scott >> > It can be either DDR or SRAM. It is not hardcoded in BootROM to >>> initialize DDR. > This depends on the config words (CF_WORDS) in the CF_HEADER. > The Boot ROM code parses the config words and programs the >>> addresses > with data values accordingly. The user may opt to initialize DDR >>> and > get the image copied onto DDR or configure CPC as SRAM and get the >>> Image copied onto SRAM. > On 1010, P1010? LS1010? Something else? > the CPC size is not big enough to accommodate the U-boot image. > So, currently the CF_WORDS are for DDR to be initialized and copy >>> the image on DDR. Generally if SPD is present, it should be used to init DDR rather >>> than using hardcoded values. If U-Boot doesn't fit in SRAM, you can use SPL instead of hardcoded init. >>> >>> I agree with Scott on this point. Using hardcoded values totally skip >>> DDR driver. You don't only lose the flexibility of various speeds, you >>> also skip all workarounds implemented in DDR driver. >>> >>> York >> >> Currently we are following the same approach which was there for SPI >> and SD on P1010 i.e hardcoded initialization of DDR in platforms like >> P1010, 9131/9132 using config words. > > I don't know about 9131/9132, but on P1010RDB we now use SPL to init DDR > when booting from SPI/SD. > > In any case, "we've always done it this way" isn't really a good reason. > We should move to SPL for SD/SPI/NAND. Let's take step by step. I intend to accept the updated patch to get NAND SECURE boot working for this board. Aneesh will submit patches to move to SPL, for SD/SPI/NAND. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] mpc85xx/t104x: Add deep sleep framework support
On 03/10/2014 11:16 PM, Tang Yuantian-B29983 wrote: >> -Original Message- >> From: Sun York-R58495 >> Sent: Tuesday, March 11, 2014 1:45 AM >> To: Tang Yuantian-B29983 >> Cc: u-boot@lists.denx.de; Li Yang-Leo-R58472; Jin Zhengxiong-R64188; Wood >> Scott-B07421 >> Subject: Re: [PATCH 2/2 v2] mpc85xx/t104x: Add deep sleep framework >> support >> >> On 02/28/2014 03:09 AM, yuantian.t...@freescale.com wrote: >>> From: Tang Yuantian >>> >>> When T104x soc wakes up from deep sleep, control is passed to the >>> primary core that starts executing uboot. After re-initialized some IP >>> blocks, like DDRC, kernel will take responsibility to continue to >>> restore environment it leaves before. >>> >>> Signed-off-by: Tang Yuantian >>> --- >>> v2: >>> - added explaination for CONFIG_DEEP_SLEEP >>> - fixed some issues >>> >>> README | 4 +++ >>> arch/powerpc/cpu/mpc85xx/asm-offsets.c | 24 ++ >> >> Please fix the out-of-tree compiling issue. You will see it if you run >> make with O= parameter. >> >> York > > Could you be more specific? What *path* should I give? > If I do the below, I got error: > > $ make O=/home/tangyt/opensource/u-boot/ > /home/tangyt/opensource/u-boot is not clean, please run 'make mrproper' > in the '/home/tangyt/opensource/u-boot' directory. > make[1]: *** [prepare3] Error 1 > make: *** [sub-make] Error 2 > It is out-of-tree compiling. You should use a clean path. cd http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: omap: cm_t35: Fix: Re-add GPMC_NAND_ECC_LP_x8_LAYOUT
Patch a7e36fc9 (mtd: nand: omap: remove unused #defines from common omap_gpmc.h) removed some MTD related defines. Including GPMC_NAND_ECC_LP_x8_LAYOUT. But this define is also needed for the memory controller configuration (only the x8 defines are needed, the x16 defines are the default). Without it the NAND subsystem is not configured correctly and booting into U-Boot does not work. Signed-off-by: Stefan Roese Cc: Pekon Gupta Cc: Nikita Kiryanov Cc: Igor Grinberg Cc: Tom Rini --- include/configs/cm_t35.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index cfc4f9b..aae05e0 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -158,6 +158,8 @@ /* CS0 */ #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ /* devices */ +#define GPMC_NAND_ECC_LP_x8_LAYOUT + /* Environment information */ #define CONFIG_BOOTDELAY 3 #define CONFIG_ZERO_BOOTDELAY_CHECK -- 1.8.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cfi_flash: Micron Nor flash don't support read operation after send write command
Micron Nor flash don't support read operation after send write command. As
below,
flash_write_cmd(info, sector, offset, AMD_CMD_WRITE_TO_BUFFER);
cnt = len >> shift;
flash_write_cmd(info, sector, offset, cnt - 1);
switch (info->portwidth) {
case FLASH_CFI_8BIT:
while (cnt-- > 0) {
flash_write8(flash_read8(src), dst);
src += 1, dst += 1;
}
break;
If the src address locate in NOR flash, flash_read operation will be failed.
So, read out the data to DRAM before send write command operation.
Signed-off-by: Qi Wang
---
drivers/mtd/cfi_flash.c | 70 +++
1 file changed, 46 insertions(+), 24 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index
a389cd1..0f532c0 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
/*
* This file implements a Common Flash Interface (CFI) driver for @@ -855,6
+857,8 @@ static int flash_write_cfibuffer (flash_info_t * info, ulong dest,
uchar * cp,
int cnt;
int retcode;
void *src = cp;
+ void *src2;
+ void *src2_bak;
void *dst = (void *)dest;
void *dst2 = dst;
int flag = 1;
@@ -880,29 +884,45 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
goto out_unmap;
}
+ src2 = malloc(len);
+ if(!src2)
+ {
+ free(src2);
+ return -ENOMEM;
+ }
+
+ src2_bak = src2;
cnt = len >> shift;
while ((cnt-- > 0) && (flag == 1)) {
switch (info->portwidth) {
case FLASH_CFI_8BIT:
- flag = ((flash_read8(dst2) & flash_read8(src)) ==
- flash_read8(src));
+ *(u8 *)src2 = flash_read8(src);
+ flag = ((flash_read8(dst2) & *(u8 *)src2) ==
+ *(u8 *)src2);
src += 1, dst2 += 1;
+ src2 +=1;
break;
case FLASH_CFI_16BIT:
- flag = ((flash_read16(dst2) & flash_read16(src)) ==
- flash_read16(src));
+ *(u16 *)src2 = flash_read16(src);
+ flag = ((flash_read16(dst2) & *(u16 *)src2) ==
+ *(u16 *)src2);
src += 2, dst2 += 2;
+ src2 += 2;
break;
case FLASH_CFI_32BIT:
- flag = ((flash_read32(dst2) & flash_read32(src)) ==
- flash_read32(src));
+ *(u32 *)src2 = flash_read32(src);
+ flag = ((flash_read32(dst2) & *(u32 *)src2) ==
+ *(u32 *)src2);
src += 4, dst2 += 4;
+ src2 += 4;
break;
case FLASH_CFI_64BIT:
- flag = ((flash_read64(dst2) & flash_read64(src)) ==
- flash_read64(src));
+ *(u64 *)src2 = flash_read64(src);
+ flag = ((flash_read64(dst2) & *(u64 *)src2) ==
+ *(u64 *)src2);
src += 8, dst2 += 8;
+ src2 += 8;
break;
}
}
@@ -912,6 +932,7 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
}
src = cp;
+ src2 = src2_bak;
sector = find_sector (info, dest);
switch (info->vendor) {
@@ -934,20 +955,20 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
while (cnt-- > 0) {
switch (info->portwidth) {
case FLASH_CFI_8BIT:
- flash_write8(flash_read8(src), dst);
- src += 1, dst += 1;
+ flash_write8(*(u8 *)src2, dst);
+ src2 += 1, dst += 1;
break;
case FLASH_CFI_16BIT:
- flash_write16(flash_read16(src), dst);
- src += 2, dst += 2;
+ flash_write16(*(u16 *)src2, dst);
+ src2 += 2, dst += 2;
break;
case FLASH_CFI_32BIT:
- flash_write32(flash_read32(src), dst);
- src += 4, dst += 4;
+
[U-Boot] Uboot - verified boot - CONFIG_OF_SEPARATE
Hey! When I build my Uboot with the CONFIG_OF_SEPARATE set to gain access to the compiled dtb, Uboot can't find my concatenated dtb during the boot. After injecting the pulbic keys for the verified boot, I cat the u-boot.dtb behind the u-boot.bin. After that I mkimage the u-boot.img as usuall. I found, that if I change the offset where the fdt_blob is searched for by +300, it finds the dtb correctly. Like this: --- #elif defined CONFIG_OF_SEPARATE /* FDT is at end of image */ - gd->fdt_blob = (void *)(_end_ofs + _TEXT_BASE); + gd->fdt_blob = (void *)(_end_ofs + _TEXT_BASE + 300); #endif --- But I can't explain why this might be. The 300 isn't a random value! I calculated it via some debug output and it works reliably. But like it is with these workarounds, I don't like them! So I'm searching for an answer. Any ideas, why the offset is not _end_ofs + _TEXT_BASE, like it should be? Cheers, Thilo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cfi_flash: Micron Nor flash don't support read operation after send write command
Micron Nor flash don't support read operation after send write command. As
below,
flash_write_cmd(info, sector, offset, AMD_CMD_WRITE_TO_BUFFER);
cnt = len >> shift;
flash_write_cmd(info, sector, offset, cnt - 1);
switch (info->portwidth) {
case FLASH_CFI_8BIT:
while (cnt-- > 0) {
flash_write8(flash_read8(src), dst);
src += 1, dst += 1;
}
break;
If the src address locate in NOR flash, flash_read operation will be failed.
So, read out the data to DRAM before send write command operation.
Signed-off-by: Qi Wang
---
drivers/mtd/cfi_flash.c | 70 +++
1 file changed, 46 insertions(+), 24 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index
a389cd1..0f532c0 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
/*
* This file implements a Common Flash Interface (CFI) driver for @@ -855,6
+857,8 @@ static int flash_write_cfibuffer (flash_info_t * info, ulong dest,
uchar * cp,
int cnt;
int retcode;
void *src = cp;
+ void *src2;
+ void *src2_bak;
void *dst = (void *)dest;
void *dst2 = dst;
int flag = 1;
@@ -880,29 +884,45 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
goto out_unmap;
}
+ src2 = malloc(len);
+ if(!src2)
+ {
+ free(src2);
+ return -ENOMEM;
+ }
+
+ src2_bak = src2;
cnt = len >> shift;
while ((cnt-- > 0) && (flag == 1)) {
switch (info->portwidth) {
case FLASH_CFI_8BIT:
- flag = ((flash_read8(dst2) & flash_read8(src)) ==
- flash_read8(src));
+ *(u8 *)src2 = flash_read8(src);
+ flag = ((flash_read8(dst2) & *(u8 *)src2) ==
+ *(u8 *)src2);
src += 1, dst2 += 1;
+ src2 +=1;
break;
case FLASH_CFI_16BIT:
- flag = ((flash_read16(dst2) & flash_read16(src)) ==
- flash_read16(src));
+ *(u16 *)src2 = flash_read16(src);
+ flag = ((flash_read16(dst2) & *(u16 *)src2) ==
+ *(u16 *)src2);
src += 2, dst2 += 2;
+ src2 += 2;
break;
case FLASH_CFI_32BIT:
- flag = ((flash_read32(dst2) & flash_read32(src)) ==
- flash_read32(src));
+ *(u32 *)src2 = flash_read32(src);
+ flag = ((flash_read32(dst2) & *(u32 *)src2) ==
+ *(u32 *)src2);
src += 4, dst2 += 4;
+ src2 += 4;
break;
case FLASH_CFI_64BIT:
- flag = ((flash_read64(dst2) & flash_read64(src)) ==
- flash_read64(src));
+ *(u64 *)src2 = flash_read64(src);
+ flag = ((flash_read64(dst2) & *(u64 *)src2) ==
+ *(u64 *)src2);
src += 8, dst2 += 8;
+ src2 += 8;
break;
}
}
@@ -912,6 +932,7 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
}
src = cp;
+ src2 = src2_bak;
sector = find_sector (info, dest);
switch (info->vendor) {
@@ -934,20 +955,20 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
while (cnt-- > 0) {
switch (info->portwidth) {
case FLASH_CFI_8BIT:
- flash_write8(flash_read8(src), dst);
- src += 1, dst += 1;
+ flash_write8(*(u8 *)src2, dst);
+ src2 += 1, dst += 1;
break;
case FLASH_CFI_16BIT:
- flash_write16(flash_read16(src), dst);
- src += 2, dst += 2;
+ flash_write16(*(u16 *)src2, dst);
+ src2 += 2, dst += 2;
break;
case FLASH_CFI_32BIT:
- flash_write32(flash_read32(src), dst);
- src += 4, dst += 4;
+
[U-Boot] [PATCH 0/4] vybrid/tower fixes and enhancements
From: Stefan Agner This patch series addresses several fixes and enhancements for the vybrid tower. The patches are originally by Marcel Ziswiler which should remain the Author of the patches, I picked them up since some changes I'm going to submit are building upon them. Changes v3: - Merged patches to reflect one logical change on a pheripherial device level. Changes v2: - Memory offset based reserved ANADIG field naming scheme. - Fixed mux_ctrl_ofs in secondary RMII1 iomux definitions. Marcel Ziswiler (4): arm: vf610: fix anadig register struct arm: vf610: add uart0 clock/iomux definitions arm: vf610: add enet1 support arm: vf610: fix double iomux configuration for vf610twr board arch/arm/include/asm/arch-vf610/crm_regs.h| 57 +++ arch/arm/include/asm/arch-vf610/imx-regs.h| 1 + arch/arm/include/asm/arch-vf610/iomux-vf610.h | 12 ++ board/freescale/vf610twr/vf610twr.c | 1 - 4 files changed, 45 insertions(+), 26 deletions(-) -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] arm: vf610: add uart0 clock/iomux definitions
From: Marcel Ziswiler
Add CCM_CCGR0_UART0_CTRL_MASK clock definition and add TX/RX iomux
definitions for UART0 (aka. SCI0).
Signed-off-by: Marcel Ziswiler
[ste...@agner.ch: regrouped patch]
Signed-off-by: Stefan Agner
---
arch/arm/include/asm/arch-vf610/crm_regs.h| 1 +
arch/arm/include/asm/arch-vf610/iomux-vf610.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 2d7a32d..04cc5bc 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -166,6 +166,7 @@ struct anadig_reg {
#define CCM_CSCMR2_RMII_CLK_SEL(v) (((v) & 0x3) << 4)
#define CCM_REG_CTRL_MASK 0x
+#define CCM_CCGR0_UART0_CTRL_MASK (0x3 << 14)
#define CCM_CCGR0_UART1_CTRL_MASK (0x3 << 16)
#define CCM_CCGR1_PIT_CTRL_MASK(0x3 << 14)
#define CCM_CCGR1_WDOGA5_CTRL_MASK (0x3 << 28)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index 4a39eb0..f3c201d 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -24,6 +24,8 @@ enum {
VF610_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x, 0x, 2,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTB4__UART1_TX= IOMUX_PAD(0x0068, 0x0068, 2,
0x0380, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTB5__UART1_RX= IOMUX_PAD(0x006c, 0x006c, 2,
0x037c, 0, VF610_UART_PAD_CTRL),
+ VF610_PAD_PTB10__UART0_TX = IOMUX_PAD(0x0080, 0x0080, 1,
__NA_, 0, VF610_UART_PAD_CTRL),
+ VF610_PAD_PTB11__UART0_RX = IOMUX_PAD(0x0084, 0x0084, 1,
__NA_, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTC1__RMII0_MDIO = IOMUX_PAD(0x00b8, 0x00b8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC0__RMII0_MDC = IOMUX_PAD(0x00b4, 0x00b4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC2__RMII0_CRS_DV= IOMUX_PAD(0x00bc, 0x00bc, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] arm: vf610: fix anadig register struct
From: Marcel Ziswiler
The anadig_reg structure started at the wrong offset (fixed by adding
reserved_0x000[4]), was missing some reserved field required for
alignment purpose (reserved_0x094[3] between pll4_denom and pll6_ctrl)
and further contained a too short reserved field causing further miss-
alignment (reserved_0x0C4[7]). Also, rename all the reserved fields
and using a memory offset based scheme for.
Discovered and tested by temporarily putting the following debug
instrumentation into board_init():
struct anadig_reg *anadig = (struct anadig_reg *)ANADIG_BASE_ADDR;
printf("&anadig->pll3_ctrl=0x%p\n", &anadig->pll3_ctrl);
printf("&anadig->pll5_ctrl=0x%p\n", &anadig->pll5_ctrl);
Signed-off-by: Marcel Ziswiler
[ste...@agner.ch: regrouped patch]
Signed-off-by: Stefan Agner
---
arch/arm/include/asm/arch-vf610/crm_regs.h | 52 --
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 85f1fda..2d7a32d 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -55,57 +55,59 @@ struct ccm_reg {
/* Analog components control digital interface (ANADIG) */
struct anadig_reg {
+ u32 reserved_0x000[4];
u32 pll3_ctrl;
- u32 resv0[3];
+ u32 reserved_0x014[3];
u32 pll7_ctrl;
- u32 resv1[3];
+ u32 reserved_0x024[3];
u32 pll2_ctrl;
- u32 resv2[3];
+ u32 reserved_0x034[3];
u32 pll2_ss;
- u32 resv3[3];
+ u32 reserved_0x044[3];
u32 pll2_num;
- u32 resv4[3];
+ u32 reserved_0x054[3];
u32 pll2_denom;
- u32 resv5[3];
+ u32 reserved_0x064[3];
u32 pll4_ctrl;
- u32 resv6[3];
+ u32 reserved_0x074[3];
u32 pll4_num;
- u32 resv7[3];
+ u32 reserved_0x084[3];
u32 pll4_denom;
+ u32 reserved_0x094[3];
u32 pll6_ctrl;
- u32 resv8[3];
+ u32 reserved_0x0A4[3];
u32 pll6_num;
- u32 resv9[3];
+ u32 reserved_0x0B4[3];
u32 pll6_denom;
- u32 resv10[3];
+ u32 reserved_0x0C4[7];
u32 pll5_ctrl;
- u32 resv11[3];
+ u32 reserved_0x0E4[3];
u32 pll3_pfd;
- u32 resv12[3];
+ u32 reserved_0x0F4[3];
u32 pll2_pfd;
- u32 resv13[3];
+ u32 reserved_0x104[3];
u32 reg_1p1;
- u32 resv14[3];
+ u32 reserved_0x114[3];
u32 reg_3p0;
- u32 resv15[3];
+ u32 reserved_0x124[3];
u32 reg_2p5;
- u32 resv16[7];
+ u32 reserved_0x134[7];
u32 ana_misc0;
- u32 resv17[3];
+ u32 reserved_0x154[3];
u32 ana_misc1;
- u32 resv18[63];
+ u32 reserved_0x164[63];
u32 anadig_digprog;
- u32 resv19[3];
+ u32 reserved_0x264[3];
u32 pll1_ctrl;
- u32 resv20[3];
+ u32 reserved_0x274[3];
u32 pll1_ss;
- u32 resv21[3];
+ u32 reserved_0x284[3];
u32 pll1_num;
- u32 resv22[3];
+ u32 reserved_0x294[3];
u32 pll1_denom;
- u32 resv23[3];
+ u32 reserved_0x2A4[3];
u32 pll1_pdf;
- u32 resv24[3];
+ u32 reserved_0x2B4[3];
u32 pll_lock;
};
#endif
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] arm: vf610: fix double iomux configuration for vf610twr board
From: Marcel Ziswiler
Get rid of double VF610_PAD_DDR_A15__DDR_A_15 iomux configuration.
Signed-off-by: Marcel Ziswiler
---
board/freescale/vf610twr/vf610twr.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 699ea7f..4ee74c0 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -31,7 +31,6 @@ void setup_iomux_ddr(void)
{
static const iomux_v3_cfg_t ddr_pads[] = {
VF610_PAD_DDR_A15__DDR_A_15,
- VF610_PAD_DDR_A15__DDR_A_15,
VF610_PAD_DDR_A14__DDR_A_14,
VF610_PAD_DDR_A13__DDR_A_13,
VF610_PAD_DDR_A12__DDR_A_12,
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] arm: vf610: add enet1 support
From: Marcel Ziswiler
This patch contains several changes required for second Ethernet
(enet1/RMII1) port on vf610
- ANADIG PLL5 control definitions required for Ethernet RMII1 clock
- Secondary Ethernet (enet1) MAC RMII1 base address definition
- RMII1 iomux definitions
- VF610_PAD_PTA6__RMII0_CLKOUT iomux definition required for
internal (e.g. crystal-less) Ethernet clocking.
Signed-off-by: Marcel Ziswiler
[ste...@agner.ch: regrouped patch]
Signed-off-by: Stefan Agner
---
arch/arm/include/asm/arch-vf610/crm_regs.h| 4
arch/arm/include/asm/arch-vf610/imx-regs.h| 1 +
arch/arm/include/asm/arch-vf610/iomux-vf610.h | 10 ++
3 files changed, 15 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 04cc5bc..e17c7d1 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -187,6 +187,10 @@ struct anadig_reg {
#define CCM_CCGR9_FEC0_CTRL_MASK 0x3
#define CCM_CCGR9_FEC1_CTRL_MASK (0x3 << 2)
+#define ANADIG_PLL5_CTRL_BYPASS (1 << 16)
+#define ANADIG_PLL5_CTRL_ENABLE (1 << 13)
+#define ANADIG_PLL5_CTRL_POWERDOWN (1 << 12)
+#define ANADIG_PLL5_CTRL_DIV_SELECT1
#define ANADIG_PLL2_CTRL_ENABLE(1 << 13)
#define ANADIG_PLL2_CTRL_POWERDOWN (1 << 12)
#define ANADIG_PLL2_CTRL_DIV_SELECT1
diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h
b/arch/arm/include/asm/arch-vf610/imx-regs.h
index b8c877f..c2f9761 100644
--- a/arch/arm/include/asm/arch-vf610/imx-regs.h
+++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
@@ -85,6 +85,7 @@
#define ESDHC0_BASE_ADDR (AIPS1_BASE_ADDR + 0x00031000)
#define ESDHC1_BASE_ADDR (AIPS1_BASE_ADDR + 0x00032000)
#define ENET_BASE_ADDR (AIPS1_BASE_ADDR + 0x0005)
+#define ENET1_BASE_ADDR(AIPS1_BASE_ADDR + 0x00051000)
/* MUX mode and PAD ctrl are in one register */
#define CONFIG_IOMUX_SHARE_CONF_REG
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index f3c201d..88807d8 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -22,6 +22,7 @@
enum {
VF610_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x, 0x, 2,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTA6__RMII0_CLKOUT= IOMUX_PAD(0x, 0x, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTB4__UART1_TX= IOMUX_PAD(0x0068, 0x0068, 2,
0x0380, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTB5__UART1_RX= IOMUX_PAD(0x006c, 0x006c, 2,
0x037c, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTB10__UART0_TX = IOMUX_PAD(0x0080, 0x0080, 1,
__NA_, 0, VF610_UART_PAD_CTRL),
@@ -35,6 +36,15 @@ enum {
VF610_PAD_PTC6__RMII0_TD1 = IOMUX_PAD(0x00cc, 0x00cc, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC7__RMII0_TD0 = IOMUX_PAD(0x00D0, 0x00D0, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC8__RMII0_TXEN = IOMUX_PAD(0x00D4, 0x00D4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC10__RMII1_MDIO = IOMUX_PAD(0x00dc, 0x00dc, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC9__RMII1_MDC = IOMUX_PAD(0x00d8, 0x00d8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC11__RMII1_CRS_DV = IOMUX_PAD(0x00e0, 0x00e0, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC12__RMII1_RD1 = IOMUX_PAD(0x00e4, 0x00e4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC13__RMII1_RD0 = IOMUX_PAD(0x00e8, 0x00e8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC14__RMII1_RXER = IOMUX_PAD(0x00ec, 0x00ec, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC15__RMII1_TD1 = IOMUX_PAD(0x00f0, 0x00f0, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC16__RMII1_TD0 = IOMUX_PAD(0x00f4, 0x00f4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC17__RMII1_TXEN = IOMUX_PAD(0x00f8, 0x00f8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTA24__ESDHC1_CLK = IOMUX_PAD(0x0038, 0x0038, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTA25__ESDHC1_CMD = IOMUX_PAD(0x003c, 0x003c, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTA26__ESDHC1_DAT0= IOMUX_PAD(0x0040, 0x0040, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)
On Tue, Mar 11, 2014 at 03:21:54PM +, Ian Campbell wrote: > On Tue, 2014-03-11 at 09:48 -0400, Tom Rini wrote: > > On Tue, Mar 11, 2014 at 10:38:05AM +, Ian Campbell wrote: > > > But what is the reason for the default behaviour of bootz doing things > > > which do not conform to linux/Documentation/arm/Booting and therefore is > > > not going to boot? > > > > Because U-Boot is more than just ARM, and ARM boards not enforcing / > > getting the correct behavour via fdt_high / initrd_high or bootm_low / > > bootm_mapsize / bootm_size / CONFIG_SYS_BOOTMAPSZ. > > So you consider this to be a board level problem, rather than an arch > level one? (IOW we can't just fix this for all arm boards at once) I'm not 100% sure. An issue is that lowmem isn't always 512MB, it may be 768MB. That also may not really matter for this, I'm not sure. But part of the problem is that AFAICS no one provides a 100% correct example today. With some testing around now, for TI platforms (DDR starts at 0x8000 it would be: /* * We setup defaults based on constraints from the Linux kernel, which * should also be safe elsewhere. We have the default load at 32MB into * DDR (for the kernel), FDT above 128MB (the maximum location for the * end of the kernel), and the ramdisk 512KB above that (allowing for * hopefully never seen large trees). We say all of this must be within * the first 512MB as that will always be within the kernel lowmem and * thus visible via bootm_size. */ #define CONFIG_EXTRA_ENV_SETTINGS \ - "loadaddr=0x8020\0" \ - "fdtaddr=0x80F8\0" \ - "fdt_high=0x\0" \ + "loadaddr=0x8200\0" \ + "fdtaddr=0x8800\0" \ + "rdaddr=0x8808\0" \ + "bootm_size=0x2000\0" \ All of that said, I could be convinced that we could try and make common/image.c::getenv_bootm_size() smarter about defaults but we need to take a lot of care there, and allow people to opt-out as that's common code and how much lowmem we have is configurable a lot. > [...] > > > Should the global default be changed to either 0x (no > > > relocation) or to start-of-ram+256MB (which should satisfy the kernels > > > requirements without needing logic changes to handle "just after the > > > 128MB boundary" as a concept). > > > > > > Or is it intended that each board should opt-in to a sensible default > > > via their default environment? > > > > > > Does bootm suffer the same? I suspect it does, at least for fdt (since > > > initrd has a load addr in the u-boot header). > > > > SoCs should set a sane and correct set of values, using either of the > > available mechanisms. I think Tegra gets this all correct via > > CONFIG_SYS_BOOTMAPSZ and I've been meaning to whack the various TI parts > > as part of the generic distro work. > > I took a look at BOOTMAPSZ on sunxi and it is using (16 << 20) which > seems sensible, if a bit small, so perhaps something else is going > wrong. > > Tegra uses 256MB, might be worth giving that a go I guess. Doing some playing around, BOOTMAPSZ isn't a complete solution, you need bootm_low also set. In fact, I found the best results with just doing botom_low but there may be cases where you also want BOOTMAPSZ. > > And keep in mind that when we set fdt/initrd_high to a non-0x > > value we're setting a maximum that's still checked vs how much we have, > > so setting base+512MB is probably a best default for cases where we may > > run on boards with varying amounts of DDR. > > I'm not sure I follow -- why is +512MB best? I'm a fan of setting things to the maximum allowed, to allow for future growth. This would also allow for pretty giant ramdisks to be passed which is unlikely but not impossible (I need to debug X and I can't use nfs/sd/etc for root, let me assemble a big ramdisk with everything I need). Getting back to why this would be left up to the SoC/board level, if for some reason there's a reason to not go up quite that high, they can tweak it. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: omap: cm_t35: Fix: Re-add GPMC_NAND_ECC_LP_x8_LAYOUT
On 03/11/14 18:04, Stefan Roese wrote: > Patch a7e36fc9 (mtd: nand: omap: remove unused #defines from common > omap_gpmc.h) removed some MTD related defines. Including > GPMC_NAND_ECC_LP_x8_LAYOUT. But this define is also needed for the > memory controller configuration (only the x8 defines are needed, > the x16 defines are the default). Without it the NAND subsystem is > not configured correctly and booting into U-Boot does not work. > > Signed-off-by: Stefan Roese > Cc: Pekon Gupta > Cc: Nikita Kiryanov > Cc: Igor Grinberg > Cc: Tom Rini Acked-by: Igor Grinberg > --- > include/configs/cm_t35.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h > index cfc4f9b..aae05e0 100644 > --- a/include/configs/cm_t35.h > +++ b/include/configs/cm_t35.h > @@ -158,6 +158,8 @@ > /* CS0 */ > #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ > /* devices */ > +#define GPMC_NAND_ECC_LP_x8_LAYOUT > + > /* Environment information */ > #define CONFIG_BOOTDELAY 3 > #define CONFIG_ZERO_BOOTDELAY_CHECK > -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] am335x_evm: Update the ramdisk args, we pass things in just fine via DT
Signed-off-by: Tom Rini
---
include/configs/am335x_evm.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 6bd8aec..11088b3 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -79,7 +79,7 @@
"nfsopts=nolock\0" \
"static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \
"::off\0" \
- "ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \
+ "ramroot=/dev/ram0 rw\0" \
"ramrootfstype=ext2\0" \
"mmcargs=setenv bootargs console=${console} " \
"${optargs} " \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] am43xx_evm: Update the ramdisk args, we pass things in just fine via DT
Signed-off-by: Tom Rini
---
include/configs/am43xx_evm.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 2c5..2d9825b 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -128,7 +128,7 @@
"usbroot=/dev/sda2 rw\0" \
"usbrootfstype=ext4 rootwait\0" \
"usbdev=0\0" \
- "ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \
+ "ramroot=/dev/ram0 rw\0" \
"ramrootfstype=ext2\0" \
"mmcargs=setenv bootargs console=${console} " \
"${optargs} " \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] TI: Add, use a DEFAULT_LINUX_BOOT_ENV environment string
To deal with a reoccurring problem properly we need to specify addresses for the Linux kernel, Flatted Device Tree and ramdisk that obey the constraints within the kernel's Documentation/arm/Booting file but also make sure that we relocate things within a valid address range. It is possible with these addresses to also set fdt_high and initrd_high to the value of 0x. We don't do this by default to allow for the most likely success of people using custom addresses however. Signed-off-by: Tom Rini --- include/configs/am335x_evm.h |5 + include/configs/am43xx_evm.h |5 + include/configs/ti_armv7_common.h | 22 +- include/configs/ti_omap4_common.h |4 +--- include/configs/ti_omap5_common.h |5 + 5 files changed, 25 insertions(+), 16 deletions(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 2020e7f..6bd8aec 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -61,11 +61,8 @@ #ifndef CONFIG_SPL_BUILD #define CONFIG_EXTRA_ENV_SETTINGS \ - "loadaddr=0x8020\0" \ - "fdtaddr=0x80F8\0" \ - "fdt_high=0x\0" \ + DEFAULT_LINUX_BOOT_ENV \ "boot_fdt=try\0" \ - "rdaddr=0x8100\0" \ "bootpart=0:2\0" \ "bootdir=/boot\0" \ "bootfile=zImage\0" \ diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index 614857d..2c5 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -112,10 +112,7 @@ #ifndef CONFIG_SPL_BUILD #define CONFIG_EXTRA_ENV_SETTINGS \ - "loadaddr=0x8020\0" \ - "fdtaddr=0x80F8\0" \ - "fdt_high=0x\0" \ - "rdaddr=0x8100\0" \ + DEFAULT_LINUX_BOOT_ENV \ "fdtfile=undefined\0" \ "bootpart=0:2\0" \ "bootdir=/boot\0" \ diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 69d69a5..fda99fb 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -36,8 +36,28 @@ /* * Our DDR memory always starts at 0x8000 and U-Boot shall have * relocated itself to higher in memory by the time this value is used. + * However, set this to a 32MB offset to allow for easier Linux kernel + * booting as the default is often used as the kernel load address. */ -#define CONFIG_SYS_LOAD_ADDR 0x8000 +#define CONFIG_SYS_LOAD_ADDR 0x8200 + +/* + * We setup defaults based on constraints from the Linux kernel, which should + * also be safe elsewhere. We have the default load at 32MB into DDR (for + * the kernel), FDT above 128MB (the maximum location for the end of the + * kernel), and the ramdisk 512KB above that (allowing for hopefully never + * seen large trees). We say all of this must be within the first 512MB + * as that will always be within the kernel lowmem and thus visible via + * bootm_size. + */ +#define DEFAULT_LINUX_BOOT_ENV \ + "loadaddr=0x8200\0" \ + "kernel_addr_r=0x8200\0" \ + "fdtaddr=0x8800\0" \ + "fdt_addr_r=0x8800\0" \ + "rdaddr=0x8808\0" \ + "ramdisk_addr_r=0x8808\0" \ + "bootm_size=0x2000\0" /* * Default to a quick boot delay. diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h index bcb5eab..387f570 100644 --- a/include/configs/ti_omap4_common.h +++ b/include/configs/ti_omap4_common.h @@ -87,10 +87,8 @@ * Environment setup */ #define CONFIG_EXTRA_ENV_SETTINGS \ - "loadaddr=0x8200\0" \ + DEFAULT_LINUX_BOOT_ENV \ "console=ttyO2,115200n8\0" \ - "fdt_high=0x\0" \ - "fdtaddr=0x80f8\0" \ "fdtfile=undefined\0" \ "bootpart=0:2\0" \ "bootdir=/boot\0" \ diff --git a/include/configs/ti_omap5_common.h b/include/configs/ti_omap5_common.h index 7b10fbd..2443d55 100644 --- a/include/configs/ti_omap5_common.h +++ b/include/configs/ti_omap5_common.h @@ -70,10 +70,7 @@ #endif #define CONFIG_EXTRA_ENV_SETTINGS \ - "loadaddr=0x8020\0" \ - "fdtaddr=0x80F8\0" \ - "fdt_high=0x\0" \ - "rdaddr=0x8100\0" \ + DEFAULT_LINUX_BOOT_ENV \ "console=" CONSOLEDEV ",115200n8\0" \ "fdtfile=undefined\0" \ "bootpart=0:2\0" \ -- 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] socfpga: Add socfpga preloader signing to mkimage
On Tuesday 11 March 2014 22:13:26 you wrote: > Hello Charles, Gerhard, > > > > > Is there any (real, technical) reason why the bzip stuff (the > > > > CRC-32 calculation that has been made available separately) > > > > cannot get built and used as a library, and the tools/ > > > > application just gets linked against it as one would expect? > > > > > > From my limited understanding, lib/ is not built for the host. It is > > > only built for the target. That is why we have all these ugly C files: > > > crc32.c, sha1.c,... in tools/. > > > > With Kbuild, is the '#include "../otherdir/source.c" trick still > > needed? Would a list of object files with relative path specs > > work, or can object files in one output directory result from > > compile units taken out of several source directories? > > In this case, object files with relative path such as "../lib/foo.o" > does not work. > > If we write ../lib/foo.o in tools/Makefile, > $(HOSTCC) will compile foo.o into lib/ directory. > And lator it will be overwritten with the one compiled with $(CC). > > I thought this is a simple way to generate two objects from > one source file, > one is for hostprogs in tools/ and the other for the target in lib/. In the long run, I guess splitting the objects something like how SPL is handled in parallel to main u-boot is the right thing, but I absolutely agree with you that this should be a separate exercise. Mixing adding new features and refactoring in one patch is best avoided. It is a similar issue that makes most of the target side code unavailable for the host tools. For example, anything requiring will clearly NOT work since the host side processor environment need not be, and indeed seldom is, the same as target. Perhaps a split compile could fix that, but it is beyond the scope of this exercise. > > BTW, I sometimes see #include for "*.c" > for example, drivers/usb/host/ehci-hcd.c of Linux Kernel, > although I admit it is ugly. > > I agree we need to do something with it, > but it's beyond the scope of this patch. > > > diff --git a/spl/Makefile b/spl/Makefile > > index 346d0aa..4e0f33f 100644 > > --- a/spl/Makefile > > +++ b/spl/Makefile > > @@ -182,6 +182,11 @@ MLO MLO.byteswap: $(obj)/u-boot-spl.bin > > > > ALL-y += $(obj)/$(SPL_BIN).bin > > > > +$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin > > + $(OBJTREE)/tools/mkimage -T socfpgaimage -d $< $@ > > + > > +ALL-$(CONFIG_SOCFPGA) += $(OBJTREE)/socfpga-signed-preloader.bin > > + > > ifdef CONFIG_SAMSUNG > > ALL-y += $(obj)/$(BOARD)-spl.bin > > endif > > Could you re-write this part as follows, please? > > > diff --git a/spl/Makefile b/spl/Makefile > index bb3d349..9f3893e 100644 > --- a/spl/Makefile > +++ b/spl/Makefile > @@ -184,6 +184,12 @@ MLO MLO.byteswap: $(obj)/u-boot-spl.bin > > ALL-y += $(obj)/$(SPL_BIN).bin > > +MKIMAGEFLAGS_socfpga-signed-preloader.bin := -T socfpgaimage > +socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin > + $(call cmd,mkimage) > + > +ALL-$(CONFIG_SOCFPGA) += socfpga-signed-preloader.bin > + > ifdef CONFIG_SAMSUNG > ALL-y += $(obj)/$(BOARD)-spl.bin > endif Thank you. I shall try that. Thank you for that valuable feedback. Regards. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild: delete *.pyc files by "make distclean"
On 11 March 2014 04:30, Masahiro Yamada wrote: > > The tools "buildman" and "patman" are written Python. > When we run them, "*.pyc" files are created under > tools/buildman, tools/patman directories. > > They should be cleaned up by "make distclean". > > Signed-off-by: Masahiro Yamada > Cc: Simon Glass > Cc: Tom Rini Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cfi_flash: Micron Nor flash don't support read operation after send
Micron Nor flash don't support read operation after send write command. As
below,
flash_write_cmd(info, sector, offset, AMD_CMD_WRITE_TO_BUFFER);
cnt = len >> shift;
flash_write_cmd(info, sector, offset, cnt - 1);
switch (info->portwidth) {
case FLASH_CFI_8BIT:
while (cnt-- > 0) {
flash_write8(flash_read8(src), dst);
src += 1, dst += 1;
}
break;
If the src address locate in NOR flash, flash_read operation will be failed.
So, read out the data to DRAM before send write command operation.
---
drivers/mtd/cfi_flash.c | 70 +++
1 file changed, 46 insertions(+), 24 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index a389cd1..0f532c0 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
/*
* This file implements a Common Flash Interface (CFI) driver for
@@ -855,6 +857,8 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
int cnt;
int retcode;
void *src = cp;
+ void *src2;
+ void *src2_bak;
void *dst = (void *)dest;
void *dst2 = dst;
int flag = 1;
@@ -880,29 +884,45 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
goto out_unmap;
}
+ src2 = malloc(len);
+ if(!src2)
+ {
+ free(src2);
+ return -ENOMEM;
+ }
+
+ src2_bak = src2;
cnt = len >> shift;
while ((cnt-- > 0) && (flag == 1)) {
switch (info->portwidth) {
case FLASH_CFI_8BIT:
- flag = ((flash_read8(dst2) & flash_read8(src)) ==
- flash_read8(src));
+ *(u8 *)src2 = flash_read8(src);
+ flag = ((flash_read8(dst2) & *(u8 *)src2) ==
+ *(u8 *)src2);
src += 1, dst2 += 1;
+ src2 +=1;
break;
case FLASH_CFI_16BIT:
- flag = ((flash_read16(dst2) & flash_read16(src)) ==
- flash_read16(src));
+ *(u16 *)src2 = flash_read16(src);
+ flag = ((flash_read16(dst2) & *(u16 *)src2) ==
+ *(u16 *)src2);
src += 2, dst2 += 2;
+ src2 += 2;
break;
case FLASH_CFI_32BIT:
- flag = ((flash_read32(dst2) & flash_read32(src)) ==
- flash_read32(src));
+ *(u32 *)src2 = flash_read32(src);
+ flag = ((flash_read32(dst2) & *(u32 *)src2) ==
+ *(u32 *)src2);
src += 4, dst2 += 4;
+ src2 += 4;
break;
case FLASH_CFI_64BIT:
- flag = ((flash_read64(dst2) & flash_read64(src)) ==
- flash_read64(src));
+ *(u64 *)src2 = flash_read64(src);
+ flag = ((flash_read64(dst2) & *(u64 *)src2) ==
+ *(u64 *)src2);
src += 8, dst2 += 8;
+ src2 += 8;
break;
}
}
@@ -912,6 +932,7 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
}
src = cp;
+ src2 = src2_bak;
sector = find_sector (info, dest);
switch (info->vendor) {
@@ -934,20 +955,20 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
while (cnt-- > 0) {
switch (info->portwidth) {
case FLASH_CFI_8BIT:
- flash_write8(flash_read8(src), dst);
- src += 1, dst += 1;
+ flash_write8(*(u8 *)src2, dst);
+ src2 += 1, dst += 1;
break;
case FLASH_CFI_16BIT:
- flash_write16(flash_read16(src), dst);
- src += 2, dst += 2;
+ flash_write16(*(u16 *)src2, dst);
+ src2 += 2, dst += 2;
break;
case FLASH_CFI_32BIT:
- flash_write32(flash_read32(src), dst);
- src += 4, dst += 4;
+
Re: [U-Boot] usb start crashing on arndale
Hi, On 11 March 2014 20:25, armdev wrote: > Adding Inderpal singh and Trini. Please help > > On 11-Mar-2014, at 12:27 pm, armdev wrote: > > > Hi, > > > > We have recently started working on arndale and running u-boot head on > it. Seems like it is crashing on our setup with a data abort on usb start. > Can anyone please confirm and suggest a fix / solution > > > > U-Boot 2014.04-rc1-00486-geeb72e6 (Mar 11 2014 - 11:44:32) for ARNDALE > > > > CPU:Exynos5250@1000MHz > > > > Board: Arndale > > I2C: i2c_init: failed to init bus 0 for speed = 10 > > ready > > DRAM: 2 GiB > > trace: copying 00084f98 bytes of early data from 5000 to beff > > trace: enabled > > WARNING: Caches not enabled > > MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 > > i2c_init: failed to init bus 0 for speed = 10 > > In:serial > > Out: serial > > Err: serial > > Net: Net Initialization Skipped > > No ethernet found. > > Hit any key to stop autoboot: 0 > > ARNDALE # usb start > > (Re)start USB... > > USB0: data abort > > pc : [] lr : [] > > sp : beb5f9c0 ip : 0003 fp : > > r10: r9 : beb62ecc r8 : befbcc80 > > r7 : befbcc84 r6 : r5 : 00ff r4 : 0001 > > r3 : r2 : 0001 r1 : 00ff r0 : > > Flags: nzCv IRQs off FIQs off Mode SVC_32 > > Resetting CPU ... > > > > > I was able to reproduce the issue and git bisect tells me that it started happening after the commit "8475c86 s5p: gpio: change gpio coding method for s5p gpio". Upon debugging further I figured out that it happens because the function fdtdec_setup_gpio returns success even if there is no gpio defined. Since no error is returned the exynos ehci driver goes ahead to setup the gpio and data abort happens. If I return failure from this function it works well. diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 1fecab3..b1c4e92 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -526,7 +526,7 @@ int fdtdec_setup_gpio(struct fdt_gpio_state *gpio) * optional GPIOs) */ if (!fdt_gpio_isvalid(gpio)) - return 0; + return -1; I am not sure of the objective to return success if there is no gpio defined. Simon, could you please suggest where do we need to fix it ? the above function or gpio driver ? Thanks, Inder > > Thanks and Regards > > Armdev@FTM Team > > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] nand/denali: Adding Denali NAND driver support
Hello Chin,
> +static uint32_t denali_dma_configuration(uint32_t ops, bool raw_xfer,
> + uint32_t irq_mask, int oob_required)
Indentation not fixed yet.
I mean, only one tab is too small for the second line.
Rationale: "Documentation/CodingStyle" of Linux Kernel
Accoding to it, the following lines should be "placed to substantially
to the right."
Chapter 2: Breaking long lines and strings
Coding style is all about readability and maintainability using commonly
available tools.
The limit on the length of lines is 80 columns and this is a strongly
preferred limit.
Statements longer than 80 columns will be broken into sensible chunks, unless
exceeding 80 columns significantly increases readability and does not hide
information. Descendants are always substantially shorter than the parent and
are placed substantially to the right. The same applies to function headers
with a long argument list. However, never break user-visible strings such as
printk messages, because that breaks the ability to grep for them.
> +void denali_nand_init(struct nand_chip *nand)
> +{
> + denali.flash_reg = (void __iomem *)CONFIG_SYS_NAND_REGS_BASE;
> + denali.flash_mem = (void __iomem *)CONFIG_SYS_NAND_DATA_BASE;
denali_nand_init() is used only inside this file.
I'd like to suggest to add "static".
> +int board_nand_init(struct nand_chip *chip)
> +{
> + puts("NAND: Denali NAND controller\n");
> + denali_nand_init(chip);
> + return 0;
> +}
Please delete
puts("NAND: Denali NAND controller\n");
With this patch, the boot messages on my board is like this:
U-Boot 2014.04-rc2-00056-g05775a7-dirty (Mar 12 2014 - 13:04:36)
CPU: Peaks LD4 (MN2WS0250) (rev. 3)
Board: Peaks LD4 Board
SC:Micro Support Card (DCC CPLD version 3.6.9)
DRAM: 512 MiB
NAND: NAND: Denali NAND controller
2048 MiB
In:serial
Out: serial
Err: serial
Net: smc911x-0
"NAND: Denali NAND controller" is interrupting
between "NAND: " and "2048 Mib"
I think it is supposed be seen like this:
DRAM: 512 MiB
NAND: 2048 MiB
In:serial
Out: serial
Err: serial
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cfi_flash: Micron Nor flash don't support read operation after send write command
Hi Qi Wang,
please don't send this patch so often.
On 11.03.2014 09:46, Qi Wang 王起 (qiwang) wrote:
Micron Nor flash don't support read operation after send write command.
Are all Micon NOR flash chips affected by this? Or only some chips?
Please list the chips/families and best add a link to the description of
this unsupported operation mode (chapter in data-sheet or errata).
Find a few more comments below.
As below,
flash_write_cmd(info, sector, offset, AMD_CMD_WRITE_TO_BUFFER);
cnt = len >> shift;
flash_write_cmd(info, sector, offset, cnt - 1);
switch (info->portwidth) {
case FLASH_CFI_8BIT:
while (cnt-- > 0) {
flash_write8(flash_read8(src), dst);
src += 1, dst += 1;
}
break;
If the src address locate in NOR flash, flash_read operation will be failed.
So, read out the data to DRAM before send write command operation.
Signed-off-by: Qi Wang
---
drivers/mtd/cfi_flash.c | 70 +++
1 file changed, 46 insertions(+), 24 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index
a389cd1..0f532c0 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
/*
* This file implements a Common Flash Interface (CFI) driver for @@ -855,6
+857,8 @@ static int flash_write_cfibuffer (flash_info_t * info, ulong dest,
uchar * cp,
int cnt;
int retcode;
void *src = cp;
+ void *src2;
+ void *src2_bak;
void *dst = (void *)dest;
void *dst2 = dst;
int flag = 1;
@@ -880,29 +884,45 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
goto out_unmap;
}
+ src2 = malloc(len);
Naming is not optimal, at least for my taste. My not use "src_buf"?
+ if(!src2)
+ {
+ free(src2);
+ return -ENOMEM;
+ }
Incorrect coding style. Please use something like this instead:
if (!src2) {
free(src2);
return -ENOMEM;
}
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cfi_flash: Micron Nor flash don't support read operation after send write command
Hi Stefan,
ok, got it.
Because I saw the patch format is malformed in the website
http://patchwork.ozlabs.org/project/uboot/list/, so I send this patch three
times. You can reference the last patch I submit. It's my first time to submit
Patch to Uboot community. Sorry for bring inconvenient for you.
Sorry for that.
Anyway, can you help check if the patch I submit make sense?
Thanks a lot
-Original Message-
From: Stefan Roese [mailto:s...@denx.de]
Sent: Wednesday, March 12, 2014 1:14 PM
To: Qi Wang 王起 (qiwang); u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] cfi_flash: Micron Nor flash don't support read
operation after send write command
Hi Qi Wang,
please don't send this patch so often.
On 11.03.2014 09:46, Qi Wang 王起 (qiwang) wrote:
> Micron Nor flash don't support read operation after send write command.
Are all Micon NOR flash chips affected by this? Or only some chips?
Please list the chips/families and best add a link to the description of
this unsupported operation mode (chapter in data-sheet or errata).
Find a few more comments below.
> As below,
>
> flash_write_cmd(info, sector, offset, AMD_CMD_WRITE_TO_BUFFER);
> cnt = len >> shift;
> flash_write_cmd(info, sector, offset, cnt - 1);
>
> switch (info->portwidth) {
> case FLASH_CFI_8BIT:
> while (cnt-- > 0) {
> flash_write8(flash_read8(src), dst);
> src += 1, dst += 1;
> }
> break;
>
> If the src address locate in NOR flash, flash_read operation will be failed.
> So, read out the data to DRAM before send write command operation.
>
> Signed-off-by: Qi Wang
> ---
> drivers/mtd/cfi_flash.c | 70 +++
> 1 file changed, 46 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index
> a389cd1..0f532c0 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -25,6 +25,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> /*
>* This file implements a Common Flash Interface (CFI) driver for @@ -855,6
> +857,8 @@ static int flash_write_cfibuffer (flash_info_t * info, ulong dest,
> uchar * cp,
> int cnt;
> int retcode;
> void *src = cp;
> + void *src2;
> + void *src2_bak;
> void *dst = (void *)dest;
> void *dst2 = dst;
> int flag = 1;
> @@ -880,29 +884,45 @@ static int flash_write_cfibuffer (flash_info_t * info,
> ulong dest, uchar * cp,
> goto out_unmap;
> }
>
> + src2 = malloc(len);
Naming is not optimal, at least for my taste. My not use "src_buf"?
> + if(!src2)
> + {
> + free(src2);
> + return -ENOMEM;
> + }
Incorrect coding style. Please use something like this instead:
if (!src2) {
free(src2);
return -ENOMEM;
}
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] kbuild: use "cc-cross-prefix" to choose CROSS_COMPILE
Hello Detlev, Gerhard, Tom, On Wed, 5 Mar 2014 08:37:54 -0500 Tom Rini wrote: > On Wed, Mar 05, 2014 at 06:24:24PM +0900, Masahiro Yamada wrote: > > > CROSS_COMPILE is generally passed from the command line > > or by the environment variable because cross tools > > vary from user to user. > > > > But, having some choices of often used CROSS_COMPILE > > seems reasonable. > > > > $(call cc-cross-prefix, ...) returns the first prefix > > where a prefix$(CC) is found in PATH. > > > > If your cross tools exist in the argument of > > $(call cc-cross-prefix, ...), you do not have to > > specify it explicitly. > > > > Signed-off-by: Masahiro Yamada > > --- > > > > My question is which cross tools are popular enough > > to be added to the list. > > > > In my opition, arm-linux-gnueabi-gcc is popular > > because it is distributed in Ubuntu. > > > > On the other hand, I am not sure ppc_8xx-gcc is currently > > being used. > > > > Which one should be to added/deleted to our default list. > > Your comments are very welcome. > > (I am not familiar with compilers very much.) > > > > > > arch/arm/config.mk| 2 +- > > arch/microblaze/config.mk | 2 +- > > arch/powerpc/config.mk| 2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > Looking at the kernel, mips is a better example of where this becomes a > handy thing, over just a "stop passing CROSS_COMPILE". But that > includes adding tool-archpref. > > -- > Tom Actually, my motivation here was to emulate arch/$(ARCH)/Makefile of Linux Kernel. Some of them are already using cc-cross-prefix. And arch/mips/Makefile looked reasonable enough to me. But if this patch is unwelcome to developers (it looks like so), I do not mind retracting it. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb start crashing on arndale
Dear Inderpal, Thanks for helping us, we were able to test ethernet over usb. It breaks often but it works with the return -1 patch. The following error is observed most of the time EHCI timed out on TD - token=0x8008d80 -Regards armdev team On 12-Mar-2014, at 9:48 am, Inderpal Singh wrote: > Hi, > > > On 11 March 2014 20:25, armdev wrote: > Adding Inderpal singh and Trini. Please help > > On 11-Mar-2014, at 12:27 pm, armdev wrote: > > > Hi, > > > > We have recently started working on arndale and running u-boot head on it. > > Seems like it is crashing on our setup with a data abort on usb start. Can > > anyone please confirm and suggest a fix / solution > > > > U-Boot 2014.04-rc1-00486-geeb72e6 (Mar 11 2014 - 11:44:32) for ARNDALE > > > > CPU:Exynos5250@1000MHz > > > > Board: Arndale > > I2C: i2c_init: failed to init bus 0 for speed = 10 > > ready > > DRAM: 2 GiB > > trace: copying 00084f98 bytes of early data from 5000 to beff > > trace: enabled > > WARNING: Caches not enabled > > MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 > > i2c_init: failed to init bus 0 for speed = 10 > > In:serial > > Out: serial > > Err: serial > > Net: Net Initialization Skipped > > No ethernet found. > > Hit any key to stop autoboot: 0 > > ARNDALE # usb start > > (Re)start USB... > > USB0: data abort > > pc : [] lr : [] > > sp : beb5f9c0 ip : 0003 fp : > > r10: r9 : beb62ecc r8 : befbcc80 > > r7 : befbcc84 r6 : r5 : 00ff r4 : 0001 > > r3 : r2 : 0001 r1 : 00ff r0 : > > Flags: nzCv IRQs off FIQs off Mode SVC_32 > > Resetting CPU ... > > > > > > I was able to reproduce the issue and git bisect tells me that it started > happening after the commit "8475c86 s5p: gpio: change gpio coding method for > s5p gpio". > > Upon debugging further I figured out that it happens because the function > fdtdec_setup_gpio returns success even if there is no gpio defined. Since no > error is returned the exynos ehci driver goes ahead to setup the gpio and > data abort happens. If I return failure from this function it works well. > > diff --git a/lib/fdtdec.c b/lib/fdtdec.c > index 1fecab3..b1c4e92 100644 > --- a/lib/fdtdec.c > +++ b/lib/fdtdec.c > @@ -526,7 +526,7 @@ int fdtdec_setup_gpio(struct fdt_gpio_state *gpio) > * optional GPIOs) > */ > if (!fdt_gpio_isvalid(gpio)) > - return 0; > + return -1; > > > I am not sure of the objective to return success if there is no gpio defined. > Simon, could you please suggest where do we need to fix it ? the above > function or gpio driver ? > > Thanks, > Inder > > > > > Thanks and Regards > > Armdev@FTM Team > > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] mpc85xx/t104x: Add deep sleep framework support
> > > > Could you be more specific? What *path* should I give? > > If I do the below, I got error: > > > > $ make O=/home/tangyt/opensource/u-boot/ > > /home/tangyt/opensource/u-boot is not clean, please run 'make > mrproper' > > in the '/home/tangyt/opensource/u-boot' directory. > > make[1]: *** [prepare3] Error 1 > > make: *** [sub-make] Error 2 > > > > It is out-of-tree compiling. You should use a clean path. > > cd mkdir ../build > make O=../build T1040QDS_config > make O=../build > > You should add other flags you normally use. > > York > I reproduced this issue. I am trying to fix it. Meanwhile please continue to review. Regards, Yuantian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
