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....@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....@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@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: > > > > > > > h...@denx.de > > > > > > > -- > > > > > > > _______________________________________________ > > > > > > > yocto mailing list > > > > > > > yocto@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: > > > > > h...@denx.de > > > > -- > > > > _______________________________________________ > > > > yocto mailing list > > > > yocto@yoctoproject.org > > > > https://lists.yoctoproject.org/listinfo/yocto
signature.asc
Description: PGP signature
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto