Re: [yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting
On Fri, Nov 02, 2018 at 07:27:04AM -0700, Khem Raj wrote: > On Fri, Nov 2, 2018 at 2:02 AM Kevin Hao 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.00] 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.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), > > > cr=10c5387d > > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > > > instruction cache > > > [0.00] 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 = 300) 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. 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. > > 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. > 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? 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 > > > > > y
Re: [yocto] Kernel development using externalsrc
On Fri, Nov 2, 2018 at 5:47 PM CHMIELARZ Radoslaw
radoslaw.chmielarz-at-leica-geosystems.com wrote:
> The company I work for uses yocto to build an image with a custom
> linux kernel. The documentation
> (https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html)
> suggests a setup where the kernel is under git and the kernel recipe
> specifies this git repository hence the workflow is the following:
>
> Make changes in local kernel directory
> Submit changes to git (and presumably push to shared space)
> Run yocto build which fetches the changes
>
> However since I don’t want to push the changes to git server before I
> test locally I have added the kernel sources using
> externalsrc.
Devtool is of course what they recommend, but can always change the git
repo to a local one in a .bbappend, so you save the push step and Yocto
build saves fetching over the network. (Making a git commit for each
build attempt is very little overhead and I would recommend it anyway as
a good working practice. You can clean up using "git rebase -i" once you
are happy with your code and before you publish it.)
In one of my development branches I find
SRC_URI = "\
git:///home/myname/projects/yoctobuild/pkgsrc/somerepo/;protocol=file;branch=debug/#675-v2.16.0
\
file://some.patch \
file://other.patch \
"
SRCREV = "${AUTOREV}"
I have not done it for the kernel, but I see no reason why it would not
work there.
(Obviously the absolute path is nothing you would be able to share
unmodified with others. Maybe it can be made a bit more portable using
${THISDIR}, but I have not had any need to try it.)
> Unfortunately this has the drawback that
> linux-libc-headers runs do_configure and do_install phase which
> invalidates glibc-initial and requires a recompilation of a couple of
> hundreds of packages. I would like to avoid it.
>
How editing the kernel source would cause rebuilds trailing
linux-libc-haeaders I cannot see in my build here
$ bitbake-diffsigs -t linux-libc-headers configure
NOTE: Starting bitbake server...
ERROR: Only one matching sigdata file found for the specified task
(linux-libc-headers do_configure)
Well, maybe I have never changed the kernel in this build area, so let's
check what it depends on:
$ bitbake-dumpsig -t linux-libc-headers configure
NOTE: Starting bitbake server...
ERROR: Metadata does not support finding signature data files
Hmm, no idea what that means. Until someone tells us what's wrong let's
use stamp files instead
$ bitbake-dumpsig
tmp/stamps/corei7-64-poky-linux/linux-libc-headers/4.15.7-r0.do_configure.sigdata...
This task depends on the checksums of files: []
Hash for dependent task
/home/geuder/projects/yoctobuild/meta-nel/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb.do_prepare_recipe_sysroot
is 5ac6adcdd9edfe2705fd461a42942613
$ bitbake-dumpsig
tmp/stamps/corei7-64-poky-linux/linux-libc-headers/4.15.7-r0.do_prepare_recipe_sysroot.sigdata...
This task depends on the checksums of files: []
Hash for dependent task
/home/geuder/projects/yoctobuild/meta-nel/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb.do_fetch
is 362b694aea2202ce72ad259579d001ad
$ bitbake-dumpsig
tmp/stamps/corei7-64-poky-linux/linux-libc-headers/4.15.7-r0.do_fetch.sigdata...
Variable SRC_URI value is
${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION}
Tasks this task depends on: []
This task depends on the checksums of files: []
So my build gets kernel headers from kernel.org (mirror), it does not
use the kernel source I use to build my kernel. Maybe that's different
for you?
Of course the output of the bitbake-dumpsig commands is massively
shortened, I just picked those lines that seemed likely candidates to
cause rebuilds. To get the whole truth in your build call...
$ bitbake-diffsigs -t linux-libc-headers configure
... after you made a small kernel edit and rebuilt.
Regards,
Uwe
Uwe Geuder
Neuro Event Labs Oy
Tampere, Finland
uwe.gexder at neuroeventlabs.com (Bot check: fix one obvious typo)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting
On Sat, Nov 3, 2018 at 1:38 AM Kevin Hao 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 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.00] 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.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), > > > > cr=10c5387d > > > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > > > > instruction cache > > > > [0.00] 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 = 300) 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 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. > > > > 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. > > > 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.
[yocto] smartpm "already installed" issue
Hello, I just created an rpm repo for my morty yocto os. The problem is that every new package installation is failed because the dependencies "are already installed". E.g.: error: package libc6-2.24-r0.arm1176jzfshf_vfp is already installed In the repo there is the same package that is locally installed. I cannot reinstall either with the package not found error. I found this error as a really similar issue: http://lists.openembedded.org/pipermail/openembedded-core/2017-February/132320.html but this patch is included in my yocto build system. Now I'm stuck, because I found no further hint about this problem. Any idea? Regards, Matthew -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting
On Sat, Nov 03, 2018 at 07:38:02AM -0700, Khem Raj wrote: > On Sat, Nov 3, 2018 at 1:38 AM Kevin Hao 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 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.00] 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.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), > > > > > cr=10c5387d > > > > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > > > > > instruction cache > > > > > [0.00] 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 = 300) 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_defco
Re: [yocto] How to avoid stripping libthread_db to enable gdb thread debugging?
Thanks mark. glibc-dbg resolved this issue. On Fri, Nov 2, 2018 at 11:21 AM Mark Hatle wrote: > On 11/2/18 1:03 PM, Hui Liu wrote: > > Hi, > > > > I add gdb to my recipe, and found gdb can't enable thread debugging. > > > > The warning from gdb is: > > > > warning: Unable to find libthread_db matching inferior's thread library, > thread > > debugging will not be available > > > > After some investigation, I found it is due to libthread_db is stripped: > > > > nm lib/libthread_db.so.1 > > nm: lib/libthread_db.so.1: no symbols > > > > Could you let me know how to avoid this? > > You need to install the dbg package. This contains the symbols necessary > for > debugging. You can install it for either cross or local (on target) > debugging. > In the cross-debuging case, you should not need it on the target. > > --Mark > > > -- > > Thanks, > > Hui > > > > > > -- Thanks, Hui -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
