[yocto] devshell env in warrior

[matthew stanger]

I'm trying to figure out why when running devshell in Warrior CC/CFLAGS are
not the same as do_compile for a recipe. For example.
devshell printenv yields:
CC=aarch64-poky-linux-gcc   -fuse-ld=bfd
-fmacro-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
-fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
-fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot=
-fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot-native=
 
-fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work-shared/tmobile-7271-kaon-mini/kernel-source=/usr/src/kernel

do_compile() {
/usr/bin/printenv | sort > debug.log
}
yields...
CC=aarch64-poky-linux-gcc  -mcpu=cortex-a53+crc+crypto
-fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=/home/matt/rdk_warrior/build/tmp/work/tmobile_7271_kaon_mini-poky-linux/ursr/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot

This causes some very different behavior out of the makefile. The recipe
I"m working with has no do_configure, and only calls a makefile through
do_compile. No appends/prepends or custom functions in the recipe. This
recipe is for a lovely Broadcom driver/userspace glob and I'm trying to
troubleshoot it with x64 but not being able to get a correct working env
makes life hard. Any idea's of where I might be going wrong?

Cheers
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[sjolley.yp.pm]

All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 280
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "2.8", "2.9', "2.99" and "Future", the more pressing/urgent
issues being in "2.8" and then "2.9".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Bash-based build tool/environment u2up-yocto

[Samo Pogačnik]

Hi,

I am new to the yocto mailing list and i would like to share my bash-based
tool/environment to build a yocto-based linux distribution. The tool/environment
is called u2up-yocto and can be found here: https://github.com/spog/u2up-yocto

Using u2up-yocto, i tried to achieve a few goals:
1) being able to build some default poky machine/image targets out-of-the-box
without manually creating specific build configuration.

2) being able to extend default functionality by adding external/internal
layers, git repos and additional local configuration without modifying any
released u2up-yocto files.

You are welcome to check two sample projects, using u2up-yocto:
- https://github.com/spog/meta-u2up-homegw.git
- https://github.com/spog/meta-u2up-pc-installer.git

3) define a new distro name

4) provide a simple common (cross-projects) downloads and shared-sstate
configuration

best regards, samo



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Running Yocto inside Docker

[Rudolf Streif]

That's more of a Gitlab than Yocto question. I am doing this all the time
with my GL server on AWS. You need to add deploy a key to the repo you want
to access and then push the key to your Docker instance from gitlab-ci.yaml
from the repo that you are using with GL CI.

:rjs

On Mon, Jun 17, 2019, 07:20 Gabriele Zampieri 
wrote:

> Hi all,
>
> does anyone have a guide on how to setup Yocto to run inside docker? Right
> now I managed to trigger the build from GitLab, but I'm facing an issue
> related to ssh keys (some recipes from my meta layer are hosted on a
> privare repository). Probably this is not the best mailing list to ask this
> kind of question, but it may worth a try.
>
> Thank you,
> Gabriele
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Am not getting udev-extraconf automount to work

[Greg Wilson-Lindberg]

I'm building for a RPi3B using the Qt supplied boot2qt framework on SUMO.
I've added udev-extraconf to pull in automount.rules.

When I plug in a USB thumb drive I get /dev/SDA & /dev/SDA1. I also get 
/tmp/.automount-sda1 with the time of insertion. I also get /run/media/sda1, 
and the /var/log/messages file has a message that 'Auto-mount of 
[/run/media/sda1] successful', but the output of the 'mount' program does not 
show the thumb drive mounted, nothing in the output at /run/media/sda1' and the 
directory is empty despite the thumb drives that I have tried having files on 
them.

Anyone have any experience with the automounter?
 

Greg Wilson-Lindberg  
 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cortexa9t2hf instead of cortexa9hf

[Arno Steffens]

Thanks for explaining this.
I take some time to read about thumb/thumb2. The feedback is mixed. It seems to 
generate more compact code, but some say it speeds up, others it slows down 
because of reduced function set - and it can cause strange effects.
And mixing this causes time to switch processor mode. So, as I am not an expert 
in this and can't decide what ist best on per function base and speed is of 
highest priority, I think I better should use not thumb(2).

So, do I get it right that with this cortexa9t2hf I just have the option to 
compile it for thumb2? But without using a dedicated compiler option it 
generates same "standard" arm code and the difference is just to adapt all the 
Makefiles for this suffix.

According to Martin I can get the previous setting by just set 
ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I 
lose other kinds of optimisation. (I am just a user not an expert in arm 
architecture).
On the other hand for those like me it is better go the standard way. Once I am 
sure compiler results will not become worse (see above) I go for the pain and 
renaming my toolchain/makefiles/stuff.

Thanks for you taking the time.
Arno

> Hello Arno,
>
> Let me try to explain my point of view. Since here (my best guess) we
> have some asynchronous bitbake code which went South upon introducing
> T2 HW extension.
>
> Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> media coprocessor) exists in both of them. In other words:
> cortexa9t2hf = cortexa9hf HW + T2 HW extension.
>
> Point [2]:
> > bitbake gives me in 2.5:
> > TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> > cortexa9"
> > TARGET_FPU   = "hard"
> >
> > and in 2.7:
> > TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
> > TARGET_FPU   = "hard"
>
> These two lines are the same: you are able to use 32b arm mode, 16bit
> thumb mode, using armv7 HW with neon HW extension, and using HW FP
> extension as well. The Cortex in both cases is A9.
>
> I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> and I have no idea if this is done intentionally or not.
>
> Because of that I copied Alex and Ross to CC: into email, so they
> should unveil this mystery (I would prefer "armv7" to stay in bitbake
> 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
>
> Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> should return "armv7" as TUNE FEATURE.
>
> Best Regards,
> Zoran
> ___
>
>
> On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens  wrote:
> >
> > Hello Zoran,
> > thanks. As far as I understand is thumb2 another mode of coding, that might 
> > create more compact code.
> > But I want to keep all compatible to my previous tool-chain and settings.
> > The only file where I can found this "cortexa9t2hf" is
> > ./meta/conf/machine/include/tune-cortexa9.inc
> > but I can't see how I can control Yocto to generate "cortexa9hf-neon" as 
> > before.
> > Or have I been wrong the time before?
> >
> > bitbake gives me in 2.5:
> >
> > TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> > cortexa9"
> > TARGET_FPU   = "hard"
> >
> > and in 2.7:
> > TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
> > TARGET_FPU   = "hard"
> >
> > so armv7a seem to be missing. In terms of thumb both is same. But is that 
> > the reason? Where to set it?
> > Arno
> >
> > >
> > > Hello Arno,
> > >
> > > Your question, per say, has little to do with YOCTO forum. But I'll
> > > try (as my best) to answer your question.
> > >
> > > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> > >
> > > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > > question is what is T2? T2 is addition to the previous architecture
> > > Cortexa9hf, and addition is Thumb-2 mode.
> > >
> > > Hope this helps,
> > >
> > > Zoran
> > > ___
> > >
> > > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens  wrote:
> > > >
> > > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > > > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do 
> > > > something wrong or what exactly does this t2 mean?
> > > > Target system is a Zynq7020 system.
> > > > --
> > > > ___
> > > > 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] cortexa9t2hf instead of cortexa9hf

[Zoran Stojsavljevic]

> Because of that I copied Alex and Ross to CC: into email, so they
> should unveil this mystery (I would prefer "armv7" to stay in bitbake
> 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).

Sorry, my bad. A15 still belongs to armv7. And now I see/understand
why you removed "armv7". Well... Time Will Tell if this is a good
decision! ;-)

Zoran
___

On Mon, Jun 17, 2019 at 4:29 PM Martin Jansa  wrote:
>
> See this oe-core commit (from 2.6 Thud):
>
> commit c88304a78e528596ca481cabe273749c286c352a
> Author: Andre McCurdy 
> Date:   Fri May 18 15:50:40 2018 -0700
>
> arch-armv7a.inc: default to Thumb2 instruction set for armv7a and above
>
> which enabled Thumb2 by default, if you want to disable it as it was before 
> set ARM_INSTRUCTION_SET to "arm".
>
> On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens  wrote:
>>
>> I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
>> Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something 
>> wrong or what exactly does this t2 mean?
>> Target system is a Zynq7020 system.
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] General Question: Device specific value store

[Matthias Schoepfer]

Hi!

I have a general, maybe dumb question. Is there a smart, recommended way 
to deal with device specific data (i.e. serial number, credentials for 
backend access, you name it), that is specific for *one* device, and 
hence does not belong into the rootfs. I know, that there are (safe) 
hardware stores for it, but what, if your device does not have one. The 
current approach is to use an additional file system. Is there a good 
way to create huge numbers of such filesystems that just hold different 
values generated of a cvs file or such. What would be the yocto way 
without crafting scripts over scripts?!


Thanks and Regards,

   Matthias

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cortexa9t2hf instead of cortexa9hf

[Martin Jansa]

See this oe-core commit (from 2.6 Thud):

commit c88304a78e528596ca481cabe273749c286c352a
Author: Andre McCurdy 
Date:   Fri May 18 15:50:40 2018 -0700

arch-armv7a.inc: default to Thumb2 instruction set for armv7a and above

which enabled Thumb2 by default, if you want to disable it as it was before
set ARM_INSTRUCTION_SET to "arm".

On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens  wrote:

> I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something
> wrong or what exactly does this t2 mean?
> Target system is a Zynq7020 system.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Running Yocto inside Docker

[Gabriele Zampieri]

Hi all,

does anyone have a guide on how to setup Yocto to run inside docker? Right
now I managed to trigger the build from GitLab, but I'm facing an issue
related to ssh keys (some recipes from my meta layer are hosted on a
privare repository). Probably this is not the best mailing list to ask this
kind of question, but it may worth a try.

Thank you,
Gabriele
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cortexa9t2hf instead of cortexa9hf

[Zoran Stojsavljevic]

Hello Arno,

Let me try to explain my point of view. Since here (my best guess) we
have some asynchronous bitbake code which went South upon introducing
T2 HW extension.

Point [1]: as far as I understand arm, cortexa9t2hf is is just a
superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
media coprocessor) exists in both of them. In other words:
cortexa9t2hf = cortexa9hf HW + T2 HW extension.

Point [2]:
> bitbake gives me in 2.5:
> TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> cortexa9"
> TARGET_FPU   = "hard"
>
> and in 2.7:
> TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
> TARGET_FPU   = "hard"

These two lines are the same: you are able to use 32b arm mode, 16bit
thumb mode, using armv7 HW with neon HW extension, and using HW FP
extension as well. The Cortex in both cases is A9.

I expect that somebody somewhere in bitbake version 1.42 - 100% sure
(since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
and I have no idea if this is done intentionally or not.

Because of that I copied Alex and Ross to CC: into email, so they
should unveil this mystery (I would prefer "armv7" to stay in bitbake
1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).

Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
should return "armv7" as TUNE FEATURE.

Best Regards,
Zoran
___


On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens  wrote:
>
> Hello Zoran,
> thanks. As far as I understand is thumb2 another mode of coding, that might 
> create more compact code.
> But I want to keep all compatible to my previous tool-chain and settings.
> The only file where I can found this "cortexa9t2hf" is
> ./meta/conf/machine/include/tune-cortexa9.inc
> but I can't see how I can control Yocto to generate "cortexa9hf-neon" as 
> before.
> Or have I been wrong the time before?
>
> bitbake gives me in 2.5:
>
> TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> cortexa9"
> TARGET_FPU   = "hard"
>
> and in 2.7:
> TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
> TARGET_FPU   = "hard"
>
> so armv7a seem to be missing. In terms of thumb both is same. But is that the 
> reason? Where to set it?
> Arno
>
> >
> > Hello Arno,
> >
> > Your question, per say, has little to do with YOCTO forum. But I'll
> > try (as my best) to answer your question.
> >
> > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> >
> > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > question is what is T2? T2 is addition to the previous architecture
> > Cortexa9hf, and addition is Thumb-2 mode.
> >
> > Hope this helps,
> >
> > Zoran
> > ___
> >
> > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens  wrote:
> > >
> > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do 
> > > something wrong or what exactly does this t2 mean?
> > > Target system is a Zynq7020 system.
> > > --
> > > ___
> > > 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] cortexa9t2hf instead of cortexa9hf

[Arno Steffens]

Hello Zoran,
thanks. As far as I understand is thumb2 another mode of coding, that might 
create more compact code.
But I want to keep all compatible to my previous tool-chain and settings.
The only file where I can found this "cortexa9t2hf" is
./meta/conf/machine/include/tune-cortexa9.inc
but I can't see how I can control Yocto to generate "cortexa9hf-neon" as before.
Or have I been wrong the time before?

bitbake gives me in 2.5:

TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard cortexa9"
TARGET_FPU   = "hard"

and in 2.7:
TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
TARGET_FPU   = "hard"

so armv7a seem to be missing. In terms of thumb both is same. But is that the 
reason? Where to set it?
Arno

>
> Hello Arno,
>
> Your question, per say, has little to do with YOCTO forum. But I'll
> try (as my best) to answer your question.
>
> Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
>
> Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> question is what is T2? T2 is addition to the previous architecture
> Cortexa9hf, and addition is Thumb-2 mode.
>
> Hope this helps,
>
> Zoran
> ___
>
> On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens  wrote:
> >
> > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something 
> > wrong or what exactly does this t2 mean?
> > Target system is a Zynq7020 system.
> > --
> > ___
> > 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] [meta-swupdate] failed update leads to kernel panic

[Zoran Stojsavljevic]

> I see the bundle_initramfs task being executed if I do any
> changes. The boot process works without swupdate in the
> image. If anything was wrong with the initramfs the whole
> system shouldn't be able to boot properly. I don't get what
> you suggest me to try.

It is just Divide and Conquer strategy. If you have normal system
working with/transitioning via initramfs, I would assume that there
should be nothing wrong with your initramfs, other than if you cut
power while update is upgrading kernel, and upon (part of kernel
upgrade) it makes/builds new initramfs (it could be very lengthy
process).

My best guess is to exclude from swupdate layer ONLY kernel upgrade,
and see if this helps, and brings you to some better point where you
can understand the problem. Again, Divide and Conquer strategy.

Zoran
___

On Mon, Jun 17, 2019 at 2:13 PM Moritz Porst  wrote:
>
> Hi Zoran
>
> On 17.06.19 12:55, Zoran Stojsavljevic wrote:
>
> I have a feeling that I misunderstand something about the ramdisk.
> To my understanding this is the microcode.cpio file which is invoked
> lastly in the grub entry.
>
> Being you, I would for the starters exclude swupdate layer and see if
> everything works without swupdate: does normally work with initramfs
> (from grub). Maybe it works already.
>
> I see the bundle_initramfs task being executed if I do any changes. The boot 
> process works without swupdate in the image. If anything was wrong with the 
> initramfs the whole system shouldn't be able to boot properly. I don't get 
> what you suggest me to try.
>
> Best regards
>
> Moritz
>
> But this is only me with my hints.
>
> Zoran
> ___
>
> On Mon, Jun 17, 2019 at 11:59 AM Moritz Porst  wrote:
>
> Hi Stefano
>
> On 17.06.19 09:19, Stefano Babic wrote:
>
> Hi Moritz,
>
> On 17/06/19 08:23, Moritz Porst wrote:
>
> Hello Stefano,
> Thanks very much for your answer
>
> On 14.06.19 14:14, Stefano Babic wrote:
>
> Hi Moritz,
>
> On 14/06/19 12:19, Moritz Porst wrote:
>
> (Sorry, the answer should go to everyone)
> Thanks for your response, unfortunately it didn't work out for me.
> Because I am not 100% sure whether I did the correct thing I describe it:
> In my layer I went to recipes-kernel/kernel/files, here I added a file
> defconfig which I filled with the content of your config-initramfs
> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
> file added so it reads (in its entirety):
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> SRC_URI += "file://0001-sdcard-power-management-off.patch"
> SRC_URI += "file://defconfig"
>
> However I *also* have a file called defconfig in meta-swupdate which is
> basically the swupdate config that comes from menuconfig. I let this
> untouched but since this is not the kernel defconfig I guess you didn't
> mean this file ?
>
> Additionally I can't mount the rootfs with the failed boot so I cannot
> access the dmesg log file. Any advice here ?
>
> Best regards
> Moritz
>
>
>
> *Gesendet:* Freitag, 14. Juni 2019 um 11:00 Uhr
> *Von:* "Zoran Stojsavljevic" 
> *An:* "Moritz Porst" 
> *Cc:* "Yocto Project" 
> *Betreff:* Re: [yocto] [meta-swupdate] failed update leads to kernel panic
>
> However if I abort the update while running (i.e. simulating a power cut)
> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
> unknown block". My understanding is that I should at least end up in a
> busybox or that the update is retried, but this does not happen.
>
> You missed to attach failed dmesg while the system booted and aborted.
> Nevertheless, I expect problem with your defconfig, which does NOT
> have options set for initramfs. These ones:
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
>
> Please, could you add these one to your current .config, this might
> very well solve your problem.
>
> Best Regards,
> Zoran
> ___
>
> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst  wrote:
>
> Hello,
>
> I am currently having trouble to get swupdate working properly.
> My problem:
> I can execute swupdate -i normally and if the update fits I have no
>
> problem. However if I abort the update while running (i.e. simulating a
> power cut) and then reboot I end up in a kernel panic: "Unable to mount
> rootfs on unknown block". My understanding is that I should at least end
> up in a busybox or that the update is retried, but this does not happen.
>
> I receive 1 error when updating which does not stop the update: "Could
>
> not find MTD".
>
> My configuration:
> I have a single rootfs and a separate boot partition. I build the
>
> initramfs using:
>
> You have a *single* rootfs, you stop an upgrade (resulting of course in
> a corrupted rootfs or worse), and you wonder that kernel cannot mount
> ityour update concept is broken.
>
> Well conceptually I want to go through the bootloader, I just fail to
> understand how I tell swupdate to do this.
>
> You *must* check the bootloader marker in U-Boot (default is the
> 

Re: [yocto] cortexa9t2hf instead of cortexa9hf

[Zoran Stojsavljevic]

Hello Arno,

Your question, per say, has little to do with YOCTO forum. But I'll
try (as my best) to answer your question.

Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).

Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
question is what is T2? T2 is addition to the previous architecture
Cortexa9hf, and addition is Thumb-2 mode.

