Re: [yocto] Strange errors while executing poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb using scarthgap release

[Zoran]

> Remember how Fedora 40 is unsupported?  If you want to use
> Fedora 40 then you’ll need to join in with the effort to support GCC 14.1, 
> which involves fixing problems like this.
>
> If you don’t want to do that, then use a supported host distribution.

I have to give you credit for this one. I will try to apply an
external patch for gcc 14 as per Martin's advice, and see what I can
do furthermore.

I have been with Fedora since 2012 (Fedora 14), and I have not once,
not twice, but quite a few times serious issues with Fedora.

Fedora is a test distro for RHELs. I did not understand this till
recently. And also for kernel.org .

Well. Learning in the meantime also ArchLinux (alternative to it is an
Ubuntu, I also used it for a couple (maybe 4) of years in parallel
with Fedora ).
___

Allow me to try the proposed patch, and see how it goes!

Thank you,
Zee
___

On Fri, May 17, 2024 at 12:52 PM Ross Burton  wrote:
>
> On 17 May 2024, at 11:13, Zoran Stojsavljevic  
> wrote:
> > ERROR: Logfile of failure stored in:
> > /home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/temp/log.do_compile.628699
>
> If you look at the log file:
>
> | ../../git/src/lib/packlib.c:554:40: error: passing argument 1 of 
> ‘HwmsHostToBigEndian’ from incompatible pointer type 
> [-Wincompatible-pointer-types]
>
>
> Remember how Fedora 40 is unsupported?  If you want to use Fedora 40 then 
> you’ll need to join in with the effort to support GCC 14.1, which involves 
> fixing problems like this.
>
> If you don’t want to do that, then use a supported host distribution.
>
> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63134): https://lists.yoctoproject.org/g/yocto/message/63134
Mute This Topic: https://lists.yoctoproject.org/mt/106133618/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Strange errors while executing poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb using scarthgap release

[Zoran]

Hello People,

Thank you very much for helping me with uninative.

This command does it for time being (as said): INHERIT:remove = “uninative”

I fixed a few issues furthermore (my own mess).

But interesting enough, I have another package issue which popped up
(the last obstacle before building .cpio):

ERROR: cracklib-native-2.9.11-r0 do_compile: oe_runmake failed
ERROR: cracklib-native-2.9.11-r0 do_compile:
ExecutionError('/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/temp/run.do_compile.628699',
1, None, None)
ERROR: Logfile of failure stored in:
/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/temp/log.do_compile.628699

I even have no idea what the purpose of cracklib-native package is?

Should I disable it (if not important) in local.conf?

The .log. (cracklib-native.log) file is attached to this email.

Zee
___

On Thu, May 16, 2024 at 5:58 PM Khem Raj  wrote:
>
> We need a new uninative tarball generated with gcc14 for f40 so there might 
> be issues like you are seeing due to that. You can disable uninative 
> temporarily in your build and see if that works for the moment
>
> On Thu, May 16, 2024 at 8:39 AM Ross Burton via lists.yoctoproject.org 
>  wrote:
>>
>>
>>
>> > On 16 May 2024, at 16:31, Zoran via lists.yoctoproject.org 
>> >  wrote:
>> > The full log (full_log.txt) is attached to this @, as per Ur request
>> > (lot of stuff, echt!).
>>
>> From your log:
>>
>> WARNING: Host distribution "fedora-40" has not been validated with this 
>> version of the build system; you may possibly experience unexpected 
>> failures. It is recommended that you use a tested distribution.
>>
>> This is saying that Fedora 40 has not been validated and you may experience 
>> unexpected failures.
>>
>> Later in the log:
>>
>> pzstd: 
>> /home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6:
>>  version `CXXABI_1.3.15' not found (required by pzstd)
>>
>> That is the sort of unexpected failure you can expect when using Fedora 40, 
>> because it has not been validated.
>>
>> This is an incompatibility with Fedora 40 and uninative, so until this is 
>> resolved you can disable uninative with this in your local.conf:
>>
>> INHERIT:remove = “uninative”
>>
>> Ross
>> 
>>
Sstate summary: Wanted 20 Local 0 Mirrors 0 Missed 20 Current 2384 (0% match, 99% complete)0
Initialising tasks: 100% |###| Time: 0:00:05
NOTE: Executing Tasks
ERROR: cracklib-native-2.9.11-r0 do_compile: oe_runmake failed
ERROR: cracklib-native-2.9.11-r0 do_compile: ExecutionError('/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/temp/run.do_compile.628699', 1, None, None)
ERROR: Logfile of failure stored in: /home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/temp/log.do_compile.628699
Log data follows:
| DEBUG: Executing python function autotools_aclocals
| DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux', 'common']
| DEBUG: Python function autotools_aclocals finished
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4
| make  all-recursive
| make[1]: Entering directory '/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/build'
| Making all in m4
| make[2]: Entering directory '/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/build/m4'
| make[2]: Nothing to be done for 'all'.
| make[2]: Leaving directory '/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/build/m4'
| Making all in lib
| make[2]: Entering directory '/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/build/lib'
| /bin/bash ../libtool  --tag=CC   --mode=compile gcc  -DHAVE_CONFIG_H -I. -I../../git/src/lib -I..  -I. -I.. -I../../git/src/lib -DIN_CRACKLIB '-DDEFAULT_CRACKLIB_DICT="/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/recipe-sysroot-native/usr/share/cracklib/pw_dict"' -Wall -isystem/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/recipe-sysroot-native/usr/include  -isystem/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/work/x86_64-linux/cracklib-native/2.9.11/recipe-sysroot-native/usr/include -O2 -pipe -c -o packlib.lo ../../git/src/lib/packlib.c
| libtool: compile:  gcc -DHAVE_CONF

Re: [yocto] Strange errors while executing poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb using scarthgap release

[Zoran]

Hello Ross,

I guess, U might be very right!

OFF TOPIC: Fedora 40.

I had another terrible issue with Fedora 40. I pressed M-net, my net
provider, that they screwed up my DNS setup. For 4 days.

Then... I started to investigate myself!

Here is what I did find about unfortunate Fedora 40 release (IT IS
ONLY Fedora 40 release mortal issue):

https://gitlab.com/gnuwget/wget2/-/issues/661#top

https://www.reddit.com/r/Fedora/comments/1cf5jpu/switching_from_wget_to_wget2_suddenly_in_fedora/?rdt=40957

Please, all U who R using Fedora 40, find that there are issues with
newly introduced wget2 (wget2-wget) Fedora 40 packages.

Zee
___


On Thu, May 16, 2024 at 5:39 PM Ross Burton  wrote:
>
>
>
> > On 16 May 2024, at 16:31, Zoran via lists.yoctoproject.org 
> >  wrote:
> > The full log (full_log.txt) is attached to this @, as per Ur request
> > (lot of stuff, echt!).
>
> From your log:
>
> WARNING: Host distribution "fedora-40" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
>
> This is saying that Fedora 40 has not been validated and you may experience 
> unexpected failures.
>
> Later in the log:
>
> pzstd: 
> /home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6:
>  version `CXXABI_1.3.15' not found (required by pzstd)
>
> That is the sort of unexpected failure you can expect when using Fedora 40, 
> because it has not been validated.
>
> This is an incompatibility with Fedora 40 and uninative, so until this is 
> resolved you can disable uninative with this in your local.conf:
>
> INHERIT:remove = “uninative”
>
> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63123): https://lists.yoctoproject.org/g/yocto/message/63123
Mute This Topic: https://lists.yoctoproject.org/mt/106133618/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Strange errors while executing poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb using scarthgap release

[Zoran]

Hello all,

I have a really strange error while compiling gcc-cross_13.2 ?!

Here is the error appearing:
ERROR: Task 
(/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb:do_gcc_stash_builddir)
failed with exit code '1'

I eliminate this error using the following addition, just to see if
the compiling will go further:

I edited poky/meta/recipes-devtools/gcc/gcc-cross.inc and added the
following line:

--- a/meta/recipes-devtools/gcc/gcc-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross.inc
@@ -131,6 +131,7 @@ do_packagedata[noexec] = "1"
 do_package_write_ipk[noexec] = "1"
 do_package_write_rpm[noexec] = "1"
 do_package_write_deb[noexec] = "1"
+do_gcc_stash_builddir[noexec] = "1" <<<===

It does pass further, till the next error:
ERROR: Task 
(/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb:do_populate_sysroot)
failed with exit code '1'

I did not take the same path, since I could not ignore the
do_populate_sysroot() task.

Does anybody have any info on such an occurrence in scarthgap release (5.0.1)?

Thank you in advance,
Zee
___

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63115): https://lists.yoctoproject.org/g/yocto/message/63115
Mute This Topic: https://lists.yoctoproject.org/mt/106133618/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] initramfs creation

[Zoran]

Please, read carefully thru this yocto @ thread.

https://www.yoctoproject.org/pipermail/yocto/2018-July/041680.html

I hope this does help.

Zee
___

On Wed, Dec 6, 2023 at 10:47 PM  wrote:
>
>  Hi,
>
> I'm trying to create a custom initramfs to handle some things before 
> switching root to my actual filesystem.  I followed the docs and have been 
> able to use INITRAMFS_IMAGE = "custom-image" and INITRAMFS_IMAGE_BUNDLE = "1" 
> to generate a zImage for my ARM platform.
>
> The custom-image.bb recipe is based on the core-image-minimal-initramfs 
> recipe and is in a meta-layer that has another image recipe for the actual 
> eMMC filesystem image.  Both the eMMC image and initramfs bundle are created.
>
> In custom-image.bb, PACKAGE_INSTALL includes INITRAMFS_SCRIPTS which seem to 
> be geared towards live-image things but that's not what I want.
>
> The image boots but hangs waiting for removable media.  I figured out that 
> /init is not pointing to systemd but the live-image script from 
> recipes-core/initrdscripts.
>
> For testing I manually symlinked systemd to /init and the board boots but it 
> wants a login password which was never created, I'm guessing its not 
> inheriting debug-tweaks from my local.conf?
>
> So my question is, what is the correct way to create a minimal initramfs 
> image along side the real recipe/image within a meta-layer?
>
> Does anyone have an example of doing this?
>
> Thanks, Matt.
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61823): https://lists.yoctoproject.org/g/yocto/message/61823
Mute This Topic: https://lists.yoctoproject.org/mt/103022933/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] TI AM62x based EV charger platform with Pionix UI s/w Image build problem. #apt #bitbake #distro #poky

[Zoran]

Hello Sairaj,

You should do df command and explore how much of your /home or /
partitions (have no idea how the system was installed) is left.

Maybe you have a problem with the limited free space on your SSD/HDD?

You should have at least 60GB or even more disk space available to do
one successful YOCTO build.

Two cent worth answer,
Zee
___


On Tue, Nov 28, 2023 at 7:00 AM  wrote:
>
> Hi team,
>
>
>
> we are trying to build TI AM62x EVSE SDK referring to 
> https://github.com/PionixPublic/ti-am62x-evse-sdk  we have tried building in 
> virtual machine and now we are trying to build in Linux  host pc with 500gb 
> of storage and 16gb ram but still bitbake runs till 99 percentage   and last 
> module Nodejs takes forever to run system experiences a freeze. Tried 
> multiple times running the bitbake but still problem remains same .
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61767): https://lists.yoctoproject.org/g/yocto/message/61767
Mute This Topic: https://lists.yoctoproject.org/mt/102846254/21656
Mute #distro:https://lists.yoctoproject.org/g/yocto/mutehashtag/distro
Mute #poky:https://lists.yoctoproject.org/g/yocto/mutehashtag/poky
Mute #apt:https://lists.yoctoproject.org/g/yocto/mutehashtag/apt
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] relabel selinux system at build time: meta-selinux (thud)

[Zoran]

I am, as we speak (Real Time here and now) working on Android 10 and
12 SELinux...

Has not too much to do with YOCTO. But I can tell you... It is bloody
tough stuff. Especially crossing the domains...

If you have any questions about that, you can ask me. If I can help? If so?

Zee
___

On Tue, Apr 4, 2023 at 12:33 PM Zoran Stojsavljevic
 wrote:
>
> This is a very tough one!
>
> Zee
> ___
>
> On Tue, Apr 4, 2023 at 11:38 AM Kamal Kishor  
> wrote:
> >
> > Hi,
> > I need to relabel the rootfs at build time instead of first boot. 
> > Currently, I am using thud branch of meta-selinux. I came across the series 
> > of patches mentioned below to enable relabelling at build time. Out of 
> > these patches some are already pushed to thud branch and some are not 
> > present. So, can someone in the community help me to figure out what all 
> > patches are required.
> > Also, I was thinking of using ROOTFS_POSTPROCESS_COMMAND or 
> > IMAGE_POSTPROCESS_COMMAND to relabel the filesystem. If this is possible 
> > what would be the steps in the postprocess funtion. Do I have to use 
> > restorecon command or setfiles command to relabel the filesystem.
> > The link to the series of patches is shown below:
> > filesystem relabel at build time
> >
> > Please provide you valuable inputs on this. If you need any more 
> > information feel free to contact
> >
> > Thanks
> > Kamal Pandey
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59612): https://lists.yoctoproject.org/g/yocto/message/59612
Mute This Topic: https://lists.yoctoproject.org/mt/98056379/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe

[Zoran]

Do not bother... This is a war between me and the entire YOCTO
community of founders... It has been going for a while. Lot of INTEL
guys and former INTEL guys against former INTEL guy. Me.

But, I came here with Peace. It seems some people could not overcome their EGOs.

I am trying to ask for a brainstorming. Now, I am trying to
understand, why the backpors took place from kirkstone... Once my
scripts were working for hardknott...

But they do not work anymore.

Well...

Not my fault. Just trying to push forward.

Zee
___

On Thu, Dec 1, 2022 at 6:01 PM Alexander Kanavin  wrote:
>
> On Thu, 1 Dec 2022 at 17:41, Rudolf J Streif  wrote:
> >
> >
> > > Recently I've also seen this:
> > > LAYERSERIES_COMPAT_phytec = "${LAYERSERIES_COMPAT_core}"
> > >
> > Oh no, now the entire Yocto Project world knows about this hack. Now we
> > need a sanity checker for this in the insane class. :)
>
> It's a slippery slope. We can also for example make bitbake forcibly
> not expand any variables in it, and write out an angry rant when
> someone tries, and then I'm sure determined people will find a way
> around that too.
>
> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58711): https://lists.yoctoproject.org/g/yocto/message/58711
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe

[Zoran]

Agreed. Will revert.

Zee
___

On Thu, Dec 1, 2022 at 1:48 PM Ross Burton  wrote:
>
> On 1 Dec 2022, at 12:46, Zoran Stojsavljevic  
> wrote:
> > But, could you, please, allow me to have my own original cannelloni
> > recipe (yes, I developed it with some help from this community) on my
> > own terms? I DID not copy it from anywhere. It is an ORIGINAL.
>
> As I explained in the bug I filed in your repository, the LICENSE statement 
> is the license of the contents of the packages, not the recipe itself.
>
> https://github.com/mguentner/cannelloni clearly says GPLv2.
>
> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58705): https://lists.yoctoproject.org/g/yocto/message/58705
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe

[Zoran]

Martin, U R too fast. Speedy Gonzales. ;-)

I do agree that this is the bad practice to change licences for the
known recipes. For the can-utils and socketcand. I'll revert this back
to GPLv2.

But, could you, please, allow me to have my own original cannelloni
recipe (yes, I developed it with some help from this community) on my
own terms? I DID not copy it from anywhere. It is an ORIGINAL.

Please, check. Do NOT overspeed. Please.

Thank you for your advice.

Zee
___

On Thu, Dec 1, 2022 at 12:18 PM Martin Jansa  wrote:
>
> On Thu, Dec 1, 2022 at 12:09 PM Ross Burton  wrote:
>>
>> On 1 Dec 2022, at 04:27, Zoran via lists.yoctoproject.org 
>>  wrote:
>> > I do not understand why we need to explicitly name releases for such
>> > simple generic layers?!
>>
>> The compatibility is because over time things change: override syntax has 
>> changed, classes get added or removed, functionality may appear in bitbake.  
>> Sometimes the breakage is subtle, and a layer may parse and appear to build 
>> fine, but be broken.
>>
>> Your meta-socketcan layer is broken in honister onwards despite claiming 
>> compatibility, for example.
>
>
> And here is another example why nobody should be using meta-socketcan:
> https://github.com/ZoranStojsavljevic/meta-socketcan/commit/cefd86cd1def9ad2e63be527f8ce36a076d7e17c#
>
> You cannot change the declared LICENSE of the components, just because you 
> wish them to use the same license as the layer metadata, especially when 
> those components clearly declare different LICENSE in the source code, e.g.:
> https://github.com/linux-can/socketcand/commit/a7ab9878d11ac187b92dcf48b6331c228f4f4b92
>
> Using COMMON_LICENSE_DIR in LIC_FILES_CHKSUM is another anti-pattern which 
> just disables whole purpose of LIC_FILES_CHKSUM and this is acceptable only 
> for "pure-metadata" recipes like packagegroups or image recipes.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58702): https://lists.yoctoproject.org/g/yocto/message/58702
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe

[Zoran]

Ross,

It is now broken even in hardknott. I tried it, just as I tried it
before (it worked before).

I have no idea what the ERROR is:

zoran.s@NBK0005U:~/projects2/yocto/bbb-yocto/build$ bitbake -k
core-image-minimal
Loading cache: 100% |
| ETA:
 --:--:--
Loaded 0 entries from dependency cache.
Parsing recipes: 100%
|#|
Time: 0:00:23
Parsing of 814 .bb files complete (0 cached, 814 parsed). 1438
targets, 41 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'cannelloni' (but
/home/zoran.s/projects2/yocto/bbb-yocto/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'cannelloni' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['cannelloni']
ERROR: Nothing RPROVIDES 'can-utils' (but
/home/zoran.s/projects2/yocto/bbb-yocto/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'can-utils' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['can-utils']
ERROR: Nothing RPROVIDES 'socketcand' (but
/home/zoran.s/projects2/yocto/bbb-yocto/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'socketcand' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['socketcand']
ERROR: Nothing RPROVIDES 'core-image-minimal'
No eligible RPROVIDERs exist for 'core-image-minimal'
NOTE: Runtime target 'core-image-minimal' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['core-image-minimal']


And my 
/home/zoran.s/projects2/yocto/bbb-yocto/poky/meta/recipes-core/images/core-image-minimal.bb
is:

SUMMARY = "A small image just capable of allowing a device to boot."

IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"

IMAGE_LINGUAS = " "

LICENSE = "MIT"

nano meta/recipes-core/images/core-image-minimal.bb

## IMAGE_INSTALL_append = " kernel-modules"
IMAGE_INSTALL_append = " \
kernel-modules \
cannelloni \
can-utils \
socketcand \
"

IMAGE_ROOTFS_SIZE ?= "8192"
IMAGE_ROOTFS_EXTRA_SPACE_append =
"${@bb.utils.contains("DISTRO_FEATURES", "systemd", " + 4096", ""
,d)}"

Zee


On Thu, Dec 1, 2022 at 12:09 PM Ross Burton  wrote:
>
> On 1 Dec 2022, at 04:27, Zoran via lists.yoctoproject.org 
>  wrote:
> > I do not understand why we need to explicitly name releases for such
> > simple generic layers?!
>
> The compatibility is because over time things change: override syntax has 
> changed, classes get added or removed, functionality may appear in bitbake.  
> Sometimes the breakage is subtle, and a layer may parse and appear to build 
> fine, but be broken.
>
> Your meta-socketcan layer is broken in honister onwards despite claiming 
> compatibility, for example.
>
> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58701): https://lists.yoctoproject.org/g/yocto/message/58701
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe

[Zoran]

Hello to Yocto community,

As I am much more passive yocto wise these few years ( working on
Android build systems and around, this is also a nightmare, I should
say ;-) ), I have one Yocto question which I never really understood.

I will ask it by example. I have one layer for the CAN tools and apps
which I have created 4 years ago:
https://github.com/ZoranStojsavljevic/meta-socketcan

In there, in conf/layer.conf:
https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/conf/layer.conf

I have the following line (layers' compatibility):
LAYERSERIES_COMPAT_meta-socketcan = "sumo thud warrior zeus dunfell
gatesgarth hardknott honister kirkstone"

I do not understand why we need to explicitly name releases for such
simple generic layers?!

Instead, for a virtual example:
LAYERSERIES_COMPAT_meta-socketcan = "${AUTOLAYER x}"

So all the layers might be included (or for at least lets say x = 4
latest releases, where x = 0 would be include all)? I do understand
that complex layers could NOT have such a definition (because of the
dependencies), but for the generic layers (as such presented), this
would be beneficial.

Thank you for the answers,
Zee
___

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58689): https://lists.yoctoproject.org/g/yocto/message/58689
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #dunfell

[Zoran]

>>> - for imageType in ${KERNEL_IMAGETYPES} ; do
>>> + for imageType in ${KERNEL_IMAGETYPE_FOR_MAKE} ; do

Interesting... What is the difference between variables
${KERNEL_IMAGETYPES} and ${KERNEL_IMAGETYPE_FOR_MAKE} ?

Zee
___

On Thu, Nov 3, 2022 at 5:24 PM Frederic Martinsons
 wrote:
>
> Hello, I'm currently migrating our system from warrior to dunfell and I have 
> an issue on fitImage support for aarch64 architecture. We use 
> KERNEL_IMAGETYPE = "fitImage" and INITRAMFS_IMAGE_BUNDLE = "1" in our 
> configuration and the kernel do_deploy steps failed on not finding the 
> initramfs file:
>
> ```
> | lib/modules/4.19.255-rt113-sigfox/kernel/drivers/usb/serial/usb_wwan.ko
> | lib/modules/4.19.255-rt113-sigfox/kernel/drivers/usb/serial/option.ko
> | lib/modules/4.19.255-rt113-sigfox/kernel/drivers/usb/class/
> | lib/modules/4.19.255-rt113-sigfox/kernel/drivers/usb/class/cdc-wdm.ko
> | lib/modules/4.19.255-rt113-sigfox/modules.order
> | lib/modules/4.19.255-rt113-sigfox/modules.builtin
> | install: cannot stat 'arch/arm64/boot/Image.initramfs': No such file or 
> directory
> | WARNING: exit code 1 from a shell command.
> | ERROR: Execution of 
> '/home/fmartinsons/TAPOS_build_for_dunfell/build-tapos/tmp/work/a3700-tapos-linux/linux-sbs/4.19.255+gitAUTOINC+5c7ccbe1aa-r4.17.1.1/temp/run.do_deploy.1460182'
>  failed with exit code 1
> ```
>
> Doing some more research, I found that the problem came from this change 
> https://git.openembedded.org/openembedded-core/commit/?id=526bdd88ccd758204452579333ba188e29270bde
>  , I found a commit introduced in kirkstone that fix my issue (at least the 
> part which revert the previous commit): 
> https://git.openembedded.org/openembedded-core/commit/?id=10a4a132e87e835726bf5da81a60f6f509b90765
>
> Can somebody know why the commit was not back-ported in dunfell ?
>
> Regards.
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58481): https://lists.yoctoproject.org/g/yocto/message/58481
Mute This Topic: https://lists.yoctoproject.org/mt/94774777/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Help with setting up a PREEMPT_RT image for BeagleBone Black #yocto

[Zoran]

Michael,

I am not sure what you are trying to achieve, but I have some advice for you.

Here is what you need to do in local.conf:

MACHINE ?= "beaglebone"
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"

Not sure what the last two commands should be, but you should NOT
mention any rt.

For -rt bbb you should set following options in virtual/kernel make menuconfig:

# CONFIG_SMP is not set
# CONFIG_MODULES is not set

CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCKDEP is not set

# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set

# CONFIG_NO_HZ is not set
CONFIG_HZ_PERIODIC=y

CONFIG_HZ_250=y
CONFIG_HZ=250

# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
# CONFIG_PM is not set

# CONFIG_FTRACE is not set

CONFIG_PREEMPT_RT_FULL=y

The commands to setup the menuconfig are the following:

[1] Run menuconfig and configure the kernel:
 $ bitbake -c menuconfig virtual/kernel

[2] To save the configuration in a defconfig format:
  $  bitbake -c savedefconfig virtual/kernel

https://variwiki.com/index.php?title=Yocto_Customizing_the_Linux_kernel

Then, you should have a bbb-rt kernel. With some tweaks and some
tricks... You'll find these for yourself!

Please, use the rt-tests package for testing kernel-bbb-rt.

My two cent worth answer,
Zee
___

