[yocto] Building multiple U-Boot binaries (with different patch sets)

[Andrei Faur]

Hello,

My scenario is the following: I have two sets of U-Boot patches and I want to
create two separate images, each one containing a U-Boot built with one of the
patch sets. Everything else in the two images (kernel, rootfs) is the same. I am
using Yocto Rocko.


Searching this list and various other forums I found several ways of doing this:

1. Use two machine files and then in u-boot-imx_%.bbappend:
  SRC_URI_machine1 += "file://patch1.patch \
   file://patch2.patch"
  SRC_URI_machine2 += "file://patch3.patch \
   file://patch4.patch"

2. Try to do something like this
https://www.yoctoproject.org/docs/2.4.2/mega-manual/mega-manual.html#platdev-building-targets-with-multiple-configurations
https://lists.yoctoproject.org/pipermail/yocto/2017-October/038460.html

3. Find a way to expand on this approach, where separate U-Boot images are built
based on UBOOT_CONFIG:
https://lists.yoctoproject.org/pipermail/meta-freescale/2016-January/017257.html


My issue with 1. is that it is abusing the "machine" concept a bit since I am
not really building for separate targets.

The problem with 2. is that it feels like a very heavyweight approach to solve
an issue which is (in theory at least) very light: one recipe (U-Boot in this
case) needs to be built differently depending on which image it ends up in. Yes,
I know that is not how the system works:
https://lists.yoctoproject.org/pipermail/yocto/2014-June/020083.html
But still, that is my use case.

I find 3. to be the most straightforward approach but my problem is that I don't
know how to modify the SRC_URI variable depending on UBOOT_CONFIG. I am not even
sure if this is possible to do, can compilation be triggered twice based on
UBOOT_CONFIG at all?


Is there a recommended way of doing this? Are there any other approaches?

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

[yocto] fb: switching to inteldrmfb from efi vga

[Knoppix]

yocto and meta-intel: 2.5.1/sumo
kernel=linux-yocto-4.15.18
machine=intel-corei7-64
distro=poky

the problem is:
when I boot the system it comes to this message and frozees: " fb:
switching to amdgpudrmfb from efi vga"

I searched a lot, there is a workaround to solve problem (add
nomodeset to grub params) but when i set this splash screen doesn't
work. (also someone on stackoverflow says when you do nomodeset you
cannot use graphical acceleration.)

There are a lot of old messages about this spesific problem which they
say "it is solved in new version of kernel" or "a new intel drm-fix
will solve" but I came accros the problem now.

Would you please advice me any tutorial to learn what's going on?

(Excuse me for my english, I am not native)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-intel] fb: switching to inteldrmfb from efi vga

[Mittal, Anuj]

On Tue, 2018-11-13 at 12:30 +0300, Knoppix wrote:
> yocto and meta-intel: 2.5.1/sumo
> kernel=linux-yocto-4.15.18
> machine=intel-corei7-64
> distro=poky
> 
> the problem is:
> when I boot the system it comes to this message and frozees: " fb:
> switching to amdgpudrmfb from efi vga"

This error says amdgpu while the subject says intel driver ... Which
one are you using and on which graphics card?

Does it work if you use 4.14 kernel?

> 
> I searched a lot, there is a workaround to solve problem (add
> nomodeset to grub params) but when i set this splash screen doesn't
> work. (also someone on stackoverflow says when you do nomodeset you
> cannot use graphical acceleration.)
> 
> There are a lot of old messages about this spesific problem which
> they
> say "it is solved in new version of kernel" or "a new intel drm-fix
> will solve" but I came accros the problem now.
> 
> Would you please advice me any tutorial to learn what's going on?
> 
> (Excuse me for my english, I am not native)

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

[yocto] meta-mingw: unable to run executables on Windows

[Samuli Piippo]

Hi,

I've just upgraded poky and meta-mingw layers from sumo to thud and as a
result a lot of the executables in the toolchain no longer run correctly on
Windows.

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++
work fine on Windows 10, but ar, as, objdumb, and others hang for ~30
seconds and exit without any output.

Has anyone else seen this?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-mingw: unable to run executables on Windows

[Burton, Ross]

On Tue, 13 Nov 2018 at 09:57, Samuli Piippo  wrote:
> I've just upgraded poky and meta-mingw layers from sumo to thud and as a 
> result a lot of the executables in the toolchain no longer run correctly on 
> Windows.
>
> I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ 
> work fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds 
> and exit without any output.
>
> Has anyone else seen this?

I suspect we need to find a maintainer who actually uses meta-mingw
and can actually test it.  Would you be willing to bisect thud to sumo
to identify where it breaks?

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

[yocto] lib32-glibc headers populated instead glibc headers in the SDK toolchain - yocto 2.2.2

[ravi chandran]

Hi all,
I am working in one project where both lib32 & lib64 need to be supported. 
Hence, lib32-glibc & glibc both are there in yocto build. In the final 
toolchain, after running "bitbake  -c populate-sdk", it is randomly, 
lib32-glibc headers are getting populated instead of glibc headers.
Ex: in the toolchain, /aarch64/usr/include/bits/endian.h - 
lib32-glibc header file content seen instead glibc header file content.
Please let me know if anybody has any solution/work-around for this.
Thanks in advance,Ravi-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Set linux capabilities on binary on a recipe in meta-oe layer

[Uwe Geuder]

On Mon, Nov 12, 2018 at 3:09 PM Markus W markus4dev-at-gmail.com wrote:
>
> Thanks Uwe!
>
> I tried the global approach by adding the following to my local.conf file:
>
> ROOTFS_POSTPROCESS_COMMAND += "my_setcap_function"
>
> my_setcap_function() {
> setcap cap_net_raw+eip ${IMAGE_ROOTFS}/usr/bin/node
> }
>
> But got the following warning:
> WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Function 
> my_setcap_function doesn't exist
>
> I have tried to add the function into a recipe but this doesn't work either. 
> Where should the function be defined?
>

As I wrote

>> This is done in your image recipe.

At least this is where I do it and it works for me.

My use of "global" was probably not so lucky, I did not mean bitbake
configuration.  I just meant that it is done in the image recipe and not
in the node recipe.

You can always use "bitbake -e" to check variable and recipe function
definitions if you are wondering what is really going on. I often
understand problems when looking at the listing produced by this
command. In your case "bitbake -e core-image-full-cmdline"

There are also other functions in the value of ROOTFS_POSTPROCESS_COMMAND so as


On Tue, Nov 13, 2018 at 4:09 AM Mike Looijmans mike.looijmans-at-topic.nl wrote:
>
> Also, there's a semicolon missing:
> ROOTFS_POSTPROCESS_COMMAND += "my_setcap_function;"
>

The final value of ROOTFS_POSTPROCESS_COMMAND as shown by "bitbake -e"
should be list of function names separated by semicolons.

My previous link was broken, hopefully this time it survives intact...

https://www.yoctoproject.org/docs/2.5.1/mega-manual/mega-manual.html#var-ROOTFS_POSTPROCESS_COMMAND

> Sometimes the problem is that parts of the underscored function name are seen
> as overrides, so you should try using "mysetcapfunction" instead as a name.
>

That has never happened to me and I use underscores in my function
names. But I could imagine that it's possible in some case. I would
strongly expect to see such issue in the output of "bitbake -e", too.


Regards,

Uwe Geuder
Neuro Event Labs Oy
Tampere, Finland
uwe.gex...@neuroeventlabs.com (Bot check: fix one obvious typo)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-mingw: unable to run executables on Windows

[Samuli Piippo]

On Tue, 13 Nov 2018 at 12:17, Burton, Ross  wrote:
>
> On Tue, 13 Nov 2018 at 09:57, Samuli Piippo  wrote:
> > I've just upgraded poky and meta-mingw layers from sumo to thud and as a 
> > result a lot of the executables in the toolchain no longer run correctly on 
> > Windows.
> >
> > I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ 
> > work fine on Windows 10, but ar, as, objdumb, and others hang for ~30 
> > seconds and exit without any output.
> >
> > Has anyone else seen this?
>
> I suspect we need to find a maintainer who actually uses meta-mingw
> and can actually test it.  Would you be willing to bisect thud to sumo
> to identify where it breaks?

I can try to setup some kind of automatic bisect run script to test this.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto x64-linux with bootia32.efi

[Knoppix]

Thanks a lot. 🙏


On Tue, Nov 13, 2018 at 10:42 AM Dimitris Tassopoulos 
wrote:

> That's great news!
> Glad to help. It's frustrating some times, but I hope that also someone
> else may come with a better solution.
>
> Regarding secureboot, I guess that if you use the same keys, then there
> shouldn't be any issue. But I haven't use it, so I can't tell from
> experience.
>
> Regards,
> Dimitris
>
> On Tue, 13 Nov 2018, 08:28 Knoppix 
>> it works!
>> It copied files to ESP (efi system partition).
>> I hope it will work with secure boot concept too.
>>
>> *Mr. Dimitris *thank you so so much. I *am so glad to you* for your
>> politeness and help.
>>
>> My best compliments..
>>
>> On Mon, Nov 12, 2018 at 5:51 PM Dimitris Tassopoulos 
>> wrote:
>>
>>> Yeah, I think everybody is pretty busy. This project is huge and there
>>> aren't many contributors.
>>>
>>> Anyway, in case you use wks files, then you can create a file named 
>>> *test.wks.in
>>> * (make sure you add
>>> the .in at the end). Then add this (or similar depending your image):
>>>
>>> bootloader --ptable gpt
>>> part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot
>>> --fstype=vfat --ondisk sda --label boot --active --align 1024
>>> part / --source rootfs --ondisk sda --fstype=ext4 --label root --align
>>> 1024 --exclude-path boot/
>>>
>>> The above will force wic tool not to use the default efi file that yocto
>>> produces and it will use the content of the /boot
>>> folder your image creates. Therefore, if you add your custom recipe that
>>> copies the efi file you want, *but also* the
>>> the rest of the boot files (like confs) then you can override the
>>> image-efi and use your custom files from the recipe.
>>>
>>> For example, keep a copy of the whole boot folder that you already have,
>>> then replace the efi file with your
>>> precompiled and then create a recipe to copy all those files to your
>>> image's /boot folder.
>>>
>>> I think that this may do the trick.
>>>
>>> The important keywords in the wks file are the `--rootfs-dir` in the
>>> /boot part, which means that you force wic
>>> to use your image's /boot folder. And the `--exclude-path` which forces
>>> wic tool not to touch your /boot folder.
>>>
>>> Best regards,
>>> Dimitris
>>>
>>> On Mon, Nov 12, 2018 at 3:37 PM Knoppix  wrote:
>>>
 Yes I did this before I sent this email. First I created x86_32 system
 and backup boot files. Then i created regular x64 system and move
 bootia32.efi file to the boot partition. (I did manualy)
 And yes I'm using wic and I have wks file. (I dont know how can i copy
 my bootia32.efi to boot partition when yocto has create image)

 But very soon I should implement secure boot with the system.
 So I think copy precompilted bootia32.efi will not work with secure
 system. (I am not sure)

 By the way this is the first mail which I took any maillist system. I'm
 so happy to experiment this feeling :) until now nobody answers me.
 Kind regards.

 On Mon, Nov 12, 2018 at 5:20 PM Dimitris Tassopoulos 
 wrote:

> You're right about the toolchain, this will hit wall, because the
> x86_64 will build fail to build the x86 efi.
>
> Are you using wic and a wks file for your image?
>
> There might be a way to override the x86_64 efi bootloader with a
> pre-compiled one.
> If you do, then I may have a solution for you.
>
> Regards,
> Dimitris
>
> On Mon, Nov 12, 2018 at 2:39 PM Knoppix  wrote:
>
>> Mr. Tassopoulos
>>
>> Thank you so much for your answer.
>>
>> I am trying to do this because my device (atom cpu) has 64bit cpu but
>> its efi doesn't support 64. Efi is x86. I learned that ".. The vast
>> majority of EFI-based x86-64 computers use 64-bit EFIs and therefore use 
>> a
>> bootx64.efi default boot loader file. A handful of early Macs and some
>> Atom-based tablets have 64-bit CPUs but 32-bit EFIs ..."
>> http://www.rodsbooks.com/efi-bootloaders/principles.html
>>
>> But I dont understand: if my target machine is x86_64 then yocto will
>> prepare native/host toolchain to gcc-x64 but when we force to install 
>> grub
>> as i386 what will happen? yocto will install a second toolchain for i386?
>> And also shouldn't grub be x86?
>>
>> Bye the way, yocto has failed when i try.
>>
>> *do_mkimage*
>> DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc',
>> 'bit-64', 'x86_64-linux', 'common']
>> DEBUG: Executing shell function do_mkimage
>> *grub-mkimage: error: invalid ELF header.*
>> WARNING: exit code 1 from a shell command.
>>
>>
>> Best regards
>>
>>
>> On Mon, Nov 12, 2018 at 11:44 AM Dimitris Tassopoulos <
>> dimt...@gmail.com> wrote:
>>
>>> I don't know about your special case and why this happens, but a
>>> simple "hack" it's, depending your bootl

Re: [yocto] yocto x64-linux with bootia32.efi

[Knoppix]

By the way I hope someone will fix this.

On Tue, Nov 13, 2018 at 5:38 PM Knoppix  wrote:

> Thanks a lot. 🙏
>
>
> On Tue, Nov 13, 2018 at 10:42 AM Dimitris Tassopoulos 
> wrote:
>
>> That's great news!
>> Glad to help. It's frustrating some times, but I hope that also someone
>> else may come with a better solution.
>>
>> Regarding secureboot, I guess that if you use the same keys, then there
>> shouldn't be any issue. But I haven't use it, so I can't tell from
>> experience.
>>
>> Regards,
>> Dimitris
>>
>> On Tue, 13 Nov 2018, 08:28 Knoppix >
>>> it works!
>>> It copied files to ESP (efi system partition).
>>> I hope it will work with secure boot concept too.
>>>
>>> *Mr. Dimitris *thank you so so much. I *am so glad to you* for your
>>> politeness and help.
>>>
>>> My best compliments..
>>>
>>> On Mon, Nov 12, 2018 at 5:51 PM Dimitris Tassopoulos 
>>> wrote:
>>>
 Yeah, I think everybody is pretty busy. This project is huge and there
 aren't many contributors.

 Anyway, in case you use wks files, then you can create a file named 
 *test.wks.in
 * (make sure you add
 the .in at the end). Then add this (or similar depending your image):

 bootloader --ptable gpt
 part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot
 --fstype=vfat --ondisk sda --label boot --active --align 1024
 part / --source rootfs --ondisk sda --fstype=ext4 --label root --align
 1024 --exclude-path boot/

 The above will force wic tool not to use the default efi file that
 yocto produces and it will use the content of the /boot
 folder your image creates. Therefore, if you add your custom recipe
 that copies the efi file you want, *but also* the
 the rest of the boot files (like confs) then you can override the
 image-efi and use your custom files from the recipe.

 For example, keep a copy of the whole boot folder that you already
 have, then replace the efi file with your
 precompiled and then create a recipe to copy all those files to your
 image's /boot folder.

 I think that this may do the trick.

 The important keywords in the wks file are the `--rootfs-dir` in the
 /boot part, which means that you force wic
 to use your image's /boot folder. And the `--exclude-path` which forces
 wic tool not to touch your /boot folder.

 Best regards,
 Dimitris

 On Mon, Nov 12, 2018 at 3:37 PM Knoppix  wrote:

