[yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting
Kevin Hao
kexin.hao at windriver.com
Sat Nov 3 18:53:28 PDT 2018
On Sat, Nov 03, 2018 at 07:38:02AM -0700, Khem Raj wrote:
> On Sat, Nov 3, 2018 at 1:38 AM Kevin Hao <kexin.hao at windriver.com> wrote:
> >
> > On Fri, Nov 02, 2018 at 07:27:04AM -0700, Khem Raj wrote:
> > > On Fri, Nov 2, 2018 at 2:02 AM Kevin Hao <kexin.hao at windriver.com> wrote:
> > > >
> > > > On Fri, Nov 02, 2018 at 09:01:34AM +0100, Heiko Schocher wrote:
> > > > > Hello Kevin,
> > > > >
> > > > > Am 01.11.2018 um 03:18 schrieb Kevin Hao:
> > > > > > On Wed, Oct 31, 2018 at 02:23:00PM +0100, Heiko Schocher wrote:
> > > > > > > Hello all,
> > > > > > >
> > > > > > > just builded core-image-minimal with current head of thud branch for
> > > > > > > the beaglebone-yocto machine, with linux 4.14.x LTS "Linux version 4.14.78",
> > > > > > > installed the resulting sd card image and boot it, and get:
> > > > > > >
> > > > > > > INIT: Id "O0" respawning too fast: disabled for
> > > > > > > 5 minutes
> > > > > > >
> > > > > > > Reason seems to be:
> > > > > > >
> > > > > > > meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > > > > >
> > > > > > > SERIAL_CONSOLES = "115200;ttyO0"
> > > > > > >
> > > > > > > shouldn't this be
> > > > > > >
> > > > > > > SERIAL_CONSOLES = "115200;ttyS0"
> > > > > > >
> > > > > > > With this fix, sd card image boot fine ... may I oversee seomthing
> > > > > > > obvious ?
> > > > > >
> > > > > > No, it should be 'ttyO0'. It is set by the omap serial driver. You can
> > > > > > refer the following in platform_data/serial-omap.h:
> > > > > > #define OMAP_SERIAL_NAME "ttyO"
> > > > >
> > > > > Yes, you are right, but I see with linux kernel 4.14.78 from
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y&id=e7405910ca5553eae8744af4e5c03e64ee048cb1
> > > > >
> > > > > and I see:
> > > > >
> > > > > [ 0.000000] Linux version 4.14.78 (oe-user at oe-host) (gcc version 8.2.0
> > > > > (GCC)) #1 Thu Nov 1 10:51:09 UTC 2018
> > > > > [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> > > > > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> > > > > [ 0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black
> > > > > [...]
> > > > > [ 0.362878] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
> > > > > [ 0.365758] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 30, base_baud = 3000000) is a 8250
> > > > > [ 1.030465] console [ttyS0] enabled
> > > > >
> > > > > So definitely a ttyS0 ...
> > > >
> > > > OK, so you don't use the linux-yocto kernel, you must not use the Yocto kernel
> > > > meta either.
> > >
> > > I dont think there is such a rule.
> >
> > I don't get what you mean about such a rule. I didn't say anything about that.
>
> re-read carefully what you wrote above and hopefully you will understand
I definitely know what I mean. I just don't understand what you are talking about.
>
>
> > I just pointed out why Heiko get stuck by that issue and how to workaround it.
> >
> > > meta-yocto-bsps are meant as
> > > references and people might want to enhance them.
> >
> > Of course, that is also why we are continually working on it.
> >
>
> your answer did not indicate that.
I apologize if I gave the expression that I don't welcome the enhancement to the meta-yocto-bsp.
But maybe you are the only one who get that from what I wrote.
>
> > >
> > > The reason that you got a ttyS0 here is that you use the
> > > > 8250_omap.c driver. But in Yocto we use the omap-serial.c driver. You can
> > > > workaround this issue by enabling SERIAL_8250_OMAP_TTYO_FIXUP.
> > > >
> > >
> > > omap serial is obsolete why does linux-yocto keeps using it.
> >
> > I guess that the original reason that we use this should be something like the
> > comments in the omap-serial.c:
> > * Note: This driver is made separate from 8250 driver as we cannot
> > * over load 8250 driver with omap platform specific configuration for
> > * features like DMA, it makes easier to implement features like DMA and
> > * hardware flow control and software flow control configuration with
> > * this driver as required for the omap-platform.
> >
> > Yes, it has been a long time since the comments were written and even before the
> > birth of the 8250_omap.c. But I am just not sure that the 8250_omap driver
> > is mature enough so we can switch to it safely and we also don't get any serial
> > issue so far. That is why we leave it as is. And it also seem that the omap-serial.c
> > is also enabled by default in both the multi_v7_defconfig and omap2plus_defconfig
> > in the latest kernel:
> > $ git grep "CONFIG_SERIAL_OMAP" arch/arm/
> > arch/arm/configs/multi_v7_defconfig:CONFIG_SERIAL_OMAP=y
> > arch/arm/configs/multi_v7_defconfig:CONFIG_SERIAL_OMAP_CONSOLE=y
> > arch/arm/configs/omap2plus_defconfig:CONFIG_SERIAL_OMAP=y
> > arch/arm/configs/omap2plus_defconfig:CONFIG_SERIAL_OMAP_CONSOLE=y
> >
> > But if you are pretty sure that the 8250_omap.c is mature enough and also
> > provide more functions than omap-serial.c, please send a patch and we can
> > definitely switch the serial driver to that.
>
> if you are in doubt always ask the source, in this case you could ask TI folks.
OK, I will dig into the source codes, but if you already know the reasons why
omap-serial.c is obsolete and can be safely replaced by 8250_omap.c, why don't
you put them here? It will help all the peoples who care about this issue.
>
> >
> > > seondly, machine config should enable both consoles ttyO0 and ttyS0 if
> > > you know that at least one kernel is using ttyO0
> >
> > Yes, this is an option to fix this issue. Do you mind send a patch?
> >
>
> I do not mind but I do not use this BSP layer, have no way to test it.
OK, I will put this on my todo list.
Thanks,
Kevin
>
> > Thanks,
> > Kevin
> > >
> > > > Thanks,
> > > > Kevin
> > > >
> > > > >
> > > > > bye,
> > > > > Heiko
> > > > > >
> > > > > > Thanks,
> > > > > > Kevin
> > > > > >
> > > > > > >
> > > > > > > bye,
> > > > > > > Heiko
> > > > > > > --
> > > > > > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> > > > > > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > > > > > > Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
> > > > > > > --
> > > > > > > _______________________________________________
> > > > > > > yocto mailing list
> > > > > > > yocto at yoctoproject.org
> > > > > > > https://lists.yoctoproject.org/listinfo/yocto
> > > > >
> > > > > --
> > > > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> > > > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > > > > Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
> > > > --
> > > > _______________________________________________
> > > > yocto mailing list
> > > > yocto at yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/yocto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20181104/0a707e9e/attachment.pgp>
More information about the yocto
mailing list