iMX31 MBX registers Porting problem

iMX31 MBX registers Porting problem

[Badguy Badguy]

Hello,

 I am trying to access the MBX registers on the iMX31 SOM from LogicPD

executing this code works on kernel 2.6.19.2 which has some out of
tree patches (freescale + community)

/* arch/arm/mach-mx3/mach-mx31lite.c */
#define MBX1_GLOBREG_REVISION  0x0F10
#define MBX_REG_SYS_PHYS_BASE  0xC0000000
#define MBX_REG_RANGE                   0x00004000

static struct resource mxc_reg_resources[] = {
       {
       .start = MBX_REG_SYS_PHYS_BASE,
       .end = MBX_REG_SYS_PHYS_BASE + MBX_REG_RANGE - 1,
       .flags = IORESOURCE_MEM },
};

/* some drivertest.c */
static u32 mx3reg_read_reg(struct mx3reg_data *mx3reg, unsigned long reg)
{
       return __raw_readl(mx3reg->reg_base + reg);
}

static int reg_probe(struct platform_device *pdev)
{
...
       mbx_reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
       if (!mbx_reg)
               return -EINVAL;
..
       mx3reg->reg_base = ioremap(mbx_reg->start, resource_size(mbx_reg));
       if (!mx3reg->reg_base) {
               ret = -ENOMEM;
               goto eremap;
       }

       printk(KERN_CRIT "Address: 0x%08X\n", mx3reg->reg_base);

       regread = mx3reg_read_reg(mx3reg, MBX1_GLOBREG_REVISION);
       printk(KERN_CRIT "MBX1_GLOBREG_REVISION: 0x%.8X\n", regread);
....
}

 I get:

Address: 0xC7860000
MBX1_GLOBREG_REVISION: 0x01010200

on kernel 2.6.19.2 and this is correct value as the revision.

I have tried it on these kernels:

2.6.19.2-custom - this one works, without any pvr drivers loaded
outside of kernel.

2.6.35
2.6.38-rc2
 neither of these worked, provide various dynamic address results for
the registers,
 when read do not conform to expected results.

here are some examples, I am iounmap and kfree when removing correctly
but I still get a new address for each insert, after removal,
this does not happen on 2.6.19.2, it's always the same.

Address: 0xC48A0000
MBX1_GLOBREG_REVISION: 0x00000000

Address: 0xC48A8000
MBX1_GLOBREG_REVISION: 0x00000000

Address: 0xC48B8000
MBX1_GLOBREG_REVISION: 0x00000000

Address: 0xC48C0000
MBX1_GLOBREG_REVISION: 0x00000000

 I have been trying to understand the code behind ioremap, and the
changes involved.

I have read a number of posts regarding ioremap
I am unsure of exactly what the problem is.

Is there another memory access method I should be using?

Could it could be that, either the ipu code, or the frame buffer code
from kernel 2.6.19.2 is somehow enabling this to work?
disabling the code via the configuration does not stop my driver from working

Is it likely there is some further initialization code in kernel 2.6.19.2?
how can I identify it?

are there any tips for finding out more about this?
I am afraid I have not been able to find a good start point.

Thanks for reading, sorry for length.

iMX31 MBX registers Porting problem

[Russell King - ARM Linux]

On Sat, Jan 29, 2011 at 11:48:54PM -0700, Badguy Badguy wrote:
> 2.6.35
> 2.6.38-rc2
>  neither of these worked, provide various dynamic address results for
> the registers,
>  when read do not conform to expected results.
> 
> here are some examples, I am iounmap and kfree when removing correctly
> but I still get a new address for each insert, after removal,
> this does not happen on 2.6.19.2, it's always the same.
> 
> Address: 0xC48A0000
> MBX1_GLOBREG_REVISION: 0x00000000
> 
> Address: 0xC48A8000
> MBX1_GLOBREG_REVISION: 0x00000000
> 
> Address: 0xC48B8000
> MBX1_GLOBREG_REVISION: 0x00000000
> 
> Address: 0xC48C0000
> MBX1_GLOBREG_REVISION: 0x00000000
> 
>  I have been trying to understand the code behind ioremap, and the
> changes involved.

I can't say why you can't access the registers, but as far as the above
goes, please check /proc/vmallocinfo after each insert and remove, and
report anything which looks wrong.

You should see a new entry when you insert, and that entry removed when
you remove your module.  Check that you're calling iounmap() with the
right arguments too.

It might help if you posted a cut-down version of your code which just
demonstrates the problem so others with an iMX31 can try it too.

iMX31 MBX registers Porting problem

[Chris]

On Sun, Jan 30, 2011 at 5:31 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jan 29, 2011 at 11:48:54PM -0700, Badguy Badguy wrote:
>> 2.6.35
>> 2.6.38-rc2
>> ?neither of these worked, provide various dynamic address results for
>> the registers,
>> Address: 0xC48C0000
>> MBX1_GLOBREG_REVISION: 0x00000000
>>
>> ?I have been trying to understand the code behind ioremap, and the
>> changes involved.
>
> I can't say why you can't access the registers, but as far as the above
> goes, please check /proc/vmallocinfo after each insert and remove, and
> report anything which looks wrong.

Ok, I did that and it inserts and removes an entry I am not sure about
what would be wrong.

0x7f000000-0x7f002000    8192 module_alloc_update_bounds+0x18/0x68
pages=1 vmalloc
...
0x848a0000-0x848a5000   20480 reg_probe+0x94/0x12c [reg] ioremap

0x7f006000-0x7f008000    8192 module_alloc_update_bounds+0x18/0x68
pages=1 vmalloc
...
0x848a8000-0x848ad000   20480 reg_probe+0x94/0x12c [reg] ioremap

here are two insertions, also showing the module bounds update, not
sure what to make of this information.

when I cat /proc/iomem I can see my entry:
   c0000000-c0003fff : mx3_mbx_regs.0

how can I know that the mapping is pointing me to my location?

>
> You should see a new entry when you insert, and that entry removed when
> you remove your module. ?Check that you're calling iounmap() with the
> right arguments too.
>

I do see the insertion and removal of a given entry when adding it,
also the one for the module wrapper.

when I read it on 2.6.19.2 it works, I have removed practically all
drivers and am left with
platform code and some serial support and it still works there.

I think I just have no confidence it has returned my requested location.
If I can get confirmation of that somehow it would be easier to move
on and look elsewhere.

> It might help if you posted a cut-down version of your code which just
> demonstrates the problem so others with an iMX31 can try it too.

I have attached a small file that I am using to example this problem.
I have no idea, what to do next here, so I am going to scour the 2.6.19.2 code
looking for something that might be turning this chip on. maybe iomux
has enabled it somewhere.

what about the amba interface? should i be using that to access this device?

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0277f/Cjacbdbd.html

are these the same thing? is this amba code found in the kernel going
to operate this device?

Thanks for your suggestions, I will continue looking.
I want to see fast graphics on the iMX on 2.6.38-rc2 :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reg.c
Type: text/x-csrc
Size: 3366 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110130/16eba3ea/attachment.bin>

iMX31 MBX registers Porting problem

[Russell King - ARM Linux]

On Sun, Jan 30, 2011 at 10:08:02PM -0700, Chris wrote:
> Ok, I did that and it inserts and removes an entry I am not sure about
> what would be wrong.
> 
> 0x7f000000-0x7f002000    8192 module_alloc_update_bounds+0x18/0x68
> pages=1 vmalloc
> ...
> 0x848a0000-0x848a5000   20480 reg_probe+0x94/0x12c [reg] ioremap
> 
> 0x7f006000-0x7f008000    8192 module_alloc_update_bounds+0x18/0x68
> pages=1 vmalloc
> ...
> 0x848a8000-0x848ad000   20480 reg_probe+0x94/0x12c [reg] ioremap
> 
> here are two insertions, also showing the module bounds update, not
> sure what to make of this information.

The 'module_alloc_update_bounds+0x18/0x68' entry is the space used for
your module.  As it is free'd lazily, each time you insert it you'll
get different virtual addresses.

> when I cat /proc/iomem I can see my entry:
>    c0000000-c0003fff : mx3_mbx_regs.0
> 
> how can I know that the mapping is pointing me to my location?

ioremap() always gives you a cookie for use with readl() et.al. or NULL.
If it's successful, the mapping will have been created and pointing at
the requested bus address.

I can't see anything wrong with your code, so I suspect you're missing
something with the hardware - maybe a clock which isn't running or an
enable bit somewhere?

I've no idea how MBX works on the MX platforms, so I can't really suggest
anything further.

iMX31 MBX registers Porting problem

[Chris]

On Mon, Jan 31, 2011 at 8:45 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sun, Jan 30, 2011 at 10:08:02PM -0700, Chris wrote:
>> Ok, I did that and it inserts and removes an entry I am not sure about
>> what would be wrong.
>>
>> 0x7f000000-0x7f002000 ? ?8192 module_alloc_update_bounds+0x18/0x68
>> pages=1 vmalloc
>> ...
>> 0x848a0000-0x848a5000 ? 20480 reg_probe+0x94/0x12c [reg] ioremap
>>
>> 0x7f006000-0x7f008000 ? ?8192 module_alloc_update_bounds+0x18/0x68
>> pages=1 vmalloc
>> ...
>> 0x848a8000-0x848ad000 ? 20480 reg_probe+0x94/0x12c [reg] ioremap
>>
>> here are two insertions, also showing the module bounds update, not
>> sure what to make of this information.
>
> The 'module_alloc_update_bounds+0x18/0x68' entry is the space used for
> your module. ?As it is free'd lazily, each time you insert it you'll
> get different virtual addresses.
>
>> when I cat /proc/iomem I can see my entry:
>> ? ?c0000000-c0003fff : mx3_mbx_regs.0
>>
>> how can I know that the mapping is pointing me to my location?
>
> ioremap() always gives you a cookie for use with readl() et.al. or NULL.
> If it's successful, the mapping will have been created and pointing at
> the requested bus address.
>

Ok, understood, so no tool to currently view what memory is being pointed at
is available in the filesystem?

My final question to you if I could would be,
I see dynamic returns on the mapped address on 2.6.30 - 2.6.38-rc2
where on 2.6.19.2 I see the same address always gets mapped.
can I get a brief explanation on this?

I also notice that the address is within different ranges for a few kernels.
I assume it is not relevant, but I have to turn over every rock here.

> I can't see anything wrong with your code, so I suspect you're missing
> something with the hardware - maybe a clock which isn't running or an
> enable bit somewhere?
>

  I have gone the extra distance in turning off support in the working kernel
2.6.19.2, I have removed nearly everything. I am down to the gpio_port
initialization code.
and that is all I have left, I will continue to look for more running clocks.

 I cannot think of anyone who would be twiddling bits on this thing
that I have not removed.
anything is possible and I am still looking.

for now I have paused moving forward, and am trying to break it on 2.6.19.2
so far it turns out I don't need very much support to talk to this device.
any suggested ways to turn off more stuff hidden somewhere perhaps?

> I've no idea how MBX works on the MX platforms, so I can't really suggest
> anything further.
>

Me neither! and that is making this really hard to figure out. trying
to find any information is impossible I think.
being a propriety chip from PowerVR with no available information
aside from how it is connected to the iMX.

Any tips for learning how to operate this device or one like it
connected in this fashion would bring great happiness.

Thank you for your comments.

iMX31 MBX registers Porting problem

[Chris]

> ?I have gone the extra distance in turning off support in the working kernel
> 2.6.19.2, I have removed nearly everything. I am down to the gpio_port
>

iMX31 MBX registers Porting problem

[Chris]

On Tue, Feb 1, 2011 at 2:05 PM, Chris <therealbadguy@gmail.com> wrote:
>> ?I have gone the extra distance in turning off support in the working kernel
>> 2.6.19.2, I have removed nearly everything. I am down to the gpio_port
>>
>

I was finally able to get this device to stop working on 2.6.19.2

it seems that a mapping is being done to the peripheral port register.

/* Setup Peripheral Port Remap register for AVIC */
        asm("ldr r0, =0xC0000015                                \n\
         mcr p15, 0, r0, c15, c2, 4");

once this code is disabled, speaking to my device no longer returns
the expected results.
however, simply pasting this code in the new kernel does not
immediately bring me happiness.
this is from a fixup routine used in kernel 2.6.19.2, so I cloned that
logic and created a fixup routine.
I think perhaps that some other things have gotten in the way.

Are there any changes that would impact me here that anyone knows of?
my concern is now that there is not the only code enabling this
access, and I am trying to research that end of it.
I am pretty confident this is not device specific any more, but more
platform support.

I know noone is working on this device, but perhaps some experience
with this register will help.
I am amazed that all these chips are parked on the new kernel versions,
does anyone have any plans to ever work with this stuff?

I think we need this working. at least bring the support as far
forward as I can.

My Last post: Stupid fingers hit enter, so sorry guys. :(