On Tuesday, 23 May 2023 17:32:16 CEST Paul Boddie wrote: > > But the DMA domain is still not found when assigning the space. I did wonder > whether I might need to create a device to hold the DMA domain resource, > but my attempt to implement this failed: > > for resource in hw:resources() do > print("resource name=" .. resource:id()) > if resource:id() == 1145130308 then > device = Io.Vi.System_bus() > device:add_resource(resource) > bus:add_child(device) > end > end
Well, this proved to be the wrong track, as I imagined, but the following helped me onto the right track: > Here, Io crashes... > > IO | L4Re[rm]: unhandled read page fault at 0x31 pc=0x102aba0 > IO | L4Re: rom/io: Unhandled exception: PC=0x102aba0 PFA=0x30 > LdrFlgs=0x0 > > ...which is the following line in Dma_domain::add_to_group: > > if (!_v_domain && !g->_set) > > I imagine that I am making this harder than it should be, though. I already suspected that I needed a DMA domain inside an actual device, as opposed to the system bus, so that the code in Io would be able to find the resource. Obviously, the attempt above did not achieve this, indicating that there is more involved in the initialisation than simply "copying" a resource into a suitable location. I then discovered that the Hw_device_DF_dma_supported property flag would allow a search using the vbus to yield a DMA domain resource with a valid identifier and for Io to find this by itself when assigning a DMA space to a domain. Although the SoC I am using has no notion of device-specific DMA domains, conceptually it makes sense to associate DMA with the peripheral I am trying to configure, so I introduced the following to my LCD controller device: LCD = Hw.Device(function() Property.hid = "jz4780-lcd"; -- compatible = {"mips,jz4780-lcd"}; Resource.regs = Res.mmio(0x13050000, 0x130517ff); Resource.irq = Res.irq({31, 31}, Io.Resource.Irq_type_level_high); Property.flags = Io.Hw_device_DF_dma_supported; end); However, one counterintuitive aspect of assigning a DMA space involves the DMA domain identifier. As suggested by the nvme-driver code, although a DMA domain has a resource identifier of 0x44414d44 ("DMAD"), the assign operation actually wants the start address associated with the resource. This turns out to be zero in my case. I still wasn't completely done, however. The map operation was failing with what tends to be described in the error messages as a "bad, unknown runtime error". Eventually, I tracked this down to the _get_ds function found in pkg/ l4re-core/moe/server/src/dma_space.cc which has some L4Re::chksys invocations. These invocations are quite unhelpful, obscuring the actual error, which was due to the received DMA space capability not having write permission. In fact, I see that the nvme-driver code for invoking the operation uses the make_cap_rw method on a L4::Ipc::Cap instance, whereas those using the C library have to set the rights bits the old-fashioned way. I don't think I have needed to do this for anything before, so this caught me out. In any case, with all this tidied up, I finally got hold of those physical addresses again, and thankfully the rest of my existing code still worked. I do wonder about where I might put that Hw_device_DF_dma_supported property, but I imagine that even if it were replicated on all appropriate devices, it would not matter which device such a global domain would be acquired from. Anyway, I hope this counts as some kind of feedback about how these frameworks are experienced by outsiders such as myself. I will now aim to pick up where I left off a few weeks ago... Thanks for the help given! Paul _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers