Setting up registers on PXA270?

Hi all

I'm currently developing a driver that will let a PXA270 running CE6
communicate with a TI floating-point DSP. I've got to the stage where
I have a dummy driver running in a debug build of CE, and I've also
used the peek and poke functions in the RedBoot bootloader to test the
interface with the hardware.

What I'm stuck on is this: Some registers in the PXA270 need changed
from their default values to make the interface work. I can't figure
out where to put the code to do this. If I put it in my driver's
XXX_Init, I suppose I need to access the registers by virtual
addresses, but I'm not sure how to do this. Is it ok to use
MmMapIoSpace() on them? I don't know if they are already controlled by
some other piece of code in the BSP that could cause conflicts.

The only alternative I can think of is to modify RedBoot so it does
the required setup before CE even loads, but I don't know if this is a
sensible thing to do.

Any thoughts much appreciated,

steve

foolblah
Tue Apr 29 04:04:00 PDT 2008

Generally, a good practice is to setup the peripheral controller, GPIOs, etc.
that you will be using in a specific driver at driver init time. This cannot
always happen, but it makes debugging easier (for you and someone else that
might look at the code someday) if you can architect it in this fashion.

What you are thinking is correct and yes you can use MmMapIoSpace() from the
DDK to map the memory space. There is a possibility that what you plan on
doing may clobber some other user of these peripherals. Do a search in the
BSP for the various peripherals that you plan on using to be sure when you
configure them you do not break something else in the process.

What controller/peripherals do you plan on utilizing?

"Steve Conner" wrote:

> Hi all
>
> I'm currently developing a driver that will let a PXA270 running CE6
> communicate with a TI floating-point DSP. I've got to the stage where
> I have a dummy driver running in a debug build of CE, and I've also
> used the peek and poke functions in the RedBoot bootloader to test the
> interface with the hardware.
>
> What I'm stuck on is this: Some registers in the PXA270 need changed
> from their default values to make the interface work. I can't figure
> out where to put the code to do this. If I put it in my driver's
> XXX_Init, I suppose I need to access the registers by virtual
> addresses, but I'm not sure how to do this. Is it ok to use
> MmMapIoSpace() on them? I don't know if they are already controlled by
> some other piece of code in the BSP that could cause conflicts.
>
> The only alternative I can think of is to modify RedBoot so it does
> the required setup before CE even loads, but I don't know if this is a
> sensible thing to do.
>
> Any thoughts much appreciated,
>
> steve
>

Steve
Tue Apr 29 06:36:56 PDT 2008

Hi FoolBlah, thanks for the reply...

I'm mapping the DSP's host port into memory using the PXA270's VLIO
feature, roughly following the guidelines in the Intel app note for
connecting an IDE hard drive.

To make this work, I need to change the direction, level and function
of a GPIO pin (enabling the relevant chip select line) and change one
of the memory controller registers to turn the VLIO on. I've tried
this through RedBoot and seen the relevant things toggling on an
oscilloscope.

My only worry is that the BSP already includes a driver for the GPIO
pins that might get in my way. If it loads before my driver, does that
mean it could stop me accessing the registers? And if it loads after
mine, it could clobber the changes that I've made.

steve


On Apr 29, 12:04 pm, FoolBlah <foolb...@discussions.microsoft.com>
wrote:
> Generally, a good practice is to setup the peripheral controller, GPIOs, etc.
> that you will be using in a specific driver at driver init time. This cannot
> always happen, but it makes debugging easier (for you and someone else that
> might look at the code someday) if you can architect it in this fashion.
>
> What you are thinking is correct and yes you can use MmMapIoSpace() from the
> DDK to map the memory space. There is a possibility that what you plan on
> doing may clobber some other user of these peripherals. Do a search in the
> BSP for the various peripherals that you plan on using to be sure when you
> configure them you do not break something else in the process.
>
> What controller/peripherals do you plan on utilizing?
>

Paul
Tue Apr 29 08:48:40 PDT 2008

Then that's a characteristics of your Platform/BSP. That's where the code
to configure the memory region where the DSP will be mapped should appear.
I'd probably do it in the bootloader myself, but that's not mandatory. You
could do it in or from a call made in OEMInit() in your platform code.

If you are *also* using GPIO to interface to this hardware, the
initialization of the direction and initial state of those pins should, to
my way of thinking, also be set up in the same place. Since all of this
stuff is completely specific to your hardware design, you'd never use the
driver anywhere else, but I prefer to have those things set in a central
location where you can document the connection between the schematic for the
hardware and what you're setting up the processor to do.

