[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Anders Larsen]

"Patrick .." <oc3an@gmx.net> schreibt:
>I applied your patches to the 1.1.3 version of U-Boot - they all apply
>fine
>except for the main csb637 patch, which complains about patching a
>Makefile
>and MAKEALL.

Hi,
that's probably due to other boards having been added in the
meantime.

>This is not the main problem however,
>
>In the AT91RM9200 initialisation code, PMC_MCKR is written incorrectly. 
>This register *MUST* be written in two separate steps (see the errata
>sheet
>for the AT91RM9200 for more details).

You're referring to Errata #28, right?
Reading the text it seems you're right; however, this is not
special to the CSB637 board - the code in question
(cpu/arm920t/at91rm9200/lowlevel_init.S) was _not_ touched by
my patch.

>In my case i write 0x201, followed by 0x202.

OK, please provide a patch to lowlevel_init.S then.

>Also, it is safe to use a divisor of 3 for the Master Clock, this gives
>61.44MHz from a core of 184.32Mhz which is fine for the CSB637 (master
>clock
>limit is 80MHz), users should see a decent improvement in performance by
>doing this as it will increase the SDRAM bandwidth by a substantial
>amount.

Well, I got the clock values from linux 2.6.12 board-csb637.c;
does Linux still boot correctly with your change?

Cheers
 Anders

CC'ed to the list, since this is relevant to ALL at91rm9200 users

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Martin Krause]

Hi,

Anders Larsen wrote on :
> "Patrick .." <oc3an@gmx.net> schreibt:
> > Also, it is safe to use a divisor of 3 for the Master Clock, this
> > gives 
> > 61.44MHz from a core of 184.32Mhz which is fine for the CSB637
> > (master clock limit is 80MHz), users should see a decent
> > improvement in performance by doing this as it will increase the
> > SDRAM bandwidth by a substantial amount.
> 
> Well, I got the clock values from linux 2.6.12 board-csb637.c;
> does Linux still boot correctly with your change?

I already posted this on the list, but a little reminder won't hurt :)

A clock rate > 180 MHz could be problematic. According errata 42 
(AC Characteristics: PLL Frequency Limitation), in AT91RM9200 errata 
sheet (doc6015) the PLL is limited to 180 MHz. We already had problems 
with this bug (with about 10%-15% of the CPUs). After configuring the
PLL for 179 MHz no errors occour any mor (before we used 207 MHz).

Regards,
Martin

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Steven Scholz]

Martin,

> A clock rate > 180 MHz could be problematic. According errata 42 
> (AC Characteristics: PLL Frequency Limitation), in AT91RM9200 errata 
> sheet (doc6015) the PLL is limited to 180 MHz. We already had problems 
> with this bug (with about 10%-15% of the CPUs). After configuring the
> PLL for 179 MHz no errors occour any mor (before we used 207 MHz).

Which errors and problems did you encounter?

--
Steven

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Anders Larsen]

"Martin Krause" <Martin.Krause@tqs.de> schreibt:
>I already posted this on the list, but a little reminder won't hurt :)
>
>A clock rate > 180 MHz could be problematic. According errata 42 
>(AC Characteristics: PLL Frequency Limitation), in AT91RM9200 errata 
>sheet (doc6015) the PLL is limited to 180 MHz. We already had problems 
>with this bug (with about 10%-15% of the CPUs). After configuring the
>PLL for 179 MHz no errors occour any mor (before we used 207 MHz).

Hi,

207 MHz is way beyond the limit - the 184 MHz of the CSB637 was
specified by Cogent, so /they/ are responsible for selecting chips
that can handle that frequency  :-)

Cheers
 Anders

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Martin Krause]

Hi Steven,

Steven Scholz wrote on :
> Martin,
> 
> > A clock rate > 180 MHz could be problematic. According errata 42
> > (AC Characteristics: PLL Frequency Limitation), in AT91RM9200 errata
> > sheet (doc6015) the PLL is limited to 180 MHz. We already had
> > problems with this bug (with about 10%-15% of the CPUs). After
> > configuring the PLL for 179 MHz no errors occour any mor (before we
> > used 207 MHz). 
> 
> Which errors and problems did you encounter?

The Linux kernel (2.4.27 linuxarm tree from Denx) did not run stable on
the affected boards. We see sporadic failures and core dumps.

Regards,
Martin

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Steven Scholz]

Patrick,

>>This is not the main problem however,
>>
>>In the AT91RM9200 initialisation code, PMC_MCKR is written incorrectly. 
>>This register *MUST* be written in two separate steps (see the errata
>>sheet
>>for the AT91RM9200 for more details).
>>In my case i write 0x201, followed by 0x202.

How did you do that?
Do you wait some time between the first and the second write?