> Yes I did this before I sent this email. First I created x86_32 system
> and backup boot files. Then i created regular x64 system and move
> bootia32.efi file to the boot partition. (I did manualy)
> And yes I'm using wic and I have wks file. (I dont know how can i copy
> my bootia32.efi to boot partition when yocto has create image)
>
> But very soon I should implement secure boot with the system.
> So I think copy precompilted bootia32.efi will not work with secure
> system. (I am not sure)
>
> By the way this is the first mail which I took any maillist system.
> I'm so happy to experiment this feeling :) until now nobody answers me.
> Kind regards.
>
> On Mon, Nov 12, 2018 at 5:20 PM Dimitris Tassopoulos <
> dimt...@gmail.com> wrote:
>
>> You're right about the toolchain, this will hit wall, because the
>> x86_64 will build fail to build the x86 efi.
>>
>> Are you using wic and a wks file for your image?
>>
>> There might be a way to override the x86_64 efi bootloader with a
>> pre-compiled one.
>> If you do, then I may have a solution for you.
>>
>> Regards,
>> Dimitris
>>
>> On Mon, Nov 12, 2018 at 2:39 PM Knoppix  wrote:
>>
>>> Mr. Tassopoulos
>>>
>>> Thank you so much for your answer.
>>>
>>> I am trying to do this because my device (atom cpu) has 64bit cpu
>>> but its efi doesn't support 64. Efi is x86. I learned that ".. The vast
>>> majority of EFI-based x86-64 computers use 64-bit EFIs and therefore 
>>> use a
>>> bootx64.efi default boot loader file. A handful of early Macs and some
>>> Atom-based tablets have 64-bit CPUs but 32-bit EFIs ..."
>>> http://www.rodsbooks.com/efi-bootloaders/principles.html
>>>
>>> But I dont understand: if my target machine is x86_64 then yocto
>>> will prepare native/host toolchain to gcc-x64 but when we force to 
>>> install
>>> grub as i386 what will happen? yocto will install a second toolchain for
>>> i386? And also shouldn't grub be x86?
>>>
>>> Bye the way, yocto has failed when i try.
>>>
>>> *do_mkimage*
>>> DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc',
>>> 'bit-64', 'x86_64-linux', 'common']
>>> DEBUG: Executing shell function do_mkimage
>>> *grub-mkimage: error: invalid ELF header.*
>>> WARNING: exit code 1 from a shell command.
>>>
>>>
>>> Best reg

[yocto] Yocto Project Status WW46’18

[Jolley, Stephen K]

Current Dev Position: YP 2.6 M4 is in preparing for release.

Next Deadline: YP 2.6 M4 Release Target was Oct. 26, 2018


SWAT Team Rotation:

· SWAT lead is currently: Armin

· SWAT team rotation: Armin -> Paul on Nov. 16, 2018

· SWAT team rotation: Paul -> Ross on Nov. 23, 2018

· https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

· YP 2.6 M4 rc1 has in completed QA and should release this week.  See 
the  QA Report: 
https://wiki.yoctoproject.org/wiki/WW44_-_2018-10-30_-_Full_Test_Cycle_2.6_M4_RC1

and the Release Criteria: 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status#Milestone_4.2FFinal_-_Target_Oct._26.2C_2018

· YP 2.4.4 (Rocko) is in QA and 65% complete.  See: 
https://wiki.yoctoproject.org/wiki/2.4_QA_Status

· A summary of changes to the Yocto Project QA process in 2.7 was sent 
out to the openembedded-architecture list: 
http://lists.openembedded.org/pipermail/openembedded-architecture/2018-November/001577.html
 This will be one of the topics for discussion in the 2.7 planning call on 
Tuesday 27th. Armin has entered a number of bugs into bugzilla for the items 
which are related to this.

· Patches for the thud point release are queuing on the branch.

· Patches are also going to start merging to master which will diverge 
from thud imminently.


Planned Releases for YP 2.7:

· YP 2.6 M4 Release Target was Oct. 26, 2018

· YP 2.7 M1 Cutoff is Dec. 10, 2018

· YP 2.7 M1 Release Target is Dec. 21, 2018

· YP 2.7 M2 Cutoff is Jan. 21, 2019

· YP 2.7 M2 Release Target is Feb. 1, 2019

· YP 2.7 M3 Cutoff is Feb. 25, 2019

· YP 2.7 M3 Release Target is Mar. 8, 2019

· YP 2.7 M4 Cutoff is Apr. 1, 2019

· YP 2.7 M4 Release Target is Apr. 26, 2019


Planned upcoming dot releases:

· YP 2.4.4 (Rocko) is in QA. See: 
https://wiki.yoctoproject.org/wiki/2.4_QA_Status

· YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done.

· YP 2.6.1 (Thud) will be targeted after YP 2.7 M1 is done.

· YP 2.5.3 (Sumo) will be targeted after YP 2.7 M4 is done.

· YP 2.6.2 (Thud) will be targeted after YP 2.5.3 is done.


Tracking Metrics:

· WDD 2402 (last week 2369) 
(https://wiki.yoctoproject.org/charts/combo.html)

· Poky Patch Metrics

oTotal patches found: 1716 (last week 1692)

oPercentage of patches in the Pending State: 739 (43%) [last week 739 (44%)]


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:(208) 244-4460
• Email: stephen.k.jol...@intel.com

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

[yocto] Invitation: Yocto Project Technical Team Meeting @ Monthly from 8am to 9am on the fourth Tuesday (PST) (yocto@yoctoproject.org)

[theyoctoproject]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
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:20181127T08
DTEND;TZID=America/Los_Angeles:20181127T09
RRULE:FREQ=MONTHLY;BYDAY=4TU
DTSTAMP:20181113T155832Z
ORGANIZER;CN=theyoctoproj...@gmail.com:mailto:theyoctoproj...@gmail.com
UID:1ssihorlhf1ptl6nddo58hf...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=theyoctoproj...@gmail.com;X-NUM-GUESTS=0:mailto:theyoctoproject@gmail.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=stephen.k.jol...@intel.com;X-NUM-GUESTS=0:mailto:stephen.k.jolley@i
 ntel.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=yocto@yoctoproject.org;X-NUM-GUESTS=0:mailto:yocto@yoctoproject.org
CREATED:20181113T155832Z
DESCRIPTION:We encourage people attending the meeting to logon and announce
  themselves on the Yocto Project IRC chancel during the meeting (optional):
 Yocto IRC: https://www.google.com/url?q=http%3A%2F%2Fwebch
 at.freenode.net%2F%3Fchannels%3D%23yocto&\;sa=D&\;usd=2&\;usg=AFQj
 CNEvOHVIkxKIrfXWfUxCcVS5_8kh5w" target="_blank">http://webchat.freenode.net
 /?channels=#yoctoWiki: https://www.yoctoproject.org/pu
 blic-virtual-meetings/">https://www.yoctoproject.org/public-virtual-meeting
 s/Bridge is with Zoom at: https://www.google.com/url?q
 =https%3A%2F%2Fzoom.us%2Fj%2F990892712&\;sa=D&\;usd=2&\;usg=AFQjCN
 G2F5sUpm-S-RhkqNhXVBd3m1_3LA" target="_blank">https://zoom.us/j/990892712\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~::~:~::-\nPlease do not edit this section of the description.\n\n
 View your event at https://www.google.com/calendar/event?action=VIEW&eid=MX
 NzaWhvcmxoZjFwdGw2bmRkbzU4aGY3cTYgeW9jdG9AeW9jdG9wcm9qZWN0Lm9yZw&tok=MjUjdG
 hleW9jdG9wcm9qZWN0QGdtYWlsLmNvbTgxNWViNzA0NWE4Y2M5YTIwYjI2ZmJhZjg4ZmEwNzA0M
 WE1MWZlN2Q&ctz=America%2FLos_Angeles&hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20181113T155832Z
LOCATION:Zoom Meeting: https://zoom.us/j/990892712
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Yocto Project Technical Team 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

[yocto] wic creates invalid image

[Donal Morrissey]

Hi There,
I have a problem with an image being created by wic. If I add more than 4
partition definitions to the wks file, the generated image will include an
additional partition with no Fstype, and spanning the full length of the
additional partitions.

Take the following wks file:

part --source rawcopy --sourceparams="file=/image-r0/uboot.env"
--ondisk "mmcblk0" --align 4096 --no-table
part --source bootimg-partition --ondisk "mmcblk0" --fstype=vfat --label
boot --align 4096 --active --fixed-size 40
part --source rootfs --ondisk "mmcblk0" --fstype=ext4 --label primary
--align 4096 --fixed-size 147456k --exclude-path data/
part --source rootfs --ondisk "mmcblk0" --fstype=ext4 --label secondary
--align 4096 --fixed-size 147456k --exclude-path data/
part --ondisk "mmcblk0" --fstype=ext4 --label appdata1 --align 4096
--fixed-size 147456k
part --ondisk "mmcblk0" --fstype=ext4 --label appdata2 --align 4096
--fixed-size 147456k
bootloader --ptable msdos

wic will create a .direct file with the following structure:
Num StartEnd  Size  Fstype
 1  12582912 54525951 41943040  fat16
 2  54525952205520895150994944  ext4
 3 205520896356515839150994944  ext4
 4 360709632666894335306184704
 5 360710144511705087150994944  ext4
 6 515899392666894335150994944  ext4

Note the start and end addresses of partition 4, it spans from the start of
partitions 5 (appdata1)  to the end of partition 6 (appdata2).

If I modify the wks file and remove the entry for appdata2, the created
direct file is valid:

Num StartEnd  Size  Fstype
 1  12582912 54525951 41943040  fat16
 2  54525952205520895150994944  ext4
 3 205520896356515839150994944  ext4
 4 356515840507510783150994944  ext4

Any suggestions on what is going on here?

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

Re: [yocto] wic creates invalid image

[Alex Kiernan]

On Tue, Nov 13, 2018 at 7:13 PM Donal Morrissey
 wrote:
>
> Hi There,
> I have a problem with an image being created by wic. If I add more than 4 
> partition definitions to the wks file, the generated image will include an 
> additional partition with no Fstype, and spanning the full length of the 
> additional partitions.
>
> Take the following wks file:
>
> part --source rawcopy --sourceparams="file=/image-r0/uboot.env" 
> --ondisk "mmcblk0" --align 4096 --no-table
> part --source bootimg-partition --ondisk "mmcblk0" --fstype=vfat --label boot 
> --align 4096 --active --fixed-size 40
> part --source rootfs --ondisk "mmcblk0" --fstype=ext4 --label primary --align 
> 4096 --fixed-size 147456k --exclude-path data/
> part --source rootfs --ondisk "mmcblk0" --fstype=ext4 --label secondary 
> --align 4096 --fixed-size 147456k --exclude-path data/
> part --ondisk "mmcblk0" --fstype=ext4 --label appdata1 --align 4096 
> --fixed-size 147456k
> part --ondisk "mmcblk0" --fstype=ext4 --label appdata2 --align 4096 
> --fixed-size 147456k
> bootloader --ptable msdos
>
> wic will create a .direct file with the following structure:
> Num StartEnd  Size  Fstype
>  1  12582912 54525951 41943040  fat16
>  2  54525952205520895150994944  ext4
>  3 205520896356515839150994944  ext4
>  4 360709632666894335306184704
>  5 360710144511705087150994944  ext4
>  6 515899392666894335150994944  ext4
>
> Note the start and end addresses of partition 4, it spans from the start of 
> partitions 5 (appdata1)  to the end of partition 6 (appdata2).
>
> If I modify the wks file and remove the entry for appdata2, the created 
> direct file is valid:
>
> Num StartEnd  Size  Fstype
>  1  12582912 54525951 41943040  fat16
>  2  54525952205520895150994944  ext4
>  3 205520896356515839150994944  ext4
>  4 356515840507510783150994944  ext4
>
> Any suggestions on what is going on here?
>

I've not checked, but I'd assume it's switched to extended partitions,
since MBR only has 4 primary partitions.

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

Re: [yocto] wic creates invalid image

[Dimitris Tassopoulos]

Hi Alex,

If you don't want the extended partitions you need to create a gpt
partition, you can do this by adding this to your wks file.

bootloader --ptable gpt

Regards,
Dimitris


On Tue, 13 Nov 2018, 20:23 Alex Kiernan  On Tue, Nov 13, 2018 at 7:13 PM Donal Morrissey
>  wrote:
> >
> > Hi There,
> > I have a problem with an image being created by wic. If I add more than
> 4 partition definitions to the wks file, the generated image will include
> an additional partition with no Fstype, and spanning the full length of the
> additional partitions.
> >
> > Take the following wks file:
> >
> > part --source rawcopy --sourceparams="file= path>/image-r0/uboot.env" --ondisk "mmcblk0" --align 4096 --no-table
> > part --source bootimg-partition --ondisk "mmcblk0" --fstype=vfat --label
> boot --align 4096 --active --fixed-size 40
> > part --source rootfs --ondisk "mmcblk0" --fstype=ext4 --label primary
> --align 4096 --fixed-size 147456k --exclude-path data/
> > part --source rootfs --ondisk "mmcblk0" --fstype=ext4 --label secondary
> --align 4096 --fixed-size 147456k --exclude-path data/
> > part --ondisk "mmcblk0" --fstype=ext4 --label appdata1 --align 4096
> --fixed-size 147456k
> > part --ondisk "mmcblk0" --fstype=ext4 --label appdata2 --align 4096
> --fixed-size 147456k
> > bootloader --ptable msdos
> >
> > wic will create a .direct file with the following structure:
> > Num StartEnd  Size  Fstype
> >  1  12582912 54525951 41943040  fat16
> >  2  54525952205520895150994944  ext4
> >  3 205520896356515839150994944  ext4
> >  4 360709632666894335306184704
> >  5 360710144511705087150994944  ext4
> >  6 515899392666894335150994944  ext4
> >
> > Note the start and end addresses of partition 4, it spans from the start
> of partitions 5 (appdata1)  to the end of partition 6 (appdata2).
> >
> > If I modify the wks file and remove the entry for appdata2, the created
> direct file is valid:
> >
> > Num StartEnd  Size  Fstype
> >  1  12582912 54525951 41943040  fat16
> >  2  54525952205520895150994944  ext4
> >  3 205520896356515839150994944  ext4
> >  4 356515840507510783150994944  ext4
> >
> > Any suggestions on what is going on here?
> >
>
> I've not checked, but I'd assume it's switched to extended partitions,
> since MBR only has 4 primary partitions.
>
> --
> Alex Kiernan
> --
> ___
> 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] Yocto Project Status WW46’18

