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.sulli...@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.ch...@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@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-intel -- _______________________________________________ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel