Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Dell Query]

[-- Attachment #1: Type: text/plain, Size: 3859 bytes --]

Hi,

I am creating a simple program which will try to read the board ID of the PPC440EPx thru BCSR but when I load it, it gives me "Data Read PLB Error". 

I am not sure if I missed out something.

I would really appreciate it if somebody could help me on this.

I have posted the source code below, as well as the complete message.

Many thanks!

SOURCE CODE:
----------------------------------------------------------------------
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/ioport.h>
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
#include <asm/ocp.h>
#include <asm/ibm4xx.h>

MODULE_LICENSE("GPL");

#define BCSR_BASE   0xC0002000
#define BCSR0       0
#define BCSR1       1
#define BCSR2       2

#define USER_LED    0x2
#define SIZE_TO_MAP 10

#define LED_ON      0

uint __iomem *bcsrbase = NULL;

static int __init initFunction(void) {
   uint tmp;
   printk("<1> Calling init function.\n");
   printk("<1> bcsrbase value %p...\n",bcsrbase);
   printk("<1> Remapping %x...\n",BCSR_BASE);
   /*map*/
   bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
   printk("<1> bcsrbase new value %p...\n",bcsrbase);
   /*read value*/
   /*based on PPC440EPx document, BCSR0 is BoardID*/
   tmp = in_be32(bcsrbase + BCSR0 /* BCSR0 */);
   printk("<1> BCSR0 %x...\n",tmp);
   /*try to output something*/
   //out_be32(bcsrbase , /*LED_ON*/);
   return 0;
}
static void __exit cleanupFunction(void) {
   printk("<1> Calling cleanup function.\n");
   /*unmap*/
   iounmap(bcsrbase);
}

module_init(initFunction);
module_exit(cleanupFunction);
----------------------------------------------------------------------
ERROR MESSAGE:
----------------------------------------------------------------------
/mnt/flash_fs/var/ftp # insmod bcsr.ko
 Calling init function.
 bcsrbase value 00000000...
 Remapping c0002000...
 bcsrbase new value d50fe000...
Machine check in kernel mode.
Data Read PLB Error
OPB to PLB3: BSTAT= 0x00000000
PLB3 to PLB4: BEAR=0xffffffffffff7fff BESR0=0x00000000 BESR1=0x00000000
PLB4 to PLB3: BEAR=0xfd7fffffffffffff BESR0=0x00000000 BESR1=0x00000000
PLB3 to OPB: BEAR=0xffffffff BESR0=0x00000000 BESR1=0x00000000
PLB3 arbiter: BEAR=0xbfffffef ACR=0x90000000 BESR=0x00000000
PLB4 to OPB1: BEAR=0x0000000efffbfffb BESR0=0x00000000 BESR1=0x00000000
PLB40 Arbiter: BEAR=0x00000000c0002000 ACR=0xde000000 BESR0=0x0f000000
PLB41 Arbiter: BEAR=0xfffffffffffffffa ACR=0xdf000000 BESR0=0x00000000
POB0: BEAR=0xc27e3194ffffffff BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000000 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: D50FC07C LR: D50FC070 CTR: 00000000
REGS: c02bcf50 TRAP: 0202   Not tainted  (2.6.21-rc4)
MSR: 00029000 <EE,ME>  CR: 24004022  XER: 00000000
TASK = c05fe490[115] 'insmod' THREAD: cdc6c000
GPR00: D50FC070 CDC6DE80 C05FE490 00000023 0A00C100 00000001 00000000 00000031
GPR08: 00000000 D50FE000 000017E4 C0290000 04004022 1016F458 00000000 00000000
GPR16: 00000000 00000000 00000030 00000030 00000124 D51132BC 00000000 C0035E2C
GPR24: 00000022 D5108000 00000022 D50F7500 CF68A21C D50F0000 CF68A000 C0279CEC
NIP [D50FC07C] initFunction+0x7c/0x128 [bcsr]
LR [D50FC070] initFunction+0x70/0x128 [bcsr]
Call Trace:
[CDC6DE80] [D50FC070] initFunction+0x70/0x128 [bcsr] (unreliable)
[CDC6DEA0] [C003731C] sys_init_module+0xe4/0x1458
[CDC6DF40] [C0001AC4] ret_from_syscall+0x0/0x3c
Instruction dump:
60842000 38600000 48000065 7c601b78 3c60d50f 7c040378 386370e8 901d76a0
4800003d 813d76a0 7c0004ac 80890000 <0c040000> 4c00012c 3c60d50f 38637108
Bus error
----------------------------------------------------------------------

       
---------------------------------
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.

[-- Attachment #2: Type: text/html, Size: 4726 bytes --]

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Josh Boyer]

On Tue, 27 Nov 2007 02:47:45 -0800 (PST)
Dell Query <dell.query@yahoo.com> wrote:

> Hi,
> 
> I am creating a simple program which will try to read the board ID of the PPC440EPx thru BCSR but when I load it, it gives me "Data Read PLB Error". 
> 
> I am not sure if I missed out something.
> 
> I would really appreciate it if somebody could help me on this.
> 
> I have posted the source code below, as well as the complete message.
> 
> Many thanks!
> 
> SOURCE CODE:
> ----------------------------------------------------------------------
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/ioport.h>
> #include <linux/delay.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> #include <linux/platform_device.h>
> #include <asm/irq.h>
> #include <asm/io.h>
> #include <linux/i2c.h>
> #include <linux/i2c-id.h>
> #include <asm/ocp.h>
> #include <asm/ibm4xx.h>
> 
> MODULE_LICENSE("GPL");
> 
> #define BCSR_BASE   0xC0002000

This is wrong.  It's 0x1C0002000.

> #define BCSR0       0
> #define BCSR1       1
> #define BCSR2       2
> 
> #define USER_LED    0x2
> #define SIZE_TO_MAP 10
> 
> #define LED_ON      0
> 
> uint __iomem *bcsrbase = NULL;
> 
> static int __init initFunction(void) {
>    uint tmp;
>    printk("<1> Calling init function.\n");
>    printk("<1> bcsrbase value %p...\n",bcsrbase);
>    printk("<1> Remapping %x...\n",BCSR_BASE);
>    /*map*/
>    bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);

Since this seems to be arch/ppc, use ioremap64.

josh

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Dell Query]

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

Oh is it 0x1C0002000?

Where can I get the document? What I have is 0xC0002000 from ep440xc_um_amcc.pdf file that I get from the accompanying PPC440EPx resource CD.

Thanks!

dell

Josh Boyer <jwboyer@gmail.com> wrote: On Tue, 27 Nov 2007 02:47:45 -0800 (PST)
Dell Query  wrote:

> Hi,
> 
> I am creating a simple program which will try to read the board ID of the PPC440EPx thru BCSR but when I load it, it gives me "Data Read PLB Error". 
> 
> I am not sure if I missed out something.
> 
> I would really appreciate it if somebody could help me on this.
> 
> I have posted the source code below, as well as the complete message.
> 
> Many thanks!
> 
> SOURCE CODE:
> ----------------------------------------------------------------------
> #include 

> #include 

> #include 

> #include 

> #include 

> #include 

> #include 

> #include 
> #include 
> #include 

> #include 

> #include 
> #include 
> 
> MODULE_LICENSE("GPL");
> 
> #define BCSR_BASE   0xC0002000

This is wrong.  It's 0x1C0002000.

> #define BCSR0       0
> #define BCSR1       1
> #define BCSR2       2
> 
> #define USER_LED    0x2
> #define SIZE_TO_MAP 10
> 
> #define LED_ON      0
> 
> uint __iomem *bcsrbase = NULL;
> 
> static int __init initFunction(void) {
>    uint tmp;
>    printk("<1> Calling init function.\n");
>    printk("<1> bcsrbase value %p...\n",bcsrbase);
>    printk("<1> Remapping %x...\n",BCSR_BASE);
>    /*map*/
>    bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);

Since this seems to be arch/ppc, use ioremap64.

josh
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

[-- Attachment #2: Type: text/html, Size: 2574 bytes --]

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Stefan Roese]

On Wednesday 28 November 2007, Dell Query wrote:
> Oh is it 0x1C0002000?

Just to be sure here, we are talking about the AMCC Sequoia board, right?

> Where can I get the document? What I have is 0xC0002000 from
> ep440xc_um_amcc.pdf file that I get from the accompanying PPC440EPx
> resource CD.

Please take a look at the 440EPx data sheet. It has a nice table with an 
overview of the address maps (table 1). Here you will notice that the EBC has 
multiple maps, one starting at 0x1.c000.0000 and another one at 
0x1.f000.0000. Yes, these are 36bit physical addresses. In U-Boot these are 
mapped via the TLB to 0xc000.0000 and 0xf000.0000. So in U-Boot you are able 
to access the CPLD at 0xc0000000. But in Linux you have to map the 36bit 
address to get the virtual address which you need for accessing. And using 
arch/ppc you need to call ioremap64() with this 36bit address as parameter.

Hope this helps.

Best regards,
Stefan

=====================================================================
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: office@denx.de
=====================================================================

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Dell Query]

[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]

I don't know if the document that came with the PPC440EPx Sequoia Resource CD is right. It is odd that it is entitled "Embedded Planet 440xC" and it showed in page 34:
-----------------------------------------------------------------------
Table 4-4. Memory Map
                            
 Function               Start Address   End Address    Size Chip Select
 DDR SDRAM              0x0000 0000     0x0FFF FFFF  256 MB —
 PCI Memory             0x8000 0000     0xBFFF FFFF 1024 MB —
 BCSR                   0xC000 0000     0xCFFF FFFF  256 MB CS2
 NAND FLASH Controller1 0xD000 0000     0xD00F FFFF    1 MB CS3/CS0
 NOR FLASH1             0xFC00 0000     0xFFFF FFFF   64 MB CS0/CS3
-----------------------------------------------------------------------
Anyway, I have seen Table 1. System Memory Address Map and it got EBC mapped at 0x1.c000.0000 and another one at 0x1.f000.0000.  But I didn't see any BCSR info. Correct me if I am wrong, but should it not give me BCSR details like:

Register 0 = ID         Board ID
Register 1 = 0000 0000  CPLD revision
Register 2 = 0000 xxxx  User dip-switch / LEDs
Register 3 = 0000 xxxx  Configuration dip-switch
Register 4 = 0000 0000  TMRCLK control
Register 5 = 0000 0000  PCI control, status, info
Register 6 = 0000 0000  Reset control
Register 7 = 0000 001x  Memory control
Register 8 = 0000 0000  Ethernet control
Register 9 = 0000 0001  USB control
Register 10 = 0000 0000 Performance timer (MS Byte, bits 27-24)
Register 11 = 0000 0000 Performance timer (bits 23-16)
Register 12 = 0000 0000 Performance timer (bits 15-8)
Register 13 = 0000 0000 Performance timer (LS Byte, bits 7-0)


Regards,

dell
Stefan Roese <sr@denx.de> wrote: On Wednesday 28 November 2007, Dell Query wrote:
> Oh is it 0x1C0002000?

Just to be sure here, we are talking about the AMCC Sequoia board, right?

> Where can I get the document? What I have is 0xC0002000 from
> ep440xc_um_amcc.pdf file that I get from the accompanying PPC440EPx
> resource CD.