--
Steven

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Steven Scholz]

Patrick,

 .. wrote:
>>--- Urspr?ngliche Nachricht ---
>>Von: Steven Scholz <steven.scholz@imc-berlin.de>
>>An: Anders Larsen <alarsen@rea.de>
>>Kopie: "Patrick .." <oc3an@gmx.net>, u-boot-users at lists.sourceforge.net
>>Betreff: Re: [U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big
>>bug..)
>>Datum: Wed, 24 Aug 2005 11:01:30 +0200

No need to sent the above text!

[snip]

>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>_______________________________________________
>>U-Boot-Users mailing list
>>U-Boot-Users at lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/u-boot-users
>>

No need to sent the above text!

[snip]

> No need to wait between the writes.

Due to all the rubbish text above I forget the question... ;-)

> This fix is quite simple to implement.  in lowlevel_init.S edit the values
> for MCKR (as shown below).  You also need to modify the length of the
> assembly loop some lines above which iterates through this list (also shown
> below).  This length should really be calculated (but it works).

Thanks a million.

> Then define MCKR_VAL0 as the first value to be written and MCKR_VAL1 as the
> second in the includes/common/csb637.h file.
> 
> Hope this helps,

Sure. Maybe you could send unified diffs next time as they're much
easier to read.

Thanks anyway!

> 	/* memory control configuration */
> 	/* this isn't very elegant, but	 what the heck */
> 	ldr	r0, =SMRDATA
> 	ldr	r1, _MTEXT_BASE
> 	sub	r0, r0, r1
> 	add	r2, r0, #88  // Edited by Patrick

Aah. I forgot that. Cause I thought the original autjort would never do
a bad thing like hardcoding such a loop count ... ;-)

--
Steven

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Anders Larsen]

Steven Scholz <steven.scholz@imc-berlin.de> schreibt:
>> Then define MCKR_VAL0 as the first value to be written and MCKR_VAL1 as
>the
>> second in the includes/common/csb637.h file.
>> 
>> Hope this helps,
>
>Sure. Maybe you could send unified diffs next time as they're much
>easier to read.

And please bear in mind that an increasing number of
boards use this code and must be modified accordingly.

Cheers
 Anders

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Anders Larsen]

"Patrick .." <oc3an@gmx.net> schreibt:
>U-Boot hangs when i don't write the register in two steps.  Errata #82 is
>the right one - it's quite tricky to interpret correctly.  I ended up with
>the sequence i used from reading this errata and a fair bit of trial &
>error.

Strange - the original code runs on three different boards here
without problems (and others are using it, too).
>
>Error: unrecognized/unsupported machine ID (r1 = 0x00000106).
>Available machine support:
>ID (hex)        NAME
>00000288        Cogent CSB637

I've long since fixed that - see the refreshed patch I sent a
few minutes ago.

Cheers
 Anders

P.S.:
- Please keep the list CC'ed
- Please do not top post/full quote

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Anders Larsen]

"Patrick .." <oc3an@gmx.net> schreibt:
>On another note, is there any reason you chose a master clock divisor of 4
>instead of 3 for the CSB637? 

Hi,

like I already said:
"I got the clock values from linux 2.6.12 board-csb637.c"
I didn't choose them myself.

>I have looked over the data sheets for all relevant devices (SDRAM,
>StrataFlash) and they definitely support at least 60Mhz (what divider 3
>gives).

Feel free to change it, then (but please make sure to update
arch/arm/mach-at91rm9200/board-csb637.c accordingly, otherwise
at least the serial interfaces will not work).

Cheers
 Anders

P.S.: PLEASE keep the list CC'ed.

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Anders Larsen]

"Patrick .." <oc3an@gmx.net> schreibt:
>My configuration is this:
>bootargs=mem=32M console=ttyS0,38400

You don't have to use the MEM=32M option - U-Boot will pass
the actual memory configuration to the kernel anyway.

>Linux version 2.6.13-rc2-csb (patrick at gt-server) (gcc version 3.4.4) #1
>Wed 
>initrd (0x10200040 - 0x1020059c) extends beyond physical memory -
>disabling
>initrd
>
>Is there a simple solution to this problem? does the ram disk need to be
>maually decompressed first?

Unfortunately yes - the 2.6 kernel is unable to handle an initrd
in flash (this is a FAQ, by the way).

Cheers
 Anders

[U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Steven Scholz]

Anders,

>>Is there a simple solution to this problem? does the ram disk need to be
>>maually decompressed first?
> 
> Unfortunately yes - the 2.6 kernel is unable to handle an initrd
> in flash (this is a FAQ, by the way).

So where is the FGA(*) then?

--
Steven

(*) FGA: Frequently Given Answer