[Peter Kjellerstedt]

>From the updates below:


  *   Patches for the thud point release are queuing on the branch.

On what branch? The thud-next branch is behind the thud branch, and the 
master-next branch contains a lot of recipe updates that do not seem suitable 
for Thud.

//Peter

From: openembedded-core-boun...@lists.openembedded.org 
 On Behalf Of Jolley, Stephen 
K
Sent: den 13 november 2018 16:48
To: yocto@yoctoproject.org; openembedded-c...@lists.openembedded.org
Subject: [OE-core] Yocto Project Status WW46’18


Current Dev Position: YP 2.6 M4 is in preparing for release.

Next Deadline: YP 2.6 M4 Release Target was Oct. 26, 2018


SWAT Team Rotation:

  *   SWAT lead is currently: Armin
  *   SWAT team rotation: Armin -> Paul on Nov. 16, 2018
  *   SWAT team rotation: Paul -> Ross on Nov. 23, 2018
  *   https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

  *   YP 2.6 M4 rc1 has in completed QA and should release this week.  See the  
QA Report: 
https://wiki.yoctoproject.org/wiki/WW44_-_2018-10-30_-_Full_Test_Cycle_2.6_M4_RC1

and the Release Criteria: 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status#Milestone_4.2FFinal_-_Target_Oct._26.2C_2018

  *   YP 2.4.4 (Rocko) is in QA and 65% complete.  See: 
https://wiki.yoctoproject.org/wiki/2.4_QA_Status
  *   A summary of changes to the Yocto Project QA process in 2.7 was sent out 
to the openembedded-architecture list: 
http://lists.openembedded.org/pipermail/openembedded-architecture/2018-November/001577.html
 This will be one of the topics for discussion in the 2.7 planning call on 
Tuesday 27th. Armin has entered a number of bugs into bugzilla for the items 
which are related to this.
  *   Patches for the thud point release are queuing on the branch.
  *   Patches are also going to start merging to master which will diverge from 
thud imminently.


Planned Releases for YP 2.7:

  *   YP 2.6 M4 Release Target was Oct. 26, 2018
  *   YP 2.7 M1 Cutoff is Dec. 10, 2018
  *   YP 2.7 M1 Release Target is Dec. 21, 2018
  *   YP 2.7 M2 Cutoff is Jan. 21, 2019
  *   YP 2.7 M2 Release Target is Feb. 1, 2019
  *   YP 2.7 M3 Cutoff is Feb. 25, 2019
  *   YP 2.7 M3 Release Target is Mar. 8, 2019
  *   YP 2.7 M4 Cutoff is Apr. 1, 2019
  *   YP 2.7 M4 Release Target is Apr. 26, 2019


Planned upcoming dot releases:

  *   YP 2.4.4 (Rocko) is in QA. See: 
https://wiki.yoctoproject.org/wiki/2.4_QA_Status
  *   YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done.
  *   YP 2.6.1 (Thud) will be targeted after YP 2.7 M1 is done.
  *   YP 2.5.3 (Sumo) will be targeted after YP 2.7 M4 is done.
  *   YP 2.6.2 (Thud) will be targeted after YP 2.5.3 is done.


Tracking Metrics:

  *   WDD 2402 (last week 2369) 
