Re: Help with RaspberryPI USB on Fiasco.OC+Genode

[Reinier M. S. <rm...@uc...>]

Hi Norman

I've been testing the USB driver in the RaspberryPI assigning priorities 
to each processes, but continue losing events. I have also tried 
changing the top value of cnt, but still the same result. I will 
continue doing some independent tests of the driver, mouse, keyboard and 
network independently.
If you have any other suggestions?

Best regards


> Hi Reinier,
>
>> I have checked the kernel warning about USB's irq, using  base_hw and
>> base_foc, and have noted (per 8000 need_trigger_sof calls):
>> (base_hw) - kicked 5, filtered aproximatelly 7600 and triggered
>> aproximatelly 250 IRQs
>> (base_foc) - kicked 3, filtered aproximatelly 7700 and triggered
>> aproximatelly 140 IRQs
>> There is a big difference in the triggered and filtered irqs. Any idea
>> or suggestion??
> SOF interrupts are filtered unless the USB driver explicitly calls
> 'schedule_sof_interrupt' and thereby propagates the next
> frame-to-deliver via the GUID scratch register to the kernel. If, for
> some reason, the USB driver is not scheduled timely enough, it might
> miss the scheduling of a frame. This can happen if the USB driver runs
> concurrently with another program that consumes a lot of CPU time. In
> such a scenario, the scheduling of the USB driver depends on the
> scheduler of the kernel. Since Fiasco.OC has a different scheduler than
> base-hw, the effect ultimately depends on the kernel. One way to work
> around it is to run the USB driver at a high priority. I.e., by
> assigning a priority of "-1" to all components except for the USB and
> timer drivers. For an example of how to use priorities in Genode, please
> have a look at the gems/run/wm.run script. Look out for the
> 'prio_levels' and 'priority' attributes.
>
> Note that this is just a guess. If the effect also occurs when not
> running a CPU hungry program besides the USB driver, the guess is most
> likely wrong.
>
>> I don't understand the use of cnt variable (need_trigger_sof). Why use
>> 160 as counter top??
> This mechanism ensures that an interrupt is delivered every now and then
> - even if the USB driver has not scheduled a frame. There are 8000 IRQs
> coming in per second. With the value of 160, an interrupt is forwarded
> to the USB driver every 20 milliseconds, which appeared to me as a
> low-enough rate to have a negligible effect on the system's performance.
>
>> I'm waiting fix this problem to upload the patch to GitHub.
>> I have tested the USB driver using two versions of Fiasco.OC, the
>> default Fiasco.OC version (https://github.com/ssumpf/foc.git) and a more
>> recently version (https://github.com/skalk/foc.git), but have the same
>> problem.
>>
>> Furthermore I have tested succesfully the support of Genode with
>> Fiasco.OC as microkernel for RaspberryPI using the autopilot tests:
>> (util_mmio,ldso,timer,lwip,rm_fault,rom_blk,tar_rom,noux,libc_ffat,libc_vfs,timed_semaphore,signal,sub_rm,python,thread_join,failsafe,noux_tool_chain_auto,
>> seoul-auto,resource_request,xml_generator,blk_cache,rump_ext2,thread,pthread,
>> netperf_lwip, netperf_lwip_usb30, netperf_lwip_bridge, netperf_lxip,
>> netperf_lxip_usb30, netperf_lxip_bridge)
>> Now I'm trying to test l4linux and other more complex examples.
>

-- 
Lic. Reinier Millo Sánchez
Centro de Estudios de Informática
Universidad Central "Marta Abreu" de Las Villas
Carretera a Camajuaní Km 5 1/2
Santa Clara, Villa Clara, Cuba
CP 54830

"antes de discutir ... respira;
   antes de hablar ... escucha;
  antes de escribir ... piensa;
   antes de herir ... siente;
  antes de rendirte ... intenta;
   antes de morir ... vive"