It shouldn’t be necessary to add the region to the device tree. Unless the region is declared as a kernel-reserved region, device untypeds are provided to user level. If you run sel4test for the platform, you can look at the full set of device untypeds passed to the initial task. Here is a link to a ZCU102 sel4test run: mcs: update AUXUPD comment for verification · seL4/seL4@3ae685a · GitHub
I am using seL4 for in our arm64 based hardware platform.
I need to write a simple driver where i need to read/write some memory mapped registers
The device physical address is “0x40520000”
When i print the bootinfo using the below code:
/– filter TaskContent(“untyped-start”, TaskContentType.ALL, subtask=‘init’) -/
printf(" CSlot \tPaddr \tSize\tType\n");
for (seL4_CPtr slot = info->untyped.start; slot != info->untyped.end; slot++) {
seL4_UntypedDesc *desc = &info->untypedList[slot - info->untyped.start];
printf(“%8p\t%16p\t2^%d\t%s\n”, (void *) slot, (void *) desc->paddr, desc->sizeBits, desc->isDevice ? “device untyped” : “untyped”);
I get the following output:
CSlot Paddr Size Type
0x1ac 0 2^30 device untyped
0x1ad 0x40000000 2^28 device untyped
0x1ae 0x50000000 2^23 device untyped
0x1af 0x50810000 2^16 device untyped
0x1b0 0x50820000 2^17 device untyped
I am mappint the physical address to virtual and trying to access it as:
va = ps_io_map(&ops.io_mapper, (uintptr_t) 0x40520000,0x3000, PS_MEM_NORMAL);
ZF_LOGE(“Physical address 0x%x mapped to virtual address %p \n”,DEV_REG_PADDR,va);
for(int j=0;j<DEV_REG_SIZE;j+=sizeof(unsigned int))
{
ZF_LOGE("Loc %d → 0x%x ",j,(unsigned int)(va+j));
}
I am able to access some registers, but then it gives a fault (after printing 5-6 register values)
Similar is the behaviour with any reg between the range 0x40000000 - 0x50000000
If the first few registers are being printed out, it would indicate that the virtual mapping is set up. The fault message contains the fault status register which can be decoded using the Arm architecture manual. Potential reasons for the fault could be:
The register address isn’t a valid hardware MMIO address for the device,
The device providing the MMIO address may not be powered, out of reset or have clocks initialized. Accessing unclocked memory could cause a fault.
The type of memory access may not be supported eg 8bit access to a register that only supports 32bit access.
Are you able to paste in the serial output from the running program and the code used to access the registers?