Paul T.

"Steve Conner" <connermcsteve@googlemail.com> wrote in message
news:a06a7353-5003-44ca-b6dd-a22f5aa49e4a@t54g2000hsg.googlegroups.com...
> Hi FoolBlah, thanks for the reply...
>
> I'm mapping the DSP's host port into memory using the PXA270's VLIO
> feature, roughly following the guidelines in the Intel app note for
> connecting an IDE hard drive.
>
> To make this work, I need to change the direction, level and function
> of a GPIO pin (enabling the relevant chip select line) and change one
> of the memory controller registers to turn the VLIO on. I've tried
> this through RedBoot and seen the relevant things toggling on an
> oscilloscope.
>
> My only worry is that the BSP already includes a driver for the GPIO
> pins that might get in my way. If it loads before my driver, does that
> mean it could stop me accessing the registers? And if it loads after
> mine, it could clobber the changes that I've made.
>
> steve
>
>
> On Apr 29, 12:04 pm, FoolBlah <foolb...@discussions.microsoft.com>
> wrote:
>> Generally, a good practice is to setup the peripheral controller, GPIOs,
>> etc.
>> that you will be using in a specific driver at driver init time. This
>> cannot
>> always happen, but it makes debugging easier (for you and someone else
>> that
>> might look at the code someday) if you can architect it in this fashion.
>>
>> What you are thinking is correct and yes you can use MmMapIoSpace() from
>> the
>> DDK to map the memory space. There is a possibility that what you plan
>> on
>> doing may clobber some other user of these peripherals. Do a search in
>> the
>> BSP for the various peripherals that you plan on using to be sure when
>> you
>> configure them you do not break something else in the process.
>>
>> What controller/peripherals do you plan on utilizing?
>>

Steve
Tue Apr 29 10:12:41 PDT 2008

Hi Paul, thanks for the reply, even though I'm not sure I understood
it :-(

I don't believe I own the source code to the BSP. It was developed by
a third party who charge a wad extra for the source. They gave us
stuff that we can build customized OS images from, but I don't know if
I can change the actual code. My driver currently resides as a
subproject in a Platform Builder OS Design project.

I don't use the GPIO as such, but the chip select line I need to use
is an alternate function of a GPIO pin. So I have to reprogram a few
GPIO registers to change the direction and function of this pin. That
only needs done once at startup.

Today I managed to get my driver to actually build with a call to
MmMapIoSpace() in it, which was a start, I suppose. Maybe tomorrow I
can run it and watch it crash without explanation ;-)

steve

On Apr 29, 4:48 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
> Then that's a characteristics of your Platform/BSP. That's where the code
> to configure the memory region where the DSP will be mapped should appear.
> I'd probably do it in the bootloader myself, but that's not mandatory. You
> could do it in or from a call made in OEMInit() in your platform code.
>
> If you are *also* using GPIO to interface to this hardware, the
> initialization of the direction and initial state of those pins should, to
> my way of thinking, also be set up in the same place. Since all of this
> stuff is completely specific to your hardware design, you'd never use the
> driver anywhere else, but I prefer to have those things set in a central
> location where you can document the connection between the schematic for the
> hardware and what you're setting up the processor to do.

Paul
Tue Apr 29 10:41:26 PDT 2008

Then all you can do is try to adjust the functionality (alternate function
register and direction, etc.), when your driver loads. Choosing not to have
the source for the BSP was a bad decision.

Paul T.

