Setup console from Device Tree

[jforissier]

This is a rework of my older proof-of-concept code to use DT in OP-TEE to configure devices etc., similar to what the Linux kernel is doing. The series can be divided in two parts:

• Patches 1 ("serial.h: add missing #include <stdbool.h>) through 12 (" core: add common implementation for console_putc() and console_flush()") rework the UART drivers in order to use the previously introduced struct serial_chip and struct serial_ops. The console initialization code is updated accordingly. Update: moved to Serial drivers rework #1393.
• Patches 13 (" core: introduce struct dt_driver") to 19 ("core: arm: generic boot: dt: switch console to /secure-chosen/stdout-path") add a framework for DT-compatible drivers and use it to setup the console from information retrieved from the DT.

Tested on QEMU with manual modifications to the emulator itself to alter the DT:

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index a193b5a..8817431 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -627,6 +627,9 @@ static void create_uart(const VirtBoardInfo *vbi, qemu_irq *pic, int uart,
         /* Mark as not usable by the normal world */
         qemu_fdt_setprop_string(vbi->fdt, nodename, "status", "disabled");
         qemu_fdt_setprop_string(vbi->fdt, nodename, "secure-status", "okay");
+       /* Select as default console for secure world */
+       qemu_fdt_add_subnode(vbi->fdt, "/secure-chosen");
+       qemu_fdt_setprop_string(vbi->fdt, "/secure-chosen", "stdout-path", nodename);
     }

With this, the console remains on the secure UART (/pl011@9040000). When the property's value is forced to "/pl011@9000000" instead, the console is switched to the Non-Secure UART. Finally, if the /secure-chose node is left empty, the console is disabled.

[MrVan]

@jforissier Just wonder is there helper functions that driver can be probed by using dts? There are too many CFG_xx in my code. I would like to use dts to differentiate, optee shmem/tee ram for different platforms. Also dtb is only used in init_fdt(fdt);, I would like to let platform code/ driver code could also access device tree. Do you have plan to add the support?

[etienne-lms]

I agree that DT could be quite useful to many platforms, to reduce some static configuration directive. Be careful that some settings may not be easily portable into the DT. TEE RAM is an example since the OP-TEE core shall be built for the exact physical location we expect it to be loaded/executed.

I also agree the DT parsing support should exit the generic_boot.c and be made available for drivers and platforms. Also, after talking about DT those last days, I believe there will likely be different needs and strategy regarding for each of the different platform. Hence, CFG_DT should only enable integration of the DT parsing/overwritting support, leaving to each platform to decide how they read/write the DTB. I have no idea of how to implement that, but we should think about it.

@jforissier, in the mean time, i feel your change can continue to be reviewed (and merged once agreed) since it still proposed interesting use of the DTB in OP-TEE. Bringing more flexibility into DT use can more later on.

[jforissier]

Superseded by #1433.