Please take a look at the 440EPx data sheet. It has a nice table with an 
overview of the address maps (table 1). Here you will notice that the EBC has 
multiple maps, one starting at 0x1.c000.0000 and another one at 
0x1.f000.0000. Yes, these are 36bit physical addresses. In U-Boot these are 
mapped via the TLB to 0xc000.0000 and 0xf000.0000. So in U-Boot you are able 
to access the CPLD at 0xc0000000. But in Linux you have to map the 36bit 
address to get the virtual address which you need for accessing. And using 
arch/ppc you need to call ioremap64() with this 36bit address as parameter.

Hope this helps.

Best regards,
Stefan

=====================================================================
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: office@denx.de
=====================================================================


       
---------------------------------
Get easy, one-click access to your favorites.  Make Yahoo! your homepage.

[-- Attachment #2: Type: text/html, Size: 4265 bytes --]

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Stefan Roese]

On Thursday 29 November 2007, Dell Query wrote:
> I don't know if the document that came with the PPC440EPx Sequoia Resource
> CD is right. It is odd that it is entitled "Embedded Planet 440xC" and it
> showed in page 34:
> -----------------------------------------------------------------------
> Table 4-4. Memory Map
>
>  Function               Start Address   End Address    Size Chip Select
>  DDR SDRAM              0x0000 0000     0x0FFF FFFF  256 MB =E2=80=94
>  PCI Memory             0x8000 0000     0xBFFF FFFF 1024 MB =E2=80=94
>  BCSR                   0xC000 0000     0xCFFF FFFF  256 MB CS2
>  NAND FLASH Controller1 0xD000 0000     0xD00F FFFF    1 MB CS3/CS0
>  NOR FLASH1             0xFC00 0000     0xFFFF FFFF   64 MB CS0/CS3
> -----------------------------------------------------------------------
> Anyway, I have seen Table 1. System Memory Address Map and it got EBC
> mapped at 0x1.c000.0000 and another one at 0x1.f000.0000.  But I didn't s=
ee
> any BCSR info. Correct me if I am wrong, but should it not give me BCSR
> details like:

This is board specific information and not CPU specific. The CPLD with it's=
=20
BCSR is a Sequoia thing and can therefor not be listed in the 440EPx manual=
s.=20
It it located on the EBC though which is documented in the 440EPx manuals.

So if this chips select which is connected to the CPLD is mapped to=20
0xc000.0000 which is the case for Sequoia, then you will "find" these=20
registers at physical address 0x1.c000.0000. And should use ioremap64() to=
=20
get the virtual address to access this CPLD.

Best regards,
Stefan

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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: office@denx.de
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Dell Query]

[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]

I see. No wonder I couldn't get more information on BCSR. I should contact sequoia to get the proper details like the correct addresses. 

I already used ioremap64(), remapping 0x1c0002000. I got a hex value for the Board ID but could figure out what it means. So I tried the USER_LED0/USER_LED1 (base address+0x2), to see if I could turn on/off the user LEDS, but still no luck.
I think I am accessing the wrong addresses so I need to verify it with them.

Thanks!

Regards,
dell
Stefan Roese <sr@denx.de> wrote: On Thursday 29 November 2007, Dell Query wrote:
> I don't know if the document that came with the PPC440EPx Sequoia Resource
> CD is right. It is odd that it is entitled "Embedded Planet 440xC" and it
> showed in page 34:
> -----------------------------------------------------------------------
> Table 4-4. Memory Map
>
>  Function               Start Address   End Address    Size Chip Select
>  DDR SDRAM              0x0000 0000     0x0FFF FFFF  256 MB —
>  PCI Memory             0x8000 0000     0xBFFF FFFF 1024 MB —
>  BCSR                   0xC000 0000     0xCFFF FFFF  256 MB CS2
>  NAND FLASH Controller1 0xD000 0000     0xD00F FFFF    1 MB CS3/CS0
>  NOR FLASH1             0xFC00 0000     0xFFFF FFFF   64 MB CS0/CS3
> -----------------------------------------------------------------------
> Anyway, I have seen Table 1. System Memory Address Map and it got EBC
> mapped at 0x1.c000.0000 and another one at 0x1.f000.0000.  But I didn't see
> any BCSR info. Correct me if I am wrong, but should it not give me BCSR
> details like:

