Re: [yocto] is there a rationale for YP using sysvinit as default init manager?

[Alexander Kanavin]

On Thu, 21 Nov 2019 at 22:18, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> We got so far and after looking at the position we ended up I decided
> it was easier to switch poky-altcfg rather than change poky and/or OE
> defaults. I resolved that bug as "complete" as we now had testing of
> systemd on a near enough equal footing to sysvinit which was the
> concern people had raised. There are problems in oe-selftest and some
> other corner cases but nothing people seem to be running into day-to-
> day.
>

It is also quite amazing that the project, by design, has entirely
sidestepped the divisive init system wars that have been gripping the
mainstream linux distros for years (and still are). I'd say it hardly
matters what the default is, if the other options are well supported.

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

Re: [yocto] is there a rationale for YP using sysvinit as default init manager?

[Richard Purdie]

On Fri, 2019-11-22 at 10:08 +1300, Paul Eggleton wrote:
> On Friday, 22 November 2019 9:40:35 AM NZDT Richard Purdie wrote:
> > On Thu, 2019-11-21 at 14:02 -0500, Robert P. J. Day wrote:
> > >   don't get me wrong, i have no problem with that, but a
> > > colleague
> > > asked me what the reason was for using sysvinit as the *default*.
> > > i
> > > hemmed and hawed and suggested it was for simplicity and
> > > reliability,
> > > and that a lot of embedded systems didn't need the flashy
> > > features of
> > > systemd, and so on.
> > > 
> > >   is there any short answer to give to that question?
> > 
> > The project existed before systemd and we haven't changed the
> > default.
> > 
> > We can change the default, it just means someone going through and
> > fixing the build failures it generates and rewriting all the test
> > metadata to invert poky and poky-altcfg. Personally I've got other
> > things I'd prefer to do...
> 
> Kai was working on changing this in the last cycle but AFAICT not all
> issues were able to be resolved in time. Kai, do you have a status
> update?

We got so far and after looking at the position we ended up I decided
it was easier to switch poky-altcfg rather than change poky and/or OE
defaults. I resolved that bug as "complete" as we now had testing of
systemd on a near enough equal footing to sysvinit which was the
concern people had raised. There are problems in oe-selftest and some
other corner cases but nothing people seem to be running into day-to-
day.

There has been representation at OE meetings, in surveys and from YP
members for us not to switch the default FWIW.

Cheers,

Richard

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

[yocto] OpenEmbedded Workshop at FOSDEM20 CFP

[Jon Mason]

We are proud to announce the inaugural OpenEmbedded Workshop. It is
being held on 03 February 2020 in Brussels, Belgium. The day after
FOSDEM.

The Call for Participation is open now. For more information, go to
https://pretalx.com/oe-workshop-2020/cfp

Early-bird tickets coming soon!

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

Re: [yocto] is there a rationale for YP using sysvinit as default init manager?

[Paul Eggleton]

On Friday, 22 November 2019 9:40:35 AM NZDT Richard Purdie wrote:
> On Thu, 2019-11-21 at 14:02 -0500, Robert P. J. Day wrote:
> >   don't get me wrong, i have no problem with that, but a colleague
> > asked me what the reason was for using sysvinit as the *default*. i
> > hemmed and hawed and suggested it was for simplicity and reliability,
> > and that a lot of embedded systems didn't need the flashy features of
> > systemd, and so on.
> > 
> >   is there any short answer to give to that question?
> 
> The project existed before systemd and we haven't changed the default.
> 
> We can change the default, it just means someone going through and
> fixing the build failures it generates and rewriting all the test
> metadata to invert poky and poky-altcfg. Personally I've got other
> things I'd prefer to do...

Kai was working on changing this in the last cycle but AFAICT not all issues 
were able to be resolved in time. Kai, do you have a status update?

Thanks
Paul

-- 

Paul Eggleton
Intel System Software Products


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

Re: [yocto] is there a rationale for YP using sysvinit as default init manager?

[Richard Purdie]

On Thu, 2019-11-21 at 14:02 -0500, Robert P. J. Day wrote:
>   don't get me wrong, i have no problem with that, but a colleague
> asked me what the reason was for using sysvinit as the *default*. i
> hemmed and hawed and suggested it was for simplicity and reliability,
> and that a lot of embedded systems didn't need the flashy features of
> systemd, and so on.
> 
>   is there any short answer to give to that question?

The project existed before systemd and we haven't changed the default.

We can change the default, it just means someone going through and
fixing the build failures it generates and rewriting all the test
metadata to invert poky and poky-altcfg. Personally I've got other
things I'd prefer to do...

Cheers,

Richard



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

[yocto] is there a rationale for YP using sysvinit as default init manager?

[Robert P. J. Day]

  don't get me wrong, i have no problem with that, but a colleague
asked me what the reason was for using sysvinit as the *default*. i
hemmed and hawed and suggested it was for simplicity and reliability,
and that a lot of embedded systems didn't need the flashy features of
systemd, and so on.

  is there any short answer to give to that question?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] populate_sdk with my image

[Mark Hatle]

On 11/21/19 12:00 PM, Mauro Ziliani wrote:
> Thanks.
> 
> This is true for a Krogoth based project?

Same class, slightly different semantics.  I don't believe src-pkgs existed yet
at that point, but dev-pkgs would have.

You will have to investigate the class for the parameters.. but general behavior
is the same.

--Mark

> Il 21/11/19 17:40, Mark Hatle ha scritto:
>> populate_sdk uses the same configuration as the regular image, as well as 
>> adding
>> "dev-pkgs dbg-pkgs src-pkgs" and optionally doc-pkgs.
>>
>> See:
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/populate_sdk_base.bbclass
>>
>> Lines 3-11, and 22.
>>
>> If dev-pkgs/src-pkgs isn't inclyding your Qt/Qml development components, then
>> they may not be packaged properly.
>>
>> The way dev-pkgs works (like 5) is by taking a list of each package 
>> installed in
>> the system and then trying to add '-dev' to it, and then install that.  
>> (Roughly)
>>
>> --Mark
>>
>>
>> On 11/21/19 10:31 AM, Mauro Ziliani wrote:
>>> Hi all.
>>>
>>> I have a recipe for my image with depends from Qt/Qml recipes
>>>
>>> When I do
>>>
>>> bitbake -c populate_sdk myimage.bb
>>>
>>>
>>> the sdk doesn't contains the dev version of the Qt/Qml libraries installed 
>>> in
>>> the final image
>>>
>>>
>>> I managing the bitbake variables  TOOLCHAIN_TARGET_TASK and 
>>> TOOLCHAIN_HOST_TASK
>>> adding manually the dependecies.
>>>
>>>
>>> There is an automatic way to do that?
>>>
>>>
>>> M
>>>
>>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] populate_sdk with my image

