All of lore.kernel.org
 help / color / mirror / Atom feed
* Problem reading and programming memory location...
@ 2013-11-12 19:23 neorf3k
  2013-11-13  7:32 ` Anatolij Gustschin
  0 siblings, 1 reply; 12+ messages in thread
From: neorf3k @ 2013-11-12 19:23 UTC (permalink / raw)
  To: Linux Ppc Dev List Dev List

we have tried to read and program an 8bit register with 32bit address. =
we have mapped it with: ioremap, kmalloc etc=85 and then using: outb, =
iowrite8 etc.. but when we write to it, the value doesn=92t change=85 =
with other memory location is ok.
That is an 8 bit register, located at 0x10020000 in a mpc5200b =
architecture. we are using kernel 2.6.33.=20
what could be?
Thank you

Lorenzo=

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
  2013-11-12 19:23 Problem reading and programming memory location neorf3k
@ 2013-11-13  7:32 ` Anatolij Gustschin
  2013-11-13 13:48   ` neorf3k
  0 siblings, 1 reply; 12+ messages in thread
From: Anatolij Gustschin @ 2013-11-13  7:32 UTC (permalink / raw)
  To: neorf3k; +Cc: Linux Ppc Dev List Dev List

On Tue, 12 Nov 2013 20:23:20 +0100
neorf3k <neorf3k@gmail.com> wrote:

> we have tried to read and program an 8bit register with 32bit address.
> we have mapped it with: ioremap, kmalloc etc=E2=80=A6 and then using: out=
b,
> iowrite8 etc.. but when we write to it, the value doesn=E2=80=99t change=
=E2=80=A6
> with other memory location is ok.
> That is an 8 bit register, located at 0x10020000 in a mpc5200b
> architecture. we are using kernel 2.6.33.=20
> what could be?

0x10020000 is not in the internal register memory map, so it
is probably a device on the LocalPlus bus. Did you configure
the chip select parameters for this device and did you enable
the associated chip select?
 =20
HTH,

Anatolij

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
  2013-11-13  7:32 ` Anatolij Gustschin
@ 2013-11-13 13:48   ` neorf3k
  2013-11-13 18:06     ` Anatolij Gustschin
  0 siblings, 1 reply; 12+ messages in thread
From: neorf3k @ 2013-11-13 13:48 UTC (permalink / raw)
  To: Anatolij Gustschin; +Cc: Linux Ppc Dev List Dev List

Yes, that is a device on the lpb via an fpga. We  have tried to =
configure the chip select 4 configuration register at address MBAR + =
0x0310, and it seems to be ok. what do you mean with =93chip select =
parameters=94?
We have been able to edit it in U-BOOT, and the board (that chip) now =
works=85
The strange thing, is that when we read in linux, at that address, we =
see other content value=85
Suggestions?

Thanks

Lorenzo

On 13/nov/2013, at 08:32 AM, Anatolij Gustschin <agust@denx.de> wrote:

> On Tue, 12 Nov 2013 20:23:20 +0100
> neorf3k <neorf3k@gmail.com> wrote:
>=20
>> we have tried to read and program an 8bit register with 32bit =
address.
>> we have mapped it with: ioremap, kmalloc etc=85 and then using: outb,
>> iowrite8 etc.. but when we write to it, the value doesn=92t change=85
>> with other memory location is ok.
>> That is an 8 bit register, located at 0x10020000 in a mpc5200b
>> architecture. we are using kernel 2.6.33.=20
>> what could be?
>=20
> 0x10020000 is not in the internal register memory map, so it
> is probably a device on the LocalPlus bus. Did you configure
> the chip select parameters for this device and did you enable
> the associated chip select?
>=20
> HTH,
>=20
> Anatolij
>=20

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
  2013-11-13 13:48   ` neorf3k
@ 2013-11-13 18:06     ` Anatolij Gustschin
  2013-11-14  8:38       ` neorf3k
  0 siblings, 1 reply; 12+ messages in thread
From: Anatolij Gustschin @ 2013-11-13 18:06 UTC (permalink / raw)
  To: neorf3k; +Cc: Linux Ppc Dev List Dev List

On Wed, 13 Nov 2013 14:48:24 +0100
neorf3k <neorf3k@gmail.com> wrote:

> Yes, that is a device on the lpb via an fpga. We  have tried to configure
> the chip select 4 configuration register at address MBAR + 0x0310, and it
> seems to be ok. what do you mean with =E2=80=9Cchip select parameters=E2=
=80=9D?

I meant the settings you can set up in the Chip Select 1=E2=80=937 Configur=
ation
Registers, like address and data bus size, wait-states, etc.

> We have been able to edit it in U-BOOT, and the board (that chip) now wor=
ks=E2=80=A6
> The strange thing, is that when we read in linux, at that address, we see
> other content value=E2=80=A6
> Suggestions?

if you can access the register under U-Boot and read out the
expected values, then the access should work under Linux too,
assuming the chip select config is not overwritten somewhere
while booting and the register address range is mapped correctly.
I don't know your code, so I would first check if the register
mapping is done correctly, i.e. check the return value of ioremap()
for errors, then check if the chip select configuration is still
valid when the kernel is up. Also verify that your fpga is not
in the reset state when Linux is running.

thanks,

Anatolij

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
  2013-11-13 18:06     ` Anatolij Gustschin
