[U-Boot] [STATUS] v2009.08-rc3 is out

[U-Boot] [STATUS] v2009.08-rc3 is out

[Wolfgang Denk]

Hi everybody...

v2009.08-rc3 has just been released.

Please help testing, and submit  fixes  to  the  remaining  problems.
Things still missing should be submitted ASAP.


* Many boards now throw the (expected)

  #warning Ethernet driver is deprecated. Please update to use CONFIG_NET_MULTI

  messages.

* ARM, MIPS and PowerPC: mostly compile clean; there are a few
  issues (mostly harmless) - responsibles have been notified

Comments and fixes welcome.

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: wd at denx.de
'What shall we do?' said Twoflower.  'Panic?'  said  Rincewind  hope-
fully. He always held that panic was the best means of survival; back
in  the  olden days, his theory went, people faced with hungry sabre-
toothed tigers could be divided very simply in those who panicked and
those who stood there saying 'What a magnificent  brute!'  or  'Here,
pussy.'                      - Terry Pratchett, _The Light Fantastic_

[U-Boot] [STATUS] v2009.08-rc3 is out

[Mike Frysinger]

On Saturday 22 August 2009 17:41:16 Wolfgang Denk 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 ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090822/ac888da6/attachment.pgp 

[U-Boot] [STATUS] v2009.08-rc3 is out

[Wolfgang Denk]

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

-- 
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: wd at denx.de
What is tolerance? -- it is the consequence of humanity. We  are  all
formed  of frailty and error; let us pardon reciprocally each other's
folly -- that is the first law of nature.                  - Voltaire

[U-Boot] [STATUS] v2009.08-rc3 is out

[Jens Scharsig]

Am 22.08.2009 23:41, schrieb Wolfgang Denk:
> Hi everybody...
> 
> v2009.08-rc3 has just been released.
> 
> Please help testing, and submit  fixes  to  the  remaining  problems.
> 
Hello,

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).

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

Regards 

Jens Scharsig

[U-Boot] [STATUS] v2009.08-rc3 is out

[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

-- 
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: wd at denx.de
Yes, it is written.  Good shall always destroy evil.
	-- Sirah the Yang, "The Omega Glory", stardate unknown

[U-Boot] [STATUS] v2009.08-rc3 is out

[Jens Scharsig]

Dear Wolfgang Denk:
> 
>> 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?

I found out, that the board hangs if there u-boot access to non SDRAM
memory like NAND or frambuffer. I try to found the reason, but the
compiled code (option -0s) is hard to debug. So I compile the Code
without -Os and the board runs (also arm ELDK).
The question goes to the gcc guru's, what is the difference? The
assembly code is as expected completly different.

regards

Jens Scharsig

[U-Boot] [STATUS] v2009.08-rc3 is out

[Jens Scharsig]

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

[U-Boot] [STATUS] v2009.08-rc3 is out

[Jens Scharsig]

Am 22.12.2010 10:29, schrieb Jens Scharsig:
> 
> In fact, the 4.2.2 code does access byte wise to soc (AT91) control registers, but should write data as an single word.
> 
Addendum:

The results: We receive an access violation. The cause is a faulty initialized chip select.
 
regards

Jens Scharsig

[U-Boot] [STATUS] v2009.08-rc3 is out

[Reinhard Meyer]

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

[U-Boot] [STATUS] v2009.08-rc3 is out

[Jens Scharsig]

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

You are right, there are some __attribute__ ((packed)) statements. I don't remember why.

I've remove this statments and the EDLK compiled binary runs.

I will send a Patch in next hours.


regards

Jens

[U-Boot] [STATUS] v2009.08-rc3 is out

[Jens Scharsig]

Sorry I'm on fault thread

I meam V2010.12-rc3

regards Jens Scharsig