[Mauro Ziliani]

Thanks.

This is true for a Krogoth based project?

Il 21/11/19 17:40, Mark Hatle ha scritto:

populate_sdk uses the same configuration as the regular image, as well as adding
"dev-pkgs dbg-pkgs src-pkgs" and optionally doc-pkgs.

See:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/populate_sdk_base.bbclass

Lines 3-11, and 22.

If dev-pkgs/src-pkgs isn't inclyding your Qt/Qml development components, then
they may not be packaged properly.

The way dev-pkgs works (like 5) is by taking a list of each package installed in
the system and then trying to add '-dev' to it, and then install that.  
(Roughly)

--Mark


On 11/21/19 10:31 AM, Mauro Ziliani wrote:

Hi all.

I have a recipe for my image with depends from Qt/Qml recipes

When I do

bitbake -c populate_sdk myimage.bb


the sdk doesn't contains the dev version of the Qt/Qml libraries installed in
the final image


I managing the bitbake variables  TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK
adding manually the dependecies.


There is an automatic way to do that?


M


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

Re: [yocto] populate_sdk with my image

[Mark Hatle]

populate_sdk uses the same configuration as the regular image, as well as adding
"dev-pkgs dbg-pkgs src-pkgs" and optionally doc-pkgs.

See:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/populate_sdk_base.bbclass

Lines 3-11, and 22.

If dev-pkgs/src-pkgs isn't inclyding your Qt/Qml development components, then
they may not be packaged properly.

The way dev-pkgs works (like 5) is by taking a list of each package installed in
the system and then trying to add '-dev' to it, and then install that.  
(Roughly)

--Mark


On 11/21/19 10:31 AM, Mauro Ziliani wrote:
> Hi all.
> 
> I have a recipe for my image with depends from Qt/Qml recipes
> 
> When I do
> 
> bitbake -c populate_sdk myimage.bb
> 
> 
> the sdk doesn't contains the dev version of the Qt/Qml libraries installed in
> the final image
> 
> 
> I managing the bitbake variables  TOOLCHAIN_TARGET_TASK and 
> TOOLCHAIN_HOST_TASK
> adding manually the dependecies.
> 
> 
> There is an automatic way to do that?
> 
> 
> M
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] populate_sdk with my image

[Mauro Ziliani]

Hi all.

I have a recipe for my image with depends from Qt/Qml recipes

When I do

bitbake -c populate_sdk myimage.bb


the sdk doesn't contains the dev version of the Qt/Qml libraries 
installed in the final image



I managing the bitbake variables TOOLCHAIN_TARGET_TASK and 
TOOLCHAIN_HOST_TASK adding manually the dependecies.



There is an automatic way to do that?


M

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

[yocto] Canceled event with note: Yocto Project Weekly Triage Meeting @ Thu Nov 28, 2019 7:30am - 8:30am (PST) (yocto@yoctoproject.org)

[theyoctoproject]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20191128T073000
DTEND;TZID=America/Los_Angeles:20191128T083000
DTSTAMP:20191121T161026Z
ORGANIZER;CN=theyoctoproj...@gmail.com:mailto:theyoctoproj...@gmail.com
UID:69b8n4lifp3et8i02e5gp0h9dk_r20190124t153...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=yo
 c...@yoctoproject.org;X-NUM-GUESTS=0:mailto:yocto@yoctoproject.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=sj
 olley.yp...@gmail.com;X-NUM-GUESTS=0:mailto:sjolley.yp...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=theyoc
 toproj...@gmail.com;X-NUM-GUESTS=0:mailto:theyoctoproj...@gmail.com
RECURRENCE-ID;TZID=America/Los_Angeles:20191128T073000
CREATED:20180524T175433Z
DESCRIPTION:Yocto Project Weekly Triage Meeting Details\n\n\nWiki: https://
 wiki.yoctoproject.org/wiki/Bug_Triage\n\n\nYocto IRC: http://webchat.freeno
 de.net/?channels=#yocto - When you join state your name on the bridge or IR
 C.\n\nWe use a Zoom Bridge at: https://zoom.us/j/454367603
LAST-MODIFIED:20191121T161025Z
LOCATION:Zoom Meeting: https://zoom.us/j/454367603
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:Yocto Project Weekly Triage Meeting
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H15M0S
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] busybox + SELinux (warrior) - reboot issue

[Mark Hatle]

I've been trying to find time to look into it, but I've not had any so far.

I'd suggest trying it on more full Linux system first to see if that resolves
the issue.  If it does, then it's simply a configuration and you can use the
audit messages to help figure it out..  but the fact it's rebooting suggests to
me that something is incorrect in the initscripts when used with busybox.

--Mark

On 11/21/19 8:54 AM, Yair Itzhaki wrote:
> Anybody?
> 
>  
> 
> Thanks,
> 
> Yair
> 
>  
> 
>  
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] busybox + SELinux (warrior) - reboot issue

[Yair Itzhaki]

Anybody?

Thanks,
Yair


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

Re: [yocto] :how to solve the basehash value changed from 'xxx' to 'aaaa' ?

[www]

Thanks, 
The cause of the error comes from the cache of the yocto project.


Thanks,
Byron





At 2019-11-21 17:13:54, "Mike Looijmans"  
wrote:
>Without your recipe source code, no one can tell for sure, but I suspect you 
>have something like a "DATE" in there that evaulates to a different value if 
>you run it a second later.
>
>
>Met vriendelijke groet / kind regards,
>
>Mike Looijmans
>System Expert
>
>
>TOPIC Embedded Products B.V.
>Materiaalweg 4, 5681 RJ Best
>Postbus 440, 5680 AK Best
>The Netherlands
>
>T: +31 (0) 499 33 69 69
>E: mike.looijm...@topicproducts.com
>W: www.topicproducts.com
>
>Please consider the environment before printing this e-mail
>On 13-11-19 04:09, www wrote:
>> Dear all,
>> 
>> When I modify the os-release file in my yocto project, it appear some error, 
>> and how can I solve it ? Who can give me some help or advice? Thank you！
>> I carried out the recommended order and it didn't work.
>> 
>> /ERROR: os-release-1.0-r0 do_compile: Taskhash mismatch 
>> ce133f0458608e03aa55224df28156e523e54903115efbbcd62946f84a867201 versus 
>> 7269881f0eb1759ed420a2db4c04fb477cd8c1288bc5f82df5c8161bb926ea1f for 
>> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile/
>> /ERROR: Taskhash mismatch 
>> ce133f0458608e03aa55224df28156e523e54903115efbbcd62946f84a867201 versus 
>> 7269881f0eb1759ed420a2db4c04fb477cd8c1288bc5f82df5c8161bb926ea1f for 
>> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile/
>> /ERROR: When reparsing 
>> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile,
>>  
>> //the basehash value changed from 
>> 99a42a1a3b1a151de604267b159558ecaf1031a3bec8917df132c81302e729a5 to 
>> 4f3288a8763e2e1af78e4b3cdd9c0c0ccb3b0d5c78a3073c188b22200df2a9b0. //The 
>> metadata is not deterministic and this needs to be fixed./
>> /ERROR: The following commands may help:/
>> /ERROR: $ bitbake os-release -cdo_compile -Snone/
>> /ERROR: Then:/
>> /ERROR: $ bitbake os-release -cdo_compile -Sprintdiff/
>> 
>> /ERROR: When reparsing 
>> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile,
>>  
>> //the basehash value changed from 
>> 99a42a1a3b1a151de604267b159558ecaf1031a3bec8917df132c81302e729a5 to 
>> 47c30012daa6aa77be09a93fe21e66995361ef26b4487111005617db8cb4de59. The 
>> metadata 
>> is not deterministic and this needs to be fixed./
>> /ERROR: The following commands may help:/
>> /ERROR: $ bitbake os-release -cdo_compile -Snone/
>> /ERROR: Then:/
>> /ERROR: $ bitbake os-release -cdo_compile -Sprintdiff/
>> 
>> thanks,
>> Byron
>> 
>> 
>> 
>
>-- 
>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH v2] diffutils: use mempcpy instead of __mempcpy

[Nicola Lunghi]

musl (like uclibc) doesn't define __mempcpy.
This patch will replace __mempcpy with mempcpy in the internal regex.c and
getopt.c implementation (similar to what is done in grep in this same repo
with the uclibc-fix.patch

This also render the line:

  EXTRA_OECONF_libc-uclibc = "--without-included-regex"

not needed anymore so it drops it.

Signed-off-by: Nicola Lunghi 
---
 ...included-libc-use-mempcpy-instead-of.patch | 54 +++
 recipes-extended/diffutils/diffutils.inc  |  7 ---
 recipes-extended/diffutils/diffutils_2.8.1.bb |  1 +
 3 files changed, 55 insertions(+), 7 deletions(-)
 create mode 100644 
recipes-extended/diffutils/diffutils-2.8.1/0002-included-libc-use-mempcpy-instead-of.patch

diff --git 
a/recipes-extended/diffutils/diffutils-2.8.1/0002-included-libc-use-mempcpy-instead-of.patch
 
b/recipes-extended/diffutils/diffutils-2.8.1/0002-included-libc-use-mempcpy-instead-of.patch
new file mode 100644
index 000..4bbc864
--- /dev/null
+++ 
b/recipes-extended/diffutils/diffutils-2.8.1/0002-included-libc-use-mempcpy-instead-of.patch
@@ -0,0 +1,54 @@
+From 61db4da387676690c0f731ef2eccc014d85c23a6 Mon Sep 17 00:00:00 2001
+From: Nicola Lunghi 
+Date: Wed, 20 Nov 2019 18:30:10 +
+Subject: [PATCH] included libc: use mempcpy instead of __mempcpy
+
+Fix to use mempcpy instead of __mempcpy. This is needed for uclibc and musl
+which doesn't define __mempcpy, only mempcpy. Since they all have
+mempcpy, we'll just use that instead.
+
+Patch source: OpenEmbedded (grep)
+Upstream-Status: Inappropriate [licensing]
+---
+ lib/getopt.c | 4 ++--
+ lib/regex.c  | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/lib/getopt.c b/lib/getopt.c
+index ed32692..6626f5e 100644
+--- a/lib/getopt.c
 b/lib/getopt.c
+@@ -334,7 +334,7 @@ exchange (argv)
+   nonoption_flags_len = nonoption_flags_max_len = 0;
+   else
+   {
+-memset (__mempcpy (new_str, __getopt_nonoption_flags,
++memset (mempcpy (new_str, __getopt_nonoption_flags,
+nonoption_flags_max_len),
+ '\0', top + 1 - nonoption_flags_max_len);
+ nonoption_flags_max_len = top + 1;
+@@ -445,7 +445,7 @@ _getopt_initialize (argc, argv, optstring)
+ if (__getopt_nonoption_flags == NULL)
+   nonoption_flags_max_len = -1;
+ else
+-  memset (__mempcpy (__getopt_nonoption_flags, orig_str, len),
++  memset (mempcpy (__getopt_nonoption_flags, orig_str, len),
+   '\0', nonoption_flags_max_len - len);
+   }
+   }
+diff --git a/lib/regex.c b/lib/regex.c
+index 6daec76..797b20a 100644
+--- a/lib/regex.c
 b/lib/regex.c
+@@ -8314,7 +8314,7 @@ regerror (errcode, preg, errbuf, errbuf_size)
+   if (msg_size > errbuf_size)
+ {
+ #if defined HAVE_MEMPCPY || defined _LIBC
+-*((char *) __mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
++*((char *) mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
+ #else
+   memcpy (errbuf, msg, errbuf_size - 1);
+   errbuf[errbuf_size - 1] = 0;
+-- 
+2.20.1
+
diff --git a/recipes-extended/diffutils/diffutils.inc 
b/recipes-extended/diffutils/diffutils.inc
index 243341a..c81348b 100644
--- a/recipes-extended/diffutils/diffutils.inc
+++ b/recipes-extended/diffutils/diffutils.inc
@@ -6,13 +6,6 @@ SECTION = "base"
 
 inherit autotools texinfo update-alternatives gettext
 
-# diffutils assumes non-glibc compilation with uclibc and
-# this causes it to generate its own implementations of
-# standard functionality.  regex.c actually breaks compilation
-# because it uses __mempcpy, there are other things (TBD:
-# see diffutils.mk in buildroot)
-EXTRA_OECONF_libc-uclibc = "--without-included-regex"
-
 ALTERNATIVE_${PN} = "diff cmp"
 ALTERNATIVE_PRIORITY = "100"
 
diff --git a/recipes-extended/diffutils/diffutils_2.8.1.bb 
b/recipes-extended/diffutils/diffutils_2.8.1.bb
index 466bf28..5a71c94 100644
--- a/recipes-extended/diffutils/diffutils_2.8.1.bb
+++ b/recipes-extended/diffutils/diffutils_2.8.1.bb
@@ -9,6 +9,7 @@ SRC_URI = "${GNU_MIRROR}/diffutils/diffutils-${PV}.tar.gz \
file://diffutils_fix_for_automake-1.12.patch \
file://fix_gcc6.patch \
file://0001-Make-it-build-with-compile-time-hardening-enabled.patch 
\
+   file://0002-included-libc-use-mempcpy-instead-of.patch \
"
 
 SRC_URI[md5sum] = "71f9c5ae19b60608f6c7f162da86a428"
-- 
2.20.1

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

Re: [yocto] Is Yocto the right fit for my project?

[Mauro Ziliani]

Hello,

Yocto is a must for your project, regarding the project evolution.


I made a project starting from an intel platform, then I port it on 
raspberry, now on imx6 dual lite.


My application never change, the system services never change.

I need to change only the parts which driver the hardware.

You can achieve this goal playing with layers

If you made a good planning of the layers, the porting will be "easy2.


Good work


Il 20/11/19 14:12, Richard Barrass ha scritto:


Hello,

I am a lead engineer on project where we run a well-known Linux 
distribution on-top of a SBC (Intel Quad Pentium processor based) 
driving a 27” display. We have a 32GB SSD to run from, which we 
partition with multiple EXT4 partitions to help with potential 
corruption mitigation if the device is switched off ‘hard’.


But, with the well-known Linux distribution comes a lot of things we 
don’t need, plus the potential ability to ‘break’ in to our 
application which is running full-screen.


We basically need

QT 5.12 runtime (our application)

SSH

OpenVPN

Wifi

Ethernet

Modem (via Telit modem)

USB-ACM

USB-Memory stick

Is this something I should be looking to the yocto project for, or 
should I be looking at a more ‘traditional’ custom linux distro.


The only other aspect, is that we have future plans to cost reduce the 
application to be running on a Pi based, 10” display system …


Any thoughts and ideas would be appreciated.

Regards

Richard

*--*

*Richard Barrass*

BassettElectronicSystemsLtd_Logo **

*Bassett Electronic Systems Ltd*. /Solutions under one roof./

T: 01793 859974 E: r.barr...@bassettelectronics.com 



Unit 23-25 Whitehill Industrial Estate, Whitehill Lane, Royal Wootton 
Bassett, Wiltshire, SN4 7DB



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

Re: [yocto] Is Yocto the right fit for my project?

[Mikko.Rapeli]

On Wed, Nov 20, 2019 at 01:12:52PM +, Richard Barrass wrote:
> Hello,
> 
> I am a lead engineer on project where we run a well-known Linux distribution 
> on-top of a SBC (Intel Quad Pentium processor based) driving a 27" display. 
> We have a 32GB SSD to run from, which we partition with multiple EXT4 
> partitions to help with potential corruption mitigation if the device is 
> switched off 'hard'.
> 
> But, with the well-known Linux distribution comes a lot of things we don't 
> need, plus the potential ability to 'break' in to our application which is 
> running full-screen.
> 
> We basically need
> 
> QT 5.12 runtime (our application)
> SSH
> OpenVPN
> Wifi
> Ethernet
> Modem (via Telit modem)
> USB-ACM
> USB-Memory stick
> 
> Is this something I should be looking to the yocto project for, or should I 
> be looking at a more 'traditional' custom linux distro.
> 
> The only other aspect, is that we have future plans to cost reduce the 
> application to be running on a Pi based, 10" display system ...
> 
> Any thoughts and ideas would be appreciated.

Sounds like yocto could fit to your needs well. My personal experiences 
summarized:

Pros with yocto:
 * configuration of everything is possible
 * BSP support available for various SoC's and boards
 * optimization for size and disabling not-needed functionality is relatively 
easy
 * BSP, OS vendor and community support is available
 * licensing policies can be configured for the build, e.g. avoid GPLv3
 * test tooling and infrastructure is provided, ptests and selftests, which can
   be reused for product specific ones
 * documentation is good, mega manual
 * fast moving and following latest open source component releases

Cons with yocto:
 * steep learning curve with bitbake and yocto distro configuration
 * need to recompile everything
 * everything needs to be configured, defaults may not be available
 * long term support not available from community directly, yet at least,
   though OS vendors do provide this for a fee
 * BSP support quality varies and may conflict with non-HW specific SW parts
 * fast moving and following latest open source component releases

Pros with well known Linux distros:
 * default configurations quite often work out of the box
 * no need to recompile everything
 * minimal BSP binaries usually available
 * long term support quite often available
 * large package collection enable fast prototyping
 * larger developer base compared to yocto

Cons with well known Linux distros:
 * dependencies are complex and images larger than needed for product
 * recompiling and customizing large set of packages may be difficult
 * cross compiling may be trickier
 * BSP deliveries may be outdated
 * licensing policies may be hard to implement, e.g. avoid GPLv3 in product 
images
 * integrated test tooling may not be available

In short I would say, with yocto you need to configure and optimize
and figure out how to maintain. With well known Linux distro you will
struggle to configure and optimize but long term maintenance will be
covered by an LTS.

"With enough thrust any pig will fly" :)

Hope this helps,

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

[linux-yocto] [PATCH 1/1] ti-am654x: add the basic scc/cfg enablement

[Jun Miao]

Add scc/cfg kernel fragment to build and boot AM65X GP EVM board.

Signed-off-by: Jun Miao 
---
 bsp/ti-am654x/ti-am654x-standard.scc |   9 ++
 bsp/ti-am654x/ti-am654x.cfg  | 185 +++
 bsp/ti-am654x/ti-am654x.scc  |   8 ++
 3 files changed, 202 insertions(+)
 create mode 100644 bsp/ti-am654x/ti-am654x-standard.scc
 create mode 100644 bsp/ti-am654x/ti-am654x.cfg
 create mode 100644 bsp/ti-am654x/ti-am654x.scc

diff --git a/bsp/ti-am654x/ti-am654x-standard.scc 
b/bsp/ti-am654x/ti-am654x-standard.scc
new file mode 100644
index ..c30282c1
--- /dev/null
+++ b/bsp/ti-am654x/ti-am654x-standard.scc
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE ti-am654x
+define KTYPE standard
+define KARCH arm64
+
+include ktypes/standard/standard.scc
+branch ti-am654x
+
+include ti-am654x.scc
diff --git a/bsp/ti-am654x/ti-am654x.cfg b/bsp/ti-am654x/ti-am654x.cfg
new file mode 100644
index ..bfb24ec8
--- /dev/null
+++ b/bsp/ti-am654x/ti-am654x.cfg
@@ -0,0 +1,185 @@
+#
+#  WARNING
+#
+# This file is a kernel configuration fragment, and not a full kernel
+# configuration file.  The final kernel configuration is made up of
+# an assembly of processed fragments, each of which is designed to
+# capture a specific part of the final configuration (e.g. platform
+# configuration, feature configuration, and board specific hardware
+# configuration).  For more information on kernel configuration, please
+# consult the product documentation.
+#
+#.
+
+#
+#
+# Platform selection
+#
+CONFIG_ARM64=y
+CONFIG_ARCH_K3=y
+
+#
+# DesignWare PCI Core Support
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_MSI_IRQ_DOMAIN=y
+CONFIG_PCI_KEYSTONE=y
+CONFIG_PCI_KEYSTONE_HOST=y
+
+#
+# MMC/SD/SDIO Host Controller Drivers
+#
+CONFIG_MMC=y
+CONFIG_MMC_SPI=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_AM654=y
+
+#
+# Power management options
+#
+CONFIG_PM_SLEEP=y
+CONFIG_PM_SLEEP_SMP=y
+CONFIG_PM=y
+CONFIG_PM_CLK=y
+CONFIG_CPU_PM=y
+
+#
+# CPU Frequency scaling
+#
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_GOV_ATTR_SET=y
+CONFIG_CPU_FREQ_GOV_COMMON=y
+CONFIG_CPU_FREQ_STAT=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
+CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
+
+#
+# CPU frequency scaling drivers
+#
+CONFIG_CPUFREQ_DT=y
+CONFIG_CPUFREQ_DT_PLATDEV=y
+
+#
+# Bus devices
+#
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_OF_PARTS=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+
+#
+# SCSI device support
+#
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+
+#
+# USB
+#
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_OF_SIMPLE=y
+CONFIG_HAS_DMA=y
+CONFIG_OMAP_USB2=y
+CONFIG_USB_DWC3_KEYSTONE=y
+
+#
+# USB for net
+#
+CONFIG_USB_NET_DRIVERS=y
+CONFIG_USB_USBNET=y
+CONFIG_NETDEVICES=y
+CONFIG_USB_NET_AX8817X=y
+
+#
+# Input device support
+#
+CONFIG_INPUT=y
+CONFIG_INPUT_MATRIXKMAP=y
+CONFIG_INPUT_EVDEV=y
+CONFIG_INPUT_KEYBOARD=y
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_INPUT_MOUSE=y
+CONFIG_INPUT_MISC=y
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SERIAL_8250_OMAP=y
+
+#
+# Memory mapped GPIO drivers
+#
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_DAVINCI=y
+
+#
+# I2C support
+#
+CONFIG_I2C=y
+CONFIG_I2C_BOARDINFO=y
+CONFIG_I2C_COMPAT=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MUX=y
+CONFIG_I2C_OMAP=y
+
+#
+# SPI Master Controller Drivers
+#
+CONFIG_SPI=y
+CONFIG_SPI_MASTER=y
+CONFIG_SPI_MEM=y
+CONFIG_SPI_OMAP24XX=y
+
+#
+# DMA Devices
+#
+CONFIG_DMADEVICES=y
+CONFIG_DMA_ENGINE=y
+CONFIG_DMA_OF=y
+
+#
+# Common Clock Framework
+#
+CONFIG_TI_SCI_CLK=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_TI_SCI_CLK_PROBE_FROM_FW=y
+
+#
+# Qualcomm SoC drivers
+#
+CONFIG_SOC_TI=y
+CONFIG_TI_SCI_PM_DOMAINS=y
+
+#
+# IRQ chip support
+#
+CONFIG_IRQCHIP=y
+CONFIG_ARM_GIC_V3=y
+CONFIG_ARM_GIC_V3_ITS=y
+CONFIG_ARM_GIC_V3_ITS_PCI=y
+CONFIG_TI_SCI_INTR_IRQCHIP=y
+CONFIG_TI_SCI_INTA_IRQCHIP=y
+CONFIG_RESET_CONTROLLER=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_RESET_TI_SYSCON=y
+
+#
+# PHY Subsystem
+#
+CONFIG_GENERIC_PHY=y
+CONFIG_PHY_XGENE=y
+CONFIG_PHY_AM654_SERDES=y
+CONFIG_PHYLIB=y
+CONFIG_NETDEVICES=y
+CONFIG_DP83867_PHY=y
diff --git a/bsp/ti-am654x/ti-am654x.scc b/bsp/ti-am654x/ti-am654x.scc
new file mode 100644
index ..f7bcdceb
--- /dev/null
+++ b/bsp/ti-am654x/ti-am654x.scc
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: MIT
+include cfg/usb-mass-storage.scc
+include cfg/fs/flash_fs.cfg
+include features/hugetlb/hugetlb.scc
+# Enable the ability to run 32 bit apps
+include arch/arm/32bit-compat.scc
+
+kconf hardware ti-am654x.cfg
-- 
2.17.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org

[linux-yocto] [yocto-kernel-cache master]: ti-am654x

[Jun Miao]

Hi Bruce,
 
I am working ti AM65x GP EVM Board with am654x soc.
Could you help me add this scc/cfg patch to yocto-kernel-cache master 
branch ?

Thanks


Jun Miao (1):
  ti-am654x: add the basic scc/cfg enablement

 bsp/ti-am654x/ti-am654x-standard.scc |   9 ++
 bsp/ti-am654x/ti-am654x.cfg  | 185 +++
 bsp/ti-am654x/ti-am654x.scc  |   8 ++
 3 files changed, 202 insertions(+)
 create mode 100644 bsp/ti-am654x/ti-am654x-standard.scc
 create mode 100644 bsp/ti-am654x/ti-am654x.cfg
 create mode 100644 bsp/ti-am654x/ti-am654x.scc

-- 
2.17.1

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

Re: [yocto] Is Yocto the right fit for my project?

[Josef Holzmayr]

Howdy!

On Wed, Nov 20, 2019 at 01:12:52PM +, Richard Barrass wrote:
> Hello,
> 
> I am a lead engineer on project where we run a well-known Linux distribution 
> on-top of a SBC (Intel Quad Pentium processor based) driving a 27" display. 
> We have a 32GB SSD to run from, which we partition with multiple EXT4 
> partitions to help with potential corruption mitigation if the device is 
> switched off 'hard'.
> 
> But, with the well-known Linux distribution comes a lot of things we don't 
> need, plus the potential ability to 'break' in to our application which is 
> running full-screen.
> 
> We basically need
> 
> QT 5.12 runtime (our application)
> SSH
> OpenVPN
> Wifi
> Ethernet
> Modem (via Telit modem)
> USB-ACM
> USB-Memory stick
> 
> Is this something I should be looking to the yocto project for, or should I 
> be looking at a more 'traditional' custom linux distro.

Certainly doable.

> 
> The only other aspect, is that we have future plans to cost reduce the 
> application to be running on a Pi based, 10" display system ...

If thats a set goal, then it makes YP even more interesting for you.

> 
> Any thoughts and ideas would be appreciated.

Prepare for a steep learning curve and a lot of headshaking each time
you say "but I just want to". But you will be rewarded with an awesome
amount of control and power if you make it through.

Have a look at 
https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj
to get an idea how things work.

Greetz

> 
> Regards
> Richard
> 
> --
> Richard Barrass
> 
> [BassettElectronicSystemsLtd_Logo]
> Bassett Electronic Systems Ltd. Solutions under one roof.
> T: 01793 859974 E: 
> r.barr...@bassettelectronics.com
> Unit 23-25 Whitehill Industrial Estate, Whitehill Lane, Royal Wootton 
> Bassett, Wiltshire, SN4 7DB
> 



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


-- 
———
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

Re: [yocto] Is Yocto the right fit for my project?

[Nicolas Dechesne]

hey,

On Thu, Nov 21, 2019 at 10:16 AM Richard Barrass
 wrote:
>
> Hello,
>
>
>
> I am a lead engineer on project where we run a well-known Linux distribution 
> on-top of a SBC (Intel Quad Pentium processor based) driving a 27” display. 
> We have a 32GB SSD to run from, which we partition with multiple EXT4 
> partitions to help with potential corruption mitigation if the device is 
> switched off ‘hard’.
>
>
>
> But, with the well-known Linux distribution comes a lot of things we don’t 
> need, plus the potential ability to ‘break’ in to our application which is 
> running full-screen.
>
>
>
> We basically need
>
>
>
> QT 5.12 runtime (our application)
>
> SSH
>
> OpenVPN
>
> Wifi
>
> Ethernet
>
> Modem (via Telit modem)
>
> USB-ACM
>
> USB-Memory stick
>
>
>
> Is this something I should be looking to the yocto project for, or should I 
> be looking at a more ‘traditional’ custom linux distro.

The way you ask the question, you seem to already know the answer ;)

Based on tools, metadata and processes provided by the Yocto Project
and OpenEmbedded, you will be able to create *the* Linux system that
fits your exact needs and requirements. You can customize the content
of the system (image), and also the features you need from each
component that make up the whole system (distro). Doing that with the
Yocto Project means that you are using a standard tool that many
people are familiar with, so it's definitely better than starting your
own custom Linux, or starting to randomly try to trim down an existing
standard Linux distro.

>
>
>
> The only other aspect, is that we have future plans to cost reduce the 
> application to be running on a Pi based, 10” display system …

The project is architecture agnostic. So once you have defined your
distro (system config) and your image (system content), you can build
the *same* Linux system for any hardware, even for different
architecture, using the same tools, same metadata, same CI scripts,
... you just need to integrate a BSP layer that provides kernel,
bootloader and hardware specific content.

>
>
>
> Any thoughts and ideas would be appreciated.

On top of that you get to work with our great community ;)

>
>
>
> Regards
>
> Richard
>
>
>
> --
>
> Richard Barrass
>
>
>
> Bassett Electronic Systems Ltd. Solutions under one roof.
>
> T: 01793 859974 E: r.barr...@bassettelectronics.com
>
> Unit 23-25 Whitehill Industrial Estate, Whitehill Lane, Royal Wootton 
> Bassett, Wiltshire, SN4 7DB
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-cgl][PATCH 1/2] core-image-cgl/core-image-cgl-initramfs: remove them

[Changqing Li]

ping

On 9/17/19 4:04 PM, changqing...@windriver.com wrote:

From: Changqing Li 

remove core-image-cgl.bb and core-image-cgl-initramfs.bb

* They require core-image-lsb.bb which has been removed by oe-core

* Even before LSB support is dropped by oe-core, core-image-cgl
   and core-image-cgl-initramfs cannot build success, failed during
   do_rootfs with below error, so I suppose that no one use these
   2 recipes, so remove it

Error:
  Problem: package logcheck-1.3.20-r0.core2_64 requires rsyslog, but none of 
the providers can be installed
   - package rsyslog-8.1907.0-r0.core2_64 conflicts with sysklogd provided by 
sysklogd-1.5.1-r0.core2_64
   - package sysklogd-1.5.1-r0.core2_64 conflicts with rsyslog provided by 
rsyslog-8.1907.0-r0.core2_64
   - package packagegroup-cgl-applications-1.0-r0.noarch requires logcheck, but 
none of the providers can be installed
   - package packagegroup-core-full-cmdline-initscripts-1.0-r6.noarch requires 
sysklogd, but none of the providers can be installed
   - package packagegroup-cgl-1.0-r0.noarch requires 
packagegroup-cgl-applications, but none of the providers can be installed
   - package packagegroup-core-full-cmdline-1.0-r6.noarch requires 
packagegroup-core-full-cmdline-initscripts, but none of the providers can be 
installed

Signed-off-by: Changqing Li 
---
  meta-cgl-common/images/core-image-cgl-initramfs.bb | 19 ---
  meta-cgl-common/images/core-image-cgl.bb   | 28 --
  2 files changed, 47 deletions(-)
  delete mode 100644 meta-cgl-common/images/core-image-cgl-initramfs.bb
  delete mode 100644 meta-cgl-common/images/core-image-cgl.bb

diff --git a/meta-cgl-common/images/core-image-cgl-initramfs.bb 
b/meta-cgl-common/images/core-image-cgl-initramfs.bb
deleted file mode 100644
index 67cb4c1..000
--- a/meta-cgl-common/images/core-image-cgl-initramfs.bb
+++ /dev/null
@@ -1,19 +0,0 @@
-require core-image-cgl.bb
-
-# Recipe is based on core-image-minimal.bb
-DESCRIPTION = "Initramfs used to mount multipath device as root file system"
-
-PACKAGE_INSTALL = "initramfs-cgl-boot busybox base-passwd udev"
-
-# Do not pollute the initrd image with rootfs features
-IMAGE_FEATURES = ""
-
-export IMAGE_BASENAME = "core-image-cgl-initramfs"
-IMAGE_LINGUAS = ""
-
-LICENSE = "MIT"
-IMAGE_FSTYPES ??= "cpio.gz.u-boot"
-
-IMAGE_ROOTFS_SIZE = "8192"
-
-BAD_RECOMMENDATIONS += "busybox-syslog"
diff --git a/meta-cgl-common/images/core-image-cgl.bb 
b/meta-cgl-common/images/core-image-cgl.bb
deleted file mode 100644
index 86bf7d4..000
--- a/meta-cgl-common/images/core-image-cgl.bb
+++ /dev/null
@@ -1,28 +0,0 @@
-require recipes-extended/images/core-image-lsb.bb
-
-
-VALGRIND ?= ""
-VALGRIND_powerpc ?= "valgrind"
-VALGRIND_e500v2 ?= ""
-VALGRIND_x86 ?= "valgrind"
-VALGRIND_x86_64 ?= "valgrind"
-VALGRIND_armv7a ?= "valgrind"
-
-# Include modules in rootfs
-IMAGE_INSTALL += "\
-packagegroup-core-buildessential \
-packagegroup-core-selinux \
-packagegroup-cgl \
-kexec-tools \
-lttng-tools \
-lttng-modules \
-${VALGRIND} \
-"
-
-IMAGE_FSTYPES += " ext3.gz"
-
-# kexec-tools doesn't work on Mips
-KEXECTOOLS_mips ?= ""
-KEXECTOOLS_mipsel ?= ""
-
-IMAGE_FEATURES += "tools-debug tools-profile"

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

Re: [yocto-announce] Mailing list platform change November 21st

[Michael Halstead]

The window for the mailing list move has shifted forward to November 21st
from 4pm to 8pm Pacific Standard Time. (2019-11-22 00:00-04:00 UTC)

Moderators please tend to all pending requests today.

Thank you,
--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

On Fri, Nov 15, 2019 at 4:25 PM Michael Halstead <
mhalst...@linuxfoundation.org> wrote:

> After backing out of the first attempt to migrate we are again moving
> our lists from Mailman to Groups.io. E-mail to lists will be delayed
> during the move window on November 21st between 17:00 and 23:00 UTC.
>
> A new account will be created for you on the Groups.io platform and most
> users will only need to update their list mailing address from the
> @yoctoproject.org to @lists.yoctoproject.org.
>
> Moderators please attend to all pending requests next Wednesday November
> 20th.
>
> Please read more about the change on the wiki:
>
> https://wiki.yoctoproject.org/wiki/index.php?title=GroupsMigration
>
> If there are serious issues we will rollback the changes. We will e-mail
> all lists when work is complete.
>
> --
> Michael Halstead
> Linux Foundation / Yocto Project
> Systems Operations Engineer
>
-- 
___
yocto-announce mailing list
yocto-announce@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto-announce

Re: [yocto] Mailing list platform change November 21st

[Michael Halstead]

The window for the mailing list move has shifted forward to November 21st
from 4pm to 8pm Pacific Standard Time. (2019-11-22 00:00-04:00 UTC)

Moderators please tend to all pending requests today.

Thank you,
--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

On Fri, Nov 15, 2019 at 4:25 PM Michael Halstead <
mhalst...@linuxfoundation.org> wrote:

> After backing out of the first attempt to migrate we are again moving
> our lists from Mailman to Groups.io. E-mail to lists will be delayed
> during the move window on November 21st between 17:00 and 23:00 UTC.
>
> A new account will be created for you on the Groups.io platform and most
> users will only need to update their list mailing address from the
> @yoctoproject.org to @lists.yoctoproject.org.
>
> Moderators please attend to all pending requests next Wednesday November
> 20th.
>
> Please read more about the change on the wiki:
>
> https://wiki.yoctoproject.org/wiki/index.php?title=GroupsMigration
>
> If there are serious issues we will rollback the changes. We will e-mail
> all lists when work is complete.
>
> --
> Michael Halstead
> Linux Foundation / Yocto Project
> Systems Operations Engineer
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Is Yocto the right fit for my project?

[Richard Barrass]

Hello,

I am a lead engineer on project where we run a well-known Linux distribution 
on-top of a SBC (Intel Quad Pentium processor based) driving a 27" display. We 
have a 32GB SSD to run from, which we partition with multiple EXT4 partitions 
to help with potential corruption mitigation if the device is switched off 
'hard'.

But, with the well-known Linux distribution comes a lot of things we don't 
need, plus the potential ability to 'break' in to our application which is 
running full-screen.

We basically need

QT 5.12 runtime (our application)
SSH
OpenVPN
Wifi
Ethernet
Modem (via Telit modem)
USB-ACM
USB-Memory stick

Is this something I should be looking to the yocto project for, or should I be 
looking at a more 'traditional' custom linux distro.

The only other aspect, is that we have future plans to cost reduce the 
application to be running on a Pi based, 10" display system ...

Any thoughts and ideas would be appreciated.

Regards
Richard

--
Richard Barrass

[BassettElectronicSystemsLtd_Logo]
Bassett Electronic Systems Ltd. Solutions under one roof.
T: 01793 859974 E: 
r.barr...@bassettelectronics.com
Unit 23-25 Whitehill Industrial Estate, Whitehill Lane, Royal Wootton Bassett, 
Wiltshire, SN4 7DB

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

[yocto] Device is unable to BOOT or INSTALL with generated .hddimg

[Oriya, Raxesh]

All,

I have device which has following configuration:

- Chipset architecture - `Intel NM10 express`
- Processor - `Atom D2550 Dual Core`
- Display - `DVI`
- Volatile Memory - `2GB DDR3`
- Storage - `16GB`

**Objective**: Device should run yocto embededded OS successfully

What I have done,

- Downloaded three required yocto layers for warrior branch i.e. 1. poky 2. 
meta-openembedded 3. meta-intel
- Modified `local.conf` with `MACHINE ??= "intel-core2-32"`
- Ran `source poky/oe-init-build-env`
- Generated `.hddimg` by bitbake `core-image-minimal`
- Flashed `.hddimg` to thumb drive through `dd` command

Attached thumb drive to device and I could see BOOT and INSTALL option, upon 
clicking any of them nothing happens(not even logs) i.e. Blank screen

Troubleshooting I tried out are,

1. Tried to boot `lubuntu` and it was successful
2. Replaced kernel & initrd of `lubuntu` with yocto's one and booting was 
successful which indicates there is no issue with kernel or initrd in `.hddimg` 
generated by yocto
3. Tried some experiment with `syslinux` as well but didn't work out

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

[yocto] Installing a Kernel module.

[Shravan Singh]

Hello All,

So I am having a little problem in understanding why I am unable to
autoload a module in my image.

So I made modifications to
1. KCONFIG, MAKEFILE
2. Added a source and header file to driver/input/touchscreen
3. Added a file in /boot/arm/dts/overlays
4. Created a patch and added that patch in
/meta-raspberrypi-warrior/recipes/kernel/linux/linux-raspberrypi_4.19.bb
5. Added the overlay file in rpi_base.inc
6. In my local.conf added it under KERNEL_MODULE_AUTOLOAD_append

created the image without any issues. But after I install that Image I do
not see the module anymore?

Why Is that Am I missing something?


Regards,
Shravan Singh
(239) 243-0838

Blue Sparq, Inc.
928 NE 24th Lane unit 4 and 5.
Cape Coral, FL 33993

IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only. If you have received
this email by mistake, please notify the sender immediately and do not
disclose the contents to anyone or make copies thereof.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Memory Tests in U-Boot

[devendra . devadiga]

Hi,

In U-Boot I found some generic memory tests commands like mtest and post 
tests. But I need complete DDR4 memory test with below algorithms:


* Checkerboard Test
* March C- Test
* Neighborhood Pattern Sensitive Fault

Can I get any reference code for these algorithms in U-Boot ?
Implementation for these algorithms available in any of U-Boot version ?

Thanks and Regards,
Devendra
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] :how to solve the basehash value changed from 'xxx' to 'aaaa' ?

[Mike Looijmans]

Without your recipe source code, no one can tell for sure, but I suspect you 
have something like a "DATE" in there that evaulates to a different value if 
you run it a second later.


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
Postbus 440, 5680 AK Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 13-11-19 04:09, www wrote:
> Dear all,
> 
> When I modify the os-release file in my yocto project, it appear some error, 
> and how can I solve it ? Who can give me some help or advice? Thank you！
> I carried out the recommended order and it didn't work.
> 
> /ERROR: os-release-1.0-r0 do_compile: Taskhash mismatch 
> ce133f0458608e03aa55224df28156e523e54903115efbbcd62946f84a867201 versus 
> 7269881f0eb1759ed420a2db4c04fb477cd8c1288bc5f82df5c8161bb926ea1f for 
> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile/
> /ERROR: Taskhash mismatch 
> ce133f0458608e03aa55224df28156e523e54903115efbbcd62946f84a867201 versus 
> 7269881f0eb1759ed420a2db4c04fb477cd8c1288bc5f82df5c8161bb926ea1f for 
> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile/
> /ERROR: When reparsing 
> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile,
>  
> //the basehash value changed from 
> 99a42a1a3b1a151de604267b159558ecaf1031a3bec8917df132c81302e729a5 to 
> 4f3288a8763e2e1af78e4b3cdd9c0c0ccb3b0d5c78a3073c188b22200df2a9b0. //The 
> metadata is not deterministic and this needs to be fixed./
> /ERROR: The following commands may help:/
> /ERROR: $ bitbake os-release -cdo_compile -Snone/
> /ERROR: Then:/
> /ERROR: $ bitbake os-release -cdo_compile -Sprintdiff/
> 
> /ERROR: When reparsing 
> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile,
>  
> //the basehash value changed from 
> 99a42a1a3b1a151de604267b159558ecaf1031a3bec8917df132c81302e729a5 to 
> 47c30012daa6aa77be09a93fe21e66995361ef26b4487111005617db8cb4de59. The 
> metadata 
> is not deterministic and this needs to be fixed./
> /ERROR: The following commands may help:/
> /ERROR: $ bitbake os-release -cdo_compile -Snone/
> /ERROR: Then:/
> /ERROR: $ bitbake os-release -cdo_compile -Sprintdiff/
> 
> thanks,
> Byron
> 
> 
> 

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