[seL4] Re: Camkes SerialServer and util_libs/libplatsupport with ODROID-C4

On Thu, Jul 1, 2021 at 8:28 PM Robert Reid wrote:

On Thu, 1 Jul 2021 at 17:16, Kent Mcleod wrote:

...

It could be that the capability to the mmio frame isn't being given to the serialserver camkes component. The serialserver component's CAmkES definition picks the serial device referred to by the stdout-path property of the chosen node in the platform device tree. In the build directory there will be a generated file "serialserver_polling.cdl". This file contains all of the capabilities that will be created during system initialization. If you search this file for the physical address of the MMIO you are trying to have mapped you can check whether it is being given to the SerialServer component. If it has been declared correctly in this generated file, then the chardev_init in libplatsupport should be able to correctly request and map it in. libplatsupport currently uses a platform specific header file to pick which serial device it initializes by default, so if the definition of PS_SERIAL_DEFAULT doesn't refer to the same device as the stdout-path property in the device tree the driver could be trying to initialize a different serial device than the one camkes allocated resources for.

On the right track with the right capability not being provided, but still can't get it working from here.

I am still using PS_SERIAL_DEFAULT to be the same as stdout, UART0_AO @ 0xff803000, so safe there. stdout-path was chosen via an alias: stdout-path = "serial0:115200n8"; serial0 = "/soc/bus@ff800000/serial@3000"

I end up with the following in the build directory: capdl_spec.c: [0] = { #ifdef CONFIG_DEBUG_BUILD .name = "serial.serial_dev_0_data_0_obj", #endif .type = CDL_Frame, .size_bits = 12, .frame_extra = { .paddr = 0x3000,.fill = { } }, },

serialserver_polling.cdl: serial.serial_dev_0_data_0_obj = frame (4k, paddr: 0x3000, fill: [])

I thought there might be some issue with the relative address in the dts; compared to sabre.dts where a full physical address is specified.

I think this would be the issue. Looking at the implementation of "dtb-query-common.template.c" that is imported by seL4DTBHardware-to.template.c (the instantiation of which causes the allocation of caps based on the original dtb() property) it assumes that the reg property contains an absolute address. It isn't handling the case where the reg value inherits the parent's reg property.

However changing the dts to use a full physical address: defined the alias: serial0 = "/soc/bus@ff800000/serial@ff803000"; chosen the serial port as stdout-path: stdout-path = "serial0:115200n8"; and updated the actual device definition later in the DTS: serial@ff803000 { ... }

still gives me paddr: 0x3000 in the cdl. Going further, I've removed the alias so it was directly defined; and eventually changed hard coding the global-components/components/SerialServer/include/plat/arm_common/plat/serial.h file: #define HARDWARE_SERIAL_CONFIG \ serial_dev.dtb = dtb({"path" : "/soc/bus@ff800000/serial@ff803000"}); \ serial_dev.generate_interrupts = 1;

- but all for the same result, no good.

I notice building for -DPLATFORM=odroidc2 results in similar (in its case paddr: 0x0000). I wonder whether there's a difference between aarch32 and aarch64 going on here.

Time to go looking at what the dtb() tool is doing?