On Thu, 1 Jul 2021 at 17:16, Kent Mcleod <kent.mcleo...@gmail.com> 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.
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 -- devel@sel4.systems
To unsubscribe send an email to devel-leave@sel4.systems