On Tue, Nov 1, 2022 at 1:54 PM Bruce Ashfield  wrote:
>
> In message: [yocto] Help with setting up a PREEMPT_RT image for BeagleBone 
> Black #yocto
> on 27/10/2022 mpha...@gmu.edu wrote:
>
> > Hello all,
> >
> > I am new to Yocto and would like to seek assistance for setting up a 
> > PREEMPT_RT
> > image for BeagleBone Black.
> >
> > Here is what I have tried so far. First I followed the Yocto Project Quick
> > Build tutorial in the documentation.
> >
> > 1)
> > sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential
> > chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils
> > iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint 
> > xterm
> > python3-subunit mesa-common-dev zstd liblz4-tool
> >
> > 2)
> > git clone git://git.yoctoproject.org/poky
> >
> > 3)
> > cd poky
> >
> > 4)
> > git checkout -t origin/langdale -b my-langdale
> >
> > 5)
> > git pull
> >
> > 6)
> > source oe-init-build-env
> >
> > 7) Then I went to poky/build/conf and edited local.conf by uncommenting
> > MACHINE ?= "beaglebone-yocto"
> > and commenting out
> > #MACHINE ??= "qemux86-64"
> > Then I added these two lines at the bottom of the file:
> > PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
> > COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
> >
> > 8) Next I ran this command:
> > bitbake core-image-minimal
> >
> > 9) Then I get errors at this point.
> > ERROR: Nothing PROVIDES 'virtual/kernel'
> > linux-yocto-upstream PROVIDES virtual/kernel but was skipped: Set
> > PREFERRED_PROVIDER_virtual/kernel to linux-yocto-upstream to enable it
> > linux-yocto PROVIDES virtual/kernel but was skipped: Set
> > PREFERRED_PROVIDER_virtual/kernel to linux-yocto to enable it
> > linux-yocto-rt PROVIDES virtual/kernel but was skipped: incompatible with
> > machine beaglebone-yocto (not in COMPATIBLE_MACHINE)
> > linux-yocto-dev PROVIDES virtual/kernel but was skipped: Set
> > PREFERRED_PROVIDER_virtual/kernel to linux-yocto-dev to enable it
> > linux-yocto-rt PROVIDES virtual/kernel but was skipped: incompatible with
> > machine beaglebone-yocto (not in COMPATIBLE_MACHINE)
> > linux-yocto-upstream PROVIDES virtual/kernel but was skipped: Set
> > PREFERRED_PROVIDER_virtual/kernel to linux-yocto-upstream to enable it
> > linux-yocto PROVIDES virtual/kernel but was skipped: Set
> > PREFERRED_PROVIDER_virtual/kernel to linux-yocto to enable it
> > linux-yocto-tiny PROVIDES virtual/kernel but was skipped: incompatible with
> > machine beaglebone-yocto (not in COMPATIBLE_MACHINE)
> > linux-dummy PROVIDES virtual/kernel but was skipped: 
> > PREFERRED_PROVIDER_virtual
> > /kernel set to linux-yocto-rt, not linux-dummy
> > linux-yocto-tiny PROVIDES virtual/kernel but was skipped: incompatible with
> > machine beaglebone-yocto (not in COMPATIBLE_MACHINE)
> > ERROR: Required build target 'core-image-minimal' has no buildable 
> > providers.
> > Missing or unbuildable dependency chain was: ['core-image-minimal', 
> > 'virtual/
> > kernel']
> >
> > Summary: There was 1 WARNING message.
> > Summary: There were 2 ERROR messages, returning a non-zero exit code.
> >
> > I've tried a variety of ways and read lots of links but still no luck. Can
> > someone tell me the best way to accomplish my goal?
> > Thank you for any help.
>
> To build a kernel recipe (not just linux-yocto), it must be marked
> as compatible with your machine. The messages you are seeing are
> telling you that, by indicating that the recipes were skipped 

Re: [yocto] Error during linux booting

[Zoran]

> For enabling systemd its best to start with
> DISTRO = "poky-altcfg"

With all due respect, Khem, I thought that this line in local.conf
makes systemd as default?!
INIT_MANAGER ?= "systemd"

>> Hello Zoran
>> Yes, i have set INIT_MANAGER ?= "systemd"

Zee
___

On Fri, Oct 21, 2022 at 6:28 PM Khem Raj  wrote:
>
> If you are using poky then ssytemd is not default init system, its
> sysvinit. For enabling systemd its best to start with
>
> DISTRO = "poky-altcfg"
>
> On Sun, Oct 16, 2022 at 11:32 AM Vaibhav Deshpande
>  wrote:
> >
> > Hello
> >
> > I am trying to build a yocto image from the kirkstone branch 
> > (https://github.com/openembedded/openembedded-core/tree/kirkstone) build 
> > gets successful but at the time of linux booting I am getting below error.
> >
> > [0.00] Linux version 5.19.0-rc4 (oe-user@oe-host) 
> > (riscv64-oe-linux-gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.38.20220708) #1 
> > SMP Wed Aug 24 14:46:22 UTC 2022
> > [0.00] random: crng init done
> > [0.00] Machine model: Ventana VT1 QEMU
> > [0.00] SBI specification v1.0 detected
> > [0.00] SBI implementation ID=0x1 Version=0x10001
> > [0.00] SBI TIME extension detected
> > [0.00] SBI IPI extension detected
> > [0.00] SBI RFENCE extension detected
> > [0.00] SBI SRST extension detected
> > [0.00] earlycon: uart8250 at MMIO 0x1000 (options '')
> > [0.00] printk: bootconsole [uart8250] enabled
> > [0.00] efi: EFI v2.90 by Das U-Boot
> > [0.00] efi: RTPROP=0xfe73c020 SMBIOS=0xfe738000 
> > MEMRESERVE=0xfd3ca020
> > [0.00] Zone ranges:
> > [0.00]   DMA32[mem 0x8000-0x]
> > [0.00]   Normal   empty
> > [0.00] Movable zone start for each node
> > [0.00] Early memory node ranges
> > [0.00]   node   0: [mem 0x8000-0xfe737fff]
> > [0.00]   node   0: [mem 0xfe738000-0xfe738fff]
> > [0.00]   node   0: [mem 0xfe739000-0xfe73bfff]
> > [0.00]   node   0: [mem 0xfe73c000-0xfe742fff]
> > [0.00]   node   0: [mem 0xfe743000-0xfff77fff]
> > [0.00]   node   0: [mem 0xfff78000-0xfff78fff]
> > [0.00]   node   0: [mem 0xfff79000-0x]
> > [0.00] Initmem setup node 0 [mem 
> > 0x8000-0x]
> > [0.00] SBI HSM extension detected
> > [0.00] riscv: base ISA extensions acdfhim
> > [0.00] riscv: ELF capabilities acdfim
> > [0.00] riscv: Svinval extension supported
> > [0.00] percpu: Embedded 18 pages/cpu s34488 r8192 d31048 u73728
> > [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 516096
> > [0.00] Kernel command line: root=/dev/vda2 rootwait console=ttyS0 
> > earlycon=uart8250,mmio,0x1000
> > [0.00] Dentry cache hash table entries: 262144 (order: 9, 2097152 
> > bytes, linear)
> > [0.00] Inode-cache hash table entries: 131072 (order: 8, 1048576 
> > bytes, linear)
> > [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
> > [0.00] Virtual kernel memory layout:
> > [0.00]   fixmap : 0xff1bfee0 - 0xff1bff00   
> > (2048 kB)
> > [0.00]   pci io : 0xff1bff00 - 0xff1c   (  
> > 16 MB)
> > [0.00]  vmemmap : 0xff1c - 0xff20   
> > (1024 TB)
> > [0.00]  vmalloc : 0xff20 - 0xff60   
> > (16384 TB)
> > [0.00]   lowmem : 0xff60 - 0xff608000   
> > (2048 MB)
> > [0.00]   kernel : 0x8000 - 0x   
> > (2047 MB)
> > [0.00] Memory: 2034884K/2097152K available (7677K kernel code, 
> > 4908K rwdata, 4096K rodata, 2204K init, 463K bss, 62268K reserved, 0K 
> > cma-reserved)
> > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1
> > [0.00] rcu: Hierarchical RCU implementation.
> > [0.00] rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=16.
> > [0.00] rcu: RCU debug extended QS entry/exit.
> > [0.00] Tracing variant of Tasks RCU enabled.
> > [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 
> > 25 jiffies.
> > [0.00] rcu: Adjusting geometry for rcu_fano

Re: [yocto] Raspberry Pi 4 h264 encoder

[Zoran]

I see that you are using the following (EXO) player:
https://github.com/google/ExoPlayer

I see that you are trying to use the HW codec for H264.

In Android, I use also the SW codec with the option:
--encoder OMX.google.h264.encoder

This email is just to make the context much cleaner, and
understandable... To YOCTO primes.

And, yes, It is interesting to me as well. How to include rpi4 HW
coders into the context? ;-)

NOT only for rpi4 silicon... ;-))

Thank you all,
Zee
___


On Fri, Oct 21, 2022 at 10:56 AM Ed Watson  wrote:
>
> I want to increase the performance streaming from a rpi4 via an rtsp streamer.
>
> I am using ffmpeg to do the encoding however it is using CPU encoding.
>
> What is the right options for using the hardware in 264 encoding?
> I assume it is  -c:v h264_omx
>
> That is not compiled it.
>
> I added to ffmpeg_%.bbappend
>
> PACKAGECONFIG += " omx omx-rpi "
>
>
>
> PACKAGECONFIG[omx] = "--enable-omx"
>
> PACKAGECONFIG[omi-rpi] = "--enable-omx-rpi"
>
>
>
> DEPENDS =+ "virtual/libomxil"
>
> RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_libomxil}"
>
> I get the error.
>
> ERROR: OMX_Core.h not found
>
>
>
> Am I braking up the wrong tree here?
>
> Thanks
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58391): https://lists.yoctoproject.org/g/yocto/message/58391
Mute This Topic: https://lists.yoctoproject.org/mt/94472166/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Error during linux booting

[Zoran]

> I have added systemd in rootfs by adding
> MAGE_INSTALL = " systemd" in local.conf
> and the issue solved is this required for the
> latest yocto version (kirkstone)?

You did set the INIT_MANAGER ?= "systemd", didn't you?

And how (in which manner) systemd influences the console, or consoles setup?

Consoles' setup should be done much earlier then systemd!?

Zee
___

On Thu, Oct 20, 2022 at 7:07 PM Vaibhav Deshpande
 wrote:
>
> Helo
>
> I have added systemd in rootfs by adding IMAGE_INSTALL = " systemd" in 
> local.conf and the issue solved
> is this required for the latest yocto version (kirkstone)?
>
>
> Thank you.
>
> Regards
> Vaibhav Vivek Deshpande
>
>
> On Mon, Oct 17, 2022 at 1:28 AM Zoran Stojsavljevic 
>  wrote:
>>
>> Interesting... Looking into the log massage itself!
>>
>> > [0.00] Kernel command line: root=/dev/vda2 rootwait console=ttyS0 
>> > earlycon=uart8250,mmio,0x1000
>>
>> Command line does not specify baud rate... Usually by default it is
>> 115200. Just a kludge.
>>
>> Then:
>>
>> > [0.00] earlycon: uart8250 at MMIO 0x1000 (options '')
>> > [0.00] printk: bootconsole [uart8250] enabled
>>
>> bootconsole enabled, seems correct.
>>
>> Then:
>>
>> > [1.628806] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>> > [1.648238] printk: console [ttyS0] disabled
>> > [1.652252] 1000.uart: ttyS0 at MMIO 0x1000 (irq = 166, 
>> > base_baud = 230400) is a 16550A
>> > [1.656816] printk: console [ttyS0] enabled
>> > [1.656816] printk: console [ttyS0] enabled
>> > [1.657728] printk: bootconsole [uart8250] disabled
>> > [1.657728] printk: bootconsole [uart8250] disabled
>>
>> From what we see that the base baud rate is 230400 (?), everything
>> else is, seems, correct.
>>
>> So, three things, which came adhoc to my mind:
>> [1] Please, check the baud rate;
>> [2] Please, check to which group /dev/ttyS0 belongs (root dialout)?
>> [3] The terminal should be interactive, but no way to check this (from
>> the logs)???
>>
>> My two cent worth answer,
>> Zee
>> ___
>>
>> On Sun, Oct 16, 2022 at 8:32 PM Vaibhav Deshpande
>>  wrote:
>> >
>> > Hello
>> >
>> > I am trying to build a yocto image from the kirkstone branch 
>> > (https://github.com/openembedded/openembedded-core/tree/kirkstone) build 
>> > gets successful but at the time of linux booting I am getting below error.
>>
>> ...[snap]...

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58387): https://lists.yoctoproject.org/g/yocto/message/58387
Mute This Topic: https://lists.yoctoproject.org/mt/94368916/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Error during linux booting

[Zoran]

Interesting... Looking into the log massage itself!

> [0.00] Kernel command line: root=/dev/vda2 rootwait console=ttyS0 
> earlycon=uart8250,mmio,0x1000

Command line does not specify baud rate... Usually by default it is
115200. Just a kludge.

Then:

> [0.00] earlycon: uart8250 at MMIO 0x1000 (options '')
> [0.00] printk: bootconsole [uart8250] enabled

bootconsole enabled, seems correct.

Then:

> [1.628806] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> [1.648238] printk: console [ttyS0] disabled
> [1.652252] 1000.uart: ttyS0 at MMIO 0x1000 (irq = 166, base_baud 
> = 230400) is a 16550A
> [1.656816] printk: console [ttyS0] enabled
> [1.656816] printk: console [ttyS0] enabled
> [1.657728] printk: bootconsole [uart8250] disabled
> [1.657728] printk: bootconsole [uart8250] disabled

>From what we see that the base baud rate is 230400 (?), everything
else is, seems, correct.

So, three things, which came adhoc to my mind:
[1] Please, check the baud rate;
[2] Please, check to which group /dev/ttyS0 belongs (root dialout)?
[3] The terminal should be interactive, but no way to check this (from
the logs)???

My two cent worth answer,
Zee
___

On Sun, Oct 16, 2022 at 8:32 PM Vaibhav Deshpande
 wrote:
>
> Hello
>
> I am trying to build a yocto image from the kirkstone branch 
> (https://github.com/openembedded/openembedded-core/tree/kirkstone) build gets 
> successful but at the time of linux booting I am getting below error.

...[snap]...

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58345): https://lists.yoctoproject.org/g/yocto/message/58345
Mute This Topic: https://lists.yoctoproject.org/mt/94368916/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] OE Linux & board-support-package

[Zoran]

This is very interesting... How do some people, or system IT
"designers", or System guys, perceive the term: "Board Support
Package"???

Funny, isn't it? Or, at least, pejorative!?

Zee
___

On Thu, May 5, 2022 at 5:42 AM jchludzinski via lists.yoctoproject.org
 wrote:
>
> OE Linux uses device tree files (*.dts and *.dtsi files), so is there
> any need for a board-support-package?
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57021): https://lists.yoctoproject.org/g/yocto/message/57021
Mute This Topic: https://lists.yoctoproject.org/mt/90904726/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] OE Linux & board-support-package

[Zoran]

Hello J,

Please, could you be more specific?

Thank you,
Zee
___


On Thu, May 5, 2022 at 5:42 AM jchludzinski via lists.yoctoproject.org
 wrote:
>
> OE Linux uses device tree files (*.dts and *.dtsi files), so is there
> any need for a board-support-package?
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56997): https://lists.yoctoproject.org/g/yocto/message/56997
Mute This Topic: https://lists.yoctoproject.org/mt/90904726/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Question about initramfs and fitImage

[Zoran]

Hello Khoi,

This might be is your starting point:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041680.html

Zee
___

On Thu, Apr 28, 2022 at 11:13 PM Khoi Dinh Trinh
 wrote:
>
> Hi All,
>
> I'm trying to build an image that uses the currently built image as the 
> initramfs instead of having to specify it in "INITRAMFS_IMAGE". For example, 
> when I run "bibake image-something", I'm hoping to use the recipe 
> "image-something" as the initramfs with the end goal that it's used in 
> creating a fit image. AFAIK, INITRAMFS_IMAGE has to be hardcoded instead of 
> being dynamically set to the name of the currently built recipe(which I 
> completely understand since the recipe being built might not necessarily be 
> an image) and this makes it easy to boot the wrong thing since the recipe 
> specified with bitbake isn't the thing being used for booting.
>
> My workaround so far is to create my own image recipe and set it to depend on 
> the image being built(specifically depend on the .cpio.gz one), however, a 
> lot of it is duplicate of the current fit image code.
>
> Our use case is that we use initramfs as our only rootfs storage to make 
> checksum at boot easier(since the final rootfs is a .cpio.gz blob) and also 
> to avoid any writes to rootfs to persist across reboot.
>
> --
> Best,
> Khoi Trinh
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56962): https://lists.yoctoproject.org/g/yocto/message/56962
Mute This Topic: https://lists.yoctoproject.org/mt/90763430/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] package and booting an initramfs image

[Zoran]

Please, read carefully thru this yocto @ thread.

https://www.yoctoproject.org/pipermail/yocto/2018-July/041680.html

Zee
___

On Tue, Apr 19, 2022 at 8:27 PM  wrote:
>
> I have a need to package my kernel, dtb, and rootfs manually and then boot 
> this as an initramfs. I'm not sure which files from the deploy/images 
> directory to use. I see there is an rootfs.cpio.gz file so I'm starting with 
> that. If I unpack that I see the kernel Image and dtb in the /boot folder and 
> what appears to be a filesystem in the rest. If I try to boot this as my 
> kernel in u-boot I get this
> Bad Linux ARM64 Image magic!
> ** No partition table - mmc 2 **
> ** No partition table - mmc 2 **
>
> Does this cpio.gz file have everything I need? How do I boot with it and 
> enter an initramfs?
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56819): https://lists.yoctoproject.org/g/yocto/message/56819
Mute This Topic: https://lists.yoctoproject.org/mt/90568270/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #zeus Problem with moving from rocko to zeus

[Zoran]

Dule, Dule, Dudule!

Slusaj i prati sta ti YOCTO velicine pricaju! I pokusaj sam da se
snadjes, jer te dobro navode! ;-)

Zee
___

On Fri, Feb 11, 2022 at 8:38 AM Dusan Radic  wrote:
>
> Here is the error:
>
> | .../kernel-source/include/linux/log2.h:22:1: warning: ignoring
> attribute 'noreturn' because it conflicts with attribute 'const'
> [-Wattributes]
> |22 | int ilog2_NaN(void);
> |   | ^~~
> | /tmp/ccA2wTxM.s: Assembler messages:
> | /tmp/ccA2wTxM.s:3486: Error: .err encountered
> | /tmp/ccA2wTxM.s:3546: Error: .err encountered
> | .../kernel-source/scripts/Makefile.build:258: recipe for target
> 'fs/fat/dir.o' failed
> | make[4]: *** [fs/fat/dir.o] Error 1
> | make[4]: *** Waiting for unfinished jobs
> |   CC  fs/cifs/smb2maperror.o
> | In file included from .../kernel-source/include/linux/kernel.h:11,
>
> However, now that I have switched to linux-imx-4.14.98 I made
> significant progress.
> It looks like it's going to work, I'll keep you posted.
>
> Best regards,
> Dule
>
> On Thu, Feb 10, 2022 at 6:20 PM Khem Raj  wrote:
> >
> >
> >
> > On 2/10/22 8:56 AM, Dusan Radic wrote:
> > > Hello,
> > >
> > > I am trying to upgrade my distro from rocko to zeus.
> > > After I fixed all the initial parsing and build problems I have
> > > reached a point where the linux-imx doesn't build. Maybe I am
> > > underestimating the task in front of me, but I have already seen it
> > > done.
> > >
> > > The error looks like this:
> > >
> > > | .../kernel-source/Makefile:947: recipe for target 'fs' failed
> > > | make[2]: *** [fs] Error 2
> > > | Makefile:146: recipe for target 'sub-make' failed
> > > | make[1]: *** [sub-make] Error 2
> > > | Makefile:24: recipe for target '__sub-make' failed
> > > | make: *** [__sub-make] Error 2
> > > | WARNING: exit code 1 from a shell command.
> > > |
> > > ERROR: Task 
> > > (.../meta-mylayer/recipes-kernel/linux/linux-imx_4.1.15.bb:do_compile)
> > > failed with exit code '1'
> > >
> > > Is it possible that I am using the wrong linux-imx version? I have
> > > tried a few but to no avail.
> > >
> >
> > perhaps there is more specific compiler error in logs above that ?
> >
> > > Thanks in advance.
> > >
> > > Best regards,
> > > Dule
> > >
> > >
> > >
> > >
> > >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56155): https://lists.yoctoproject.org/g/yocto/message/56155
Mute This Topic: https://lists.yoctoproject.org/mt/89050046/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] gpsd [version 3.23; master branch]: Is it possible to include / enable ubxtool?

[Zoran]

To add every package (into poky) by every personal wish of any Yocto
user, or not to add any package without exclusion, that is the
question?

Why not to do addition of the proprietary layer for missing package or
group of missing by the same/similar context packages???

Zee
___

On Wed, Sep 1, 2021 at 12:33 PM Matthias Klein
 wrote:
>
> Hello,
>
> is it somehow possible to add the ubxtool in the gpsd-utils package?
>
> (I use the current master branch)
>
> Best regards,
> Matthias
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54626): https://lists.yoctoproject.org/g/yocto/message/54626
Mute This Topic: https://lists.yoctoproject.org/mt/85298361/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] kcrash package compile issue

[Zoran]

> That means that kwindowsystem did not install all necessary bits.

Oh, I see... It has everything to do with Xwindows systems in X11
Client/Server domain.

kwindoes => KDE desktop.

Apology for the confusion!

Zee
___



On Mon, Aug 30, 2021 at 2:19 PM Andreas Müller  wrote:
>
> On Mon, Aug 30, 2021 at 6:46 AM Zoran  wrote:
> >
> > > CMake Error in src/CMakeLists.txt:
> > >
> > > Imported target "KF5::WindowSystem" includes non-existent path
> >
> > You somehow mixed Windows and Linux Cmake build systems. Not sure how...
> >
> > Solution 1: fix on the fly current problem:
> > You should inspect the file: src/CMakeLists.txt and try to fix Windows
> > paths to match Linux paths.
> >
> > Solution 2: delete the current Cmake setup and execute it from scratch:
> > Error should not happen, since you need to delete the Cmake setup and
> > do the whole thing from scratch.
> > 1) configure <<= This step causes you problems!
> > 2) make
> > 3) make install
> >
> > Zee
> > ___
> >
> >
> > On Mon, Aug 30, 2021 at 6:10 AM sateesh m  wrote:
> > >
> > > Hi Team,
> > >
> > >  I am trying to build kcrash package. I got below error.Can 
> > > anybody know how to fix this please guide me.
> > >
> > > ERROR: kcrash-5.85.0-r0 do_configure: Execution of 
> > > '/home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/temp/run.do_configure.12650'
> > >  failed with exit code 1:
> > >
> > > -- The C compiler identification is GNU 10.2.0
> > >
> > > -- The CXX compiler identification is GNU 10.2.0
> > >
> > > -- Detecting C compiler ABI info
> > >
> > > -- Detecting C compiler ABI info - done
> > >
> > > -- Check for working C compiler: 
> > > /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot-native/usr/bin/riscv64-oe-linux/riscv64-oe-linux-gcc
> > >  - skipped
> > >
> > > -- Detecting C compile features
> > >
> > > -- Detecting C compile features - done
> > >
> > > -- Detecting CXX compiler ABI info
> > >
> > > -- Detecting CXX compiler ABI info - done
> > >
> > > -- Check for working CXX compiler: 
> > > /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot-native/usr/bin/riscv64-oe-linux/riscv64-oe-linux-g++
> > >  - skipped
> > >
> > > -- Detecting CXX compile features
> > >
> > > -- Detecting CXX compile features - done
> > >
> > > --
> > >
> > >
> > >
> > > Installing in /usr. Run 
> > > /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/build/prefix.sh
> > >  to set the environment for KCrash.
> > >
> > > -- Looking for __GLIBC__
> > >
> > > -- Looking for __GLIBC__ - found
> > >
> > > -- Performing Test _OFFT_IS_64BIT
> > >
> > > -- Performing Test _OFFT_IS_64BIT - Success
> > >
> > > -- Performing Test HAVE_DATE_TIME
> > >
> > > -- Performing Test HAVE_DATE_TIME - Success
> > >
> > > -- Performing Test BSYMBOLICFUNCTIONS_AVAILABLE
> > >
> > > -- Performing Test BSYMBOLICFUNCTIONS_AVAILABLE - Success
> > >
> > > fatal: not a git repository (or any of the parent directories): .git
> > >
> > > -- Found X11: 
> > > /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot/usr/include
> > >
> > > -- Looking for XOpenDisplay in 
> > > /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot/usr/lib/libX11.so;/home/sateesh/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot/usr/lib/libXext.so
> > >
> > > -- Looking for XOpenDisplay in 
> > > /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot/usr/lib/libX11.so;/home/sateesh/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot/usr/lib/libXext.so
> > >  - found
> > >
> > > -- Looking for gethostbyname
> > >
> > > -- Looking for gethostbyname - found
> > >
> > > -- Looking for connect
> > >
> > > -- Looking for connect - found
> > >
> > > -- Looking for remove
> > >
> > > -- Looking for 

Re: [yocto] kcrash package compile issue

[Zoran]

> CMake Error in src/CMakeLists.txt:
>
> Imported target "KF5::WindowSystem" includes non-existent path

You somehow mixed Windows and Linux Cmake build systems. Not sure how...

Solution 1: fix on the fly current problem:
You should inspect the file: src/CMakeLists.txt and try to fix Windows
paths to match Linux paths.

Solution 2: delete the current Cmake setup and execute it from scratch:
Error should not happen, since you need to delete the Cmake setup and
do the whole thing from scratch.
1) configure <<= This step causes you problems!
2) make
3) make install

Zee
___


On Mon, Aug 30, 2021 at 6:10 AM sateesh m  wrote:
>
> Hi Team,
>
>  I am trying to build kcrash package. I got below error.Can 
> anybody know how to fix this please guide me.
>
> ERROR: kcrash-5.85.0-r0 do_configure: Execution of 
> '/home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/temp/run.do_configure.12650'
>  failed with exit code 1:
>
> -- The C compiler identification is GNU 10.2.0
>
> -- The CXX compiler identification is GNU 10.2.0
>
> -- Detecting C compiler ABI info
>
> -- Detecting C compiler ABI info - done
>
> -- Check for working C compiler: 
> /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot-native/usr/bin/riscv64-oe-linux/riscv64-oe-linux-gcc
>  - skipped
>
> -- Detecting C compile features
>
> -- Detecting C compile features - done
>
> -- Detecting CXX compiler ABI info
>
> -- Detecting CXX compiler ABI info - done
>
> -- Check for working CXX compiler: 
> /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot-native/usr/bin/riscv64-oe-linux/riscv64-oe-linux-g++
>  - skipped
>
> -- Detecting CXX compile features
>
> -- Detecting CXX compile features - done
>
> --
>
>
>
> Installing in /usr. Run 
> /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/build/prefix.sh
>  to set the environment for KCrash.
>
> -- Looking for __GLIBC__
>
> -- Looking for __GLIBC__ - found
>
> -- Performing Test _OFFT_IS_64BIT
>
> -- Performing Test _OFFT_IS_64BIT - Success
>
> -- Performing Test HAVE_DATE_TIME
>
> -- Performing Test HAVE_DATE_TIME - Success
>
> -- Performing Test BSYMBOLICFUNCTIONS_AVAILABLE
>
> -- Performing Test BSYMBOLICFUNCTIONS_AVAILABLE - Success
>
> fatal: not a git repository (or any of the parent directories): .git
>
> -- Found X11: 
> /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot/usr/include
>
> -- Looking for XOpenDisplay in 
> /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot/usr/lib/libX11.so;/home/sateesh/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot/usr/lib/libXext.so
>
> -- Looking for XOpenDisplay in 
> /home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot/usr/lib/libX11.so;/home/sateesh/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kcrash/5.85.0-r0/recipe-sysroot/usr/lib/libXext.so
>  - found
>
> -- Looking for gethostbyname
>
> -- Looking for gethostbyname - found
>
> -- Looking for connect
>
> -- Looking for connect - found
>
> -- Looking for remove
>
> -- Looking for remove - found
>
> -- Looking for shmat
>
> -- Looking for shmat - found
>
> -- Looking for IceConnectionNumber in ICE
>
> -- Looking for IceConnectionNumber in ICE - found
>
> -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
>
> -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
>
> -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
>
> -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
>
> -- Performing Test COMPILER_HAS_DEPRECATED_ATTR
>
> -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
>
> -- The following features have been enabled:
>
>
>
> * Core Pattern Raising, Raising signals to kernel core patterns (iff the 
> pattern is a process). You may wish to not install drkonqi if this can cause 
> a UI conflict.
>
>
>
> -- The following OPTIONAL packages have been found:
>
>
>
> * X11
>
>
>
> -- The following REQUIRED packages have been found:
>
>
>
> * ECM (required version >= 5.85.0), Extra CMake Modules., 
> 
>
> * Qt5 (required version >= 5.15.0)
>
> * Qt5Core (required version >= 5.15.0)
>
> * KF5CoreAddons (required version >= 5.85.0)
>
> * Qt5Gui (required version >= 5.15.0)
>
> * KF5WindowSystem (required version >= 5.85.0)
>
> * Qt5X11Extras (required version >= 5.15.0)
>
>
>
> -- The following features have been disabled:
>
>
>
> * QCH, API documentation in QCH format (for e.g. Qt Assistant, Qt Creator & 
> KDevelop)
>
>
>
> -- Configuring done
>
> CMake Error in src/CMakeLists.txt:
>
> Imported target "KF5::WindowSystem" includes non-existent path
>
>
>
> "/home/yocto/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/kwindowsystem/5.85.0-r0/recipe-sysroot/usr/include"
>
>
>

Re: [yocto] Getting bitbake error after 54% recipes are baked. #dunfell #yocto

[Zoran]

> keep in mind that based upon how many vcores you allocate to VM will
> determine memory pressure
> as well. So if you have 2 cores perhaps 4GB is ok or maybe even 4
> cores might workout ok but some bigger packages like
> chromium etc. need minimal 16GB RAM to build.

This should be reflected somewhere in YOCTO documentation. Especially
for chromium.

In the section: Host HW Requirements (with some explanation why).

Zee
___


On Tue, Aug 17, 2021 at 10:14 PM Khem Raj  wrote:
>
> On Tue, Aug 17, 2021 at 10:36 AM  wrote:
> >
> > Previously SDRAM was 3 GB allocated.
> >
> > After changing SDRAM to 4 GB.
> > then trying to build/make/bitbake..
>
> keep in mind that based upon how many vcores you allocate to VM will
> determine memory pressure
> as well. So if you have 2 cores perhaps 4GB is ok or maybe even 4
> cores might workout ok but some bigger packages like
> chromium etc. need minimal 16GB RAM to build.
>
> >
> > getting new error i.e.
> > Unable to connect to bitbake server
>
> this seems that it finds bitbake is still running and its trying to
> reconnect to it. Maybe just reboot the box and try again
>
> >
> >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54463): https://lists.yoctoproject.org/g/yocto/message/54463
Mute This Topic: https://lists.yoctoproject.org/mt/84950547/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Getting bitbake error after 54% recipes are baked. #dunfell #yocto

[Zoran]

> /home/vrana/Desktop/yocto_Practice/build/tmp/ \
> work/core2-64-poky-linux/gcc/9.3.0-r0/recipe-sysroot-native/ \
> usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/ \
> gcc/x86_64-poky-linux/9.3.0/as:
> *out of memory allocating 4064 bytes after a total of 452272128 bytes*

Looks to me that your VM ran out of SDRAM memory,
allocated for the VM, somehow.

> Memory allocated to VM machine is 100+ GB.

It is (hopefully) a VDI (Dynamic) VM disk image, NOT a SDRAM,
my best guess.

[1] You can just try to continue bitbake process, it might pass, since the
 Bitbake processes were forcefully killed, and some memory hogged
 fortunately were entirely deallocated;
[2] If [1] fails again a few times, you can try to reconfigure VMM to give
 more SDRAM to VM (have no idea what is the allocated default), it
 might help!

Zee
___

On Tue, Aug 17, 2021 at 5:38 PM  wrote:

> Hi,
>
> I am using* ubuntu 16.04* (host) in VirtualBox.
>
> Memory allocated to VM machine is 100+ GB.
>
> Poky* dunfell*.
>
> While trying to build the project fo*r x86_64.*
>
> Steps followed as per yocto quick guide for "dunfell"
>
> 
>
> after baking 54% of recipe I am getting error.
>
>
> 
>
> |
> /home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/as:
> out of memory allocating 4064 bytes after a total of 452272128 bytes
>
> | Makefile:1117: recipe for target 'insn-emit.o' failed
>
> | make[1]: *** [insn-emit.o] Error 2
>
> | make[1]: *** Waiting for unfinished jobs
>
> | rm gcc.pod
>
> | make[1]: Leaving directory
> '/home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/gcc-9.3.0/build.x86_64-poky-linux.x86_64-poky-linux/gcc'
>
> | Makefile:4328: recipe for target 'all-gcc' failed
>
> | make: *** [all-gcc] Error 2
>
> | WARNING: exit code 1 from a shell command.
>
> |
>
> ERROR: Task
> (/home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:do_compile)
> failed with exit code '1'
>
> NOTE: Tasks Summary: Attempted 1832 tasks of which 0 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
>
> /home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:
> do_compile
>
> Summary: There were 2 ERROR messages shown, returning a non-zero exit
> code.
>
>
>
> 
>
> looking for guidance.
>
>
>
> Regards,
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54454): https://lists.yoctoproject.org/g/yocto/message/54454
Mute This Topic: https://lists.yoctoproject.org/mt/84950547/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Hardknott systemd-journald issue

