16.05 custom kernel call fails to get session capability. - users

28 Jun 2016


      Hi,
I'm moving from release 15.11 to 16.05 on base-hw and am having a 
"service denied" issue when trying to get a connection to a custom 
service I created to handle pin muxing on TI Sitara processors. In this 
family of processors, access to a "Control Module" is need to enable 
subsystems, set up clock frequencies, and set the mode for gpio pins 
which have multiple functions dependent upon the mode they are set to. 
Write access to the Control Module is only allowed in a privileged mode 
so I had to create custom kernel calls to access the appropriate SoC 
registers. I did this in release 14.05 by adding the code for 
unrestricted kernel calls to base-hw and it has been working without 
issue through various releases until I stared to move to 16.05.
The log output I'm getting is:
  Starting kernel ...
kernel initialized
Genode 16.05 <local changes>
int main(): --- create local services ---
int main(): --- start init ---
int main(): transferred 503 MB to init
int main(): --- init created, waiting for exit condition ---
[init] Could not open ROM session for module "ld.lib.so"
[init -> ctrl_module] ---437x Control Module Server : Setting Pin Muxes---
[init -> ctrl_module] pin mux capability
[init -> timer] Maximum timeout 1717986000 us
[init -> timer] --- am437x timer driver ---
[init -> 437x_platform_client] --- 437x platform being configured --
[init -> ctrl_module] Uncaught exception of type 
'Genode::Parent::Service_denied'
[init -> ctrl_module] Warning: abort called - thread: ep
[init] virtual void Genode::Child_policy::exit(int): child "ctrl_module" 
exited w
ith exit value 1
[init -> 437x_platform_client] Enabled dmtimer 3 freq = 1
[init -> 437x_platform_client] Enabled dmtimer 4 freq = 1
....(other messages unrelated to the issue follow)
The uncaught exception is being generated in my "pinmux_session" 
connection code when a capability for a session is requested, as shown 
the following in the following code snippet from pinmux_connection.h
namespace Genode { struct Pinmux_connection; }
struct Genode::Pinmux_connection : Connection<Pinmux_session>, 
Pinmux_session_client
{
       /**
      * Issue session request
      *
      * \noapi
      */
     Capability<Pinmux_session> _session(Parent &parent, char const 
*label, long priority,
                                             unsigned long affinity)
     {
         Genode::printf("pin mux capability\n");
         return***/session(parent,/**/
/**/                       "priority=0x%lx, affinity=0x%lx, 
ram_quota=16K, label="%s"",/**/
/**/                       priority, affinity, label); (exception occurs 
here)/*
     }
/**
         * Constructor
         *
         * \param label     initial session label
         * \param priority  designated priority of the Pinmux
         * \param affinity  which physical CPU the VM should run on top of
     */
     Pinmux_connection(Genode::Env &env, const char *label = "",
                       long priority = Cpu_session::DEFAULT_PRIORITY,
                   unsigned long affinity = 0)
         : Connection<Pinmux_session>(
             env, _session(env.parent(), label, priority, affinity)),
           Pinmux_session_client(cap()) { }
/**
      * Constructor
      *
      * \noapi
      * \deprecated  Use the constructor with 'Env &' as first
      *              argument instead
      */
     Pinmux_connection(const char *label = "",
                   long priority = Cpu_session::DEFAULT_PRIORITY,
                   unsigned long affinity = 0)
     :
Connection<Pinmux_session>(_session(*env()->parent(), label, priority, 
affinity)),
         Pinmux_session_client(cap())
     { Genode::printf("ctrl mod connection\n");}
};
This code differs from the 15.11 code in that the request for a session 
now requires a "parent" argument in 16.05. Looking at similar kernel 
call codes like the vm calls, my changes to my custom calls  for 16.05 
appear to be correct.
I can see in the kernel code (parent.h) where the exception is occurring 
but I have no clue as to why it occurs. Any hints would be greatly 
appreciated.
Thanks,
Bob Stewart