On Thu, Jul 1, 2021 at 8:28 PM Robert Reid <[email protected]> wrote:
>
> On Thu, 1 Jul 2021 at 17:16, Kent Mcleod <[email protected]> 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?
>
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
