2009-10-01 11:01:44     memory access

2009-10-01 11:01:44     memory access

Filip Vanalme (BELGIUM)

Message: 80772   

Hi,

I know this is not the way to do it, but for fast testing things...

Should it be possible to access memory locations in Async Memory Bank 2 from user space application ? Do I have to configure it somewhere ?

I did a small test an I succeeded in reading from 0x28000000 till 0x280003FF. Reading at address 0x28000400 and beyond gives me a kernel panic :

DCPLB_FAULT_ADDR=28000400

ICPLB_FAULT_ADDR=00613828

Stack from 0020aa28:<0>

       <0> 00000000<0> 00105394<0> 00000000<0> 00613828<0> 0000ffff<0> ffa00226<0> 00686aa4<0> 00683974<0>

       <0> 005ffedc<0> 00000001<0> 0010690c<0> 00000002<0> 006b8000<0> 00000000<0> ffffffff<0> 00000026<0>

       <0> 02000020<0> 004b3eae<0> 004b3eae<0> 00000026<0> 00000000<0> 00652000<0> 00613828<0> 004b3eae<0>

       <0> 00613832<0> 00000010<0> 02000020<0> 00000001<0> 004afd8d<0> 00000000<0> 004afd8a<0> 00000000<0>

       <0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000312<0> 00418244<0> 005fedc8<0>

       <0> 00001000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0>

Call Trace:<0>

       <0> [<00100000>]<0> [<00107e74>]<0> [<00107eb8>]<0> [<00107f04>]<0>

       <0> [<00107f48>]<0> [<00107db8>]<0> [<00107e0c>]<0> [<00107e40>]<0>

       <0> [<00107db8>]<0> [<00107dbc>]<0> [<00107de4>]<0> [<001e5430>]<0>

       <0> [<001e5444>]<0> [<001853bc>]<0> [<001853c8>]<0> [<001e89c4>]<0>

       <0> [<00185314>]<0> [<001e5450>]<0> [<001853bc>]<0> [<001853c8>]<0>

       <0> [<001e89c4>]<0> [<00185314>]<0> [<001e5460>]<0> [<001853bc>]<0>

       <0> [<001853c8>]<0> [<001e89c4>]<0> [<00185314>]<0> [<001e546c>]<0>

       <0> [<001853bc>]<0> [<001853c8>]<0>

Kernel panic - not syncing: No CPLB Address Match

I'm sure I'm missing something...

(I know the registers of a quad uart are actually mapped at the beginning of bank 2 - that explains certainly why I succeed in accessing that address region. But where is it configure...? )

Filip

TranslateQuoteReplyEditDelete

2009-10-01 12:00:19     Re: memory access

Mike Frysinger (UNITED STATES)

Message: 80775   

it should work fine, but that doesnt mean the kernel version you're using supports it.  you didnt say what version of software you're using.

QuoteReplyEditDelete

2009-10-02 02:18:11     Re: memory access

Filip Vanalme (BELGIUM)

Message: 80788   

Kernel version 2006R1... I know, this is old...but for now, that's what I have...

TranslateQuoteReplyEditDelete

2009-10-02 02:25:08     Re: memory access

Mike Frysinger (UNITED STATES)

Message: 80789   

iirc, 2006R1 had crappy CPLB handling.  we threw it all out for scalable versions.

try reading /proc/cplb (or maybe named something similar) and see if you have dcplbs for that region.  clearly you dont so you'll have to find/hack the cplb code to add proper entries for the async banks.  you can probably find it under arch/blackfin/kernel/*cplb*.[ch] ... and maybe setup.c.  hard to say.

QuoteReplyEditDelete

2009-10-02 04:35:17     Re: memory access

Filip Vanalme (BELGIUM)

Message: 80799   

Hi Mike,

I checked the /proc/cplbinfo file and indeed found an entry for the address 0x28000000 with only 1K of size instead of 4M. Now I still have to lookup where the cplb table is established... (I found a file setup_561.c in /arch/blackfin/kernel, but I'm not sure this is the one I need...)

Thanks.

Filip

TranslateQuoteReplyEditDelete

2009-10-02 12:50:55     Re: memory access

Mike Frysinger (UNITED STATES)

Message: 80809   

if you get really stuck, let me know and i'll take a peek.  the 2006 kernel was before i started working on Blackfin sources, so it'd take me a little while to track down the issue.

QuoteReplyEditDelete

2009-10-27 07:02:21     Re: memory access

Filip Vanalme (BELGIUM)

Message: 81779   

Hi Mike,

I finally found that I had to change the cplbtab.h file (linux-2.6.x/include/asm_blackfin/cplbtab.h). There, I could change the range of the 0x28000000 from 1K to 1M. running cat /proc/cplbinfo showed the modified range. After that, I no langer have kernel panics when writing to that range.

However, when inspecting the signals with a logic analyzer, I notice that the ARE, AWE and AOE are not always active when writing in the AMB2. When writing to 0x28000000, I notice an active AWE. However, when writing to 0x28000200, AWE does not change at all. The only difference is that an uart is mapped in that lower part of AMB2 (configured in ezkit.c). And thus this part is maybe "enabled" somewhere in the uart kernel driver, while the rest of the AMB2 remains inaccessible.

Is there still something I have to change before I can really access the whole range of AMB2 ? Somthing to do with rights/permissions ?

Many thanks in advance !

Filip

TranslateQuoteReplyEditDelete

2009-10-27 07:13:11     Re: memory access

Mike Frysinger (UNITED STATES)

Message: 81780   

if you're writing directly to the async bank from userspace, i'm not aware of anything in software that would make a difference here.  there are no software settings that allows for behavior changes within an async bank.  you can change things between async banks (so ASM0 vs ASM1), but settings for an async bank are the same for the entire bank.

if the CPLB settings marked the region as cached, then you might get random funky behavior, but i'm pretty sure we've never marked any async region as cached and all you did was increase the size.  you could double check the /proc/cplbinfo file to make sure it isnt cached.

otherwise, someone who knows something about hardware would have to provide a suggestion.  i'm just a software guy.

QuoteReplyEditDelete

2009-10-27 07:52:10     Re: memory access

Filip Vanalme (BELGIUM)

Message: 81783   

Thanks Mike,

This is what my cplbinfo looks like now :

root:/bin> cat /proc/cplbinfo

------------------ CPLB Information ------------------

Instrction CPLB entry:

Address         Data    Size    Valid   Locked  Swapin  iCount  oCount

0xffa00000      0x20007 1M      Y       Y        0      0       0

0xfeb00000      0x20007 1M      Y       Y        1      0       0

0x00000000      0x31007 4M      Y       Y        2      0       0

0x00400000      0x31005 4M      Y       N        3      0       0

0x00800000      0x31005 4M      Y       N        4      0       0

0x00c00000      0x31005 4M      Y       N        5      0       0

0x01000000      0x31005 4M      Y       N        6      0       0

0x01400000      0x31005 4M      Y       N        7      0       0

0x01800000      0x31005 4M      Y       N        8      0       0

0x01c00000      0x31005 4M      Y       N        9      0       0

0x02000000      0x31005 4M      Y       N       10      0       0

0x02400000      0x31005 4M      Y       N       11      0       0

0x02800000      0x31005 4M      Y       N       12      0       0

0x02c00000      0x30005 4M      Y       N       13      0       0

0x03000000      0x30005 4M      Y       N       14      0       0

0x03400000      0x30005 4M      Y       N       15      0       0

0x03800000      0x30005 4M      Y       N       -1      0       0

0x03c00000      0x30005 4M      Y       N       -1      0       0

Data CPLB entry:

Address         Data    Size    Valid   Locked  Swapin  iCount  oCount

0xff800000      0x3421f 4M      Y       Y        0      0       0

0xfeb00000      0x2c21f 1M      Y       Y        1      0       0

0x2c000000      0x0c21d 1K      Y       N        8      1       1

0x28000000      0x2c21d 1M      Y       N       11      1       1

0x20000000      0x3021d 4M      Y       N       -1      0       1

0x20400000      0x3021d 4M      Y       N       -1      0       1

0x20800000      0x3021d 4M      Y       N        6      1       0

0x20c00000      0x3021d 4M      Y       N        7      1       0

0x26000000      0x2c21d 1M      Y       N       -1      0       0

0x2d000000      0x0c21d 1K      Y       N       -1      0       0

0x00000000      0x3d21f 4M      Y       Y        2      0       0

0x00400000      0x3d21d 4M      Y       N        9      1       1

0x00800000      0x3d21d 4M      Y       N       10      1       1

0x00c00000      0x3d21d 4M      Y       N       -1      0       1

0x01000000      0x3d21d 4M      Y       N       12      1       1

0x01400000      0x3d21d 4M      Y       N       13      1       1

0x01800000      0x3d21d 4M      Y       N       -1      0       0

0x01c00000      0x3d21d 4M      Y       N       -1      0       0

0x02000000      0x3d21d 4M      Y       N       14      1       1

0x02400000      0x3d21d 4M      Y       N        4      1       0

0x02800000      0x3d21d 4M      Y       N        5      1       0

0x02c00000      0x3c21d 4M      Y       N       15      1       1

0x03000000      0x3c21d 4M      Y       N       -1      0       1

0x03400000      0x3c21d 4M      Y       N        3      0       0

0x03800000      0x3c21d 4M      Y       N       -1      0       0

0x03c00000      0x3c21d 4M      Y       N       -1      0       0

root:/bin>

I don't see any problems with it, you ?

Filip

TranslateQuoteReplyEditDelete

2009-10-27 08:13:29     Re: memory access

Mike Frysinger (UNITED STATES)

Message: 81785   

your 0x28000000 range is marked as cached: 0x2c21d

that 0xc needs to be 0x0

QuoteReplyEditDelete

2009-10-27 09:02:03     Re: memory access

Filip Vanalme (BELGIUM)

Message: 81787   

OK, changed it to not cached :

0xff800000      0x3421f 4M      Y       Y        0      0       0

0xfeb00000      0x2c21f 1M      Y       Y        1      0       0

0x2c000000      0x0c21d 1K      Y       N        8      1       1

0x28000000      0x3021d 4M      Y       N       11      1       1

0x20000000      0x3021d 4M      Y       N       -1      0       1

0x20400000      0x3021d 4M      Y       N       -1      0       1

But it still doesn't work correctly. We notice a strange behaviour :

In my application, in a simple for-loop, I write 0xFF on addresses 0x28000000 till 0x28000400. On the logic analyzer we see a valid AWE signal from 0x28000000 till 0x280000FF. However, if I start writing from 0x28000020 then everything goes well till address 0x28000103. Writing from 0x28000120 works well till 0x2800013F. Not logical at all...

I will continue investigating this, because this makes no sense...

Filip

TranslateQuoteReplyEditDelete

2009-10-28 03:28:20     Re: memory access

Filip Vanalme (BELGIUM)

Message: 81808   

Hi Mike,

I think everything is OK now. The problem was, beside the problem with the cplb,  a wrong interpretation of the logic analyzer results due to our testing setup (e.g. wrong triggering). Yesterday evening, I was finally able to write to e.g. address 0x28006800 and the analyze showed correct behaviour. Today, I continue testing, but I expect the addressing to be working fine now.

Thanks for your support !

Filip