(https://wiki.yoctoproject.org/charts/combo.html)
  *   Poky Patch Metrics

 *   Total patches found: 1716 (last week 1692)
 *   Percentage of patches in the Pending State: 739 (43%) [last week 739 
(44%)]


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:(208) 244-4460
• Email: 
stephen.k.jol...@intel.com

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

Re: [yocto] [OE-core] Yocto Project Status WW46’18

[Richard Purdie]

On Tue, 2018-11-13 at 19:59 +, Peter Kjellerstedt wrote:
> From the updates below:
>  
>  Patches for the thud point release are queuing on the branch.
>  
> On what branch? The thud-next branch is behind the thud branch, and
> the master-next branch contains a lot of recipe updates that do not
> seem suitable for Thud.

They are queued on the thud branch. The thud release is a revision a
bit behind current thud HEAD.

Cheers,

Richard

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

[yocto] m4-native, zedboard, "Please port gnulib fseeko.c to your platform"

[Robert P. J. Day]

  been away from YP for a few months, diving back in, want to build a
core-image-minimal for my zedboard, and i will first admit that i'm
using a non-approved distro (fully-updated fedora 29):

"WARNING: Host distribution "fedora-29" 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."

  no matter, i will live dangerously. but then things take an ugly
turn:

"WARNING: Your host glibc verson (2.28) is newer than that in
uninative (2.27). Disabling uninative so that sstate is not
corrupted."

  ok, let's see how far we get ... and that's here, trying to compile
m4-native:

| gcc   -I. -I../../m4-1.4.18/lib
-isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
-isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
-O2 -pipe -c -o freadahead.o ../../m4-1.4.18/lib/freadahead.c
| gcc   -I. -I../../m4-1.4.18/lib
-isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
-isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
-O2 -pipe -c -o fseeko.o ../../m4-1.4.18/lib/fseeko.c
| ../../m4-1.4.18/lib/freadahead.c: In function ‘freadahead’:
| ../../m4-1.4.18/lib/fseeko.c: In function ‘rpl_fseeko’:
| ../../m4-1.4.18/lib/freadahead.c:92:3: error: #error "Please port
gnulib freadahead.c to your platform! Look at the definition of
fflush, fread, ungetc on your system, then report this to bug-gnulib."
|   #error "Please port gnulib freadahead.c to your platform! Look at
the definition of fflush, fread, ungetc on your system, then report
this to bug-gnulib."
|^
| ../../m4-1.4.18/lib/fseeko.c:110:4: error: #error "Please port
gnulib fseeko.c to your platform! Look at the code in fseeko.c, then
report this to bug-gnulib."
|#error "Please port gnulib fseeko.c to your platform! Look at the
code in fseeko.c, then report this to bug-gnulib."


and so on. red hat's bugzilla has an entry for just this:

https://bugzilla.redhat.com/show_bug.cgi?id=1595702

but i'm unsure (read, have no clue) how to deal with this, and i
suspect it affects more targets than just zedboard which is why i'm
asking on the general YP list.

  thoughts? is there a cheap fix for this? i'm about to dive into
debugging this, but if someone wants to make my life easy, that'd be
great.

rday

-- 


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

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] m4-native, zedboard, "Please port gnulib fseeko.c to your platform"

[akuster808]

Robert,

On 11/13/18 12:28 PM, Robert P. J. Day wrote:
>   been away from YP for a few months, diving back in, want to build a
> core-image-minimal for my zedboard, and i will first admit that i'm
> using a non-approved distro (fully-updated fedora 29):
>
> "WARNING: Host distribution "fedora-29" 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."
>
>   no matter, i will live dangerously. but then things take an ugly
> turn:
>
> "WARNING: Your host glibc verson (2.28) is newer than that in
> uninative (2.27). Disabling uninative so that sstate is not
> corrupted."

>   ok, let's see how far we get ... and that's here, trying to compile
> m4-native:
>
> | gcc   -I. -I../../m4-1.4.18/lib
> -isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
> -isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
> -O2 -pipe -c -o freadahead.o ../../m4-1.4.18/lib/freadahead.c
> | gcc   -I. -I../../m4-1.4.18/lib
> -isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
> -isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
> -O2 -pipe -c -o fseeko.o ../../m4-1.4.18/lib/fseeko.c
> | ../../m4-1.4.18/lib/freadahead.c: In function ‘freadahead’:
> | ../../m4-1.4.18/lib/fseeko.c: In function ‘rpl_fseeko’:
> | ../../m4-1.4.18/lib/freadahead.c:92:3: error: #error "Please port
> gnulib freadahead.c to your platform! Look at the definition of
> fflush, fread, ungetc on your system, then report this to bug-gnulib."
> |   #error "Please port gnulib freadahead.c to your platform! Look at
> the definition of fflush, fread, ungetc on your system, then report
> this to bug-gnulib."
> |^
> | ../../m4-1.4.18/lib/fseeko.c:110:4: error: #error "Please port
> gnulib fseeko.c to your platform! Look at the code in fseeko.c, then
> report this to bug-gnulib."
> |#error "Please port gnulib fseeko.c to your platform! Look at the
> code in fseeko.c, then report this to bug-gnulib."
>
>
> and so on. red hat's bugzilla has an entry for just this:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1595702
>
> but i'm unsure (read, have no clue) how to deal with this, and i
> suspect it affects more targets than just zedboard which is why i'm
> asking on the general YP list.
>
>   thoughts? is there a cheap fix for this? i'm about to dive into
> debugging this, but if someone wants to make my life easy, that'd be
> great.

Thud has :
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/m4?h=thud&id=95ca077ab871ceff46c2052f324f879a1d624ff4

with backports pending verification for sumo but missed th Rocko cutoff.

- armin

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