@ 2013-11-14  8:38       ` neorf3k
       [not found]         ` <20131114100917.31f674d7@crub>
  0 siblings, 1 reply; 12+ messages in thread
From: neorf3k @ 2013-11-14  8:38 UTC (permalink / raw)
  To: Anatolij Gustschin

Thank you again=85
we have checked, and the settings in Chip Select 4 Configuration, seems =
to be ok=85

The strange thing is the return value from ioremap(). In U-Boot return =
value from address 0x1002000 is 0x45f80360=85 if we try to map it in our =
module, then we use ioremap(), return value is 0x10101010. So maybe the =
register address is mapped wrong=85 what could i fix it?
Then, after we have setted up the reg at 0x1002000 and we boot linux=85 =
the 0x1002000 doesn=92t change its value=85=20

Thanks again=85

Lorenzo

On 13/nov/2013, at 07:06 PM, Anatolij Gustschin <agust@denx.de> wrote:

> On Wed, 13 Nov 2013 14:48:24 +0100
> neorf3k <neorf3k@gmail.com> wrote:
>=20
>> Yes, that is a device on the lpb via an fpga. We  have tried to =
configure
>> the chip select 4 configuration register at address MBAR + 0x0310, =
and it
>> seems to be ok. what do you mean with =93chip select parameters=94?
>=20
> I meant the settings you can set up in the Chip Select 1=967 =
Configuration
> Registers, like address and data bus size, wait-states, etc.
>=20
>> We have been able to edit it in U-BOOT, and the board (that chip) now =
works=85
>> The strange thing, is that when we read in linux, at that address, we =
see
>> other content value=85
>> Suggestions?
>=20
> if you can access the register under U-Boot and read out the
> expected values, then the access should work under Linux too,
> assuming the chip select config is not overwritten somewhere
> while booting and the register address range is mapped correctly.
> I don't know your code, so I would first check if the register
> mapping is done correctly, i.e. check the return value of ioremap()
> for errors, then check if the chip select configuration is still
> valid when the kernel is up. Also verify that your fpga is not
> in the reset state when Linux is running.
>=20
> thanks,
>=20
> Anatolij

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
       [not found]         ` <20131114100917.31f674d7@crub>
@ 2013-11-14  9:49           ` neorf3k
  2013-11-15 16:27           ` neorf3k
  1 sibling, 0 replies; 12+ messages in thread
From: neorf3k @ 2013-11-14  9:49 UTC (permalink / raw)
  To: Anatolij Gustschin; +Cc: Linux Ppc Dev List Dev List

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

Sorry, the address is 0x10020000.
I've executed this code:

/* code */
   unsigned char *virt_base;
    u8 regval;
    
    /* map 4kbyte reg. space */
    virt_base = ioremap(0x10020000, 0x1000);
    if (!virt_base) {
        printk("fpga ioremap failed\n");
        return;
    }
    
    regval = in_8(virt_base);
    
    
    printk("reg. value 0x%02x\n", regval);
    printk("reg. value %x\n", virt_base);
/* code */

and i've:

reg. value 0x10
address c90e8000

in U-BOOT in reg. value i've: 0xf8

Thank you so much again…

Lorenzo

On 14/nov/2013, at 10:09 AM, Anatolij Gustschin <agust@denx.de> wrote:

>  u8 regval;
> 
>   /* map 4kbyte reg. space */
>   virt_base = ioremap(0x10020000, 0x1000);
>   if (!virt_base) {
>     printk("fpga ioremap failed\n");
>     return;
>   }
> 
>   regval = in_8(virt_base);
> 
>   printk("reg. value 0x%02x\n", regval);


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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
       [not found]         ` <20131114100917.31f674d7@crub>
  2013-11-14  9:49           ` neorf3k
@ 2013-11-15 16:27           ` neorf3k
  2013-11-16 14:29             ` Anatolij Gustschin
  1 sibling, 1 reply; 12+ messages in thread
From: neorf3k @ 2013-11-15 16:27 UTC (permalink / raw)
  To: Anatolij Gustschin; +Cc: Linux Ppc Dev List Dev List, linuxppc-embedded

Hello again, I=92ve tried this code, but we are not able to change cs4 =
reg value=85 what could be?

=97

#define MALab_DEVICE_NAME	"MALab"
#define MPC5xxx_MM_CS4_START	(MBAR_BASE + 0x0024)
#define MPC5xxx_MM_CS4_STOP	(MBAR_BASE + 0x0028)
#define MPC5xxx_MM_IPBI	 (MBAR_BASE + 0x0054)

#define MALab_MM_START	 0x10020000U
#define MALab_MM_END	 0x10020FFFU
#define MALab_MM_SIZE	 0x00001000U

int init_module(void) { ...
    u16 cs4_start_value;
    u16 cs4_stop_value;
    u32 cs4_enable_value;
   =20
    u8 rvoice_ioaddr_value;

   =20
    // reserve a page of memory for our hardware /proc/iomem
    if ( check_region(MALab_MM_START,MALab_MM_SIZE) ) {
        printk (KERN_ALERT "LED init_module: memory already in use\n");
        return -EBUSY;
    }

   =20
    request_mem_region(MALab_MM_START,MALab_MM_SIZE,MALab_DEVICE_NAME);

   =20
    void __iomem *cs0_reg   =3D ioremap ((volatile unsigned =
long)(MBAR_BASE + 0x0300), 4);
    void __iomem *cs3_reg   =3D ioremap ((volatile unsigned =
long)(MBAR_BASE + 0x030C), 4);
   =20
    void __iomem *ipbi_cr =3D ioremap ((volatile unsigned =
long)(MPC5xxx_MM_IPBI), 4);
    void __iomem *cs4_start  =3D ioremap ((volatile unsigned =
long)(MPC5xxx_MM_CS4_START + 2), 2);
    void __iomem *cs4_stop   =3D ioremap ((volatile unsigned =
long)(MPC5xxx_MM_CS4_STOP + 2), 2);
   =20
    void __iomem *cs4_enable   =3D ioremap ((volatile unsigned =
long)(MBAR_BASE + 0x0310), 4);
    void __iomem *cs_ctrl_reg   =3D ioremap ((volatile unsigned =
long)(MBAR_BASE + 0x0318), 4);
    void __iomem *rvoice_ioaddr   =3D ioremap ((volatile unsigned =
long)(MALab_MM_START), MALab_MM_SIZE);
   =20
    //disable CSO

    out_be32(cs0_reg, 0x0004ed00);

   =20
    //disable CS3

    out_be32(cs3_reg, 0x0002cf00);

    // enable LocalBus chip select CS4
    out_be32(ipbi_cr, 0x00290001);

    cs4_start_value=3Din_be16(cs4_start);
    cs4_start_value=3DMALab_MM_START >>16;
    out_be16(cs4_start, cs4_start_value);
    cs4_stop_value=3Din_be16(cs4_stop);
    cs4_stop_value=3DMALab_MM_END >>16;
    out_be16(cs4_stop, cs4_stop_value);

    //enable CS4 and WSE
    out_be32(ipbi_cr, 0x00100001);

    // LocalBus Chip Select 4 Configuration Register
    out_be32(cs4_enable, 0x0002DC00);

    //Enable Chip Select Control Register
    out_be32(cs_ctrl_reg, 0x01000000);

   =20
    rvoice_ioaddr_value=3Din_8(rvoice_ioaddr);
    rvoice_ioaddr_value=3D0xAA;

    printk("rvoice_ioaddr_value---before : %x \n",in_8(rvoice_ioaddr));
    out_8(rvoice_ioaddr, rvoice_ioaddr_value);
    printk("rvoice_ioaddr_value---after : %x \n",in_8(rvoice_ioaddr));
   =20
    =85 }


=97=97

Thank you

Lorenzo


On 14/nov/2013, at 10:09 AM, Anatolij Gustschin <agust@denx.de> wrote:

> Hi,
>=20
> you mention the 0x1002000 as address, this is an address in SDRAM. In
> the previous email you mentioned 0x10020000 as the address. Please =
check
> what is passed to ioremap() as the first argument. Usually the mapping
> and the access to a 8-bit wide register would happen as follows:
>=20
>   u8 regval;
>=20
>   /* map 4kbyte reg. space */
>   virt_base =3D ioremap(0x10020000, 0x1000);
>   if (!virt_base) {
>     printk("fpga ioremap failed\n");
>     return;
>   }
>=20
>   regval =3D in_8(virt_base);
>=20
>   printk("reg. value 0x%02x\n", regval);
>=20
>=20
>=20
> thanks,
>=20
> Anatolij
>=20
>=20
> On Thu, 14 Nov 2013 09:38:35 +0100
> neorf3k <neorf3k@gmail.com> wrote:
>=20
>> Thank you again=85
>> we have checked, and the settings in Chip Select 4 Configuration, =
seems to be ok=85
>>=20
>> The strange thing is the return value from ioremap(). In U-Boot =
return value from address 0x1002000 is 0x45f80360=85 if we try to map it =
in our module, then we use ioremap(), return value is 0x10101010. So =
maybe the register address is mapped wrong=85 what could i fix it?
>> Then, after we have setted up the reg at 0x1002000 and we boot linux=85=
 the 0x1002000 doesn=92t change its value=85=20
>>=20
>> Thanks again=85
>>=20
>> Lorenzo
>>=20
>> On 13/nov/2013, at 07:06 PM, Anatolij Gustschin <agust@denx.de> =
wrote:
>>=20
>>> On Wed, 13 Nov 2013 14:48:24 +0100
>>> neorf3k <neorf3k@gmail.com> wrote:
>>>=20
>>>> Yes, that is a device on the lpb via an fpga. We  have tried to =
configure
>>>> the chip select 4 configuration register at address MBAR + 0x0310, =
and it
>>>> seems to be ok. what do you mean with =93chip select parameters=94?
>>>=20
>>> I meant the settings you can set up in the Chip Select 1=967 =
Configuration
>>> Registers, like address and data bus size, wait-states, etc.
>>>=20
>>>> We have been able to edit it in U-BOOT, and the board (that chip) =
now works=85
>>>> The strange thing, is that when we read in linux, at that address, =
we see
>>>> other content value=85
>>>> Suggestions?
>>>=20
>>> if you can access the register under U-Boot and read out the
>>> expected values, then the access should work under Linux too,
>>> assuming the chip select config is not overwritten somewhere
>>> while booting and the register address range is mapped correctly.
>>> I don't know your code, so I would first check if the register
>>> mapping is done correctly, i.e. check the return value of ioremap()
>>> for errors, then check if the chip select configuration is still
>>> valid when the kernel is up. Also verify that your fpga is not
>>> in the reset state when Linux is running.
>>>=20
>>> thanks,
>>>=20
>>> Anatolij
>>=20
>>=20

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
  2013-11-15 16:27           ` neorf3k
