Hi stefan,
Thanks a lot in Advance,
We are trying to debug the " Failed to communicate Thread Event ". And we found that Platform is not getting Initialized, we are facing Problem in the Platform constructor located in file : base-hw/src/coe/platform.cc
In the Platform () constructor
Rom_module * rom_module = new (core_mem_alloc()) Rom_module(header->base, header->size, (const char*)header->name);
is not getting executed(giving page fault) . Do you know what could be the problem ?
Regards
Chirag Garg IIT Madras , Rise Lab
Hi,
On 07/28/2014 11:28 AM, chirag garg wrote:
Hi stefan,
Thanks a lot in Advance,
We are trying to debug the " Failed to communicate Thread Event ". And we found that Platform is not getting Initialized, we are facing Problem in the Platform constructor located in file : base-hw/src/coe/platform.cc
In the Platform () constructor
Rom_module * rom_module = new (core_mem_alloc()) Rom_module(header->base, header->size, (const char*)header->name);
is not getting executed(giving page fault) . Do you know what could be the problem ?
Do you've inserted the right existent RAM regions within your Platform::_ram_regions definitions? If you added incorrect RAM regions the "core_mem_alloc()" allocator of core will insert invalid page table entries in kernel/core's page table, and any access to the memory of the new Rom_module (returned by core_mem_alloc()) will fault.
But it's just guessing. Again, it is up to you to investigate what exact memory access is responsible for the fault.
Regards Stefan
Regards
Chirag Garg IIT Madras , Rise Lab
Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Stefan, I am working along with Chirag to port Genode on imx6.
We inserted the existing RAM regions in Platform::_ram_regions.( We rechecked it with linux kernel source code for imx6) But still we are getting page fault on every access to new Rom_module.
I tried to track the memory allocation what I understood is, In map_local() call, when inserting into page tables in "_insert_second_level()" function in short_translation_table.h file of base-hw, slab->phys_addr() and slab->virt_addr() return 0 after kernel initialization. So it creates a new page table and inserting into it. Inserting the same values(phys:10000000, virt:1000) as arguments of map_local() function in platform.cc. When I print the address of new page table created, I found that it is in the range of Program Image.(address of pt is 10159000, and program image range is (10001000-10189fa4).
I wonder if the memory allotted is clashing with program memory. Or, Can it be the issue with MMDC controller of imx6? Because no other board in base-hw uses MMDC controller, do we need to implement the interface for MMDC in imx6?
Thanks and Regards
Praveen, IIT Madras
On Tue, Jul 29, 2014 at 6:43 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 07/28/2014 11:28 AM, chirag garg wrote:
Hi stefan,
Thanks a lot in Advance,
We are trying to debug the " Failed to communicate Thread Event ". And we found that Platform is not getting Initialized, we are facing Problem in the Platform constructor located in file : base-hw/src/coe/platform.cc
In the Platform () constructor
Rom_module * rom_module = new (core_mem_alloc()) Rom_module(header->base, header->size, (const char*)header->name);
is not getting executed(giving page fault) . Do you know what could be
the
problem ?
Do you've inserted the right existent RAM regions within your Platform::_ram_regions definitions? If you added incorrect RAM regions the "core_mem_alloc()" allocator of core will insert invalid page table entries in kernel/core's page table, and any access to the memory of the new Rom_module (returned by core_mem_alloc()) will fault.
But it's just guessing. Again, it is up to you to investigate what exact memory access is responsible for the fault.
Regards Stefan
Regards
Chirag Garg IIT Madras , Rise Lab
Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.cl... _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Praveen, Stefan isn't online these days. 'Genode::map_local()' uses the 'Kernel::core_pd()->platform_pd()->page_slab()' as backing store. This allocator is of the type 'Genode::Page_slab' as defined in 'base-hw/src/core/include/page_slab.h'. The class contains a member 'Slab_block _initial_sb' which is used for the first couple of allocations (especially for the allocation of the second slab block). Furthermore the page slab of the core PD is created via the 'unmanaged_singleton' utility in 'base-hw/src/core/kernel/kernel.cc'. Thus it should be located in the BSS. That said, it might be normal that you're observing a page-table base inside the program image. Is 0x10159000 inside your BSS? You can check this via 'genode-arm-objdump' or instrument the Page_slab::alloc method to check wether it uses the initial block for this page table.
Cheers Martin
On 08.08.2014 09:14, Praveen B wrote:
Hi Stefan, I am working along with Chirag to port Genode on imx6.
We inserted the existing RAM regions in Platform::_ram_regions.( We rechecked it with linux kernel source code for imx6) But still we are getting page fault on every access to new Rom_module.
I tried to track the memory allocation what I understood is, In map_local() call, when inserting into page tables in "_insert_second_level()" function in short_translation_table.h file of base-hw, slab->phys_addr() and slab->virt_addr() return 0 after kernel initialization. So it creates a new page table and inserting into it. Inserting the same values(phys:10000000, virt:1000) as arguments of map_local() function in platform.cc. When I print the address of new page table created, I found that it is in the range of Program Image.(address of pt is 10159000, and program image range is (10001000-10189fa4).
I wonder if the memory allotted is clashing with program memory. Or, Can it be the issue with MMDC controller of imx6? Because no other board in base-hw uses MMDC controller, do we need to implement the interface for MMDC in imx6?
Thanks and Regards
Praveen, IIT Madras
On Tue, Jul 29, 2014 at 6:43 PM, Stefan Kalkowski <stefan.kalkowski@...1... mailto:stefan.kalkowski@...1...> wrote:
Hi, On 07/28/2014 11:28 AM, chirag garg wrote: > Hi stefan, > > Thanks a lot in Advance, > > We are trying to debug the " Failed to communicate Thread Event ". And we > found that Platform is not getting Initialized, we are facing Problem in > the Platform constructor located in file : base-hw/src/coe/platform.cc > > In the Platform () constructor > > Rom_module * rom_module = new (core_mem_alloc()) > Rom_module(header->base, header->size, (const > char*)header->name); > > is not getting executed(giving page fault) . Do you know what could be the > problem ? Do you've inserted the right existent RAM regions within your Platform::_ram_regions definitions? If you added incorrect RAM regions the "core_mem_alloc()" allocator of core will insert invalid page table entries in kernel/core's page table, and any access to the memory of the new Rom_module (returned by core_mem_alloc()) will fault. But it's just guessing. Again, it is up to you to investigate what exact memory access is responsible for the fault. Regards Stefan > > > Regards > > Chirag Garg > IIT Madras , Rise Lab > > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > > > > _______________________________________________ > genode-main mailing list > genode-main@lists.sourceforge.net <mailto:genode-main@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/ ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net <mailto:genode-main@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/genode-main
Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello,
I read the Bastei Design PDF and have a question regarding the information flow.
On page 5 it is stated: “When a parent calls the session function of the root interface of a server child, the server creates a new client session and returns the corresponding client_session capability. This session capability provides the actual service-specific interface. The parent can use it directly or it may pass it to other processes, in particular to another child that requested the session.“
If i understand it correctly:
Service A is pronounces to “init”. “Init” has the capability to Service A (e.g. AHCI). Program B is started. If Program B requests a service (e.g. read something fromAHCI), Init looks up its root list and notifies A that the service is requested, A creates a new capability and passes it to “Init”, which passes the capability further to B.
Is this correct? And does this happen always?
Can a capability then be revoked? E.g. Program B does something which is not wanted and therefore the already given capability will be removed?
Best regards Wolfgang
Hi Wolfgang,
Service A is pronounces to “init”. “Init” has the capability to Service A (e.g. AHCI). Program B is started. If Program B requests a service (e.g. read something fromAHCI), Init looks up its root list and notifies A that the service is requested, A creates a new capability and passes it to “Init”, which passes the capability further to B.
Is this correct? And does this happen always?
yes and yes.
Can a capability then be revoked? E.g. Program B does something which is not wanted and therefore the already given capability will be removed?
Since the common parent of A and B possesses both the root capability of service A and the session capability created for the client B, the parent can, at any time, close the session at service A by invoking the 'Root::close' function with the session capability as argument. (note however that the init process has no such policy) When the service A destructs the session (the 'Rpc_object') all capabilities that refer the 'Rpc_object' become invalid. The client is no longer able to reach the service using the now invalidated session capability.
Hence, in principle, a common parent is able to break the relationship between a client and a server by closing the corresponding sessions. In practice, a partial revocation of access rights to once-established sessions, is not common. "Revocation" should better be done by destructing a subsystem altogether and starting a new one.
Best regards Norman
Hi,
On Mon, Aug 11, 2014 at 03:52:53PM +0200, Norman Feske wrote:
Hi Wolfgang,
Service A is pronounces to “init”. “Init” has the capability to Service A (e.g. AHCI). Program B is started. If Program B requests a service (e.g. read something fromAHCI), Init looks up its root list and notifies A that the service is requested, A creates a new capability and passes it to “Init”, which passes the capability further to B.
Is this correct? And does this happen always?
yes and yes.
Please forgive me that I interfere, but reading your post I'd like to substantiate Norman's answer a bit. The answer to your second question depends on the concrete use case. The mediation of session-creation requests always happens as there is no way around it. But once the session is created, communication happens directly between server and client without interposition of the parent. So your example of "read something from AHCI" has two phases:
1. Session creation with mediation by the parent creates session capability 2. Client calls the read function via the session capability directly at the server.
Regards
Hi Martin,
Sorry I could not reply soon as I've been away for a while. And Thank you for the explanation.
The address 0x10159000 is not present in BSS. BSS range is 0x10070000 to 0x10112fa4.
I've checked it and everything is going fine until first Rom_module is created. After allocation, we are getting page fault in the constructor call of Avl_string_base, the class from which Rom_module is derived. The address of page fault is 0x1008 same as in the case of Bob working on Beaglebone. And our code was also working till 13.11.
I guess our problem is also related to MMU, which is MMDC for imx6 as I mentioned in my previous mail. We will pull the current branch and try if it works, as you suggested for Bob.
Thanks and Regards
Praveen IIT Madras.
On Mon, Aug 11, 2014 at 4:43 PM, Martin Stein <martin.stein@...1...> wrote:
Hi Praveen, Stefan isn't online these days. 'Genode::map_local()' uses the 'Kernel::core_pd()->platform_pd()->page_slab()' as backing store. This allocator is of the type 'Genode::Page_slab' as defined in 'base-hw/src/core/include/page_slab.h'. The class contains a member 'Slab_block _initial_sb' which is used for the first couple of allocations (especially for the allocation of the second slab block). Furthermore the page slab of the core PD is created via the 'unmanaged_singleton' utility in 'base-hw/src/core/kernel/kernel.cc'. Thus it should be located in the BSS. That said, it might be normal that you're observing a page-table base inside the program image. Is 0x10159000 inside your BSS? You can check this via 'genode-arm-objdump' or instrument the Page_slab::alloc method to check wether it uses the initial block for this page table.
Cheers Martin
On 08.08.2014 09:14, Praveen B wrote:
Hi Stefan, I am working along with Chirag to port Genode on imx6.
We inserted the existing RAM regions in Platform::_ram_regions.( We rechecked it with linux kernel source code for imx6) But still we are getting page fault on every access to new Rom_module.
I tried to track the memory allocation what I understood is, In map_local() call, when inserting into page tables in "_insert_second_level()" function in short_translation_table.h file of base-hw, slab->phys_addr() and slab->virt_addr() return 0 after kernel initialization. So it creates a new page table and inserting into it. Inserting the same values(phys:10000000, virt:1000) as arguments of map_local() function in platform.cc. When I print the address of new page table created, I found that it is in the range of Program Image.(address of pt is 10159000, and program image range is (10001000-10189fa4).
I wonder if the memory allotted is clashing with program memory. Or, Can it be the issue with MMDC controller of imx6? Because no other board in base-hw uses MMDC controller, do we need to implement the interface for MMDC in imx6?
Thanks and Regards
Praveen, IIT Madras
On Tue, Jul 29, 2014 at 6:43 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 07/28/2014 11:28 AM, chirag garg wrote:
Hi stefan,
Thanks a lot in Advance,
We are trying to debug the " Failed to communicate Thread Event ". And
we
found that Platform is not getting Initialized, we are facing Problem in the Platform constructor located in file : base-hw/src/coe/platform.cc
In the Platform () constructor
Rom_module * rom_module = new (core_mem_alloc()) Rom_module(header->base, header->size, (const char*)header->name);
is not getting executed(giving page fault) . Do you know what could be
the
problem ?
Do you've inserted the right existent RAM regions within your Platform::_ram_regions definitions? If you added incorrect RAM regions the "core_mem_alloc()" allocator of core will insert invalid page table entries in kernel/core's page table, and any access to the memory of the new Rom_module (returned by core_mem_alloc()) will fault.
But it's just guessing. Again, it is up to you to investigate what exact memory access is responsible for the fault.
Regards Stefan
Regards
Chirag Garg IIT Madras , Rise Lab
Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.cl... _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now.http://p.sf.net/sfu/bds
genode-main mailing listgenode-main@...220...://lists.sourceforge.net/lists/listinfo/genode-main
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Praveen,
On 18.08.2014 07:00, Praveen B wrote:
We will pull the current branch and try if it works, as you suggested for Bob.
I think that would be a good idea. Be aware that further wide-ranging clean-up commits, especially "hw: re-organize file structure", entered the master branch recently. If you have any questions regarding the concept behind these changes, don't hesitate to ask.
Martin
Martin,
Thank you very much. For the latest code we can start genode successfully, after adding appropriate changes for imx6.
But there was one issue, imx53 and imx31 uses uart 1 and imx6 uses uart2 as mentioned by Aditya here, http://sourceforge.net/p/genode/mailman/message/31897976/ .
In the latest code imx53 and imx31 uses serial.h from imx folder in base-hw/src/core/include/spec folder. Instead of using this serial.h, we modified serial.h to use uart 2 and kept the file in imx6 folder and changed the makefile accordingly. Now it is working.
Thank you
Praveen IIT Madras.
On Mon, Aug 18, 2014 at 12:02 PM, Martin Stein <martin.stein@...1...
wrote:
Hi Praveen,
On 18.08.2014 07:00, Praveen B wrote:
We will pull the current branch and try if it works, as you suggested for Bob.
I think that would be a good idea. Be aware that further wide-ranging clean-up commits, especially "hw: re-organize file structure", entered the master branch recently. If you have any questions regarding the concept behind these changes, don't hesitate to ask.
Martin
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Praveen,
Thank you very much. For the latest code we can start genode successfully, after adding appropriate changes for imx6.
Cool :-)
But there was one issue, imx53 and imx31 uses uart 1 and imx6 uses uart2 as mentioned by Aditya here, http://sourceforge.net/p/genode/mailman/message/31897976/ .
In the latest code imx53 and imx31 uses serial.h from imx folder in base-hw/src/core/include/spec folder. Instead of using this serial.h, we modified serial.h to use uart 2 and kept the file in imx6 folder and changed the makefile accordingly. Now it is working.
That's right. I merged this back end in 'imx' as our current main line doesn't support any imx platform that needs another implementation. However, the 'imx6/serial.h' solution is fine if you're planning to bring your imx6 support to main line someday.
Cheers, Martin
-
unknown＠example.com -
chirag garg -
Christian Helmuth -
Martin Stein -
Norman Feske -
Praveen B -
Stefan Kalkowski