Re: [seL4] IOMUX on iMX6 conflict with libethdrivers
Hey Fabrizio?, I'm sorry we took so long to get back to you: The underlying problem here is that we haven't yet finished defining and implementing a driver framework for our userspace code, so in order to satisfy dependencies, we began stuffing them into the io_ops struct. So since lots of devices depend on an initialized mux driver, what you see here is the result of that, unfortunately -- the good news is that we're currently defining a driver framework internally (https://docs.sel4.systems/seL4DriverAPI/ChildEnumeration.html is one of the draft pages of documentation -- but none of this is finalized) over the course of this year. What I'd recommend is that you use the helper function, mux_sys_valid() in mux.h (https://github.com/seL4/util_libs/blob/master/libplatsupport/arch_include/ar...) inside of the ethernet driver, and map the whole 16K range inside of the IO-Ops initializer -- essentially what's going on there is that there's a dependency on the mux driver that's satisfied by the IO-Ops object. Thanks very much for your patience,? and this sort of thing should be cleaned up soon. Yours truly, -- Kofi Doku Atuah Kernel engineer DATA61 | CSIRO
Kofi,
Thanks for your reply.
Ok, I have implemented what I think is a clean fix until the new framework
will be ready.
To avoid the libethdrivers to directly accessing the 'priv' field of the
mux_sys->priv, I have added one more function to the mux_sys API:
mux_sys_get_vaddr() that simply returns the vaddr of the mapped MUXC. I
have then extended the size of the area mapped to include the entire 16Kb
of the MUXC.
Then the libethdriver now uses the mux_sys_valid to check if the mux is
available, and if so, used it to retrieve the vaddr of the MUXC. If not it
proceed by privately mapping & unmapping the MUX when it's done.
My changes are in pull request #16:
https://github.com/seL4/util_libs/pull/16
I have tested it on my build and it works.
Regards,
Fabrizio
On Wed, Jul 4, 2018 at 9:38 PM,
Hey Fabrizio, I'm sorry we took so long to get back to you:
The underlying problem here is that we haven't yet finished defining and implementing a driver framework for our userspace code, so in order to satisfy dependencies, we began stuffing them into the io_ops struct. So since lots of devices depend on an initialized mux driver, what you see here is the result of that, unfortunately -- the good news is that we're currently defining a driver framework internally ( https://docs.sel4.systems/seL4DriverAPI/ChildEnumeration.html is one of the draft pages of documentation -- but none of this is finalized) over the course of this year.
What I'd recommend is that you use the helper function, mux_sys_valid() in mux.h (https://github.com/seL4/util_libs/blob/master/ libplatsupport/arch_include/arm/platsupport/mux.h#L35) inside of the ethernet driver, and map the whole 16K range inside of the IO-Ops initializer -- essentially what's going on there is that there's a dependency on the mux driver that's satisfied by the IO-Ops object.
Thanks very much for your patience, and this sort of thing should be cleaned up soon.
Yours truly,
-- Kofi Doku Atuah Kernel engineer DATA61 | CSIRO
_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
?Thanks, Fabrizio, Appreciate your understanding and I'll look into the PR :) -- Kofi Doku Atuah Kernel engineer DATA61 | CSIRO
Kofi,
I have added one more fix to that PR. It's related to an issue with the
UART1 of the IMX6 that does not receive data by default because the
internal MUX does not route the signal from the outside pin to the UART1 RX.
Check the changeset in that PR and let me know if there are any problems
(as I have added one more functionality to the imx6_mux_feature_enable
function).
Regards,
Fabrizio
On Thu, Jul 5, 2018 at 8:35 PM
Thanks, Fabrizio,
Appreciate your understanding and I'll look into the PR :)
-- Kofi Doku Atuah Kernel engineer DATA61 | CSIRO
_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
participants (2)
-
Fabrizio Bertocci
-
Kofidoku.Atuah@data61.csiro.au