[Zoran]

Hello Jupiter,

This might provide you a great help:
https://askubuntu.com/questions/864722/where-is-journalctl-data-stored

Namely:





*Usually the storage directory is /var/log/journal or /run/log/journal, but
it doesn't have to necessarily exist in your system.If you just want to
check the amount of space that the journal is currently occupying on your
disk, simply type:$ journalctl --disk-usage*

You also can combine the df command (look into man df).

Zee
___


On Tue, Aug 17, 2021 at 4:18 AM JH  wrote:

> Hi,
>
> I've just upgraded from Zeus to Hardknott with the kernel 5.10.59, the
> /run/log/journal was running out of space and crashed, is it a kernel
> issue or Hardknott build issue?
>
> I never seen that issue in Zeus, I thought that systemd-journald
> should be capable of detecting the space, if it is no log space, stop
> writing rather crashing the tmpfs
>
> [13749.397288] systemd-journald[97]: Failed to open runtime journal:
> No space left on device
> [13749.439047] systemd-journald[97]: File
> /run/log/journal/4ba2cd613d004916863e30730800bb69/system.journal
> corrupted or uncleanly shut down, renaming and replacing.
>
> Thank you.
>
> Kind regards,
>
> - jh
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54427): https://lists.yoctoproject.org/g/yocto/message/54427
Mute This Topic: https://lists.yoctoproject.org/mt/84939691/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] run.do_image_zipabox2_sdimg.27223: parted: not found

[Zoran]

having a really funky issue


This is the truth... Truly funky issue, no doubts! 

Zee
___

On Thu, Jul 1, 2021 at 5:57 PM Yocto  wrote:

> having a really funky issue everything builds fine under pyro updated it
> all to dunfell, and now im hitting this failure below, i also pasted the
> log and the offending recipe on pastebin logfile:
> https://pastebin.com/38TzNa5h bb recipe: https://pastebin.com/jhfTBv58
> Logfile of failure stored in:
> /home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/log.do_image_zipabox2_sdimg.27223
> Log data follows: | DEBUG: Executing python function set_image_size |
> DEBUG: 1032444.40 = 794188 * 1.30 | DEBUG: 1032444.40 =
> max(1032444.40, 8192)[1032444.40] + 0 | DEBUG: 1032445.00 =
> int(1032444.40) | DEBUG: 1032445 = aligned(1032445) | DEBUG: returning
> 1032445 | DEBUG: Python function set_image_size finished | DEBUG: Executing
> shell function do_image_zipabox2_sdimg | 0+0 records in | 0+0 records out |
> 0 bytes copied, 8.9773e-05 s, 0.0 kB/s |
> /home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/run.do_image_zipabox2_sdimg.27223:
> 124:
> /home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/run.do_image_zipabox2_sdimg.27223:
> parted: not found | WARNING: exit code 127 from a shell command. | ERROR:
> Execution of
> '/home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/run.do_image_zipabox2_sdimg.27223'
> failed with exit code 127: | 0+0 records in | 0+0 records out | 0 bytes
> copied, 8.9773e-05 s, 0.0 kB/s |
> /home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/run.do_image_zipabox2_sdimg.27223:
> 124:
> /home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/run.do_image_zipabox2_sdimg.27223:
> parted: not found | WARNING: exit code 127 from a shell command. | ERROR:
> Task
> (/home/dingo/TEST3/Zipato/zipato-yocto-public/meta-zipato-public/images/zipabox2-image/zipabox2-image-blank_1.0.bb:do_image_zipabox2_sdimg)
> failed with exit code '1' NOTE: Tasks Summary: Attempted 4542 tasks of
> which 4540 didn't need to be rerun and 2 failed. Summary: 2 tasks failed:
> /home/dingo/TEST3/Zipato/zipato-yocto-public/meta-zipato-public/images/zipabox2-image/zipabox2-image-blank_1.0.bb:do_image_zipabox2_mender
> /home/dingo/TEST3/Zipato/zipato-yocto-public/meta-zipato-public/images/zipabox2-image/zipabox2-image-blank_1.0.bb:do_image_zipabox2_sdimg
> --
> Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54035): https://lists.yoctoproject.org/g/yocto/message/54035
Mute This Topic: https://lists.yoctoproject.org/mt/83920160/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Problem with YOCTO Dunfell and host Fedora 33

[Zoran]

Hello to everyone,

Mguentner fixed the cmake issue:
https://github.com/mguentner/cannelloni/issues/35

With this patch:
https://github.com/mguentner/cannelloni/commit/125a7c72e4bcbbf580aeb6ee03e25ed0540be217

So I also reinstated the old cannelloni recipe with:
https://github.com/ZoranStojsavljevic/meta-socketcan/commit/b79e35425b72ba1caf90404a953235a43202e16f

Zee
___

On Fri, May 21, 2021 at 7:55 AM Zoran via lists.yoctoproject.org
 wrote:
>
> Hello Joel,
>
> Thank you for the tips. Really helpful, appreciated very much.
>
> I spent some time this morning investigating this issue, and to find
> the culprit.
>
> Here are my findings, which resulted in a cannelloni.bb recipe change
> (according to what you wrote).
>
> The fix submitted is in recipe:
> https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/cannelloni/cannelloni.bb
>
> The last cannelloni version which works is:
> https://github.com/mguentner/cannelloni/commit/0bd7e27db35bdef361226882ae04205504f7b2f4
>
> The culprit introducing the cmake errors is this one:
> https://github.com/mguentner/cannelloni/commit/d01dd1dc745914d129b1f4da2074e282253246af
>
> And, the issue recorded with Maximilian Guentner's cannelloni repo:
> https://github.com/mguentner/cannelloni/issues/35
>
> Thank you again,
> Zoran
> ___
>
> On Thu, May 20, 2021 at 4:48 PM Joel Winarske  wrote:
> >
> > Hi Zoran,
> >
> > Your cannelloni recipe is set to autorev, meaning it's not locked to a 
> > commit.  So when something changes upstream you have to manage it.
> >
> > Chances are Canelloni introduced a CMake change which is overwriting 
> > (opposed to appending) one or more variables required for cross compiling.  
> > Perhaps try to cross compile (not a host build) Canelloni by itself without 
> > Yocto involved.  Once that's sorted, then reintroduce yocto.
> >
> >
> > Joel
> >
> >
> > On Thu, May 20, 2021, 6:58 AM Zoran  wrote:
> >>
> >> Hello Yocto developers,
> >>
> >> I have few problems running the following self proprietary script from
> >> one of my public git repos:
> >> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh
> >>
> >> I recall that last time I used the script (I used then Fedora 31), the
> >> ./yocto setup dunfell worked seamlessly, did setup the environment,
> >> and upon bitbake -k core-image-minimal completed the tasks without any
> >> problem.
> >>
> >> Now, I am using Fedora 33 (in the meantime I did two Fedora version 
> >> upgrades).
> >>
> >> The problem is that while compiling the cannelloni package, the
> >> following errors were issued (please, look into the attached file
> >> cmake_problem.txt).
> >>
> >> This cmake problem was introduced after switching from Fedora 31 to Fedora 
> >> 33 ?!
> >>
> >> Any clue/idea why this is happening??? What is the cause of the problem?
> >>
> >> Thank you,
> >> Zoran
> >> ___
> >>
> >>
> >>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54011): https://lists.yoctoproject.org/g/yocto/message/54011
Mute This Topic: https://lists.yoctoproject.org/mt/82961982/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] Hardknott (GCC10) Compiler Issues

[Zoran]

> The target system should be independent of buildtools version and the target
> system should also be binary reproducible so if that were changing through
> changing buildtools tarball, that would be worrying in itself.

Even better, the rootfs built by YOCTO could be used, but anyone can
build U-Boot and kernel outside of the YOCTO, using their own cross
compilers (I use Fedora 33 ARM cross compilers, since my Linux host is
Fedora 33).

Then to install all the different components on the SDcard for the
target system.

And see if the issue repeats itself...

Zee
___

On Mon, Jun 28, 2021 at 2:49 PM Richard Purdie
 wrote:
