Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 10/11/2010 14:24, Daniel Hobi a écrit : > On 10.11.2010 13:48, Albert ARIBAUD wrote: >> Le 10/11/2010 13:31, Daniel Hobi a écrit : > But shouldn't this change be applied to all ARM linker scripts, ie > arch/arm/cpu/*/u-boot.lds? Yes, it should. :) >>> >>> Can you please provide such a patch? >> >> I could, but I tend to provide patches only for boards that I can test, >> which basically covers only arm926ejs, or that I can get tested; I'd >> prefer not to provide patches for HW that I cannot test, and thus I >> would prefer that patches for other cpus be handled by people who >> actually own boards with these cpus and can test their patching. After >> all, this very bugfix is due to ELF relocations having been tested with >> too poor a range of toolchains. > > I prefer a single patch to solve one problem in all places. And since > you probably have most experience with the new ARM relocation, that > patch should come from you. Figures. :) > The ARM architecture and board maintainers will test your patch during > the current release cycle. Alright. I'll prepare a V5 patch set with fixes to all ARM cpus. Wolfgang, is a single *patch* for all cpus ok or do you want a single *patchset* with one patch per cpu? Please tell me the single patch approach is ok. :) > Best regards, > Daniel Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to use the NEON instruction at u-boot?
Kyungmin Park writes:
> Hi,
>
> Now I'm trying to use the NEON instruction at u-boot. but it's failed
> and got the data abort.
> Are there any way to use the NEON instruction at u-boot?
No, just like you can't use floating-point.
> The main purpose is to use the neon memcpy as below.
>
> bge 1f
> // copies 4 bytes, destination 32-bits aligned
> vld4.8 {d0[0], d1[0], d2[0], d3[0]}, [r1]!
> vst4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0, :32]!
> 1: bcc 2f
Plain LDR/STR will be just as fast as that.
--
Måns Rullgård
m...@mansr.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/corenet_ds: display the RCW at boot
From: Timur Tabi
Display the 64-byte Reset Configuration Word (RCW) during boot, so that there's
no confusion as to what RCW U-boot is using.
Reset Configuration Word (RCW):
: 4a50 18181818
0010: 28402400 2000 fe80 0120
0020: 000b
0030:
Signed-off-by: Timur Tabi
Signed-off-by: Roy Zang
Signed-off-by: Kumar Gala
---
board/freescale/corenet_ds/corenet_ds.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/board/freescale/corenet_ds/corenet_ds.c
b/board/freescale/corenet_ds/corenet_ds.c
index 68c63ac..f183cf6 100644
--- a/board/freescale/corenet_ds/corenet_ds.c
+++ b/board/freescale/corenet_ds/corenet_ds.c
@@ -45,6 +45,8 @@ int checkboard (void)
{
u8 sw;
struct cpu_type *cpu = gd->cpu;
+ ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
+ unsigned int i;
printf("Board: %sDS, ", cpu->name);
printf("Sys ID: 0x%02x, Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ",
@@ -66,6 +68,19 @@ int checkboard (void)
puts("36-bit Addressing\n");
#endif
+ /* Display the RCW, so that no one gets confused as to what RCW
+* we're actually using for this boot.
+*/
+ puts("Reset Configuration Word (RCW):");
+ for (i = 0; i < ARRAY_SIZE(gur->rcwsr); i++) {
+ u32 rcw = in_be32(&gur->rcwsr[i]);
+
+ if ((i % 4) == 0)
+ printf("\n %08x:", i * 4);
+ printf(" %08x", rcw);
+ }
+ puts("\n");
+
/* Display the actual SERDES reference clocks as configured by the
* dip switches on the board. Note that the SWx registers could
* technically be set to force the reference clocks to match the
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] add Ben NanoNote board
Dear Xiangfu Liu, In message <1289446657-12499-6-git-send-email-xian...@openmobilefree.net> you wrote: > From: Xiangfu Liu > > Signed-off-by: Xiangfu Liu > --- > board/xburst/nanonote/Makefile| 45 > board/xburst/nanonote/config.mk | 31 ++ > board/xburst/nanonote/nanonote.c | 124 ++ > board/xburst/nanonote/u-boot-nand.lds | 63 +++ > include/configs/nanonote.h| 188 > + > include/configs/qi_lb60.h | 28 + > 6 files changed, 479 insertions(+), 0 deletions(-) > create mode 100644 board/xburst/nanonote/Makefile > create mode 100644 board/xburst/nanonote/config.mk > create mode 100644 board/xburst/nanonote/nanonote.c > create mode 100644 board/xburst/nanonote/u-boot-nand.lds > create mode 100644 include/configs/nanonote.h > create mode 100644 include/configs/qi_lb60.h Entry to MAINTAINERS mssing. Entry to boards.cfg missing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Motto of the Electrical Engineer: Working computer hardware is a lot like an erect penis: it stays up as long as you don't fuck with it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to use the NEON instruction at u-boot?
2010/11/11 Måns Rullgård :
> Kyungmin Park writes:
>
>> Hi,
>>
>> Now I'm trying to use the NEON instruction at u-boot. but it's failed
>> and got the data abort.
>> Are there any way to use the NEON instruction at u-boot?
>
> No, just like you can't use floating-point.
I don't use the floating-point just use the 64 or 128 registers for memcpy.
>
>> The main purpose is to use the neon memcpy as below.
>>
>> bge 1f
>> // copies 4 bytes, destination 32-bits aligned
>> vld4.8 {d0[0], d1[0], d2[0], d3[0]}, [r1]!
>> vst4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0, :32]!
>> 1: bcc 2f
>
> Plain LDR/STR will be just as fast as that.
I saw you patches and the result using neon is better than ARM optimized memcpy.
Now I used the ARM optimized memcpy. and try to find a better solution as NEON.
Thank you,
Kyungmin Park
>
> --
> Måns Rullgård
> m...@mansr.com
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to use the NEON instruction at u-boot?
Hi Kyungmin Park,
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> boun...@lists.denx.de] On Behalf Of Kyungmin Park
> Sent: Thursday, November 11, 2010 11:05 AM
> To: u-boot@lists.denx.de"
> Cc: Minkyu Kang
> Subject: [U-Boot] How to use the NEON instruction at u-boot?
>
> Hi,
>
> Now I'm trying to use the NEON instruction at u-boot. but it's
> failed
> and got the data abort.
> Are there any way to use the NEON instruction at u-boot?
>
> The main purpose is to use the neon memcpy as below.
>
> bge 1f
> // copies 4 bytes, destination 32-bits aligned
> vld4.8 {d0[0], d1[0], d2[0], d3[0]}, [r1]!
> vst4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0, :32]!
> 1: bcc 2f
>
I am not sure if there is a valid use-case for this. But if you
are keen on using Neon you will have to enable the co-processor first.
Here is a piece of code I wrote for doing this in another bootloader.
#define VMSR_FPSCR_r0 dcd 0xeee80a10
#define VMRS_r0_FPSCR dcd 0xeef80a10
__asm uint32 enable_neon(void)
{
ldr r0, =0x00F0
MCR p15,0,r0,c1,c0,2 // CP15 Coprocessor Access Control Register
ldr r0, =0x4000
VMSR_FPSCR_r0
VMRS_r0_FPSCR
bx r14
}
This is written for RVCT tool chain. So you may have to convert it
for GCC. Also, my assembler didn't allow ARMv7 instructions. So, I
used DCD. You can either use .word in gcc or use the real instructions
if your assembler understands those instructions.
> Thank you,
> Kyungmin Park
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to use the NEON instruction at u-boot?
On Thu, Nov 11, 2010 at 5:58 PM, V, Aneesh wrote:
> Hi Kyungmin Park,
>
>> -Original Message-
>> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
>> boun...@lists.denx.de] On Behalf Of Kyungmin Park
>> Sent: Thursday, November 11, 2010 11:05 AM
>> To: u-boot@lists.denx.de"
>> Cc: Minkyu Kang
>> Subject: [U-Boot] How to use the NEON instruction at u-boot?
>>
>> Hi,
>>
>> Now I'm trying to use the NEON instruction at u-boot. but it's
>> failed
>> and got the data abort.
>> Are there any way to use the NEON instruction at u-boot?
>>
>> The main purpose is to use the neon memcpy as below.
>>
>> bge 1f
>> // copies 4 bytes, destination 32-bits aligned
>> vld4.8 {d0[0], d1[0], d2[0], d3[0]}, [r1]!
>> vst4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0, :32]!
>> 1: bcc 2f
>>
>
> I am not sure if there is a valid use-case for this. But if you
> are keen on using Neon you will have to enable the co-processor first.
> Here is a piece of code I wrote for doing this in another bootloader.
>
> #define VMSR_FPSCR_r0 dcd 0xeee80a10
> #define VMRS_r0_FPSCR dcd 0xeef80a10
> __asm uint32 enable_neon(void)
> {
> ldr r0, =0x00F0
> MCR p15,0,r0,c1,c0,2 // CP15 Coprocessor Access Control Register
> ldr r0, =0x4000
> VMSR_FPSCR_r0
> VMRS_r0_FPSCR
> bx r14
> }
Thanks
NEON instruction is working but need to debug to use it correctly.
I used it as below.
ldr r0, =0x00F0
mcr p15, 0, r0, c1, c0, 2
ldr r0, =0x4000
.word 0xeee80a10
.word 0xeef80a10
Thank you,
Kyungmin Park
>
> This is written for RVCT tool chain. So you may have to convert it
> for GCC. Also, my assembler didn't allow ARMv7 instructions. So, I
> used DCD. You can either use .word in gcc or use the real instructions
> if your assembler understands those instructions.
>
>> Thank you,
>> Kyungmin Park
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Hope all is well
Hope all is well! I am not sure why but it has been really hard to get a response from you on this situation! My guess is that my mail is not being sent out, I shot support an email to see if there is a problem, Hope they can get it fixed. I did not get a response from you; Can you tell me if you got my email? You do not seem like the type of person that would blow someone off.I would like to get better acquainted also; Well I pray that you get this one and that we can hopefully get something started if were right for each other,thanks Linda.___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v0]p1_p2_rdb: to set SQW/INT pin of RTC as INT line
On Oct 25, 2010, at 4:22 AM, Priyanka Jain wrote: > p1_p2_rdb : SQW/INT pin in RTC can be used for > generating square wave(by default) or as interrupt line. > U-boot is registering this pin for interrupts. > Configuring SQW/INT bit as interrupt line during board initialization > to avoid spurious interrupts generated by square wave. > > Signed-off-by: Priyanka Jain > --- > board/freescale/p1_p2_rdb/p1_p2_rdb.c |1 + > include/configs/P1_P2_RDB.h |1 + > 2 files changed, 2 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
Kim, Timur, some comments on this from your side would really help ! The issue can be summarized like this : - MPC8377 based board is basically running fine with both U-Boot and Linux. - Activating USB support within U-Boot leads to *very* early crash : No console output - not even PCI clocks enabled. - Within Linux USB is working without problems, i.e. there's no hardware issue. I have an SMSC USB3300 PHY connected via ULPI and a self powered SMSC 2514 1:4 Hub. This is exactly the same as on mvblm7 board (=MPC8343). This behaviour reminds me of e.g. one or more missing sync instructions during early init as discussed with Jocke in the past weeks. It is very unlikely that I'm the only one facing this problem. Can you at least tell me whether there are 837x boards known to work with latest code utilizing USB and Nor-Boot ? Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] submissions
Dear Mr & Mis: I'm appreciate being taken in. Thank you very much. -- Best regards, Terry Liu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] da8xx: add SPI Flash support
The following patches were already sent to the Arago project, but not yet to u-boot ML to be merged into the mainline. They add support for the SPI flash. Compared to the original patches, they are only rebased on the current u-boot tree. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] da8xx: Add cpu_is_da8xx macros
From: Sudhakar Rajashekhara
Signed-off-by: Sudhakar Rajashekhara
CC: Stefano Babic
CC: Detlev Zundev
CC: Ben Gardiner
---
arch/arm/include/asm/arch-davinci/hardware.h | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index 3520cf8..2a460b5 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -149,6 +149,7 @@ typedef volatile unsigned int * dv_reg_p;
#define DAVINCI_DDR_EMIF_DATA_BASE 0xc000
#define DAVINCI_INTC_BASE 0xfffee000
#define DAVINCI_BOOTCFG_BASE 0x01c14000
+#define JTAG_ID_REG(DAVINCI_BOOTCFG_BASE + 0x18)
#endif /* CONFIG_SOC_DA8XX */
@@ -442,6 +443,21 @@ struct davinci_uart_ctrl_regs {
#define DAVINCI_UART_PWREMU_MGMT_URRST (1 << 13)
#define DAVINCI_UART_PWREMU_MGMT_UTRST (1 << 14)
+static inline int cpu_is_da830(void)
+{
+ unsigned int jtag_id= REG(JTAG_ID_REG);
+ unsigned short part_no = (jtag_id >> 12) & 0x;
+
+ return ((part_no == 0xb7df) ? 1 : 0);
+}
+static inline int cpu_is_da850(void)
+{
+ unsigned int jtag_id= REG(JTAG_ID_REG);
+ unsigned short part_no = (jtag_id >> 12) & 0x;
+
+ return ((part_no == 0xb7d1) ? 1 : 0);
+}
+
#endif /* CONFIG_SOC_DA8XX */
#endif /* __ASM_ARCH_HARDWARE_H */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] da850: Enable SPI Flash
The patch was already posted to the arago project,
but not yet to mainline. It allows to save environment into
the spi flash. Tested on LogiPD tmdxl138.
Signed-off-by: Sudhakar Rajashekhara
Signed-off-by: Stefano Babic
CC: Detlev Zundev
CC: Ben Gardiner
---
arch/arm/include/asm/arch-davinci/hardware.h | 12 ++-
include/configs/da850evm.h | 28 ++
2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index 2a460b5..21b2076 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -133,7 +133,8 @@ typedef volatile unsigned int * dv_reg_p;
#define DAVINCI_PSC1_BASE 0x01e27000
#define DAVINCI_SPI0_BASE 0x01c41000
#define DAVINCI_USB_OTG_BASE 0x01e0
-#define DAVINCI_SPI1_BASE 0x01e12000
+#define DAVINCI_SPI1_BASE (cpu_is_da830() ? \
+ 0x01e12000 : 0x01f0e000)
#define DAVINCI_GPIO_BASE 0x01e26000
#define DAVINCI_EMAC_CNTRL_REGS_BASE 0x01e23000
#define DAVINCI_EMAC_WRAPPER_CNTRL_REGS_BASE 0x01e22000
@@ -364,6 +365,9 @@ struct davinci_pllc_regs {
#define davinci_pllc_regs ((struct davinci_pllc_regs *)DAVINCI_PLL_CNTRL0_BASE)
#define DAVINCI_PLLC_DIV_MASK 0x1f
+#define ASYNC3 get_async3_src()
+#define PLL1_SYSCLK2 ((1 << 16) | 0x2)
+#define DAVINCI_SPI1_CLKID (cpu_is_da830() ? 2 : ASYNC3)
/* Clock IDs */
enum davinci_clk_ids {
DAVINCI_SPI0_CLKID = 2,
@@ -458,6 +462,12 @@ static inline int cpu_is_da850(void)
return ((part_no == 0xb7d1) ? 1 : 0);
}
+static inline int get_async3_src(void)
+{
+ return (REG(&davinci_syscfg_regs->cfgchip3) & 0x10) ?
+ PLL1_SYSCLK2 : 2;
+}
+
#endif /* CONFIG_SOC_DA8XX */
#endif /* __ASM_ARCH_HARDWARE_H */
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 7b04be0..8e273b4 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -27,6 +27,7 @@
* Board
*/
#define CONFIG_DRIVER_TI_EMAC
+#define CONFIG_USE_SPIFLASH
/*
* SoC Configuration
@@ -71,6 +72,15 @@
#define CONFIG_BAUDRATE115200 /* Default baud rate */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
+#define CONFIG_SPI
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_STMICRO
+#define CONFIG_DAVINCI_SPI
+#define CONFIG_SYS_SPI_BASEDAVINCI_SPI1_BASE
+#define CONFIG_SYS_SPI_CLK clk_get(DAVINCI_SPI1_CLKID)
+#define CONFIG_SF_DEFAULT_SPEED3000
+#define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED
+
/*
* I2C Configuration
*/
@@ -116,6 +126,16 @@
#define CONFIG_NET_MULTI
#endif
+#ifdef CONFIG_USE_SPIFLASH
+#undef CONFIG_ENV_IS_IN_FLASH
+#undef CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_ENV_SIZE(64 << 10)
+#define CONFIG_ENV_OFFSET (256 << 10)
+#define CONFIG_ENV_SECT_SIZE (64 << 10)
+#define CONFIG_SYS_NO_FLASH
+#endif
+
/*
* U-Boot general configuration
*/
@@ -179,6 +199,14 @@
#define CONFIG_CMD_UBIFS
#endif
+#ifdef CONFIG_USE_SPIFLASH
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_FLASH
+#define CONFIG_CMD_SPI
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SAVEENV
+#endif
+
#if !defined(CONFIG_USE_NAND) && \
!defined(CONFIG_USE_NOR) && \
!defined(CONFIG_USE_SPIFLASH)
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] da850: Enable SPI Flash
Hi Stefano, > The patch was already posted to the arago project, > but not yet to mainline. It allows to save environment into > the spi flash. Tested on LogiPD tmdxl138. If this patch is only "transferred" by you, then please do not change the commit message so that (ideally) one can trace a commit through trees using the messages. Add such additional (transient) information below the "--" in the mail so it will not get into the repository. Thanks! Detlev -- Q: What do you get when you cross an elephant and a banana? A: |elephant| * |banana| * sin(theta) -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Hanging in kmalloc of nand_scan_tail() function
Dear everyone, I'm using u-boot-2010.09. After I download u-boot.bin to my boards(cpu is s3c2410),the output from serial shows that cpu has exception, the information list as following: U-Boot 2010.09 (Nov 11 2010 - 21:55:07) U-Boot code: 33F8 -> 33FA0BDC BSS: -> 33FA45EC RAM Configuration: Bank #0: 3000 64 MiB NAND: data abort pc : [<33f8fbb4>] lr : [<33f85f70>] sp : 33f07fac ip : fp : r10: 1298 r9 : ff7f r8 : 33f4ffe0 r7 : r6 : 33fa3b50 r5 : 33fa3c00 r4 : 33fa0274 r3 : 33f9ff54 r2 : 0064 r1 : 0001 r0 : cc33cc33 Flags: NzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... value of pc locate at function, value of lr locate at (/drivers/mtd/nand/nand_base.c). I have seen that someone had this problem before, have you resolved it? Can you give me some suggestions? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v0] e1000_initialize: memset 0x0 nic and hw structure before their use
On Nov 11, 2010, at 1:37 AM, Wolfgang Denk wrote: > Dear Prabhakar, > > In message <1289451431-22179-1-git-send-email-prabha...@freescale.com> you > wrote: >> nic and hw structures are allocated via malloc i.e. return memory >> is not zero initialized. Because of this few structure member like >> "function pointers" are initialized with garbage values. >> >> It may cause problem. for eg. during eth_initialize, dev->write_hwaddr >> is used. > > thanks. I already have a patch series "Add initialized eth_device > structure" on my stack. I think this covers this, too. which patch is that? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] da8xx: Add cpu_is_da8xx macros
On Thu, Nov 11, 2010 at 9:38 AM, Stefano Babic wrote: > From: Sudhakar Rajashekhara > > Signed-off-by: Sudhakar Rajashekhara > CC: Stefano Babic > CC: Detlev Zundev > CC: Ben Gardiner Applies cleanly to 0c0892be0d93a5a892b93739c5eb3bf692fed4ff of git://git.denx.de/u-boot.git; no checkpatch warnings. Tested along with "[PATCH 2/2] da850: Enable SPI Flash" on da850evm with no changes to the config. SPI flash was usable as the environment and location of the u-boot image. Tested-by: Ben Gardiner Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] da850: Enable SPI Flash
On 11/11/2010 03:55 PM, Detlev Zundel wrote: > If this patch is only "transferred" by you, then please do not change > the commit message so that (ideally) one can trace a commit through > trees using the messages. Agree, this is the case of the first patch in the patchset. However, this patch has some slight changes and it will be erroneous to think that it is exactly the same. I think the best solution is to add the original commit message to mine, and grepping for the original message will still work. I'll do in V2. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
On Thu, Nov 11, 2010 at 6:24 AM, Andre Schwarz wrote: > - Activating USB support within U-Boot leads to *very* early crash : > No console output - not even PCI clocks enabled. I don't know anything about USB or the 8377, but it could be that you're U-Boot image is too large. Try disabling some other large feature (like PCI and Ethernet support) and booting that image. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] TQM85xx: Fix bug introduced by 83xx/85xx/86xx: LBC register cleanup
The size of the other bank needed to be added to the br0 setting; this got dropped in the LBC cleanup. Signed-off-by: Becky Bruce --- This has been neither built or tested, as TQM8555 doesn't seem to build on the head of this tree, and I don't have a board to test on. board/tqc/tqm85xx/tqm85xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/tqc/tqm85xx/tqm85xx.c b/board/tqc/tqm85xx/tqm85xx.c index 2c3885f..b21e791 100644 --- a/board/tqc/tqm85xx/tqm85xx.c +++ b/board/tqc/tqm85xx/tqm85xx.c @@ -298,7 +298,7 @@ int misc_init_r (void) */ set_lbc_or(0, ((-flash_info[1].size) & 0x8000) | (CONFIG_SYS_OR0_PRELIM & 0x7fff)); - set_lbc_br(0, gd->bd->bi_flashstart | + set_lbc_br(0, (gd->bd->bi_flashstart + flash_info[0].size) | (CONFIG_SYS_BR0_PRELIM & 0x7fff)); /* -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] TQM85xx: Fix bug introduced by 83xx/85xx/86xx: LBC register cleanup
The size of the other bank needed to be added to the br0 setting; this got dropped in the LBC cleanup. Signed-off-by: Becky Bruce --- This has been neither built or tested, as TQM8555 doesn't seem to build on the head of this tree, and I don't have a board to test on. board/tqc/tqm85xx/tqm85xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/tqc/tqm85xx/tqm85xx.c b/board/tqc/tqm85xx/tqm85xx.c index 2c3885f..b21e791 100644 --- a/board/tqc/tqm85xx/tqm85xx.c +++ b/board/tqc/tqm85xx/tqm85xx.c @@ -298,7 +298,7 @@ int misc_init_r (void) */ set_lbc_or(0, ((-flash_info[1].size) & 0x8000) | (CONFIG_SYS_OR0_PRELIM & 0x7fff)); - set_lbc_br(0, gd->bd->bi_flashstart | + set_lbc_br(0, (gd->bd->bi_flashstart + flash_info[0].size) | (CONFIG_SYS_BR0_PRELIM & 0x7fff)); /* -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hanging in kmalloc of nand_scan_tail() function
On Thu, 11 Nov 2010 23:06:01 +0800 terry wrote: > Dear everyone, > I'm using u-boot-2010.09. After I download u-boot.bin to my boards(cpu > is s3c2410),the output from serial shows that cpu has exception, the > information list as following: > U-Boot 2010.09 (Nov 11 2010 - 21:55:07) > > U-Boot code: 33F8 -> 33FA0BDC BSS: -> 33FA45EC > RAM Configuration: > Bank #0: 3000 64 MiB > NAND: data abort > pc : [<33f8fbb4>] lr : [<33f85f70>] > sp : 33f07fac ip : fp : > r10: 1298 r9 : ff7f r8 : 33f4ffe0 > r7 : r6 : 33fa3b50 r5 : 33fa3c00 r4 : 33fa0274 > r3 : 33f9ff54 r2 : 0064 r1 : 0001 r0 : cc33cc33 > Flags: NzCv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... > > value of pc locate at function, value of lr locate at > (/drivers/mtd/nand/nand_base.c). Could you look up the specific line numbers of 0x33f8fbb4 and 0x33f85f6c, and show a few lines of disassembly around those addresses? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Change of ColdFire Custodian
Hi, Here is a short announcement about a change in the U-boot ColdFire custodian. It is unfortunately that I have less time to take care of the ColdFire custodianship for some time now, and I was looking for right candidate to take over this ColdFire custodianship. Jason (Jin Zhengxiong) has experience in ColdFire u-boot/Linux development, he is qualified for this task. I propose Jin Zhengxiong as new ColdFire u-boot custodian. Any comments? Regards, TsiChung ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
Timur, > > - Activating USB support within U-Boot leads to *very* early crash : > > No console output - not even PCI clocks enabled. > > I don't know anything about USB or the 8377, but it could be that > you're U-Boot image is too large. Try disabling some other large > feature (like PCI and Ethernet support) and booting that image. I'm at 300KiB at the moment with plenty of flash. Is there anything specific you're thinking about ? Will try to dig into it by disabling USB init functions step-by-step then ... Cheers, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
On Thu, Nov 11, 2010 at 2:11 PM, Schwarz,Andre wrote: > I'm at 300KiB at the moment with plenty of flash. > > Is there anything specific you're thinking about ? No, it's just wild speculation. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TQM85xx: Fix bug introduced by 83xx/85xx/86xx: LBC register cleanup
Dear Becky Bruce, In message <1289496785-9243-1-git-send-email-bec...@kernel.crashing.org> you wrote: > The size of the other bank needed to be added to the br0 setting; > this got dropped in the LBC cleanup. > > Signed-off-by: Becky Bruce > --- > This has been neither built or tested, as TQM8555 doesn't seem to build on the > head of this tree, and I don't have a board to test on. It build just fine for me... What exactly are your problems? [And which tool chain are you using?] Your patch indeed fixes the problem (and I'm a bit angry with myself that I didn't see this problem myself.) Thanks a lot! Tested on TQM8555. Tested-by: Wolfgang Denk Acked-by: Wolfgang Denk Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de We are all agreed that your theory is crazy. The question which divides us is whether it is crazy enough to have a chance of being correct. My own feeling is that it is not crazy enough. - Niels Bohr ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v0] e1000_initialize: memset 0x0 nic and hw structure before their use
Dear Kumar Gala, In message you wrote: > > > thanks. I already have a patch series "Add initialized eth_device > > structure" on my stack. I think this covers this, too. > > which patch is that? Um... you're right, e1000 is not included there, only e100. In any case, the fix should be implemented in the same way and style as in that series - for a reference please see http://article.gmane.org/gmane.comp.boot-loaders.u-boot/86816 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "There's only one kind of woman ..." "Or man, for that matter. You either believe in yourself or you don't." -- Kirk and Harry Mudd, "Mudd's Women", stardate 1330.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: S3C64XX: fix timer broken by relocation
Dear Darius Augulis,
On 2 November 2010 05:49, Darius Augulis wrote:
> S3C64XX timer uses static variables which
> are initialized before relocation and used after it.
> Move them to global data structure.
>
> Signed-off-by: Darius Augulis
> ---
> arch/arm/cpu/arm1176/s3c64xx/timer.c | 36
> ++
> arch/arm/include/asm/global_data.h | 6 ++
> 2 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/cpu/arm1176/s3c64xx/timer.c
> b/arch/arm/cpu/arm1176/s3c64xx/timer.c
> index 9768319..4e420cb 100644
> --- a/arch/arm/cpu/arm1176/s3c64xx/timer.c
> +++ b/arch/arm/cpu/arm1176/s3c64xx/timer.c
> @@ -43,7 +43,7 @@
> #include
> #include
>
> -static ulong timer_load_val;
> +DECLARE_GLOBAL_DATA_PTR;
>
> #define PRESCALER 167
>
> @@ -60,12 +60,6 @@ static inline ulong read_timer(void)
> return timers->TCNTO4;
> }
>
> -/* Internal tick units */
> -/* Last decremneter snapshot */
> -static unsigned long lastdec;
> -/* Monotonic incrementing timer */
> -static unsigned long long timestamp;
> -
> int timer_init(void)
> {
> s3c64xx_timers *const timers = s3c64xx_get_base_timers();
> @@ -83,20 +77,20 @@ int timer_init(void)
> * the prescaler automatically for other PCLK frequencies.
> */
> timers->TCFG0 = PRESCALER << 8;
> - if (timer_load_val == 0) {
> - timer_load_val = get_PCLK() / PRESCALER * (100 / 4); /* 100s
> */
> + if (gd->timer_load_val == 0) {
> + gd->timer_load_val = get_PCLK() / PRESCALER * (100 / 4); /*
> 100s */
> timers->TCFG1 = (timers->TCFG1 & ~0xf) | 0x2;
> }
>
> /* load value for 10 ms timeout */
> - lastdec = timers->TCNTB4 = timer_load_val;
> + gd->lastdec = timers->TCNTB4 = gd->timer_load_val;
> /* auto load, manual update of Timer 4 */
> timers->TCON = (timers->TCON & ~0x0070) | TCON_4_AUTO |
> TCON_4_UPDATE;
>
> /* auto load, start Timer 4 */
> timers->TCON = (timers->TCON & ~0x0070) | TCON_4_AUTO | COUNT_4_ON;
> - timestamp = 0;
> + gd->timestamp = 0;
>
> return 0;
> }
> @@ -113,16 +107,16 @@ unsigned long long get_ticks(void)
> {
> ulong now = read_timer();
>
> - if (lastdec >= now) {
> + if (gd->lastdec >= now) {
> /* normal mode */
> - timestamp += lastdec - now;
> + gd->timestamp += gd->lastdec - now;
> } else {
> /* we have an overflow ... */
> - timestamp += lastdec + timer_load_val - now;
> + gd->timestamp += gd->lastdec + gd->timer_load_val - now;
> }
> - lastdec = now;
> + gd->lastdec = now;
>
> - return timestamp;
> + return gd->timestamp;
> }
>
> /*
> @@ -132,14 +126,14 @@ unsigned long long get_ticks(void)
> ulong get_tbclk(void)
> {
> /* We overrun in 100s */
> - return (ulong)(timer_load_val / 100);
> + return (ulong)(gd->timer_load_val / 100);
> }
>
> void reset_timer_masked(void)
> {
> /* reset time */
> - lastdec = read_timer();
> - timestamp = 0;
> + gd->lastdec = read_timer();
> + gd->timestamp = 0;
> }
>
> void reset_timer(void)
> @@ -150,7 +144,7 @@ void reset_timer(void)
> ulong get_timer_masked(void)
> {
> unsigned long long res = get_ticks();
> - do_div (res, (timer_load_val / (100 * CONFIG_SYS_HZ)));
> + do_div (res, (gd->timer_load_val / (100 * CONFIG_SYS_HZ)));
> return res;
> }
>
> @@ -161,7 +155,7 @@ ulong get_timer(ulong base)
>
> void set_timer(ulong t)
> {
> - timestamp = t * (timer_load_val / (100 * CONFIG_SYS_HZ));
> + gd->timestamp = t * (gd->timer_load_val / (100 * CONFIG_SYS_HZ));
> }
>
> void __udelay(unsigned long usec)
> diff --git a/arch/arm/include/asm/global_data.h
> b/arch/arm/include/asm/global_data.h
> index ada3fbb..69fb7b6 100644
> --- a/arch/arm/include/asm/global_data.h
> +++ b/arch/arm/include/asm/global_data.h
> @@ -61,6 +61,12 @@ typedef struct global_data {
> unsigned long tbu;
> unsigned long long timer_reset_value;
> #endif
> +#ifdef CONFIG_S3C64XX
> + /* "static data" needed by s3c64xx's timer.c */
> + unsigned long timer_load_val;
> + unsigned long lastdec;
> + unsigned long long timestamp;
> +#endif
> unsigned long relocaddr; /* Start address of U-Boot in RAM */
> phys_size_t ram_size; /* RAM size */
> unsigned long mon_len; /* monitor len */
>
I think it's not good way.
We just need to fix the timer_init function.
Because we can use the static variables after relocation.
I'll post the timer patch for s5p series.
Please refer it.
Thanks
Minkyu Kang
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/li
Re: [U-Boot] [PATCH] zlib: updated to v.1.2.3
Hi Wolfgang, As you had suggested I tried build u-boot with one of the 2010.09v. But I observe the same failures in them. The configuration step of u-boot for the boards works fine but the cross-compiling shows the same crc32 error. $ make at91sam9263ek_config Configuring for at91sam9263ek board... $ make CROSS_COMPILE=arm-linux- for dir in tools examples/standalone examples/api arch/arm/cpu/arm926ejs /home/R anga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/arch/arm/cpu/arm926ejs/ ; do \ make -C $dir _depend ; done make[1]: Entering directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09- rc1/tools' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-r c1/tools' make[1]: Entering directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09- rc1/examples/standalone' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-r c1/examples/standalone' make[1]: Entering directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09- rc1/examples/api' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-r c1/examples/api' make[1]: Entering directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09- rc1/arch/arm/cpu/arm926ejs' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-r c1/arch/arm/cpu/arm926ejs' make[1]: Entering directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09- rc1/arch/arm/cpu/arm926ejs' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-r c1/arch/arm/cpu/arm926ejs' make -C tools all make[1]: Entering directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09- rc1/tools' gcc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/Ranga /MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/include -idirafter /home/Ranga/MyPrj /LinuxPort/bootldr/u-boot-2010.09-rc1/include2 -idirafter /home/Ranga/MyPrj/Linu xPort/bootldr/u-boot-2010.09-rc1/include -I /home/Ranga/MyPrj/LinuxPort/bootldr/ u-boot-2010.09-rc1/lib/libfdt -I /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010 .09-rc1/tools -DTEXT_BASE=0x23f0 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -ansi -pedantic -c -o crc32.o /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/l ib/crc32.c In file included from /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/lib /crc32.c:20: /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/include/u-boot/zl ib.h:667 : error: conflicting types for 'crc32' /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/include/u-boot/cr c.h:29: error: previous declaration of 'crc32' was here /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/include/u-boot/zl ib.h:667 : error: conflicting types for 'crc32' /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/include/u-boot/cr c.h:29: error: previous declaration of 'crc32' was here /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/lib/crc32.c:220: error: c onflicting types for 'crc32' /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/include/u-boot/zl ib.h:667 : error: previous declaration of 'crc32' was here /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/lib/crc32.c:220: error: c onflicting types for 'crc32' /home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-rc1/include/u-boot/zl ib.h:667 : error: previous declaration of 'crc32' was here make[1]: *** [crc32.o] Error 1 make[1]: Leaving directory `/home/Ranga/MyPrj/LinuxPort/bootldr/u-boot-2010.09-r c1/tools' make: *** [tools] Error 2 I am a newbie to U-boot and linux, so please let me know if I am going wrong anywhere. Here are the steps I have followed. 1) I have an at91sam9263ek_config board and I built my toolchain and am trying to build u-boot using cygwin environment. 2) My toolchain was built without errors but I did not include at91 specific linux header files while building my toolchain - could this affect building u-boot? 3) Is there any compatibility between linux kernel and uboot version I need to take into account while building u-boot? 4) I also observed one more thing: I receive compile errors mentioned above, only from the third time I run the CROSS_COMPILE command. The first two times I run it, I receive a lot more erros. Please let me know if there is anything I have missed out. Regards, Shyama. -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, November 11, 2010 1:32 AM To: Asokan, Shyama Trikkadeeri Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] zlib: updated to v.1.2.3 Dear "Asokan, Shyama Trikkadeeri", In message <575ed9d63b7e244bbb3786a299acbba08af...@ie10ev813.global.ds.honeywell.co m> you wrote: > > It looks like there has been a mail chain regarding this compile error > and it has also been fixed. Can someone let me know which uboo
[U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
suggested from Daniel Hobi Tested on following boards: arm1136: qong armv7: omap3_beagle arm926ejs: magnesium, tx25 Signed-off-by: Heiko Schocher cc: Daniel Hobi cc: Albert ARIBAUD --- arch/arm/cpu/arm1136/start.S |1 + arch/arm/cpu/arm1176/start.S |1 + arch/arm/cpu/arm720t/start.S |1 + arch/arm/cpu/arm920t/start.S |1 + arch/arm/cpu/arm925t/start.S |1 + arch/arm/cpu/arm926ejs/start.S |1 + arch/arm/cpu/arm946es/start.S |1 + arch/arm/cpu/arm_intcm/start.S |1 + arch/arm/cpu/armv7/start.S |1 + arch/arm/cpu/ixp/start.S |1 + arch/arm/cpu/lh7a40x/start.S |1 + arch/arm/cpu/pxa/start.S |1 + arch/arm/cpu/s3c44b0/start.S |1 + arch/arm/cpu/sa1100/start.S|1 + arch/arm/lib/board.c |2 +- 15 files changed, 15 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S index aecc943..f8558c1 100644 --- a/arch/arm/cpu/arm1136/start.S +++ b/arch/arm/cpu/arm1136/start.S @@ -176,6 +176,7 @@ next: /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x #ifdef CONFIG_NAND_SPL diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index f04d268..03365dc 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S @@ -251,6 +251,7 @@ skip_tcmdisable: /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x bl board_init_f diff --git a/arch/arm/cpu/arm720t/start.S b/arch/arm/cpu/arm720t/start.S index 8cd267b..21b2aca 100644 --- a/arch/arm/cpu/arm720t/start.S +++ b/arch/arm/cpu/arm720t/start.S @@ -159,6 +159,7 @@ reset: /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x bl board_init_f diff --git a/arch/arm/cpu/arm920t/start.S b/arch/arm/cpu/arm920t/start.S index d4edde7..57430f8 100644 --- a/arch/arm/cpu/arm920t/start.S +++ b/arch/arm/cpu/arm920t/start.S @@ -205,6 +205,7 @@ copyex: /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x bl board_init_f diff --git a/arch/arm/cpu/arm925t/start.S b/arch/arm/cpu/arm925t/start.S index 51229c6..3e6dd90 100644 --- a/arch/arm/cpu/arm925t/start.S +++ b/arch/arm/cpu/arm925t/start.S @@ -196,6 +196,7 @@ poll1: /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x bl board_init_f diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6dcc9b4..bf4988d 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -174,6 +174,7 @@ reset: /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x bl board_init_f diff --git a/arch/arm/cpu/arm946es/start.S b/arch/arm/cpu/arm946es/start.S index cad43ba..1d9ba30 100644 --- a/arch/arm/cpu/arm946es/start.S +++ b/arch/arm/cpu/arm946es/start.S @@ -165,6 +165,7 @@ reset: /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x bl board_init_f diff --git a/arch/arm/cpu/arm_intcm/start.S b/arch/arm/cpu/arm_intcm/start.S index 957ca34..c481de7 100644 --- a/arch/arm/cpu/arm_intcm/start.S +++ b/arch/arm/cpu/arm_intcm/start.S @@ -163,6 +163,7 @@ reset: /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x bl board_init_f diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index bb3948d..691eab0 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -166,6 +166,7 @@ next: /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x bl board_in
Re: [U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
Dear Heiko Schocher,
> diff --git a/arch/arm/cpu/sa1100/start.S b/arch/arm/cpu/sa1100/start.S
> index ace0c07..91cdd72 100644
> --- a/arch/arm/cpu/sa1100/start.S
> +++ b/arch/arm/cpu/sa1100/start.S
> @@ -152,6 +152,7 @@ reset:
> /* Set stackpointer in internal RAM to call board_init_f */
> call_board_init_f:
> ldr sp, =(CONFIG_SYS_INIT_SP_ADDR)
> + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
> ldr r0,=0x
> bl board_init_f
>
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index 1fd5f83..96c0e30 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -276,7 +276,7 @@ void board_init_f (ulong bootflag)
> ulong addr, addr_sp;
>
> /* Pointer is writable since we allocated a register for it */
> - gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
> + gd = (gd_t *) ((CONFIG_SYS_INIT_SP_ADDR)& ~0x07);
> /* compiler optimization barrier needed for GCC>= 3.4 */
> __asm__ __volatile__("": : :"memory");
>
Is bootflag ever used? If not, why not change the parameter to
give the gd address to board_init_f?
ld r0, sp (whatever the exact assembly syntax for that would be)
void board_init_f (gd_t *gd_addr)
...
gd = gd_addr;
One further thought, why not init the reserved register in assembly and
remove the gd relevant code in C? But that bears some risk if the register
is changed and the assembly is forgotten to adapt..
Best regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] Add readme of how to boot from espi flash for p4080ds.
Signed-off-by: Shaohui Xie --- doc/README.espi-boot-p4080ds | 82 ++ 1 files changed, 82 insertions(+), 0 deletions(-) create mode 100644 doc/README.espi-boot-p4080ds diff --git a/doc/README.espi-boot-p4080ds b/doc/README.espi-boot-p4080ds new file mode 100644 index 000..50447c1 --- /dev/null +++ b/doc/README.espi-boot-p4080ds @@ -0,0 +1,82 @@ +Overview: += +The P4080 integrates a pre-boot-loader(PBL) which performs configuration +registers read and write to initialize external memory devices such as I2c, +eLBC FCM(NAND flash), eSDHC, or SPI interface, loads RCW and/or pre-boot +initialization commands from those devices before the local cores are permitted +to boot. + +Boot from SPI: +== + +The P4080 is capable of booting from SPI. The bootup process can be divided into +two stages: the first stage will load RCW and write configuration registers to +initialize SPI interface, and configure CPC1 as 1M SRAM, and loads U-boot image +to CPC1. The second stage will configure all the hardware and boot up to U-Boot +command line. + +The PBL image contains three parts, the first is RCW, the second is PBI commands +performs configuration registers write, the third is the 512KB u-boot image. The +PBL image is produced by tool pbl_image_tool.html. + +Build and boot steps + + +1. Producing RCW +Copy RCW of u-boot dump and paste it to tab "Tools" of the tool and choose +"RCW[0:511] U-Boot CCSR Dump" and then click button "Decode PBL", switch to tab +"Boot" and change PBI_SRC to "0b0101 - SPI 24b Addressing", change BOOT_LOC to +"0b1 - Memory Complex 1". + +2. Producing ACS File + make P4080DS_PBLSPI_config + make CROSS_COMPILE=powerpc-none-linux-gnuspe- all + xxd u-boot.bin > u-boot.xxd + +3. Producing PBI commands +Switch to tab "PBI" and paste commands below into text field, then choose +"ACS File (XXD Object Dump)", change Offset to "f8", and click "Browse" to +select the u-boot.xxd file produced in step 2, and click "Add PBI Data", after +it finished, paste "09138000 " and "091380c0 " at the end. + +Below are Commands pasted before click "Add PBI Data". + + PBI DATA | Description + - + | 0901 00200400 | CPCFI & | + | 09138000 | CPCLFC | + | 091380c0 0100 | | + - + | 09010100 | Configure | + | 09010104 fffb | CPC1 as | + | 09010f00 0800 | 1M SRAM | + | 0901 8000 | | + - + | 09000d00 | Configure | + | 09000d04 fff0 | LAW of | + | 09000d08 8113 | CPC1| + - + | 0910 | Configure | + | 0914 ff00 | Alternate | + | 0918 8100 | | + - + | 0911 8403 | Initialize | + | 09110020 2d170008 | SPI interface | + | 09110024 0018 | | + | 09110028 0018 | | + | 0911002c 0018 | | + - + | 09138000 | Flush command | + | 091380c0 | | + - + +4. Producing PBL image + 1. Switch to tab "Tools" and click "Encode PBL", after it finished copy +the encoded content to file and save as x.xxd. + 2. xxd -r x.xxd > pbl_u-boot.bin + +5. Put image to SPI flash + Put the pbl_u-boot.bin to SPI flash from offset 0. + +6. Change dip-switch + Change SW1[2] = off, then power on. -- 1.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
Hello Reinhard,
Reinhard Meyer wrote:
> Dear Heiko Schocher,
>> diff --git a/arch/arm/cpu/sa1100/start.S b/arch/arm/cpu/sa1100/start.S
>> index ace0c07..91cdd72 100644
>> --- a/arch/arm/cpu/sa1100/start.S
>> +++ b/arch/arm/cpu/sa1100/start.S
>> @@ -152,6 +152,7 @@ reset:
>> /* Set stackpointer in internal RAM to call board_init_f */
>> call_board_init_f:
>> ldrsp, =(CONFIG_SYS_INIT_SP_ADDR)
>> +bicsp, sp, #7 /* 8-byte alignment for ABI compliance */
>> ldrr0,=0x
>> blboard_init_f
>>
>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>> index 1fd5f83..96c0e30 100644
>> --- a/arch/arm/lib/board.c
>> +++ b/arch/arm/lib/board.c
>> @@ -276,7 +276,7 @@ void board_init_f (ulong bootflag)
>> ulong addr, addr_sp;
>>
>> /* Pointer is writable since we allocated a register for it */
>> -gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
>> +gd = (gd_t *) ((CONFIG_SYS_INIT_SP_ADDR)& ~0x07);
>> /* compiler optimization barrier needed for GCC>= 3.4 */
>> __asm__ __volatile__("": : :"memory");
>>
>
> Is bootflag ever used? If not, why not change the parameter to
No.
> give the gd address to board_init_f?
>
> ld r0, sp (whatever the exact assembly syntax for that would be)
>
> void board_init_f (gd_t *gd_addr)
> ...
> gd = gd_addr;
I thought this too, but in arch/powerpc/lib/board.c it is used as bootflag,
so I didn;t want to touch this ... but looking in arch/*/lib/board.c
this first parameter is not always used as bootflag ... so I think
that would be good ... opinions?
> One further thought, why not init the reserved register in assembly and
> remove the gd relevant code in C? But that bears some risk if the register
> is changed and the assembly is forgotten to adapt..
No, I think this is to risky ...
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] [PATCH 1/2] PBL: add support for boot from SPI flash.
PBL: SPI flash used as RCW and PBI source, CPC1 used as 1M SRAM
where PBL will copy whole U-BOOT image to, U-boot can boot from CPC1
after PBL completes RCW and PBI phases.
To produces the U-boot image which can used by PBL, pbl_image_tool.html
is a necessary tool.
Signed-off-by: Chunhe Lan
Signed-off-by: Mingkai Hu
Signed-off-by: Shaohui Xie
---
arch/powerpc/cpu/mpc85xx/cpu_init.c | 25 +
board/freescale/corenet_ds/config.mk | 6 ++
board/freescale/corenet_ds/tlb.c |9 +
boards.cfg |1 +
include/configs/corenet_ds.h | 31 +--
5 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 27236a0..b5a90fb 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -136,6 +136,26 @@ static void enable_cpc(void)
cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
+#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L3_ADDR)
+ if (in_be32(&cpc->cpccsr0) & CPC_CSR0_CE) {
+ /* find and disable LAW of SRAM */
+ struct law_entry law = find_law(CONFIG_SYS_INIT_L3_ADDR);
+
+ if (law.index == -1) {
+ printf("\nFatal error happened\n");
+ return;
+ } else
+ disable_law(law.index);
+
+#ifdef CONFIG_SYS_P4080_ERRATUM_CPC4
+ /* Disable workaround - only needed in all SRAM mode */
+ clrbits_be32(&cpc->cpchdbcr0, CPC_HDBCR0_CDQ_SPEC_DIS);
+#endif
+ out_be32(&cpc->cpccsr0, 0);
+ out_be32(&cpc->cpcsrcr0, 0);
+ }
+#endif
+
for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) {
u32 cpccfg0 = in_be32(&cpc->cpccfg0);
size += CPC_CFG0_SZ_K(cpccfg0);
@@ -155,6 +175,11 @@ void invalidate_cpc(void)
cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) {
+#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L3_ADDR)
+ /* skip CPC1 when it used as all SRAM */
+ if (i == 0)
+ continue;
+#endif
/* Flash invalidate the CPC and clear all the locks */
out_be32(&cpc->cpccsr0, CPC_CSR0_FI | CPC_CSR0_LFC);
while (in_be32(&cpc->cpccsr0) & (CPC_CSR0_FI | CPC_CSR0_LFC))
diff --git a/board/freescale/corenet_ds/config.mk
b/board/freescale/corenet_ds/config.mk
index 15bbf20..ece4578 100644
--- a/board/freescale/corenet_ds/config.mk
+++ b/board/freescale/corenet_ds/config.mk
@@ -24,4 +24,10 @@
# P4080DS board
#
+ifeq ($(CONFIG_PBLSPI), y)
+RESET_VECTOR_ADDRESS = 0xfffc
+endif
+
+ifndef RESET_VECTOR_ADDRESS
RESET_VECTOR_ADDRESS = 0xeffc
+endif
diff --git a/board/freescale/corenet_ds/tlb.c b/board/freescale/corenet_ds/tlb.c
index 1ae0416..08f91a7 100644
--- a/board/freescale/corenet_ds/tlb.c
+++ b/board/freescale/corenet_ds/tlb.c
@@ -51,9 +51,18 @@ struct fsl_e_tlb_entry tlb_table[] = {
/* TLB 1 */
/* *I*** - Covers boot page */
+#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L3_ADDR)
+ /* *I*G - L3SRAM. When L3 is used as 1M SRAM, the address of the
+* SRAM is at 0xfff0, it covered the 0xf000.
+* */
+ SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L3_ADDR, CONFIG_SYS_INIT_L3_ADDR,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 0, BOOKE_PAGESZ_1M, 1),
+#else
SET_TLB_ENTRY(1, 0xf000, 0xf000,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 0, BOOKE_PAGESZ_4K, 1),
+#endif
/* *I*G* - CCSRBAR */
SET_TLB_ENTRY(1, CONFIG_SYS_CCSRBAR, CONFIG_SYS_CCSRBAR_PHYS,
diff --git a/boards.cfg b/boards.cfg
index 6c2a667..562721f 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -195,6 +195,7 @@ P1022DS powerpc mpc85xx p1022ds
freescale
P2020DSpowerpc mpc85xx p2020ds freescale
stxgp3 powerpc mpc85xx stxgp3 stx
P4080DSpowerpc mpc85xx corenet_ds freescale
+P4080DS_PBLSPI powerpc mpc85xx corenet_ds freescale -
P4080DS:PBLSPI,SYS_TEXT_BASE=0xFFF8
sbc8540powerpc mpc85xx sbc8560 -
- SBC8540
sbc8548powerpc mpc85xx sbc8548 -
- sbc8548
sbc8560powerpc mpc85xx sbc8560 -
- sbc8560
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index 2ac59e5..df03448 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -28,6 +28,11 @@
#include "../board/freescale/common/ics307_clk.h"
+#ifdef CONFIG_PB
Re: [U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
Le 12/11/2010 07:53, Heiko Schocher a écrit : > suggested from Daniel Hobi > > Tested on following boards: > arm1136: qong > armv7: omap3_beagle > arm926ejs: magnesium, tx25 > > Signed-off-by: Heiko Schocher > cc: Daniel Hobi > cc: Albert ARIBAUD I'm a bit uneasy about having the symbol unaligned and the aligning done by the code (and in different places): > ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) > + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ > - gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR); > + gd = (gd_t *) ((CONFIG_SYS_INIT_SP_ADDR)& ~0x07); > There is always a risk that overhauls of the code, or new uses elsewhere in the code, forget about the alignment constraint and use the symbol straight away, which could cause all sorts of hard to debug issues. Could we not align the symbol value itself so that the code simply uses the symbol? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
