12184 2017-10-04 19:51:51 +0000 sysvinit-inittab_2.88dsf.bb: ${base_bindir}/start_getty? 2018-10-12 16:38:10 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 2.4 x86 Multiple RESOLVED FIXED Medium+ normal 2.5 M4 1 pokylinux pokylinux andrea.adami maxin.john meta.mr.watcher meta.watcher sgw stephano yin.thong.choong --- --- Don't know oldest_to_newest 77353 0 pokylinux 2017-10-04 19:51:51 +0000 I use a multi_v7_defconfig kernel[1] with various device trees[2] and apparently different versions of u-boot for different boards. This means I can keep kernel+rootfs identical between various boards and just need board specific u-boot(s), u-boot configs and appropriate device trees. I pass the console over the kernel command line and in my machine config I have some dummy SERIAL_CONSOLES="115200;console" u-boot passes the correct console per board e.g.: cat /proc/cmdline console=ttymxc1,115200n8 ip=192.168.42.11:192.168.42.1:192.168.42.1:255.255.255.0:imx6q-phytec-mira-rdk-nand:eth0:off nfsroot=192.168.42.1:/opt/poky/mira-rootfs,v3,tcp noinitrd nohlt panic=1 earlyprintk=ttymxc1,115200n8 My tests with rocko indicated that the boards are not booting anymore which boils down to ${base_bindir}/start_getty being used instead of ${base_sbindir}/getty. Looks like ${base_bindir}/start_getty freaks out;) this is what I see in /etc/inittab, which does not work: sole:12345:respawn:/bin/start_getty 115200 console vt102 if I run /bin/start_getty manually on the board I get: root@multi-v7-ml:~# /bin/start_getty 115200 console vt102 /bin/start_getty: line 30: [: 1: unary operator expected /bin/start_getty: line 30: [: 2: unary operator expected root@multi-v7-ml:~# My fix for now to get the board booting is to replace /bin/start_getty with the good old /sbin/getty[4]. Something like a bbappend file, which does this: do_install_append() { sed -i 's/bin\/start_getty/sbin\/getty/' ${D}${sysconfdir}/inittab } [1] https://github.com/RobertBerger/meta-mainline/blob/rocko-training-v4.9.x/multi-v7-ml/recipes-kernel/linux/linux-yocto-custom_4.9.44.bb [2] https://github.com/RobertBerger/meta-mainline/blob/rocko-training-v4.9.x/multi-v7-ml/conf/machine/multi-v7-ml.conf#L114 [3] https://github.com/RobertBerger/meta-mainline/blob/rocko-training-v4.9.x/multi-v7-ml/conf/machine/multi-v7-ml.conf#L90 [4] https://github.com/RobertBerger/meta-mainline/blob/rocko-training-v4.9.x/multi-v7-ml/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bbappend 77354 1 pokylinux 2017-10-04 19:53:11 +0000 SERIAL_CONSOLES="115200;console" [3] 77463 2 ross.burton 2017-10-09 16:11:17 +0000 So the problem is that the script expects the console (argument 2 to start_getty) to have an index. Can you just use a different value for the dummy console? 77731 3 pokylinux 2017-10-20 14:16:32 +0000 @Ross: Where should this index come from? I could use another value as a dummy console. What would you suggest? I see in the official repo[1] e.g. for the Beagle Bone Black: SERIAL_CONSOLE = "115200 ttyO0" which is actually deprecated for SERIAL_CONSOLES = "115200;console" and I am not quite sure where this index you are talking about should come from. [1] https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf/machine/beaglebone.conf 77732 4 pokylinux 2017-10-20 14:20:16 +0000 I'll try with SERIAL_CONSOLES = "115200;console1" and see if this makes any difference. 77741 5 pokylinux 2017-10-20 15:32:12 +0000 Did not work as well. If I use a non dummy value it works: in top level machine config: SERIAL_CONSOLES="115200;ttymxc1" created this inittab: mxc1:12345:respawn:/bin/start_getty 115200 ttymxc1 vt102 which works for this specific board. ... but how would I create a rootfs which works on various different boards with different consoles with /bin/start_getty as I can do with /sbin/getty? A dummy console e.g. SERIAL_CONSOLES="115200;ttyres1" does not make /bin/start_getty freak out, but this does not help, since I still don't get a getty: INIT: Id "res1" respawning too fast: disabled for 5 minutes 77742 6 pokylinux 2017-10-20 15:38:19 +0000 ... and ... a list of consoles where I add e.g. 2 consoles for 2 boards does not work as well, since one of them will always be invalid which leads to something like this: Poky (Yocto Project Reference Distro) 2.4 imx6q-phytec-mira-rdk-nand-bsp /dev/ttymxc1 INIT: Id "res1" respawning too fast: disabled for 5 minutes Poky (Yocto Project Reference Distro) 2.4 imx6q-phytec-mira-rdk-nand-bsp /dev/ttymxc1 imx6q-phytec-mira-rdk-nand-bsp login: Poky (Yocto Project Reference Distro) 2.4 imx6q-phytec-mira-rdk-nand-bsp /dev/ttymxc1 imx6q-phytec-mira-rdk-nand-bsp login: Poky (Yocto Project Reference Distro) 2.4 imx6q-phytec-mira-rdk-nand-bsp /dev/ttymxc1 imx6q-phytec-mira-rdk-nand-bsp login: root root@imx6q-phytec-mira-rdk-nand-bsp:~# [ 55.641543] random: crng init done root@imx6q-phytec-mira-rdk-nand-bsp:~# root@imx6q-phytec-mira-rdk-nand-bsp:~# root@imx6q-phytec-mira-rdk-nand-bsp:~# root@imx6q-phytec-mira-rdk-nand-bsp:~# 77952 7 pokylinux 2017-11-03 17:24:02 +0000 If we insist that a oe/yocto build has always to be for one very specific board than /bin/start_getty enforces this behaviour and I will need to add this bbappend to my meta layer (which is how I have it right now and how it works for me). do_install_append() { sed -i 's/bin\/start_getty/sbin\/getty/' ${D}${sysconfdir}/inittab } The sad thing is, that it worked before the script and the script broke it and it's not very clear to me what this magic script tries to solve. I found this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10844 and this: https://patchwork.openembedded.org/patch/144225/ 80199 8 maxin.john 2018-04-11 05:47:55 +0000 (In reply to comment #3) > @Ross: Where should this index come from? > > I could use another value as a dummy console. > > What would you suggest? > > I see in the official repo[1] e.g. for the Beagle Bone Black: > > SERIAL_CONSOLE = "115200 ttyO0" This shouldn't be a problem since we process SERIAL_CONSOLES in bitbake.conf as: SERIAL_CONSOLES ??= "${@d.getVar('SERIAL_CONSOLE').replace(' ', ';')}" 80200 9 maxin.john 2018-04-11 06:48:17 +0000 (In reply to comment #6) > ... and ... > > a list of consoles where I add e.g. 2 consoles for 2 boards does not work as > well, since one of them will always be invalid which leads to something like > this: > > Poky (Yocto Project Reference Distro) 2.4 imx6q-phytec-mira-rdk-nand-bsp > /dev/ttymxc1 > > INIT: Id "res1" respawning too fast: disabled for 5 minutes This generally happens when we set the device in inittab and it is not available (not enabled in kernel) One way to fix this scenario is to use "SERIAL_CONSOLES_CHECK" instead of SERIAL_CONSOLES. Could you please try this method and see if the error persists ? commit 5e7d4ca3f34ef2eded0605327feed1f4611fe232 Author: Matthew McClintock <msm@freescale.com> Date: Wed Jul 11 18:15:27 2012 -0500 sysvinit-inittab_2.88dsf.bb: Allow multiple serial port consoles to be defined Set SERIAL_CONSOLES if you want to define multiple serial consoles, also if you need to check for the presence of the serial consoles you can also define SERIAL_CONSOLES_CHECK to determine if these are present when you boot. This will prevent error message that pop up when the serial port is not present. SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1 115200;ttyEHV0" SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}" The above lines in machine.conf or elsewhere will have the effect of having two serial consoles and removing any that are not present at boot (From OE-Core rev: eecd65f188ba2c924626b7e1bf5c8e2eb51e9b59) Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 80237 10 maxin.john 2018-04-13 04:57:21 +0000 Please let us know if using "SERIAL_CONSOLES_CHECK" instead of "SERIAL_CONSOLE" fixes this. 80395 11 stephano 2018-04-25 09:52:25 +0000 @Robert please see @Maxin's fix on Comment 9. Let us know if that doesn't work for you. 80400 12 pokylinux 2018-04-25 23:27:50 +0000 I am currently on the road, so it might take some time to test it. I do have rocko with the "commit 5e7d4ca3f34ef2eded0605327feed1f4611fe232" inside. Please stay tuned for a while. 80401 13 pokylinux 2018-04-26 01:03:09 +0000 I did a quick test while delivering a training. machine config: https://pastebin.com/gaM3GpVj bootlog excerpt: https://pastebin.com/F6FCyu2g new inittab generated (which does not work) https://pastebin.com/cqXRTTw6 ====== This is the bootlog excerpt as it should be: https://pastebin.com/uaMQhFY0 This is the inittab which works: https://pastebin.com/RWcZcMPC Please note, that the magic line in inittab which makes it work is: sole:12345:respawn:/sbin/getty 115200 console vt102 Am I doing the right thing in machine config? SERIAL_CONSOLES="115200;console" SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}" Note that console is just a dummy value, which is replaced with the right value by the bootloader: root@am335x-phytec-wega-bsp:~# cat /proc/cmdline console=ttyO0,115200n8 ip=192.168.42.11:192.168.42.1:192.168.42.1:255.255.255.0:am335x-phytec-wega:eth0:off nfsroot=192.168.42.1:/opt/poky/wega-rootfs,v3,tcp noinitrd nohlt panic=1 root@am335x-phytec-wega-bsp:~# For this Sitara based board it's console=ttyO0,115200n8 80405 14 pokylinux 2018-04-26 01:30:34 +0000 I assume, that I should add all the possible consoles for all my boards in SERIAL_CONSOLES. something like: SERIAL_CONSOLES = "115200;ttyO0 115200;ttymxc1" SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}" for sitara and i.mx6 80406 15 pokylinux 2018-04-26 02:05:02 +0000 With a quick check for sitara it seems to work: inittab: # Normally not reached, but fallthrough in case of emergency. z6:6:respawn:/sbin/sulogin O0:12345:respawn:/bin/start_getty 115200 ttyO0 vt102 80427 16 maxin.john 2018-04-26 22:14:07 +0000 (In reply to comment #15) > With a quick check for sitara it seems to work: > > inittab: > > # Normally not reached, but fallthrough in case of emergency. > z6:6:respawn:/sbin/sulogin > O0:12345:respawn:/bin/start_getty 115200 ttyO0 vt102 Good to hear that it worked for you. Do you think it is fine to close this bug, then ? 80431 17 pokylinux 2018-04-26 23:28:11 +0000 If you like you can close it. I would like to test it on a few more boards just to be sure it works for my use case. Thanks! 80434 18 maxin.john 2018-04-27 03:13:48 +0000 (In reply to comment #17) > If you like you can close it. I would like to test it on a few more boards > just to be sure it works for my use case. > > Thanks! Sure. Please feel free to reopen this, if you run into any troubles while testing on other boards.