Dear Mike Frysinger,

In message 200908221908.17384.vapier@gentoo.org you wrote:

...

v2009.08-rc3 has just been released.

maybe you just didnt push updated master branch ? the 2009.08-rc3 tag is a commit ahead of master ...

Sorry, pulled into wrong (local only) branch. Should be fixed now.

Best regards,

Wolfgang Denk

Dear Jens Scharsig,

In message 4D10BB60.9020800@scharsoft.de you wrote:

I have tested the EB+CPUx9K2 Board. It can be compiled with gcc 4.2.2 (ELDK) and gcc 4.5.1 (buildroot 2010.11).

Thanks for testing.

But it runs only , if I use the newer 4.5.1 toolchain. I think, there are toolchain issues with relocation

Can you please try and investigate the issue?

Best regards,

Wolfgang Denk

Dear Wolfgang Denk,

Can you please try and investigate the issue?

I have parsed the code again and again. In result I found the problem in generated code.

By an Examble:

Source:

/* Setup Smart Media, first enable the address range of CS3 */ writel(readl(&mc->ebi.csa) | AT91_EBI_CSA_CS3A, &mc->ebi.csa);

/* RWH = 1 | RWS = 0 | TDF = 1 | NWS = 3 */ csr = AT91_SMC_CSR_RWHOLD(1) | AT91_SMC_CSR_TDF(1) | AT91_SMC_CSR_NWS(3) | AT91_SMC_CSR_ACSS_STANDARD | AT91_SMC_CSR_DBW_8 | AT91_SMC_CSR_WSEN; writel(csr, &mc->smc.csr[3]);

4.2.2 (ELDK) generated code

0x23fdc698 <nand_hw_init>: mvn r2, #159 ; 0x9f 0x23fdc698 <nand_hw_init+4>: ldr r3, [r2] 0x23fdc69c <nand_hw_init+8>: orr r3, r3, #8 0x23fdc6a0 <nand_hw_init+12>: str r3, [r2] 0x23fdc6a4 <nand_hw_init+16>: mvn r3, #0 0x23fdc6a8 <nand_hw_init+20>: ldrb r2, [r3, #-131] ; 0x83 0x23fdc6ac <nand_hw_init+24>: mvn r2, #124 ; 0x7c 0x23fdc6b0 <nand_hw_init+28>: strb r2, [r3, #-131] ; 0x83 0x23fdc6b4 <nand_hw_init+32>: ldrb r2, [r3, #-130] ; 0x82 0x23fdc6b8 <nand_hw_init+36>: mov r2, #65 ; 0x41 0x23fdc6bc <nand_hw_init+40>: strb r2, [r3, #-130] ; 0x82 0x23fdc6c0 <nand_hw_init+44>: ldrb r2, [r3, #-129] ; 0x81 0x23fdc6c4 <nand_hw_init+48>: mov r2, #0 0x23fdc6c8 <nand_hw_init+52>: strb r2, [r3, #-129] ; 0x81 0x23fdc6cc <nand_hw_init+56>: mov r0, #16 0x23fdc6d0 <nand_hw_init+60>: ldrb r2, [r3, #-128] ; 0x80 0x23fdc6d4 <nand_hw_init+64>: strb r0, [r3, #-128] ; 0x80

4.5.1 (buildroot) generated code

0x23fdc308 <nand_hw_init>: mvn r3, #159 ; 0x9f 0x23fdc30c <nand_hw_init+4>: ldr r2, [r3] 0x23fdc310 <nand_hw_init+8>: orr r2, r2, #8 0x23fdc314 <nand_hw_init+12>: str r2, [r3] 0x23fdc318 <nand_hw_init+16>: ldr r2, [pc, #76] ; 0x23fdc36c <nand_hw_init+100> 0x23fdc31c <nand_hw_init+20>: add r3, r3, #28 0x23fdc320 <nand_hw_init+24>: str r2, [r3]

In fact, the 4.2.2 code does access byte wise to soc (AT91) control registers, but should write data as an single word.

But I have no idea to prevent this.

Best regards

Jens Scharsig

Dear Jens Scharsig,

I have parsed the code again and again. In result I found the problem in generated code.

In fact, the 4.2.2 code does access byte wise to soc (AT91) control registers, but should write data as an single word.

But I have no idea to prevent this.

By chance, the structure declaration has a packed attribute? Or other quirks which might make the compiler think the field _might be_ unaligned?

Best Regards, Reinhard

Sorry I'm on fault thread

I meam V2010.12-rc3

regards Jens Scharsig