>
> On Thu, 2021-06-24 at 21:48 -0700, Chuck Wolber wrote:
> > All,
> >
> > Please accept my apologies in advance for the detailed submission. I think
> > it is warranted in this case.
> >
> > There is something... "odd" about the GCC 10 compiler that is delivered with
> > Hardknott. I am still chasing it down, so I am not yet ready to declare a
> > root cause or submit a bug, but I am posting what I have now in case anyone
> > has some insights to offer.
>
> The issue you describe does sound strange. I was a little unclear about 
> exactly
> which combinations were passing/failing. Are you saying that some versions of
> buildtools let the system work but some do not? We now have gcc 11 in master
> so it would be interesting to know how things worked there and if any
> regression was fixed.
>
> I have also heard reports of issues with bison segfaulting from other sources
> but I don't have anything I can point to specifically about it.
>
> The target system should be independent of buildtools version and the target
> system should also be binary reproducible so if that were changing through
> changing buildtools tarball, that would be worrying in itself.
>
> > P.P.S. For the sake of completeness, I had to add the following files to 
> > the buildtools-extended
> > sysroot to fully complete the build of our images:
> >
> > /usr/include/magic.h -> util-linux "more" command requires this.
> > /usr/include/zstd.h -> I do not recall which recipe required this.
> > /usr/bin/free -> The OpenJDK 8 build scripts need this.
> > /usr/include/sys/* -> openjdk-8-native
> > /lib/libcap.so.2 -> The binutils "dir" command quietly breaks the build 
> > without this. I am not a fan of the
> > lack of error checking in the binutils build...
> > /usr/include/sensors/error.h and sensors.h -> mesa-native
> > /usr/include/zstd_errors.h -> qemu-system-native
>
> It is great to have this list, outside the non-jdk issues are probably issues 
> we
> should look at fixing in OE-Core. Do you mean binutils above for the dir 
> command?
>
> Cheers,
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53991): https://lists.yoctoproject.org/g/yocto/message/53991
Mute This Topic: https://lists.yoctoproject.org/mt/83843656/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] Hardknott (GCC10) Compiler Issues

[Zoran]

At least seems that GCC 10.2 is not the cause of the problem for my
cannelloni recipe issue:

https://github.com/mguentner/cannelloni/issues/35

The same error repeats itself with GCC 11.2 (in hardknott).

The issue is most probably optimizing GCC switches and Include paths
in further cannelloni commits (after release 1.0.0, which compiles
with both 10.2 and 11.1 fine).

Best Regards,
Zee
___

On Mon, Jun 28, 2021 at 2:49 PM Richard Purdie
 wrote:
>
> On Thu, 2021-06-24 at 21:48 -0700, Chuck Wolber wrote:
> > All,
> >
> > Please accept my apologies in advance for the detailed submission. I think
> > it is warranted in this case.
> >
> > There is something... "odd" about the GCC 10 compiler that is delivered with
> > Hardknott. I am still chasing it down, so I am not yet ready to declare a
> > root cause or submit a bug, but I am posting what I have now in case anyone
> > has some insights to offer.
>
> The issue you describe does sound strange. I was a little unclear about 
> exactly
> which combinations were passing/failing. Are you saying that some versions of
> buildtools let the system work but some do not? We now have gcc 11 in master
> so it would be interesting to know how things worked there and if any
> regression was fixed.
>
> I have also heard reports of issues with bison segfaulting from other sources
> but I don't have anything I can point to specifically about it.
>
> The target system should be independent of buildtools version and the target
> system should also be binary reproducible so if that were changing through
> changing buildtools tarball, that would be worrying in itself.
>
> > P.P.S. For the sake of completeness, I had to add the following files to 
> > the buildtools-extended
> > sysroot to fully complete the build of our images:
> >
> > /usr/include/magic.h -> util-linux "more" command requires this.
> > /usr/include/zstd.h -> I do not recall which recipe required this.
> > /usr/bin/free -> The OpenJDK 8 build scripts need this.
> > /usr/include/sys/* -> openjdk-8-native
> > /lib/libcap.so.2 -> The binutils "dir" command quietly breaks the build 
> > without this. I am not a fan of the
> > lack of error checking in the binutils build...
> > /usr/include/sensors/error.h and sensors.h -> mesa-native
> > /usr/include/zstd_errors.h -> qemu-system-native
>
> It is great to have this list, outside the non-jdk issues are probably issues 
> we
> should look at fixing in OE-Core. Do you mean binutils above for the dir 
> command?
>
> Cheers,
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53990): https://lists.yoctoproject.org/g/yocto/message/53990
Mute This Topic: https://lists.yoctoproject.org/mt/83843656/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Hardknott (GCC10) Compiler Issues

[Zoran]

> GCCVERSION = "9.%"

Basically, do NOT use this instruction anywhere. It clearly does NOT work?!

I did replace the whole gcc/ in the: poky/meta/recipes-devtools/gcc
for hardknott branch:

Now I have a gcc_11.1 compiler (from master branch), instead of gcc_10.2.

poky/meta/recipes-devtools/gcc
[vuser@fedora33-ssd projects_yocto]$ cd
bbb-yocto-hardknott/poky/meta/recipes-devtools/gcc
[vuser@fedora33-ssd gcc]$ ls -al
total 180
drwxr-xr-x.  3 vuser vboxusers  4096 Jun 25 13:50 .
drwxr-xr-x. 94 vuser vboxusers  4096 Jun 25 14:45 ..
drwxr-xr-x.  2 vuser vboxusers  4096 Jun 25 13:50 gcc
-rw-r--r--.  1 vuser vboxusers   800 Jun 25 13:50 gcc_11.1.bb
-rw-r--r--.  1 vuser vboxusers  5330 Jun 25 13:50 gcc-11.1.inc
-rw-r--r--.  1 vuser vboxusers  4560 Jun 25 13:50 gcc-common.inc
-rw-r--r--.  1 vuser vboxusers  4426 Jun 25 13:50 gcc-configure-common.inc
-rw-r--r--.  1 vuser vboxusers66 Jun 25 13:50 gcc-cross_11.1.bb
-rw-r--r--.  1 vuser vboxusers77 Jun 25 13:50 gcc-cross-canadian_11.1.bb
-rw-r--r--.  1 vuser vboxusers  6971 Jun 25 13:50 gcc-cross-canadian.inc
-rw-r--r--.  1 vuser vboxusers  6383 Jun 25 13:50 gcc-cross.inc
-rw-r--r--.  1 vuser vboxusers73 Jun 25 13:50 gcc-crosssdk_11.1.bb
-rw-r--r--.  1 vuser vboxusers   429 Jun 25 13:50 gcc-crosssdk.inc
-rw-r--r--.  1 vuser vboxusers  9593 Jun 25 13:50 gcc-multilib-config.inc
-rw-r--r--.  1 vuser vboxusers67 Jun 25 13:50 gcc-runtime_11.1.bb
-rw-r--r--.  1 vuser vboxusers 12398 Jun 25 13:50 gcc-runtime.inc
-rw-r--r--.  1 vuser vboxusers   271 Jun 25 13:50 gcc-sanitizers_11.1.bb
-rw-r--r--.  1 vuser vboxusers  4407 Jun 25 13:50 gcc-sanitizers.inc
-rw-r--r--.  1 vuser vboxusers   208 Jun 25 13:50 gcc-shared-source.inc
-rw-r--r--.  1 vuser vboxusers   113 Jun 25 13:50 gcc-source_11.1.bb
-rw-r--r--.  1 vuser vboxusers  1468 Jun 25 13:50 gcc-source.inc
-rw-r--r--.  1 vuser vboxusers  8598 Jun 25 13:50 gcc-target.inc
-rw-r--r--.  1 vuser vboxusers  4924 Jun 25 13:50 gcc-testsuite.inc
-rw-r--r--.  1 vuser vboxusers   143 Jun 25 13:50 libgcc_11.1.bb
-rw-r--r--.  1 vuser vboxusers  5175 Jun 25 13:50 libgcc-common.inc
-rw-r--r--.  1 vuser vboxusers  1785 Jun 25 13:50 libgcc.inc
-rw-r--r--.  1 vuser vboxusers   151 Jun 25 13:50 libgcc-initial_11.1.bb
-rw-r--r--.  1 vuser vboxusers  2020 Jun 25 13:50 libgcc-initial.inc
-rw-r--r--.  1 vuser vboxusers68 Jun 25 13:50 libgfortran_11.1.bb
-rw-r--r--.  1 vuser vboxusers  2574 Jun 25 13:50 libgfortran.inc
[vuser@fedora33-ssd gcc]$

Waiting for the compilation results (still compiles).

Zee
___


On Fri, Jun 25, 2021 at 10:15 AM Zoran via lists.yoctoproject.org
 wrote:
>
> > I have no idea if this is possible in the current YOCTO development stage:
> > GCCVERSION = "11.%"
> > To do the FF to GCC 11.>
>
> WARNING: preferred version 11.% of gcc-runtime not available (for item libg2c)
> WARNING: versions of gcc-runtime available: 10.2.0
>
> For hardknott. Guess, this answers my later question.
>
> Let us see about my very first question!
>
> BR,
> Zee
> ___
>
> INCLUDED:
> WARNING: preferred version 11.% of gcc-runtime not available (for item 
> libssp-dev)
> WARNING: versions of gcc-runtime available: 10.2.0
> WARNING: preferred version 11.% of gcc-runtime not available (for item 
> libg2c-dev)
> WARNING: versions of gcc-runtime available: 10.2.0
> WARNING: preferred version 11.% of gcc-runtime not available (for item libssp)
> WARNING: versions of gcc-runtime available: 10.2.0
>
> Build Configuration:
> BB_VERSION   = "1.50.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "fedora-33"
> TARGET_SYS   = "arm-poky-linux-gnueabi"
> MACHINE  = "beaglebone"
> DISTRO   = "poky"
> DISTRO_VERSION   = "3.3.1"
> TUNE_FEATURES= "arm vfp cortexa8 neon callconvention-hard"
> TARGET_FPU   = "hard"
> meta
> meta-poky
> meta-yocto-bsp   = "hardknott:74dbb08c3709fec6563ee65a3661f66fdcbb3e2f"
> meta-jumpnow = "hardknott:ac90f018ebb9de8d6ac12f22368e004aa7be69a2"
> meta-bbb = "hardknott:d838aa54e3ed81d08597c08e112fc8966aaa501d"
> meta-oe
> meta-python
> meta-networking  = "hardknott:aca88908fd329f5cef6f19995b072397fb2d8ec6"
> meta-qt5 = 
> "upstream/hardknott:a00af3eae082b772469d9dd21b2371dd4d237684"
> meta-socketcan   = "master:cefd86cd1def9ad2e63be527f8ce36a076d7e17c"
>
> NOTE: Fetching uninative binary shim 
> http://downloads.yoctoproject.org/releases/uninative/3.2/x86_64-nativesdk-libc.tar.xz;sha256sum=3ee8c7d55e2d4c7ae3887cddb97219f97b94efddfeee2e24923c0cb0e8ce84c6
>  (will check PREMIRRORS first)
> Initialising tasks: 100% 
> |

Re: [yocto] Hardknott (GCC10) Compiler Issues

[Zoran]

> I have no idea if this is possible in the current YOCTO development stage:
> GCCVERSION = "11.%"
> To do the FF to GCC 11.>


*WARNING: preferred version 11.% of gcc-runtime not available (for item
libg2c)WARNING: versions of gcc-runtime available: 10.2.0*

For hardknott. Guess, this answers my later question.

Let us see about my very first question!

BR,
Zee
___

INCLUDED:
WARNING: preferred version 11.% of gcc-runtime not available (for item
libssp-dev)
WARNING: versions of gcc-runtime available: 10.2.0
WARNING: preferred version 11.% of gcc-runtime not available (for item
libg2c-dev)
WARNING: versions of gcc-runtime available: 10.2.0
WARNING: preferred version 11.% of gcc-runtime not available (for item
libssp)
WARNING: versions of gcc-runtime available: 10.2.0

Build Configuration:
BB_VERSION   = "1.50.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "fedora-33"
TARGET_SYS   = "arm-poky-linux-gnueabi"
MACHINE  = "beaglebone"
DISTRO   = "poky"
DISTRO_VERSION   = "3.3.1"
TUNE_FEATURES= "arm vfp cortexa8 neon callconvention-hard"
TARGET_FPU   = "hard"
meta
meta-poky
meta-yocto-bsp   = "*hardknott:*
74dbb08c3709fec6563ee65a3661f66fdcbb3e2f"
meta-jumpnow = "*hardknott*
:ac90f018ebb9de8d6ac12f22368e004aa7be69a2"
meta-bbb = "hardknott:d838aa54e3ed81d08597c08e112fc8966aaa501d"
meta-oe
meta-python
meta-networking  = "hardknott:aca88908fd329f5cef6f19995b072397fb2d8ec6"
meta-qt5 =
"upstream/hardknott:a00af3eae082b772469d9dd21b2371dd4d237684"
meta-socketcan   = "master:cefd86cd1def9ad2e63be527f8ce36a076d7e17c"

NOTE: Fetching uninative binary shim
http://downloads.yoctoproject.org/releases/uninative/3.2/x86_64-nativesdk-libc.tar.xz;sha256sum=3ee8c7d55e2d4c7ae3887cddb97219f97b94efddfeee2e24923c0cb0e8ce84c6
(will check PREMIRRORS first)
Initialising tasks: 100%
|#######|
Time: 0:00:11
Sstate summary: Wanted 1709 Local 0 Network 0 Missed 1709 Current 0 (0%
match, 0% complete)
NOTE: Executing Tasks


On Fri, Jun 25, 2021 at 7:58 AM Zoran via lists.yoctoproject.org
 wrote:

> An interesting issue, and I think I hit it as well (my best guess).
>
> Here is my issue:
> https://github.com/mguentner/cannelloni/issues/35
>
> > During the thud-to-hardknott upgrade process, we did nightly
> > builds of the new hardknott based target image from our thud
> > based SDK VM. I assumed that since GCC10 was being built
> > as part of the build sysroot bootstrap process, we were getting
> > a clean and consistent result irrespective of the underlying
> > build server OS.
>
> Maybe you can try the following: in your local.conf to insert the
> following line:
>
> GCCVERSION = "9.%"
>
> for hardknott release.
>
> I need to try this myself, I just used gcc as is (default one which
> comes with the release, I guess 10).
>
> I have no idea if this is possible in the current YOCTO development stage:
>
> GCCVERSION = "11.%"
>
> To do the FF to GCC 11.
>
> Zee
> ___
>
> On Fri, Jun 25, 2021 at 6:48 AM Chuck Wolber 
> wrote:
> >
> > All,
> >
> > Please accept my apologies in advance for the detailed submission. I
> think it is warranted in this
> > case.
> >
> > There is something... "odd" about the GCC 10 compiler that is delivered
> with Hardknott. I am still
> > chasing it down, so I am not yet ready to declare a root cause or submit
> a bug, but I am posting
> > what I have now in case anyone has some insights to offer.
> >
> > For all I know it is something unusual that I am doing, but we have a
> lot of history with our
> > build/dev/release methods, so I would be surprised if that was actually
> the case. I have also
> > discussed aspects of this on IRC for the last few days, so some of this
> may be familiar to some
> > of you.
> >
> > Background: We maintain a virtual machine SDK for our developers that is
> as close as possible to
> > the actual embedded hardware environment that we target. The SDK image
> is our baseline Linux
> > OS plus lots of the expected dev and debugging tools. The image deployed
> to our target devices is
> > the baseline Linux OS plus the core application suite. It is also
> important to note that we only
> > support the x86_64 machine architecture in our target devices and
> development workstations.
> >
> > We also spin up and spin down the SDK VM for our nightly builds. This
> guarantees strict consistency
&g

Re: [yocto] Hardknott (GCC10) Compiler Issues

[Zoran]

An interesting issue, and I think I hit it as well (my best guess).

Here is my issue:
https://github.com/mguentner/cannelloni/issues/35

> During the thud-to-hardknott upgrade process, we did nightly
> builds of the new hardknott based target image from our thud
> based SDK VM. I assumed that since GCC10 was being built
> as part of the build sysroot bootstrap process, we were getting
> a clean and consistent result irrespective of the underlying
> build server OS.

Maybe you can try the following: in your local.conf to insert the
following line:

GCCVERSION = "9.%"

for hardknott release.

I need to try this myself, I just used gcc as is (default one which
comes with the release, I guess 10).

I have no idea if this is possible in the current YOCTO development stage:

GCCVERSION = "11.%"

To do the FF to GCC 11.

Zee
___

On Fri, Jun 25, 2021 at 6:48 AM Chuck Wolber  wrote:
>
> All,
>
> Please accept my apologies in advance for the detailed submission. I think it 
> is warranted in this
> case.
>
> There is something... "odd" about the GCC 10 compiler that is delivered with 
> Hardknott. I am still
> chasing it down, so I am not yet ready to declare a root cause or submit a 
> bug, but I am posting
> what I have now in case anyone has some insights to offer.
>
> For all I know it is something unusual that I am doing, but we have a lot of 
> history with our
> build/dev/release methods, so I would be surprised if that was actually the 
> case. I have also
> discussed aspects of this on IRC for the last few days, so some of this may 
> be familiar to some
> of you.
>
> Background: We maintain a virtual machine SDK for our developers that is as 
> close as possible to
> the actual embedded hardware environment that we target. The SDK image is our 
> baseline Linux
> OS plus lots of the expected dev and debugging tools. The image deployed to 
> our target devices is
> the baseline Linux OS plus the core application suite. It is also important 
> to note that we only
> support the x86_64 machine architecture in our target devices and development 
> workstations.
>
> We also spin up and spin down the SDK VM for our nightly builds. This 
> guarantees strict consistency
> and eliminates lots of variables when we are trying to troubleshoot something 
> hairy.
>
> We just upgraded from Thud to Hardknott. This means we built our new 
> Hardknott based SDK VM
> image from our Thud based SDK VM (GCC 8 / glibc 2.28). When we attempted to 
> build our target
> device image in the new Hardknott based SDK VM, we consistently got a 
> segfault when any build
> task involves bison issuing a warning of some sort. I traced this down for a 
> very long time and it
> seemed to have something to do with the libtextstyle library from gettext and 
> the way bison used it.
> But I now believe that this to be a red herring. Bison seems to be very 
> fragile, but in this case,
> that may have actually been a good thing.
>
> After some experimentation I found that the issue went away when I dropped 
> down to the 3.6.4
> recipe of bison found at OE-Core:bc95820cd. But this did not sit right with 
> me. There is no way I
> should be the only person seeing this issue.
>
> Then I tried an experiment... I assumed I was encountering a compiler 
> bootstrap issue with such a
> big jump (GCC8 -> GCC10), so I rebuilt our hardknott based SDK VM with the 
> 3.3.1 version of
> buildtools-extended. The build worked flawlessly, but when I booted into the 
> new SDK VM and
> kicked off the build I got the same result (bison segfault when any build 
> warnings are encountered).
>
> This is when I started to mentally put a few more details together with other 
> post-upgrade issues that
> had been discovered in our lab. We attributed them to garden variety API and 
> behavioral changes
> expected during a Yocto upgrade, but now I am not so sure.
>
> During the thud-to-hardknott upgrade process, we did nightly builds of the 
> new hardknott based
> target image from our thud based SDK VM. I assumed that since GCC10 was being 
> built as part of
> the build sysroot bootstrap process, we were getting a clean and consistent 
> result irrespective of the
> underlying build server OS.
>
> One of the issues we were seeing in the lab was a periodic hang during the 
> initramfs phase of the
> boot process. We run a couple of setup scripts to manage the sysroot before 
> the switch_root, so it
> is not unusual to see some "growing pains" after an upgrade. The hangs were 
> random with no
> obvious cause, but systemd is very weird anyway so we attributed it to a new 
> dependency or race
> condition that we had to address after going from systemd 239 to 247.
>
> It is also worth noting that systemd itself was not hung, it responded to the 
> 'ole "three finger salute"
> and dutifully filled the screen with shutdown messages. It was just that the 
> boot process randomly
> stopped cold in initramfs before the switch root. We would also occasionally 
> see 

Re: [yocto] QEMU Size Increase from Yocto Thud to Zeus

[Zoran]

> Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.

Does it mean that with the local.conf line:

# enable,disable,depends,rdepends
#
PACKAGECONFIG[qemu] = "--with-qemu,--without-qemu,qemu,"

The QEMU is completely removed (this is all that needs to be done, or...)?

Thank you,
Zee
___

On Mon, Jun 14, 2021 at 12:14 PM Ross Burton  wrote:
>
> Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.
>
> Ross
>
> On Mon, 14 Jun 2021 at 09:04, Aashik Aswin  wrote:
> >
> > Thanks for the clarification, yes I am installing QEMU in my image. Is 
> > there some way that we can disable the additional architectures and 
> > streamline the size ?
> >
> > Thanks
> >
> > On Fri, Jun 11, 2021 at 8:48 PM Ross Burton  wrote:
> >>
> >> Are you installing qemu into your image though?
> >>
> >> Qemu did get larger as it is built with more architectures enabled,
> >> but unless you're installing it in your image it won't make a
> >> difference.
> >>
> >> Ross
> >>
> >> On Fri, 11 Jun 2021 at 11:40, Aashik Aswin  
> >> wrote:
> >> >
> >> > Hi Experts,
> >> >
> >> > I am upgrading my Linux from Yocto Thud to Zeus (5.4 Kernel) . After 
> >> > building I could see a significant increase in the size of the image.
> >> > On checking with buildhistory enabled, I could see that qemu has nearly 
> >> > doubled in size.
> >> >
> >> > Thud (4.19) - 223084  KiB qemu
> >> > Zeus (5.4) - 474757  KiB qemu
> >> >
> >> > Is this size increase expected or are there some additional configs that 
> >> > might have been added as a part of the upgrade ?
> >> >
> >> > Appreciate your help.
> >> >
> >> > TIA,
> >> > Aashik
> >> >
> >> >
> >> >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53858): https://lists.yoctoproject.org/g/yocto/message/53858
Mute This Topic: https://lists.yoctoproject.org/mt/83465520/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

[Zoran]

What about the following:
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

To be enhanced/added with the following:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-hardknott/README.md

Best Regards,
Zee
___

On Fri, May 28, 2021 at 3:02 PM Swapna Nannapaneni
 wrote:
>
> Typo. No leading space  INIT_MANAGER = "sysvinit".
>
> Thanks,
> Priya.
>
> On Fri, May 28, 2021 at 8:55 AM Zoran Stojsavljevic 
>  wrote:
>>
>> > you don't want the leading space.
>>
>> I got the idea from reading
>> https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection
>>
>> But this is exactly why we need some explicit examples. :-)
>>
>> Zee
>> ___
>>
>> On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day  
>> wrote:
>> >
>> > On Fri, 28 May 2021, Zoran wrote:
>> >
>> > > > Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf
>> > >
>> > > Is it INIT_MANAGER  = " sysvinit" , or INIT_MANAGER  = "sysvinit" (no
>> > > blank at the beginning)?
>> > >
>> > > Thank you,
>> > > Zee
>> >
>> >   you don't want the leading space.
>> >
>> > rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53707): https://lists.yoctoproject.org/g/yocto/message/53707
Mute This Topic: https://lists.yoctoproject.org/mt/83136294/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

[Zoran]

> you don't want the leading space.

I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

But this is exactly why we need some explicit examples. :-)

Zee
___

On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day  wrote:
>
> On Fri, 28 May 2021, Zoran wrote:
>
> > > Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf
> >
> > Is it INIT_MANAGER  = " sysvinit" , or INIT_MANAGER  = "sysvinit" (no
> > blank at the beginning)?
> >
> > Thank you,
> > Zee
>
>   you don't want the leading space.
>
> rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53693): https://lists.yoctoproject.org/g/yocto/message/53693
Mute This Topic: https://lists.yoctoproject.org/mt/83136294/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

[Zoran]

> Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf

Is it INIT_MANAGER  = " sysvinit" , or INIT_MANAGER  = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
___

On Fri, May 28, 2021 at 1:47 PM Swapna Nannapaneni
 wrote:
>
> Thanks Robert and Raj!!
>
> I am using Yocto 3.1 Dunfell release.
>
> You are right about the .bbappend file. Changed the name in the overlay to 
> new-ver.bbappend  and no longer see the warning.
>
> Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf but looks 
> like generated rootfs has init file pointing to init -> ../lib/systemd/systemd
>
> Priya.
>
> On Thu, May 27, 2021 at 7:28 PM Khem Raj  wrote:
>>
>>
>>
>> On 5/27/21 3:04 PM, sayinswa...@gmail.com wrote:
>> > Hello Yocto team:
>> >
>> > I just started with yocto and would like to know the process for
>> > switching the init manager from systemd to sysvinit.
>> >
>> > I tried this options in config file
>> > VIRTUAL-RUNTIME_init_manager = "busybox"
>> > PREFERRED_PROVIDER_udev = "sysvinit"
>> > PREFERRED_PROVIDER_udev-utils = "sysvinit"
>> > DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
>> > DEFAULT_DISTRO_FEATURES += " sysvinit"
>> >
>> > I see a warning when building my machine:
>> >
>> > No recipe for target:
>> > /recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
>>
>> Please find out which layer is adding this bbappend you could use
>>
>> bitbake-layers show-appends sysvinit
>>
>> It seems recipe version is newer perhaps and the bbappend is still made
>> for older recipe, these things happen when you mix release branches for
>> different layers.
>>
>> >
>> > When I run this build on my target it still shows me systemd init 
>> > manager...
>> >
>> > Not sure if I am missing any options.
>> > Could you please let me know if there are any pointers I can refer to?
>> >
>> > Thanks,
>> > Priya
>> >
>> >
>> >
>> >
>> >
>> >
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53691): https://lists.yoctoproject.org/g/yocto/message/53691
Mute This Topic: https://lists.yoctoproject.org/mt/83136294/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

[Zoran]

Why do I (always) point out the obvious?

And I do need... Geniuses are not meant to fix The World to understand them!?

Geniuses should understand The World (and act properly)!

Extras to geniality, do you, YOCTO primes, think?
___

Robert... If I am correct, i'm I?

Should you include in docs some examples??? Yes, U should!
As for an example fix:
poky/meta/conf/distro/include/init-manager-*.con, NOT
conf/distro/include/init-manager-*.conf

(full path is more explicit, isn't it?)

And some local.conf examples/snippets (since all descriptions are here
and there very dry):

## Add systemd service
INIT_MANAGER = "systemd"
## DISTRO_FEATURES_append = " systemd"
## DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
## VIRTUAL-RUNTIME_init_manager = "systemd"
## VIRTUAL-RUNTIME_dev_manager = "systemd"
## VIRTUAL-RUNTIME_initscripts = ""

Where INIT_MANAGER = "systemd" replaces all commented commands below

My two cent advice,
Zee
___

On Fri, May 28, 2021 at 1:28 AM Khem Raj  wrote:
>
>
>
> On 5/27/21 3:04 PM, sayinswa...@gmail.com wrote:
> > Hello Yocto team:
> >
> > I just started with yocto and would like to know the process for
> > switching the init manager from systemd to sysvinit.
> >
> > I tried this options in config file
> > VIRTUAL-RUNTIME_init_manager = "busybox"
> > PREFERRED_PROVIDER_udev = "sysvinit"
> > PREFERRED_PROVIDER_udev-utils = "sysvinit"
> > DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
> > DEFAULT_DISTRO_FEATURES += " sysvinit"
> >
> > I see a warning when building my machine:
> >
> > No recipe for target:
> > /recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
>
> Please find out which layer is adding this bbappend you could use
>
> bitbake-layers show-appends sysvinit
>
> It seems recipe version is newer perhaps and the bbappend is still made
> for older recipe, these things happen when you mix release branches for
> different layers.
>
> >
> > When I run this build on my target it still shows me systemd init manager...
> >
> > Not sure if I am missing any options.
> > Could you please let me know if there are any pointers I can refer to?
> >
> > Thanks,
> > Priya
> >
> >
> >
> >
> >
> >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53689): https://lists.yoctoproject.org/g/yocto/message/53689
Mute This Topic: https://lists.yoctoproject.org/mt/83136294/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [announcement] jumpnow/meta-bbb and jumpnow/meta-jumpnow

[Zoran]

Hello Folks,

In order to continue to develop my:
https://github.com/ZoranStojsavljevic/bbb-yocto

And advance to yocto hardknott, I did the temporary moves:

Cloned both jumpnow repos to my github space:
https://github.com/ZoranStojsavljevic/meta-bbb
https://github.com/ZoranStojsavljevic/meta-jumpnow

So far, I did only the framework job creating hardknott branches, to
be able to commence.

I'll try to advance meta-bbb with some recent kernels (5.12) in the near Future.

I hope Scott Ellis will return to continue to maintain his repos, but
in the meantime...

Zee
___

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53675): https://lists.yoctoproject.org/g/yocto/message/53675
Mute This Topic: https://lists.yoctoproject.org/mt/83131275/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] hardknott core-image-weston weston is crashing

[Zoran]

Seems like this bug has nothing to do with YOCTO, rather with Wayland setup

https://wayland-devel.freedesktop.narkive.com/6yavoPFZ/i-ve-got-a-question-to-ask-you

My two cent worth attempt,
Zoran
___

On Wed, May 26, 2021 at 11:40 AM Marek Belisko  wrote:
>
> Hi,
>
> I'm using hardknott poky release and build core-image-weston. When
> started on display I didn't see wayland screen + terminal just
> console. Same setup works fine on dunfell release.
>
> Output from weston service:
>
>GL_EXT_map_buffer_range GL_KHR_debug
>GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object
>GL_OES_required_internalformat GL_OES_surfaceless_context
>GL_EXT_separate_shader_objects
>GL_EXT_compressed_ETC1_RGB8_sub_texture
>GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp
>GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex
>GL_OES_texture_border_clamp GL_KHR_no_error
>GL_KHR_texture_compression_astc_sliced_3d
>GL_KHR_parallel_shader_compile GL_MESA_tile_raster_order
> [09:38:18.885] GL ES 2 renderer features:
>read-back format: BGRA
>wl_shm sub-image to texture: yes
>EGL Wayland extension: yes
> [09:38:18.899] warning: no input devices on entering Weston. Possible causes:
> - no permissions to read /dev/input/event*
> - seats misconfigured (Weston backend option 'seat', udev
> device property ID_SEAT)
> [09:38:18.899] failed to create input devices
> Segmentation fault
>
> Machine is RPI3. Any ideas?
>
> Thanks and BR,
>
> marek
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53651): https://lists.yoctoproject.org/g/yocto/message/53651
Mute This Topic: https://lists.yoctoproject.org/mt/83096738/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] ERROR: ParseError at .../bbb-yocto-gatesgarth/meta-bbb/images/console-image.bb:4: Could not include required file images/basic-dev-image.bb

[Zoran]

> IIRC, dhcp-server has been replaced by kea, check on that side maybe.
> Read the migration notes, pretty sure the kea thing is listed there.

Done. All fixed according to Quentin's recommendations.

https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh#L114
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-gatesgarth/local.conf#L18
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-gatesgarth/local.conf_kernel#L26

Added to README.md .
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/README.md

Thank you,
Zoran
___

On Mon, May 24, 2021 at 9:27 PM Quentin Schulz  wrote:
>
>
>
> On May 24, 2021 2:13:57 PM UTC, Zoran  wrote:
> >Or, maybe, now the DHCP is included in the releases by default?
> >
> >Thank you,
> >Zoran
> >___
> >
> >On Mon, May 24, 2021 at 4:09 PM Zoran Stojsavljevic
> > wrote:
> >>
> >> Hello Quentin,
> >>
> >> Thank you for finding the bug. It was in front of my eyes (I print all
> >> the layers at the end of setup, but I missed to compare bb-layers from
> >> dunfell with bb-layers from gatesgarth).
> >>
> >> I should do better. With regards to testing thinking. ;-)
> >> ___
> >>
> >> Now, there are other bugs (I should say, new features introduced).
> >>
> >> Loading cache: 100%
> >> ||
> >> Time: 0:00:00
> >> Loaded 3533 entries from dependency cache.
> >> Parsing recipes: 100%
> >> |##|
> >> Time: 0:00:00
> >> Parsing of 2311 .bb files complete (2309 cached, 2 parsed). 3535
> >> targets, 121 skipped, 1 masked, 0 errors.
> >> NOTE: Resolving any missing task queue dependencies
> >> ERROR: Nothing RPROVIDES 'dhcp-libs' (but
> >> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> >> RDEPENDS on or otherwise requires it)
> >> NOTE: Runtime target 'dhcp-libs' is unbuildable, removing...
> >> Missing or unbuildable dependency chain was: ['dhcp-libs']
> >> ERROR: Nothing RPROVIDES 'dhcp-server' (but
> >> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> >> RDEPENDS on or otherwise requires it)
> >> NOTE: Runtime target 'dhcp-server' is unbuildable, removing...
> >> Missing or unbuildable dependency chain was: ['dhcp-server']
> >> ERROR: Nothing RPROVIDES 'dhcp-server-config' (but
> >> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> >> RDEPENDS on or otherwise requires it)
> >> NOTE: Runtime target 'dhcp-server-config' is unbuildable, removing...
> >> Missing or unbuildable dependency chain was: ['dhcp-server-config']
> >> ERROR: Nothing RPROVIDES 'dhcp-client' (but
> >> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> >> RDEPENDS on or otherwise requires it)
> >> NOTE: Runtime target 'dhcp-client' is unbuildable, removing...
> >> Missing or unbuildable dependency chain was: ['dhcp-client']
> >> ERROR: Nothing RPROVIDES 'dhcp-relay' (but
> >> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> >> RDEPENDS on or otherwise requires it)
> >> NOTE: Runtime target 'dhcp-relay' is unbuildable, removing...
> >> Missing or unbuildable dependency chain was: ['dhcp-relay']
> >> ERROR: Nothing RPROVIDES 'dhcp-omshell' (but
> >> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> >> RDEPENDS on or otherwise requires it)
> >> NOTE: Runtime target 'dhcp-omshell' is unbuildable, removing...
> >> Missing or unbuildable dependency chain was: ['dhcp-omshell']
> >>
> >> Seems that this line in local.conf got severely changed, or most
> >> likely the DHCP package version/handling got changed:
> >>
> >> CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp-libs dhcp-server
> >> dhcp-server-config dhcp-client dhcp-relay dhcp-omshell cmake
> >> libsocketcan nfs-utils rt-tests strace procps
> >> packagegroup-core-buildessential "
> >>
> >> The question is: what should I include in the
> >> CORE_IMAGE_EXTRA_INSTALL_append for the DHCP package for gatesgarth
> >> and later releases???
> >>

Re: [yocto] ERROR: ParseError at .../bbb-yocto-gatesgarth/meta-bbb/images/console-image.bb:4: Could not include required file images/basic-dev-image.bb

[Zoran]

Or, maybe, now the DHCP is included in the releases by default?

Thank you,
Zoran
___

On Mon, May 24, 2021 at 4:09 PM Zoran Stojsavljevic
 wrote:
>
> Hello Quentin,
>
> Thank you for finding the bug. It was in front of my eyes (I print all
> the layers at the end of setup, but I missed to compare bb-layers from
> dunfell with bb-layers from gatesgarth).
>
> I should do better. With regards to testing thinking. ;-)
> ___
>
> Now, there are other bugs (I should say, new features introduced).
>
> Loading cache: 100%
> ||
> Time: 0:00:00
> Loaded 3533 entries from dependency cache.
> Parsing recipes: 100%
> |##|
> Time: 0:00:00
> Parsing of 2311 .bb files complete (2309 cached, 2 parsed). 3535
> targets, 121 skipped, 1 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing RPROVIDES 'dhcp-libs' (but
> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'dhcp-libs' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['dhcp-libs']
> ERROR: Nothing RPROVIDES 'dhcp-server' (but
> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'dhcp-server' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['dhcp-server']
> ERROR: Nothing RPROVIDES 'dhcp-server-config' (but
> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'dhcp-server-config' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['dhcp-server-config']
> ERROR: Nothing RPROVIDES 'dhcp-client' (but
> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'dhcp-client' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['dhcp-client']
> ERROR: Nothing RPROVIDES 'dhcp-relay' (but
> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'dhcp-relay' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['dhcp-relay']
> ERROR: Nothing RPROVIDES 'dhcp-omshell' (but
> /home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
> RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'dhcp-omshell' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['dhcp-omshell']
>
> Seems that this line in local.conf got severely changed, or most
> likely the DHCP package version/handling got changed:
>
> CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp-libs dhcp-server
> dhcp-server-config dhcp-client dhcp-relay dhcp-omshell cmake
> libsocketcan nfs-utils rt-tests strace procps
> packagegroup-core-buildessential "
>
> The question is: what should I include in the
> CORE_IMAGE_EXTRA_INSTALL_append for the DHCP package for gatesgarth
> and later releases???
>
> Thank you,
> Zoran
> ___
>
> On Mon, May 24, 2021 at 2:24 PM Quentin Schulz  wrote:
> >
> > Hi Zoran,
> >
> > On May 24, 2021 8:27:58 AM UTC, Zoran  wrote:
> > >Hello again to YOCTO Folks,
> > >
> > >Here is another blunder I ran into while fixing a yocto-setup.sh script:
> > >https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh
> > >
> > >While executing $  . ./yocto-setup.sh dunfell, everything ran smoothly.
> > >
> > >I did the same routine with the $  . ./yocto-setup.sh gatesgarth, and
> > >approximately after:
> > >Parsing recipes: 9% |##
> > >
> > >The following message pops up!
> > >Loading cache: 100% |
> > >| ETA:  --:--:--
> > >Loaded 0 entries from dependency cache.
> > >ERROR: ParseError at
> > >/home/vuser/projects_yocto/bbb-yocto-gatesgarth/meta-bbb/images/console-image.bb:4:
> > >Could not include required file images/basic-dev-image.bb
> > >
> > >Summary: There was 1 WARNING message shown.
> > >Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> > >
> >
> > The layer is not included. Check in your bblayers.c

Re: [yocto] ERROR: ParseError at .../bbb-yocto-gatesgarth/meta-bbb/images/console-image.bb:4: Could not include required file images/basic-dev-image.bb

[Zoran]

Hello Quentin,

Thank you for finding the bug. It was in front of my eyes (I print all
the layers at the end of setup, but I missed to compare bb-layers from
dunfell with bb-layers from gatesgarth).

I should do better. With regards to testing thinking. ;-)
___

Now, there are other bugs (I should say, new features introduced).

Loading cache: 100%
||
Time: 0:00:00
Loaded 3533 entries from dependency cache.
Parsing recipes: 100%
|##|
Time: 0:00:00
Parsing of 2311 .bb files complete (2309 cached, 2 parsed). 3535
targets, 121 skipped, 1 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'dhcp-libs' (but
/home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'dhcp-libs' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['dhcp-libs']
ERROR: Nothing RPROVIDES 'dhcp-server' (but
/home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'dhcp-server' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['dhcp-server']
ERROR: Nothing RPROVIDES 'dhcp-server-config' (but
/home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'dhcp-server-config' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['dhcp-server-config']
ERROR: Nothing RPROVIDES 'dhcp-client' (but
/home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'dhcp-client' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['dhcp-client']
ERROR: Nothing RPROVIDES 'dhcp-relay' (but
/home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'dhcp-relay' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['dhcp-relay']
ERROR: Nothing RPROVIDES 'dhcp-omshell' (but
/home/vuser/projects_yocto/bbb-yocto-gatesgarth/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'dhcp-omshell' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['dhcp-omshell']

Seems that this line in local.conf got severely changed, or most
likely the DHCP package version/handling got changed:

CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp-libs dhcp-server
dhcp-server-config dhcp-client dhcp-relay dhcp-omshell cmake
libsocketcan nfs-utils rt-tests strace procps
packagegroup-core-buildessential "

The question is: what should I include in the
CORE_IMAGE_EXTRA_INSTALL_append for the DHCP package for gatesgarth
and later releases???

Thank you,
Zoran
___

On Mon, May 24, 2021 at 2:24 PM Quentin Schulz  wrote:
>
> Hi Zoran,
>
> On May 24, 2021 8:27:58 AM UTC, Zoran  wrote:
> >Hello again to YOCTO Folks,
> >
> >Here is another blunder I ran into while fixing a yocto-setup.sh script:
> >https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh
> >
> >While executing $  . ./yocto-setup.sh dunfell, everything ran smoothly.
> >
> >I did the same routine with the $  . ./yocto-setup.sh gatesgarth, and
> >approximately after:
> >Parsing recipes: 9% |##
> >
> >The following message pops up!
> >Loading cache: 100% |
> >| ETA:  --:--:--
> >Loaded 0 entries from dependency cache.
> >ERROR: ParseError at
> >/home/vuser/projects_yocto/bbb-yocto-gatesgarth/meta-bbb/images/console-image.bb:4:
> >Could not include required file images/basic-dev-image.bb
> >
> >Summary: There was 1 WARNING message shown.
> >Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> >
>
> The layer is not included. Check in your bblayers.conf. see 
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/a6e8e8ce491705816d02df58fa0ef9378b18ef83/yocto-setup.sh#L114
>  where you are missing the gatesgarth check.
>
> Cheers,
> Quentin
>
>
> >If you peek into the following github repos:
> >https://github.com/jumpnow/meta-bbb
> >https://github.com/jumpnow/meta-jumpnow
> >
> >You'll see that in later  images/basic-dev-image.bb does exist, as
> >well as in the dunfell branch:
> >https://github.com/jumpnow/meta-jumpnow/blob/zeus/images/basic-dev-image.bb
> >
> >As well as in gatesgarth branch:
>

[yocto] ERROR: ParseError at .../bbb-yocto-gatesgarth/meta-bbb/images/console-image.bb:4: Could not include required file images/basic-dev-image.bb

[Zoran]

Hello again to YOCTO Folks,

Here is another blunder I ran into while fixing a yocto-setup.sh script:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh

While executing $  . ./yocto-setup.sh dunfell, everything ran smoothly.

I did the same routine with the $  . ./yocto-setup.sh gatesgarth, and
approximately after:
Parsing recipes: 9% |##

The following message pops up!
Loading cache: 100% |
| ETA:  --:--:--
Loaded 0 entries from dependency cache.
ERROR: ParseError at
/home/vuser/projects_yocto/bbb-yocto-gatesgarth/meta-bbb/images/console-image.bb:4:
Could not include required file images/basic-dev-image.bb

Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

If you peek into the following github repos:
https://github.com/jumpnow/meta-bbb
https://github.com/jumpnow/meta-jumpnow

You'll see that in later  images/basic-dev-image.bb does exist, as
well as in the dunfell branch:
https://github.com/jumpnow/meta-jumpnow/blob/zeus/images/basic-dev-image.bb

As well as in gatesgarth branch:
https://github.com/jumpnow/meta-jumpnow/blob/gatesgarth/images/basic-dev-image.bb

What I see upon the logic, something changes in poky/ setup, while
transitioning from dunfell to gatesgarth.

I also have created an issue in bbb-yocto repo:
https://github.com/ZoranStojsavljevic/bbb-yocto/issues/3

I would appreciate any ideas or hints...  Maybe some changes required
in local.conf ?

You can all try it yourselves, and see the same!

Thank you,
Zoran
___

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53623): https://lists.yoctoproject.org/g/yocto/message/53623
Mute This Topic: https://lists.yoctoproject.org/mt/83046309/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Problem with YOCTO Dunfell and host Fedora 33

[Zoran]

Hello Joel,

Thank you for the tips. Really helpful, appreciated very much.

I spent some time this morning investigating this issue, and to find
the culprit.

Here are my findings, which resulted in a cannelloni.bb recipe change
(according to what you wrote).

The fix submitted is in recipe:
https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/cannelloni/cannelloni.bb

The last cannelloni version which works is:
https://github.com/mguentner/cannelloni/commit/0bd7e27db35bdef361226882ae04205504f7b2f4

The culprit introducing the cmake errors is this one:
https://github.com/mguentner/cannelloni/commit/d01dd1dc745914d129b1f4da2074e282253246af

And, the issue recorded with Maximilian Guentner's cannelloni repo:
https://github.com/mguentner/cannelloni/issues/35

Thank you again,
Zoran
___

On Thu, May 20, 2021 at 4:48 PM Joel Winarske  wrote:
>
> Hi Zoran,
>
> Your cannelloni recipe is set to autorev, meaning it's not locked to a 
> commit.  So when something changes upstream you have to manage it.
>
> Chances are Canelloni introduced a CMake change which is overwriting (opposed 
> to appending) one or more variables required for cross compiling.  Perhaps 
> try to cross compile (not a host build) Canelloni by itself without Yocto 
> involved.  Once that's sorted, then reintroduce yocto.
>
>
> Joel
>
>
> On Thu, May 20, 2021, 6:58 AM Zoran  wrote:
>>
>> Hello Yocto developers,
>>
>> I have few problems running the following self proprietary script from
>> one of my public git repos:
>> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh
>>
>> I recall that last time I used the script (I used then Fedora 31), the
>> ./yocto setup dunfell worked seamlessly, did setup the environment,
>> and upon bitbake -k core-image-minimal completed the tasks without any
>> problem.
>>
>> Now, I am using Fedora 33 (in the meantime I did two Fedora version 
>> upgrades).
>>
>> The problem is that while compiling the cannelloni package, the
>> following errors were issued (please, look into the attached file
>> cmake_problem.txt).
>>
>> This cmake problem was introduced after switching from Fedora 31 to Fedora 
>> 33 ?!
>>
>> Any clue/idea why this is happening??? What is the cause of the problem?
>>
>> Thank you,
>> Zoran
>> ___
>>
>> 
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53614): https://lists.yoctoproject.org/g/yocto/message/53614
Mute This Topic: https://lists.yoctoproject.org/mt/82961982/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Problem with YOCTO Dunfell and host Fedora 33

[Zoran]

Hello Yocto developers,

I have few problems running the following self proprietary script from
one of my public git repos:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh

I recall that last time I used the script (I used then Fedora 31), the
./yocto setup dunfell worked seamlessly, did setup the environment,
and upon bitbake -k core-image-minimal completed the tasks without any
problem.

Now, I am using Fedora 33 (in the meantime I did two Fedora version upgrades).

The problem is that while compiling the cannelloni package, the
following errors were issued (please, look into the attached file
cmake_problem.txt).

This cmake problem was introduced after switching from Fedora 31 to Fedora 33 ?!

Any clue/idea why this is happening??? What is the cause of the problem?

Thank you,
Zoran
___
[vuser@fedora33-ssd build]$ bitbake -k core-image-minimal
WARNING: Host distribution "fedora-33" has not been validated with this version 
of the build system; you may possibly experience unexpected failures. It is 
recommended that you use a tested distribution.
Loading cache: 100% 
|| 
Time: 0:00:00
Loaded 3309 entries from dependency cache.
Parsing recipes: 100% 
|##| 
Time: 0:00:01
Parsing of 2201 .bb files complete (2198 cached, 3 parsed). 3312 targets, 117 
skipped, 1 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.46.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "arm-poky-linux-gnueabi"
MACHINE  = "beaglebone"
DISTRO   = "poky"
DISTRO_VERSION   = "3.1.7"
TUNE_FEATURES= "arm vfp cortexa8 neon callconvention-hard"
TARGET_FPU   = "hard"
meta 
meta-poky
meta-yocto-bsp   = "dunfell:97a9f30f1c457c55bf0c791d0466ff8620110a49"
meta-jumpnow = "dunfell:b3995636741be0d219a50035c98ded8b48590888"
meta-bbb = "dunfell:fa02d8e9079c1cc18f83527588a9dd2747293992"
meta-oe  
meta-python  
meta-networking  = "dunfell:2915810edbb6599051e30efb3b7f805665ddcc23"
meta-qt5 = 
"upstream/dunfell:b4d24d70aca75791902df5cd59a4f4a54aa4a125"
meta-socketcan   = "master:4e7128b75ba731fc8be662385659fb7f9c440d12"

Initialising tasks: 100% 
|###| Time: 
0:00:04
Sstate summary: Wanted 10 Found 0 Missed 10 Current 1698 (0% match, 99% 
complete)
NOTE: Executing Tasks
ERROR: cannelloni-1.0-r0 do_compile: Execution of 
'/home/vuser/projects_yocto/bbb-yocto/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/temp/run.do_compile.2406989'
 failed with exit code 1:
[1/12] 
/home/vuser/projects_yocto/bbb-yocto/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
   -I. -Wall -DNDEBUG -MD -MT CMakeFiles/addsources.dir/connection.cpp.o -MF 
CMakeFiles/addsources.dir/connection.cpp.o.d -o 
CMakeFiles/addsources.dir/connection.cpp.o -c 
/home/vuser/projects_yocto/bbb-yocto/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/git/connection.cpp
FAILED: CMakeFiles/addsources.dir/connection.cpp.o 
/home/vuser/projects_yocto/bbb-yocto/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
   -I. -Wall -DNDEBUG -MD -MT CMakeFiles/addsources.dir/connection.cpp.o -MF 
CMakeFiles/addsources.dir/connection.cpp.o.d -o 
CMakeFiles/addsources.dir/connection.cpp.o -c 
/home/vuser/projects_yocto/bbb-yocto/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/git/connection.cpp
In file included from 
/home/vuser/projects_yocto/bbb-yocto/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/git/connection.cpp:21:
/home/vuser/projects_yocto/bbb-yocto/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/git/connection.h:23:10:
 fatal error: linux/can/raw.h: No such file or directory
   23 | #include 
  |  ^
compilation terminated.
[2/12] 
/home/vuser/projects_yocto/bbb-yocto/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
   -I. -Wall -DNDEBUG -MD -MT CMakeFiles/addsources.dir/thread.cpp.o -MF 
CMakeFiles/addsources.dir/thread.cpp.o.d -o 
CMakeFiles/addsources.dir/thread.cpp.o -c 
/home/vuser/projects_yocto/bbb-yocto/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/git/thread.cpp
FAIL

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

[Zoran]

Hello Rohit,

It is a good find. I also googled for the error, and found this as an
explanation:
https://www.yoctoproject.org/pipermail/yocto/2019-February/044153.html

I included Alex (Kanavin), who created the above mail.

Maybe Alex can give more light on the problem?

In the meantime, you should explore (by similarities) this pointer in
very details:
https://github.com/Xilinx/meta-virtualization/issues/4#issuecomment-590532621

Zoran
___

On Thu, May 13, 2021 at 8:25 AM rohit jadhav  wrote:
>
> Hi Zoran,
>log.do_rootfs.31340is linked to log.do_rootfs I have checked with ls 
> command, So both files are identical.
>
> While surfing I found similar thread but its for different package  its as 
> follows :
> https://github.com/Xilinx/meta-virtualization/issues/4
>
> Can you please help out with this for our Package Hostapd ?
>
> Thanks and Regards
> Rohit
>
> On Thu, May 13, 2021 at 10:18 AM Zoran Stojsavljevic 
>  wrote:
>>
>> From the log log.do_rootfs.31340 file, there are the following:
>>
>> [1] ERROR: Postinstall scriptlets of ['hostapd'] have failed.
>>
>> HOSTAP stands for: HOST Access Point Daemon. I could not conclude too much 
>> from:
>> https://en.wikipedia.org/wiki/Hostapd
>>
>> It is kind of a hot spot, as my best understanding is.
>>
>> [2] Details of the failure are in
>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
>>
>> So, my best guess, looking into log.do_rootfs will tell us much more.
>>
>> Please, attach this one for our review as well.
>>
>> Thank you,
>> Zoran
>> ___
>>
>> On Wed, May 12, 2021 at 5:29 PM rohit jadhav  wrote:
>> >
>> > Hi Zoran ,
>> > I have attached the log file for your reference.
>> > Thank You
>> > Regards
>> > Rohit
>> >
>> > On Wed, May 12, 2021 at 7:50 PM Zoran Stojsavljevic 
>> >  wrote:
>> >>
>> >> > Log file in:
>> >> > /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
>> >> > imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
>> >> log.do_rootfs.31340
>> >>
>> >> Could you, please, attach a log file?
>> >>
>> >> Thank you,
>> >> Zoran
>> >> ___
>> >>
>> >>
>> >> On Wed, May 12, 2021 at 2:01 PM rohit jadhav  
>> >> wrote:
>> >>>
>> >>> Facing following issue :
>> >>> ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of 
>> >>> ['hostapd'] have failed. If the intention is to defer them to first boot,
>> >>> then please place them into pkg_postinst_ontarget_${PN} ().
>> >>> Deferring to first boot via 'exit 1' is no longer supported.
>> >>> Details of the failure are in 
>> >>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
>> >>> ERROR: Logfile of failure stored in: 
>> >>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
>> >>> ERROR: Task 
>> >>> (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
>> >>>  failed with exit code '1'
>> >>>
>> >>> Please guide me if anyone have any idea to resolve.
>> >>>
>> >>> Thanks in advance.
>> >>> 
>> >>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53502): https://lists.yoctoproject.org/g/yocto/message/53502
Mute This Topic: https://lists.yoctoproject.org/mt/82769987/21656
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

[Zoran]

>From the log log.do_rootfs.31340 file, there are the following:

[1] ERROR: Postinstall scriptlets of ['hostapd'] have failed.

HOSTAP stands for: HOST Access Point Daemon. I could not conclude too much from:
https://en.wikipedia.org/wiki/Hostapd

It is kind of a hot spot, as my best understanding is.

[2] Details of the failure are in
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.

So, my best guess, looking into log.do_rootfs will tell us much more.

Please, attach this one for our review as well.

Thank you,
Zoran
___

On Wed, May 12, 2021 at 5:29 PM rohit jadhav  wrote:
>
> Hi Zoran ,
> I have attached the log file for your reference.
> Thank You
> Regards
> Rohit
>
> On Wed, May 12, 2021 at 7:50 PM Zoran Stojsavljevic 
>  wrote:
>>
>> > Log file in:
>> > /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
>> > imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
>> log.do_rootfs.31340
>>
>> Could you, please, attach a log file?
>>
>> Thank you,
>> Zoran
>> ___
>>
>>
>> On Wed, May 12, 2021 at 2:01 PM rohit jadhav  wrote:
>>>
>>> Facing following issue :
>>> ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of 
>>> ['hostapd'] have failed. If the intention is to defer them to first boot,
>>> then please place them into pkg_postinst_ontarget_${PN} ().
>>> Deferring to first boot via 'exit 1' is no longer supported.
>>> Details of the failure are in 
>>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
>>> ERROR: Logfile of failure stored in: 
>>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
>>> ERROR: Task 
>>> (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
>>>  failed with exit code '1'
>>>
>>> Please guide me if anyone have any idea to resolve.
>>>
>>> Thanks in advance.
>>> 
>>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53499): https://lists.yoctoproject.org/g/yocto/message/53499
Mute This Topic: https://lists.yoctoproject.org/mt/82769987/21656
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [yocto] Yocto Project Status WW18`21

[Zoran]

> We have discussed extending it but we currently only have the funding
> for the originally planned 2 years.

Really/echt??? Why? ;)

Zoran
___

On Wed, May 5, 2021 at 12:33 AM Richard Purdie
 wrote:
>
> On Tue, 2021-05-04 at 18:38 +0200, Alexander Kanavin wrote:
> > On Tue, 4 May 2021 at 16:46, Stephen Jolley  wrote:
> > > We are pleased to announce that our April 2022 release (potentially 3.5) 
> > > will
> > > be the next LTS as per our original two year schedule. If there are 
> > > features
> > > desired in the next LTS, now is the time to get them submitted and 
> > > stabilized
> > > ready.
> > >
> >
> > What will happen to the current LTS at that point? Will support be cut off,
> > will there be a transition window, or is it currently undefined?
>
> We have discussed extending it but we currently only have the funding for the
> originally planned 2 years. Discussions are continuing but since we do all
> agree that the next LTS will start then, we decided to at least let people
> plan against that.
>
> Unless funding/support is secured, dunfell would move to community support
> if anyone were willing to step up, or become EOL and replaced by the new LTS.
> There would likely be some period of overlap of a few months to transition.
>
> There is also concern about pressuring wider community layers for longer 
> support
> cycles which is something we need to think about.
>
> Cheers,
>
> Richard
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53486): https://lists.yoctoproject.org/g/yocto/message/53486
Mute This Topic: https://lists.yoctoproject.org/mt/82591732/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

[Zoran]

> Log file in:
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
> imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
*log.do_rootfs.31340*

Could you, please, attach a log file?

Thank you,
Zoran
___


On Wed, May 12, 2021 at 2:01 PM rohit jadhav 
wrote:

> Facing following issue :
> ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of
> ['hostapd'] have failed. If the intention is to defer them to first boot,
> then please place them into pkg_postinst_ontarget_${PN} ().
> Deferring to first boot via 'exit 1' is no longer supported.
> Details of the failure are in
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
> ERROR: Logfile of failure stored in:
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
> ERROR: Task
> (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
> failed with exit code '1'
>
> Please guide me if anyone have any idea to resolve.
>
> Thanks in advance.
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53481): https://lists.yoctoproject.org/g/yocto/message/53481
Mute This Topic: https://lists.yoctoproject.org/mt/82769987/21656
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
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

[Zoran]

> +-#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

[Zoran]

> 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

Re: [yocto] Enabling Serial console via uart1(serial1) in cm3(rpi3) kernel 5.4. #cm3 #dunfell

[Zoran]

Why am I (only, seems) always answering NON YOCTO issues in the YOCTO
thread??? ;-)
___

OK. The good sign about what U R talking is shown here:
[0.000885] printk: console [tty1] enabled

> But now another issue I'm facing when I'm enabling console
> via this ttsS0 port i.e.
> [   13.280639] ttyS ttyS0: 2 input overrun(s)

It is on the several places:
[6.480654] ttyS ttyS0: 2 input overrun(s)
[7.962826] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex,
lpa 0xCDE1
[7.973416] ttyS ttyS0: 2 input overrun(s)
[   11.883822] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[   11.893705] ttyS ttyS0: 2 input overrun(s)
[   13.268076] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state
recovery directory
[   13.280639] ttyS ttyS0: 2 input overrun(s)

It seems that the solution for this problem is:
https://www.linuxquestions.org/questions/linux-kernel-70/tty-usb-input-overruns-4175512707/

Namely:
https://www.linuxquestions.org/questions/linux-kernel-70/tty-usb-input-overruns-4175512707/#post5215591

> I fixed the problem with increasing the N_TTY_BUF_SIZE from 4096 to 131072
> (file /include/linux/tty.h) and recompiled the linux kernel. I'm getting no 
> more tty
> input overrun(s).

Please, let us know.

Zee
___





On Mon, Mar 22, 2021 at 10:19 AM  wrote:
>
> Hi Zoran,
> here is the cat /proc/cmdline output of my cm3-
>
> coherent_pool=1M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 
> snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=720 
> bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 
> smsc95xx.macaddr=B8:27:EB:AD:85:CA vc_mem.mem_base=0x3ec0 
> vc_mem.mem_size=0x4000  dwc_otg.lpm_enable=0 console=ttyS0,115200 
> console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait 
> kgdboc=ttyAMA0,115200
>
> Earlier my issue was that  I was no getting /dev/ttyS0 terminal in my yocto 
> image for cm3.
> But going through the web I got that setting 1 to 
> CONFIG_SERIAL_8250_RUNTIME_UARTS  solved that issue and now I'm getting ttyS0 
> in my /dev directory.
>
> But now another issue I'm facing when I'm enabling cosole via this ttsS0 port 
> i.e.
>   
> [   13.280639] ttyS ttyS0: 2 input 
> overrun(s)
>
> here is my dmesg output:
>
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 5.4.64-v7 (oe-user@oe-host) (gcc version 9.3.0 
> (GCC)) #1 SMP Fri Sep 11 12:57:30 UTC 2020
> [0.00] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
> [0.00] CPU: div instructions available: patching division code
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: Raspberry Pi Compute Module 3 Rev 1.0
> [0.00] Memory policy: Data cache writealloc
> [0.00] Reserved memory: created CMA memory pool at 0x3740, size 
> 64 MiB
> [0.00] OF: reserved mem: initialized node linux,cma, compatible id 
> shared-dma-pool
> [0.00] On node 0 totalpages: 242688
> [0.00]   Normal zone: 2133 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 242688 pages, LIFO batch:63
> [0.00] percpu: Embedded 20 pages/cpu s50060 r8192 d23668 u81920
> [0.00] pcpu-alloc: s50060 r8192 d23668 u81920 alloc=20*4096
> [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 240555
> [0.00] Kernel command line: coherent_pool=1M 
> snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 
> snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=720 
> bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 
> smsc95xx.macaddr=B8:27:EB:AD:85:CA vc_mem.mem_base=0x3ec0 
> vc_mem.mem_size=0x4000  dwc_otg.lpm_enable=0 console=ttyS0,115200 
> console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait 
> kgdboc=ttyAMA0,115200
> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
> bytes, linear)
> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, 
> linear)
> [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
> [0.00] Memory: 880444K/970752K available (9216K kernel code, 716K 
> rwdata, 2684K rodata, 1024K init, 849K bss, 24772K reserved, 65536K 
> cma-reserved)
> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [0.00] ftrace: allocating 29805 entries in 59 pages
> [0.00] rcu: Hierarchical RCU implementation.
> [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 
> jiffies.
> [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irq

Re: [yocto] spidev.c ?

[Zoran]

>  // interrupt-parent = <>;
>  // interrupts = <0 24 IRQ_TYPE_EDGE_FALLING>;

Not sure if you did represent these values correctly?!

I have for enc28j60:something like this:
interrupt-parent = <>;
interrupts = <1 IRQ_TYPE_EDGE_FALLING>;

Where <> is gpio chip name (the gpio port 2),
and <1 IRQ_TYPE_EDGE_FALLING>;is pin 1 of port 2 (32 pins for ports
from port 0).

<> should be an INT controller.
Since <0 24 IRQ_TYPE_EDGE_FALLING>; you are trying to represent 0 as
port #, 24 as pin #...

I have no idea how many pins you have per gpio port? 16? 32?

You should carefully analyse and try to understand if you wrote this
device tree sequence correctly.

But I am just guessing now...

Zee
___

On Sat, Mar 20, 2021 at 11:02 PM jchludzinski  wrote:
>
> Using 'make nconfig' I selected the following options:
> (Keep in mind I using an Altera/Intel Arria 10 SoC which uses DesignWare hard 
> SPI controllers. BUT the SPI controllers I'm concerned with now are soft 
> controllers defined in the FPGA code).
>
>  .config - Linux/arm 5.4.74 Kernel Configuration
>  ┌── SPI support 
> ─┐
>  │
> │
>  │--- SPI support 
> │
>  │[*]   Debug support for SPI drivers 
> │
>  │-*-   SPI memory extension  
> │
>  │  *** SPI Master Controller Drivers *** 
> │
>  │   Altera SPI Controller
>
> ...
>
>  │<*>   Utilities for Bitbanging SPI masters  
> │
>  │< >   Cadence SPI controller
> │
>  │< >   CLPS711X host SPI controller  
> │
>  │<*>   DesignWare SPI controller core support
> │
>  │<*> PCI interface driver for DW SPI core
> │
>  │<*> Memory-mapped io interface driver for 
> DW SPI core   │
>
> ...
>
>  │  *** SPI Protocol Masters ***  
> │
>  │   User mode SPI device driver support   
> │
>  │   spi loopback test framework support   
> │
>  │< >   Infineon TLE62X0 (for power switching)
> │
>  │[*]   SPI slave protocol handlers   
> │
>  │ SPI slave handler reporting boot up 
> time│
>  │ SPI slave handler controlling system 
> state  │
>
> This got the SPI nodes to show up in /sys/firmware/devicetree/ but there were 
> no udev files (/dev/spidevXX). So I commented out the 'interrupts' in the 
> DTSI file and the udev files appeared?
>
> spi2: spi@0xc00c0800 { // hps_spi_1553_int
>address-cells = <0x1>;
>#size-cells = <0x0>;
>reg = <0xc00c0800 0x20>;
>// interrupt-parent = <>;
>// interrupts = <0 24 IRQ_TYPE_EDGE_FALLING>;
>num-cs = <0x1>;
>status = "okay";
>
>spidev@0 {
>   compatible = "rohm,dh2228fv";
>   #address-cells = <0x1>;
>   #size-cells = <0x0>;
>   reg = <0x0>;
>   spi-max-frequency = <0x1f400>;
>   // enable-dma = <0x1>;
>};
> };
>
> BUT I need those interrupts. Thoughts and/or suggestions?
>
> ---

Re: [yocto] spidev.c ?

[Zoran]

Hello John,

It seems that your target is configured correctly. Since you have all
the components you should and must have as SPI framework.

Namely I was looking for /sys/bus (since you must have an SPI bus
driver), and then /sys/class (since as my best understanding is that
SPI is a master/slave device), you must have class/). Others are
assumed, you added debug directories.

> When I separately build spidev.c as an .ko and try
> loading it, I get: "Device or resource busy"

This is understandable, since you already have included spidev.ko as
menuconfig value Y, so it is already present in the kernel, but as a
built-in part of the kernel (my best guess).

> root@arria10:~# lsmod
> Module  Size  Used by
> spi_altera 16384  0
> spidev 20480  0

I see that you did change the menuconfig, and made spidev to be M.

What I also see is that there are no dependencies between spidev and
spi_altera. This is what you really wanted?

> But there are NO udev files for the SPI devices
> defined in the DTSI file.

Could you, please, better explain this sentence? In more details (as
much as you can)?

Thank you,
Zee
___


On Thu, Mar 18, 2021 at 10:07 PM jchludzinski  wrote:
>
> root@arria10:~# find /sys/ -name 'spi*'
>
> /sys/kernel/debug/clk/spi_m_clk
> /sys/kernel/debug/tracing/events/spi
> /sys/kernel/debug/tracing/events/spi/spi_controller_idle
> /sys/kernel/debug/tracing/events/spi/spi_controller_busy
> /sys/kernel/debug/tracing/events/spi/spi_message_submit
> /sys/kernel/debug/tracing/events/spi/spi_message_start
> /sys/kernel/debug/tracing/events/spi/spi_message_done
> /sys/kernel/debug/tracing/events/spi/spi_transfer_start
> /sys/kernel/debug/tracing/events/spi/spi_transfer_stop
> /sys/kernel/debug/regmap/spi0.0
> /sys/devices/platform/soc/ffda5000.spi/spi_master
> /sys/devices/platform/soc/ffda5000.spi/spi_master/spi0
> /sys/devices/platform/soc/ffda5000.spi/spi_master/spi0/spi0.0
> /sys/devices/platform/soc/ffda5000.spi/spi_master/spi0/spi0.0/statistics/spi_sync
> /sys/devices/platform/soc/ffda5000.spi/spi_master/spi0/spi0.0/statistics/spi_async
> /sys/devices/platform/soc/ffda5000.spi/spi_master/spi0/spi0.0/statistics/spi_sync_immediate
> /sys/devices/platform/soc/ffda5000.spi/spi_master/spi0/statistics/spi_sync
> /sys/devices/platform/soc/ffda5000.spi/spi_master/spi0/statistics/spi_async
> /sys/devices/platform/soc/ffda5000.spi/spi_master/spi0/statistics/spi_sync_immediate
> /sys/class/spidev
> /sys/class/spi_master
> /sys/class/spi_master/spi0
> /sys/firmware/devicetree/base/__symbols__/spi2
> /sys/firmware/devicetree/base/__symbols__/spi0
> /sys/firmware/devicetree/base/__symbols__/spin_ctrl_1
> /sys/firmware/devicetree/base/__symbols__/spi_m_clk
> /sys/firmware/devicetree/base/__symbols__/spi1
> /sys/firmware/devicetree/base/__symbols__/spin_ctrl_2
> /sys/firmware/devicetree/base/soc/spi@ff809000
> /sys/firmware/devicetree/base/soc/spi@ffda5000
> /sys/firmware/devicetree/base/soc/spi@ffda5000/resource-manager@0/spi-max-frequency
> /sys/firmware/devicetree/base/soc/clkmgr@ffd04000/clocks/spi_m_clk
> /sys/firmware/devicetree/base/soc/spi@ffda4000
> /sys/firmware/devicetree/base/spi@0xc00c0800
> /sys/firmware/devicetree/base/spi@0xc00c0800/spidev@0
> /sys/firmware/devicetree/base/spi@0xc00c0800/spidev@0/spi-max-frequency
> /sys/firmware/devicetree/base/testcase-data-2/fairway-1/ride@200/spin-controller
> /sys/firmware/devicetree/base/testcase-data-2/fairway-1/ride@200/spin-rph
> /sys/firmware/devicetree/base/testcase-data-2/fairway-1/ride@100/spin-controller
> /sys/firmware/devicetree/base/testcase-data-2/fairway-1/ride@100/spin-controller-names
> /sys/firmware/devicetree/base/testcase-data-2/substation@100/motor-1/spin
> /sys/bus/platform/drivers/spi_altera
> /sys/bus/spi
> /sys/bus/spi/devices/spi0.0
> /sys/bus/spi/drivers/spi-nor
> /sys/bus/spi/drivers/altr_a10sr/spi0.0
> /sys/bus/spi/drivers/spidev
> /sys/module/spidev
> /sys/module/spidev/drivers/spi:spidev
> /sys/module/spi_altera
>
>
>
>
> On 2021-03-18 03:44, Zoran wrote:
>
> I am guessing here But what do you have while executing the
> following command being in /sys
>  as root?
>
> root@arm:/sys# find . -name spi*
>
> Zee
> ___
>
> On Wed, Mar 17, 2021 at 5:41 PM jchludzinski via
> lists.yoctoproject.org
>  wrote:
>
>
> In the YOCTO/Linux source tree there's drivers/spi/ which has all the source 
> for SPI drivers. There's only 1 file, spidev.c, which has:
>
> static int __init spidev_init(void)
> {
> int status;
>
> /* Claim our 256 reserved device numbers.  Then register a class
>  * that will key udev/mdev to add/remove /dev nodes.  Last, register
>  * the d

Re: [yocto] spidev.c ?

[Zoran]

I am guessing here But what do you have while executing the
following command being in /sys
 as root?

root@arm:/sys# find . -name spi*

Zee
___

On Wed, Mar 17, 2021 at 5:41 PM jchludzinski via
lists.yoctoproject.org
 wrote:
>
> In the YOCTO/Linux source tree there's drivers/spi/ which has all the source 
> for SPI drivers. There's only 1 file, spidev.c, which has:
>
> static int __init spidev_init(void)
> {
> int status;
>
> /* Claim our 256 reserved device numbers.  Then register a class
>  * that will key udev/mdev to add/remove /dev nodes.  Last, register
>  * the driver which manages those device numbers.
>  */
> BUILD_BUG_ON(N_SPI_MINORS > 256);
> status = register_chrdev(SPIDEV_MAJOR, "spi", _fops);
> if (status < 0)
> return status;
>
> spidev_class = class_create(THIS_MODULE, "spidev");
> if (IS_ERR(spidev_class)) {
> unregister_chrdev(SPIDEV_MAJOR, 
> spidev_spi_driver.driver.name);
> return PTR_ERR(spidev_class);
> }
>
> status = spi_register_driver(_spi_driver);
> if (status < 0) {
> class_destroy(spidev_class);
> unregister_chrdev(SPIDEV_MAJOR, 
> spidev_spi_driver.driver.name);
> }
> return status;
> }
> module_init(spidev_init);
>
> ... for creating device files in udev.
>
> So when I use 'make nconfig' to specifiy that I want a loadable module for 
> the ALTERA SPI driver, why don't I see a spidev.o file in drivers/spi/ ?
>
> How does spi-altera.ko create device files without a call to 
> register_chrdev(...).
>
> How is it a loadable module without module_init(...)?
>
> When I separately build spidev.c as an .ko and try loading it, I get: "Device 
> or resourse busy"
>
> ---John
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52762): https://lists.yoctoproject.org/g/yocto/message/52762
Mute This Topic: https://lists.yoctoproject.org/mt/81407811/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How can I create a truly minimal distribution that runs entirely from RAM?

[Zoran]

> Please be aware that this is a community mailing list for the Yocto
> Project, and we expect everyone to be as pleasant as possible
> I don't think the tone of your last email is appropriate for our
> mailing lists.

Unfortunately, Nicolas, you are barking under the wrong tree.

Please, go to Ross Burton, bark there, and align the (?) views (nothing against
your attack against me).

Thank you,
Zoran Stojsavljevic
___

On Mon, Mar 15, 2021 at 6:21 PM Nicolas Dechesne
 wrote:
>
> hey Zoran,
>
>
> On Mon, Mar 15, 2021 at 5:01 PM Zoran  wrote:
> >
> > > How can I instruct Yocto to execute do_image_cpio first?
> >
> > YOCTO people are entitled to answer that question. Aren't ya, INTEL folks???
> >
> > Actually, iNTEL (IOTG) is responsible for that (since YOCTO support is
> > 90% from INTEL), and I assume INTEL YOCTO people are entitled
> > answering that///
>
> Please be aware that this is a community mailing list for the Yocto
> Project, and we expect everyone to be as pleasant as possible. I don't
> think the tone of your last email is appropriate for our mailing
> lists. Please refrain yourself from such claims, or we will need to
> use moderation. Let's make sure our discussions are about technical
> content and in case of any doubt, please refer to our CoC, at
> https://www.yoctoproject.org/community/code-of-conduct/.
>
> >
> >
> > Thank you,
> > Zee (Zoran)
> > ___
> >
> > On Mon, Mar 15, 2021 at 12:17 AM p32 via lists.yoctoproject.org
> >  wrote:
> > >
> > > Thank you very much. I figured out that you can have Yocto create a 
> > > suitable U-Boot wrapper as follows (from the image recipe):
> > > IMAGE_FSTYPES = "cpio.xz.u-boot"
> > >
> > > Now there is only one last issue that I wasn't able to solve yet: I would 
> > > like Yocto to not only generate this U-Boot file but also add it to the 
> > > boot partition of a wic.gz image. I tried to extend the image recipe as 
> > > follows:
> > > IMAGE_FSTYPES = "cpio.xz.u-boot wic.gz"
> > > IMAGE_BOOT_FILES_append += 
> > > "${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cpio.xz.u-boot"
> > >
> > > Unfortunately, there is a dependency issue here. BitBake schedules the 
> > > do_image_wic task before the do_image_cpio task, which creates the u-boot 
> > > file. I tried to fix it as follows (from the image recipe):
> > > do_image_wic[depends] = "my-image-recipe:do_image_cpio"
> > >
> > > While the dependency graph acknowledges this dependency, BitBake does not 
> > > seem to care about it. Whatever I try, do_image_wic is always executed 
> > > first and, obviously, does not succeed. I think the problem is comparable 
> > > to the unsolved one outlined here:
> > > https://stackoverflow.com/questions/58954170/yocto-creating-a-dependency-for-wic-to-cpio-gz-image
> > >
> > > How can I instruct Yocto to execute do_image_cpio first?
> > >
> > >
> > >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52712): https://lists.yoctoproject.org/g/yocto/message/52712
Mute This Topic: https://lists.yoctoproject.org/mt/81241640/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How can I create a truly minimal distribution that runs entirely from RAM?

[Zoran]

I can tell you... Ross!

Please, focus on The Problem. Could you, please???

Since, I, an independent entity, am trying to help the people!

OK? Since I do not care about political IOTG development, rather than
on overall (NOT INTEL) resolution of the problem?!

Do you understand the core of the problem (since I am the only one
trying to help here)???

Or do I need to explain it more to (you and INTEL) the ground???

Did you contribute to the solution of the problem??? Or you need salt
and pepper from me?

Do you get it???

Thank you for understanding,
Zoran Stojsavljevic
___

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52711): https://lists.yoctoproject.org/g/yocto/message/52711
Mute This Topic: https://lists.yoctoproject.org/mt/81241640/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How can I create a truly minimal distribution that runs entirely from RAM?

[Zoran]

> How can I instruct Yocto to execute do_image_cpio first?

YOCTO people are entitled to answer that question. Aren't ya, INTEL folks???

Actually, iNTEL (IOTG) is responsible for that (since YOCTO support is
90% from INTEL), and I assume INTEL YOCTO people are entitled
answering that///

Thank you,
Zee (Zoran)
___

On Mon, Mar 15, 2021 at 12:17 AM p32 via lists.yoctoproject.org
 wrote:
>
> Thank you very much. I figured out that you can have Yocto create a suitable 
> U-Boot wrapper as follows (from the image recipe):
> IMAGE_FSTYPES = "cpio.xz.u-boot"
>
> Now there is only one last issue that I wasn't able to solve yet: I would 
> like Yocto to not only generate this U-Boot file but also add it to the boot 
> partition of a wic.gz image. I tried to extend the image recipe as follows:
> IMAGE_FSTYPES = "cpio.xz.u-boot wic.gz"
> IMAGE_BOOT_FILES_append += "${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cpio.xz.u-boot"
>
> Unfortunately, there is a dependency issue here. BitBake schedules the 
> do_image_wic task before the do_image_cpio task, which creates the u-boot 
> file. I tried to fix it as follows (from the image recipe):
> do_image_wic[depends] = "my-image-recipe:do_image_cpio"
>
> While the dependency graph acknowledges this dependency, BitBake does not 
> seem to care about it. Whatever I try, do_image_wic is always executed first 
> and, obviously, does not succeed. I think the problem is comparable to the 
> unsolved one outlined here:
> https://stackoverflow.com/questions/58954170/yocto-creating-a-dependency-for-wic-to-cpio-gz-image
>
> How can I instruct Yocto to execute do_image_cpio first?
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52709): https://lists.yoctoproject.org/g/yocto/message/52709
Mute This Topic: https://lists.yoctoproject.org/mt/81241640/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How can I create a truly minimal distribution that runs entirely from RAM?

[Zoran]

> 1. have Yocto generate an initramfs.cpio.xz.uboot file
> instead of just an initramfs.cpio.xz file and to

I assume this is not too hard to achieve. Somewhere in some bitbake
config file this should be added, but either me do not know that.

So, we'll both wait for this info, maybe some new variable should be
defined for such cases as initramfs, for YOCTO build system to
generate.

For example, adding INITRAMFS_CONF = "1" into local.conf (initially
this variable should be set to INITRAMFS_CONF ??= "0") in some YOCTO
defconfig file?!

> 2. modify the default environment that Yocto will
> compile into the U-Boot binary?

This, I believe, is achievable by the following steps:

  1. Taking/cloning last U-Boot from denx git;
  2. Modifying the ./include/configs/ file, introducing
the following:

  #ifdef CONFIG_SUPPORT_INITRAMFS_BOOT
  #define INITRAMFS_ENV \
  
  #else
  #define INITRAMFS_ENV ""
  #endif

3. Compile U-boot, place it on SDcard and test, to see if you
are able to make it work after rebooting the system;
4. tar again U-Boot source code with these changes, and upload
it on your server;
5. Change the U-boot recipe to be downloaded from your server!

Another approach I do not know (maybe YOCTO people do know a better
approach from inside the YOCTO build system).

Hope this helps.

Zoran
___


On Fri, Mar 12, 2021 at 10:49 PM p32 via lists.yoctoproject.org
 wrote:
>
> Thank you very much for your help on the second issue! I was unaware of the 
> fact that another mkimage call is necessary. After taking a look at the the 
> references you provided, I was able to boot the system from an initramfs.
>
> However, my current approach requires two manual steps after running Yocto: I 
> need to call mkimage on the cpio.xz file and to extend/configure the U-Boot 
> environment in the running system. Is there a way to automate this?
>
> More specifically, is it possible to...
>
> have Yocto generate an initramfs.cpio.xz.uboot file instead of just an 
> initramfs.cpio.xz file and to
> modify the default environment that Yocto will compile into the U-Boot binary?
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52706): https://lists.yoctoproject.org/g/yocto/message/52706
Mute This Topic: https://lists.yoctoproject.org/mt/81241640/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] ttyS0 is not getting generated in my Raspberry-CM3 module.

[Zoran]

> ...I'm not getting /dev/ttyS0 even after giving
> enable_uart=1 in config.txt file...

And what U R getting exactly? ls -al /dev | grep ttyS
And, also, could you do it for: ls -al /dev | grep ttyUSB (with
serial/USB cable plugged-in)?

Zee
___

On Fri, Mar 12, 2021 at 6:57 AM  wrote:
>
> Dear Team,
>
> I'm building linux-raspberry, in this I'm not getting getting /dev/ttyS0 even 
> after giving enable_uart=1 in config.txt file.
> I'm building two different kernels i.e. 4.14 and 5.4 using poky-dunell and 
> poky-sumo for each different kernel. In both of them I'm not getting ttyS0 
> terminal in /dev directory.
>
> I need to use this terminal for console purpose.
>
> Please assist me with this issue.
>
> Thanks and Regards.
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52674): https://lists.yoctoproject.org/g/yocto/message/52674
Mute This Topic: https://lists.yoctoproject.org/mt/81273312/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How can I create a truly minimal distribution that runs entirely from RAM?

[Zoran]

BBB example:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041696.html

The line:
DISTRO_FEATURES_append = " ram"

Should be:
DISTRO_FEATURES_append = " nfs"

BSP Traces for BBB (YOCTO Warrior):
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/target-bbb-platform-traces.txt

And the ash script in the U-Boot supporting above written:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/u-boot.ash#L3

Line 3 to 10.

Please, pay attention to line 1 as well!

Zee
___

On Thu, Mar 11, 2021 at 12:32 AM p32 via lists.yoctoproject.org
 wrote:
>
> Hello everyone,
>
> I am currently using this Yocto-based build setup provided by NXP to create a 
> custom Linux distribution for one of the i.MX boards. My custom image is 
> based on the core-image-minimal recipe and works fine, i.e., runs on the 
> platform as expected. However, I have to following two issues:
>
> Although core-image-minimal is documented as "A small image just capable of 
> allowing a device to boot", I can tell from the running system that it 
> contains a huge number of components that I think are not be strictly 
> necessary to boot the device. For instance, the boot log contains entries 
> about an FPGA manager framework, Bluetooth, Ethernet, KVM, USB, and a lot of 
> i.MX-specific modules such as for DMA or power management. For evaluation 
> purposes, I want to get rid of all of these and end up with a truly minimal 
> Linux system that is able to boot, schedule its tasks, and to communicate via 
> UART. How can I achieve this without losing the i.MX support, i.e., the 
> generation of a bootloader and suitable device tree files?
>
> Furthermore, I would like the minimal system to run entirely from RAM. More 
> specifically: After being started from the SD card, U-Boot should start the 
> Linux distribution via initramfs. I am able to generate some kind of 
> initramfs binary using the following changes:
> # local.conf
> INITRAMFS_IMAGE = "recipe-name"
> INITRAMFS_IMAGE_BUNDLE = "1"
> # recipe-name.bb
> IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
> PACKAGE_INSTALL = "${IMAGE_INSTALL}"
>
> However, this does not affect the generated U-Boot, which means that U-Boot 
> still tries to boot from an SD card partition. What is the "right way" to 
> make use of the Image-initramfs-board.bin or the image-board.cpio.gz files 
> that Yocto creates in this case?
>
> Any help yould be greatly appreciated.
>
> Kind regards!
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52659): https://lists.yoctoproject.org/g/yocto/message/52659
Mute This Topic: https://lists.yoctoproject.org/mt/81241640/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Assign IP address at boot time

[Zoran]

Hello,

Maybe you can stop in the U-Boot monitor, and check your environment?
=>
=> print serverip
=> print ipaddr
=> print gatewayip
=> print gw_ip

And see what and how your bootcmd and similar env variables look like?

And if you do not have defined above, to add them (according to ash
script) and try booting again?

Zee
___


On Tue, Mar 9, 2021 at 10:28 PM jchludzinski via
lists.yoctoproject.org
 wrote:
>
> Where do I assign a static IP address to my sole network interface?
>
> I tried using the Linux boot parameters (in extlinux.conf):
>
> LABEL Arria10 SOCDK SDMMC
> KERNEL ../zImage
> FDT ../socfpga_arria10_phead.dtb
> APPEND root=/dev/mmcblk0p2 rw rootwait earlyprintk console=ttyS0,115200n8 
> ip=192.168.0.101:255.255.255.0:eth0
>
> Then I tried editing: /etc/network/interfaces
>
> iface eth0 inet static
> address 192.168.0.101
> netmask 255.255.255.0
>
> Both failed. Where do I go?
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52642): https://lists.yoctoproject.org/g/yocto/message/52642
Mute This Topic: https://lists.yoctoproject.org/mt/81212608/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #av1 #armv6 #raspberrypi #neon

[Zoran]

https://yocto.yoctoproject.narkive.com/Wle40I09/gcc-on-arm

https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-TUNE_FEATURES
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-AVAILTUNES

Zee
___

On Thu, Feb 18, 2021 at 3:28 PM safouane maaloul
 wrote:
>
> Yes I will check it. Do you know how to remove callconvention-hard from 
> TUNE_FEATURES ?
>
> Best regards,
>
> Safouane
>
> Le jeu. 18 févr. 2021 à 14:52, Zoran Stojsavljevic 
>  a écrit :
>>
>> > TUNE_FEATURES= "arm armv6 vfp arm1176jzfs callconvention-hard"
>>
>> Here is an interesting reading for you, for me also:
>> https://www.yoctoproject.org/pipermail/meta-xilinx/2015-July/001060.html
>>
>> What I am getting from this reading is that you need to try with the
>> following line:
>> TUNE_FEATURES= "arm armv6 vfp arm1176jzfs"
>>
>> I guess, YOCTO people have not too much experience with armv6, nor me,
>> but this should be (I hope) generic.
>>
>> Hope this helps.
>> Zoran
>> ___
>>
>> On Thu, Feb 18, 2021 at 12:44 PM safouane maaloul
>>  wrote:
>> >
>> > This is my build configuration :
>> > Build Configuration:
>> > BB_VERSION   = "1.46.0"
>> > BUILD_SYS= "x86_64-linux"
>> > NATIVELSBSTRING  = "universal"
>> > TARGET_SYS   = "arm-poky-linux-gnueabi"
>> > MACHINE  = "raspberrypi0-wifi"
>> > DISTRO   = "poky"
>> > DISTRO_VERSION   = "3.1.5"
>> > TUNE_FEATURES= "arm armv6 vfp arm1176jzfs callconvention-hard"
>> > TARGET_FPU   = "hard"
>> > meta
>> > meta-poky
>> > meta-yocto-bsp   = "dunfell:7ea41de13774675828239b7738d3f5d70be8b1af"
>> > meta-oe
>> > meta-multimedia
>> > meta-networking
>> > meta-python  = "dunfell:5bba79488b7d393d2258d6e917f7bf7b0d7c4073"
>> > meta-raspberrypi = "dunfell:987993209716302eb8f314f69a2a3340555f94d8"
>> > meta-gstreamer1.0= "dunfell:b489b1ba084544d9c4c08f7c3b3d1c37ffa53c51"
>> >
>> > Best regards,
>> >
>> > Safouane
>> >
>> > Le mer. 17 févr. 2021 à 13:24, Zoran Stojsavljevic 
>> >  a écrit :
>> >>
>> >> So, what is your MACHINE variable set to?
>> >>
>> >> Maybe knowing that, somebody can help.
>> >>
>> >> Zee
>> >
>> >
>> >
>> > --
>> > SAFOUANE MAALOUL
>> > maaloulsafou...@gmail.com
>> >
>
>
>
> --
> SAFOUANE MAALOUL
> maaloulsafou...@gmail.com
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52386): https://lists.yoctoproject.org/g/yocto/message/52386
Mute This Topic: https://lists.yoctoproject.org/mt/80700217/21656
Mute #raspberrypi:https://lists.yoctoproject.org/g/yocto/mutehashtag/raspberrypi
Mute #av1:https://lists.yoctoproject.org/g/yocto/mutehashtag/av1
Mute #neon:https://lists.yoctoproject.org/g/yocto/mutehashtag/neon
Mute #armv6:https://lists.yoctoproject.org/g/yocto/mutehashtag/armv6
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #av1 #armv6 #raspberrypi #neon

[Zoran]

> TUNE_FEATURES= "arm armv6 vfp arm1176jzfs callconvention-hard"

Here is an interesting reading for you, for me also:
https://www.yoctoproject.org/pipermail/meta-xilinx/2015-July/001060.html

What I am getting from this reading is that you need to try with the
following line:
TUNE_FEATURES= "arm armv6 vfp arm1176jzfs"

I guess, YOCTO people have not too much experience with armv6, nor me,
but this should be (I hope) generic.

Hope this helps.
Zoran
___

On Thu, Feb 18, 2021 at 12:44 PM safouane maaloul
 wrote:
>
> This is my build configuration :
> Build Configuration:
> BB_VERSION   = "1.46.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal"
> TARGET_SYS   = "arm-poky-linux-gnueabi"
> MACHINE  = "raspberrypi0-wifi"
> DISTRO   = "poky"
> DISTRO_VERSION   = "3.1.5"
> TUNE_FEATURES= "arm armv6 vfp arm1176jzfs callconvention-hard"
> TARGET_FPU   = "hard"
> meta
> meta-poky
> meta-yocto-bsp   = "dunfell:7ea41de13774675828239b7738d3f5d70be8b1af"
> meta-oe
> meta-multimedia
> meta-networking
> meta-python  = "dunfell:5bba79488b7d393d2258d6e917f7bf7b0d7c4073"
> meta-raspberrypi = "dunfell:987993209716302eb8f314f69a2a3340555f94d8"
> meta-gstreamer1.0= "dunfell:b489b1ba084544d9c4c08f7c3b3d1c37ffa53c51"
>
> Best regards,
>
> Safouane
>
> Le mer. 17 févr. 2021 à 13:24, Zoran Stojsavljevic 
>  a écrit :
>>
>> So, what is your MACHINE variable set to?
>>
>> Maybe knowing that, somebody can help.
>>
>> Zee
>
>
>
> --
> SAFOUANE MAALOUL
> maaloulsafou...@gmail.com
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52382): https://lists.yoctoproject.org/g/yocto/message/52382
Mute This Topic: https://lists.yoctoproject.org/mt/80700217/21656
Mute #raspberrypi:https://lists.yoctoproject.org/g/yocto/mutehashtag/raspberrypi
Mute #av1:https://lists.yoctoproject.org/g/yocto/mutehashtag/av1
Mute #neon:https://lists.yoctoproject.org/g/yocto/mutehashtag/neon
Mute #armv6:https://lists.yoctoproject.org/g/yocto/mutehashtag/armv6
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #av1 #armv6 #raspberrypi #neon

[Zoran]

So, what is your MACHINE variable set to?

Maybe knowing that, somebody can help.

Zee

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52362): https://lists.yoctoproject.org/g/yocto/message/52362
Mute This Topic: https://lists.yoctoproject.org/mt/80700217/21656
Mute #raspberrypi:https://lists.yoctoproject.org/g/yocto/mutehashtag/raspberrypi
Mute #av1:https://lists.yoctoproject.org/g/yocto/mutehashtag/av1
Mute #neon:https://lists.yoctoproject.org/g/yocto/mutehashtag/neon
Mute #armv6:https://lists.yoctoproject.org/g/yocto/mutehashtag/armv6
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Enabling Serial console via uart1(serial1) in cm3(rpi3) kernel 5.4. #cm3 #dunfell

[Zoran]

Hello Prashant,

Can you telnet to the target? And issue the following: cat /proc/cmdline

And post it here?

In the meantime, you can verify the issue with:
https://www.raspberrypi.org/documentation/configuration/cmdline-txt.md

Hope this helps,
Zee
___

On Thu, Feb 11, 2021 at 2:24 PM  wrote:
>
> Dear Team,
>
> I'm using poky-dunfell  to get os for my raspberrypi-cm3.
> I need to get the stdout data to serial console via uart1(serial1).
>
> I given change in my cmdline.txt as:   dwc_otg.lpm_enable=0 
> console=serial1,115200 consol=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 
> rootwait kgdboc=serial0,115200
> and in  config.txt  as:
>
> dtoverlay=pi3-disable-bt
> dtparam=uart1=on
> # Enable UART
> enable_uart=1
> dtoverlay=uart1,txd1_pin=32,rxd1_pin=33
> core_freq=250
> force_turbo=1
>
> then also I'm not getting the serial output in my serial1.
>
> Please help to resolve this issue.
>
> Thanks & Regards.
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52295): https://lists.yoctoproject.org/g/yocto/message/52295
Mute This Topic: https://lists.yoctoproject.org/mt/80556996/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Mute #cm3:https://lists.yoctoproject.org/g/yocto/mutehashtag/cm3
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] Let me tell you how I really feel. Zero filter. If you need meta-python2, you need to become a maintainer. Immediately. Period.

[Zoran]

> This sounds like a good idea to me and I have admin
> right so I've given you access :)

+1

Zee
___

On Tue, Feb 2, 2021 at 10:33 AM Richard Purdie
 wrote:
>
> On Mon, 2021-02-01 at 15:40 +0100, Martin Jansa wrote:
> > can I get the write access to meta-python2 as mentioned above?
> >
> > I have 2 fixes to make it parse able with latest oe-core:
> > https://lists.openembedded.org/g/openembedded-devel/message/89201
> > https://lists.openembedded.org/g/openembedded-devel/message/89200
> >
> > to fix issues discussed in:
> > https://github.com/openembedded/openembedded-core/commit/fd6a007efa7cb45101a66f294af81d9d33bb3fab#commitcomment-46565284
> > https://lists.openembedded.org/g/openembedded-core/message/147477
> > https://lists.openembedded.org/g/openembedded-core/message/147514
>
> This sounds like a good idea to me and I have admin right so I've given
> you access :)
>
> Cheers,
>
> Richard
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52186): https://lists.yoctoproject.org/g/yocto/message/52186
Mute This Topic: https://lists.yoctoproject.org/mt/80286758/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

> Interestingly I don't have any header file on the target:

Yes, since U R compiling target modules on the HOST GCC cross compiler
(using YOCTO bitbake scripts).

I ALWAYS keep full target setup, with as many tools as I can to do
target module compiling, and other stuff.

YOCTO is after all YOCTO (doing host and target prep), but I like to
have total control over the target myself. ;-)

To include target kernel-dev, please, use the local.conf similar to one here:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-dunfell/local.conf_kernel

Zee
___


On Wed, Jan 20, 2021 at 12:20 PM Zoltan Kerenyi Nagy
 wrote:
>
> Hi Zoran,
>
> Interestingly I don't have any header file on the target:
>
> # find / -name *.h
>
> #
>
>
> --
> Zolee
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52057): https://lists.yoctoproject.org/g/yocto/message/52057
Mute This Topic: https://lists.yoctoproject.org/mt/79498728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

Zolee,

You need also to do on the target platform the following (very first time):

You must have header files, at minimum, in target's : /usr/src/$(uname -r)/

Or for yocto (AFAIK), maybe: /usr/src/kernel/$(uname -r)/

To prepare out-of-tree device driver compilation in /usr/src/kernel/$(uname -r)/

/usr/src/kernel/$(uname -r)$ make oldconfig && make prepare
/usr/src/kernel/$(uname -r)$ sudo make scripts prepare

Zee
___

On Tue, Jan 19, 2021 at 3:48 PM Zoltan Kerenyi Nagy
 wrote:
>
> My modeles.dep file looks like this on target:
>
> kernel/fs/nfs/flexfilelayout/nfs_layout_flexfiles.ko:
> kernel/crypto/echainiv.ko:
> kernel/crypto/gcm.ko:
> kernel/crypto/ccm.ko:
> kernel/crypto/ghash-generic.ko:
> kernel/drivers/char/hw_random/rng-core.ko:
> kernel/net/ipv4/tcp_bic.ko:
> kernel/net/ipv4/tcp_westwood.ko:
> kernel/net/ipv4/tcp_htcp.ko:
> kernel/net/bridge/br_netfilter.ko:
> kernel/net/wireless/cfg80211.ko: kernel/net/rfkill/rfkill.ko
> kernel/net/mac80211/mac80211.ko: kernel/net/wireless/cfg80211.ko 
> kernel/net/rfkill/rfkill.ko
> kernel/net/rfkill/rfkill.ko:
> kernel/net/rfkill/rfkill-regulator.ko: kernel/net/rfkill/rfkill.ko
> kernel/net/rfkill/rfkill-gpio.ko: kernel/net/rfkill/rfkill.ko
> extra/cdc-ncm.ko: extra/cdc-wdm.ko
> extra/hello.ko:
> extra/cdc-wdm.ko:
> extra/huawei_cdc_ncm.ko: extra/cdc-wdm.ko
>
> --
> Zolee
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52051): https://lists.yoctoproject.org/g/yocto/message/52051
Mute This Topic: https://lists.yoctoproject.org/mt/79498728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] insmod - huawei E3372h kernel module

[Zoran]

Forwarded to r...@burtonini.com .

Thank you,
Zoran/Zee

-- Forwarded message -
From: Zoran via lists.yoctoproject.org

Date: Tue, Jan 19, 2021 at 2:23 PM
Subject: Re: [yocto] insmod - huawei E3372h kernel module
To: Zoltan Kerenyi Nagy , Burton, Ross

Cc: Yocto-mailing-list 

> As far as I understand the KERNEL_MODULE_AUTOLOAD directive will
> populate the /etc/modules file, however, after bitbaking, on the device there
> is no /etc/modules file or folder but another folder:
>
> root@barix-ipam400:~# ls /lib/modules/4.10.0/extra/
> cdc-ncm.ko cdc-wdm.ko hello.ko   huawei_cdc_ncm.ko

Hello Ross,

Any comment from you on the target module configuration?

My understanding is the same, the YOCTO building system should somehow
create targets' /etc/modules file, since every reboot should repeat
the order of modules loading (read from the same).

Thank you,
Zoran
___

On Tue, Jan 19, 2021 at 2:00 PM Zoltan Kerenyi Nagy
 wrote:
>
> I don have a recipie for /etc/modules
>
> To my understanding this order will cause the load:
>
> KERNEL_MODULE_AUTOLOAD += "ncm_driver"KERNEL_MODULE_PROBECONF += 
> "ncm_driver"cdc_ncm = "options ncm_driver 
> iProduct=USB_Host_Driver_for_Network_Control_Model iManufacturer=NCM"
>
> KERNEL_MODULE_AUTOLOAD += "wmc_device_managment"KERNEL_MODULE_PROBECONF += 
> "wmc_device"cdc_wdm = "options wmc_device 
> iProduct=USB_CDC_WCM_Device_Management iManufacturer=WMC"
>
> KERNEL_MODULE_AUTOLOAD += "lte"KERNEL_MODULE_PROBECONF += "lte"huawei_cdc_ncm 
> = "options lte iProduct=E3372h iManufacturer=Huawei"
>
> As far as I understand the KERNEL_MODULE_AUTOLOAD directive will populate the 
> /etc/modules file, however, after bitbaking, on the device there is no 
> /etc/modules file or folder but another folder:
>
> root@barix-ipam400:~# ls /lib/modules/4.10.0/extra/
> cdc-ncm.ko cdc-wdm.ko hello.ko   huawei_cdc_ncm.ko
>
>
>
> --
> Zolee
>
>



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52042): https://lists.yoctoproject.org/g/yocto/message/52042
Mute This Topic: https://lists.yoctoproject.org/mt/79498728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

> As far as I understand the KERNEL_MODULE_AUTOLOAD directive will
> populate the /etc/modules file, however, after bitbaking, on the device there
> is no /etc/modules file or folder but another folder:
>
> root@barix-ipam400:~# ls /lib/modules/4.10.0/extra/
> cdc-ncm.ko cdc-wdm.ko hello.ko   huawei_cdc_ncm.ko

Hello Ross,

Any comment from you on the target module configuration?

My understanding is the same, the YOCTO building system should somehow
create targets' /etc/modules file, since every reboot should repeat
the order of modules loading (read from the same).

Thank you,
Zoran
___

On Tue, Jan 19, 2021 at 2:00 PM Zoltan Kerenyi Nagy
 wrote:
>
> I don have a recipie for /etc/modules
>
> To my understanding this order will cause the load:
>
> KERNEL_MODULE_AUTOLOAD += "ncm_driver"KERNEL_MODULE_PROBECONF += 
> "ncm_driver"cdc_ncm = "options ncm_driver 
> iProduct=USB_Host_Driver_for_Network_Control_Model iManufacturer=NCM"
>
> KERNEL_MODULE_AUTOLOAD += "wmc_device_managment"KERNEL_MODULE_PROBECONF += 
> "wmc_device"cdc_wdm = "options wmc_device 
> iProduct=USB_CDC_WCM_Device_Management iManufacturer=WMC"
>
> KERNEL_MODULE_AUTOLOAD += "lte"KERNEL_MODULE_PROBECONF += "lte"huawei_cdc_ncm 
> = "options lte iProduct=E3372h iManufacturer=Huawei"
>
> As far as I understand the KERNEL_MODULE_AUTOLOAD directive will populate the 
> /etc/modules file, however, after bitbaking, on the device there is no 
> /etc/modules file or folder but another folder:
>
> root@barix-ipam400:~# ls /lib/modules/4.10.0/extra/
> cdc-ncm.ko cdc-wdm.ko hello.ko   huawei_cdc_ncm.ko
>
>
>
> --
> Zolee
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52041): https://lists.yoctoproject.org/g/yocto/message/52041
Mute This Topic: https://lists.yoctoproject.org/mt/79498728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

> KERNEL_MODULE_AUTOLOAD += "ncm_driver"KERNEL_MODULE_PROBECONF
> += "ncm_driver"*cdc_ncm* = "options ncm_driver iProduct=
> USB_Host_Driver_for_Network_Control_Model iManufacturer=NCM"

> KERNEL_MODULE_AUTOLOAD += "wmc_device_managment"
> KERNEL_MODULE_PROBECONF += "wmc_device"*cdc_wdm* = "options wmc_device
> iProduct=USB_CDC_WCM_Device_Management iManufacturer=WMC"

> KERNEL_MODULE_AUTOLOAD += "lte"KERNEL_MODULE_PROBECONF +=
> "lte"*huawei_cdc_ncm* = "options lte iProduct=E3372h iManufacturer=Huawei"

Here is the exact loading order, outlined in target's /etc/modules :

debian@arm:~$ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

*cdc_ncm*
*cdc_wdm*
*huawei_cdc_ncm*

You need to, using YOCTO recipes, to modify /etc/modules file to look
as shown above, while bitbaking the target.

Zoran
___


On Sun, Jan 17, 2021 at 1:34 PM Zoltan Kerenyi Nagy <
kerenyi.nagy.zol...@gmail.com> wrote:

> Hi,
>
> I contacted the kernel module (cdc_ncm) developper, and he suggested to
> change/experiment the kernel module load order.
>
> I thought if I specify this way: KERNEL_MODULE_AUTOLOAD +=
> "ncm_driver"KERNEL_MODULE_PROBECONF += "ncm_driver"cdc_ncm = "options
> ncm_driver iProduct=USB_Host_Driver_for_Network_Control_Model
> iManufacturer=NCM" KERNEL_MODULE_AUTOLOAD +=
> "wmc_device_managment"KERNEL_MODULE_PROBECONF += "wmc_device"cdc_wdm =
> "options wmc_device iProduct=USB_CDC_WCM_Device_Management
> iManufacturer=WMC" KERNEL_MODULE_AUTOLOAD += "lte"KERNEL_MODULE_PROBECONF
> += "lte"huawei_cdc_ncm = "options lte iProduct=E3372h iManufacturer=Huawei"
> Than this means the order of loading too. Is there any additional feature
> in Yocto that can interfere and set the exact kernel module loading order?
>
> Thanks,
>
>
> --
> Zolee
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52028): https://lists.yoctoproject.org/g/yocto/message/52028
Mute This Topic: https://lists.yoctoproject.org/mt/79498728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

Even better:

debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/usb$ lsmod
Module  Size  Used by


*huawei_cdc_ncm 16384  0cdc_wdm24576  1
huawei_cdc_ncmcdc_ncm32768  1 huawei_cdc_ncm*
spidev 20480  0
evdev  20480  1
usb_f_acm  20480  2
u_serial   24576  3 usb_f_acm
usb_f_ncm  24576  2
usb_f_rndis24576  4
u_ether24576  2 usb_f_ncm,usb_f_rndis
libcomposite   49152  16 usb_f_acm,usb_f_ncm,usb_f_rndis
8021q  24576  0
garp   16384  1 8021q
stp16384  1 garp
mrp16384  1 8021q
llc16384  2 garp,stp
iptable_nat16384  0
nf_nat 28672  1 iptable_nat
nf_conntrack   98304  1 nf_nat
nf_defrag_ipv6 20480  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
iptable_mangle 16384  0
iptable_filter 16384  0
mikrobus_test  16384  1
mikrobus   32768  1 mikrobus_test
ip_tables  24576  3 iptable_mangle,iptable_filter,iptable_nat
x_tables   24576  3 iptable_mangle,ip_tables,iptable_filter
debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/usb$

Zolee, U need (based upon this lsmod on my target) to solve the problem
(homework for you).

( U owe me double Glenmorangie on rocks! )

Zee
___

On Fri, Jan 8, 2021 at 1:49 PM Zoran via lists.yoctoproject.org
 wrote:

> > Does it mean that it will never ever work?
> > Could you please try this one? This might match your kernel version:
> >
> https://elixir.bootlin.com/linux/v5.8.18/source/drivers/net/usb/huawei_cdc_ncm.c
> >
> > Zolee
>
> [vuser@fedora33-ssd usb]$ kdiff3 huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
> org.kde.kdiff3: "Loading A: /home/vuser/projects/
> kernel.bb/bb-kernel-5.8.18-bone24/KERNEL/drivers/net/usb/huawei_cdc_ncm_5.8.18.c
> "
> "/proc/1715042/root"
> org.kde.kdiff3: Loading B:  "/home/vuser/projects/
> kernel.bb/bb-kernel-5.8.18-bone24/KERNEL/drivers/net/usb/huawei_cdc_ncm.c"
> [vuser@fedora33-ssd usb]$ diff huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
> [vuser@fedora33-ssd usb]$ diff -c huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
> [vuser@fedora33-ssd usb]$ diff -s huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
> Files huawei_cdc_ncm_5.8.18.c and huawei_cdc_ncm.c are identical
> [vuser@fedora33-ssd usb]$
>
> This is the same modul. You need to try to built-in this one in the kernel.
>
> Obviously, you need to load some basic module, this one is dependent upon
> (my best guess).
>
> This one is missing. Maybe this one!
>
> $ cat config-5.8.18-bone24 | grep HUAWEI
> *# CONFIG_NET_VENDOR_HUAWEI is not set*
> CONFIG_USB_NET_HUAWEI_CDC_NCM=m
>
> Zee
> ___
>
> On Fri, Jan 8, 2021 at 1:29 PM Zoltan Kerenyi Nagy <
> kerenyi.nagy.zol...@gmail.com> wrote:
>
>> Does it mean that it will never ever work?
>>
>> Could you please try this one? This might match your kernel version:
>>
>>
>> https://elixir.bootlin.com/linux/v5.8.18/source/drivers/net/usb/huawei_cdc_ncm.c
>> --
>> Zolee
>>
>>
>>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51951): https://lists.yoctoproject.org/g/yocto/message/51951
Mute This Topic: https://lists.yoctoproject.org/mt/79498728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