"Steve Conner" <connermcsteve@googlemail.com> wrote in message
news:282cb8c2-dc6b-4648-8b1c-28bc571554a2@m45g2000hsb.googlegroups.com...
> Hi Paul, thanks for the reply, even though I'm not sure I understood
> it :-(
>
> I don't believe I own the source code to the BSP. It was developed by
> a third party who charge a wad extra for the source. They gave us
> stuff that we can build customized OS images from, but I don't know if
> I can change the actual code. My driver currently resides as a
> subproject in a Platform Builder OS Design project.
>
> I don't use the GPIO as such, but the chip select line I need to use
> is an alternate function of a GPIO pin. So I have to reprogram a few
> GPIO registers to change the direction and function of this pin. That
> only needs done once at startup.
>
> Today I managed to get my driver to actually build with a call to
> MmMapIoSpace() in it, which was a start, I suppose. Maybe tomorrow I
> can run it and watch it crash without explanation ;-)
>
> steve
>
> On Apr 29, 4:48 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
> no instrument no spam DOT com> wrote:
>> Then that's a characteristics of your Platform/BSP. That's where the
>> code
>> to configure the memory region where the DSP will be mapped should
>> appear.
>> I'd probably do it in the bootloader myself, but that's not mandatory.
>> You
>> could do it in or from a call made in OEMInit() in your platform code.
>>
>> If you are *also* using GPIO to interface to this hardware, the
>> initialization of the direction and initial state of those pins should,
>> to
>> my way of thinking, also be set up in the same place. Since all of this
>> stuff is completely specific to your hardware design, you'd never use the
>> driver anywhere else, but I prefer to have those things set in a central
>> location where you can document the connection between the schematic for
>> the
>> hardware and what you're setting up the processor to do.
>

Bruce
Tue Apr 29 12:47:01 PDT 2008

A "wad extra" could save you time and money in the long run. Since you
don't have the source, you should open a discussion with the vendor about
your concerns with changing the GPIO settings. Only they have the answers
about their BSP.

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com

EuroTech Inc.
www.EuroTech.com

"Steve Conner" <connermcsteve@googlemail.com> wrote in message
news:282cb8c2-dc6b-4648-8b1c-28bc571554a2@m45g2000hsb.googlegroups.com...
> Hi Paul, thanks for the reply, even though I'm not sure I understood
> it :-(
>
> I don't believe I own the source code to the BSP. It was developed by
> a third party who charge a wad extra for the source. They gave us
> stuff that we can build customized OS images from, but I don't know if
> I can change the actual code. My driver currently resides as a
> subproject in a Platform Builder OS Design project.
>
> I don't use the GPIO as such, but the chip select line I need to use
> is an alternate function of a GPIO pin. So I have to reprogram a few
> GPIO registers to change the direction and function of this pin. That
> only needs done once at startup.
>
> Today I managed to get my driver to actually build with a call to
> MmMapIoSpace() in it, which was a start, I suppose. Maybe tomorrow I
> can run it and watch it crash without explanation ;-)
>
> steve
>
> On Apr 29, 4:48 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
> no instrument no spam DOT com> wrote:
>> Then that's a characteristics of your Platform/BSP. That's where the
>> code
>> to configure the memory region where the DSP will be mapped should
>> appear.
>> I'd probably do it in the bootloader myself, but that's not mandatory.
>> You
>> could do it in or from a call made in OEMInit() in your platform code.
>>
>> If you are *also* using GPIO to interface to this hardware, the
>> initialization of the direction and initial state of those pins should,
>> to
>> my way of thinking, also be set up in the same place. Since all of this
>> stuff is completely specific to your hardware design, you'd never use the
>> driver anywhere else, but I prefer to have those things set in a central
>> location where you can document the connection between the schematic for
>> the
>> hardware and what you're setting up the processor to do.
>

porkingson
Tue Apr 29 18:04:35 PDT 2008

> XXX_Init, I suppose I need to access the registers by virtual
> addresses, but I'm not sure how to do this. Is it ok to use
> MmMapIoSpace() on them? I don't know if they are already controlled by
> some other piece of code in the BSP that could cause conflicts.
>

Using MmMapIoSpace:

- It's OK to map the same physical memory to the virtual memory of
different processes at the same time, if that's what you're worried
about. You won't get a conflict because the GPIO driver has the same
memory mapped, but you WILL get a conflict if the GPIO driver happens
to be toggling your pin. Said conflict will be expressed in the form
of your device not working. You should check the documentation for
your BSP or call the people you bought it from and make sure that GPIO
is available

- Make sure your driver is running in kernel space and not user
space. User mode drivers can't access physical memory directly, as I
understand it

> The only alternative I can think of is to modify RedBoot so it does
> the required setup before CE even loads, but I don't know if this is a
> sensible thing to do.

I agree with FoolBlah in that you should set your peripheral up in the
driver

Steve
Thu May 15 03:07:32 PDT 2008

Hi all

Just a follow-up on this, I've got it working well, thanks to all who
helped out!

I contacted the BSP developers, and they said just to go ahead and map
the registers and poke them. So I did and to cut a long story short,
it worked. The driver has been running overnight in a test harness
with 5-10MByte/sec transfer rates and no errors.

Steve <- off to play with my new DSP1: