Re: [yocto] [PATCH yocto-autobuilder-helper] run-docs-build: build from tags dynamically instead of static list
On Wed, Apr 7, 2021 at 10:16 AM Nicolas Dechesne < nicolas.deche...@linaro.org> wrote: > hey! > > On Wed, Apr 7, 2021 at 9:31 AM Quentin Schulz wrote: > >> Hi Michael, >> >> On April 6, 2021 10:58:20 PM UTC, Michael Halstead < >> mhalst...@linuxfoundation.org> wrote: >> >All new releases are Sphinx ready so we exclude old tags and build for >> >all the rest. >> > > Thanks for starting this! > > >> > >> >Signed-off-by: Michael Halstead >> >--- >> > scripts/run-docs-build | 14 ++ >> > 1 file changed, 10 insertions(+), 4 deletions(-) >> > >> >diff --git a/scripts/run-docs-build b/scripts/run-docs-build >> >index 910f03d..13df34a 100755 >> >--- a/scripts/run-docs-build >> >+++ b/scripts/run-docs-build >> >@@ -7,6 +7,7 @@ ypdocs=$2/documentation/ >> > bbdocs=$3/doc/ >> > docs_buildtools=/srv/autobuilder/ >> autobuilder.yoctoproject.org/pub/buildtools/x86_64-buildtools-docs-nativesdk-standalone-3.2+snapshot-20201105.sh >> > outputdir=$builddir/output >> >+excluded_tags="yocto-3.1.4 yocto-3.1.3 yocto-3.1.2 yocto-3.1.1 >> yocto-3.1 yocto-3.0.1 yocto-3.0 yocto-2.6.4 yocto-2.6.3 yocto-2.7.1 >> yocto-2.6.2 yocto-2.7 yocto-2.6.1 yocto-2.6 yocto-2.5.2 yocto-2.5.1 >> yocto-2.4.4 yocto-2.4.3 yocto-2.5 yocto-2.3.4 yocto-1.0.2 yocto-1.1.2 >> yocto-1.2.2 yocto-1.2.1 yocto-1.3 yocto-1.3.1 yocto-1.3.2 yocto-1.4.3 >> yocto-1.4.2 yocto-1.4.1 yocto-1.4 yocto-2.1.3 yocto-2.4.2 yocto-2.1.1 >> yocto-2.1.2 yocto-2.0.3 yocto-1.8.2 yocto-2.2.3 yocto-2.4.1 yocto-2.3.3 >> yocto-2.3.2 yocto-2.4 yocto-2.2.2 yocto-2.3.1 yocto-2.3 yocto-2.2.1 >> yocto-2.0.2 yocto-2.2 yocto-2.1 yocto-2.0.1 yocto-2.0 yocto-1.8.1 >> yocto-1.7.3 yocto-1.6.3 yocto-1.7.2 yocto-1.8 yocto-1.5.1" >> > >> > >> > cd $builddir >> >@@ -77,13 +78,18 @@ for branch in dunfell gatesgarth hardknott; do >> > done >> > >> > # Yocto Project releases/tags >> >-for tag in 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3; do >> >+cd $ypdocs >> >+for tag in $(git tag -l |grep 'yocto-' |sort); do >> >> IIUC the man page, >> git tag --list 'yocto-*' | sort >> > > sort -V is even better since it does "natural sort of (version) numbers > within text", let's get ready for 3.10 ;) > > And using -V, how about something along these lines: > > v_sphinx='yocto-3.1.5' > for v in $(git tag --list 'yocto-*'); do > first=$(printf '%s\n%s' $v $v_sphinx | sort -V | head -n1) > if [ "$first" = "$v_sphinx" ]; then > echo "Yocto $v uses Sphinx!" > fi > done > > and it outputs the following when I run it locally: > > Yocto yocto-3.1.5 uses Sphinx! > Yocto yocto-3.1.6 uses Sphinx! > Yocto yocto-3.2 uses Sphinx! > Yocto yocto-3.2.1 uses Sphinx! > Yocto yocto-3.2.2 uses Sphinx! > Yocto yocto-3.2.3 uses Sphinx! > > > > would be doing the same thing as the one command with grep above. >> Discovered it recently so just wanted to share. >> >> I guess this is something we can also do for bitbake Sphinx documentation? >> > > yes. > Well, in fact no , we shouldn't, is a short answer ;) Here is the long answer.. For bitbake and YP, we currently publish: master, master-next and 'stable' branches (e.g. 1.46, 1.48, 1.50 for bitbake dunfell, gatesgarth, hardknott for YP). Then we also publish YP releases (and point releases), e.g. 3.1.5 and beyond, but we don't publish anything for releases/point release of bitbake, At least just yet. And it's a 'bug'. Since the YP docs includes links (with intersphinx) to bitbake docs, then when we look at a master, master-next or any branches on docs.yp.org, then the links are correct. for example if you look at https://docs.yoctoproject.org/dunfell/what-i-wish-id-known.html vs https://docs.yoctoproject.org/gatesgarth/what-i-wish-id-known.html this page has links to bitbake and it points respectively to: https://docs.yoctoproject.org/bitbake/1.46/bitbake-user-manual/bitbake-user-manual-intro.html#generating-dependency-graphs and https://docs.yoctoproject.org/bitbake/1.48/bitbake-user-manual/bitbake-user-manual-intro.html#generating-dependency-graphs Which is correct. [Side note: I've noticed that the hardknott page is wrong, since https://docs.yoctoproject.org/hardknott/what-i-wish-id-known.html and the following link > https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-intro.html#generating-dependency-graphs I will send a patch for that] Now if we look at a YP release, such as https://docs.yoctoproject.org/3.1.6/what-i-wish-id-known.html it has this link: https://docs.yoctoproject.org/bitbake/1.46/bitbake-user-manual/bitbake-user-manual-intro.html#generating-dependency-graphs which is not correct, since it links to a bitbake 'branch' docs build, and not a bitbake 'release' docs build. > >> >> Removed the git context inadvertently but, is =~ some bash built-in? I >> don't know what's the shebang on top but maybe we want to force it to bash >> since I'm not sure it's POSIX "compliant" anymore? > > > It is bash already. > > >> >> Reviewed-by: Quentin Schulz >> >> Thanks, >> Quentin >> > -=-=-=-=-=-=-=-=-=-=-=- Links:
Re: [yocto] No significant diff b/w qemux86 and qemuarm poky build of core-image-minimal
On Tue, Mar 30, 2021 at 2:20 PM Khem Raj wrote: > > > > On 3/30/21 1:48 PM, Ross Burton wrote: > > On Tue, 30 Mar 2021 at 20:41, Khem Raj wrote: > >> Thanks for this infor Randy, really appreciated, I think I will also > >> look at the h/w angle. > > > > Khem: if you can reproduce this on demand with a clean build (ie > > oe-init-build-env with a clean build directory, just set DL_DIR) then > > enabling buildstats would give some interesting metrics. > > buildstats-diff can compare two build runs and tell you what the > > differences are. > > > > yeah this is doing world build of not only core but several other layers > included a usual build takes around 10 hrs for this machine config, I am > planning to > > 1. Collect build stats > 2. buiid another qemu machine on this VM > > it could very well be rotting hardware underneath the VM. > To close the loop, it turned out to be the case that CPU performance on VM has deteriorated which stress-ng showed. The VM has been rebuilt and everything seems to be holding fine now. Thanks for your help and chiming in. > > Ross > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53057): https://lists.yoctoproject.org/g/yocto/message/53057 Mute This Topic: https://lists.yoctoproject.org/mt/81730917/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH v2 yocto-autobuilder-helper] run-docs-build: build from tags dynamically instead of static list
Build Sphinx docs for all versions newer than yocto-3.1.5 inclusive. Integrate suggestions from Quentin Schulz and Nicolas Dechesne. Signed-off-by: Michael Halstead --- scripts/run-docs-build | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/scripts/run-docs-build b/scripts/run-docs-build index 910f03d..52bd567 100755 --- a/scripts/run-docs-build +++ b/scripts/run-docs-build @@ -77,13 +77,19 @@ for branch in dunfell gatesgarth hardknott; do done # Yocto Project releases/tags -for tag in 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3; do -cd $ypdocs -git checkout yocto-$tag -make clean -make publish -mkdir $outputdir/$tag -cp -r ./_build/final/* $outputdir/$tag +v_sphinx='yocto-3.1.5' #This and newer versions have Sphinx docs. +cd $ypdocs +for tag in $(git tag --list 'yocto-*'); do +first=$(printf '%s\n%s' $tag $v_sphinx | sort --version-sort | head -n1) +if [ "$first" = "$v_sphinx" ]; then +cd $ypdocs +git checkout $tag +make clean +make publish +version=$(echo $tag | cut -c7-) +mkdir $outputdir/$version +cp -r ./_build/final/* $outputdir/$version +fi done # Update switchers.js with the copy from master ypdocs -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53056): https://lists.yoctoproject.org/g/yocto/message/53056 Mute This Topic: https://lists.yoctoproject.org/mt/81928997/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Yocto Project Summit - registration open
Registration is now open for the upcoming Yocto Project Summit!! details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/ CfP: https://pretalx.com/yocto-project-summit-2021/cfp registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501 PS: Don't forget to get in your talk proposals! The CfP closes April 25th -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53055): https://lists.yoctoproject.org/g/yocto/message/53055 Mute This Topic: https://lists.yoctoproject.org/mt/81925790/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Yocto Technical Team Minutes, Engineering Sync, for April 6, 2021
Yocto Technical Team Minutes, Engineering Sync, for April 6, 2021 archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == announcements == The upcoming Yocto Project Summit is taking place May 25-26 2021 details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/ CfP: https://pretalx.com/yocto-project-summit-2021/cfp registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501 == disclaimer == Best efforts are made to ensure the below is accurate and valid. However, errors sometimes happen. If any errors or omissions are found, please feel free to reply to this email with any corrections. == attendees == Trevor Woerner, Stephen Jolley, Richard Purdie, Steve Sakoman, Peter Kjellerstedt, Armin Kuster, Scott Murray, Michael Halstead, Bruce Ashfield, Saul Wold, Joshua Watt, Jon Mason, Jan-Simon Möller, Randy MacLeod, Paul Barker, Denys Dmytriyenko, Rob Wolley, sakib.sajal@windriver, Tim Orling, Ross Burton, Philip Ballister, Daiane Angolini, Trevor Gamblin, Alejandro H == notes == - close to building 3.3-rc1 - still need changelog, migration guide, release notes, etc - released 3.2.3 - change to allow qemu to run from tmpfs - can’t use cgroups - lots of version upgrades, need to wait for 3.4 - ~50 intermittent AB issues - planning doc available for 3.4 == general == RP: still thinking about what to do with docs for 3.3, still need to wait on changelog, migration, release notes before we can release RP: lots of I/O copying the qemu images before starting up the tests, causing some of the timeouts, therefore the move to running from tmpfs Bruce: there are some perf-tests things missing from master-next RP: oops, missed it SteveS: is the tmpfs something we want to backport to dunfell RP: ultimately yes. low risk. but give it time on the AB first before merging. should be a nice simple change StephenJ: we were supposed to do a 3.1.7 last week but there wasn’t anything for it SteveS: i didn’t want to get in the way of master releases. there is another bitbake change that i’d like to get in too, but we can do that anytime StephenJ: we’ll want it behind the master release, but it should come out sometime this month. i also have 3.1.8, 3.1.9, and 3.1.10 in the planning docs, as milestones RP: we’ll get 3.3 build, then we can do the next 3.1.y after that PaulB: prserv modernization (async-io json-rpc startup/shutdown readonly-mode) i’ve now got all that done, oe-selftest is passing, bitbake self-test is passing. still have another day of tidying up. should it be sent as an RFC? RP: it’s good timing. i think it’s 3.4 material and it’s a good time to put it out there (see 3.4 planning doc). RP: PaulG also put out some patches to make the fetcher more efficient regarding kernel fetching which also sounds like 3.4 material. master-next is where i’m putting 3.4 things for now. PaulB: i think they’re all bitbake patches, and there’s one oe-core patch. for the RFC i’ll just send it all together and we can split them up later JPEW: can you CC me please PaulB: np Randy: memory-resident bitbake as the default? RP: i’d like to see it, but depends on whether we can get all the bugs worked out before. the blocker was that enabling it for oe-selftest causes carnage. we need to figure out why, it shouldn’t cause any issues, but it does. once we can get oe-selftest working then i’m game for enabling it by default and simply fixing anything that comes up. this change retrofits bitbake to do something it wasn’t designed to do. there’s some assumption somewhere that’s being violated that we don’t know RP: the tmpfs change i just made is a good example of showing you how to change every test TrevorG: re doc change, i submitted a v2 (thanks MichaelO for review) and added instructions. i think we want something added to the -dev manual? RP: yes, we now have a doc person and we want to cover the AB in the test manual. the test manual we currently have is just a start, mostly pointers, but i’d like to see it expanded TimO: i’d like to add a ptest for python or ptest for perl section too to the test manual RP: re AB-int. can we list out what’s in the I/O queue that the kernel is processing? i’m guessing not (security reasons) but it would be great if it could. in the past we’ve listed out processes that are occurring when failures occur; that allowed us to identify an issue with building webkit, but there’s only so much a process listing will give us and there are other stats we should look at at failure time Randy: yes, we’ve looked at a bunch of stuff, but most of them need root permissions RP: if the tools are standard then we can give access to those tools to the poky builder user RP: with more tooling we’ll probably see a lot of these qemu startup issues and we’ll probably also see lots of
Re: [linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: patches to fix build error and debug calltrace
In message: [linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: patches to fix build error and debug calltrace on 07/04/2021 Zhantao Tang wrote: > > Hi Bruce, > > > There are 2 patches to update the linux-yocto, branch > v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx. > > patch[0001]: drivers: mailbox: replace mutex with spinlock in llce_mailbox > this patch is to fix debug calltrace due to may sleep mutex called in > atomic context. > > patch[0002]: drivers: crypto: hse: replace devm_ioremap_nocache with > devm_ioremap > this patch is to fix the hse uio driver build error. > > > Would you please help to merge these two patches into linux-ycoto kernel, > v5.10, branch is v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx? merged. Bruce > > > Thanks, > Zhantao > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9718): https://lists.yoctoproject.org/g/linux-yocto/message/9718 Mute This Topic: https://lists.yoctoproject.org/mt/81913009/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [yocto-kernel-cache yocto-5.10]: nxp-s32g2xx: add HSE UIO related configs to make hse demo work
In message: [linux-yocto] [yocto-kernel-cache yocto-5.10]: nxp-s32g2xx: add HSE UIO related configs to make hse demo work on 07/04/2021 Zhantao Tang wrote: > > Hi Bruce, > > On S32G platform, there is a HSE demo for linux, which depends on UIO configs > enablement. > The following patch is to fix this. > > Would you please help to merge this patch into yocto-kernel-cache, branch is > yocto-5.10 ? merged. Bruce > > > Thanks, > Zhantao -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9717): https://lists.yoctoproject.org/g/linux-yocto/message/9717 Mute This Topic: https://lists.yoctoproject.org/mt/81912979/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [[linux-yocto][linux-yocto v5.4/standard/preempt-rt/intel-x86] x86/alternatives: Acquire pte lock with interrupts enabled
Since this isn't rt-only, and is part of the upstream kernel (but apparently not nomiated for 5.4-stable backporting), I'd prefer to merge this to all branches, versus just the intel-x86 preempt-rt. I'll do that tomorrow, unless I hear objections. Bruce In message: [[linux-yocto][linux-yocto v5.4/standard/preempt-rt/intel-x86] x86/alternatives: Acquire pte lock with interrupts enabled on 07/04/2021 Jun Miao wrote: > From: Sebastian Andrzej Siewior > > commit a6d996cbd38b42341ad3fce74506b9fdc280e395 upstream > > pte lock is never acquired in-IRQ context so it does not require interrupts > to be disabled. The lock is a regular spinlock which cannot be acquired > with interrupts disabled on RT. > > RT complains about pte_lock() in __text_poke() because it's invoked after > disabling interrupts. > > __text_poke() has to disable interrupts as use_temporary_mm() expects > interrupts to be off because it invokes switch_mm_irqs_off() and uses > per-CPU (current active mm) data. > > Move the PTE lock handling outside the interrupt disabled region. > > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Thomas Gleixner > Acked-by; Peter Zijlstra (Intel) > Link: https://lore.kernel.org/r/20200813105026.bvugytmsso6mu...@linutronix.de > Signed-off-by: Jun Miao > --- > arch/x86/kernel/alternative.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c > index c826cddae157..34a1b8562c31 100644 > --- a/arch/x86/kernel/alternative.c > +++ b/arch/x86/kernel/alternative.c > @@ -874,8 +874,6 @@ static void *__text_poke(void *addr, const void *opcode, > size_t len) >*/ > BUG_ON(!pages[0] || (cross_page_boundary && !pages[1])); > > - local_irq_save(flags); > - > /* >* Map the page without the global bit, as TLB flushing is done with >* flush_tlb_mm_range(), which is intended for non-global PTEs. > @@ -892,6 +890,8 @@ static void *__text_poke(void *addr, const void *opcode, > size_t len) >*/ > VM_BUG_ON(!ptep); > > + local_irq_save(flags); > + > pte = mk_pte(pages[0], pgprot); > set_pte_at(poking_mm, poking_addr, ptep, pte); > > @@ -941,8 +941,8 @@ static void *__text_poke(void *addr, const void *opcode, > size_t len) >*/ > BUG_ON(memcmp(addr, opcode, len)); > > - pte_unmap_unlock(ptep, ptl); > local_irq_restore(flags); > + pte_unmap_unlock(ptep, ptl); > return addr; > } > > -- > 2.25.1 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9716): https://lists.yoctoproject.org/g/linux-yocto/message/9716 Mute This Topic: https://lists.yoctoproject.org/mt/81911651/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-imx8][PATCH] tools: perf: Fix the undefined build errors in metricgroup__print()
merged. Bruce In message: [linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-imx8][PATCH] tools: perf: Fix the undefined build errors in metricgroup__print() on 07/04/2021 Xiaolei Wang wrote: > Because the patch taken out from linux-imx puts free(s) in the wrong > position, a build error appears > > Fixes: 40be8dc54887(tools: perf: metricgroup: add metricgroup for each PMU) > > Signed-off-by: Xiaolei Wang > --- > tools/perf/util/metricgroup.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c > index cc31fd0741e5..b31cf4cb7b3a 100644 > --- a/tools/perf/util/metricgroup.c > +++ b/tools/perf/util/metricgroup.c > @@ -576,11 +576,11 @@ void metricgroup__print(bool metrics, bool > metricgroups, char *filter, > continue; > strlist__add(me->metrics, s); > } > + if (!raw) > + free(s); > } > free(omg); > > - if (!raw) > - free(s); > } > } > } > -- > 2.25.1 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9715): https://lists.yoctoproject.org/g/linux-yocto/message/9715 Mute This Topic: https://lists.yoctoproject.org/mt/81911633/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: drivers: net: phy: drop unneeded codes in nxp phy config init
In message: [linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: drivers: net: phy: drop unneeded codes in nxp phy config init on 07/04/2021 Zhantao Tang wrote: > > Hi Bruce, > > > There are some unneeded codes in nxp phy driver need to drop, the following > patch is to do this. > > Would you please help to merge this patch into linux-ycoto kernel, v5.10, > branch is v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx? merged. Bruce > > > Thanks, > Zhantao > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9714): https://lists.yoctoproject.org/g/linux-yocto/message/9714 Mute This Topic: https://lists.yoctoproject.org/mt/81911545/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [v5.10] [yocto-kernel-cache] [PATCH] firmware: fix CONFIG_FW_LOADER option mismatch warning
merged. FW_LOADER is definitely one of the options we have to keep adjusting per BSP. I also merged this to master. Bruce In message: [linux-yocto] [v5.10] [yocto-kernel-cache] [PATCH] firmware: fix CONFIG_FW_LOADER option mismatch warning on 07/04/2021 qiang.zh...@windriver.com wrote: > From: Zqiang > > [NOTE]: 'CONFIG_FW_LOADER' last val (m) and .config val (y) do not match > [INFO]: CONFIG_FW_LOADER : y ## .config: 1632 > :configs/v5.10/ktypes/base/base.cfg (m) > [INFO]: selection details for 'CONFIG_FW_LOADER': > Symbols currently y-selecting this symbol: > - R8169 > > Replace CONFIG_R8169 value from 'y' to 'm' > > Signed-off-by: Zqiang > --- > 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 deb0caf3..a5c79cea 100644 > --- a/bsp/intel-x86/intel-x86.cfg > +++ b/bsp/intel-x86/intel-x86.cfg > @@ -318,7 +318,7 @@ CONFIG_DMA_CMA=y > # Realtek Network Driver > CONFIG_STAGING=y > CONFIG_NET_VENDOR_REALTEK=y > -CONFIG_R8169=y > +CONFIG_R8169=m > > # Marvell WiFi-Ex Driver for PCIE 8766/8897/8997 > CONFIG_MWIFIEX=m > -- > 2.29.2 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9713): https://lists.yoctoproject.org/g/linux-yocto/message/9713 Mute This Topic: https://lists.yoctoproject.org/mt/81909021/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console
On Wed, Apr 7, 2021 at 9:27 AM Joshua Watt wrote: > Please add Upstream-Status: https://wiki.yoctoproject.org/wiki/Best_Known_Methods_(BKMs)_for_Package_Updating#Patch_Upstreaming -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53053): https://lists.yoctoproject.org/g/yocto/message/53053 Mute This Topic: https://lists.yoctoproject.org/mt/81904391/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console
On 4/6/21 6:47 PM, Yann Dirson wrote:
From: Yann Dirson
TF-A runs between two u-boot stages which both uses 150 baud, it
just makes no sense to use the same UART at a different rate.
Here is a sample session with the successive stages, with TF-A artificially
separated for emphasis:
[20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43)
[20210406-175438.135956] Channel 0: DDR3, 933MHz
[20210406-175438.236974] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16
Size=1024MB
[20210406-175438.237000] Channel 1: DDR3, 933MHz
[20210406-175438.237004] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16
Size=1024MB
[20210406-175438.237008] 256B stride
[20210406-175438.237012] Trying to boot from BOOTROM
[20210406-175438.237015] Returning to boot ROM...
[20210406-175438.237018]
[20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +)
[20210406-175438.573431] Trying to boot from MMC1
[20210406-175438.589254] NOTICE: BL31: v2.3():v2.3-dirty
[20210406-175440.534055] NOTICE: BL31: Built : 15:56:43, Apr 20 2020
[20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +)
[20210406-175441.393429]
[20210406-175441.393433] SoC: Rockchip rk3399
Very good. TF-A should work "out of the box" in meta-rockchip, so I
think changing it's baudrate to 150 makes sense at this point (at
least until u-boot can pass the DTB)
Signed-off-by: Yann Dirson
---
.../files/serial-console-baudrate.patch | 35 +++
.../trusted-firmware-a_%.bbappend | 5 +++
2 files changed, 40 insertions(+)
create mode 100644
recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
new file mode 100644
index 000..10b5a2b
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
@@ -0,0 +1,35 @@
+From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
+From: Yann Dirson
+Date: Tue, 6 Apr 2021 17:28:45 +0200
+Subject: [PATCH] Set serial console baudrate back to 150.
+
+TF-A runs between two u-boot stages which both uses 150 baud, it
+just makes no sense to use the same UART at a different rate.
+
+This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
+Main reason for that change stated in
https://developer.trustedfirmware.org/T762
+is ChromeOS compatibility.
+
+Looks like this patch may become unnecessary in the future, when
+u-boot and TF-A get to communicate this value.
Please add Upstream-Status:
+
+---
+ plat/rockchip/rk3399/rk3399_def.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/rk3399_def.h
b/plat/rockchip/rk3399/rk3399_def.h
+index ba83242eb..8d6ecfbe6 100644
+--- a/plat/rockchip/rk3399/rk3399_def.h
b/plat/rockchip/rk3399/rk3399_def.h
+@@ -17,7 +17,7 @@
+ /**
+ * UART related constants
+ **/
+-#define RK3399_BAUDRATE 115200
++#define RK3399_BAUDRATE 150
+ #define RK3399_UART_CLOCK 2400
+
+
/**
+--
+2.30.2
+
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 442dee8..1942c17 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,3 +4,8 @@ DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native"
COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"
COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+SRC_URI += "\
+file://serial-console-baudrate.patch \
+"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53052): https://lists.yoctoproject.org/g/yocto/message/53052
Mute This Topic: https://lists.yoctoproject.org/mt/81904391/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] QA notification for completed autobuilder build (yocto-3.3.rc2)
A build flagged for QA (yocto-3.3.rc2) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.3.rc2 Build hash information: bitbake: a1848a481e36b729c8e4130c394b1d462d4b488a meta-arm: 219fd34b7676ffedd1a1ad3626ec4337391975f4 meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f meta-intel: 01cfc99a8f960917433a8a46b41bb4febb5b1993 meta-kernel: 29329d7cacc71595cecfdd05a455a0cfb164564d meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e oecore: 14241ed09f9ed317045cf75a6d08416d3579bb8d poky: e1839b58ebe05242a52fe050aa9a08140136aa0a This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53051): https://lists.yoctoproject.org/g/yocto/message/53051 Mute This Topic: https://lists.yoctoproject.org/mt/81913830/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [kernel-cache yocto-5.10] qemuppc64: Enable the RTC driver
Enable the RTC driver to fix the following warning in boot: hwclock: can't open '/dev/misc/rtc': No such file or directory Signed-off-by: Kevin Hao --- bsp/qemu-ppc64/qemu-ppc64.cfg | 3 +++ 1 file changed, 3 insertions(+) diff --git a/bsp/qemu-ppc64/qemu-ppc64.cfg b/bsp/qemu-ppc64/qemu-ppc64.cfg index 9aac06de0eb6..b2a5194dd1d1 100644 --- a/bsp/qemu-ppc64/qemu-ppc64.cfg +++ b/bsp/qemu-ppc64/qemu-ppc64.cfg @@ -73,3 +73,6 @@ CONFIG_USB_XHCI_PCI=y CONFIG_USB_XHCI_PLATFORM=y CONFIG_DRM_BOCHS=n + +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_GENERIC=y -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9712): https://lists.yoctoproject.org/g/linux-yocto/message/9712 Mute This Topic: https://lists.yoctoproject.org/mt/81913368/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 2/2] drivers: crypto: hse: replace devm_ioremap_nocache with devm_ioremap
According to upstream commit 4bdc0d676a64("remove
ioremap_nocache and devm_ioremap_nocache "), replace
devm_ioremap_nocache() with devm_ioremap().
Signed-off-by: Zhantao Tang
---
drivers/crypto/hse/hse-uio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/hse/hse-uio.c b/drivers/crypto/hse/hse-uio.c
index c75e719b94ba..5b916a41732f 100644
--- a/drivers/crypto/hse/hse-uio.c
+++ b/drivers/crypto/hse/hse-uio.c
@@ -202,7 +202,7 @@ void *hse_uio_register(struct device *dev, void *mu)
priv->info.priv = priv;
/* map HSE shared RAM area */
- priv->shm = devm_ioremap_nocache(dev, HSE_SHARED_RAM_ADDR,
+ priv->shm = devm_ioremap(dev, HSE_SHARED_RAM_ADDR,
HSE_SHARED_RAM_SIZE);
if (IS_ERR_OR_NULL(priv->shm))
return ERR_PTR(-ENOMEM);
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9711):
https://lists.yoctoproject.org/g/linux-yocto/message/9711
Mute This Topic: https://lists.yoctoproject.org/mt/81913015/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/2] drivers: mailbox: replace mutex with spinlock in llce_mailbox
This patch is to fix the following debug calltrace:
BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:1149
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 4974, name: ip
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<>] 0x0
hardirqs last disabled at (0): []
copy_process+0x2e4/0x1000
softirqs last enabled at (0): []
copy_process+0x2e4/0x1000
softirqs last disabled at (0): [<>] 0x0
Preemption disabled at:
[] msg_submit+0x2c/0x100
CPU: 2 PID: 4974 Comm: ip Tainted: G W 5.4.105-yocto-standard
#1
Hardware name: Freescale S32G274 (DT)
Call trace:
dump_backtrace+0x0/0x184
show_stack+0x28/0x34
dump_stack+0xd0/0x12c
___might_sleep+0x1a4/0x244
__might_sleep+0x5c/0x90
mutex_lock_io_nested+0x68/0x8bc
execute_config_cmd.isra.0+0x40/0xe0 [llce_mailbox]
llce_mb_send_data+0xe0/0x234 [llce_mailbox]
msg_submit+0xa8/0x100
mbox_send_message+0x84/0x120
llce_can_init+0x94/0x110 [llce_can]
llce_can_open+0x4c/0x1e0 [llce_can]
__dev_open+0x108/0x1b0
__dev_change_flags+0x1b4/0x220
dev_change_flags+0x40/0x80
do_setlink+0x1f8/0x930
__rtnl_newlink+0x51c/0x7c4
rtnl_newlink+0x58/0x80
rtnetlink_rcv_msg+0x18c/0x490
netlink_rcv_skb+0x60/0x120
rtnetlink_rcv+0x2c/0x3c
netlink_unicast+0x184/0x224
netlink_sendmsg+0x1a0/0x340
sys_sendmsg+0x1c8/0x214
___sys_sendmsg+0x94/0xec
__sys_sendmsg+0x7c/0xd0
__arm64_sys_sendmsg+0x30/0x3c
el0_svc_common.constprop.0+0x78/0x13c
el0_svc_handler+0x80/0xa0
el0_svc+0x8/0x208
IPv6: ADDRCONF(NETDEV_CHANGE): llcecan0: link becomes ready
The root cause of this issue is that,
in msg_submit()(in drivers/mailbox/mailbox.c) the irq will be disabled by
spin_lock_irqsave(>lock, flags)
then llce_mb_send_data()(in drivers/mailbox/llce-mailbox.c) will
execute mutex_lock_io(), this mutex may sleep, so the calltrace shows.
So replace the mutex with spinlock to fix it.
Signed-off-by: Zhantao Tang
Signed-off-by: Bruce Ashfield
---
drivers/mailbox/llce-mailbox.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/mailbox/llce-mailbox.c b/drivers/mailbox/llce-mailbox.c
index 19682eefef30..a17fe52508dd 100644
--- a/drivers/mailbox/llce-mailbox.c
+++ b/drivers/mailbox/llce-mailbox.c
@@ -69,7 +69,7 @@ struct llce_mb {
struct llce_fifoirq rxin_irqs;
struct llce_fifoirq rxout_irqs;
struct llce_fifoirq txack_irqs;
- struct mutex txack_lock;
+ spinlock_t txack_lock;
struct llce_can_shared_memory *sh_mem;
void __iomem *rxout_fifo;
void __iomem *rxin_fifo;
@@ -448,8 +448,9 @@ static int execute_config_cmd(struct mbox_chan *chan,
struct llce_can_command *sh_cmd;
void __iomem *txack, *push0;
int ret = 0;
+ unsigned long flags;
- mutex_lock_io(>txack_lock);
+ spin_lock_irqsave(>txack_lock, flags);
txack = get_host_txack(mb, LLCE_CAN_HIF0);
@@ -469,7 +470,7 @@ static int execute_config_cmd(struct mbox_chan *chan,
writel(idx, push0);
release_lock:
- mutex_unlock(>txack_lock);
+ spin_unlock_irqrestore(>txack_lock, flags);
return ret;
}
@@ -719,11 +720,12 @@ static bool llce_mb_last_tx_done(struct mbox_chan *chan)
struct llce_mb *mb = priv->mb;
struct llce_can_command *cmd;
struct llce_can_command *sh_cmd;
+ unsigned long flags;
if (!is_config_chan(priv->type))
return false;
- mutex_lock_io(>txack_lock);
+ spin_lock_irqsave(>txack_lock, flags);
txack = get_host_txack(mb, LLCE_CAN_HIF0);
@@ -735,7 +737,7 @@ static bool llce_mb_last_tx_done(struct mbox_chan *chan)
memcpy(cmd, sh_cmd, sizeof(*cmd));
- mutex_unlock(>txack_lock);
+ spin_unlock_irqrestore(>txack_lock, flags);
if (priv->type != S32G274_LLCE_HIF_CONF_MB)
llce_mbox_chan_received_data(chan, cmd);
@@ -1447,7 +1449,7 @@ static int llce_mb_probe(struct platform_device *pdev)
if (!mb)
return -ENOMEM;
- mutex_init(>txack_lock);
+ spin_lock_init(>txack_lock);
ctrl = >controller;
ctrl->txdone_irq = false;
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9710):
https://lists.yoctoproject.org/g/linux-yocto/message/9710
Mute This Topic: https://lists.yoctoproject.org/mt/81913013/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: patches to fix build error and debug calltrace
Hi Bruce, There are 2 patches to update the linux-yocto, branch v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx. patch[0001]: drivers: mailbox: replace mutex with spinlock in llce_mailbox this patch is to fix debug calltrace due to may sleep mutex called in atomic context. patch[0002]: drivers: crypto: hse: replace devm_ioremap_nocache with devm_ioremap this patch is to fix the hse uio driver build error. Would you please help to merge these two patches into linux-ycoto kernel, v5.10, branch is v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx? Thanks, Zhantao -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9709): https://lists.yoctoproject.org/g/linux-yocto/message/9709 Mute This Topic: https://lists.yoctoproject.org/mt/81913009/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH] nxp-s32g2xx: add HSE UIO related configs to make hse demo work
For S32G platform, there is a demo for linux, which uses UIO to communicate with linux kernel and HSE firmware, so add related configs to make the demo work. Signed-off-by: Zhantao Tang --- bsp/nxp-s32g2xx/nxp-s32g2xx.cfg | 5 + 1 file changed, 5 insertions(+) diff --git a/bsp/nxp-s32g2xx/nxp-s32g2xx.cfg b/bsp/nxp-s32g2xx/nxp-s32g2xx.cfg index 27240a0a..1a172d93 100644 --- a/bsp/nxp-s32g2xx/nxp-s32g2xx.cfg +++ b/bsp/nxp-s32g2xx/nxp-s32g2xx.cfg @@ -153,3 +153,8 @@ CONFIG_CAN_LLCE=m # Regulator configuration CONFIG_REGULATOR=y + +#HSE UIO +CONFIG_UIO=y +CONFIG_CRYPTO_DEV_NXP_HSE=y +CONFIG_CRYPTO_DEV_NXP_HSE_UIO=y -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9708): https://lists.yoctoproject.org/g/linux-yocto/message/9708 Mute This Topic: https://lists.yoctoproject.org/mt/81912981/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [yocto-kernel-cache yocto-5.10]: nxp-s32g2xx: add HSE UIO related configs to make hse demo work
Hi Bruce, On S32G platform, there is a HSE demo for linux, which depends on UIO configs enablement. The following patch is to fix this. Would you please help to merge this patch into yocto-kernel-cache, branch is yocto-5.10 ? Thanks, Zhantao -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9707): https://lists.yoctoproject.org/g/linux-yocto/message/9707 Mute This Topic: https://lists.yoctoproject.org/mt/81912979/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #yocto #sdk -XILINX/vivado dependencies
No the vivado module sets up key variables, the lib path, and the include paths for building Xilinx low level drivers built into bootapp/kernel... I need to be able to include these components in actual SDK build... Steve -Original Message- From: Khem Raj Sent: Tuesday, April 6, 2021 4:28 PM To: Monsees, Steven C (US) Cc: yocto@lists.yoctoproject.org Subject: Re: [yocto] #yocto #sdk -XILINX/vivado dependencies External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar. there is KERNEL_MODULE_AUTOLOAD which could be used to load modules on boot, don't know if that suffices to what you need but worth looking into. On Tue, Apr 6, 2021 at 12:47 PM Monsees, Steven C (US) via lists.yoctoproject.org wrote: > > > > Working with zeus, aarch64, with Xilinx vivado dependencies… > > Kerenl image and bootapp build and run correctly, need to be able to > build EXT SDK,,, > > > > How do I incorporate the dependencies of the low level Xilinx FPGA support > (i.e. “vivado”) into the Ext SDK build env ? > > > > Is there a way to build in support so that the “module load” command would be > usable from the “.conf” or the env-setup script, (i.e. “module load vivado…” > ? > > > > Thanks, > > Steve > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53050): https://lists.yoctoproject.org/g/yocto/message/53050 Mute This Topic: https://lists.yoctoproject.org/mt/81899470/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-security][PATCH] Use libest "main" branch instead of "master".
This patch fixes the issue: WARNING: libest-3.2.0-r0 do_fetch: Failed to fetch URL git://github.com/cisco/libest, attempting MIRRORS if available ERROR: libest-3.2.0-r0 do_fetch: Fetcher failure: Unable to find revision 4ca02c6d7540f2b1bcea278a4fbe373daac7103b in branch master even from upstream ERROR: libest-3.2.0-r0 do_fetch: Fetcher failure for URL: 'git://github.com/cisco/libest'. Unable to fetch URL from any source. Signed-off-by: Anton Antonov --- recipes-security/libest/libest_3.2.0.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-security/libest/libest_3.2.0.bb b/recipes-security/libest/libest_3.2.0.bb index f993bd6..5b6dc99 100644 --- a/recipes-security/libest/libest_3.2.0.bb +++ b/recipes-security/libest/libest_3.2.0.bb @@ -6,7 +6,7 @@ LICENSE = "OpenSSL" LIC_FILES_CHKSUM = "file://LICENSE;md5=ecb78acde8e3b795de8ef6b61aed5885" SRCREV = "4ca02c6d7540f2b1bcea278a4fbe373daac7103b" -SRC_URI = "git://github.com/cisco/libest" +SRC_URI = "git://github.com/cisco/libest;branch=main" DEPENDS = "openssl" -- 2.20.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53049): https://lists.yoctoproject.org/g/yocto/message/53049 Mute This Topic: https://lists.yoctoproject.org/mt/81912123/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] dpkg-scanpackages from my recipe
Hi all.
I'd like to use dpkg-scanpackages inside my recipe
The recipe copies some deb package into my folder ${D}/myfolder
Then I'd like to apply dpkg-scanpackages to ${D}/myfolder
I miss last step.
Running dpkg-scanpackages ${D}/myfolder ends with and error.
Dpkg.pm missing
How can I "install" Dpkg.pm so I can use dpkg-scanpackages directly from my
recipe?
Best regards,
MZ
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53048): https://lists.yoctoproject.org/g/yocto/message/53048
Mute This Topic: https://lists.yoctoproject.org/mt/81911865/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console
> +-#define RK3399_BAUDRATE 115200
> ++#define RK3399_BAUDRATE 150
> + #define RK3399_UART_CLOCK 2400
Interesting... For years (a few decades) everybody has used 115200 as
the standard setup for UART, as global definition.
Why suddenly somebody changed the UART baud rate to be non-standard?
>From the speed point of view???
Don't think so.
Should U-Boot be adjusted to the standard baud rate of 115200 for RK3399?
My two cent addendum/thinking,
Zee
___
On Wed, Apr 7, 2021 at 1:47 AM Yann Dirson wrote:
>
> From: Yann Dirson
>
> TF-A runs between two u-boot stages which both uses 150 baud, it
> just makes no sense to use the same UART at a different rate.
>
> Here is a sample session with the successive stages, with TF-A artificially
> separated for emphasis:
>
> [20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43)
> [20210406-175438.135956] Channel 0: DDR3, 933MHz
> [20210406-175438.236974] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16
> Size=1024MB
> [20210406-175438.237000] Channel 1: DDR3, 933MHz
> [20210406-175438.237004] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16
> Size=1024MB
> [20210406-175438.237008] 256B stride
> [20210406-175438.237012] Trying to boot from BOOTROM
> [20210406-175438.237015] Returning to boot ROM...
> [20210406-175438.237018]
> [20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +)
> [20210406-175438.573431] Trying to boot from MMC1
>
> [20210406-175438.589254] NOTICE: BL31: v2.3():v2.3-dirty
> [20210406-175440.534055] NOTICE: BL31: Built : 15:56:43, Apr 20 2020
>
> [20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +)
> [20210406-175441.393429]
> [20210406-175441.393433] SoC: Rockchip rk3399
>
> Signed-off-by: Yann Dirson
> ---
> .../files/serial-console-baudrate.patch | 35 +++
> .../trusted-firmware-a_%.bbappend | 5 +++
> 2 files changed, 40 insertions(+)
> create mode 100644
> recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
>
> diff --git
> a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
> b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
> new file mode 100644
> index 000..10b5a2b
> --- /dev/null
> +++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
> @@ -0,0 +1,35 @@
> +From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
> +From: Yann Dirson
> +Date: Tue, 6 Apr 2021 17:28:45 +0200
> +Subject: [PATCH] Set serial console baudrate back to 150.
> +
> +TF-A runs between two u-boot stages which both uses 150 baud, it
> +just makes no sense to use the same UART at a different rate.
> +
> +This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
> +Main reason for that change stated in
> https://developer.trustedfirmware.org/T762
> +is ChromeOS compatibility.
> +
> +Looks like this patch may become unnecessary in the future, when
> +u-boot and TF-A get to communicate this value.
> +
> +---
> + plat/rockchip/rk3399/rk3399_def.h | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/plat/rockchip/rk3399/rk3399_def.h
> b/plat/rockchip/rk3399/rk3399_def.h
> +index ba83242eb..8d6ecfbe6 100644
> +--- a/plat/rockchip/rk3399/rk3399_def.h
> b/plat/rockchip/rk3399/rk3399_def.h
> +@@ -17,7 +17,7 @@
> + /**
> + * UART related constants
> + **/
> +-#define RK3399_BAUDRATE 115200
> ++#define RK3399_BAUDRATE 150
> + #define RK3399_UART_CLOCK 2400
> +
> +
> /**
> +--
> +2.30.2
> +
> diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
> b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
> index 442dee8..1942c17 100644
> --- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
> +++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
> @@ -4,3 +4,8 @@ DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native"
>
> COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"
> COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
> +
> +FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> +SRC_URI += "\
> +file://serial-console-baudrate.patch \
> +"
> --
> 2.30.2
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53046): https://lists.yoctoproject.org/g/yocto/message/53046
Mute This Topic: https://lists.yoctoproject.org/mt/81904391/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console
> Sure it is awkward when all tools have come to default > to 115200, but then is the situation so different from > when we transitioned from, say, 9600? These are historical reasons. It started as 600, 1200, then quickly jumped to 9600 (4x), stayed some time there, and then transitioned via 19600 to final 115200. But I also see baud rates of 57600. 115200/9600 = 12 The serial speed transmission was the issue here. > Hopefully someone from Rockchip will answer :) Could not agree more with you on the statement. Hopefully! ;) > When working on this platform everyone now has his tools setup > for 150, because that's the vendor BSP settings. Would we > have good technical reasons to switch back ? Since most of them use 115200. And clock divisors are adjusted to that baud rate, my best guess. Maybe the reason for that is that the base clocking tree frequency for Rockchip could not derive 115200, rather 15?! Zee ___ On Wed, Apr 7, 2021 at 10:55 AM Yann Dirson wrote: > > Le mer. 7 avr. 2021 à 06:07, Zoran Stojsavljevic > a écrit : > > > > > +-#define RK3399_BAUDRATE 115200 > > > ++#define RK3399_BAUDRATE 150 > > > + #define RK3399_UART_CLOCK 2400 > > > > Interesting... For years (a few decades) everybody has used 115200 as > > the standard setup for UART, as global definition. > > Sure it is awkward when all tools have come to default to 115200, but then > is the situation so different form when we transitionned from, say, 9600 ? > > > Why suddenly somebody changed the UART baud rate to be non-standard? > > From the speed point of view??? > > > > Don't think so. > > Hopefully someone from Rockchip will answer :) > > > Should U-Boot be adjusted to the standard baud rate of 115200 for RK3399? > > When working on this platform everyone now has his tools setup for 150, > because that's the vendor BSP settings. Would we have good technical reasons > to switch back ? > > > > > > My two cent addendum/thinking, > > Zee > > ___ > > > > > > On Wed, Apr 7, 2021 at 1:47 AM Yann Dirson > > wrote: > > > > > > From: Yann Dirson > > > > > > TF-A runs between two u-boot stages which both uses 150 baud, it > > > just makes no sense to use the same UART at a different rate. > > > > > > Here is a sample session with the successive stages, with TF-A > > > artificially > > > separated for emphasis: > > > > > > [20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43) > > > [20210406-175438.135956] Channel 0: DDR3, 933MHz > > > [20210406-175438.236974] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 > > > Size=1024MB > > > [20210406-175438.237000] Channel 1: DDR3, 933MHz > > > [20210406-175438.237004] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 > > > Size=1024MB > > > [20210406-175438.237008] 256B stride > > > [20210406-175438.237012] Trying to boot from BOOTROM > > > [20210406-175438.237015] Returning to boot ROM... > > > [20210406-175438.237018] > > > [20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 > > > +) > > > [20210406-175438.573431] Trying to boot from MMC1 > > > > > > [20210406-175438.589254] NOTICE: BL31: v2.3():v2.3-dirty > > > [20210406-175440.534055] NOTICE: BL31: Built : 15:56:43, Apr 20 2020 > > > > > > [20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +) > > > [20210406-175441.393429] > > > [20210406-175441.393433] SoC: Rockchip rk3399 > > > > > > Signed-off-by: Yann Dirson > > > --- > > > .../files/serial-console-baudrate.patch | 35 +++ > > > .../trusted-firmware-a_%.bbappend | 5 +++ > > > 2 files changed, 40 insertions(+) > > > create mode 100644 > > > recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch > > > > > > diff --git > > > a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch > > > b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch > > > new file mode 100644 > > > index 000..10b5a2b > > > --- /dev/null > > > +++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch > > > @@ -0,0 +1,35 @@ > > > +From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001 > > > +From: Yann Dirson > > > +Date: Tue, 6 Apr 2021 17:28:45 +0200 > > > +Subject: [PATCH] Set serial console baudrate back to 150. > > > + > > > +TF-A runs between two u-boot stages which both uses 150 baud, it > > > +just makes no sense to use the same UART at a different rate. > > > + > > > +This effectively reverts part of > > > 0c05748bdebfad9fa43a80962186438bb8fbce62. > > > +Main reason for that change stated in > > > https://developer.trustedfirmware.org/T762 > > > +is ChromeOS compatibility. > > > + > > > +Looks like this patch may become unnecessary in the future, when > > > +u-boot and TF-A get to communicate this value. > > > + > > > +--- > > > + plat/rockchip/rk3399/rk3399_def.h | 2 +- > > > + 1 file changed, 1 insertion(+), 1 deletion(-) > > >
[[linux-yocto][linux-yocto v5.4/standard/preempt-rt/intel-x86] x86/alternatives: Acquire pte lock with interrupts enabled
From: Sebastian Andrzej Siewior commit a6d996cbd38b42341ad3fce74506b9fdc280e395 upstream pte lock is never acquired in-IRQ context so it does not require interrupts to be disabled. The lock is a regular spinlock which cannot be acquired with interrupts disabled on RT. RT complains about pte_lock() in __text_poke() because it's invoked after disabling interrupts. __text_poke() has to disable interrupts as use_temporary_mm() expects interrupts to be off because it invokes switch_mm_irqs_off() and uses per-CPU (current active mm) data. Move the PTE lock handling outside the interrupt disabled region. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Acked-by; Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20200813105026.bvugytmsso6mu...@linutronix.de Signed-off-by: Jun Miao --- arch/x86/kernel/alternative.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c index c826cddae157..34a1b8562c31 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -874,8 +874,6 @@ static void *__text_poke(void *addr, const void *opcode, size_t len) */ BUG_ON(!pages[0] || (cross_page_boundary && !pages[1])); - local_irq_save(flags); - /* * Map the page without the global bit, as TLB flushing is done with * flush_tlb_mm_range(), which is intended for non-global PTEs. @@ -892,6 +890,8 @@ static void *__text_poke(void *addr, const void *opcode, size_t len) */ VM_BUG_ON(!ptep); + local_irq_save(flags); + pte = mk_pte(pages[0], pgprot); set_pte_at(poking_mm, poking_addr, ptep, pte); @@ -941,8 +941,8 @@ static void *__text_poke(void *addr, const void *opcode, size_t len) */ BUG_ON(memcmp(addr, opcode, len)); - pte_unmap_unlock(ptep, ptl); local_irq_restore(flags); + pte_unmap_unlock(ptep, ptl); return addr; } -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9706): https://lists.yoctoproject.org/g/linux-yocto/message/9706 Mute This Topic: https://lists.yoctoproject.org/mt/81911651/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-imx8][PATCH] tools: perf: Fix the undefined build errors in metricgroup__print()
Because the patch taken out from linux-imx puts free(s) in the wrong position, a build error appears Fixes: 40be8dc54887(tools: perf: metricgroup: add metricgroup for each PMU) Signed-off-by: Xiaolei Wang --- tools/perf/util/metricgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c index cc31fd0741e5..b31cf4cb7b3a 100644 --- a/tools/perf/util/metricgroup.c +++ b/tools/perf/util/metricgroup.c @@ -576,11 +576,11 @@ void metricgroup__print(bool metrics, bool metricgroups, char *filter, continue; strlist__add(me->metrics, s); } + if (!raw) + free(s); } free(omg); - if (!raw) - free(s); } } } -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9705): https://lists.yoctoproject.org/g/linux-yocto/message/9705 Mute This Topic: https://lists.yoctoproject.org/mt/81911633/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH] drivers: net: phy: drop unneeded codes in nxp phy config init
Since commit d73a2156bdad ("net: phy: simplify phy_mac_interrupt
and related functions") has droped the phy_queue in struct phy_device,
and it is relocated into struct nxp_specific_data which will be private
data of related phy_device. As a result, there will be no one to init
the phy_queue before nxp phy config init, so drop the cancel_work_sync()
in nxp_config_init(), otherwise, there will be warning calltrace like
the following:
WARNING: CPU: 0 PID: 188 at kernel/workqueue.c:3037
__flush_work.isra.0+0x2b4/0x2e0
Modules linked in: nxp pfeng(O+) hse llce_core sch_fq_codel openvswitch
nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 fuse
CPU: 0 PID: 188 Comm: systemd-udevd Tainted: G O
5.10.25-yocto-standard #1
Hardware name: Freescale S32G274 (DT)
pstate: 0005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
pc : __flush_work.isra.0+0x2b4/0x2e0
lr : __cancel_work_timer+0x134/0x1ac
sp : ffc0127db290
x29: ffc0127db290 x28:
x27: ff885f9ffce0 x26: ffc010c9cba8
x25: ff88002bc380 x24: 0001
x23: ffc0100629b0 x22: ffc01148bb60
x21: ff88002bc380 x20: ff8805a19208
x19: ff8805a19208 x18:
x17: 0002 x16: 33bd918e20a0
x15: 00cefe10e88b39bc x14: ffc010bfbc90
x13: 0354 x12: f5257d14
x11: 00cefe10 x10: 0920
x9 : ffc010066608 x8 : ff88002bcd00
x7 : 3abf x6 : b8f3
x5 : x4 :
x3 : 00a0 x2 :
x1 : 0011 x0 :
Call trace:
__flush_work.isra.0+0x2b4/0x2e0
__cancel_work_timer+0x134/0x1ac
cancel_work_sync+0x20/0x30
nxp_config_init+0x2ec/0x3e4 [nxp]
nxp_probe+0x80/0x100 [nxp]
phy_probe+0x7c/0x1dc
really_probe+0xf0/0x4b4
driver_probe_device+0x64/0xcc
__device_attach_driver+0xb4/0x110
bus_for_each_drv+0x84/0xd4
__device_attach+0xe4/0x18c
device_initial_probe+0x20/0x30
bus_probe_device+0xa4/0xb0
device_add+0x334/0x72c
phy_device_register+0x64/0xb0
of_mdiobus_phy_device_register+0xd8/0x100
of_mdiobus_register_phy+0x10c/0x170
of_mdiobus_register+0x144/0x360
pfeng_mdio_register+0xcc/0x110 [pfeng]
pfeng_drv_probe+0x1b8/0x2c0 [pfeng]
pfeng_s32g_probe+0x528/0xad0 [pfeng]
platform_drv_probe+0x60/0xb4
really_probe+0xf0/0x4b4
driver_probe_device+0x64/0xcc
device_driver_attach+0xcc/0xd4
__driver_attach+0x90/0x130
bus_for_each_dev+0x7c/0xd0
driver_attach+0x30/0x3c
bus_add_driver+0x114/0x200
driver_register+0x84/0x140
__platform_driver_register+0x54/0x60
pfeng_platform_driver_init+0x2c/0x1000 [pfeng]
do_one_initcall+0x6c/0x2e0
do_init_module+0x60/0x27c
load_module+0x1f9c/0x27d0
__do_sys_finit_module+0xb8/0xfc
__arm64_sys_finit_module+0x2c/0x40
el0_svc_common.constprop.0+0x9c/0x1c0
do_el0_svc+0x78/0xa0
el0_svc+0x20/0x30
el0_sync_handler+0x1a4/0x1b0
el0_sync+0x174/0x180
---[ end trace bbae33eae4d3e4e9 ]---
Besides, the comments on the phy_queue are modified to compatible
with the codes.
Signed-off-by: Zhantao Tang
---
drivers/net/phy/nxp/nxp.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/phy/nxp/nxp.c b/drivers/net/phy/nxp/nxp.c
index 786c26017b6e..8760c220d716 100644
--- a/drivers/net/phy/nxp/nxp.c
+++ b/drivers/net/phy/nxp/nxp.c
@@ -163,12 +163,9 @@ static int nxp_config_init(struct phy_device *phydev)
/* Setup and queue a polling function:
*
-* The phy_queue is normally used to schedule the interrupt handler
-* from interrupt context after an irq has been received.
-* Here it is repurposed as scheduling mechanism for the poll function
+* Here the phy_queue is to purposed as scheduling mechanism for the
poll function
*/
if (((struct nxp_specific_data *)phydev->priv)->poll_setup == 0) {
- cancel_work_sync(&(((struct nxp_specific_data
*)phydev->priv)->phy_queue));
INIT_WORK(&(((struct nxp_specific_data
*)phydev->priv)->phy_queue), poll);
queue_work(system_power_efficient_wq, &(((struct
nxp_specific_data *)phydev->priv)->phy_queue));
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9704):
https://lists.yoctoproject.org/g/linux-yocto/message/9704
Mute This Topic: https://lists.yoctoproject.org/mt/81911546/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
[linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: drivers: net: phy: drop unneeded codes in nxp phy config init
Hi Bruce, There are some unneeded codes in nxp phy driver need to drop, the following patch is to do this. Would you please help to merge this patch into linux-ycoto kernel, v5.10, branch is v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx? Thanks, Zhantao -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9703): https://lists.yoctoproject.org/g/linux-yocto/message/9703 Mute This Topic: https://lists.yoctoproject.org/mt/81911545/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] ERROR: The following required tools (as specified by HOSTTOOLS) appear to be unavailable in PATH,
On Wed, 7 Apr 2021, shoareau via lists.yoctoproject.org wrote: > > > Good morning, > > I am using a linux VM on Windows 10 (virtual box & debian). > I am trying to build a linux kernel for raspberry2 based > on https://medium.com/@meronz/learning-yocto-part-1-a989f4340e90 > $ mkdir -p yocto/sources && cd yocto/sources > $ git clone -b pyro git://git.yoctoproject.org/poky.git > $ git clone -b pyro git://git.yoctoproject.org/meta-raspberrypi.git > > After configuring the local.conf and bblayers.conf, when i use bitbake in my > build path: > bitbake rpi-hwup-image > > I have the error : > ERROR: The following required tools (as specified by HOSTTOOLS) appear to be > unavailable in PATH, > please install them > in order to proceed > gawk simply install the gawk utility, that should fix it. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9702): https://lists.yoctoproject.org/g/linux-yocto/message/9702 Mute This Topic: https://lists.yoctoproject.org/mt/81911438/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] ERROR: The following required tools (as specified by HOSTTOOLS) appear to be unavailable in PATH,
Good morning, I am using a linux VM on Windows 10 (virtual box & debian). I am trying to build a linux kernel for raspberry2 based on https://medium.com/@meronz/learning-yocto-part-1-a989f4340e90 ( https://medium.com/@meronz/learning-yocto-part-1-a989f4340e90 ) $ mkdir -p yocto/sources && cd yocto/sources $ git clone -b pyro git://git.yoctoproject.org/poky.git $ git clone -b pyro git://git.yoctoproject.org/meta-raspberrypi.git After configuring the local.conf and bblayers.conf, when i use bitbake in my build path: bitbake rpi-hwup-image I have the error : ERROR: The following required tools (as specified by HOSTTOOLS) appear to be unavailable in PATH, please install them in order to proceed gawk Did you have this issue? What did i miss? Thank you ERROR: The following required tools (as specified by HOSTTOOLS) appear to be unavailable in PATH, please install them in order to proceed gawk -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9701): https://lists.yoctoproject.org/g/linux-yocto/message/9701 Mute This Topic: https://lists.yoctoproject.org/mt/81911438/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console
Le mer. 7 avr. 2021 à 06:07, Zoran Stojsavljevic a écrit : > > > +-#define RK3399_BAUDRATE 115200 > > ++#define RK3399_BAUDRATE 150 > > + #define RK3399_UART_CLOCK 2400 > > Interesting... For years (a few decades) everybody has used 115200 as > the standard setup for UART, as global definition. Sure it is awkward when all tools have come to default to 115200, but then is the situation so different form when we transitionned from, say, 9600 ? > Why suddenly somebody changed the UART baud rate to be non-standard? > From the speed point of view??? > > Don't think so. Hopefully someone from Rockchip will answer :) > Should U-Boot be adjusted to the standard baud rate of 115200 for RK3399? When working on this platform everyone now has his tools setup for 150, because that's the vendor BSP settings. Would we have good technical reasons to switch back ? > > My two cent addendum/thinking, > Zee > ___ > > > On Wed, Apr 7, 2021 at 1:47 AM Yann Dirson > wrote: > > > > From: Yann Dirson > > > > TF-A runs between two u-boot stages which both uses 150 baud, it > > just makes no sense to use the same UART at a different rate. > > > > Here is a sample session with the successive stages, with TF-A artificially > > separated for emphasis: > > > > [20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43) > > [20210406-175438.135956] Channel 0: DDR3, 933MHz > > [20210406-175438.236974] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 > > Size=1024MB > > [20210406-175438.237000] Channel 1: DDR3, 933MHz > > [20210406-175438.237004] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 > > Size=1024MB > > [20210406-175438.237008] 256B stride > > [20210406-175438.237012] Trying to boot from BOOTROM > > [20210406-175438.237015] Returning to boot ROM... > > [20210406-175438.237018] > > [20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +) > > [20210406-175438.573431] Trying to boot from MMC1 > > > > [20210406-175438.589254] NOTICE: BL31: v2.3():v2.3-dirty > > [20210406-175440.534055] NOTICE: BL31: Built : 15:56:43, Apr 20 2020 > > > > [20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +) > > [20210406-175441.393429] > > [20210406-175441.393433] SoC: Rockchip rk3399 > > > > Signed-off-by: Yann Dirson > > --- > > .../files/serial-console-baudrate.patch | 35 +++ > > .../trusted-firmware-a_%.bbappend | 5 +++ > > 2 files changed, 40 insertions(+) > > create mode 100644 > > recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch > > > > diff --git > > a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch > > b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch > > new file mode 100644 > > index 000..10b5a2b > > --- /dev/null > > +++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch > > @@ -0,0 +1,35 @@ > > +From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001 > > +From: Yann Dirson > > +Date: Tue, 6 Apr 2021 17:28:45 +0200 > > +Subject: [PATCH] Set serial console baudrate back to 150. > > + > > +TF-A runs between two u-boot stages which both uses 150 baud, it > > +just makes no sense to use the same UART at a different rate. > > + > > +This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62. > > +Main reason for that change stated in > > https://developer.trustedfirmware.org/T762 > > +is ChromeOS compatibility. > > + > > +Looks like this patch may become unnecessary in the future, when > > +u-boot and TF-A get to communicate this value. > > + > > +--- > > + plat/rockchip/rk3399/rk3399_def.h | 2 +- > > + 1 file changed, 1 insertion(+), 1 deletion(-) > > + > > +diff --git a/plat/rockchip/rk3399/rk3399_def.h > > b/plat/rockchip/rk3399/rk3399_def.h > > +index ba83242eb..8d6ecfbe6 100644 > > +--- a/plat/rockchip/rk3399/rk3399_def.h > > b/plat/rockchip/rk3399/rk3399_def.h > > +@@ -17,7 +17,7 @@ > > + > > /** > > + * UART related constants > > + > > **/ > > +-#define RK3399_BAUDRATE 115200 > > ++#define RK3399_BAUDRATE 150 > > + #define RK3399_UART_CLOCK 2400 > > + > > + > > /** > > +-- > > +2.30.2 > > + > > diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend > > b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend > > index 442dee8..1942c17 100644 > > --- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend > > +++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend > > @@ -4,3 +4,8 @@ DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native" > > > > COMPATIBLE_MACHINE_append_rk3399 = "|rk3399" > >
Re: [yocto] [PATCH yocto-autobuilder-helper] run-docs-build: build from tags dynamically instead of static list
hey! On Wed, Apr 7, 2021 at 9:31 AM Quentin Schulz wrote: > Hi Michael, > > On April 6, 2021 10:58:20 PM UTC, Michael Halstead < > mhalst...@linuxfoundation.org> wrote: > >All new releases are Sphinx ready so we exclude old tags and build for > >all the rest. > Thanks for starting this! > > > >Signed-off-by: Michael Halstead > >--- > > scripts/run-docs-build | 14 ++ > > 1 file changed, 10 insertions(+), 4 deletions(-) > > > >diff --git a/scripts/run-docs-build b/scripts/run-docs-build > >index 910f03d..13df34a 100755 > >--- a/scripts/run-docs-build > >+++ b/scripts/run-docs-build > >@@ -7,6 +7,7 @@ ypdocs=$2/documentation/ > > bbdocs=$3/doc/ > > docs_buildtools=/srv/autobuilder/ > autobuilder.yoctoproject.org/pub/buildtools/x86_64-buildtools-docs-nativesdk-standalone-3.2+snapshot-20201105.sh > > outputdir=$builddir/output > >+excluded_tags="yocto-3.1.4 yocto-3.1.3 yocto-3.1.2 yocto-3.1.1 yocto-3.1 > yocto-3.0.1 yocto-3.0 yocto-2.6.4 yocto-2.6.3 yocto-2.7.1 yocto-2.6.2 > yocto-2.7 yocto-2.6.1 yocto-2.6 yocto-2.5.2 yocto-2.5.1 yocto-2.4.4 > yocto-2.4.3 yocto-2.5 yocto-2.3.4 yocto-1.0.2 yocto-1.1.2 yocto-1.2.2 > yocto-1.2.1 yocto-1.3 yocto-1.3.1 yocto-1.3.2 yocto-1.4.3 yocto-1.4.2 > yocto-1.4.1 yocto-1.4 yocto-2.1.3 yocto-2.4.2 yocto-2.1.1 yocto-2.1.2 > yocto-2.0.3 yocto-1.8.2 yocto-2.2.3 yocto-2.4.1 yocto-2.3.3 yocto-2.3.2 > yocto-2.4 yocto-2.2.2 yocto-2.3.1 yocto-2.3 yocto-2.2.1 yocto-2.0.2 > yocto-2.2 yocto-2.1 yocto-2.0.1 yocto-2.0 yocto-1.8.1 yocto-1.7.3 > yocto-1.6.3 yocto-1.7.2 yocto-1.8 yocto-1.5.1" > > > > > > cd $builddir > >@@ -77,13 +78,18 @@ for branch in dunfell gatesgarth hardknott; do > > done > > > > # Yocto Project releases/tags > >-for tag in 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3; do > >+cd $ypdocs > >+for tag in $(git tag -l |grep 'yocto-' |sort); do > > IIUC the man page, > git tag --list 'yocto-*' | sort > sort -V is even better since it does "natural sort of (version) numbers within text", let's get ready for 3.10 ;) And using -V, how about something along these lines: v_sphinx='yocto-3.1.5' for v in $(git tag --list 'yocto-*'); do first=$(printf '%s\n%s' $v $v_sphinx | sort -V | head -n1) if [ "$first" = "$v_sphinx" ]; then echo "Yocto $v uses Sphinx!" fi done and it outputs the following when I run it locally: Yocto yocto-3.1.5 uses Sphinx! Yocto yocto-3.1.6 uses Sphinx! Yocto yocto-3.2 uses Sphinx! Yocto yocto-3.2.1 uses Sphinx! Yocto yocto-3.2.2 uses Sphinx! Yocto yocto-3.2.3 uses Sphinx! would be doing the same thing as the one command with grep above. > Discovered it recently so just wanted to share. > > I guess this is something we can also do for bitbake Sphinx documentation? > yes. > > Removed the git context inadvertently but, is =~ some bash built-in? I > don't know what's the shebang on top but maybe we want to force it to bash > since I'm not sure it's POSIX "compliant" anymore? It is bash already. > > Reviewed-by: Quentin Schulz > > Thanks, > Quentin > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53044): https://lists.yoctoproject.org/g/yocto/message/53044 Mute This Topic: https://lists.yoctoproject.org/mt/81903406/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper] run-docs-build: build from tags dynamically instead of static list
Hi Michael, On April 6, 2021 10:58:20 PM UTC, Michael Halstead wrote: >All new releases are Sphinx ready so we exclude old tags and build for >all the rest. > >Signed-off-by: Michael Halstead >--- > scripts/run-docs-build | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > >diff --git a/scripts/run-docs-build b/scripts/run-docs-build >index 910f03d..13df34a 100755 >--- a/scripts/run-docs-build >+++ b/scripts/run-docs-build >@@ -7,6 +7,7 @@ ypdocs=$2/documentation/ > bbdocs=$3/doc/ > docs_buildtools=/srv/autobuilder/autobuilder.yoctoproject.org/pub/buildtools/x86_64-buildtools-docs-nativesdk-standalone-3.2+snapshot-20201105.sh > outputdir=$builddir/output >+excluded_tags="yocto-3.1.4 yocto-3.1.3 yocto-3.1.2 yocto-3.1.1 yocto-3.1 >yocto-3.0.1 yocto-3.0 yocto-2.6.4 yocto-2.6.3 yocto-2.7.1 yocto-2.6.2 >yocto-2.7 yocto-2.6.1 yocto-2.6 yocto-2.5.2 yocto-2.5.1 yocto-2.4.4 >yocto-2.4.3 yocto-2.5 yocto-2.3.4 yocto-1.0.2 yocto-1.1.2 yocto-1.2.2 >yocto-1.2.1 yocto-1.3 yocto-1.3.1 yocto-1.3.2 yocto-1.4.3 yocto-1.4.2 >yocto-1.4.1 yocto-1.4 yocto-2.1.3 yocto-2.4.2 yocto-2.1.1 yocto-2.1.2 >yocto-2.0.3 yocto-1.8.2 yocto-2.2.3 yocto-2.4.1 yocto-2.3.3 yocto-2.3.2 >yocto-2.4 yocto-2.2.2 yocto-2.3.1 yocto-2.3 yocto-2.2.1 yocto-2.0.2 yocto-2.2 >yocto-2.1 yocto-2.0.1 yocto-2.0 yocto-1.8.1 yocto-1.7.3 yocto-1.6.3 >yocto-1.7.2 yocto-1.8 yocto-1.5.1" > > > cd $builddir >@@ -77,13 +78,18 @@ for branch in dunfell gatesgarth hardknott; do > done > > # Yocto Project releases/tags >-for tag in 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3; do >+cd $ypdocs >+for tag in $(git tag -l |grep 'yocto-' |sort); do IIUC the man page, git tag --list 'yocto-*' | sort would be doing the same thing as the one command with grep above. Discovered it recently so just wanted to share. I guess this is something we can also do for bitbake Sphinx documentation? Removed the git context inadvertently but, is =~ some bash built-in? I don't know what's the shebang on top but maybe we want to force it to bash since I'm not sure it's POSIX "compliant" anymore? Reviewed-by: Quentin Schulz Thanks, Quentin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53043): https://lists.yoctoproject.org/g/yocto/message/53043 Mute This Topic: https://lists.yoctoproject.org/mt/81903406/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