Hope this helps,

Zoran
___

On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens  wrote:
>
> I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something 
> wrong or what exactly does this t2 mean?
> Target system is a Zynq7020 system.
> --
> ___
> 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] [meta-swupdate] failed update leads to kernel panic

[Moritz Porst]

Hi Zoran

On 17.06.19 12:55, Zoran Stojsavljevic wrote:

I have a feeling that I misunderstand something about the ramdisk.
To my understanding this is the microcode.cpio file which is invoked
lastly in the grub entry.

Being you, I would for the starters exclude swupdate layer and see if
everything works without swupdate: does normally work with initramfs
(from grub). Maybe it works already.


I see the bundle_initramfs task being executed if I do any changes. The
boot process works without swupdate in the image. If anything was wrong
with the initramfs the whole system shouldn't be able to boot properly.
I don't get what you suggest me to try.

Best regards

Moritz



But this is only me with my hints.

Zoran
___

On Mon, Jun 17, 2019 at 11:59 AM Moritz Porst  wrote:

Hi Stefano

On 17.06.19 09:19, Stefano Babic wrote:

Hi Moritz,

On 17/06/19 08:23, Moritz Porst wrote:

Hello Stefano,
Thanks very much for your answer

On 14.06.19 14:14, Stefano Babic wrote:

Hi Moritz,

On 14/06/19 12:19, Moritz Porst wrote:

(Sorry, the answer should go to everyone)
Thanks for your response, unfortunately it didn't work out for me.
Because I am not 100% sure whether I did the correct thing I describe it:
In my layer I went to recipes-kernel/kernel/files, here I added a file
defconfig which I filled with the content of your config-initramfs
my linux-yocto_%.bbappend, residing one level lower (kernel), got this
file added so it reads (in its entirety):

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://0001-sdcard-power-management-off.patch"
SRC_URI += "file://defconfig"

However I *also* have a file called defconfig in meta-swupdate which is
basically the swupdate config that comes from menuconfig. I let this
untouched but since this is not the kernel defconfig I guess you didn't
mean this file ?

Additionally I can't mount the rootfs with the failed boot so I cannot
access the dmesg log file. Any advice here ?

Best regards
Moritz



*Gesendet:* Freitag, 14. Juni 2019 um 11:00 Uhr
*Von:* "Zoran Stojsavljevic" 
*An:* "Moritz Porst" 
*Cc:* "Yocto Project" 
*Betreff:* Re: [yocto] [meta-swupdate] failed update leads to kernel panic

However if I abort the update while running (i.e. simulating a power cut)
and then reboot I end up in a kernel panic: "Unable to mount rootfs on
unknown block". My understanding is that I should at least end up in a
busybox or that the update is retried, but this does not happen.

You missed to attach failed dmesg while the system booted and aborted.
Nevertheless, I expect problem with your defconfig, which does NOT
have options set for initramfs. These ones:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs

Please, could you add these one to your current .config, this might
very well solve your problem.

Best Regards,
Zoran
___

On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst  wrote:

Hello,

I am currently having trouble to get swupdate working properly.
My problem:
I can execute swupdate -i normally and if the update fits I have no

problem. However if I abort the update while running (i.e. simulating a
power cut) and then reboot I end up in a kernel panic: "Unable to mount
rootfs on unknown block". My understanding is that I should at least end
up in a busybox or that the update is retried, but this does not happen.

I receive 1 error when updating which does not stop the update: "Could

not find MTD".

My configuration:
I have a single rootfs and a separate boot partition. I build the

initramfs using:

You have a *single* rootfs, you stop an upgrade (resulting of course in
a corrupted rootfs or worse), and you wonder that kernel cannot mount
ityour update concept is broken.

Well conceptually I want to go through the bootloader, I just fail to
understand how I tell swupdate to do this.

You *must* check the bootloader marker in U-Boot (default is the
"recovery_status" variable) and you *mus*t start again the updater (the
ramdisk) until the marker (it is a transaction flag) is set. It is
erased by SWUpdate only after a successful update. You are now starting
your board with a half-completed update.

So I configured swupdate in menuconfig to work with grub which I set in
my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
work with grub ?

Yes, but you have to set / configure yourself how Grub start, that is a
suitable grub.cfg where variables in grubenv are evalutated (do not
forget load_env in grub.cfg).

Ok I was not aware about this. my grub.cfg now reads:
entry {
load_env
linux ./bzImage [options...]
initrd microcode.cpio
}

The interface between SWUpdate and Grub is grubenv - SWUpdate just sets
variables, but it is duty of bootloader to evaluated them.

(I prefer to stick to EFI because partitioning of
images works out of the box with .wic images)
When you say "you must start again the updater", that's where I'm lost.
 From the documentation I understand that I initiate an update using
"swupdate -i 

Re: [yocto] Share SSTATE_DIR between instances

[Gabriele Zampieri]

Cool, thanks!

Gabriele

Il giorno lun 17 giu 2019 alle ore 14:03 Burton, Ross 
ha scritto:

