Thanks Damon, I see that the driver has since been added to util_libs and I was just wondering about some errors I am getting when trying to use it. I made a quick hello world app and set up the camkes file as such: Hello World! Assertion failed: !"sys_socket not implemented" (/home/nkem/Test/projects/camkes-tool/libsel4camkes/src/sys_socket.c: camkes_sys_socket: 42) dwmac.687000 Waiting for PHY auto negotiation to complete.......... done Speed: 1000, full duplex Assertion failed: buf (/home/nkem/Test/projects/global-components/components/Ethdriver/src/ethdriver.c: server_init: 388) On Thu, 28 Jan 2021 at 01:19, Lee, Damon (Data61, Eveleigh) < Damon.Lee@data61.csiro.au> wrote:
Hi Nkem,
Just to clarify, a modification I made was calling the ethif_init function
ethernet.c file[1] and passing some parameters (base_addr,mac,
dma_ops,ethif_recv_callback). Currently, dma_ops and ethif_recv_callback
contain null values and I'm not too sure what I need to initialise them as.
The issue is more clear now, the issue lies with the fact that the Ethernet
driver structure layout is different from the expected layout in libethdrivers.
For the `dma_ops` case, this shouldn't be NULL, and depending on what CAmkES
application (e.g. picoserver) you are using, this will be handled automatically
for you. Otherwise, you can call `camkes_io_ops` and then you can access the
underlying `dma_ops` structure inside the `ps_io_ops_t` pointer.
As for the `ethif_recv_callback` this shouldn't be there, the libethdrivers
drivers instead require these functions to be filled in [1]. What I'm trying to
say here is that the model of the AOS Ethernet driver is different from those
expected in libethdrivers, and you would need to modify the AOS Ethernet driver
quite heavily so that it matches the model in libethdrivers.
Also, please could you clarify how I am meant to modify the callbacks so
that it gets the correct registers and IRQs from the DTS.
The callbacks are called like a lambda in a 'map' function like in other
languages. It's given the current IRQ or register information each time it's
called and the user can choose to take that information and use it to allocate
hardware resources. So in the case of the C2, looking at the kernel DTS for it
(kernel/tools/dts/odroidc2.dts), the Ethernet node (/soc/ethernet@c9410000)
contains one interrupt entry and two register entries. The interrupt entry is
simple, you could simple call `ps_irq_register` on the IRQ information in the
first invocation. As for the registers, you would need to call `ps_mem_map`
twice, once for each time the callback is called.
If aren't in a rush to solve these issues, the team is considering porting over
the AOS Ethernet driver for the C2 over to libethdrivers in the next few days.
Though this would take a few days to do, review, and have it pushed out to
upstream.
Hope this helps,
Damon
[1] https://github.com/seL4/util_libs/blob/master/libethdrivers/src/plat/imx6/im...