@ 2013-11-16 14:29             ` Anatolij Gustschin
  2013-11-16 15:11               ` neorf3k
  2013-11-19 10:20               ` neorf3k
  0 siblings, 2 replies; 12+ messages in thread
From: Anatolij Gustschin @ 2013-11-16 14:29 UTC (permalink / raw)
  To: neorf3k; +Cc: linuxppc-dev

Hi Lorenzo,

see my comments below.

On Fri, 15 Nov 2013 17:27:30 +0100
neorf3k <neorf3k@gmail.com> wrote:

> Hello again, I=E2=80=99ve tried this code, but we are not able to
> change cs4 reg value=E2=80=A6 what could be?
>=20
> =E2=80=94
>=20
> #define MALab_DEVICE_NAME	"MALab"
> #define MPC5xxx_MM_CS4_START	(MBAR_BASE + 0x0024)
> #define MPC5xxx_MM_CS4_STOP	(MBAR_BASE + 0x0028)
> #define MPC5xxx_MM_IPBI	 (MBAR_BASE + 0x0054)
>=20
> #define MALab_MM_START	 0x10020000U
> #define MALab_MM_END	 0x10020FFFU

Please change MALab_MM_END to 0x10030000U.

> #define MALab_MM_SIZE	 0x00001000U
>=20
> int init_module(void) { ...
>     u16 cs4_start_value;
>     u16 cs4_stop_value;
>     u32 cs4_enable_value;
>    =20
>     u8 rvoice_ioaddr_value;
>=20
>    =20
>     // reserve a page of memory for our hardware /proc/iomem
>     if ( check_region(MALab_MM_START,MALab_MM_SIZE) ) {
>         printk (KERN_ALERT "LED init_module: memory already in use\n");
>         return -EBUSY;
>     }
>=20
>    =20
>     request_mem_region(MALab_MM_START,MALab_MM_SIZE,MALab_DEVICE_NAME);
>=20
>    =20
>     void __iomem *cs0_reg   =3D ioremap ((volatile unsigned long)(MBAR_BA=
SE + 0x0300), 4);
>     void __iomem *cs3_reg   =3D ioremap ((volatile unsigned long)(MBAR_BA=
SE + 0x030C), 4);
>
>     void __iomem *ipbi_cr =3D ioremap ((volatile unsigned long)(MPC5xxx_M=
M_IPBI), 4);
>     void __iomem *cs4_start  =3D ioremap ((volatile unsigned long)(MPC5xx=
x_MM_CS4_START + 2), 2);
>     void __iomem *cs4_stop   =3D ioremap ((volatile unsigned long)(MPC5xx=
x_MM_CS4_STOP + 2), 2);
>    =20
>     void __iomem *cs4_enable   =3D ioremap ((volatile unsigned long)(MBAR=
_BASE + 0x0310), 4);
>     void __iomem *cs_ctrl_reg   =3D ioremap ((volatile unsigned long)(MBA=
R_BASE + 0x0318), 4);


this might work, but this is not how ioremap() supposed to be used.
The mapping is done in 4k-page granularity, so it would be better
to just map the internal register range my one ioremap() call, i.e.

    reg_base =3D ioremap(MBAR_BASE, 0x400);

and then to calculate the register offsets, i.e.

   cs0_reg =3D reg_base + 0x0300;
   cs0_reg =3D reg_base + 0x030C;
   ...
   ipbi_cr =3D reg_base + 0x0054;
   cs4_start =3D reg_base + 0x0026;
   cs4_stop =3D reg_base + 0x002a;
   ...

For FPGA mapping you need a separate ioremap() call of course.

>     void __iomem *rvoice_ioaddr   =3D ioremap ((volatile unsigned long)(M=
ALab_MM_START), MALab_MM_SIZE);
>
>     //disable CSO
>=20
>     out_be32(cs0_reg, 0x0004ed00);
>=20
>    =20
>     //disable CS3
>=20
>     out_be32(cs3_reg, 0x0002cf00);
>=20
>     // enable LocalBus chip select CS4
>     out_be32(ipbi_cr, 0x00290001);

The comment and the code doesn't match here, the code disables
CS4 to configure the its range, so the comment is confusing.

>     cs4_start_value=3Din_be16(cs4_start);
>     cs4_start_value=3DMALab_MM_START >>16;
>     out_be16(cs4_start, cs4_start_value);
>     cs4_stop_value=3Din_be16(cs4_stop);
>     cs4_stop_value=3DMALab_MM_END >>16;
>     out_be16(cs4_stop, cs4_stop_value);

Here is the problem. The _minimal_ chip select range _must_
be 64 KiB, otherwise the register access can't work. Your
current chip select 4 range is less then 1 KiB:

  0x10020FFF - 0x10020000 =3D 0xFFF

Since you right-shift the start and stop values by 16,
the chip select start and stop registers are both 0x1002.
The resulting chip select address range is 0. Therefore
please set MALab_MM_END value to 0x10030000.

Thanks,
Anatolij

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
  2013-11-16 14:29             ` Anatolij Gustschin
@ 2013-11-16 15:11               ` neorf3k
  2013-11-19 10:20               ` neorf3k
  1 sibling, 0 replies; 12+ messages in thread
From: neorf3k @ 2013-11-16 15:11 UTC (permalink / raw)
  To: Anatolij Gustschin; +Cc: Linux Ppc Dev List Dev List

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

Hi Anatolij,
thank you so much for you answer… monday i’ll test… 
i answer you just to complete the information:
we are using an mpc5200b and the details for that reg located at: 0x10020000 are:

Chip select 4 specification:
Lp_cs4
bus size: 8 bit
bus control: 2 wait state R/W ACK disabled
size allocated: 4 KByte

Our Register 8 bit LP_cs4 (we want to write)

cs4 offset: 0x001

Thank you again..

Lorenzo

On 16/nov/2013, at 03:29 PM, Anatolij Gustschin <agust@denx.de> wrote:

> Hi Lorenzo,
> 
> see my comments below.
> 
> On Fri, 15 Nov 2013 17:27:30 +0100
> neorf3k <neorf3k@gmail.com> wrote:
> 
>> Hello again, I’ve tried this code, but we are not able to
>> change cs4 reg value… what could be?
>> 
>> —
>> 
>> #define MALab_DEVICE_NAME	"MALab"
>> #define MPC5xxx_MM_CS4_START	(MBAR_BASE + 0x0024)
>> #define MPC5xxx_MM_CS4_STOP	(MBAR_BASE + 0x0028)
>> #define MPC5xxx_MM_IPBI	 (MBAR_BASE + 0x0054)
>> 
>> #define MALab_MM_START	 0x10020000U
>> #define MALab_MM_END	 0x10020FFFU
> 
> Please change MALab_MM_END to 0x10030000U.
> 
>> #define MALab_MM_SIZE	 0x00001000U
>> 
>> int init_module(void) { ...
>>    u16 cs4_start_value;
>>    u16 cs4_stop_value;
>>    u32 cs4_enable_value;
>> 
>>    u8 rvoice_ioaddr_value;
>> 
>> 
>>    // reserve a page of memory for our hardware /proc/iomem
>>    if ( check_region(MALab_MM_START,MALab_MM_SIZE) ) {
>>        printk (KERN_ALERT "LED init_module: memory already in use\n");
>>        return -EBUSY;
>>    }
>> 
>> 
>>    request_mem_region(MALab_MM_START,MALab_MM_SIZE,MALab_DEVICE_NAME);
>> 
>> 
>>    void __iomem *cs0_reg   = ioremap ((volatile unsigned long)(MBAR_BASE + 0x0300), 4);
>>    void __iomem *cs3_reg   = ioremap ((volatile unsigned long)(MBAR_BASE + 0x030C), 4);
>> 
>>    void __iomem *ipbi_cr = ioremap ((volatile unsigned long)(MPC5xxx_MM_IPBI), 4);
>>    void __iomem *cs4_start  = ioremap ((volatile unsigned long)(MPC5xxx_MM_CS4_START + 2), 2);
>>    void __iomem *cs4_stop   = ioremap ((volatile unsigned long)(MPC5xxx_MM_CS4_STOP + 2), 2);
>> 
>>    void __iomem *cs4_enable   = ioremap ((volatile unsigned long)(MBAR_BASE + 0x0310), 4);
>>    void __iomem *cs_ctrl_reg   = ioremap ((volatile unsigned long)(MBAR_BASE + 0x0318), 4);
> 
> 
> this might work, but this is not how ioremap() supposed to be used.
> The mapping is done in 4k-page granularity, so it would be better
> to just map the internal register range my one ioremap() call, i.e.
> 
>    reg_base = ioremap(MBAR_BASE, 0x400);
> 
> and then to calculate the register offsets, i.e.
> 
>   cs0_reg = reg_base + 0x0300;
>   cs0_reg = reg_base + 0x030C;
>   ...
>   ipbi_cr = reg_base + 0x0054;
>   cs4_start = reg_base + 0x0026;
>   cs4_stop = reg_base + 0x002a;
>   ...
> 
> For FPGA mapping you need a separate ioremap() call of course.
> 
>>    void __iomem *rvoice_ioaddr   = ioremap ((volatile unsigned long)(MALab_MM_START), MALab_MM_SIZE);
>> 
>>    //disable CSO
>> 
>>    out_be32(cs0_reg, 0x0004ed00);
>> 
>> 
>>    //disable CS3
>> 
>>    out_be32(cs3_reg, 0x0002cf00);
>> 
>>    // enable LocalBus chip select CS4
>>    out_be32(ipbi_cr, 0x00290001);
> 
> The comment and the code doesn't match here, the code disables
> CS4 to configure the its range, so the comment is confusing.
> 
>>    cs4_start_value=in_be16(cs4_start);
>>    cs4_start_value=MALab_MM_START >>16;
>>    out_be16(cs4_start, cs4_start_value);
>>    cs4_stop_value=in_be16(cs4_stop);
>>    cs4_stop_value=MALab_MM_END >>16;
>>    out_be16(cs4_stop, cs4_stop_value);
> 
> Here is the problem. The _minimal_ chip select range _must_
> be 64 KiB, otherwise the register access can't work. Your
> current chip select 4 range is less then 1 KiB:
> 
>  0x10020FFF - 0x10020000 = 0xFFF
> 
> Since you right-shift the start and stop values by 16,
> the chip select start and stop registers are both 0x1002.
> The resulting chip select address range is 0. Therefore
> please set MALab_MM_END value to 0x10030000.
> 
> Thanks,
> Anatolij


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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
  2013-11-16 14:29             ` Anatolij Gustschin
  2013-11-16 15:11               ` neorf3k
@ 2013-11-19 10:20               ` neorf3k
  2013-11-19 21:45                 ` Anatolij Gustschin
  1 sibling, 1 reply; 12+ messages in thread
From: neorf3k @ 2013-11-19 10:20 UTC (permalink / raw)
  To: Anatolij Gustschin; +Cc: Linux Ppc Dev List Dev List

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

Hello Anatolij, this is our code, used at University, but again it doesn’t work…

How i told, the only information we have about that reg are:

Chip select 4 specification:
Lp_cs4
bus size: 8 bit
bus control: 2 wait state R/W ACK disabled
size allocated: 4 KByte

Our Register 8 bit LP_cs4 (we want to write)

cs4 offset: 0x001

The code we have used:

——
#define MBAR_BASE       0xF0000000
#define MALab_MM_START	 0x10020000U
#define MALab_MM_END	 0x10030000U
#define MALab_MM_SIZE	 0x00010000U

#define MALab_DEVICE_NAME	"MALab"

int init_module(void) { ...
    u16 cs4_start_value;
    u16 cs4_stop_value;
    u32 cs4_enable_value;
    u32 cs0_reg_value;
    u32 cs3_reg_value;
    u32 ipbi_cr_value;
    u32 cs_ctrl_reg_value;
    u8 rvoice_ioaddr_value;
    
    
    // reserve a page of memory for our hardware /proc/iomem
    if ( check_region(MALab_MM_START,MALab_MM_SIZE) ) {
        printk (KERN_ALERT "LED init_module: memory already in use\n");
        return -EBUSY;
    }
    
    request_region(MALab_MM_START,MALab_MM_SIZE,MALab_DEVICE_NAME);
    
    void __iomem *reg_base = ioremap(MBAR_BASE, 0x400);
    void __iomem *cs0_reg   = reg_base + 0x0300;
    void __iomem *cs1_reg   = reg_base + 0x0304;
    void __iomem *cs2_reg   = reg_base + 0x0308;
    void __iomem *cs3_reg   = reg_base + 0x030C;
    void __iomem *ipbi_cr = reg_base + 0x0054;
    void __iomem *cs4_start  = reg_base + 0x0024;
    void __iomem *cs4_stop   = reg_base + 0x0028;
    void __iomem *cs4_enable   = reg_base + 0x0310;
    void __iomem *cs_ctrl_reg   = reg_base + 0x0318;
    void __iomem *rvoice_ioaddr   = ioremap ((volatile unsigned long)(MALab_MM_START), MALab_MM_SIZE);
    
    printk(KERN_ALERT “r_ioaddr: 0x%08x\n", (u32)rvoice_ioaddr);
    
    //Chip Select 0/Boot Configuration Register: CE=0
    cs0_reg_value =in_be32(cs0_reg);
    out_be32(cs0_reg, (cs0_reg_value &= ~0x00010000));
    
    //Chip Select 3 Configuration Register: CE=0
    cs3_reg_value =in_be32(cs3_reg);
    out_be32(cs3_reg, (cs3_reg_value &= ~0x00010000));
    
    //enable LocalBus chip select CS4 to hit on our address range
    ipbi_cr_value=in_be32(ipbi_cr);
    out_be32(ipbi_cr, (ipbi_cr_value &= 0x00100001));
    out_be32(ipbi_cr, (ipbi_cr_value |= 0x00100001));
    out_be16(cs4_start+2, MALab_MM_START >>16);
    out_be16(cs4_stop+2, MALab_MM_END >>16);

    // LocalBus Chip Select 4 Configuration Register
    out_be32(cs4_enable, 0x0002DC00);
    
    //Enable Chip Select Control Register
    cs_ctrl_reg_value=in_be32(cs_ctrl_reg);
    out_be32(cs_ctrl_reg, (cs_ctrl_reg_value |= 0x01000000));
    
    //start solution A
    rvoice_ioaddr_value=in_8(rvoice_ioaddr);
    rvoice_ioaddr_value=0xAA;
    printk("A r_ioaddr_value---before : %x \n",in_8(rvoice_ioaddr));
    
    out_8(rvoice_ioaddr, rvoice_ioaddr_value);
    
    printk("A r_ioaddr_value---after : %x \n",in_8(rvoice_ioaddr));
    //end solution A
    
    //start solution B
    *(volatile u8 *)rvoice_ioaddr = 0xAA;
    printk("\n B r_ioaddr_value %x\n",*(volatile u8 *)rvoice_ioaddr);
    //end solution B

    
    ... }
——

the result is:

rvoice_ioaddr: 0xc9080000
A rvoice_ioaddr_value---before : 10 
A rvoice_ioaddr_value---after : 10 
B rvoice_ioaddr_value 10
——

we found some information on this post: http://linuxppc.10917.n7.nabble.com/MPC5200b-kernel-module-memory-mapping-td59862.html

Thanks again…

Lorenzo


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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
  2013-11-19 10:20               ` neorf3k
@ 2013-11-19 21:45                 ` Anatolij Gustschin
  2013-11-26 18:29                   ` neorf3k
  0 siblings, 1 reply; 12+ messages in thread
From: Anatolij Gustschin @ 2013-11-19 21:45 UTC (permalink / raw)
  To: neorf3k; +Cc: Linux Ppc Dev List Dev List

Hi Lorenzo,

On Tue, 19 Nov 2013 11:20:24 +0100
neorf3k <neorf3k@gmail.com> wrote:

> Hello Anatolij, this is our code, used at University, but again it doesn=
=E2=80=99t work=E2=80=A6
>=20
> How i told, the only information we have about that reg are:
>=20
> Chip select 4 specification:
> Lp_cs4
> bus size: 8 bit
> bus control: 2 wait state R/W ACK disabled
> size allocated: 4 KByte
>=20
> Our Register 8 bit LP_cs4 (we want to write)
>=20
> cs4 offset: 0x001

is the byte in FPGA at offset 0x0 writable? In your code you
currently test read/write access to the byte at offset 0x0.

If the read/write access works under U-Boot, then maybe the
chip select parameters for CS4 are configured differently
in U-Boot. You can dump the Chip Select 4 configuration
registers under U-Boot and compare. Is address- and data-bus
to the FPGA multipexed? Another possible reason for non-working
access could be that the configured CS4 range 0x10020000 - 0x10030000
overlaps with configured range for CS0, CS1, CS2 or CS3. Can you
verify that no such overlapping exists.

Thanks,

Anatolij

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Problem reading and programming memory location...
  2013-11-19 21:45                 ` Anatolij Gustschin
@ 2013-11-26 18:29                   ` neorf3k
  0 siblings, 0 replies; 12+ messages in thread
From: neorf3k @ 2013-11-26 18:29 UTC (permalink / raw)
  To: Anatolij Gustschin; +Cc: Linux Ppc Dev List Dev List

Hi Anatolij,
we have tried again=85 but the problem is still there=85 we are not able =
to read/write, not only CS4, but also CS1, CS2, CS3, etc=85

According to you, could we fix the problem if we include our Virtex FPGA =
in Device Tree?

U-Boot has been patched (not by us), for CS4, with:

+#define CONFIG_SYS_CS0_START		CONFIG_SYS_FLASH_BASE
+#define CONFIG_SYS_CS0_SIZE		CONFIG_SYS_FLASH_SIZE
+#define CONFIG_SYS_CS0_CFG       0x000ADD00


+#define CONFIG_SYS_CS3_START     0x10000000    //
+#define CONFIG_SYS_CS3_SIZE      0x00020000    //
+#define CONFIG_SYS_CS3_CFG       0x0002DF00    //=20
+
+#define CONFIG_SYS_CS4_START     0x10020000    //
+#define CONFIG_SYS_CS4_SIZE      0x00020000    //
+#define CONFIG_SYS_CS4_CFG       0x0002DC00    //=20
+
+#define CONFIG_SYS_CS5_START     0x11000000    //
+#define CONFIG_SYS_CS5_SIZE      0x01000000    //
+#define CONFIG_SYS_CS5_CFG       0x0002DD00    //=20
+
+#define CONFIG_SYS_CS_BURST		0x00000000
+#define CONFIG_SYS_CS_DEADCYCLE	0x33333333
+
+#define CONFIG_SYS_RESET_ADDRESS	0xff000000

but CONFIG_SYS_CS4_SIZE should be: 0x00010000 ...

Thank you

Lorenzo

On 19/nov/2013, at 10:45 PM, Anatolij Gustschin <agust@denx.de> wrote:

> Hi Lorenzo,
>=20
> On Tue, 19 Nov 2013 11:20:24 +0100
> neorf3k <neorf3k@gmail.com> wrote:
>=20
>> Hello Anatolij, this is our code, used at University, but again it =
doesn=92t work=85
>>=20
>> How i told, the only information we have about that reg are:
>>=20
>> Chip select 4 specification:
>> Lp_cs4
>> bus size: 8 bit
>> bus control: 2 wait state R/W ACK disabled
>> size allocated: 4 KByte
>>=20
>> Our Register 8 bit LP_cs4 (we want to write)
>>=20
>> cs4 offset: 0x001
>=20
> is the byte in FPGA at offset 0x0 writable? In your code you
> currently test read/write access to the byte at offset 0x0.
>=20
> If the read/write access works under U-Boot, then maybe the
> chip select parameters for CS4 are configured differently
> in U-Boot. You can dump the Chip Select 4 configuration
> registers under U-Boot and compare. Is address- and data-bus
> to the FPGA multipexed? Another possible reason for non-working
> access could be that the configured CS4 range 0x10020000 - 0x10030000
> overlaps with configured range for CS0, CS1, CS2 or CS3. Can you
> verify that no such overlapping exists.
>=20
> Thanks,
>=20
> Anatolij

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2013-11-26 18:29 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-12 19:23 Problem reading and programming memory location neorf3k
2013-11-13  7:32 ` Anatolij Gustschin
2013-11-13 13:48   ` neorf3k
2013-11-13 18:06     ` Anatolij Gustschin
2013-11-14  8:38       ` neorf3k
     [not found]         ` <20131114100917.31f674d7@crub>
2013-11-14  9:49           ` neorf3k
2013-11-15 16:27           ` neorf3k
2013-11-16 14:29             ` Anatolij Gustschin
2013-11-16 15:11               ` neorf3k
2013-11-19 10:20               ` neorf3k
2013-11-19 21:45                 ` Anatolij Gustschin
2013-11-26 18:29                   ` neorf3k

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.