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

[Andrei Gherzan]

On Wed, Apr 19, 2017 at 12:26 PM, Andreas Müller
<schnitzeltony at googlemail.com> wrote:
> On Wed, Apr 19, 2017 at 1:00 PM, 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 would prefer standalone configurations as I found the including
> approach confusing several times and I am not interested in
> raspberrypi-all personally (quite the oposite: different Pi machines
> is a yocto test case for me)

I've seen people requesting it and this approach would unblock them.


--
Andrei Gherzan