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

[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] Re: [U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Patrick ..]

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

No proglems, list is CC'd!! :)

Linux still appears to boot fine right up until it says.  

RAMDISK: Couldn't find valid RAM disk image starting at 0.
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(1,0)

which is expected.

You are correct, the /arch/arm/mach-at91rm9200/board-csb637.c file had to be
edited in order to work with the new master clock.  I believe there is a way
of detecting clock speeds which i will look up later.  This would be better
than them being hard-coded.

This is probably a bit off topic for this list, but does anyone know a way
of making ram disk images that doesn't require root access (which i don't
have on the box i am working on)

I am aware of the following method:

dd if=/dev/zero of=rootfs.img bs=1k count=400
mkfs.ext2 -c rootfs.img
mount -o loop rootfs.img /mntpoint
cp -av rootfs/* /mntpoint
umount /mntpoint
gzip -v9 -c rootfs.img >rootfs.gz

However mount requires root access :(

-Patrick

-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

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

[Patrick ..]

>>>This is probably a bit off topic for this list, but does anyone know a
>>
>>way
>>
>>>of making ram disk images that doesn't require root access (which i
>>
>>don't
>>
>>>have on the box i am working on)
>>
>>genext2fs ?
>>
>>--
>>Steven
>
>
Thanks, i'll check it out of cvs and have a look.

Aside from this I made an empty ram disk simply to see if the kernel would
mount it.

My configuration is this:
bootargs=mem=32M console=ttyS0,38400
Flash Address 10100000 contains linux kernel image
Flash Address 10200000 contains compressed ram disk

Unfortunately i ran into this error after executing bootm 10100000 10200000:

Linux version 2.6.13-rc2-csb (patrick at gt-server) (gcc version 3.4.4) #1 Wed 
Aug 24 20:29:20 EST 2005
CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T)
Machine: Cogent CSB637
initrd (0x10200040 - 0x1020059c) extends beyond physical memory - disabling
initrd

which looks like the ram disk isn't being decompressed into ram from flash.

Is there a simple solution to this problem? does the ram disk need to be
maually decompressed first?

Thanks,

-Patrick

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse f?r Mail, Message, More +++

[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

[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] CSB637 support

[Anders Larsen]

Wolfgang Denk <wd@denx.de> schreibt:
>> about csb637 support, but i am unable to find the actual patch.
>
>It was posted by Anders Larsen in 4 parts on 2005-04-29

Hi,

I've refreshed the patch(es) against current top-of-git.
Do you want me to re-send them?

Cheers
 Anders

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

[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] Re: [U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)

[Patrick ..]

> --- 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
> 
> 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
> 
> 
> 
> -------------------------------------------------------
> 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 wait between the writes.

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

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,

-Patrick

SMRDATA:
	.word MC_PUIA
	.word MC_PUIA_VAL
	.word MC_PUP
	.word MC_PUP_VAL
	.word MC_PUER
	.word MC_PUER_VAL
	.word MC_ASR
	.word MC_ASR_VAL
	.word MC_AASR
	.word MC_AASR_VAL
	.word EBI_CFGR
	.word EBI_CFGR_VAL
	.word SMC2_CSR
	.word SMC2_CSR_VAL
	.word PLLAR
	.word PLLAR_VAL
	.word PLLBR
	.word PLLBR_VAL
	.word MCKR          // Edited by Patrick
	.word MCKR_VAL0     // Edited by Patrick
	.word MCKR          // Edited by Patrick
	.word MCKR_VAL1     // Edited by Patrick
	/* SMRDATA is 88 bytes long */
	/* here there's a delay of 100 */



	/* 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

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse f?r Mail, Message, More +++

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