> Does it mean that it will never ever work?
> Could you please try this one? This might match your kernel version:
>
https://elixir.bootlin.com/linux/v5.8.18/source/drivers/net/usb/huawei_cdc_ncm.c
>
> Zolee

[vuser@fedora33-ssd usb]$ kdiff3 huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
org.kde.kdiff3: "Loading A: /home/vuser/projects/
kernel.bb/bb-kernel-5.8.18-bone24/KERNEL/drivers/net/usb/huawei_cdc_ncm_5.8.18.c
"
"/proc/1715042/root"
org.kde.kdiff3: Loading B:  "/home/vuser/projects/
kernel.bb/bb-kernel-5.8.18-bone24/KERNEL/drivers/net/usb/huawei_cdc_ncm.c"
[vuser@fedora33-ssd usb]$ diff huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
[vuser@fedora33-ssd usb]$ diff -c huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
[vuser@fedora33-ssd usb]$ diff -s huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
Files huawei_cdc_ncm_5.8.18.c and huawei_cdc_ncm.c are identical
[vuser@fedora33-ssd usb]$

This is the same modul. You need to try to built-in this one in the kernel.

Obviously, you need to load some basic module, this one is dependent upon
(my best guess).

This one is missing. Maybe this one!

$ cat config-5.8.18-bone24 | grep HUAWEI
*# CONFIG_NET_VENDOR_HUAWEI is not set*
CONFIG_USB_NET_HUAWEI_CDC_NCM=m

Zee
___

On Fri, Jan 8, 2021 at 1:29 PM Zoltan Kerenyi Nagy <
kerenyi.nagy.zol...@gmail.com> wrote:

> Does it mean that it will never ever work?
>
> Could you please try this one? This might match your kernel version:
>
>
> https://elixir.bootlin.com/linux/v5.8.18/source/drivers/net/usb/huawei_cdc_ncm.c
> --
> Zolee
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51949): https://lists.yoctoproject.org/g/yocto/message/51949
Mute This Topic: https://lists.yoctoproject.org/mt/79498728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

> insmod /lib/modules/4.10.0/extra/huawei_cdc_ncm.ko
> insmod: can't insert '/lib/modules/4.10.0/extra/huawei_cdc_ncm.ko': *unknown
symbol in module, or unknown parameter*

On my target (Pocket Bone):

debian@arm:/lib/modules/5.8.18-bone24/kernel$ find . -name huawei_cdc_ncm*
./drivers/net/usb/huawei_cdc_ncm.ko.xz
debian@arm:/lib/modules/5.8.18-bone24/kernel$ cd ./drivers/net/usb/






*debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/sudo insmod
huawei_cdc_ncm.ko.xz[ 6554.826591] huawei_cdc_ncm: Unknown symbol
cdc_ncm_tx_fixup (err -2)[ 6554.833115] huawei_cdc_ncm: Unknown symbol
cdc_ncm_bind_common (err -2)[ 6554.841745] huawei_cdc_ncm: Unknown symbol
usb_cdc_wdm_register (err -2)[ 6554.849680] huawei_cdc_ncm: Unknown symbol
cdc_ncm_unbind (err -2)[ 6554.857042] huawei_cdc_ncm: Unknown symbol
cdc_ncm_rx_fixup (err -2)insmod: ERROR: could not insert module
huawei_cdc_ncm.ko.xz: Unknown symbol in module*
debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/usb$ uname -a
Linux arm 5.8.18-bone24 #1 PREEMPT Sun Dec 13 19:15:04 CET 2020 armv7l
GNU/Linux
debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/usb$ cat
/etc/debian_version
10.7
debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/usb$

Good Luck!
Zoran
___


On Fri, Jan 8, 2021 at 12:22 PM Zoltan Kerenyi Nagy <
kerenyi.nagy.zol...@gmail.com> wrote:

> No success :-(
>
> insmod /lib/modules/4.10.0/extra/huawei_cdc_ncm.ko
> insmod: can't insert '/lib/modules/4.10.0/extra/huawei_cdc_ncm.ko': *unknown
> symbol in module, or unknown parameter*
>
> --
> Zolee
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51944): https://lists.yoctoproject.org/g/yocto/message/51944
Mute This Topic: https://lists.yoctoproject.org/mt/79498728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Unable to extract tar file #dunfell #yocto

[Zoran]

Just maybe... This web pointer can help you!

https://stackoverflow.com/questions/46448682/cmake-error-the-source-does-not-appear-to-contain-cmakelists-txt/52068568

Zoran
___

On Fri, Jan 8, 2021 at 7:18 AM Vijay Rakesh Munganda
 wrote:
>
> Anyone, please suggest.
>
> Thanks,
> Vijay Rakesh
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51929): https://lists.yoctoproject.org/g/yocto/message/51929
Mute This Topic: https://lists.yoctoproject.org/mt/79494357/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

> Since some variables and functions are exported in .c files, and not
> propagated into related .h files. And then this makes some confusion
> while having OOT drivers.

Quite an opposite. It must be defined to be exported, and to appear in
Module.symvers .

If it is NOT defined as exported (EXPORT_SYMBOL, EXPORT_SYMBOL_GPL),
it will behave as from your initial post, if the driver is defined as
a module.

The example for this behaviour is here:
https://github.com/ZoranStojsavljevic/mikrobus/blob/mikrobusv2-debug/mikrobus_core.c#L447

Symbol regulator_register_always_on (it is NOT exported at all,
neither in include/linux/regulator/fixed.h, neither in
drivers/regulator/fixed-helper.c).

So the mikrobus driver, being a module, produces such an error:
unknown symbol in module, or unknown parameter .
___

Sorry for the confusion. :(

Zoran
___


On Thu, Jan 7, 2021 at 6:55 PM Zoltan Kerenyi Nagy
 wrote:
>
> Yep, the best would be if the driver burned into the root filesystem with 
> bitbake. I dont want to compile that driver on the device. I'll modifile the 
> makefile tomorrow, thanks
>
> On 2021. Jan 7., Thu at 18:20, Zoran Stojsavljevic 
>  wrote:
>>
>> If I think more... For driver development the Out Of (OOT) Tree driver
>> is a must, and so far the most efficient way is to have native tool
>> environment presence on the target, so the quick recompilation of the
>> module is a must/should be achieved... It is a pain doing this on the
>> host using cross compilation, or even building it to the kernel.
>>
>> Once the driver is stable, then it should be built-in with Y in the
>> kernel, changing the YOCTO kernel defconfig (not the topic for this
>> problem, there is a good explanation how to do that in YOCTO manuals).
>>
>> If the driver is out of shelf, it should be recompiled as built-in the 
>> kernel.
>>
>> There are differences between having an OOT driver versus a built-in driver.
>>
>> Since some variables and functions are exported in .c files, and not
>> propagated into related .h files. And then this makes some confusion
>> while having OOT drivers.
>>
>> Zoran
>> ___
>>
>> On Thu, Jan 7, 2021 at 4:27 PM Zoran via lists.yoctoproject.org
>>  wrote:
>> >
>> > No, no... I did not mean in the makefile to change m to y.
>> >
>> > Please, maybe you can try to set your makefile to lookalike as these ones:
>> > https://github.com/ZoranStojsavljevic/mikrobus/blob/mikrobusv2/Makefile
>> > https://github.com/ZoranStojsavljevic/mikrobus/blob/mikrobusv2-debug/Makefile
>> >
>> > Zoran
>> > ___
>> >
>> > On Thu, Jan 7, 2021 at 4:17 PM Zoltan Kerenyi Nagy
>> >  wrote:
>> > >
>> > > Hi Zoran,
>> > >
>> > > Thanks, I modified the Makefile:
>> > >
>> > > obj-m := huawei_cdc_ncm.o
>> > > Kconfig (obj-y := huawei_cdc_ncm.o)
>> > > SRC := $(shell pwd)
>> > > all:
>> > > $(MAKE) -C $(KERNEL_SRC) M=$(SRC)
>> > > modules_install:
>> > > $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
>> > > clean:
>> > > rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c
>> > > rm -f Module.markers Module.symvers modules.order
>> > > rm -rf .tmp_versions Modules.symvers
>> > >
>> > > but this is the error:
>> > >
>> > > ERROR: huawei-1.1-r0 do_configure: oe_runmake failed
>> > > ERROR: huawei-1.1-r0 do_configure: Function failed: do_configure (log 
>> > > file is located at 
>> > > /home/kerenyiz/oe-core/build/tmp-glibc/work/barix_ipam400-oe-linux-gnueabi/huawei/1.1-r0/temp/log.do_configure.4488)
>> > > ERROR: Logfile of failure stored in: 
>> > > /home/kerenyiz/oe-core/build/tmp-glibc/work/barix_ipam400-oe-linux-gnueabi/huawei/1.1-r0/temp/log.do_configure.4488
>> > > Log data follows:
>> > > | DEBUG: Executing shell function do_configure
>> > > | NOTE: make 
>> > > KERNEL_SRC=/home/kerenyiz/oe-core/build/tmp-glibc/work-shared/barix-ipam400/kernel-source
>> > >  clean
>> > > | ERROR: oe_runmake failed
>> > > | Makefile:2: *** empty variable name.  Stop.
>> > > | ERROR: Function failed: do_configure (log file is located at 
>> > > /home/kerenyiz/oe-core/build/tmp-glibc/work/barix_ipam400-oe-linux-gnueabi/huawei/1.1-r0/temp/log.do_configure.4488)
>> > > ERROR: Task 
>> > > (/home/kerenyiz/oe-core/build/../stuff/meta-barix-sdk/recipes-z/kernel-modules/huawei/huawei_1.1.bb:do_configure)
>> >

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

If I think more... For driver development the Out Of (OOT) Tree driver
is a must, and so far the most efficient way is to have native tool
environment presence on the target, so the quick recompilation of the
module is a must/should be achieved... It is a pain doing this on the
host using cross compilation, or even building it to the kernel.

Once the driver is stable, then it should be built-in with Y in the
kernel, changing the YOCTO kernel defconfig (not the topic for this
problem, there is a good explanation how to do that in YOCTO manuals).

If the driver is out of shelf, it should be recompiled as built-in the kernel.

There are differences between having an OOT driver versus a built-in driver.

Since some variables and functions are exported in .c files, and not
propagated into related .h files. And then this makes some confusion
while having OOT drivers.

Zoran
___

On Thu, Jan 7, 2021 at 4:27 PM Zoran via lists.yoctoproject.org
 wrote:
>
> No, no... I did not mean in the makefile to change m to y.
>
> Please, maybe you can try to set your makefile to lookalike as these ones:
> https://github.com/ZoranStojsavljevic/mikrobus/blob/mikrobusv2/Makefile
> https://github.com/ZoranStojsavljevic/mikrobus/blob/mikrobusv2-debug/Makefile
>
> Zoran
> ___
>
> On Thu, Jan 7, 2021 at 4:17 PM Zoltan Kerenyi Nagy
>  wrote:
> >
> > Hi Zoran,
> >
> > Thanks, I modified the Makefile:
> >
> > obj-m := huawei_cdc_ncm.o
> > Kconfig (obj-y := huawei_cdc_ncm.o)
> > SRC := $(shell pwd)
> > all:
> > $(MAKE) -C $(KERNEL_SRC) M=$(SRC)
> > modules_install:
> > $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
> > clean:
> > rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c
> > rm -f Module.markers Module.symvers modules.order
> > rm -rf .tmp_versions Modules.symvers
> >
> > but this is the error:
> >
> > ERROR: huawei-1.1-r0 do_configure: oe_runmake failed
> > ERROR: huawei-1.1-r0 do_configure: Function failed: do_configure (log file 
> > is located at 
> > /home/kerenyiz/oe-core/build/tmp-glibc/work/barix_ipam400-oe-linux-gnueabi/huawei/1.1-r0/temp/log.do_configure.4488)
> > ERROR: Logfile of failure stored in: 
> > /home/kerenyiz/oe-core/build/tmp-glibc/work/barix_ipam400-oe-linux-gnueabi/huawei/1.1-r0/temp/log.do_configure.4488
> > Log data follows:
> > | DEBUG: Executing shell function do_configure
> > | NOTE: make 
> > KERNEL_SRC=/home/kerenyiz/oe-core/build/tmp-glibc/work-shared/barix-ipam400/kernel-source
> >  clean
> > | ERROR: oe_runmake failed
> > | Makefile:2: *** empty variable name.  Stop.
> > | ERROR: Function failed: do_configure (log file is located at 
> > /home/kerenyiz/oe-core/build/tmp-glibc/work/barix_ipam400-oe-linux-gnueabi/huawei/1.1-r0/temp/log.do_configure.4488)
> > ERROR: Task 
> > (/home/kerenyiz/oe-core/build/../stuff/meta-barix-sdk/recipes-z/kernel-modules/huawei/huawei_1.1.bb:do_configure)
> >  failed with exit code '1'
> > NOTE: Tasks Summary: Attempted 3880 tasks of which 3873 didn't need to be 
> > rerun and 1 failed.
> >
> > On Thu, 7 Jan 2021 at 16:03, Zoran Stojsavljevic 
> >  wrote:
> >>
> >> Hello Zoltan,
> >>
> >> > root@barix-ipam400:~# insmod /lib/modules/4.10.0/extra/huawei_cdc_ncm.ko
> >> > insmod: can't insert '/lib/modules/4.10.0/extra/huawei_cdc_ncm.ko': 
> >> > unknown symbol in module, or unknown parameter
> >>
> >> Please, try to set Kconfig (obj-y := huawei_cdc_ncm.o) to y, I guess
> >> 99.9% that the kernel compilation (actually, driver compilation) will
> >> pass.
> >>
> >> I think YOCTO (recipe) behaves perfectly correctly.
> >>
> >> Other approach: try to compile the same module with Makefile above on
> >> the target.
> >>
> >> (my two cent thoughts)
> >>
> >> Zoran
> >> ___
> >>
> >> On Thu, Jan 7, 2021 at 2:46 PM Zoltan Kerenyi Nagy
> >>  wrote:
> >> >
> >> > Hi Folks,
> >> >
> >> > I bitbaked a Huawei E3372h driver into the distro with this recipe file:
> >> >
> >> > SUMMARY = "Huawei Stick kernel module"
> >> > LICENSE = "CLOSED"
> >> >
> >> > inherit module
> >> >
> >> > SRC_URI = "file://Makefile \
> >> >file://huawei_cdc_ncm.c \
> >> >   "
> >> >
> >> > S = "${WORKDIR}"
> >> >
> >> > The makefile looks like this:
> >> >
> >> > obj-m := huawei_cdc_ncm.o
> >> 

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

No, no... I did not mean in the makefile to change m to y.

Please, maybe you can try to set your makefile to lookalike as these ones:
https://github.com/ZoranStojsavljevic/mikrobus/blob/mikrobusv2/Makefile
https://github.com/ZoranStojsavljevic/mikrobus/blob/mikrobusv2-debug/Makefile

Zoran
___

On Thu, Jan 7, 2021 at 4:17 PM Zoltan Kerenyi Nagy
 wrote:
>
> Hi Zoran,
>
> Thanks, I modified the Makefile:
>
> obj-m := huawei_cdc_ncm.o
> Kconfig (obj-y := huawei_cdc_ncm.o)
> SRC := $(shell pwd)
> all:
> $(MAKE) -C $(KERNEL_SRC) M=$(SRC)
> modules_install:
> $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
> clean:
> rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c
> rm -f Module.markers Module.symvers modules.order
> rm -rf .tmp_versions Modules.symvers
>
> but this is the error:
>
> ERROR: huawei-1.1-r0 do_configure: oe_runmake failed
> ERROR: huawei-1.1-r0 do_configure: Function failed: do_configure (log file is 
> located at 
> /home/kerenyiz/oe-core/build/tmp-glibc/work/barix_ipam400-oe-linux-gnueabi/huawei/1.1-r0/temp/log.do_configure.4488)
> ERROR: Logfile of failure stored in: 
> /home/kerenyiz/oe-core/build/tmp-glibc/work/barix_ipam400-oe-linux-gnueabi/huawei/1.1-r0/temp/log.do_configure.4488
> Log data follows:
> | DEBUG: Executing shell function do_configure
> | NOTE: make 
> KERNEL_SRC=/home/kerenyiz/oe-core/build/tmp-glibc/work-shared/barix-ipam400/kernel-source
>  clean
> | ERROR: oe_runmake failed
> | Makefile:2: *** empty variable name.  Stop.
> | ERROR: Function failed: do_configure (log file is located at 
> /home/kerenyiz/oe-core/build/tmp-glibc/work/barix_ipam400-oe-linux-gnueabi/huawei/1.1-r0/temp/log.do_configure.4488)
> ERROR: Task 
> (/home/kerenyiz/oe-core/build/../stuff/meta-barix-sdk/recipes-z/kernel-modules/huawei/huawei_1.1.bb:do_configure)
>  failed with exit code '1'
> NOTE: Tasks Summary: Attempted 3880 tasks of which 3873 didn't need to be 
> rerun and 1 failed.
>
> On Thu, 7 Jan 2021 at 16:03, Zoran Stojsavljevic 
>  wrote:
>>
>> Hello Zoltan,
>>
>> > root@barix-ipam400:~# insmod /lib/modules/4.10.0/extra/huawei_cdc_ncm.ko
>> > insmod: can't insert '/lib/modules/4.10.0/extra/huawei_cdc_ncm.ko': 
>> > unknown symbol in module, or unknown parameter
>>
>> Please, try to set Kconfig (obj-y := huawei_cdc_ncm.o) to y, I guess
>> 99.9% that the kernel compilation (actually, driver compilation) will
>> pass.
>>
>> I think YOCTO (recipe) behaves perfectly correctly.
>>
>> Other approach: try to compile the same module with Makefile above on
>> the target.
>>
>> (my two cent thoughts)
>>
>> Zoran
>> ___
>>
>> On Thu, Jan 7, 2021 at 2:46 PM Zoltan Kerenyi Nagy
>>  wrote:
>> >
>> > Hi Folks,
>> >
>> > I bitbaked a Huawei E3372h driver into the distro with this recipe file:
>> >
>> > SUMMARY = "Huawei Stick kernel module"
>> > LICENSE = "CLOSED"
>> >
>> > inherit module
>> >
>> > SRC_URI = "file://Makefile \
>> >file://huawei_cdc_ncm.c \
>> >   "
>> >
>> > S = "${WORKDIR}"
>> >
>> > The makefile looks like this:
>> >
>> > obj-m := huawei_cdc_ncm.o
>> >
>> > SRC := $(shell pwd)
>> >
>> > all:
>> > $(MAKE) -C $(KERNEL_SRC) M=$(SRC)
>> >
>> > modules_install:
>> > $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
>> >
>> > clean:
>> > rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c
>> > rm -f Module.markers Module.symvers modules.order
>> > rm -rf .tmp_versions Modules.symvers
>> >
>> > The source file is the one that matches the kernel:
>> >
>> > https://elixir.bootlin.com/linux/v4.0/source/drivers/net/usb/huawei_cdc_ncm.c
>> >
>> > I included this into the conf file:
>> > KERNEL_MODULE_AUTOLOAD += "lte"KERNEL_MODULE_PROBECONF += 
>> > "lte"huawei_cdc_ncm = "options lte iProduct=E3372h iManufacturer=Huawei"
>> >
>> > Bitbake runs without error, however when I insert the SD card into the 
>> > hardware ( barix ipam 400)
>> > and boot the hardware this is the error message:
>> >
>> > root@barix-ipam400:~# insmod /lib/modules/4.10.0/extra/huawei_cdc_ncm.ko
>> > insmod: can't insert '/lib/modules/4.10.0/extra/huawei_cdc_ncm.ko': 
>> > unknown symbol in module, or unknown parameter
>> >
>> > To me it looks like that there was an error during the bitbake, or the 
>> > header files included in the driver doesn't match the kernel.
>> >
>> > Do you have any idea how to procede?
>> >
>> > Thanks,
>> >
>> >
>> >
>> > --
>> > Zolee
>> > 
>> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51919): https://lists.yoctoproject.org/g/yocto/message/51919
Mute This Topic: https://lists.yoctoproject.org/mt/79498728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] insmod - huawei E3372h kernel module

[Zoran]

Hello Zoltan,

> root@barix-ipam400:~# insmod /lib/modules/4.10.0/extra/huawei_cdc_ncm.ko
> insmod: can't insert '/lib/modules/4.10.0/extra/huawei_cdc_ncm.ko': unknown 
> symbol in module, or unknown parameter

Please, try to set Kconfig (obj-y := huawei_cdc_ncm.o) to y, I guess
99.9% that the kernel compilation (actually, driver compilation) will
pass.

I think YOCTO (recipe) behaves perfectly correctly.

Other approach: try to compile the same module with Makefile above on
the target.

(my two cent thoughts)

Zoran
___

On Thu, Jan 7, 2021 at 2:46 PM Zoltan Kerenyi Nagy
 wrote:
>
> Hi Folks,
>
> I bitbaked a Huawei E3372h driver into the distro with this recipe file:
>
> SUMMARY = "Huawei Stick kernel module"
> LICENSE = "CLOSED"
>
> inherit module
>
> SRC_URI = "file://Makefile \
>file://huawei_cdc_ncm.c \
>   "
>
> S = "${WORKDIR}"
>
> The makefile looks like this:
>
> obj-m := huawei_cdc_ncm.o
>
> SRC := $(shell pwd)
>
> all:
> $(MAKE) -C $(KERNEL_SRC) M=$(SRC)
>
> modules_install:
> $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
>
> clean:
> rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c
> rm -f Module.markers Module.symvers modules.order
> rm -rf .tmp_versions Modules.symvers
>
> The source file is the one that matches the kernel:
>
> https://elixir.bootlin.com/linux/v4.0/source/drivers/net/usb/huawei_cdc_ncm.c
>
> I included this into the conf file:
> KERNEL_MODULE_AUTOLOAD += "lte"KERNEL_MODULE_PROBECONF += "lte"huawei_cdc_ncm 
> = "options lte iProduct=E3372h iManufacturer=Huawei"
>
> Bitbake runs without error, however when I insert the SD card into the 
> hardware ( barix ipam 400)
> and boot the hardware this is the error message:
>
> root@barix-ipam400:~# insmod /lib/modules/4.10.0/extra/huawei_cdc_ncm.ko
> insmod: can't insert '/lib/modules/4.10.0/extra/huawei_cdc_ncm.ko': unknown 
> symbol in module, or unknown parameter
>
> To me it looks like that there was an error during the bitbake, or the header 
> files included in the driver doesn't match the kernel.
>
> Do you have any idea how to procede?
>
> Thanks,
>
>
>
> --
> Zolee
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51917): https://lists.yoctoproject.org/g/yocto/message/51917
Mute This Topic: https://lists.yoctoproject.org/mt/79498728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using U-boot in Yocto

[Zoran]

Hello Jonas,

Do not forget that you can also build and use U-Boot completely out of
a YOCTO tree.

I do things like that, not using the YOCTO U-Boot build.

(As a matter of fact, I do not use the kernel as well, only rootfs for
the testing purposes)

But it depends what and how your business/project management model
looks like, I should say.

Zoran
___

On Sun, Dec 20, 2020 at 3:10 PM Jonas Vautherin
 wrote:
>
> Oh, for some reason I had not found the docs. Thanks a lot, that looks really 
> good!
>
> On Sun, Dec 20, 2020 at 2:13 PM Paul Barker  wrote:
>>
>> On Sun, 20 Dec 2020 at 09:02, Jonas Vautherin  
>> wrote:
>> >
>> > Hello!
>> >
>> > I am new to Yocto, and hope that this is the right way to ask for help :-).
>> >
>> > I would like to have a way to flash my RPi over USB using `fastboot`, and 
>> > it seems to me that one way to do that is to enable a "fastboot mode" in 
>> > U-boot. Therefore, I am trying to use U-boot in my Yocto image.
>> >
>> > There seems to be a recipe for it, hence I just added the package to my 
>> > `-image.bb` file:
>> >
>> > ```
>> > IMAGE_INSTALL += "u-boot"
>> > ```
>> >
>> > However, I am not really used to bootloaders, and I am not sure it is 
>> > booting with it. How can I check if my system is booting with U-boot? It 
>> > does not seem like it's appearing in `dmesg` (which I presume is only 
>> > starting with the kernel). Do I need to observe that with a serial 
>> > connection to my RPi, or is there a log saved somewhere on the system?
>> >
>> > Note that my image uses `meta-raspberrypi` for MACHINE "raspberrypi4-64" 
>> > (Raspberry Pi 4 Model B).
>>
>> The IMAGE_INSTALL variable is used for packages to install into the
>> rootfs. Typically bootloaders need some special handling and simply
>> adding them to IMAGE_INSTALL either doesn't work or isn't sufficient
>> to enable booting via the chosen bootloader.
>>
>> For Raspberry Pi we made this simple by adding the RPI_USE_U_BOOT
>> variable which you can set in your distro config or in local.conf. See
>> https://meta-raspberrypi.readthedocs.io/en/latest/extra-build-config.html#boot-to-u-boot
>> for more details.
>>
>> The layer documentation for meta-raspberrypi is actually pretty good,
>> you can find it at
>> https://meta-raspberrypi.readthedocs.io/en/latest/index.html.
>>
>> Thanks,
>>
>> --
>> Paul Barker
>> Konsulko Group
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51819): https://lists.yoctoproject.org/g/yocto/message/51819
Mute This Topic: https://lists.yoctoproject.org/mt/79100324/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image

[Zoran]

> Is there documentation on how to set this up ?

Please, try this:

https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-dunfell/local.conf

This is the systemd addendum in my BBB Dunfell local.conf :

## Add systemd service
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_dev_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""

With systemd added, you'll inherit timedatectl tool.

Best Regards,
Zoran
___

On Tue, Sep 29, 2020 at 5:57 PM Monsees, Steven C (US) via
lists.yoctoproject.org
 wrote:
>
>
> Is there documentation on how to set this up ?
>
> -Original Message-
> From: yocto@lists.yoctoproject.org [mailto:yocto@lists.yoctoproject.org] On 
> Behalf Of Quentin Schulz
> Sent: Tuesday, September 29, 2020 11:53 AM
> To: Monsees, Steven C (US) 
> Cc: yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #yocto #linux #systemd Having issues building command 
> line utilities: ntpq, timedatectl, and ntpstat into kernel image
>
> *** WARNING ***
> EXTERNAL EMAIL -- This message originates from outside our organization.
>
>
> Hi Steve,
>
> On Tue, Sep 29, 2020 at 08:45:56AM -0700, Monsees, Steven C (US) via 
> lists.yoctoproject.org wrote:
> > I currently have "ntpq" building and installing correctly...
> >
> > Can someone tell me what it takes to get the "timedatectl" command utility 
> > built into Yocto kernel image ?
> >
> > I see it referenced in both :
> >
> > openembedded-core/meta/recipes-core/systemd/systemd_234.bb:
> > ${bindir}/timedatectl \
> > poky/meta/recipes-core/systemd/systemd_234.bb:
> > ${bindir}/timedatectl \
> >
>
> It comes with systemd. Use it as your init system and then you'll have the 
> command.
>
> Quentin
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50889): https://lists.yoctoproject.org/g/yocto/message/50889
Mute This Topic: https://lists.yoctoproject.org/mt/77180295/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #systemd:https://lists.yoctoproject.org/g/yocto/mutehashtag/systemd
Mute #linux:https://lists.yoctoproject.org/g/yocto/mutehashtag/linux
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto systemd not able to start sshd after a reboot

[Zoran]

Maybe this should be added to sshd.service [unit] part
(to have added dependency) to solve this problem:

> The sshd.service file is as follows:
> [Unit]
> Description=OpenSSH server daemon
> Documentation=man:sshd(8) man:sshd_config(5)
> After=sshdgenkeys.service
> Wants=sshdgenkeys.service
*Requires=**sshd.socket*

Zoran
___
On Fri, Sep 18, 2020 at 5:29 PM  wrote:
>
> I am facing a peculiar problem with openssh. I have built openssh_8.0p1on
zeus.
>
> The sshd.service file is as follows:
> [Unit]
> Description=OpenSSH server daemon
> Documentation=man:sshd(8) man:sshd_config(5)
> After=sshdgenkeys.service
> Wants=sshdgenkeys.service
>
> [Service]
> Type=simple
> PIDFile=/var/run/sshd.pid
> EnvironmentFile=-/etc/default/sshd
> ExecStart=/usr/sbin/sshd -D $OPTIONS
> ExecReload=/bin/kill -HUP $MAINPID
> ExecStop=/bin/kill $MAINPID
> PermissionsStartOnly=true
> KillMode=process
> Restart=on-failure
> StandardError=syslog
>
> [Install]
> WantedBy=multi-user.target
>
> It starts without issues, if i do a systemctl start sshd.service. If I do
a test of the config file it does not come up with any errors:
>
> genericx86-64:~$ sudo /usr/sbin/sshd -t
> genericx86-64:~$
>
> Problem:
> If I reboot the server, sshd does not start. There is no error on syslog.
I have enabled debug logging, still no logs in syslog.
>
> # Logging
> SyslogFacility DAEMON
> LogLevel DEBUG3
>
> Even systemctl is-enabled sshd shows as enabled.
>
> After a reboot, if I do a systemctl status sshd it shows:
> Loaded: loaded  (/lib/systemd/system/sshd.service; enabled; vendor
preset: enabled)
> Active: inactive (dead)
>
> If I manually run systemctl start sshd.service, everything works
perfectly well without issues. sshd start on 0.0.0.0:2224 and I am able to
ssh in as well.
>
> It's just that systemctl is not able to start sshd after a reboot and
there is no error that i can find or debug. Absolutely run out of ideas to
resolve this. Any help will be greatly appreciated.
>
> Thanks and Regards,
> -=Srijan Nandi
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50838): https://lists.yoctoproject.org/g/yocto/message/50838
Mute This Topic: https://lists.yoctoproject.org/mt/76932692/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] SIGINT Issues with Zeus Migration

[Zoran]

Hello Leon,

> Aashik, how are you sending the signal? Using CTRL-C or
> using the "kill" command?

This is a good suggestion for the test. To open another terminal and
issue: kill -SIGINT .

I should add that this MUST work: kill -SIGKILL , since
SIGKILL handler is un-preemptable.

If it does not, something is very wrong... I suggest, Aashik, you
write YOCTO bugzilla for Zeus.

> Zoran, are you suggesting that the program will change the signal
> handler to default even after it has exited, and for the subsequent
> ping command?

Yes, I do. Then, the ping command should be issued again, and my best
guess is, it should terminate the ping process.

Leon, you should try to write another C f-n and to install other
SIGINT handler (replacing SIG_DFL), then test it with my original C:

void  myhandler(int signum) {
if (SIGINT == signum)
printf("\nHey, I got SIGINT: %d\n\n",signum);
}

Zoran
___

On Fri, Sep 25, 2020 at 10:54 AM Leon Woestenberg  wrote:
>
> Hi Aashik, Zoran,
>
>
> On Fri, Sep 25, 2020 at 10:02 AM Zoran  wrote:
> >
> > > ...that I am not able to send SIGINT to commands such as Ping, tail etc.\
>
> Aashik, how are you sending the signal? Using CTRL-C or using the
> "kill" command?
>
> >
> > Please, do the following: issue in zeus xterm the command: man signal
> > and read it.
> >
> That reads to use sigaction() instead of signal() I would assume.
>
> > Then execute the following code (ad-hoc from the top of my head):
> > <...>
> > This program serves the double purpose:
> > [1] Gives you the address of the old SIGINT handler which was executed
> > prior execution of this code;
> > [2] After execution, repeat the routine (ping) and see if 
> > terminates the ping process.
> >
>
> Zoran, are you suggesting that program will change the signal handler
> to default even after it has exited, and for the subsequent ping
> command?
>
> Regards,
>
> Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50817): https://lists.yoctoproject.org/g/yocto/message/50817
Mute This Topic: https://lists.yoctoproject.org/mt/77073508/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] SIGINT Issues with Zeus Migration

[Zoran]

> ...that I am not able to send SIGINT to commands such as Ping, tail etc.

Please, do the following: issue in zeus xterm the command: man signal
and read it.

Then execute the following code (ad-hoc from the top of my head):

#include 
#include 
#include 
#include 

typedef void (*sighandler_t)(int);
sighandler_t signal_handler;
sighandler_t signal(int signum, sighandler_t handler);

int main() {
signal_handler = signal(SIGINT, SIG_DFL);
printf ("Old signal handler is 0x%x\n", signal_handler);
}

Where the following is also known:
#define SIG_ERR  ((__sighandler_t) -1)  /* Error return.  */
#define SIG_DFL  ((__sighandler_t)  0)  /* Default action. */
#define SIG_IGN  ((__sighandler_t)  1)  /* Ignore signal. */

This program serves the double purpose:
[1] Gives you the address of the old SIGINT handler which was executed
prior execution of this code;
[2] After execution, repeat the routine (ping) and see if 
terminates the ping process.

All other comments are obvious (testing the Zeus SIGINT signal, yada
yada yada... ;-)

Zoran
___

On Fri, Sep 25, 2020 at 6:48 AM Aashik Aswin  wrote:
>
> Hello Developers,
>
> I recently migrated all my platform Recipes from Thud (Linux 4.19) to Zeus 
> (5.4). I understand there might be compatibility issues and was able to fix 
> most of them.
>
> However one issue I am facing is that in the newly migrated Zeus Image is 
> that I am not able to send SIGINT to commands such as Ping, tail etc. I am 
> only able to run them in non-interactive mode. I have to reboot the box if I 
> executed those above commands in interactive mode.
>
> Can anyone suggest which recipe/config can be a good starting point?
>
> Please let me know your suggestions.
>
> Thanks,
> Aashik
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50813): https://lists.yoctoproject.org/g/yocto/message/50813
Mute This Topic: https://lists.yoctoproject.org/mt/77073508/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto systemd not able to start sshd after a reboot

[Zoran]

> There was a sshd.socket file in /lib/systemd/system which had the following 
> line in it.

Interesting... Pushed/forced me to think.

There is no formal dependency between sshd.service and sshd.socket!

[vuser@fedora32-ssd systemd]$ systemctl list-dependencies sshd.service
| grep ssh
sshd.service
● ├─sshd-keygen.target
● │ ├─sshd-keygen@ecdsa.service
● │ ├─sshd-keygen@ed25519.service
● │ └─sshd-keygen@rsa.service
[vuser@fedora32-ssd systemd]$ systemctl list-dependencies sshd.service
| grep socket
●   ├─lvm2-lvmetad.socket
●   ├─lvm2-lvmpolld.socket
[vuser@fedora32-ssd systemd]$ systemctl list-dependencies sshd.socket
| grep sshd
sshd.socket

Strange... Isn't it?!

Zoran
___

On Sat, Sep 19, 2020 at 3:37 PM  wrote:
>
> Hello All,
>
> I finally got it to work!!!
>
> There was a sshd.socket file in /lib/systemd/system which had the following 
> line in it.
>
> Conflicts=sshd.service
>
> I remove it and added the following two lines:
>
> After=network.target
> Before=sshd.service
>
> And that did the trick. Now sshd service starts on every boot.
>
> Thanks,
> -=Srijan Nandi
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50754): https://lists.yoctoproject.org/g/yocto/message/50754
Mute This Topic: https://lists.yoctoproject.org/mt/76932692/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto systemd not able to start sshd after a reboot

[Zoran]

Interesting... Here is what I have on Fedora32:

[root@fedora32-ssd system]# pwd
/lib/systemd/system
[root@fedora32-ssd system]# cat /lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
*After=network.target sshd-keygen.target*
Wants=sshd-keygen.target

[Service]
Type=notify
EnvironmentFile=-/etc/sysconfig/sshd-permitrootlogin
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $PERMITROOTLOGIN
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

*Seems that some leftovers from System V still reside in YOCTO...
Correct???*

Best Regards,
Zoran
___


On Sat, Sep 19, 2020 at 3:37 PM  wrote:

> Hello All,
>
> I finally got it to work!!!
>
> There was a sshd.socket file in /lib/systemd/system which had the
> following line in it.
>
> Conflicts=sshd.service
>
> I remove it and added the following two lines:
>
> After=network.target
> Before=sshd.service
>
> And that did the trick. Now sshd service starts on every boot.
>
> Thanks,
> -=Srijan Nandi
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50741): https://lists.yoctoproject.org/g/yocto/message/50741
Mute This Topic: https://lists.yoctoproject.org/mt/76932692/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto systemd not able to start sshd after a reboot

[Zoran]

Hello Srijan,

Did you recap/look into this sshd.service file?
https://lists.yoctoproject.org/g/yocto/message/49993

Zoran
___

On Fri, Sep 18, 2020 at 8:07 PM  wrote:
>
> Hello Khem,
>
> With the above sshd.service file the sshd daemon fails to start. It gives an 
> error "(code=exited, status=203/EXEC)".
>
> Cannot figure out as to why the systemd for sshd fails to work, while the 
> other systemd files are working perfectly fine.
>
> -=Srijan Nandi
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50736): https://lists.yoctoproject.org/g/yocto/message/50736
Mute This Topic: https://lists.yoctoproject.org/mt/76932692/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA notification for completed autobuilder build (yocto-3.0.4.rc1)

[Zoran]

>* Intel* and WR YP QA is planning for QA execution for YP
> build yocto-3.0.3.rc2.

With all due respect... INTEL part I'll drop out. ;-)

Better to keep YOCTO as an Open Source project without
mentioning ECO systems financing it... Correct?!

YOCTO is an (Force Major context) Open Source project... Isn't it?!

Thank you,
Zoran Stojsavljevic
___




On Mon, Aug 17, 2020 at 9:09 AM Sangeeta Jain 
wrote:

> Hello All,
>
> Intel and WR YP QA is planning for QA execution for YP build
> yocto-3.0.3.rc2. We are planning to execute following tests for this cycle:
>
> OEQA-manual tests for following module:
> 1. OE-Core
> 2. BSP-hw
>
> Runtime auto test for following platforms:
> 1. MinnowTurbot 32-bit
> 2. Coffee Lake
> 3. NUC 7
> 4. NUC 6
> 5. Edgerouter
> 6. MPC8315e-rdb
> 7. Beaglebone
>
> ETA for completion is next Wednesday, Aug 19.
>
> Thanks,
> Sangeeta
>
> > -Original Message-
> > From: Poky Build User 
> > Sent: Saturday, 15 August, 2020 1:06 PM
> > To: yocto@lists.yoctoproject.org
> > Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
> > ; Yeoh, Ee Peng ; Chan,
> > Aaron Chun Yew ;
> > richard.pur...@linuxfoundation.org; akuster...@gmail.com;
> > sjolley.yp...@gmail.com; Jain, Sangeeta 
> > Subject: QA notification for completed autobuilder build
> (yocto-3.0.4.rc1)
> >
> >
> > A build flagged for QA (yocto-3.0.4.rc1) was completed on the
> autobuilder and is
> > available at:
> >
> >
> > https://autobuilder.yocto.io/pub/releases/yocto-3.0.4.rc1
> >
> >
> > Build hash information:
> >
> > bitbake: fd279f857c98d492f43cc62d9ebae18ce6412b6e
> > meta-arm: 38de27d05f104f989adfed5c5363464dd600b316
> > meta-gplv2: 0f4eecc000f66d114ad258fa31aed66afa292166
> > meta-intel: ce6f8ddd2d7f42a9fe530d30332b0d9695e4904b
> > meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
> > meta-mingw: 756963cc28ebc163df7d7f4b4ee004c18d3d3260
> > oecore: 9cad716656b427e625a470a820b8b29b1ec9f976
> > poky: f2eb22a8783f1eecf99bd4042695bab920eed00e
> >
> >
> >
> > 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 (#50287): https://lists.yoctoproject.org/g/yocto/message/50287
Mute This Topic: https://lists.yoctoproject.org/mt/76203993/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?

[Zoran]

Hello Scott,

What I wanted to say here is that you do not change anything while
building a YOCTO load. You'll get all the components in:
.../tmp/deploy/images/$(PLATFORM) , namely:
XYZ,rootfs.cpio.zx
U-Boot
zImage
modules

But you can build a rt-kernel very conventionally, using out of YOCTO
classical kernel build.
[1] Download from the provider the normal kernel;
[2] Apply rt-patches to it (usually there is a script for it);
[3] make imx8_defconfig or whatever *_defconfig which suits to your platform;
[4] make menuconfig (for checking which CONFIG_ options are included,
and if you need something more/less, to adjust it;
[5] make
[6] sudo make modules_install

This is in nutshell, you might need to use cross compiling options,
like I do for BBB:
https://github.com/ZoranStojsavljevic/MikroE_BeagleBone-Black_BSP-Integration/blob/master/README.md

(please, find U-Boot and kernel classical building procedures in there)

The same for U-Boot, or even you can use YOCTO's U-Boot.

Then, if the whole system suits your requirements, you might go by
Bruce's advices (from his very last email).

Just an idea how to ease your initial pain...

Zoran
___


On Tue, Jul 28, 2020 at 4:18 PM Scott Whitney  wrote:
>
> Hi Zoran,
>
> Thank you for responding.  I confess I am still new to building Linux with 
> Yocto, so some of your steps may seem obvious, but are a bit confusing to a 
> 'newbie'.
>
> I am using normal Yocto instruction provided by Variscite to build our 
> rootfs, U-Boot, and kernel.  However, I am not doing anything special to 
> build an rt-kernel, and that is what I am trying to find out how to do.
>
> For example, after downloading and installing prerequisite executables, I 
> initialize our repo (example is for Yocto Warrior, but similar for Yocto 
> Zeus):
>
> $ repo init -u https://github.com/varigit/variscite-bsp-platform.git -b 
> fsl-warrior -m imx-4.19.35-1.1.0-var01.xml
> $ repo sync -j4
>
> Then I configure our machine, distro, and build directory:
>
> $ cd ~/var-fsl-yocto
> $ MACHINE=imx8mm-var-dart DISTRO=fsl-imx-xwayland . var-setup-release.sh -b 
> build_xwayland
>
> Then I am in the build_xwayland directory, and create our SD card image using:
>
> $ bitbake fsl-image-qt5
>
> The SD card image ends up in the build_xwayland/tmp/deploy/images directory, 
> and I use the following to flash the SD card:
>
> # For fsl-image-qt5 image (Qt5-XWAYLAND & Qt5-WAYLAND)
> $ zcat 
> tmp/deploy/images/imx8mm-var-dart/fsl-image-qt5-imx8mm-var-dart.sdcard.gz | 
> sudo dd of=/dev/sdX bs=1M conv=fsync
>
> What steps are you suggesting to configure rt-linux?  I would appreciate it 
> if you could be specific, since some of the steps involved are new to me.
>
> I have already added a .bbappend file to modify the device tree for our 
> application, and have run bitbake -c menuconfig virtual/kernel to update the 
> kernel configuration.
>
> Thanks for your assistance and tolerance for my inexperienced questions.
>
> Scott D. Whitney
>
> s...@inea.com| T: 781-801-1152| F: 781-801-1108| 
> www.inea.com
>
> -Original Message-
> From: Zoran Stojsavljevic 
> Sent: Tuesday, July 28, 2020 10:05 AM
> To: Scott Whitney 
> Cc: Bruce Ashfield ; yo...@yoctoproject.org
> Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?
>
> Hello Scott,
>
> I have a bit of a different idea about the whole YOCTO process.
>
> Let me suggest something else, actually a hybrid combination of the YOCTO 
> build system.
>
> You can do the whole process of YOCTO, but why do you not use components out 
> of the YOCTO building process?
>
> For example, you can use rootfs built by YOCTO, and U-Boot and rt-kernel 
> built out of the YOCTO, for the beginning?
>
> Then, as an option, if you are satisfied with the reached architecture, you 
> can write your own recipe for the rt-kernel (you need to incorporate a bunch 
> of patches into the rt-kernel proprietary recipe).
>
> Zoran
> ___
>
>
> On Tue, Jul 28, 2020 at 2:45 PM Scott Whitney  wrote:
> >
> > Hi Bruce,
> >
> >
> >
> > Yes, we are using Linux built by Yocto, but where is the preferred provider 
> > for the kernel set to linux-yocto-rt?
> >
> >
> >
> > Thanks for your help
> >
> >
> >
> > Scott D. Whitney
> >
> > s...@inea.com| T: 781-801-1152| F: 781-801-1108| 
> > www.inea.com
> >
> >
> >
> > From: Bruce Ashfield 
> > Sent: Monday, July 27, 2020 10:04 PM
> > To: Scott Whitney 
> > Cc: yo...@yoctoproject.org
> > Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?
> >
> >
> >
&g

Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?

[Zoran]

Hello Scott,

I have a bit of a different idea about the whole YOCTO process.

Let me suggest something else, actually a hybrid combination of the
YOCTO build system.

You can do the whole process of YOCTO, but why do you not use
components out of the YOCTO building process?

For example, you can use rootfs built by YOCTO, and U-Boot and
rt-kernel built out of the YOCTO, for the beginning?

Then, as an option, if you are satisfied with the reached
architecture, you can write your own recipe for the rt-kernel (you
need to incorporate a bunch of patches into the rt-kernel proprietary
recipe).

Zoran
___


On Tue, Jul 28, 2020 at 2:45 PM Scott Whitney  wrote:
>
> Hi Bruce,
>
>
>
> Yes, we are using Linux built by Yocto, but where is the preferred provider 
> for the kernel set to linux-yocto-rt?
>
>
>
> Thanks for your help
>
>
>
> Scott D. Whitney
>
> s...@inea.com| T: 781-801-1152| F: 781-801-1108| 
> www.inea.com
>
>
>
> From: Bruce Ashfield 
> Sent: Monday, July 27, 2020 10:04 PM
> To: Scott Whitney 
> Cc: yo...@yoctoproject.org
> Subject: Re: [yocto] How to enable preempt-rt in Yocto Zeus or Warrior?
>
>
>
>
>
>
>
> On Mon, Jul 27, 2020 at 3:51 PM Scott Whitney  wrote:
>
> Hi Yocto group,
>
>
>
> I’m working with a newly-released copy of Yocto Zeus from Variscite for the 
> i.MX8MM Mini, although the same option seems to apply to the previous Yocto 
> Warrior.
>
>
>
> I understand that a Linux real-time kernel can be enabled by setting 
> LINUX_KERNEL_TYPE = “preempt-rt”.  Where does this option need to be set so 
> that when I bitbake fsl-image-qt5, I get the Linux “preempt-rt” kernel 
> instead of the “standard” kernel?
>
>
>
> Is there a specific configuration file that needs to be modified, or a new 
> recipe in a layer?  I am confused and hoping that you can help.
>
>
>
> If you aren't using linux-yocto, you'll need to arrange for the preempt-rt 
> patch(es) to be applied to whatever kernel you are using. Which means you are 
> creating a new recipe, bbappending an existing one, or if you are lucky the 
> kernel provider already has a -rt recipe available.
>
>
>
> If you are using linux-yocto, it's as simple as setting the preferred 
> provider of the kernel as linux-yocto-rt  and building.
>
>
>
> Bruce
>
>
>
>
>
>
>
> Best regards,
>
>
>
> Scott D. Whitney
>
> Principal Software Engineer
>
>
> Intertech Engineering Associates, Inc.
> 100 Lowder Brook Drive, Suite 2500
> Westwood, MA  02090
> s...@inea.com| T: 781-801-1152| F: 781-801-1108| 
> www.inea.com
>
>
>
>
>
>
> --
>
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at 
> its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50117): https://lists.yoctoproject.org/g/yocto/message/50117
Mute This Topic: https://lists.yoctoproject.org/mt/75830848/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] openssh_8.0p1 on zeus - sshd.service not starting [RESOLVED] #yocto

[Zoran]

Although, I must admit, I have there OpenSSH_7.9p1.

Zoran
___

On Sat, Jul 18, 2020 at 5:38 PM Zoran via lists.yoctoproject.org
 wrote:
>
> This is what I have with my BBB on SDcard with Debian Buster:
>
> root@arm:/etc/systemd/system# cat sshd.service
> [Unit]
> Description=OpenBSD Secure Shell server
> Documentation=man:sshd(8) man:sshd_config(5)
> After=network.target auditd.service
> ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
>
> [Service]
> EnvironmentFile=-/etc/default/ssh
> ExecStartPre=/usr/sbin/sshd -t
> ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
> ExecReload=/usr/sbin/sshd -t
> ExecReload=/bin/kill -HUP $MAINPID
> KillMode=process
> Restart=on-failure
> RestartPreventExitStatus=255
> Type=notify
> RuntimeDirectory=sshd
> RuntimeDirectoryMode=0755
>
> [Install]
> WantedBy=multi-user.target
> Alias=sshd.service
>
> root@arm:/etc/systemd/system# systemctl status sshd
> ● ssh.service - OpenBSD Secure Shell server
>Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: 
> enab
>Active: active (running) since Fri 2020-07-17 17:22:23 UTC; 22h ago
>  Docs: man:sshd(8)
>man:sshd_config(5)
>   Process: 650 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
>  Main PID: 691 (sshd)
> Tasks: 1 (limit: 1059)
>Memory: 2.2M
>CGroup: /system.slice/ssh.service
>└─691 /usr/sbin/sshd -D
>
> Jul 17 17:22:22 arm systemd[1]: Starting OpenBSD Secure Shell server...
> Jul 17 17:22:23 arm sshd[691]: Server listening on 0.0.0.0 port 22.
> Jul 17 17:22:23 arm sshd[691]: Server listening on :: port 22.
> Jul 17 17:22:23 arm systemd[1]: Started OpenBSD Secure Shell server.
> root@arm:/etc/systemd/system#
>
> Works seamlessly. Just for comparison.
>
> Best Regards,
> Zoran
> ___
>
> On Sat, Jul 18, 2020 at 5:19 PM  wrote:
> >
> > Helo Zoran,
> >
> > Type=notify didn't work, either.
> >
> > The only thing that worked was Type=simple.
> >
> > Thanks,
> > -=Srijan Nandi
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49994): https://lists.yoctoproject.org/g/yocto/message/49994
Mute This Topic: https://lists.yoctoproject.org/mt/75633169/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] openssh_8.0p1 on zeus - sshd.service not starting [RESOLVED] #yocto

[Zoran]

This is what I have with my BBB on SDcard with Debian Buster:

root@arm:/etc/systemd/system# cat sshd.service
[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target
Alias=sshd.service

root@arm:/etc/systemd/system# systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enab
   Active: active (running) since Fri 2020-07-17 17:22:23 UTC; 22h ago
 Docs: man:sshd(8)
   man:sshd_config(5)
  Process: 650 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 691 (sshd)
Tasks: 1 (limit: 1059)
   Memory: 2.2M
   CGroup: /system.slice/ssh.service
   └─691 /usr/sbin/sshd -D

Jul 17 17:22:22 arm systemd[1]: Starting OpenBSD Secure Shell server...
Jul 17 17:22:23 arm sshd[691]: Server listening on 0.0.0.0 port 22.
Jul 17 17:22:23 arm sshd[691]: Server listening on :: port 22.
Jul 17 17:22:23 arm systemd[1]: Started OpenBSD Secure Shell server.
root@arm:/etc/systemd/system#

Works seamlessly. Just for comparison.

Best Regards,
Zoran
___

On Sat, Jul 18, 2020 at 5:19 PM  wrote:
>
> Helo Zoran,
>
> Type=notify didn't work, either.
>
> The only thing that worked was Type=simple.
>
> Thanks,
> -=Srijan Nandi 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49993): https://lists.yoctoproject.org/g/yocto/message/49993
Mute This Topic: https://lists.yoctoproject.org/mt/75633169/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] openssh_8.0p1 on zeus - sshd.service not starting [RESOLVED} #yocto

[Zoran]

> Finally was able to resolve the issue. It seems the sshd.service
> did not line Type=forking.
>
> I changed it to Type=simple and it started working.

Please, could you try with Type=notify ?

Thank you,
Zoran
___

On Sat, Jul 18, 2020 at 12:53 PM  wrote:
>
> Finally was able to resolve the issue. It seems the sshd.service did not line 
> Type=forking.
>
> I changed it to Type=simple and it started working.
>
> So now my sshd.service file looks like this:
>
>
>
> [Unit]
>
> Description=OpenSSH server daemon
>
> Documentation=man:sshd(8) man:sshd_config(5)
>
> After=network.target sshdkeygen.service
>
> Wants=sshdkeygen.service
>
>
>
> [Service]
>
> Type=simple
>
> PIDFile=/run/sshd.pid
>
> EnvironmentFile=-@SYSCONFDIR@/default/sshd
>
> ExecStart=@SBINDIR@/sshd -D $OPTIONS
>
> ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID
>
> PermissionsStartOnly=true
>
> ExecStartPre=-/bin/mkdir -p /var/run/sshd
>
> ExecStartPre=/bin/chmod -R 755 /var/run/sshd
>
> KillMode=process
>
> Restart=on-failure
>
> RestartSec=42s
>
>
>
> [Install]
>
> WantedBy=multi-user.target
>
> Thanks,
> -=Srijan Nandi
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49991): https://lists.yoctoproject.org/g/yocto/message/49991
Mute This Topic: https://lists.yoctoproject.org/mt/75629249/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] openssh_8.0p1 on zeus - sshd.service not starting #yocto

[Zoran]

>From the source config file:
> ExecStart=@SBINDIR@/sshd -D $OPTIONS

>From your reply:
> But if I run the /usr/sbin/sshd -f /etc/ssh/sshd_config, it starts fine.

If you run the command: /usr/sbin/sshd -D -f /etc/ssh/sshd_config, I
bet it'll fail again!

So, I have no idea what -D option does mean (lazy to investigate),
seems that this was the main cause of the problem:
https://unix.stackexchange.com/questions/390224/openssh-server-start-failed-with-result-timeout

Please, read this link carefully.

Best Regards,
Zoran
___

On Thu, Jul 16, 2020 at 5:53 PM  wrote:
>
> Hello Zoran,
>
> I started the service and then ran journalctl -u sshd.service -r -n 10
>
> This is what I see:
>
> sshd.service Failed with result 'timeout'
> sshd.service: start operation timed out. Terminating.
>
> But if I run the /usr/sbin/sshd -f /etc/ssh/sshd_config, it starts fine.
>
> Thanks,
> -=Srijan Nandi 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49971): https://lists.yoctoproject.org/g/yocto/message/49971
Mute This Topic: https://lists.yoctoproject.org/mt/75542163/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] openssh_8.0p1 on zeus - sshd.service not starting #yocto

[Zoran]

On my BBB board (as test vehicle), the following is true:

root@arm:~# uname -a
Linux arm 5.7.6 #1 SMP Tue Jun 30 16:46:05 CEST 2020 armv7l GNU/Linux
root@arm:~# lshw -short
H/W path  Device  Class  Description

  system TI AM335x BeagleBone Black
/0busMotherboard
/0/0  processor  cpu
/0/1  processor  idle-states
/0/2  memory 491MiB System memory
/1eth0networkEthernet interface
root@arm:~# which systemctl
/bin/systemctl
root@arm:~# systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enab
   Active: active (running) since Thu 2020-07-16 12:21:59 UTC; 2h 33min ago
 Docs: man:sshd(8)
   man:sshd_config(5)
  Process: 435 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 765 (sshd)
   Memory: 2.1M
   CGroup: /system.slice/ssh.service
   └─765 /usr/sbin/sshd -D

Jul 16 12:00:13 arm systemd[1]: Starting OpenBSD Secure Shell server...
Jul 16 12:21:59 arm sshd[765]: Server listening on 0.0.0.0 port 22.
Jul 16 12:21:59 arm sshd[765]: Server listening on :: port 22.
Jul 16 12:21:59 arm systemd[1]: Started OpenBSD Secure Shell server.
root@arm:~#

Although I am not running YOCTO there, you can see that I have systemd
present, and that my sshd server is running.

You should give us more info using: $ journalctl -u sshd.service -r -n 1

Zoran
___

On Thu, Jul 16, 2020 at 4:01 PM  wrote:
>
> I am facing an issue with openssh_8.0p1 on zeus...systemd is not able to 
> start sshd.service. I am using the following sshd.service file.
>
> [Unit]
> Description=OpenSSH server daemon
> Documentation=man:sshd(8) man:sshd_config(5)
> After=network.target sshdgenkeys.service
> Wants=sshdgenkeys.service
>
> [Service]
> Type=forking
> PIDFile=@localstatedir@/run/sshd.pid
> EnvironmentFile=-@SYSCONFDIR@/default/sshd
> ExecStart=@SBINDIR@/sshd -D $OPTIONS
> ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID
> PermissionsStartOnly=true
> ExecStartPre=-/bin/mkdir -p /var/run/sshd
> ExecStartPre=/bin/chmod -R 755 /var/run/sshd
> KillMode=process
> Restart=on-failure
> RestartSec=42s
>
> [Install]
> WantedBy=multi-user.target
>
>
> Has anyone else faced a similar issue.
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49968): https://lists.yoctoproject.org/g/yocto/message/49968
Mute This Topic: https://lists.yoctoproject.org/mt/75542163/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-