[meta-intel] [PATCH 1/2] intel-corei7-64: add machine configurations specific to leafhill bsp

[Jianxun Zhang]

I just provide my comment in lines on console stuff from RMC perspective.

Thanks

> On Sep 6, 2016, at 11:21 AM, Cal Sullivan <california.l.sullivan at intel.com> wrote:
> 
> 
> 
> On 09/06/2016 10:43 AM, Saul Wold wrote:
>> On Mon, 2016-09-05 at 14:18 +0800, Rebecca Chang Swee Fun wrote:
>>> We would like to enable new BSP for Intel Atom E3900 SoC based
>>> platforms.
>>> This will help us to consolidate BSP into intel-common and we can use
>>> KERNEL_FEATURES to select target BSP to compile.
>>> 
>>> Leaf Hill uses different serial console port setup. Hence this
I have a questions on the “boards” derived from a SoC "platform". Are we expecting all boards based on this SoC will have identical console or any settings hardcoded here?
>>> mechanism are in place to enable new bsp with existing machine
>>> configurations file.
>>> 
>>> Leaf Hill BSP also required additional kernel stack protector
>>> settings to compile kernel with security defense enabled.
>>> 
>> Is this for Jethro, Kroghoth, master?
>> 
>> more comments below
>> 
>>> Signed-off-by: Rebecca Chang Swee Fun
>>> <rebecca.swee.fun.chang at intel.com>
>>> ---
>>>  conf/machine/intel-corei7-64.conf | 9 ++++++---
>>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/conf/machine/intel-corei7-64.conf b/conf/machine/intel-
>>> corei7-64.conf
>>> index cc16d62..7a5b400 100644
>>> --- a/conf/machine/intel-corei7-64.conf
>>> +++ b/conf/machine/intel-corei7-64.conf
>>> @@ -29,6 +29,9 @@ XSERVER ?= "${XSERVER_X86_BASE} \
>>>              ${XSERVER_X86_VESA} \
>>>             "
>>>  -SYSLINUX_OPTS = "serial 0 115200"
>>> -SERIAL_CONSOLE = "115200 ttyS0"
>>> -APPEND += "console=ttyS0,115200 console=tty0"
>>> +SYSLINUX_OPTS = "serial ${@bb.utils.contains('KERNEL_FEATURES',
>>> 'leafhill', '2', '0', d)} 115200"
>>> +SERIAL_CONSOLE = "115200 ${@bb.utils.contains('KERNEL_FEATURES',
>>> 'leafhill', 'ttyS2', 'ttyS0', d)}"
>> Can we not use the SERIAL_CONSOLES = "115200,ttyS2 115200,ttyS0"
>> variable here instead?
> 
> I think doing a switch based on KERNEL_FEATURES doesn't scale well and makes things a lot less readable.

> We can also do this:
> 
> SERIAL_CONSOLES = "115200,ttyS2 115200,ttyS0"
> SERIAL_CONSOLES_CHECK = "ttyS2 ttyS0"
> 
> This should stop getty from trying to enable non-existent serial consoles, stopping the annoying "trying to respawn" warning we would get every five minutes otherwise.
NUC Gen 6 example in rmc dir fixed a similar issue by modifying inittab in _installation_ time for a specific board, so you don’t need to specify OE variables for a board conf.
> 
> 
>> 
>>> +APPEND += "${@bb.utils.contains('KERNEL_FEATURES', 'leafhill',
>>> 'console=ttyS2,115200n8', 'console=ttyS0,115200', d)} console=tty0"
>>> +APPEND += "${@bb.utils.contains('KERNEL_FEATURES', 'leafhill',
>>> 'reboot=efi kmemleak=off i915.enable_ipc=1', '', d)}"
>> So the console settings I understand, but I think we can set multiple
>> consoles on the command line.
> Yep, multiple consoles in APPEND is fine. We do it in core2 already.

I think it is another twist following the traditional build-time approach, same as to put these in a board conf file. If we enable RMC and check in all supported later, we won’t need APPEND very much for board-specifc differentiations.

But if you do need a different kernel config or compiling flag , that’s another story.
>> 
>> Moving forward for 2.2 and beyond, you should start learning about the
>> "Runtime Machine Config" RMC that was recently introduced into meta-
>> intel for 2.2
>> 
>>> +
>>> +KERNEL_EXTRA_ARGS = "${@bb.utils.contains('KERNEL_FEATURES',
>>> 'leafhill', 'EXTRA_CFLAGS="-D_FORTIFY_SOURCE=2 -Wformat -O2 -Wformat-
>>> security"', '', d)}"
>> Do we really need to change the CFLAGS here?  Would the be appropriate
>> for all kernels moving forward?  These seem more like product quality
>> or maybe distro related CFLAGS than BSP generic flags.
>> 
>> We want to keep the difference between a non-intel-core* bsp and the
>> intel-core* bsps to a minimum, this will always guarantee they are
>> different
> Agree here.
> 
> ---
> Cal
>> Sau!
>> 
> 
> -- 
> _______________________________________________
> meta-intel mailing list
> meta-intel at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel