Hi This piece of code is missing the mapping of the GPIO4's MMIO region. For your >client program to successfully access the GPIO chip you need to create a virtual >device in IO's lua configuration file. Then you attach this device to a virtual bus. In the >startup script you hand IO's capability to that virtual bus to the 'vbus' cap of your >client. Then you client can query its vbus to discover connected devices and their resources (see documentation of libvbus for reference). Then your client can map the >GPIO's chip MMIO region.
Best, Matthias.
Thank you for the explanation. I am reading through the libvbus doc right now. I'm still not fully understand but if i conclude the method to access the gpio of omap4460 in Pandaboard is : Define the res.mmio(address) in lua .dev script. Make vbus capabilities in .cfg. Make a program that can access GPIO via vbus with a client-server concept? I'm sorry i'm not fully understand about this, but what is the server of this client i am making. Also, before i your email, i already 'porting' a omap4460-chip driver in io module. and editing the .devs file so it matches with the memory of omap4460 (The two file is attached). Is my step right, and after that what should i do to be able to access it via my main program. When i try to compile the omap44x2.c it give me error like attached below. Is it because i'm not insert all of the virtual function in my program ? because actually i am not really in my goal in the mean time. I really appreciate and say biggest thanks with any of your suggestion and answer P.S : I am attaching my current main program just in case. And i still access it directly. without main2.c : http://pastebin.com/eZKqy1LE omap44x2.c : http://pastebin.com/0hupnnyR arm-omap4.devs : http://pastebin.com/pK6k7F5y error output : http://pastebin.com/s2skR3wu
On 12/30/2014 03:11 AM, Erry Pradana Darajati wrote:
Hi This piece of code is missing the mapping of the GPIO4's MMIO region. For your >client program to successfully access the GPIO chip you need to create a virtual >device in IO's lua configuration file. Then you attach this device to a virtual bus. In the >startup script you hand IO's capability to that virtual bus to the 'vbus' cap of your >client. Then you client can query its vbus to discover connected devices and their >resources (see documentation of libvbus for reference). Then your client can map the >GPIO's chip MMIO region.
Best, Matthias.
Thank you for the explanation. I am reading through the libvbus doc right now. I'm still not fully understand but if i conclude the method to access the gpio of omap4460 in Pandaboard is : Define the res.mmio(address) in lua .dev script. Make vbus capabilities in .cfg. Make a program that can access GPIO via vbus with a client-server concept? I'm sorry i'm not fully understand about this, but what is the server of this client i am making.
You don't need a client server concept here. Your program can query its vbus directly using the vbus API of libvbus.
Also, before i your email, i already 'porting' a omap4460-chip driver in io module. and editing the .devs file so it matches with the memory of omap4460 (The two file is attached). Is my step right, and after that what should i do to be able to access it via my main program. When i try to compile the omap44x2.c it give me error like attached below. Is it because i'm not insert all of the virtual function in my program ? because actually i am not really in my goal in the mean time.
You need to implement pure virtual functions in your driver. That's why the compiler errors out. Best, Matthias.
I really appreciate and say biggest thanks with any of your suggestion and answer
P.S : I am attaching my current main program just in case. And i still access it directly. without
main2.c : http://pastebin.com/eZKqy1LE omap44x2.c : http://pastebin.com/0hupnnyR arm-omap4.devs : http://pastebin.com/pK6k7F5y error output :http://pastebin.com/s2skR3wu <http://pastebin.com/s2skR3wu>
-- Matthias Lange, matthias.lange@kernkonzept.com, +49 - 351 - 41 88 86 14 Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth
Hello L4-Hackers, i noticed some wiered behavior when using l4io_request_iomem(). Have a look at this simplified code:
Server::dispatch(l4_umword_t, L4::Ipc::Iostream &ios){
ios >> v1; ios >> v2;
l4io_request_iomem(ADDR, 4, L4IO_MEM_NONCACHED, &baseaddr);
ios >> v3; ios >> v4;
}
When using l4io_request_iomem(), it kind of destroys the ioStream so that v3 and v4 get wrong values. v1 and v2 are correct and of course, i checked that v3 and v4 are correct when l4io_request_iomem() is not there. It's ok for me, since i just rearrange my code. But how does this behavior come? is it a bug, maybe? Using: l4re-snapshot-2014022818. greets, ba_f
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05.01.2015 12:38, ba_f wrote:
Hello L4-Hackers,
i noticed some wiered behavior when using l4io_request_iomem().
Have a look at this simplified code:
Server::dispatch(l4_umword_t, L4::Ipc::Iostream &ios){
ios >> v1; ios >> v2;
l4io_request_iomem(ADDR, 4, L4IO_MEM_NONCACHED, &baseaddr);
ios >> v3; ios >> v4;
}
When using l4io_request_iomem(), it kind of destroys the ioStream so that v3 and v4 get wrong values. v1 and v2 are correct and of course, i checked that v3 and v4 are correct when l4io_request_iomem() is not there.
It's ok for me, since i just rearrange my code.
But how does this behavior come? is it a bug, maybe?
This is intentional behavior and caused by the way clients and servers work. L4 IPC basically works by the sender putting data into its UTCB and then invoking a system call. The kernel then copies the data from the sender's UTCB into the receiver's UTCB and wakes up the receiver if necessary. When your server's dispatch() method is called, the arguments for the call are still within the server's UTCB area. The Iostream's stream operators allow you to retrieve these arguments and deal with them. In your code you now do an l4io request, which in turn sends an IPC message to the IO server. As explained above, for that purpose your server will now put data into its UTCB and issue an IPC system call. This overwrites any data that was previously stored in the UTCB and hence invalidates the Iostream's content. Possible solutions: * Move the l4io request to the point where you have read all data from the server request, i.e., after the "ios >> v4" line. * Alternatively, copy the whole UTCB content to an intermediate location before issuing another IPC. Hth, Bjoern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlSqfI0ACgkQP5ijxgQLUNm89QCfZYcirTmS5+aAc5NW2N0/W4la gm0AniqgVqe6lbbzBHKJLWfiKDGf2zBa =o5Bx -----END PGP SIGNATURE-----
participants (4)
-
ba_f -
Björn Döbel -
Erry Pradana Darajati -
Matthias Lange