Re: [yocto] How to patch a recipe .inc file
Hi,
To add some kernel config I have created an extra .cfg file in:
my_recipe/recipes-kernel/linux/linux-raspberrypi/
and add an bb_append file:
recipes-kernel/linux/linux-raspberrypi_%25.bbappend
__
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://your_conf.cfg"
__
BR
Jonas
> 8 aug. 2019 kl. 01:02 skrev Greg Wilson-Lindberg :
>
> I'm working with a Yocto Sumo build provided with Qt's boot2qt system. I'm
> trying to enable using initramfs as a step in trying to enable OSTree updates.
>
> In the meta-raspberrypi documentation, section 3.14, it says to add some
> kernel config to the linux-raspberrypi.inc file. I would prefer to keep my
> changes to Yocto layer files in my own tree so I'm trying to figure out how
> to patch the existing file. I've got bitbake finding my patch file, but it
> can't find the file to patch.
>
> Can somebody help me to specify that the file that I'm patching is part of
> the meta-raspberrypi linux recipe?
>
> I'm going to be gone for a week, but I wanted to ask this now so maybe I'll
> have some information when I get back.
>
> Regards,
> Greg Wilson-Lindberg
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.3.rc1)
Hello All, This is the full report for 2.6.3 RC1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/log/?h=intel-yocto-testresults === Summary No high milestone defects. No new defects are found in this build. ===QA notes= One minor issue is observed, after installed core-image-sato-sdk image to NUC7 internal harddisk, during boot up, it hangs at the Yocto splash screen. Need to manual press keyboard "enter" button multiple times for it to continue the boot and bring the screen to sato GUI. No bug is filed for this issue as this seems to be a minor issue and QA team investigating more onto it. This bug is consistently reproducible. Thanks & Regards, Sangeeta Jain -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [kernel-cache] Question about profiling.scc
On Wed, Aug 7, 2019 at 10:03 PM Hongzhi, Song wrote: > Hi Bruce, > > > profiling.cfg is just designed for powertop and oprofile. > that comment is a bit misleading. Things like perf events, rely on config_profiling .. so it is more of a base config than just for those two. bruce > >1 # for oprofile and powertop >2 CONFIG_PROFILING=y >3 CONFIG_OPROFILE=y >4 CONFIG_FRAME_POINTER=y >5 CONFIG_X86_LOCAL_APIC=y > > Maybe split profiling.cfg and move them to their recipe is a good way. > > > --Hongzhi > > > > On 8/7/19 10:43 AM, Bruce Ashfield wrote: > > > > > > On Mon, Aug 5, 2019 at 11:44 PM Hongzhi, Song > > mailto:hongzhi.s...@windriver.com>> wrote: > > > > Hi Bruce, > > > > I see profiling.scc is included by kernel-cache/bsp/*, such as > > bsp/intel-x86 bsp/common-pc/ ... . > > > > > > My question is that is it necessary to open profiling.cfg defaultly? > > > > > > We left profiling as a per-BSP decision, since production machine > > configurations don't want the overhead that it brings. > > > > Not all BSPs follow the split between developer and production, but > > see how it is used in: > > > > bsp/common-pc-64/common-pc-64-developer.scc:include > > features/profiling/profiling.scc > > bsp/common-pc-64/common-pc-64-preempt-rt.scc:include > > features/profiling/profiling.scc > > > > If it was enabled by default, it really should be in the developer > > ktype and then BSPs could have the split between production and > > developer/debug in their definitions .. with the developer ones > > getting profiling by default. > > > > Bruce > > > > > > > > --Hongzhi > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [kernel-cache] Question about profiling.scc
Hi Bruce, profiling.cfg is just designed for powertop and oprofile. 1 # for oprofile and powertop 2 CONFIG_PROFILING=y 3 CONFIG_OPROFILE=y 4 CONFIG_FRAME_POINTER=y 5 CONFIG_X86_LOCAL_APIC=y Maybe split profiling.cfg and move them to their recipe is a good way. --Hongzhi On 8/7/19 10:43 AM, Bruce Ashfield wrote: On Mon, Aug 5, 2019 at 11:44 PM Hongzhi, Song mailto:hongzhi.s...@windriver.com>> wrote: Hi Bruce, I see profiling.scc is included by kernel-cache/bsp/*, such as bsp/intel-x86 bsp/common-pc/ ... . My question is that is it necessary to open profiling.cfg defaultly? We left profiling as a per-BSP decision, since production machine configurations don't want the overhead that it brings. Not all BSPs follow the split between developer and production, but see how it is used in: bsp/common-pc-64/common-pc-64-developer.scc:include features/profiling/profiling.scc bsp/common-pc-64/common-pc-64-preempt-rt.scc:include features/profiling/profiling.scc If it was enabled by default, it really should be in the developer ktype and then BSPs could have the split between production and developer/debug in their definitions .. with the developer ones getting profiling by default. Bruce --Hongzhi -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] How to patch a recipe .inc file
I'm working with a Yocto Sumo build provided with Qt's boot2qt system. I'm trying to enable using initramfs as a step in trying to enable OSTree updates. In the meta-raspberrypi documentation, section 3.14, it says to add some kernel config to the linux-raspberrypi.inc file. I would prefer to keep my changes to Yocto layer files in my own tree so I'm trying to figure out how to patch the existing file. I've got bitbake finding my patch file, but it can't find the file to patch. Can somebody help me to specify that the file that I'm patching is part of the meta-raspberrypi linux recipe? I'm going to be gone for a week, but I wanted to ask this now so maybe I'll have some information when I get back. Regards, Greg Wilson-Lindberg -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] U-boot enable not working for Raspberry Pi3
Hi Marek,
I'm going to top post so you don't have to scroll to the meat of the matter.
I had rebuilt my system because of a failing main hard disk and had lost
settings on a number of the programs that I had to re-install and didn't
notice. One that has obviously caused me problems is that the editor that I use
I keep set to automatically save any changes on loss of focus. I had changed
the local.conf file, but I didn't realize that it hadn't written out the
changes.
I realized yesterday that the editor wasn't working as I expected and fixed the
setting and went on. This morning I rebuilt my yocto system and it rebuilt more
than I expected and when I installed it and booted, much to my surprise I
realized that u-boot was being executed.
So sorry for the false concern, and thank you for the help and maybe someone
will learn something from either my mistake or from your helpful responses.
Best Regards,
Greg Wilson-Lindberg
> -Original Message-
> From: Greg Wilson-Lindberg
> Sent: Tuesday, August 06, 2019 12:03 PM
> To: Belisko Marek
> Cc: Yocto list discussion
> Subject: RE: [yocto] U-boot enable not working for Raspberry Pi3
>
> Hi Marek,
>
> > -Original Message-
> > From: Belisko Marek [mailto:marek.beli...@gmail.com]
> > Sent: Tuesday, August 06, 2019 11:40 AM
> > To: Greg Wilson-Lindberg
> > Cc: Yocto list discussion
> > Subject: Re: [yocto] U-boot enable not working for Raspberry Pi3
> >
> > Hi Greg,
> >
> > On Tue, Aug 6, 2019 at 8:29 PM Greg Wilson-Lindberg
> >
> > wrote:
> > >
> > > Hi Marek,
> > >
> > > Thanks for the suggestion, that seems to be the case. What image are
> > > you
> > building so I can try that to see what I get?
> > Please don't top post ;). I'm building basic image. I worked few
> > months ago with bootqt and sometimes it was bit tricky ;). Are you
> > sure you have this variable set in local.conf?
>
> Here is an excerpt from my local.conf file:
>
> # CONF_VERSION is increased each time build/conf/ changes incompatibly and is
> used to # track the version of this file when it was generated. This can
> safely be
> ignored if # this doesn't mean anything to you.
> CONF_VERSION = "1"
>
>
> #
> # Custom additions
> #
>
> # Additional dtbo's
> KERNEL_DEVICETREE_remove = " overlays/mcp2515-can0.dtbo
> overlays/mcp2515-can1.dtbo"
>
> # Fixes for inclusion of mysql
> PACKAGECONFIG_append_pn-qtbase += " sql-mysql"
> QT_CONFIG_FLAGS_append_pn-qtbase += " -I /usr/include/mysql"
> QT_CONFIG_FLAGS_append_pn-qtbase += " -I
> ${STAGING_DIR_TARGET}/usr/include/mysql"
>
> RPI_USE_U_BOOT = "1"
>
> # End Custom additions
> #
>
> #INHERIT += "rm_work"
> INHERIT += "image-buildinfo"
> INHERIT += "internal-build"
>
> I copied the line from the meta-raspberrypi documentation so I think it
> should be
> formatted correctly. I know the mysql stuff is working correctly.
>
> I tried bitbake -e core-image-minmal and I don't get it being set then either.
>
> > >
> > > BR,
> > > Greg
> > >
> > > > -Original Message-
> > > > From: Belisko Marek [mailto:marek.beli...@gmail.com]
> > > > Sent: Tuesday, August 06, 2019 11:12 AM
> > > > To: Greg Wilson-Lindberg
> > > > Cc: Yocto list discussion
> > > > Subject: Re: [yocto] U-boot enable not working for Raspberry Pi3
> > > >
> > > > Hi Greg,
> > > >
> > > > On Tue, Aug 6, 2019 at 7:12 PM Greg Wilson-Lindberg
> > > >
> > > > wrote:
> > > > >
> > > > > I'm working with a Yocto Sumo build provided with Qt's boot2qt
> > > > > system. I'm trying
> > > > to enable using Das U-boot to load Linux as a first step in trying
> > > > to enable OSTree updates.
> > > > >
> > > > > In the meta-raspberrypi documentation is says to set:
> > > > >
> > > > > RPI_USE_U_BOOT = "1"
> > > > Could be tha tboot2qt somehow drop your config. Please try tin run
> > > > bitbake -e | grep ^RPI_USE_U_BOOT to be sure that
> > > > variable exists. I used it many times and it works perfectly fine.
> > > > >
> > > > > to enable u-boot for the raspberrypi. I have set that variable
> > > > > in the top level
> > > > local.conf file but I don't seem to be getting any changes in the
> > > > build. Nothing in the cooker log shows building u-boot, and the
> > > > start up screen doesn't show any u-boot messages.
> > > > >
> > > > > It appears that I'm missing necessary to turn u-boot on, can
> > > > > anybody shed some
> > > > light on what is going on?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Greg Wilson-Lindberg
> > > > > www.sakuraus.com
> > > > > --
> > > > > ___
> > > > > yocto mailing list
> > > > > yocto@yoctoproject.org
> > > > > https://lists.yoctoproject.org/listinfo/yocto
> > > >
> > > > BR,
> > > >
> > > > marek
> > > >
> > > > --
> > > > as simple and primitive as possible
> > > > -
> > > > Marek Belisko - OPEN-NANDRA
> > > > Freelance Developer
> > > >
> > > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > > > Tel: +421
Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.41
On Fri, Aug 2, 2019 at 11:43 PM Paul Gortmaker wrote: > Bruce, Yocto kernel folks: > > Here is the next 4.18.x stable update "extension" primarily created > for the Yocto project, continuing from the previous v4.18.40 release. > > There are about 220 commits here, based on commits chosen from what were > used in the 4.19.46/47 stable releases -- plus some TCP related commits > that were of interest to reach ahead and source from newer 4.19 now. > Not all the 47 content was processed here, in order to keep the release > size sane. The remainder will be considered for the 4.18.42 release. > > And as we enter August, I need to again remind people that the creation > of these 4.18 stable backport releases will be ending relatively soon, > as I'll expect to be moving to newer kernels used in newer Yocto > releases. So people need to get their own maintenance or migration > plans in place as soon as possible, if they have not yet done so. > > I've put this 4.18.x queue through the usual testing; build testing > on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis > and finally some sanity runtime tests on x86-64. > > I did the signed tag just as per the previously released versions. > Please find a signed v4.18.41 tag using this key: > > http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6 > > in the repo in the kernel.org directory here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git > > for merge to standard/base in linux-yocto-4.18 and then out from there > into the other base and BSP branches. > Thanks Paul, this is now merged! Bruce > > For those who are interested, the evolution of the commits is here: > > > https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/ > > This repo isn't needed for anything; it just exists for transparency and > so people can see the evolution of the raw commits that were originally > selected to create this 4.18.x release. > > Paul. > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [kernel-cache master][PATCH][V2] ti-am335x: add the basic scc/cfg enablement
I've merged v2, and created the standard/ti-am335x in linux-yocto-dev. Bruce On Wed, Aug 7, 2019 at 3:54 AM Jun Miao wrote: > Add scc/cfg kernel fragment to build and boot EVM/SK and BeagleBone Black > boards all with am335x soc > > Signed-off-by: Jun Miao > --- > bsp/ti-am335x/ti-am335x-standard.scc | 8 + > bsp/ti-am335x/ti-am335x.cfg | 236 +++ > bsp/ti-am335x/ti-am335x.scc | 8 + > cfg/remoteproc.cfg | 3 + > 4 files changed, 255 insertions(+) > create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc > create mode 100644 bsp/ti-am335x/ti-am335x.cfg > create mode 100644 bsp/ti-am335x/ti-am335x.scc > create mode 100644 cfg/remoteproc.cfg > > diff --git a/bsp/ti-am335x/ti-am335x-standard.scc > b/bsp/ti-am335x/ti-am335x-standard.scc > new file mode 100644 > index ..d357a729 > --- /dev/null > +++ b/bsp/ti-am335x/ti-am335x-standard.scc > @@ -0,0 +1,8 @@ > +define KMACHINE ti-am335x > +define KTYPE standard > +define KARCH arm64 > + > +include ktypes/standard/standard.scc > +branch ti-am335x > + > +include ti-am335x.scc > diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg > new file mode 100644 > index ..77085326 > --- /dev/null > +++ b/bsp/ti-am335x/ti-am335x.cfg > @@ -0,0 +1,236 @@ > +#. > +#WARNING > +# > +# This file is a kernel configuration fragment, and not a full kernel > +# configuration file. The final kernel configuration is made up of > +# an assembly of processed fragments, each of which is designed to > +# capture a specific part of the final configuration (e.g. platform > +# configuration, feature configuration, and board specific hardware > +# configuration). For more information on kernel configuration, please > +# consult the product documentation. > +# > +#. > + > +CONFIG_ARM=y > +CONFIG_ARCH_OMAP=y > +CONFIG_OMAP_DM_TIMER=y > +CONFIG_SOC_AM33XX=y > +CONFIG_ARCH_OMAP2PLUS=y > + > + > +# > +# At least one emulation must be selected > +# > +CONFIG_VFP=y > +CONFIG_VFPv3=y > +CONFIG_NEON=y > + > +# > +# Power management options > +# > + > +CONFIG_PM=y > +CONFIG_REGMAP_IRQ=y > + > +# > +# RAM/ROM/Flash chip drivers > +# > +CONFIG_OMAP_OCP2SCP=y > +CONFIG_MTD=y > +CONFIG_MTD_CMDLINE_PARTS=y > +CONFIG_MTD_BLKDEVS=y > +CONFIG_MTD_BLOCK=y > +CONFIG_MTD_NAND_ECC=y > +CONFIG_MTD_RAW_NAND=y > +CONFIG_MTD_CFI=y > +CONFIG_MTD_CFI_INTELEXT=y > + > +CONFIG_MTD_NAND=y > +CONFIG_MTD_NAND_OMAP2=y > +CONFIG_MTD_NAND_OMAP_BCH=y > +CONFIG_MTD_NAND_OMAP_BCH_BUILD=y > + > +# Misc devices > +CONFIG_EEPROM_AT24=y > +CONFIG_SENSORS_LIS3_I2C=y > +CONFIG_BLK_DEV_SD=y > + > +CONFIG_ETHERNET=y > +CONFIG_NET_VENDOR_TI=y > +CONFIG_TI_DAVINCI_MDIO=y > +CONFIG_TI_DAVINCI_CPDMA=y > +CONFIG_TI_CPSW_PHY_SEL=y > +CONFIG_TI_CPSW_ALE=y > +CONFIG_TI_CPSW=y > +CONFIG_TI_CPTS=y > +CONFIG_PHYLIB=y > + > +CONFIG_SMSC_PHY=y > +CONFIG_FIXED_PHY=y > + > +# > +# Input Device Drivers > +# > + > +CONFIG_INPUT=y > +CONFIG_INPUT_MOUSEDEV=y > +CONFIG_INPUT_EVDEV=y > +CONFIG_INPUT_KEYBOARD=y > +CONFIG_KEYBOARD_GPIO=y > +CONFIG_KEYBOARD_MATRIX=y > +CONFIG_INPUT_TOUCHSCREEN=y > +CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y > +CONFIG_INPUT_MISC=y > +CONFIG_INPUT_TPS65218_PWRBUTTON=m > +CONFIG_SERIAL_EARLYCON=y > + > +# > +# 8250 serial port support > +# > + > +CONFIG_SERIAL_8250=y > +CONFIG_SERIAL_8250_CONSOLE=y > +CONFIG_SERIAL_OF_PLATFORM=y > +CONFIG_SERIAL_8250_OMAP=y > +CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y > + > +CONFIG_SERIAL_CORE=y > +CONFIG_SERIAL_CORE_CONSOLE=y > + > +CONFIG_HW_RANDOM=y > +CONFIG_HW_RANDOM_OMAP=y > + > +# I2C support > +CONFIG_I2C=y > +CONFIG_I2C_CHARDEV=y > +CONFIG_I2C_OMAP=y > +CONFIG_SENSORS_TSL2550=y > +CONFIG_GPIO_TWL4030=y > +CONFIG_PTP_1588_CLOCK=y > +CONFIG_GPIO_PCF857X=y > +CONFIG_PINCTRL=y > +CONFIG_PINCTRL_SINGLE=y > + > +CONFIG_GPIOLIB=y > +CONFIG_OF_GPIO=y > +CONFIG_GPIOLIB_IRQCHIP=y > +CONFIG_GPIO_SYSFS=y > + > +CONFIG_GPIO_OMAP=y > +CONFIG_GPIO_PCA953X=m > +CONFIG_GPIO_TPS65910=y > + > +CONFIG_WATCHDOG=y > +CONFIG_WATCHDOG_CORE=y > +CONFIG_OMAP_WATCHDOG=m > + > +CONFIG_MFD_SYSCON=y > +CONFIG_MFD_TI_AM335X_TSCADC=y > +CONFIG_MFD_OMAP_USB_HOST=y > +CONFIG_MFD_TPS65217=y > +CONFIG_MFD_TPS65218=y > +CONFIG_MFD_TPS65910=y > +CONFIG_TWL6040_CORE=y > + > +# > +# LCD > +# > +CONFIG_DRM=y > +CONFIG_DRM_OMAP=y > +CONFIG_OMAP2_DSS_DPI=y > +CONFIG_DRM_TILCDC=y > +CONFIG_DRM_OMAP_PANEL_DPI=y > +CONFIG_DRM_I2C_NXP_TDA998X=y > + > +CONFIG_BACKLIGHT_LCD_SUPPORT=y > +CONFIG_LCD_CLASS_DEVICE=y > +CONFIG_LCD_PLATFORM=y > +CONFIG_BACKLIGHT_CLASS_DEVICE=y > +CONFIG_BACKLIGHT_GENERIC=y > +CONFIG_PWM=y > +CONFIG_BACKLIGHT_PWM=y > +CONFIG_BACKLIGHT_GPIO=y > + > + > +CONFIG_SOUND=m > +CONFIG_SND=m > +CONFIG_SND_SOC=m > +CONFIG_SND_DAVINCI_SOC_MCASP=m > +CONFIG_SND_SIMPLE_CARD=m > + > + > +#CONFIG_USB_ANNOUNCE_NEW_DEVICES=y > +#CONFIG_USB_MON=m > + > +# > +#
Re: [linux-yocto] [kernel-cache master]: ti-am335x
On Wed, Aug 7, 2019 at 2:01 AM Jun Miao wrote: > > On 8/7/19 10:45 AM, Bruce Ashfield wrote: > > On Tue, Aug 6, 2019 at 6:20 AM Jun Miao wrote: > > > >> Hi Bruce, > >> > >> I am working ti boards(AM335x evm/sk/BBB) with am335x soc. > >> > >> 1.This patch add scc/cfg to yocto-kernel-cache master branch. > >> > > #1 shouldn't be a problem. > > > > 2.Could you help me build a new branch "ti-am335x" in > >> linux-yocto-dev? > >> > >> > > but #2 raises a question. I try and limit the number of BSP specific > > branches. What type of patches are you expecting to put on that branch, > and > > do you expect that they won't be safe for other boards ? > > > > Bruce > > > hi Bruce , > > This branch is prepared for ti-am335x CI/CD development,and there will > be some TI SDK patches into. > > i am afraid that those patches for ti-am335x(evm/sk/bbb) boards will > influence other boards. > We should always try and keep patches clean .. but I understand the reality. I'll create the branch as I merge the kernel-cache parts and we can revisit how long we need a BSP branch in the future. Bruce > > > Thanks > Jun > > > > >> Thanks > >> > >> > >> > >> Jun Miao (1): > >>ti-am335x: add the basic scc/cfg enablement > >> > >> bsp/ti-am335x/ti-am335x-standard.scc | 8 + > >> bsp/ti-am335x/ti-am335x.cfg | 242 +++ > >> bsp/ti-am335x/ti-am335x.scc | 7 + > >> 3 files changed, 257 insertions(+) > >> create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc > >> create mode 100644 bsp/ti-am335x/ti-am335x.cfg > >> create mode 100644 bsp/ti-am335x/ti-am335x.scc > >> > >> -- > >> 2.22.0 > >> > >> > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [kernel-cache][master][PATCH 1/2] bsp/intel-x86: Set CONFIG_NODES_SHIFT to 6
I'm not sure if the intel folks are using these fragments and object to the different behaviour, but they look ok to me. I've merged them for now, but will reconsider if they cause problems in other configs. Bruce On Wed, Aug 7, 2019 at 3:27 AM Yongxin Liu wrote: > This config specifies the maximum number (as a power of 2) of NUMA > Nodes available on the target. 2^6 is big enough for most current > systems. > > Signed-off-by: Yongxin Liu > --- > bsp/intel-x86/intel-x86.cfg | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/bsp/intel-x86/intel-x86.cfg b/bsp/intel-x86/intel-x86.cfg > index 0056be44..c7682a71 100644 > --- a/bsp/intel-x86/intel-x86.cfg > +++ b/bsp/intel-x86/intel-x86.cfg > @@ -20,7 +20,7 @@ CONFIG_SCHED_SMT=y > > CONFIG_NUMA=y > CONFIG_ACPI_NUMA=y > -CONFIG_NODES_SHIFT=2 > +CONFIG_NODES_SHIFT=6 > > CONFIG_EXPERT=y > CONFIG_PROCESSOR_SELECT=y > -- > 2.14.4 > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] nfsd: Move nfsd patch from nfsd-enable.scc to new created nfs.scc
On Wed, Aug 7, 2019 at 3:25 AM wrote: > From: He Zhe > > Remove nfsd patch from nfsd-enable.scc which can be included directly or by > other features, and thus cause re-application of the patch. > > Create nfs.scc to include both configuration and patches for potential > inclusion > for BSPs and/or KTYPEs. > So clearly you are enabling this via a KERNEL_FEATURE, and triggered the double patch. I have no objection to moving it around this way, so this is now merged. Bruce > > Signed-off-by: He Zhe > --- > features/nfsd/nfsd-enable.scc | 1 - > features/nfsd/nfsd.scc| 5 + > 2 files changed, 5 insertions(+), 1 deletion(-) > create mode 100644 features/nfsd/nfsd.scc > > diff --git a/features/nfsd/nfsd-enable.scc b/features/nfsd/nfsd-enable.scc > index ee85152..8a7835d 100644 > --- a/features/nfsd/nfsd-enable.scc > +++ b/features/nfsd/nfsd-enable.scc > @@ -2,4 +2,3 @@ define KFEATURE_DESCRIPTION "Enable NFS server support" > define KFEATURE_COMPATIBILITY all > > kconf non-hardware nfsd.cfg > -patch nfsd4-Fix-kernel-crash-when-reading-proc-file-reply_.patch > diff --git a/features/nfsd/nfsd.scc b/features/nfsd/nfsd.scc > new file mode 100644 > index 000..ee85152 > --- /dev/null > +++ b/features/nfsd/nfsd.scc > @@ -0,0 +1,5 @@ > +define KFEATURE_DESCRIPTION "Enable NFS server support" > +define KFEATURE_COMPATIBILITY all > + > +kconf non-hardware nfsd.cfg > +patch nfsd4-Fix-kernel-crash-when-reading-proc-file-reply_.patch > -- > 2.7.4 > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] Replace busybox by bash
Good advice, thanks Ross. On 8/7/19, Ross Burton wrote: > On 06/08/2019 13:34, JH wrote: >> The busybox is too simple, my application heavy based on shell >> scripts, I have been thinking to dig out the busybox and replace it by >> bash, has anyone remove the busybox to use bash as default shell? How >> large size will be increased and what will be any side effect? > > Removing busybox is not trivial, but you can just install > bash/coreutils/etc as required. > > Yes it's bigger, but you want the full tools. No side effects. > > Ross > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] -staticdev packages not in sdk
>On Tue, 2019-08-06 at 14:04 +, Koeller, Thomas wrote:
>> browsing the list archives I came across an older thread that exactly
>> describes the problem I am currently struggling with:
>>
>> https://lists.yoctoproject.org/pipermail/yocto/2018-February/039950.html
>>
>> In short, I have a recipe that produces only a couple of header files
>> and a single static library, nothing to be installed on the target.
>> So the base package is empty, which is why I have 'ALLOW_EMPTY_${PN}
>> = "1"' in its recipe. In my image definition I have
>> 'SDKIMAGE_FEATURES_append = " staticdev-pkgs"', so I expect the
>> -staticdev package to be included when generating the SDK. This is,
>> however, not the case. While a large number of -staticdev packages
>> from different recipes is now included in the SDK, only the -dev
>> package is included for my recipe, not the -staticdev (though the
>> corresponding rpm is actually built and contains the library as
>> expected, it just is not installed).
>>
>> The archived mail thread referenced above suggests adding the base
>> package ${PN} to IMAGE_INSTALL, which indeed does work for me.
>> However, I do not understand why this is necessary at all, as my
>> package is already referenced from another recipe by being listed in
>> that recipe's DEPENDS variable, shouldn't that be enough?
>
> DEPENDS means its a *build* time dependency. Since nothing links to it
> there is no runtime dependency generated and this empty package you've
> created is never installed into the image.
>
> If its not installed into the image, the SDK for that image won't have
> the corresponding -dev package.
But the -dev image is in fact installed, it is the -staticdev that is
not.
> If you add an RDEPENDS on the empty package to something in the image,
> you'll probably find the -dev package then is installed.
Meanwhile, I tried a different approach:
In bitbake.conf there is a line
DEPCHAIN_POST = "-dev -dbg"
that causes -dev and -dbg packages to pull in the respective packages
generated by recipes that are dependencies. This seemed to explain why
-dev packages were chained while -staticdev were not. I appended
" -staticdev" to that variable (in my image recipe), which IMHO should
be the default. I do not see any reason why -staticdev packages should
be treated differently from -dev in this respect.
Then, I used
ALLOW_EMPTY_${PN}-staticdev = "1"
in my dependent recipe, because that one does not produce a non-empty
-staticdev package.
I chose that approach because to me it appeared to be the cleanest way
to address the problem. Too bad it doesn't work, still only the -dev
packages are included in the SDK. Any idea as to why this did not work
out?
>> Also, the -dev package gets installed into the SDK even without such
>> cruft. As far as I can see, identical logic is applied to both -dev
>> and -staticdev packages, so what is the difference?
>>
>> I also found a different workaround for the problem: listing the
>> -staticdev package in TOOLCHAIN_TARGET_TASK. Needless to say, this
>> workaround is just as undesirable as the former one.
Thomas Koeller
Senior Software Developer
Basler AG
An der Strusbek 60-62
22926 Ahrensburg
Germany
Tel. +49 4102 463 390
Fax +49 4102 463 46 390
thomas.koel...@baslerweb.com
www.baslerweb.com
Management board: Dr.-Ing. Dietmar Ley (CEO) · John P. Jennings · Arndt Bake ·
Hardy Mehl
Chairman of the supervisory board: Norbert Basler
Basler AG · Amtsgericht Lübeck HRB 4090 · Ust-IdNr.: DE 135 098 121 ·
Steuer-Nr.: 30 292 04497 · WEEE-Reg.-Nr. DE 83888045
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to create a service only startes at shutdown process?
On 08/07/2019 04:11 PM, JH wrote: Hi, Most of the services are started in boot, how can I have create a service only to be active in shutdown (not in boot) to clean up? Thank you. Kind regards, - jh Make use of ExecStop, leave ExecStart to be empty. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to create a service only startes at shutdown process?
Hi, Most of the services are started in boot, how can I have create a service only to be active in shutdown (not in boot) to clean up? Thank you. Kind regards, - jh -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [kernel-cache master][PATCH][V2] ti-am335x: add the basic scc/cfg enablement
Add scc/cfg kernel fragment to build and boot EVM/SK and BeagleBone Black boards all with am335x soc Signed-off-by: Jun Miao --- bsp/ti-am335x/ti-am335x-standard.scc | 8 + bsp/ti-am335x/ti-am335x.cfg | 236 +++ bsp/ti-am335x/ti-am335x.scc | 8 + cfg/remoteproc.cfg | 3 + 4 files changed, 255 insertions(+) create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc create mode 100644 bsp/ti-am335x/ti-am335x.cfg create mode 100644 bsp/ti-am335x/ti-am335x.scc create mode 100644 cfg/remoteproc.cfg diff --git a/bsp/ti-am335x/ti-am335x-standard.scc b/bsp/ti-am335x/ti-am335x-standard.scc new file mode 100644 index ..d357a729 --- /dev/null +++ b/bsp/ti-am335x/ti-am335x-standard.scc @@ -0,0 +1,8 @@ +define KMACHINE ti-am335x +define KTYPE standard +define KARCH arm64 + +include ktypes/standard/standard.scc +branch ti-am335x + +include ti-am335x.scc diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg new file mode 100644 index ..77085326 --- /dev/null +++ b/bsp/ti-am335x/ti-am335x.cfg @@ -0,0 +1,236 @@ +#. +#WARNING +# +# This file is a kernel configuration fragment, and not a full kernel +# configuration file. The final kernel configuration is made up of +# an assembly of processed fragments, each of which is designed to +# capture a specific part of the final configuration (e.g. platform +# configuration, feature configuration, and board specific hardware +# configuration). For more information on kernel configuration, please +# consult the product documentation. +# +#. + +CONFIG_ARM=y +CONFIG_ARCH_OMAP=y +CONFIG_OMAP_DM_TIMER=y +CONFIG_SOC_AM33XX=y +CONFIG_ARCH_OMAP2PLUS=y + + +# +# At least one emulation must be selected +# +CONFIG_VFP=y +CONFIG_VFPv3=y +CONFIG_NEON=y + +# +# Power management options +# + +CONFIG_PM=y +CONFIG_REGMAP_IRQ=y + +# +# RAM/ROM/Flash chip drivers +# +CONFIG_OMAP_OCP2SCP=y +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_RAW_NAND=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_INTELEXT=y + +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_OMAP2=y +CONFIG_MTD_NAND_OMAP_BCH=y +CONFIG_MTD_NAND_OMAP_BCH_BUILD=y + +# Misc devices +CONFIG_EEPROM_AT24=y +CONFIG_SENSORS_LIS3_I2C=y +CONFIG_BLK_DEV_SD=y + +CONFIG_ETHERNET=y +CONFIG_NET_VENDOR_TI=y +CONFIG_TI_DAVINCI_MDIO=y +CONFIG_TI_DAVINCI_CPDMA=y +CONFIG_TI_CPSW_PHY_SEL=y +CONFIG_TI_CPSW_ALE=y +CONFIG_TI_CPSW=y +CONFIG_TI_CPTS=y +CONFIG_PHYLIB=y + +CONFIG_SMSC_PHY=y +CONFIG_FIXED_PHY=y + +# +# Input Device Drivers +# + +CONFIG_INPUT=y +CONFIG_INPUT_MOUSEDEV=y +CONFIG_INPUT_EVDEV=y +CONFIG_INPUT_KEYBOARD=y +CONFIG_KEYBOARD_GPIO=y +CONFIG_KEYBOARD_MATRIX=y +CONFIG_INPUT_TOUCHSCREEN=y +CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y +CONFIG_INPUT_MISC=y +CONFIG_INPUT_TPS65218_PWRBUTTON=m +CONFIG_SERIAL_EARLYCON=y + +# +# 8250 serial port support +# + +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_SERIAL_8250_OMAP=y +CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y + +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y + +CONFIG_HW_RANDOM=y +CONFIG_HW_RANDOM_OMAP=y + +# I2C support +CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y +CONFIG_I2C_OMAP=y +CONFIG_SENSORS_TSL2550=y +CONFIG_GPIO_TWL4030=y +CONFIG_PTP_1588_CLOCK=y +CONFIG_GPIO_PCF857X=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_SINGLE=y + +CONFIG_GPIOLIB=y +CONFIG_OF_GPIO=y +CONFIG_GPIOLIB_IRQCHIP=y +CONFIG_GPIO_SYSFS=y + +CONFIG_GPIO_OMAP=y +CONFIG_GPIO_PCA953X=m +CONFIG_GPIO_TPS65910=y + +CONFIG_WATCHDOG=y +CONFIG_WATCHDOG_CORE=y +CONFIG_OMAP_WATCHDOG=m + +CONFIG_MFD_SYSCON=y +CONFIG_MFD_TI_AM335X_TSCADC=y +CONFIG_MFD_OMAP_USB_HOST=y +CONFIG_MFD_TPS65217=y +CONFIG_MFD_TPS65218=y +CONFIG_MFD_TPS65910=y +CONFIG_TWL6040_CORE=y + +# +# LCD +# +CONFIG_DRM=y +CONFIG_DRM_OMAP=y +CONFIG_OMAP2_DSS_DPI=y +CONFIG_DRM_TILCDC=y +CONFIG_DRM_OMAP_PANEL_DPI=y +CONFIG_DRM_I2C_NXP_TDA998X=y + +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y +CONFIG_LCD_PLATFORM=y +CONFIG_BACKLIGHT_CLASS_DEVICE=y +CONFIG_BACKLIGHT_GENERIC=y +CONFIG_PWM=y +CONFIG_BACKLIGHT_PWM=y +CONFIG_BACKLIGHT_GPIO=y + + +CONFIG_SOUND=m +CONFIG_SND=m +CONFIG_SND_SOC=m +CONFIG_SND_DAVINCI_SOC_MCASP=m +CONFIG_SND_SIMPLE_CARD=m + + +#CONFIG_USB_ANNOUNCE_NEW_DEVICES=y +#CONFIG_USB_MON=m + +# +# USB Host Controller Drivers +# +CONFIG_USB=y +CONFIG_USB_SUPPORT=y + +CONFIG_USB_EHCI_HCD=m +CONFIG_USB_EHCI_TT_NEWSCHED=y +CONFIG_USB_EHCI_HCD_OMAP=m +CONFIG_USB_MUSB_HDRC=m + +# +# USB Physical Layer drivers Peripheral Controller +# +CONFIG_USB_PHY=y +CONFIG_NOP_USB_XCEIV=m +CONFIG_AM335X_CONTROL_USB=m +CONFIG_AM335X_PHY_USB=m + +# Platform Glue Layer +CONFIG_USB_MUSB_DSPS=m +CONFIG_USB_MUSB_AM335X_CHILD=m + +# MUSB DMA mode +CONFIG_USB_TI_CPPI41_DMA=y + + +# +# MMC/SD/SDIO Card Drivers +# +CONFIG_MMC=y
[linux-yocto] [kernel-cache][master][PATCH 2/2] bsp/intel-x86: Enable NUMA balancing for intel-x86-64
Add support for automatic NUMA aware memory/task placement. Enable automatic NUMA balancing as default. Signed-off-by: Yongxin Liu --- bsp/intel-x86/intel-x86-64.cfg | 6 ++ 1 file changed, 6 insertions(+) diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg index cd091026..681ba7e1 100644 --- a/bsp/intel-x86/intel-x86-64.cfg +++ b/bsp/intel-x86/intel-x86-64.cfg @@ -1,3 +1,9 @@ +# +# General setup +# +CONFIG_NUMA_BALANCING=y +CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y + # # ACPI NUMA # -- 2.14.4 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [kernel-cache][master][PATCH 1/2] bsp/intel-x86: Set CONFIG_NODES_SHIFT to 6
This config specifies the maximum number (as a power of 2) of NUMA Nodes available on the target. 2^6 is big enough for most current systems. Signed-off-by: Yongxin Liu --- bsp/intel-x86/intel-x86.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsp/intel-x86/intel-x86.cfg b/bsp/intel-x86/intel-x86.cfg index 0056be44..c7682a71 100644 --- a/bsp/intel-x86/intel-x86.cfg +++ b/bsp/intel-x86/intel-x86.cfg @@ -20,7 +20,7 @@ CONFIG_SCHED_SMT=y CONFIG_NUMA=y CONFIG_ACPI_NUMA=y -CONFIG_NODES_SHIFT=2 +CONFIG_NODES_SHIFT=6 CONFIG_EXPERT=y CONFIG_PROCESSOR_SELECT=y -- 2.14.4 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH] nfsd: Move nfsd patch from nfsd-enable.scc to new created nfs.scc
From: He Zhe Remove nfsd patch from nfsd-enable.scc which can be included directly or by other features, and thus cause re-application of the patch. Create nfs.scc to include both configuration and patches for potential inclusion for BSPs and/or KTYPEs. Signed-off-by: He Zhe --- features/nfsd/nfsd-enable.scc | 1 - features/nfsd/nfsd.scc| 5 + 2 files changed, 5 insertions(+), 1 deletion(-) create mode 100644 features/nfsd/nfsd.scc diff --git a/features/nfsd/nfsd-enable.scc b/features/nfsd/nfsd-enable.scc index ee85152..8a7835d 100644 --- a/features/nfsd/nfsd-enable.scc +++ b/features/nfsd/nfsd-enable.scc @@ -2,4 +2,3 @@ define KFEATURE_DESCRIPTION "Enable NFS server support" define KFEATURE_COMPATIBILITY all kconf non-hardware nfsd.cfg -patch nfsd4-Fix-kernel-crash-when-reading-proc-file-reply_.patch diff --git a/features/nfsd/nfsd.scc b/features/nfsd/nfsd.scc new file mode 100644 index 000..ee85152 --- /dev/null +++ b/features/nfsd/nfsd.scc @@ -0,0 +1,5 @@ +define KFEATURE_DESCRIPTION "Enable NFS server support" +define KFEATURE_COMPATIBILITY all + +kconf non-hardware nfsd.cfg +patch nfsd4-Fix-kernel-crash-when-reading-proc-file-reply_.patch -- 2.7.4 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