> It's always a good idea to share sstate between builds.
>
> Ross
>
> On Mon, 17 Jun 2019 at 12:32, Gabriele Zampieri 
> wrote:
> >
> > Hi all,
> >
> > is it a good idea to share the SSTATE_DIR between a docker container
> (used with GitLab pipelines) and the local bitbake instance? They both work
> on the same MACHINE.
> >
> > Gabriele
> > --
> > ___
> > 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] Share SSTATE_DIR between instances

[Burton, Ross]

It's always a good idea to share sstate between builds.

Ross

On Mon, 17 Jun 2019 at 12:32, Gabriele Zampieri  wrote:
>
> Hi all,
>
> is it a good idea to share the SSTATE_DIR between a docker container (used 
> with GitLab pipelines) and the local bitbake instance? They both work on the 
> same MACHINE.
>
> Gabriele
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] cortexa9t2hf instead of cortexa9hf

[Arno Steffens]

I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something 
wrong or what exactly does this t2 mean?
Target system is a Zynq7020 system.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Share SSTATE_DIR between instances

[Gabriele Zampieri]

Hi all,

is it a good idea to share the SSTATE_DIR between a docker container (used
with GitLab pipelines) and the local bitbake instance? They both work on
the same MACHINE.

Gabriele
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-swupdate] failed update leads to kernel panic

[Zoran Stojsavljevic]

> I have a feeling that I misunderstand something about the ramdisk.
> To my understanding this is the microcode.cpio file which is invoked
> lastly in the grub entry.

Being you, I would for the starters exclude swupdate layer and see if
everything works without swupdate: does normally work with initramfs
(from grub). Maybe it works already.

But this is only me with my hints.

Zoran
___

On Mon, Jun 17, 2019 at 11:59 AM Moritz Porst  wrote:
>
> Hi Stefano
>
> On 17.06.19 09:19, Stefano Babic wrote:
>
> Hi Moritz,
>
> On 17/06/19 08:23, Moritz Porst wrote:
>
> Hello Stefano,
> Thanks very much for your answer
>
> On 14.06.19 14:14, Stefano Babic wrote:
>
> Hi Moritz,
>
> On 14/06/19 12:19, Moritz Porst wrote:
>
> (Sorry, the answer should go to everyone)
> Thanks for your response, unfortunately it didn't work out for me.
> Because I am not 100% sure whether I did the correct thing I describe it:
> In my layer I went to recipes-kernel/kernel/files, here I added a file
> defconfig which I filled with the content of your config-initramfs
> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
> file added so it reads (in its entirety):
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> SRC_URI += "file://0001-sdcard-power-management-off.patch"
> SRC_URI += "file://defconfig"
>
> However I *also* have a file called defconfig in meta-swupdate which is
> basically the swupdate config that comes from menuconfig. I let this
> untouched but since this is not the kernel defconfig I guess you didn't
> mean this file ?
>
> Additionally I can't mount the rootfs with the failed boot so I cannot
> access the dmesg log file. Any advice here ?
>
> Best regards
> Moritz
>
>
>
> *Gesendet:* Freitag, 14. Juni 2019 um 11:00 Uhr
> *Von:* "Zoran Stojsavljevic" 
> *An:* "Moritz Porst" 
> *Cc:* "Yocto Project" 
> *Betreff:* Re: [yocto] [meta-swupdate] failed update leads to kernel panic
>
> However if I abort the update while running (i.e. simulating a power cut)
> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
> unknown block". My understanding is that I should at least end up in a
> busybox or that the update is retried, but this does not happen.
>
> You missed to attach failed dmesg while the system booted and aborted.
> Nevertheless, I expect problem with your defconfig, which does NOT
> have options set for initramfs. These ones:
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
>
> Please, could you add these one to your current .config, this might
> very well solve your problem.
>
> Best Regards,
> Zoran
> ___
>
> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst  wrote:
>
> Hello,
>
> I am currently having trouble to get swupdate working properly.
> My problem:
> I can execute swupdate -i normally and if the update fits I have no
>
> problem. However if I abort the update while running (i.e. simulating a
> power cut) and then reboot I end up in a kernel panic: "Unable to mount
> rootfs on unknown block". My understanding is that I should at least end
> up in a busybox or that the update is retried, but this does not happen.
>
> I receive 1 error when updating which does not stop the update: "Could
>
> not find MTD".
>
> My configuration:
> I have a single rootfs and a separate boot partition. I build the
>
> initramfs using:
>
> You have a *single* rootfs, you stop an upgrade (resulting of course in
> a corrupted rootfs or worse), and you wonder that kernel cannot mount
> ityour update concept is broken.
>
> Well conceptually I want to go through the bootloader, I just fail to
> understand how I tell swupdate to do this.
>
> You *must* check the bootloader marker in U-Boot (default is the
> "recovery_status" variable) and you *mus*t start again the updater (the
> ramdisk) until the marker (it is a transaction flag) is set. It is
> erased by SWUpdate only after a successful update. You are now starting
> your board with a half-completed update.
>
> So I configured swupdate in menuconfig to work with grub which I set in
> my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
> work with grub ?
>
> Yes, but you have to set / configure yourself how Grub start, that is a
> suitable grub.cfg where variables in grubenv are evalutated (do not
> forget load_env in grub.cfg).
>
> Ok I was not aware about this. my grub.cfg now reads:
> entry {
> load_env
> linux ./bzImage [options...]
> initrd microcode.cpio
> }
>
> The interface between SWUpdate and Grub is grubenv - SWUpdate just sets
> variables, but it is duty of bootloader to evaluated them.
>
> (I prefer to stick to EFI because partitioning of
> images works out of the box with .wic images)
> When you say "you must start again the updater", that's where I'm lost.
> From the documentation I understand that I initiate an update using
> "swupdate -i abc.swu" but this just runs the update without setting any
> flag for the bootloader.
>
> SWUpdate sets
>
> I have an update 

Re: [yocto] [meta-swupdate] failed update leads to kernel panic

[Moritz Porst]

Hi Stefano

On 17.06.19 09:19, Stefano Babic wrote:

Hi Moritz,

On 17/06/19 08:23, Moritz Porst wrote:

Hello Stefano,
Thanks very much for your answer

On 14.06.19 14:14, Stefano Babic wrote:

Hi Moritz,

On 14/06/19 12:19, Moritz Porst wrote:

(Sorry, the answer should go to everyone)
Thanks for your response, unfortunately it didn't work out for me.
Because I am not 100% sure whether I did the correct thing I describe it:
In my layer I went to recipes-kernel/kernel/files, here I added a file
defconfig which I filled with the content of your config-initramfs
my linux-yocto_%.bbappend, residing one level lower (kernel), got this
file added so it reads (in its entirety):

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://0001-sdcard-power-management-off.patch"
SRC_URI += "file://defconfig"

However I *also* have a file called defconfig in meta-swupdate which is
basically the swupdate config that comes from menuconfig. I let this
untouched but since this is not the kernel defconfig I guess you didn't
mean this file ?

Additionally I can't mount the rootfs with the failed boot so I cannot
access the dmesg log file. Any advice here ?

Best regards
Moritz



*Gesendet:* Freitag, 14. Juni 2019 um 11:00 Uhr
*Von:* "Zoran Stojsavljevic" 
*An:* "Moritz Porst" 
*Cc:* "Yocto Project" 
*Betreff:* Re: [yocto] [meta-swupdate] failed update leads to kernel panic

However if I abort the update while running (i.e. simulating a power cut)
and then reboot I end up in a kernel panic: "Unable to mount rootfs on
unknown block". My understanding is that I should at least end up in a
busybox or that the update is retried, but this does not happen.

You missed to attach failed dmesg while the system booted and aborted.
Nevertheless, I expect problem with your defconfig, which does NOT
have options set for initramfs. These ones:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs

Please, could you add these one to your current .config, this might
very well solve your problem.

Best Regards,
Zoran
___

On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst  wrote:

Hello,

I am currently having trouble to get swupdate working properly.
My problem:
I can execute swupdate -i normally and if the update fits I have no

problem. However if I abort the update while running (i.e. simulating a
power cut) and then reboot I end up in a kernel panic: "Unable to mount
rootfs on unknown block". My understanding is that I should at least end
up in a busybox or that the update is retried, but this does not happen.

I receive 1 error when updating which does not stop the update: "Could

not find MTD".

My configuration:
I have a single rootfs and a separate boot partition. I build the

initramfs using:

You have a *single* rootfs, you stop an upgrade (resulting of course in
a corrupted rootfs or worse), and you wonder that kernel cannot mount
ityour update concept is broken.

Well conceptually I want to go through the bootloader, I just fail to
understand how I tell swupdate to do this.

You *must* check the bootloader marker in U-Boot (default is the
"recovery_status" variable) and you *mus*t start again the updater (the
ramdisk) until the marker (it is a transaction flag) is set. It is
erased by SWUpdate only after a successful update. You are now starting
your board with a half-completed update.

So I configured swupdate in menuconfig to work with grub which I set in
my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
work with grub ?

Yes, but you have to set / configure yourself how Grub start, that is a
suitable grub.cfg where variables in grubenv are evalutated (do not
forget load_env in grub.cfg).


Ok I was not aware about this. my grub.cfg now reads:
entry {
load_env
linux ./bzImage [options...]
initrd microcode.cpio
}



The interface between SWUpdate and Grub is grubenv - SWUpdate just sets
variables, but it is duty of bootloader to evaluated them.


(I prefer to stick to EFI because partitioning of
images works out of the box with .wic images)
When you say "you must start again the updater", that's where I'm lost.
 From the documentation I understand that I initiate an update using
"swupdate -i abc.swu" but this just runs the update without setting any
flag for the bootloader.

SWUpdate sets


I have an update that is actually too large for the rootfs partition to
produce an update failure. SWUpdate then sets recovery_status=failed. On
boot I end up in a kernel panic
If I power off before the update finishes I get no recovery_status in
grubenv.
Manually adding recovery_status=in_progress also does not work (of
course maintaining the 1024 file size). "Does not work" means I end up
in a kernel panic.




One more thing: swupdate complains that there is no grubenv file.

Then it does not work, you have to fix it...


I
defined a path in the config file and create this file using
"grub-editenv /path/as/in/config create".

Grubenv is just a simple 1KB file, you can 

Re: [yocto] [meta-swupdate] failed update leads to kernel panic

[Stefano Babic]

Hi Moritz,

On 17/06/19 08:23, Moritz Porst wrote:
> Hello Stefano,
> Thanks very much for your answer
> 
> On 14.06.19 14:14, Stefano Babic wrote:
>> Hi Moritz,
>>
>> On 14/06/19 12:19, Moritz Porst wrote:
>>> (Sorry, the answer should go to everyone)
>>> Thanks for your response, unfortunately it didn't work out for me.
>>> Because I am not 100% sure whether I did the correct thing I describe it:
>>> In my layer I went to recipes-kernel/kernel/files, here I added a file
>>> defconfig which I filled with the content of your config-initramfs
>>> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
>>> file added so it reads (in its entirety):
>>>  
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>> SRC_URI += "file://0001-sdcard-power-management-off.patch"
>>> SRC_URI += "file://defconfig"
>>>  
>>> However I *also* have a file called defconfig in meta-swupdate which is
>>> basically the swupdate config that comes from menuconfig. I let this
>>> untouched but since this is not the kernel defconfig I guess you didn't
>>> mean this file ?
>>>  
>>> Additionally I can't mount the rootfs with the failed boot so I cannot
>>> access the dmesg log file. Any advice here ?
>>>  
>>> Best regards
>>> Moritz
>>>  
>>>  
>>>  
>>> *Gesendet:* Freitag, 14. Juni 2019 um 11:00 Uhr
>>> *Von:* "Zoran Stojsavljevic" 
>>> *An:* "Moritz Porst" 
>>> *Cc:* "Yocto Project" 
>>> *Betreff:* Re: [yocto] [meta-swupdate] failed update leads to kernel panic
 However if I abort the update while running (i.e. simulating a power cut)
 and then reboot I end up in a kernel panic: "Unable to mount rootfs on
 unknown block". My understanding is that I should at least end up in a
 busybox or that the update is retried, but this does not happen.
>>> You missed to attach failed dmesg while the system booted and aborted.
>>> Nevertheless, I expect problem with your defconfig, which does NOT
>>> have options set for initramfs. These ones:
>>> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
>>>
>>> Please, could you add these one to your current .config, this might
>>> very well solve your problem.
>>>
>>> Best Regards,
>>> Zoran
>>> ___
>>>
>>> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst  wrote:
 Hello,

 I am currently having trouble to get swupdate working properly.
 My problem:
 I can execute swupdate -i normally and if the update fits I have no
>>> problem. However if I abort the update while running (i.e. simulating a
>>> power cut) and then reboot I end up in a kernel panic: "Unable to mount
>>> rootfs on unknown block". My understanding is that I should at least end
>>> up in a busybox or that the update is retried, but this does not happen.
 I receive 1 error when updating which does not stop the update: "Could
>>> not find MTD".
 My configuration:
 I have a single rootfs and a separate boot partition. I build the
>>> initramfs using:
>> You have a *single* rootfs, you stop an upgrade (resulting of course in
>> a corrupted rootfs or worse), and you wonder that kernel cannot mount
>> ityour update concept is broken.
> Well conceptually I want to go through the bootloader, I just fail to
> understand how I tell swupdate to do this.
>> You *must* check the bootloader marker in U-Boot (default is the
>> "recovery_status" variable) and you *mus*t start again the updater (the
>> ramdisk) until the marker (it is a transaction flag) is set. It is
>> erased by SWUpdate only after a successful update. You are now starting
>> your board with a half-completed update.
> 
> So I configured swupdate in menuconfig to work with grub which I set in
> my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
> work with grub ?

Yes, but you have to set / configure yourself how Grub start, that is a
suitable grub.cfg where variables in grubenv are evalutated (do not
forget load_env in grub.cfg).

The interface between SWUpdate and Grub is grubenv - SWUpdate just sets
variables, but it is duty of bootloader to evaluated them.

> (I prefer to stick to EFI because partitioning of
> images works out of the box with .wic images)
> When you say "you must start again the updater", that's where I'm lost.
> From the documentation I understand that I initiate an update using
> "swupdate -i abc.swu" but this just runs the update without setting any
> flag for the bootloader.

SWUpdate sets

> One more thing: swupdate complains that there is no grubenv file.

Then it does not work, you have to fix it...

> I
> defined a path in the config file and create this file using
> "grub-editenv /path/as/in/config create".

Grubenv is just a simple 1KB file, you can dump it.

> swupdate does not give an
> error after I have done this.

If the interface to bootloader (for grub, this means grubenv) is
specified and correct, SWUpdate will set the variable "recovery_status"
as transaction flag. You have to evaluate it in grub.cfg and start the
ramdisk 

Re: [yocto] [meta-swupdate] failed update leads to kernel panic

[Moritz Porst]

Hello Stefano,
Thanks very much for your answer

On 14.06.19 14:14, Stefano Babic wrote:

Hi Moritz,

On 14/06/19 12:19, Moritz Porst wrote:

(Sorry, the answer should go to everyone)
Thanks for your response, unfortunately it didn't work out for me.
Because I am not 100% sure whether I did the correct thing I describe it:
In my layer I went to recipes-kernel/kernel/files, here I added a file
defconfig which I filled with the content of your config-initramfs
my linux-yocto_%.bbappend, residing one level lower (kernel), got this
file added so it reads (in its entirety):

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://0001-sdcard-power-management-off.patch"
SRC_URI += "file://defconfig"

However I *also* have a file called defconfig in meta-swupdate which is
basically the swupdate config that comes from menuconfig. I let this
untouched but since this is not the kernel defconfig I guess you didn't
mean this file ?

Additionally I can't mount the rootfs with the failed boot so I cannot
access the dmesg log file. Any advice here ?

Best regards
Moritz



*Gesendet:* Freitag, 14. Juni 2019 um 11:00 Uhr
*Von:* "Zoran Stojsavljevic" 
*An:* "Moritz Porst" 
*Cc:* "Yocto Project" 
*Betreff:* Re: [yocto] [meta-swupdate] failed update leads to kernel panic

However if I abort the update while running (i.e. simulating a power cut)
and then reboot I end up in a kernel panic: "Unable to mount rootfs on
unknown block". My understanding is that I should at least end up in a
busybox or that the update is retried, but this does not happen.

You missed to attach failed dmesg while the system booted and aborted.
Nevertheless, I expect problem with your defconfig, which does NOT
have options set for initramfs. These ones:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs

Please, could you add these one to your current .config, this might
very well solve your problem.

Best Regards,
Zoran
___

On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst  wrote:

Hello,

I am currently having trouble to get swupdate working properly.
My problem:
I can execute swupdate -i normally and if the update fits I have no

problem. However if I abort the update while running (i.e. simulating a
power cut) and then reboot I end up in a kernel panic: "Unable to mount
rootfs on unknown block". My understanding is that I should at least end
up in a busybox or that the update is retried, but this does not happen.

I receive 1 error when updating which does not stop the update: "Could

not find MTD".

My configuration:
I have a single rootfs and a separate boot partition. I build the

initramfs using:

You have a *single* rootfs, you stop an upgrade (resulting of course in
a corrupted rootfs or worse), and you wonder that kernel cannot mount
ityour update concept is broken.

Well conceptually I want to go through the bootloader, I just fail to
understand how I tell swupdate to do this.


You *must* check the bootloader marker in U-Boot (default is the
"recovery_status" variable) and you *mus*t start again the updater (the
ramdisk) until the marker (it is a transaction flag) is set. It is
erased by SWUpdate only after a successful update. You are now starting
your board with a half-completed update.


So I configured swupdate in menuconfig to work with grub which I set in
my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
work with grub ? (I prefer to stick to EFI because partitioning of
images works out of the box with .wic images)
When you say "you must start again the updater", that's where I'm lost.
From the documentation I understand that I initiate an update using
"swupdate -i abc.swu" but this just runs the update without setting any
flag for the bootloader.
One more thing: swupdate complains that there is no grubenv file. I
defined a path in the config file and create this file using
"grub-editenv /path/as/in/config create". swupdate does not give an
error after I have done this.



Best regards,
Stefano Babic


Best regards
Moritz





---
IMAGE_INSTALL = "base-files \
base-passwd \
swupdate \
busybox \
libconfig \
util-linux-sfdisk \
mtd-utils \
mtd-utils-ubifs \
${@bb.utils.contains('SWUPDATE_INIT', 'tiny',

'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \

"
---
This is taken from swupdate-image. I include the same packages (via

_append) in my base image, is this necessary ?

I bundle the initramfs with my image using INITRAMFS_IMAGE_BUNDLE = "1"

Can you see a mistake I made ?

Best regards
Moritz
--
___
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] [update-rc.d][PATCH V3] update-rc.d: support enable/disable options

[Changqing Li]

ping

On 5/28/19 8:59 AM, Changqing Li wrote:

ping

On 4/30/19 2:56 PM, changqing...@windriver.com wrote:

From: Changqing Li 

Add support of enable/disable options, refer
https://manpages.debian.org/wheezy/sysv-rc/update-rc.d.8.en.html

With support of these options, the usr can never change an existing
configuration even after upgrading a package. The program will only
install links if none are present, otherwise, it will keep
the previous configuration.

preinst in update-rc.d.bbclass will delete all the links under
rcrunlevel.d, this behavior now conflicts with enable/disable
options. so remove preinst from the update-rc.d.bbclass

[Yocto 12955]

Signed-off-by: Changqing Li 
---
  update-rc.d | 81 
+

  1 file changed, 81 insertions(+)

diff --git a/update-rc.d b/update-rc.d
index e07cf85..a7fb7bc 100644
--- a/update-rc.d
+++ b/update-rc.d
@@ -27,6 +27,7 @@ usage()
  usage: update-rc.d [-n] [-f] [-r ]  remove
 update-rc.d [-n] [-r ] [-s]  defaults [NN | 
sNN kNN]
 update-rc.d [-n] [-r ] [-s]  start|stop NN 
runlvl [runlvl] [...] .
+   update-rc.d [-n] [-r ] [-s]  enable|disable 
[S|2|3|4|5]

  -n: not really
  -f: force
  -v: verbose
@@ -101,6 +102,53 @@ makelinks()
  done
  }
  +# function to disable/enable init script link of one run level
+# $1 should be K/S, means to disable/enable
+# $2 means which run level to disable/enable
+renamelink()
+{
+    local oldstartstop newstartstop lev oldnn newnn
+    if [ "x$1" = "xS" ]; then
+    oldstartstop="K"
+    newstartstop="S"
+    else
+    oldstartstop="S"
+    newstartstop="K"
+    fi
+
+    lev=$2
+    # modifies existing runlevel links for the script 
/etc/init.d/name by renaming start links to stop link
+    # or stop link to start link with a sequence number equal to 
the difference of 100 minus the original sequence number.

+    if ls ${etcd}${lev}.d/${oldstartstop}*${bn} >/dev/null 2>&1; then
+    oldnn=`basename ${etcd}${lev}.d/${oldstartstop}*${bn}|cut 
-c2-3`

+    newnn=$[100-$oldnn]
+    [ $verbose -eq 1 ] && echo "rename 
${etcd}${lev}.d/${oldstartstop}${oldnn}${bn} -> 
${etcd}${lev}.d/${newstartstop}${newnn}${bn}"

+    if [ $notreally -eq 0 ];then
+    mv ${etcd}${lev}.d/${oldstartstop}${oldnn}${bn} 
${etcd}${lev}.d/${newstartstop}${newnn}${bn}

+    fi
+    if [ $dostart -eq 1 ] && [ $newstartstop = "S" ] && [ $lev = 
$RUNLEVEL ]; then

+    $fn start || true
+    fi
+    fi
+
+}
+
+# function to disable/enable init script link
+# $1 should be K/S, means to disable/enable
+# $2 run level [S|2|3|4|5], optional, If no start runlevel is
+# specified after the disable or enable keywords
+# the script will attempt to modify links in all start runlevels
+renamelinks()
+{
+    if [ $# -eq 2 ]; then
+    renamelink $1 $2
+    else
+    for i in 2 3 4 5 S; do
+    renamelink $1 $i
+    done
+    fi
+}
+
  while [ $# -gt 0 ]; do
  case $1 in
  -n)    notreally=1
@@ -221,6 +269,13 @@ case $1 in
  ;;
    start | stop)
+    if [ $# -lt 4 ]
+    then
+    echo "Not enough arguments"
+    usage
+    exit 1
+    fi
+
  while [ $# -gt 0 ]; do
  if [ $1 = "start" ]; then
  letter=S
@@ -251,6 +306,32 @@ case $1 in
  makelinks
  ;;
  +    enable | disable)
+    if [ $1 = "enable" ]; then
+    letter=S
+    elif [ $1 = "disable" ]; then
+    letter=K
+    else
+    usage
+    exit 1
+    fi
+    shift
+    #
+    if [ $# -gt 0 ]
+    then
+    case $1 in
+    S|2|3|4|5)
+    renamelinks $letter $1
+    ;;
+    *)
+    usage
+    exit 1
+    ;;
+    esac
+    else
+    renamelinks $letter
+    fi
+    ;;
  *)
  usage
  exit 1



--
BRs

Sandy(Li Changqing)

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto