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) < [email protected]> 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/imx6.c#L370 > > _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
