[yocto] [meta-raspberrypi] Unified serial console device option

[Khem Raj]

On Wed, Apr 19, 2017 at 4:00 AM, Andrei Gherzan <andrei at gherzan.ro> wrote:
> Hello all,
>
> I'm trying to have the ability for user to use serial0 as serial port
> on the header and serial1 (when available) for Bluetooth. In this way
> rpi2 and rpi3 (32b) will have the same configuration. The story goes
> identical for rpi0 and rpi0-wifi.
>
> Now, what I was planning to do is:
> 1. create udev rules to generate the the symlinks accordingly to dt aliases.
> 2. add the above package (with the rules) as a machine recommends
> (MACHINE_ESSENTIAL_*).
> 3. and then change all the SERIAL_CONSOLE = 'serial0 115200'
>
> This works great with one exception: system parses the console
> argument in cmdline and spawns through a generator a new getty
> instance on that device. Adding systemd-serialgetty package will make
> system have two getty services on the same device (serial0 and for
> example AMA0) which is obviously unusable and wrong. Sysvinit works
> ok.
>
> Then I thought to make this completely optional:
> 1. create udev rules to generate the the symlinks accordingly to dt aliases.
> 2. make SERIAL_CONSOLE configurable (default assignments)
> 3. a user wanting to take advantage of the udev rules will have to add
> the rpi udev rules to the image and modify in his/her local.conf
> SERIAL_CONSOLE
>
> Currently we have a cascade setup for our machine configuration: ex
> rpi3 includes rpi2 and tweaks some things. We do this to avoid some
> duplication (even though the gain is really minimal - 2-3 lines).
> Anyway it is something after all.
>
> This again looks fine but because we have machine which include other
> machine conf, I endded up having a problem when I want to overwrite
> both definitions: see rpi3 which includes rpi2 (defines a
> SERIAL_CONSOLE) than overwrites SERIAL_CONSOLE.
>
> What do you guys think as a way forward? One way would be to make the
> boards definitions be stand alone and use default assignments which I
> think it would fix everything and make the mechanism completely
> optional.
>
> BTW: This would unlock the ability to create a raspberrypi-all machine
> that would work on any raspberry board (armv6 + wifi firmware + etc).
>

I think as a BSP layer, we only need it to expose knobs for serial
consoles such that all consoles are accounted for on a given machine.
Then I am fine if you want to treat the machine configs as references
meaning that someone can inherit the machine conf and override serial
console. Beyond that its
a distribution option to unify machine or consoles etc. I would leave it to that
and ensure that if some distros wanted such a set up and anything was
missing from machine perspective that should be added.

> --
> Andrei Gherzan