This is board specific information and not CPU specific. The CPLD with it's 
BCSR is a Sequoia thing and can therefor not be listed in the 440EPx manuals. 
It it located on the EBC though which is documented in the 440EPx manuals.

So if this chips select which is connected to the CPLD is mapped to 
0xc000.0000 which is the case for Sequoia, then you will "find" these 
registers at physical address 0x1.c000.0000. And should use ioremap64() to 
get the virtual address to access this CPLD.

Best regards,
Stefan

=====================================================================
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: office@denx.de
=====================================================================


       
---------------------------------
Get easy, one-click access to your favorites.  Make Yahoo! your homepage.

[-- Attachment #2: Type: text/html, Size: 2947 bytes --]

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Stefan Roese]

On Thursday 29 November 2007, Dell Query wrote:
> I see. No wonder I couldn't get more information on BCSR. I should contact
> sequoia to get the proper details like the correct addresses.
>
> I already used ioremap64(), remapping 0x1c0002000. I got a hex value for
> the Board ID but could figure out what it means. So I tried the
> USER_LED0/USER_LED1 (base address+0x2), to see if I could turn on/off the
> user LEDS, but still no luck. I think I am accessing the wrong addresses so
> I need to verify it with them.

Why do think you need the offset 0x2000? I just tested on my Sequoia under 
U-Boot and "see" the CPLD at address 0xc000.0000:

=> md.b c0000000 20
c0000000: 0f 00 c0 07 00 80 00 80 00 20 00 00 00 00 00 00    ......... ......
c0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

So you should map not 0x1.c000.2000 but 0x1.c000.0000 under Linux. Please let 
me know if this works.

Best regards,
Stefan

=====================================================================
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: office@denx.de
=====================================================================

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Dell Query]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

Hi Stefan,

1. I used the 0x1c0002000 offset because I was referring to the first reply that I received. Now, I used the address 0x1c0002000 and tried to read from it. I retrieved 0x0f01c087. May I know what does this mean? How does this data relate to Board ID?

2. Referring back to "Embedded Planet 440xC" document, I tried to activate the USER_LED0/USER_LED1 (with new address 0x1c0000000 + 0x2 offset) by setting it to 0. But didn't see the led turned on. Did some experiments and tried 0x1c0000000 without offset, sent 0, and found that USER_LED0 (CR3) and USER_LED1 (CR4) are activated! This got me confused. May I know why is this so? Could you please refer me to some documents?


Thanks for all the assistance.

Regards,
dell
Stefan Roese <sr@denx.de> wrote: On Thursday 29 November 2007, Dell Query wrote:
> I see. No wonder I couldn't get more information on BCSR. I should contact
> sequoia to get the proper details like the correct addresses.
>
> I already used ioremap64(), remapping 0x1c0002000. I got a hex value for
> the Board ID but could figure out what it means. So I tried the
> USER_LED0/USER_LED1 (base address+0x2), to see if I could turn on/off the
> user LEDS, but still no luck. I think I am accessing the wrong addresses so
> I need to verify it with them.

Why do think you need the offset 0x2000? I just tested on my Sequoia under 
U-Boot and "see" the CPLD at address 0xc000.0000:

=> md.b c0000000 20
c0000000: 0f 00 c0 07 00 80 00 80 00 20 00 00 00 00 00 00    ......... ......
c0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

So you should map not 0x1.c000.2000 but 0x1.c000.0000 under Linux. Please let 
me know if this works.

Best regards,
Stefan

=====================================================================
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: office@denx.de
=====================================================================


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

[-- Attachment #2: Type: text/html, Size: 2536 bytes --]

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Stefan Roese]

Hi Dell (???),

On Thursday 29 November 2007, Dell Query wrote:
> 1. I used the 0x1c0002000 offset because I was referring to the first reply
> that I received. Now, I used the address 0x1c0002000 and tried to read from
> it. I retrieved 0x0f01c087. May I know what does this mean? How does this
> data relate to Board ID?

Please refer to the document describing the CPLD registers. They are byte 
registers and not 32bit lword registers (see below).

> 2. Referring back to "Embedded Planet 440xC" document, I tried to activate
> the USER_LED0/USER_LED1 (with new address 0x1c0000000 + 0x2 offset) by
> setting it to 0. But didn't see the led turned on. Did some experiments and
> tried 0x1c0000000 without offset, sent 0, and found that USER_LED0 (CR3)
> and USER_LED1 (CR4) are activated! This got me confused. May I know why is
> this so? Could you please refer me to some documents?

The address of the CPLD is without this 0x2000 offset as it seems. Maybe the 
Sequoia users manual is incorrect here.

Make sure that you address these registers with the correct functions. That is 
in_8()/out_8(). Here a log from U-Boot:

=> md.l c0000000 1
c0000000: 0f00c007    ....
=> md.b c0000000 4
c0000000: 0f 00 c0 07    ....

By writing 0x00 to offset 0x02 (LED control) I am able to set the user led's. 
This should work in Linux the same way:

=> mw.b c0000002 00

Best regards,
Stefan

=====================================================================
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: office@denx.de
=====================================================================

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Dell Query]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

Hi Stefan,

I finally got the new pdf files from other Resource CDs and used 0xc000000 address, without 0x2000 offset.

It works! Thanks a lot for the help.

But may I know why in Linux it is mapped to 0x1c000000, wherein the doc stated 0xc000000?

Thanks a lot!

Stefan Roese <sr@denx.de> wrote: Hi Dell (???),

On Thursday 29 November 2007, Dell Query wrote:
> 1. I used the 0x1c0002000 offset because I was referring to the first reply
> that I received. Now, I used the address 0x1c0002000 and tried to read from
> it. I retrieved 0x0f01c087. May I know what does this mean? How does this
> data relate to Board ID?

Please refer to the document describing the CPLD registers. They are byte 
registers and not 32bit lword registers (see below).

> 2. Referring back to "Embedded Planet 440xC" document, I tried to activate
> the USER_LED0/USER_LED1 (with new address 0x1c0000000 + 0x2 offset) by
> setting it to 0. But didn't see the led turned on. Did some experiments and
> tried 0x1c0000000 without offset, sent 0, and found that USER_LED0 (CR3)
> and USER_LED1 (CR4) are activated! This got me confused. May I know why is
> this so? Could you please refer me to some documents?

The address of the CPLD is without this 0x2000 offset as it seems. Maybe the 
Sequoia users manual is incorrect here.

Make sure that you address these registers with the correct functions. That is 
in_8()/out_8(). Here a log from U-Boot:

=> md.l c0000000 1
c0000000: 0f00c007    ....
=> md.b c0000000 4
c0000000: 0f 00 c0 07    ....

By writing 0x00 to offset 0x02 (LED control) I am able to set the user led's. 
This should work in Linux the same way:

=> mw.b c0000002 00

Best regards,
Stefan

=====================================================================
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: office@denx.de
=====================================================================


       
---------------------------------
Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now.

[-- Attachment #2: Type: text/html, Size: 2608 bytes --]

Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)

[Stefan Roese]

On Monday 03 December 2007, Dell Query wrote:
> I finally got the new pdf files from other Resource CDs and used 0xc000000
> address, without 0x2000 offset.

Good.

> It works! Thanks a lot for the help.
>
> But may I know why in Linux it is mapped to 0x1c000000, wherein the doc
> stated 0xc000000?

The doc most probably only refers to the virtual address mapped in U-Boot 
here.

Best regards,
Stefan

=====================================================================
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: office@denx.de
=====================================================================