On a TI am3359 processor (Beaglebone Black) I'm attempting to attempting to control the GPIO pin-muxing through the Control subsystem registers which start at 0x4e100000. I can read and write to the GPIO0 through GPIO3 registers correctly through MMIO after attaching the device memory, but when I try to write to any of the pin mux registers nothing is written and no errors are output.
The code I've written to set up pin muxing resides in a gpio driver which is a modified version of an am 33xx gpio driver I pulled from the ksyslabs.org repository.
With verbosity turned on, I see the that the pin mux registers are attached to local memory: /Genode::Io_mem_session_component::Dataspace_attr Genode::Io_mem_session_component::_prepare_io_mem(const char*, Genode::Range_allocator*): I/O mem [44e10000,44e11000)// //[init -> gpio_drv] GPIO_control base is 0x44e10000 local is 0x4000/
I write a value of 5 to the register offset 0x800 into the Control dataspace: /[init -> gpio_drv] mmio write 0x4800: 0x00000005// //[init -> gpio_drv] void Omap_driver::set_pin_controls(int, int, int): B=1, P=0, Mode=5, Input=0, Offset=0/
In jdb I see that the value at 0x4800 has not changed after apparently writing 5 to it.
I believe I've set up the IO memory mapping correctly, the values read from the pin muxing registers look correct, and the GPIO subsystem appears to be set up correctly as I can turn on and off some LEDs.
Is there something I need to do to enable writing to the memory region containing the Control registers?
Thanks for any help.
Bob Stewart
Hello Bob,
On Thu, Oct 24, 2013 at 08:57:08AM -0400, Bob Stewart wrote:
I write a value of 5 to the register offset 0x800 into the Control dataspace: /[init -> gpio_drv] mmio write 0x4800: 0x00000005// //[init -> gpio_drv] void Omap_driver::set_pin_controls(int, int, int): B=1, P=0, Mode=5, Input=0, Offset=0/
In jdb I see that the value at 0x4800 has not changed after apparently writing 5 to it.
It's just a guess, but are you sure that reading the register should gain the value write to it before? Often, the semantics of device registers are different from this assumption.
Greets
Thanks for the reply Christian. If I'm writing to a local memory location why would the change in value not show in the debugger, even if that location is memory mapped to a hardware register?
Bob Stewart
Sent with AquaMail for Android http://www.aqua-mail.com
On October 24, 2013 9:31:37 AM Christian Helmuth <christian.helmuth@...1...> wrote:
Hello Bob,
On Thu, Oct 24, 2013 at 08:57:08AM -0400, Bob Stewart wrote:
I write a value of 5 to the register offset 0x800 into the Control dataspace: /[init -> gpio_drv] mmio write 0x4800: 0x00000005// //[init -> gpio_drv] void Omap_driver::set_pin_controls(int, int, int): B=1, P=0, Mode=5, Input=0, Offset=0/ In jdb I see that the value at 0x4800 has not changed after apparently writing 5 to it.
It's just a guess, but are you sure that reading the register should gain the value write to it before? Often, the semantics of device registers are different from this assumption.
Greets
Christian Helmuth Genode Labs
http://www.genode-labs.com/ · http://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clk... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hej,
On Thu, Oct 24, 2013 at 11:20:09AM -0400, Bob Stewart wrote:
Thanks for the reply Christian. If I'm writing to a local memory location why would the change in value not show in the debugger, even if that location is memory mapped to a hardware register?
From my experience this heavily depends on the device behind the
"memory location" as this is not RAM. The device may, for example, interpret bit 0 set on write as "clear register", which would gain you 0x0 on writing 0x1. Note, it was just a plain guess as I do not know your platform or device very well.
BTW, which Ksyslabs repository and branch did you base your work on? Does it already include a GPIO driver for your BeagleBone?
Regards
Understand what you mean now, Christian. The registers I'm working with are read by the processor to determine what mode the gpio pins will run in (amongst other things), so once set they should be readable. I'll do some testing with hardware to see if the mode changes are really taking effect. On this hardware there are eight modes per pin and, depending on the mode, the pin might simply be digital level or it might output a PWM signal. So mode setting is important.
I pulled the "decaprox" branch from ksyslabs repository. That branch has a driver for am33xx gpio. I moved the changes for the am33xx gpio into my local copy of 13.08 along with test stubs. All that worked ok and I could get gpio pins to function as I wanted. The gpio driver does not however have functionality to set the pin modes and one is stuck with pins in the mode the boot rom sets.
Bob
Sent with AquaMail for Android http://www.aqua-mail.com
On October 24, 2013 11:30:46 AM Christian Helmuth <christian.helmuth@...1...> wrote:
Hej,
On Thu, Oct 24, 2013 at 11:20:09AM -0400, Bob Stewart wrote:
Thanks for the reply Christian. If I'm writing to a local memory location
why would the change in value not show in the debugger, even if that location is memory mapped to a hardware register?
From my experience this heavily depends on the device behind the "memory location" as this is not RAM. The device may, for example, interpret bit 0 set on write as "clear register", which would gain you 0x0 on writing 0x1. Note, it was just a plain guess as I do not know your platform or device very well.
BTW, which Ksyslabs repository and branch did you base your work on? Does it already include a GPIO driver for your BeagleBone?
Regards
Christian Helmuth Genode Labs
http://www.genode-labs.com/ · http://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clk... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
I finally got back to looking at this issue and re-read the TI processor document regarding the "Control Module" in the am3359. Apparently the registers in the Control Module can only be written in processor privileged mode and my process would be running in user mode. How can a mechanism be created in Genode to write to such registers?
Bob Stewart
Sent with AquaMail for Android http://www.aqua-mail.com
On October 24, 2013 12:20:16 PM Bob Stewart <robjsstewart@...196...> wrote:
Understand what you mean now, Christian. The registers I'm working with are read by the processor to determine what mode the gpio pins will run in (amongst other things), so once set they should be readable. I'll do some testing with hardware to see if the mode changes are really taking effect. On this hardware there are eight modes per pin and, depending on the mode, the pin might simply be digital level or it might output a PWM signal. So mode setting is important.
I pulled the "decaprox" branch from ksyslabs repository. That branch has a driver for am33xx gpio. I moved the changes for the am33xx gpio into my local copy of 13.08 along with test stubs. All that worked ok and I could get gpio pins to function as I wanted. The gpio driver does not however have functionality to set the pin modes and one is stuck with pins in the mode the boot rom sets.
Bob
On October 24, 2013 11:30:46 AM Christian Helmuth <christian.helmuth@...1...> wrote:
Hej,
On Thu, Oct 24, 2013 at 11:20:09AM -0400, Bob Stewart wrote:
Thanks for the reply Christian. If I'm writing to a local memory
location why would the change in value not show in the debugger, even if that location is memory mapped to a hardware register?
From my experience this heavily depends on the device behind the "memory location" as this is not RAM. The device may, for example, interpret bit 0 set on write as "clear register", which would gain you 0x0 on writing 0x1. Note, it was just a plain guess as I do not know your platform or device very well.
BTW, which Ksyslabs repository and branch did you base your work on? Does it already include a GPIO driver for your BeagleBone?
Regards -- Christian Helmuth Genode Labs
http://www.genode-labs.com/ · http://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clk... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Bob,
On Thu, Oct 31, 2013 at 07:44:09PM -0400, Bob Stewart wrote:
I finally got back to looking at this issue and re-read the TI processor document regarding the "Control Module" in the am3359. Apparently the registers in the Control Module can only be written in processor privileged mode and my process would be running in user mode. How can a mechanism be created in Genode to write to such registers?
That's unfortunate. So far, we had not to enable an SoC with the described behavior. On i.MX31, we side stepped this by reconfiguring the AHB-to-IP bus interface properly. In my opinion, an appropriate solution for the issue is a kernel interface for the purpose of peek/poke on MMIO regions. The interface should be reserved to a privileged component, i.e. core. Further, the Io_mem service could be extended by peek/poke RPC methods, which can be invoked by the actual driver. If the peek/poke service should be subject to a policy decision, the Io_mem session could be extended by a parameter enabling the interface.
If you're using base-foc, you may have a look at the Thread::handle_slow_trap method in the Fiasco.OC sources to add the kernel interface for peek/poke. In the past, the original Fiasco kernel (base-fiasco/contrib) provided an interface to execute, e.g., wrmsr on x86 with special trap handling. On base-hw, further extensions to MMIO region handling in the platform-specific part of core would be needed.
Regards
-
Bob Stewart -
Christian Helmuth