Re: [yocto] [meta-raspberrypi][PATCH] wic: add swap partition and set /root and /swap size
Hi, On 14/11/2019 11:11, Paul Barker wrote: On Thu, 14 Nov 2019, at 06:04, Hongxu Jia wrote: - Add swap partition to workaround memory limitation - Support to set /root and /swap size, 4G /root and 1G /swap by default Signed-off-by: Hongxu Jia These settings feel distro-specific to me. They're not required for how many of us use the Raspberry Pi so it's best not to force them on everyone. I tend to agree with Paul. The final SD card configuration is generally a per project decision (more or less). The BSP provides a bootable reference and from there sky is the limit. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
On 3 November 2019 13:18:53 GMT, Khem Raj wrote: >On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan >wrote: > >> On 01/11/2019 17:18, Khem Raj wrote: >> > On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan >wrote: >> >> >> >> Hi Steve, >> >> >> >> On 01/11/2019 05:32, Steve Pavao wrote: >> >>> poky linux build fails when ARM erratum mfix linker switch is >specified >> >>> in local.conf: >> >>> >> >>> TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419” >> >>> >> >>> causes build failure. >> >>> >> >>> Please advise how to use this switch successfully. I am synced >current >> >>> in master branch in all layers as of today. The switch causes >libtool >> >>> link to fail due to missing libbz2.so. If I don’t specify the >switch, >> >>> the build completes without errors. >> >>> >> >>> It is important to be able to build poky linux with this switch >to >> avoid >> >>> certain crash conditions as described in the ARM errata document. >> >> >> >> I haven't tried this erratum fix. It is indeed implemented at the >> >> linker's lever. It's curious though to see the bz2 dependency. Can >you >> >> share the specific error? I assume you are doing this on RPi3. >> >> >> > >> > this will impact rpi3 in 64bit mode, don't think 32bit needs this. >I >> > think its best to >> > add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS >> >> I was thinking about this. The erratum seems to show that this >applies >> to all revisions of a53. So it sounds like we should add it in >> `tune-cortexa53.inc`. >> > >Up to r0b4 only so maybe not all a53 implementations are impacted > As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed? -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
On 01/11/2019 17:18, Khem Raj wrote: On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan wrote: Hi Steve, On 01/11/2019 05:32, Steve Pavao wrote: poky linux build fails when ARM erratum mfix linker switch is specified in local.conf: TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419” causes build failure. Please advise how to use this switch successfully. I am synced current in master branch in all layers as of today. The switch causes libtool link to fail due to missing libbz2.so. If I don’t specify the switch, the build completes without errors. It is important to be able to build poky linux with this switch to avoid certain crash conditions as described in the ARM errata document. I haven't tried this erratum fix. It is indeed implemented at the linker's lever. It's curious though to see the bz2 dependency. Can you share the specific error? I assume you are doing this on RPi3. this will impact rpi3 in 64bit mode, don't think 32bit needs this. I think its best to add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS I was thinking about this. The erratum seems to show that this applies to all revisions of a53. So it sounds like we should add it in `tune-cortexa53.inc`. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
Hi Steve, On 01/11/2019 05:32, Steve Pavao wrote: poky linux build fails when ARM erratum mfix linker switch is specified in local.conf: TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419” causes build failure. Please advise how to use this switch successfully. I am synced current in master branch in all layers as of today. The switch causes libtool link to fail due to missing libbz2.so. If I don’t specify the switch, the build completes without errors. It is important to be able to build poky linux with this switch to avoid certain crash conditions as described in the ARM errata document. I haven't tried this erratum fix. It is indeed implemented at the linker's lever. It's curious though to see the bz2 dependency. Can you share the specific error? I assume you are doing this on RPi3. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Task vardeps on a variable changed externally
Cheers Paul! On 09/10/2019 11:07, Paul Barker wrote: On Wed, 9 Oct 2019, at 10:42, Andrei Gherzan wrote: Hi guys, I struggle to figure out an issue that I lately got into. I want to have a recipe which writes a manifest of all the layers part of the build. These layers are all git repositories and I want their revision to be exposed at runtime. Do you need this to be an actual package or would you be happy with it just injected into the rootfs via IMAGE_PREPROCESS_COMMAND? If so you could take a look at image-buildinfo.bbclass which seemed to work well when I've done it in the past. That is exactly what I've done in the past to workaround this but now, when facing the same issue again, I thought that there must be something better. It really sounds to me as a bug and I'm mainly searching for an explanation if that is not the case. The only other way I've done something like this in the past is to put the git commands into do_compile for a recipe and set do_compile[nostamp] = "1". That way the task and every task that depends on it are always re-ran. It does mean that it will be re-ran even if the git repositories haven't been updated at all. Myeah. That would always invalidate the recipe. Not great. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Task vardeps on a variable changed externally
Hi guys,
I struggle to figure out an issue that I lately got into. I want to have
a recipe which writes a manifest of all the layers part of the build.
These layers are all git repositories and I want their revision to be
exposed at runtime. So I obviously have a a python function which
computes let's say, for the sake of example, a revision of one layer.
def get_rev(d):
# returns revision of a repository
LAYER_REVISION := "${get_rev(d)}"
The recipe also has a `do_compile` variable dependency:
do_compile[vardeps] += "LAYER_REVISION"
Checking the task signature I see the inclusion of the expanded variable
LAYER_REVISION.
Now, if I externally change the revision of that respective layer the
task is not re-triggered even so the recipe environment reports the
updated variable (bitbake -e). What is even more confusing is that if
for whatever reason the do_compile task gets invalidated (or I force
it), the build system returns a "basehash value changed" error.
I would expect that the change of revision to trickle a task
invalidation and the task to be rerun but that doesn't seem to happen as
described above.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Issues building bcm2835_bootfiles in Thud
Hello, On 14/08/2019 17.39, Phillip Marks wrote: > We are building Thud for a raspberry-pi0+wifi and we've noticed that > the recipe bcm2835_bootfiles > under meta-raspberrypi/recipes-bsp/bootfiles is not pulling in the > proprietary *.dtb modules from the firmware repository. This is > causing linux-raspberrypi to fail as it tries to build those modules > and fails on "no target found for bcm2708-rpi-0-w.dtb". How does > bcm2835_bootfiles pull in the Broadcom firmware modules and where in > build does it store them? We don't see them in tmp/work. > Are you using a clean thud setup or updating the kernel to the current HEAD? You shouldn't hit this issue following the versions use in the thud branch of meta-raspberrypi. Long story short, the build system doesn't take advantage of the precompiled dtb files available in the Raspberry Pi firmware repository. It maintains a list of dtb as a variable and compiles them while compiling the kernel. I suspect that you have a bbappend which updates the kernel to current HEAD (includes a dtb rename backport). -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-rpi vs meta-raspberrypi. Which one?
On 8 August 2019 20:59:03 BST, Khem Raj wrote: >Meta-raspberrypi > >On Thu, Aug 8, 2019 at 12:57 PM Mauro Ziliani >wrote: > >> Hi all. >> >> I'm working on a RPi3B with pyro and qt5/qml >> >> Which layer between rpi and raspberrypi? TIL : there is a meta-rpi layer. It could use a better readme description because the current one can be confusing. -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel-devsrc used to be full source - not the case since thud
On 23/05/2019 17.11, Bruce Ashfield wrote: > > > On Thu, May 23, 2019 at 11:24 AM Andrei Gherzan <mailto:and...@gherzan.ro>> wrote: > > On 23/05/2019 16.10, Bruce Ashfield wrote: >> >> >> On Thu, May 23, 2019 at 11:00 AM Andrei Gherzan >> mailto:and...@gherzan.ro>> wrote: >> >> >> On 23/05/2019 15.39, Bruce Ashfield wrote: >>> >>> >>> On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield >>> mailto:bruce.ashfi...@gmail.com>> >>> wrote: >>> >>> >>> >>> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan >>> mailto:and...@gherzan.ro>> wrote: >>> >>> Hello, >>> >>> This might have been discussed before. I couldn't >>> find a relevant >>> thread, but if it is so, just link me to it. >>> >>> Since thud, more specific since >>> >>> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f >>> Author: Bruce Ashfield >> <mailto:bruce.ashfi...@windriver.com>> >>> Date: Sat Aug 18 22:50:44 2018 -0400 >>> kernel-devsrc: restructure for out of tree (and >>> on target) module builds >>> >>> ... we switched from a recipe that was deploying the >>> entire source code >>> to one that provides mainly the kernel headers (but >>> not only). This >>> change broke people expectations of this recipe >>> while the description is >>> also confusing: "Development source linux kernel. >>> When built, this >>> recipe packages the \source of the preferred >>> virtual/kernel provider and >>> makes it available for full kernel \development or >>> external module builds". >>> >>> If size is not a problem (which can be the case when >>> you compile on a >>> builder for example and deploy only a OOT kernel >>> module through other >>> means), the full kernel source was a painless >>> experience where things like >>> >>> commit a9471601fedd1f5087304eaa5fd39b98ae220313 >>> Author: Bruce Ashfield >> <mailto:bruce.ashfi...@windriver.com>> >>> Date: Thu Aug 30 09:45:41 2018 -0400 >>> kernel-devsrc: fix arm/arm64 target module build >>> >>> ... would not appear. I understand the size impact >>> on target and for >>> those cases, continuously maintaining this recipe >>> with new >>> files/resources needed from the kernel, makes sense. >>> So my proposal is >>> to have two recipes, for example kernel-devsrc and >>> kernel-fullsrc >>> (kernel-src etc.) so people can choose what they >>> need/want >>> deploying/using. Or even have another devsrc >>> provider. I'm open to any >>> implementation detail. I'd just want to have an >>> option for a full kernel >>> source recipe. >>> >>> >>> This is already planned, and hidden in bugzilla >>> somewhere. I'll have some new kernel packaging >>> options available for the fall release. >>> >>> >>> It looks like the bugs that I was using for development were >>> finally moved to resolved (they were a bit old, and >>> contained collected information on various kernel packaging >>> options .. my searching of bugzilla isn't turning it up at >>> the moment). So I just created a new bug to track the >>> development for 2.8. >>> >>> The issue with the multiple kernel source providers is >>> really about test cycles. The smaller devsrc is for >>> on-target module development and builds against the ex
Re: [yocto] kernel-devsrc used to be full source - not the case since thud
On 23/05/2019 16.10, Bruce Ashfield wrote: > > > On Thu, May 23, 2019 at 11:00 AM Andrei Gherzan <mailto:and...@gherzan.ro>> wrote: > > > On 23/05/2019 15.39, Bruce Ashfield wrote: >> >> >> On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield >> mailto:bruce.ashfi...@gmail.com>> wrote: >> >> >> >> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan >> mailto:and...@gherzan.ro>> wrote: >> >> Hello, >> >> This might have been discussed before. I couldn't find a >> relevant >> thread, but if it is so, just link me to it. >> >> Since thud, more specific since >> >> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f >> Author: Bruce Ashfield > <mailto:bruce.ashfi...@windriver.com>> >> Date: Sat Aug 18 22:50:44 2018 -0400 >> kernel-devsrc: restructure for out of tree (and on >> target) module builds >> >> ... we switched from a recipe that was deploying the >> entire source code >> to one that provides mainly the kernel headers (but not >> only). This >> change broke people expectations of this recipe while the >> description is >> also confusing: "Development source linux kernel. When >> built, this >> recipe packages the \source of the preferred >> virtual/kernel provider and >> makes it available for full kernel \development or >> external module builds". >> >> If size is not a problem (which can be the case when you >> compile on a >> builder for example and deploy only a OOT kernel module >> through other >> means), the full kernel source was a painless experience >> where things like >> >> commit a9471601fedd1f5087304eaa5fd39b98ae220313 >> Author: Bruce Ashfield > <mailto:bruce.ashfi...@windriver.com>> >> Date: Thu Aug 30 09:45:41 2018 -0400 >> kernel-devsrc: fix arm/arm64 target module build >> >> ... would not appear. I understand the size impact on >> target and for >> those cases, continuously maintaining this recipe with new >> files/resources needed from the kernel, makes sense. So >> my proposal is >> to have two recipes, for example kernel-devsrc and >> kernel-fullsrc >> (kernel-src etc.) so people can choose what they need/want >> deploying/using. Or even have another devsrc provider. >> I'm open to any >> implementation detail. I'd just want to have an option >> for a full kernel >> source recipe. >> >> >> This is already planned, and hidden in bugzilla somewhere. >> I'll have some new kernel packaging >> options available for the fall release. >> >> >> It looks like the bugs that I was using for development were >> finally moved to resolved (they were a bit old, and contained >> collected information on various kernel packaging options .. my >> searching of bugzilla isn't turning it up at the moment). So I >> just created a new bug to track the development for 2.8. >> >> The issue with the multiple kernel source providers is really >> about test cycles. The smaller devsrc is for on-target module >> development and builds against the exported uapi headers, and >> that is what the nightly / automated tests will use. We had >> issues with both the amount of time it took to package the entire >> source, and the amount of space that it took up on the images. >> Hence the creation of devsrc. >> >> With new kernel-source and kernel-headers packages (the working >> names), they are really provided as references to the running >> kernel, and will largely be an exercise left up to the developer >> to use them as they want. > > Right. So is there anything that holds us from creating two > recipes - one for what we currently have and one for what we used > to have pre-thud - find some pretty names and start from that? I'm > asking just in case I'm missing any internal architecture >
Re: [yocto] kernel-devsrc used to be full source - not the case since thud
On 23/05/2019 15.39, Bruce Ashfield wrote: > > > On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield > mailto:bruce.ashfi...@gmail.com>> wrote: > > > > On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan <mailto:and...@gherzan.ro>> wrote: > > Hello, > > This might have been discussed before. I couldn't find a relevant > thread, but if it is so, just link me to it. > > Since thud, more specific since > > commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f > Author: Bruce Ashfield <mailto:bruce.ashfi...@windriver.com>> > Date: Sat Aug 18 22:50:44 2018 -0400 > kernel-devsrc: restructure for out of tree (and on target) > module builds > > ... we switched from a recipe that was deploying the entire > source code > to one that provides mainly the kernel headers (but not only). > This > change broke people expectations of this recipe while the > description is > also confusing: "Development source linux kernel. When built, this > recipe packages the \source of the preferred virtual/kernel > provider and > makes it available for full kernel \development or external > module builds". > > If size is not a problem (which can be the case when you > compile on a > builder for example and deploy only a OOT kernel module > through other > means), the full kernel source was a painless experience where > things like > > commit a9471601fedd1f5087304eaa5fd39b98ae220313 > Author: Bruce Ashfield <mailto:bruce.ashfi...@windriver.com>> > Date: Thu Aug 30 09:45:41 2018 -0400 > kernel-devsrc: fix arm/arm64 target module build > > ... would not appear. I understand the size impact on target > and for > those cases, continuously maintaining this recipe with new > files/resources needed from the kernel, makes sense. So my > proposal is > to have two recipes, for example kernel-devsrc and kernel-fullsrc > (kernel-src etc.) so people can choose what they need/want > deploying/using. Or even have another devsrc provider. I'm > open to any > implementation detail. I'd just want to have an option for a > full kernel > source recipe. > > > This is already planned, and hidden in bugzilla somewhere. I'll > have some new kernel packaging > options available for the fall release. > > > It looks like the bugs that I was using for development were finally > moved to resolved (they were a bit old, and contained collected > information on various kernel packaging options .. my searching of > bugzilla isn't turning it up at the moment). So I just created a new > bug to track the development for 2.8. > > The issue with the multiple kernel source providers is really about > test cycles. The smaller devsrc is for on-target module development > and builds against the exported uapi headers, and that is what the > nightly / automated tests will use. We had issues with both the amount > of time it took to package the entire source, and the amount of space > that it took up on the images. Hence the creation of devsrc. > > With new kernel-source and kernel-headers packages (the working > names), they are really provided as references to the running kernel, > and will largely be an exercise left up to the developer to use them > as they want. Right. So is there anything that holds us from creating two recipes - one for what we currently have and one for what we used to have pre-thud - find some pretty names and start from that? I'm asking just in case I'm missing any internal architecture discussions or so. And about test cycles, I'm not sure I understand why having a provider vs having two separate recipes impact automated tests. In both cases you will select whatever you want to test - by using a specific recipe or by setting a preferred provider (I don't have a strong opinion here but I was just curious about the time impact on automated tests). Replying to the other email (this thread was forked). We have maintained a similar kernel headers approach for a couple of years now. And many times we found ourselves in the situation where something had to be added/removed/checked - that was either kernel fork specific or something that was added due to kernel updates. And this loop of fixes here and there was obviously completely resolved by just using the "old" kernel-devsrc which always had "everything" in. A good example i
Re: [yocto] kernel-devsrc used to be full source - not the case since thud
On 23/05/2019 15.32, Bruce Ashfield wrote: > > > On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan <mailto:and...@gherzan.ro>> wrote: > > Hello, > > This might have been discussed before. I couldn't find a relevant > thread, but if it is so, just link me to it. > > Since thud, more specific since > > commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f > Author: Bruce Ashfield <mailto:bruce.ashfi...@windriver.com>> > Date: Sat Aug 18 22:50:44 2018 -0400 > kernel-devsrc: restructure for out of tree (and on target) > module builds > > ... we switched from a recipe that was deploying the entire source > code > to one that provides mainly the kernel headers (but not only). This > change broke people expectations of this recipe while the > description is > also confusing: "Development source linux kernel. When built, this > recipe packages the \source of the preferred virtual/kernel > provider and > makes it available for full kernel \development or external module > builds". > > If size is not a problem (which can be the case when you compile on a > builder for example and deploy only a OOT kernel module through other > means), the full kernel source was a painless experience where > things like > > commit a9471601fedd1f5087304eaa5fd39b98ae220313 > Author: Bruce Ashfield <mailto:bruce.ashfi...@windriver.com>> > Date: Thu Aug 30 09:45:41 2018 -0400 > kernel-devsrc: fix arm/arm64 target module build > > ... would not appear. I understand the size impact on target and for > those cases, continuously maintaining this recipe with new > files/resources needed from the kernel, makes sense. So my proposal is > to have two recipes, for example kernel-devsrc and kernel-fullsrc > (kernel-src etc.) so people can choose what they need/want > deploying/using. Or even have another devsrc provider. I'm open to any > implementation detail. I'd just want to have an option for a full > kernel > source recipe. > > > This is already planned, and hidden in bugzilla somewhere. I'll have > some new kernel packaging > options available for the fall release. Nice to hear that. Can you share more details on that because we plan to implement it for BalenaOS and would be a waste to redo what you already have or do it in different ways and reset afterwards. -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] kernel-devsrc used to be full source - not the case since thud
Hello, This might have been discussed before. I couldn't find a relevant thread, but if it is so, just link me to it. Since thud, more specific since commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f Author: Bruce Ashfield Date: Sat Aug 18 22:50:44 2018 -0400 kernel-devsrc: restructure for out of tree (and on target) module builds ... we switched from a recipe that was deploying the entire source code to one that provides mainly the kernel headers (but not only). This change broke people expectations of this recipe while the description is also confusing: "Development source linux kernel. When built, this recipe packages the \source of the preferred virtual/kernel provider and makes it available for full kernel \development or external module builds". If size is not a problem (which can be the case when you compile on a builder for example and deploy only a OOT kernel module through other means), the full kernel source was a painless experience where things like commit a9471601fedd1f5087304eaa5fd39b98ae220313 Author: Bruce Ashfield Date: Thu Aug 30 09:45:41 2018 -0400 kernel-devsrc: fix arm/arm64 target module build ... would not appear. I understand the size impact on target and for those cases, continuously maintaining this recipe with new files/resources needed from the kernel, makes sense. So my proposal is to have two recipes, for example kernel-devsrc and kernel-fullsrc (kernel-src etc.) so people can choose what they need/want deploying/using. Or even have another devsrc provider. I'm open to any implementation detail. I'd just want to have an option for a full kernel source recipe. Regards, -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-raspberrypi_4.19.bb unknown commit
Hi, On 20/05/2019 19.30, Khem Raj wrote: > > > On 5/16/19 8:53 AM, Andrei Gherzan wrote: >> >> On 12/05/2019 16.04, Jean-Christian de Rivaz wrote: >>> Le 11.05.19 à 21:46, Paul Barker a écrit : >>>> On Sat, 11 May 2019, at 20:44, Jean-Christian de Rivaz wrote: >>>>> Hi, >>>>> >>>>> I try to use the Linux 4.19 for the RaspberryPi from the >>>>> meta-raspberrypi recipe linux-raspberrypi_4.19.bb but the commit >>>>> ab8652c03fa081b27de7e28a74c2536cb2aa3e5b from his SRCREV don't exists >>>>> into the repository github.com/raspberrypi/linux branch rpi-4.19.y >>>>> . I >>>>> searched that commit on a few others branches but failed to find it. >>>>> Have anyone tested that recipe ? >>>> The upstream rpi-4.19.y branch is still unstable and they enjoy >>>> rebasing commits. The breaks the commit references used in our >>>> recipes. >>>> >>>> For now I recommend sticking to the 4.14.y kernels for Raspberry Pi. >>>> >>> Too bad, I need Linux >= 4.19 to enable cgroup2 memory.oom_group to >>> properly kill and restart xserver-nodm with chromium in kiosk mode >>> displaying videos all the days long. There a bug somewhere in >>> chromium/ffmpeg/gpu that eat all the available memory, and I don't have >>> time and money to dig in that complexity and patch acceptance >>> marathon. >> Feel free to complain upstream: >> https://github.com/raspberrypi/linux/issues/2931 >> > > this has been fixed upstream. So I think time to bump the SRCREV and > change default kernel back to 4.19 again. I'll handle this today. -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display
Hi, On 16/05/2019 17.24, Rudolf J Streif wrote: > Thank you, Paul. I did read Andrei's excellent documentation and > enabled I2C and SPI etc. And it didn't work? -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] I'm currently finishing my masters thesis and I really need a bit of help from you if possible. I have a questionnaire which I need to get some feedback about and filled by people who are deep
Hi guys, I'm currently finishing my masters thesis and I really need a bit of help if possible. The project is entitled "Empowering git repositories with visualization tools to aid awareness of dependencies in open source" and I have a questionnaire which I need to get some feedback on and filled by people who are involved in Yocto project. If don't mind and can sacrifice 10 minutes for this, please find the form here: https://docs.google.com/forms/d/e/1FAIpQLSePIfr83Eb3fgylNDJalSxS0xu_Fr7rirz2TT5wWlEqwHwTFg/viewform . If interested, I can come back and validate the results after one week. Thanks in advance, -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display
HI, On 16/05/2019 16.31, Rudolf J Streif wrote: > I am trying to use the "official" RPi 7" touch display > (https://www.raspberrypi.org/products/raspberry-pi-touch-display/) > with meta-raspberrypi (most recent from master). However, I cannot get > it to work. As a matter of fact the display does not even show the GPU > rainbow screen making me think that the GPU firmware packaged with > meta-raspberrypi does not support the DSI display. It works just fine > with the latest Raspbian release (screen and touch). > > I searched the web up and down but could not find anything. Maybe > somebody has an idea? Wrong firmware (maybe cannot be distributed > because of licensing...)? Sadly we don't actively test display and other related toys so they might be broken. Even so, I would be surprised if the DSI port doesn't work. What is you final config.txt (pastebin it please)? -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-raspberrypi_4.19.bb unknown commit
On 12/05/2019 16.04, Jean-Christian de Rivaz wrote: > Le 11.05.19 à 21:46, Paul Barker a écrit : >> On Sat, 11 May 2019, at 20:44, Jean-Christian de Rivaz wrote: >>> Hi, >>> >>> I try to use the Linux 4.19 for the RaspberryPi from the >>> meta-raspberrypi recipe linux-raspberrypi_4.19.bb but the commit >>> ab8652c03fa081b27de7e28a74c2536cb2aa3e5b from his SRCREV don't exists >>> into the repository github.com/raspberrypi/linux branch rpi-4.19.y . I >>> searched that commit on a few others branches but failed to find it. >>> Have anyone tested that recipe ? >> The upstream rpi-4.19.y branch is still unstable and they enjoy rebasing >> commits. The breaks the commit references used in our recipes. >> >> For now I recommend sticking to the 4.14.y kernels for Raspberry Pi. >> > Too bad, I need Linux >= 4.19 to enable cgroup2 memory.oom_group to > properly kill and restart xserver-nodm with chromium in kiosk mode > displaying videos all the days long. There a bug somewhere in > chromium/ffmpeg/gpu that eat all the available memory, and I don't have > time and money to dig in that complexity and patch acceptance marathon. Feel free to complain upstream: https://github.com/raspberrypi/linux/issues/2931 -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] CAN: Add Pican2 support
Hi Fabien, On Fri, Nov 16, 2018 at 5:29 PM Fabien Lahoudere < fabien.lahoud...@collabora.com> wrote: > In order to make Pican 2 work, we : > - add mcp2515.dto to the overlay list > - add a variable to enable it in local.conf > - create a udev rule to mount interface > > > http://skpang.co.uk/catalog/pican2-canbus-board-for-raspberry-pi-23-p-1475.html > > Signed-off-by: Fabien Lahoudere > Could you please submit this PR in github? Check the readme for more information. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-layer raspberry
Hi, On Fri, Oct 19, 2018 at 11:39 PM Zolee K wrote: > Hello, > > Do you know if I include tha raspberrypi layer it would compile to a > raspberry pi 1 machine as well or only to the later models? > > RaspberryPi 1 should work just fine. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Problem enabling w1-gpio
Hi Markus, On Fri, Oct 5, 2018 at 4:28 PM Markus W wrote: > Hi! > > I'm creating a yocto image (sumo) for the raspberrypi and got stuck on how > to enable the one-wire interface on boot. > > I have enabled the SPI bus and I2C in my local.conf file. > > ENABLE_SPI_BUS = "1" > ENABLE_I2C = "1" > > and checked that they are loaded on boot. > > I'm struggling to figure out where to set "dtoverlay=w1-gpio" and how to > enable the w1-gpio module on boot. The /boot/config.txt file doesn't exist > by default after startup. If I create this file with the line above > directly on the rpi and reboot it, the w1-gpio interface is still not > enabled. > /boot when you run up the image is on the rootfs while the file you are looking for is in the boot partition. You will need to mount (or set a boot mount - fstab, systemd etc) the boot partition (p1) and you will see the file afterwards. Alternatively, just mount the SD card's partitions on your working station and modify the file offline. --- Andrei -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberry]rpi-config
On Tue, Sep 11, 2018 at 4:41 PM idealsim wrote: > Hi i'm trying to build an image for a raspberry-pi 3 on branch sumo but i > have an error when i try to include rpi-config. See the issue under : > > ERROR: Task do_populate_sdk in > > /media/xxx/data/raspberry/yocto/yocto_official/poky-sumo/meta-xxx/recipes-/images/ > console-image-.bb > rdepends upon non-existent task do_package_write_rpm in > > /media/xxx/data/raspberry/yocto/yocto_official/poky-sumo/meta-raspberrypi/recipes-bsp/bootfiles/ > rpi-config_git.bb > ERROR: Command execution failed: 1 > Is your image installing rpi-config? -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] No package 'wayland-egl' found
Hi, On Tue, May 15, 2018 at 1:48 AM, Bill Jenkins wrote: > > > On May 14, 2018, at 2:43 PM, Bill Jenkins wrote: > > > > Hi, > > > > I just sync'd to the head of the master branch in the poky and > meta-raspberrypi repos today > > and tried a build that successfully completed last week, but now fails > with the error message > > "No package 'wayland-egl' found" during the gtk+3_3.22.29.bb:do_configure > task. > > > > I see some recent commits in both branches related to egl movement > between wayland > > and userland. I made sure to be up-to-date in both repos. What could I > be missing? > > > > I found that by removing the do_install_append_rpi() from commit de8912cb, > the build > finishes successfully. Is there something else that this commit is > depending on that I do > not have? > > I can confirm this is an issue introduced by https://github.com/ agherzan/meta-raspberrypi/pull/247 . We will be fixing this soon but in the meanwhile could you create a new issue in github? Regards, Andrei -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Compute Module 3 machine .conf questions
Currently, the cm3 machine is only there as for people to see clearly what machine as supported. As well, in some cases, we need some machine specific tweaks so we need a new machine - it's not the case here. -- Andrei Gherzan On Wed, May 2, 2018 at 11:56 PM, Steve Pavao wrote: > Hi Andrei, > > We were able to verify that we could directly use the raspberrypi3-64.conf > for the cm3 as 64-bit, as you had suggested. Thanks for that suggestion. > > It just seemed a bit confusing that there is only one cm3 machine conf, > and it tunnels through to a rpi2. All the online doc about the cm3 > mentions the rpi3. A colleague wonders if there are any differences that > someone was planning to eventually use that cm3 conf to enumerate, > otherwise - having a cm3 conf seems like unnecessary duplication. > > Thanks again for your help! > > - Steve Pavao > Korg R&D > > > On May 1, 2018, at 9:39 AM, Andrei Gherzan wrote: > > Hi Steve, > > On Tue, May 1, 2018 at 12:40 AM, Steve Pavao wrote: > >> Hello, >> >> My company has bought a Raspberry Pi Compute Module 3 for evaluation, and >> I have a 2 questions about the supplied machine .conf files for it. >> >> 1. Should the supplied raspberrypi-cm3.conf file internally refer to the >> Raspberry Pi 3 instead of the Raspberry Pi 2, since the RPi3 is the >> hardware basis of the Compute Module 3? >> > > RaspberryPi 3 is currently almost the same as RaspberryPi 2 in terms of > configuration. What is the problem you are facing? > > >> 2. Should there also be an additional .conf file supplied in the >> meta-raspberry pi layer for a 64-bit version of poky Linux for the Compute >> Module 3, just as there is a raspberrypi3-64 machine .conf for the RPi3? >> > > You can use directly raspberrypi3-64 as far as I am aware. The cm confs > are used as aliases right now. They point to one of the Raspberrypi 2 or 3 > machine configurations. > > -- > Andrei G. > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Revert "u-boot: Update RPi Zero W defconfig to support DTB."
On Wed, May 9, 2018 at 7:10 PM, Ryan Harkin wrote: > Apologies all, > > I forgot to add [meta-raspberrypi] to the subject line. > > Andrei, > > Please let me know if you'd like me to resend. Assuming you don't have a > fix for this in flight already. > > Regards, > Ryan. > > I was just going to point that out. Anyway, the patch/fix is already in master. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Compute Module 3 machine .conf questions
Hi Steve, On Tue, May 1, 2018 at 12:40 AM, Steve Pavao wrote: > Hello, > > My company has bought a Raspberry Pi Compute Module 3 for evaluation, and > I have a 2 questions about the supplied machine .conf files for it. > > 1. Should the supplied raspberrypi-cm3.conf file internally refer to the > Raspberry Pi 3 instead of the Raspberry Pi 2, since the RPi3 is the > hardware basis of the Compute Module 3? > RaspberryPi 3 is currently almost the same as RaspberryPi 2 in terms of configuration. What is the problem you are facing? > 2. Should there also be an additional .conf file supplied in the > meta-raspberry pi layer for a 64-bit version of poky Linux for the Compute > Module 3, just as there is a raspberrypi3-64 machine .conf for the RPi3? > You can use directly raspberrypi3-64 as far as I am aware. The cm confs are used as aliases right now. They point to one of the Raspberrypi 2 or 3 machine configurations. -- Andrei G. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
On Wed, Mar 28, 2018 at 2:57 PM, Andrei Gherzan wrote: > Hi guys, > > On Wed, Mar 28, 2018 at 2:40 PM, Paul Barker > wrote: > >> On Wed, Mar 28, 2018 at 1:41 PM, Måns Zigher >> wrote: >> > Hi, >> > >> > Thanks I will do that. But I have other layers that depend on the rocko >> of >> > meta-raspberrypi so I believe I will have to use the rocko at some >> point but >> > for testing I will try Morty. What is the reason for using Morty do you >> > know? Is rocko unstable? >> > >> >> Yea, we need to get this fixed in rocko. My test device for >> raspberrypi3 is a Model B v1.2, not a B+ so you may have to help us >> out with testing here. >> >> Could you try out core-image-base built from master with just the >> required layers? If that works then a kernel/firmware backport is >> likely what's needed. >> >> > Today I will have 3b+ support PR to master. Afterwards we can start > backporting things as needed. I'm currently only interested in rocko but if > other people are willing to do it, we can PR stuff in older versions too. > > https://github.com/agherzan/meta-raspberrypi/pull/215 I tested this PR using rocko + meta-rpi master on rpi3b and rpi3b+. Boots ok, wifi connectivity tested with NM and bluetooth pair with bluetoothctl. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
On Wed, Mar 28, 2018 at 1:38 PM, Sherif Omran wrote: > Please use Morty, it works fine. > I don't think that is true though. It needs newer firmware. Not even master has it. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
Hi guys, On Wed, Mar 28, 2018 at 2:40 PM, Paul Barker wrote: > On Wed, Mar 28, 2018 at 1:41 PM, Måns Zigher > wrote: > > Hi, > > > > Thanks I will do that. But I have other layers that depend on the rocko > of > > meta-raspberrypi so I believe I will have to use the rocko at some point > but > > for testing I will try Morty. What is the reason for using Morty do you > > know? Is rocko unstable? > > > > Yea, we need to get this fixed in rocko. My test device for > raspberrypi3 is a Model B v1.2, not a B+ so you may have to help us > out with testing here. > > Could you try out core-image-base built from master with just the > required layers? If that works then a kernel/firmware backport is > likely what's needed. > > Today I will have 3b+ support PR to master. Afterwards we can start backporting things as needed. I'm currently only interested in rocko but if other people are willing to do it, we can PR stuff in older versions too. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] how to install rpi-config package?
On Thu, Mar 8, 2018 at 11:17 AM, Paul Barker wrote: > On Thu, Mar 8, 2018 at 6:20 AM, kk wrote: > > This is ok: > > $ bitbake rpi-config > > But I check the image directory under workdir, I found nothing in it, > and no > > command raspi-config. > > > > The rpi-config recipe creates the config.txt file in the > "tmp/deploy/images//bcm2835-bootfiles/" directory (if I've > got the path right) which is then copied to the boot partition for an > SD card image. > > I believe raspi-config is specific to the Raspbian distribution and > isn't used in images built with OpenEmbedded. Paul is correct. Actually there is almost a name clash here. rpi-config in meta-raspberrypi is a recipe which deploys the config.txt in deploy directory. The raspbian tool that you refer to is not included / integrated in oe but has a very similar name: raspi-config . So at this point when baking rpi-config all you get is a config.txt in the deploy directory. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] linux kernel rt
On Thu, Mar 1, 2018 at 1:59 PM, Andreas Müller wrote: > On Fri, Jan 26, 2018 at 3:09 PM, Trevor Woerner > wrote: > > On Fri, Jan 26, 2018 at 3:43 AM, Martin Hundebøll > > wrote: > >> > >> > >> > >> On 2018-01-26 04:51, Khem Raj wrote: > >>> > >>> > >>> Secondly, I wonder how good is upstream mainline kernel for rpi now a > >>> days, we could always have a mainline recipe as an option and use it > as base > >>> for things like rt. > >> > >> > >> Apart from runtime device tree overlay support for RPi hats/extension > >> boards, mainline linux fully supports each RPi revision. > >> > >> I guess linux-yocto-rt would be just fine... > >> > > > > Does anyone know if the FIQ bug has been fixed upstream? The last time I > > looked into PREEMPT_RT on the RPi, the only way to make it work/stable > was > > to patch the FIQ issue, or disable FIQ altogether (not ideal). This patch > > was outside both the kernel and the PREEMPT_RT patch. > > > > -- > Seems RPi.org made some progress on this[1]. > > If I only had some time left to give this a try... > > [1] https://github.com/raspberrypi/linux/issues/2244# > issuecomment-369597357 Nice. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip] Wifi driver on CHIP boards?
On Thu, Feb 22, 2018 at 8:34 PM, Drew Moseley wrote: > On 09/04/2017 06:17 AM, Andrei Gherzan wrote: > > On Wed, Aug 30, 2017 at 11:44 PM, Drew Moseley > wrote: > >> Has anyone managed to use the onboard WIFI for the CHIP boards in the >> current meta-chip repo? I added the kernel-module-r8723bs and rtl8723bs >> packages to my build and setup a wpa_supplicant.conf that works on other >> boards but I get error messages about power save. A few google searches >> suggested some power save changes but nothing I tried worked. >> >> root@chip:~# ifup wlan0 >> Successfully initialized wpa_supplicant >> [ 172.875000] rtl8723bs: accquire FW from file:rtlwifi/rtl8723bs_nic.bin >> [ 174.225000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready >> [ 174.235000] RTL8723BS: set bssid:00:00:00:00:00:00 >> ioctl[SIOCSIWAP]: Operation not permitted >> udhcpc (v1.24.1) started >> Sending discover... >> [ 175.855000] RTL8723BS: nolinked power save enter >> Sending discover... >> Sending discover... >> No lease, forking to background >> root@chip:~# [ 184.58] RTL8723BS: nolinked power save leave >> [ 184.80] RTL8723BS: set bssid:20:c9:d0:18:7a:95 >> [ 184.81] RTL8723BS: set ssid [caribbean] fw_state = 0x0088 >> [ 194.605000] RTL8723BS: nolinked power save enter >> [ 195.85] RTL8723BS: nolinked power save leave >> [ 196.06] RTL8723BS: set bssid:00:00:00:00:00:00 >> >> > We use the same packages in resinos to add wifi support and everything > seems sane. However we only tested with NM not directly with wpa. > > ref: https://github.com/resin-os/resin-chip/pull/23 > > Andrei > > > Andrei, > > Are you certain this is working in resinos currently? I modified my > config to use NetworkManager and it has similar behavior. The "nolinked > power save" messages are evidently debug so I ignore them but I do get the > following: > > [ 246.05] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = > 0x0008 > [ 246.145000] RTL8723BS: start auth > [ 246.15] RTL8723BS: auth success, start assoc > [ 249.225000] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = > 0x0008 > [ 249.42] RTL8723BS: start auth > [ 249.43] RTL8723BS: auth success, start assoc > [ 252.885000] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = > 0x0008 > [ 253.105000] RTL8723BS: start auth > [ 253.115000] RTL8723BS: auth success, start assoc > [ 257.075000] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = > 0x0008 > [ 257.305000] RTL8723BS: start auth > [ 257.315000] RTL8723BS: auth success, start assoc > [ 268.225000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > > and then no connection. I even disabled encryption temporarily on my wifi > and was unable to connect. > > I tried to build a resinos image for CHIP to try it but was unsuccessful. > Do you have any binaries I can try? > > Also, I installed the stock debian from flash.getchip.com and it was able > to connect so my hardware seems solid. > We dropped currently the work on getting chip support on resin. Or at least we postponed it so I don't have any binaries. But at that point wifi was working. I haven't played with the board lately so can't say too much about it. One thing I would do is: 1. compare the wifi firmware on yocto and debian ones 2. check the driver it uses (both the same?) 3. kernel versions? -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] [kronos]wayland lib linking added for libbrcmEGL to avoid undefined symbol while linking libbrcmEGL.so
On Thu, Feb 1, 2018 at 6:56 AM, HASEENAMOL wrote: > [meta-raspberrypi][PATCH] > > In wayland enabled build libbrcmEGL lib is using wayland functions, but > during the build it is not linking with wayland libraries. Hence if try to > link libbrcmEGL, will get undefined symbols. > > > > Best Regards > > Haseenamol > Hi, Thanks for your contribution. We are currently using github for sending patches to this yocto BSP. See http://meta-raspberrypi.readthedocs.io/en/latest/contributing.html for more information. Regards, -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Layer documentation for meta-raspberrypi
On Thu, Jan 25, 2018 at 6:34 PM, Khem Raj wrote: > On 12/21/17 7:15 AM, Andrei Gherzan wrote: > > Nice. Good job. > > > > -- > > Andrei Gherzan > > > > On Mon, Dec 18, 2017 at 9:57 PM, Mirza Krak > <mailto:mirza.k...@gmail.com>> wrote: > > > > On Dec 18, 2017 20:50, "Paul Barker" > <mailto:pbar...@toganlabs.com>> wrote: > > > > On Mon, Dec 11, 2017 at 12:20 PM, Paul Barker > > mailto:pbar...@toganlabs.com>> wrote: > > > On Mon, Dec 11, 2017 at 12:08 PM, Mirza Krak < > mirza.k...@gmail.com <mailto:mirza.k...@gmail.com>> wrote: > > >> 2017-12-11 12:55 GMT+01:00 Paul Barker <mailto:pbar...@toganlabs.com>>: > > >>> Hi all, > > >>> > > >>> As a quick announcement, the layer documentation for > meta-raspberrypi > > >>> is now available on Read the Docs: > > >>> http://meta-raspberrypi.readthedocs.io/en/latest/ > > <http://meta-raspberrypi.readthedocs.io/en/latest/> > > >>> > > > > >> > > >> One little thing though, the current "theme" used which I > assume is > > >> the default Sphinx theme is not optimal IMO. > > >> > > > > > > > > Thanks for the feedback. The conf.py file we're using is just > what was > > > generated by sphinx-quickstart with minimal tweaks. It sets > html_theme > > > which is obviously overriding the default for read the docs. > > > > > > I think I should be able to get the right behaviour by > commenting out > > > the html_theme setting completely. I'll give that a go and see > what > > > happens. > > > > > > > That worked. Looks much better! > > http://meta-raspberrypi.readthedocs.io/en/latest/index.html > > <http://meta-raspberrypi.readthedocs.io/en/latest/index.html> > > > > > > Great job. Agree that it looks much better. > > > what is that triplebyte thing? Can this be kept off > Where do you see that? -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] linux kernel rt
Hi Andreas, On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller wrote: > On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan wrote: > >> Hi all, >> >> On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller > > wrote: >> >>> On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak >>> wrote: >>> >>>> 2017-12-14 9:41 GMT+01:00 Andreas Müller : >>>> > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran < >>>> sherifomran2...@gmail.com> >>>> > wrote: >>>> >> >>>> >> hey guys, >>>> >> >>>> >> any body tried the real time kernel? I get an error, it is snot in >>>> the >>>> >> compatibility list. >>>> >> can we skip it? >>>> >> >>>> >> thanks >>>> >> >>>> >> -- >>>> > >>>> > Good news: I use RT kernel only together with VC4 graphics and have >>>> lots of >>>> > fun on PI2/3. >>>> > Bad news: As far as I know it is not in meta-raspberrypi but in my >>>> fork [1]. >>>> > There were attempts to land the RT-patches in meta-raspberrypi but >>>> that was >>>> > denied for huge patch size :( >>>> >>>> If the patch size was the only problem one can pull it by doing the >>>> following in the recipe: >>>> >>>> SRC_URI += " \ >>>> https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patc >>>> h-4.9.65-rt56.patch.gz;name=rt-patch >>>> \ >>>> " >>>> >>>> SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95" >>>> SRC_URI[rt-patch.sha256sum] = >>>> "47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539" >>>> >>>> Note that above sums are "random" and not the for the actually file >>>> but are there for reference. >>>> >>>> That way you do not need to keep a copy of it in meta-raspberrypi. >>>> >>>> -- >>>> >>> Hi Mirza, >>> >>> Problem is that patches need alignments sometimes either caused by >>> Raspberry-Pi-specific adjustments or versions not matching exactly - RT >>> kernel patch updates are less frequent than kernel updates. Anyway: git is >>> very good at maintaining huge text content and this should not be a problem >>> these days. Another discussion about RT kernel was to have an extra kernel >>> for it and I never understood why. To me that seems nothing but an extra >>> maintenance burden. >>> >>> However - just wrote to Paul: I plan to be at FOSDEM and we can discuss >>> there how to get back to one layer only (not mine!) making everybody happy >>> :) >>> >>> >> I remember the discussion. Indeed that was the reason and the >> recommendation was to maintain a separate linux-raspberry fork where >> whoever has interest in this will maintain on top of linux-raspberrypi this >> patch. Obviously that didn't happen but I'd like to see it landing. >> >> Yes that was one of the suggestions which made me say 'Thanks - this is > just additional maintenance burden and will not work for long time - I do > my own'. FWIW: That suggestion came at a time when you (Andrei) seemed > overworked totally (just to mention - PLEASE don't take it as criticism - I > know what I am talking of when it comes to 'overworked'). > You will be suprised but all of us are busy and this is a side project handled as good possible in our spare time. I do agree that there was a time where this project was a little demoted in priority. But even if that is the case, contributions are always welcomed - as you know. > > Why not simply one stable kernel with RT-patches applied if user decides > by an option? That is what I am doing for >1 year now and meta-raspi-light > is the one which caused me least efforts/headaches of all. And yes I know I > made life easy here by removing userland completely and taking care for > RPi2/3 only. > > I will always advocate against forks but definitely that is an option too. What I want to understand is why maintaining it in meta-raspberrypi was painful. Basically, the question is how do you currently maintain, rebase etc the rt patch? I would expect it to happen in a git tree as well. Isn't that the case? -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] linux kernel rt
Hi all, On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller wrote: > On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak wrote: > >> 2017-12-14 9:41 GMT+01:00 Andreas Müller : >> > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran < >> sherifomran2...@gmail.com> >> > wrote: >> >> >> >> hey guys, >> >> >> >> any body tried the real time kernel? I get an error, it is snot in the >> >> compatibility list. >> >> can we skip it? >> >> >> >> thanks >> >> >> >> -- >> > >> > Good news: I use RT kernel only together with VC4 graphics and have >> lots of >> > fun on PI2/3. >> > Bad news: As far as I know it is not in meta-raspberrypi but in my fork >> [1]. >> > There were attempts to land the RT-patches in meta-raspberrypi but that >> was >> > denied for huge patch size :( >> >> If the patch size was the only problem one can pull it by doing the >> following in the recipe: >> >> SRC_URI += " \ >> https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patc >> h-4.9.65-rt56.patch.gz;name=rt-patch >> \ >> " >> >> SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95" >> SRC_URI[rt-patch.sha256sum] = >> "47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539" >> >> Note that above sums are "random" and not the for the actually file >> but are there for reference. >> >> That way you do not need to keep a copy of it in meta-raspberrypi. >> >> -- >> > Hi Mirza, > > Problem is that patches need alignments sometimes either caused by > Raspberry-Pi-specific adjustments or versions not matching exactly - RT > kernel patch updates are less frequent than kernel updates. Anyway: git is > very good at maintaining huge text content and this should not be a problem > these days. Another discussion about RT kernel was to have an extra kernel > for it and I never understood why. To me that seems nothing but an extra > maintenance burden. > > However - just wrote to Paul: I plan to be at FOSDEM and we can discuss > there how to get back to one layer only (not mine!) making everybody happy > :) > > I remember the discussion. Indeed that was the reason and the recommendation was to maintain a separate linux-raspberry fork where whoever has interest in this will maintain on top of linux-raspberrypi this patch. Obviously that didn't happen but I'd like to see it landing. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] How to modify KERNEL_DEVICETREE?
Hi, You need to make that variable available in both sdcard generation code which resides in the image recipe and in the kernel recipe. You can do this by modifying that variable from local.conf (distro would work too I think but it doesn't sounds like the right place to be). -- Andrei Gherzan On Sun, Dec 17, 2017 at 6:36 PM, Drew Moseley wrote: > I'm trying to figure out how to properly modify the KERNEL_DEVICETREE > variable. It seems that the meta-raspberrypi layer uses that variable > in the sdcard_image-rpi.bbclass and defines it in the machine conf > layer. In poky, the variable is set and appended to in the various > linux-yocto recipes. If I make a similar change in a linux-raspberrypi > bbappend file, it works fine for the build of the linux-raspberrypi > recipe but when it is trying to package up the rpi-sdimg file, the > changes from the kernel recipe are not available and generally the build > will fail since the files expected during the image creation will not > have been created during the kernel build. > > I can envision several different workarounds here but I'm struggling to > come up with a solid fix. Does anyone have any suggestions? > > It also looks like the meta-freescale layer will have a similar issue. > > Drew > > > -- > ___ > 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] Layer documentation for meta-raspberrypi
Nice. Good job. -- Andrei Gherzan On Mon, Dec 18, 2017 at 9:57 PM, Mirza Krak wrote: > On Dec 18, 2017 20:50, "Paul Barker" wrote: > > On Mon, Dec 11, 2017 at 12:20 PM, Paul Barker > wrote: > > On Mon, Dec 11, 2017 at 12:08 PM, Mirza Krak > wrote: > >> 2017-12-11 12:55 GMT+01:00 Paul Barker : > >>> Hi all, > >>> > >>> As a quick announcement, the layer documentation for meta-raspberrypi > >>> is now available on Read the Docs: > >>> http://meta-raspberrypi.readthedocs.io/en/latest/ > >>> > > >> > >> One little thing though, the current "theme" used which I assume is > >> the default Sphinx theme is not optimal IMO. > >> > > > > > Thanks for the feedback. The conf.py file we're using is just what was > > generated by sphinx-quickstart with minimal tweaks. It sets html_theme > > which is obviously overriding the default for read the docs. > > > > I think I should be able to get the right behaviour by commenting out > > the html_theme setting completely. I'll give that a go and see what > > happens. > > > > That worked. Looks much better! > http://meta-raspberrypi.readthedocs.io/en/latest/index.html > > > Great job. Agree that it looks much better. > > Best Regards > Mirza > > > -- > ___ > 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-raspberrypi][PATCH] rpi-config: Setup lcd_rotate for Raspberry Pi display
On Thu, Nov 30, 2017 at 5:43 PM, Paul Barker wrote:
> On Thu, Nov 30, 2017 at 5:16 PM, Paul Barker
> wrote:
> > On Wed, Nov 29, 2017 at 10:20 PM, wrote:
> >> From: Drew Moseley
> >>
> >> Signed-off-by: Drew Moseley
> >> ---
> >> docs/extra-build-config.md | 6 ++
> >> recipes-bsp/bootfiles/rpi-config_git.bb | 6 ++
> >> 2 files changed, 12 insertions(+)
> >>
> >> diff --git a/docs/extra-build-config.md b/docs/extra-build-config.md
> >> index 380d969..0390eee 100644
> >> --- a/docs/extra-build-config.md
> >> +++ b/docs/extra-build-config.md
> >> @@ -170,6 +170,12 @@ Screen LCD, HDMI interface (<
> http://www.waveshare.com/7inch-HDMI-LCD-C.htm>) Rev
> >>
> >> WAVESHARE_1024X600_C_2_1 = "1"
> >>
> >> +If you would like to use the Raspberry Pi, 7 inch Capacitive Touch
> Screen
> >> +LCD (https://www.raspberrypi.org/products/raspberry-pi-touch-display/),
> please
> >> +set the following in your local.conf:
> >> +
> >> +RASPBERRYPI_DISPLAY = "1"
> >> +
> >> ## Enable UART
> >>
> >> RaspberryPi 0, 1, 2 and CM will have UART console enabled by default.
> >> diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb
> b/recipes-bsp/bootfiles/rpi-config_git.bb
> >> index ca4160b..e9a4fe2 100644
> >> --- a/recipes-bsp/bootfiles/rpi-config_git.bb
> >> +++ b/recipes-bsp/bootfiles/rpi-config_git.bb
> >> @@ -127,6 +127,12 @@ do_deploy() {
> >> echo "hdmi_cvt 1024 600 60 6 0 0 0" >> ${DEPLOYDIR}/bcm2835-
> bootfiles/config.txt
> >> echo "hdmi_drive=1" >> ${DEPLOYDIR}/bcm2835-
> bootfiles/config.txt
> >> fi
> >> +
> >> +# Raspberry Pi 7" Display/Touch screen (
> https://www.raspberrypi.org/products/raspberry-pi-touch-display/)
> >> +if [ "${RASPBERRYPI_DISPLAY}" = "1" ]; then
> >> +echo "# Raspberry Pi 7\" display/touch screen" >>
> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> >> +echo "lcd_rotate=2" >> ${DEPLOYDIR}/bcm2835-
> bootfiles/config.txt
> >> +fi
> >> }
> >>
> >> do_deploy_append_raspberrypi3-64() {
> >
> > This all looks good in general. Just a quick check though - are all
> > users of this display going to want that lcd_rotate value? I've never
> > used this display so not sure if that's specific to particular use
> > cases or not.
> >
> > If you're happy that this is applicable for everyone could you submit
> > this as a pull request on github
> > (https://github.com/agherzan/meta-raspberrypi).
> >
>
> Someone has come back off-list and said they use that display without
> the lcd_rotate setting. I think we'll have to drop this then.
>
> It may be good to have an RPI_EXTRA_CONFIG variable or similar to add
> arbitrary text to the config file, so you could do something like
> this:
>
> RPI_EXTRA_CONFIG = " \
> # Raspberry Pi 7\" display/touch screen \
> lcd_rotate=2 \
> "
>
> How does that sound?
>
>
>
I like this.
--
Andrei Gherzan
--
Andrei Gherzan
On Thu, Nov 30, 2017 at 5:43 PM, Paul Barker wrote:
> On Thu, Nov 30, 2017 at 5:16 PM, Paul Barker
> wrote:
> > On Wed, Nov 29, 2017 at 10:20 PM, wrote:
> >> From: Drew Moseley
> >>
> >> Signed-off-by: Drew Moseley
> >> ---
> >> docs/extra-build-config.md | 6 ++
> >> recipes-bsp/bootfiles/rpi-config_git.bb | 6 ++
> >> 2 files changed, 12 insertions(+)
> >>
> >> diff --git a/docs/extra-build-config.md b/docs/extra-build-config.md
> >> index 380d969..0390eee 100644
> >> --- a/docs/extra-build-config.md
> >> +++ b/docs/extra-build-config.md
> >> @@ -170,6 +170,12 @@ Screen LCD, HDMI interface (<
> http://www.waveshare.com/7inch-HDMI-LCD-C.htm>) Rev
> >>
> >> WAVESHARE_1024X600_C_2_1 = "1"
> >>
> >> +If you would like to use the Raspberry Pi, 7 inch Capacitive Touch
> Screen
> >> +LCD (https://www.raspberrypi.org/products/raspberry-pi-touch-display/),
> please
> >> +set the following in your local.conf:
> >> +
> >> +RASPBERRYPI_DISPLAY = "1"
> >> +
> >> ## Enable UART
> >>
> >> RaspberryPi 0, 1, 2 and CM will have UART console enabled by default.
> >> diff --git a/recipes-bsp/bo
Re: [yocto] [meta-raspberrypi][PATCH 1/5] x264: Disable asm for raspberrypi0-wifi
Hi all, On Thu, Nov 2, 2017 at 3:51 PM, Andrei Gherzan wrote: > This used to work in the past because this machine was based on raspberrypi > one. Now that they are separate, we need a configuration for it too > otherwise: > > | common/arm/quant-a.S: Assembler messages: > | common/arm/quant-a.S:362: Error: selected processor does not support > `rbit > r1,r1' in ARM mode > | common/arm/quant-a.S:363: Error: selected processor does not support > `rbit > r1,r1' in ARM mode > > Signed-off-by: Andrei Gherzan > --- > recipes-multimedia/x264/x264_git.bbappend | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/recipes-multimedia/x264/x264_git.bbappend > b/recipes-multimedia/x264/x264_git.bbappend > index c1cb3bc..505719e 100644 > --- a/recipes-multimedia/x264/x264_git.bbappend > +++ b/recipes-multimedia/x264/x264_git.bbappend > @@ -1 +1,2 @@ > EXTRA_OECONF_append_raspberrypi = " --disable-asm" > +EXTRA_OECONF_append_raspberrypi0-wifi = " --disable-asm" > -- > 2.7.4 > > Pushed a PR to github too: https://github.com/agherzan/meta-raspberrypi/pull/149 in which I fixed the two typos in this series: "firmware.in" and "zzImage". Andrei -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 5/5] firmware.in: Update to 20170811
Signed-off-by: Andrei Gherzan
---
recipes-bsp/common/firmware.inc | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
index ac2bd82..67078c1 100644
--- a/recipes-bsp/common/firmware.inc
+++ b/recipes-bsp/common/firmware.inc
@@ -1,10 +1,9 @@
-RPIFW_DATE ?= "20170811"
+RPIFW_DATE ?= "20171029"
RPIFW_SRC_URI ?=
"https://github.com/raspberrypi/firmware/archive/1.${RPIFW_DATE}.tar.gz";
RPIFW_S ?= "${WORKDIR}/firmware-1.${RPIFW_DATE}"
SRC_URI = "${RPIFW_SRC_URI}"
-SRC_URI[md5sum] = "afd09f9a6df14e32b6d832fd9f51d087"
-SRC_URI[sha256sum] =
"a25f6281d64732892a2e838cc2346f1a88505b5c77a57a6540755362ea64043a"
-
+SRC_URI[md5sum] = "4d27c1888a7bab3097471906e7b4a319"
+SRC_URI[sha256sum] =
"46ce28c8d87ef22bdcc57ac1836ca3f04d1ec6f46580ff5a30bf76b3c0822117"
PV = "${RPIFW_DATE}"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 4/5] rpi-base.inc: KERNEL_IMAGETYPE default to zzImage
We used to have this as the default but there was a bug at some point in the
firmware which didn't work with compressed kernel images. We switched to Image
and never changed it back even though that bug is long history.
In this way we will stop carrying 15M of a kernel image. 4M looks much better.
Signed-off-by: Andrei Gherzan
---
conf/machine/include/rpi-base.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/conf/machine/include/rpi-base.inc
b/conf/machine/include/rpi-base.inc
index 688227c..71c63cb 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -51,7 +51,7 @@ KERNEL_DEVICETREE ?= " \
# within u-boot to load the kernel.
KERNEL_BOOTCMD ??= "bootm"
KERNEL_IMAGETYPE_UBOOT ??= "uImage"
-KERNEL_IMAGETYPE ?= "${@bb.utils.contains('RPI_USE_U_BOOT', '1',
'${KERNEL_IMAGETYPE_UBOOT}', 'Image', d)}"
+KERNEL_IMAGETYPE ?= "${@bb.utils.contains('RPI_USE_U_BOOT', '1',
'${KERNEL_IMAGETYPE_UBOOT}', 'zImage', d)}"
MACHINE_FEATURES += "apm usbhost keyboard vfat ext2 screen touchscreen alsa
bluetooth wifi sdio"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 3/5] pi-blaster: An .inc file looks too much for this small recipe
Signed-off-by: Andrei Gherzan
---
recipes-devtools/pi-blaster/pi-blaster.inc| 21 -
recipes-devtools/pi-blaster/pi-blaster_git.bb | 22 +-
2 files changed, 21 insertions(+), 22 deletions(-)
delete mode 100644 recipes-devtools/pi-blaster/pi-blaster.inc
diff --git a/recipes-devtools/pi-blaster/pi-blaster.inc
b/recipes-devtools/pi-blaster/pi-blaster.inc
deleted file mode 100644
index 3cb79cc..000
--- a/recipes-devtools/pi-blaster/pi-blaster.inc
+++ /dev/null
@@ -1,21 +0,0 @@
-DESCRIPTION = "This project enables PWM on the GPIO pins you request of a
Raspberry Pi."
-HOMEPAGE = "https://github.com/sarfata/pi-blaster/";
-SECTION = "devel/libs"
-LICENSE = "MIT"
-LIC_FILES_CHKSUM =
"file://README.md;beginline=225;endline=252;md5=a012868ef5f83b9f257af253d7cb07a3"
-
-SRC_URI = "git://github.com/sarfata/pi-blaster \
- file://remove-initscript-lsb-dependency.patch \
-"
-
-S = "${WORKDIR}/git"
-
-inherit update-rc.d autotools
-
-INITSCRIPT_PACKAGES = "${PN}"
-INITSCRIPT_NAME_${PN} = "${PN}.boot.sh"
-INITSCRIPT_PARAMS_${PN} = "defaults 15 85"
-
-COMPATIBLE_MACHINE = "^rpi$"
-
-PACKAGE_ARCH = "${MACHINE_ARCH}"
diff --git a/recipes-devtools/pi-blaster/pi-blaster_git.bb
b/recipes-devtools/pi-blaster/pi-blaster_git.bb
index 730f9d3..2748459 100644
--- a/recipes-devtools/pi-blaster/pi-blaster_git.bb
+++ b/recipes-devtools/pi-blaster/pi-blaster_git.bb
@@ -1,3 +1,23 @@
-require pi-blaster.inc
+DESCRIPTION = "This project enables PWM on the GPIO pins you request of a
Raspberry Pi."
+HOMEPAGE = "https://github.com/sarfata/pi-blaster/";
+SECTION = "devel/libs"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM =
"file://README.md;beginline=225;endline=252;md5=a012868ef5f83b9f257af253d7cb07a3"
+
+SRC_URI = "git://github.com/sarfata/pi-blaster \
+ file://remove-initscript-lsb-dependency.patch \
+"
+
+S = "${WORKDIR}/git"
SRCREV = "1035ad7dffb270c40eec1bb3a654171a755fba98"
+
+inherit update-rc.d autotools
+
+INITSCRIPT_PACKAGES = "${PN}"
+INITSCRIPT_NAME_${PN} = "${PN}.boot.sh"
+INITSCRIPT_PARAMS_${PN} = "defaults 15 85"
+
+COMPATIBLE_MACHINE = "^rpi$"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 2/5] linux-raspberrypi: Update 4.9 recipe to 4.9.59
Signed-off-by: Andrei Gherzan
---
recipes-kernel/linux/linux-raspberrypi_4.9.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
index dd9afe2..061e893 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
@@ -1,8 +1,8 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-LINUX_VERSION ?= "4.9.50"
+LINUX_VERSION ?= "4.9.59"
-SRCREV = "46e2d4d1bd2c17e2f84dd90768321ee0bbaa6b8a"
+SRCREV = "e7976b2affa8c05bd299ead0ad9c36ddaf135b9d"
SRC_URI = "git://github.com/raspberrypi/linux.git;branch=rpi-4.9.y"
require linux-raspberrypi.inc
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 1/5] x264: Disable asm for raspberrypi0-wifi
This used to work in the past because this machine was based on raspberrypi one. Now that they are separate, we need a configuration for it too otherwise: | common/arm/quant-a.S: Assembler messages: | common/arm/quant-a.S:362: Error: selected processor does not support `rbit r1,r1' in ARM mode | common/arm/quant-a.S:363: Error: selected processor does not support `rbit r1,r1' in ARM mode Signed-off-by: Andrei Gherzan --- recipes-multimedia/x264/x264_git.bbappend | 1 + 1 file changed, 1 insertion(+) diff --git a/recipes-multimedia/x264/x264_git.bbappend b/recipes-multimedia/x264/x264_git.bbappend index c1cb3bc..505719e 100644 --- a/recipes-multimedia/x264/x264_git.bbappend +++ b/recipes-multimedia/x264/x264_git.bbappend @@ -1 +1,2 @@ EXTRA_OECONF_append_raspberrypi = " --disable-asm" +EXTRA_OECONF_append_raspberrypi0-wifi = " --disable-asm" -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/3] linux-firmware: Replace /lib with ${nonarch_base_libdir}
The entire patch set was merged to master. Thanks.
On 25 October 2017 06:43:28 BST, Michael Gloff wrote:
>From: Michael Gloff
>
> Use standard variable name and avoid
> QA errors when usermerge DISTRO_FEATURE is enabled.
>
>Signed-off-by: Michael Gloff
>---
> recipes-kernel/linux-firmware/linux-firmware_%.bbappend | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/recipes-kernel/linux-firmware/linux-firmware_%.bbappend
>b/recipes-kernel/linux-firmware/linux-firmware_%.bbappend
>index 565b735..daf1dbc 100644
>--- a/recipes-kernel/linux-firmware/linux-firmware_%.bbappend
>+++ b/recipes-kernel/linux-firmware/linux-firmware_%.bbappend
>@@ -10,17 +10,17 @@ do_install_append() {
> # (v7.45.41.46)
> local _firmware="brcmfmac43430-sdio.bin"
> local _oldmd5=9258986488eca9fe5343b0d6fe040f8e
>- if [ "$(md5sum ${D}/lib/firmware/brcm/$_firmware | awk '{print $1}')"
>!= "$_oldmd5" ]; then
>+ if [ "$(md5sum ${D}${nonarch_base_libdir}/firmware/brcm/$_firmware |
>awk '{print $1}')" != "$_oldmd5" ]; then
> _firmware=""
> bbwarn "linux-firmware stopped providing brcmfmac43430
> v7.45.41.26."
> else
> _firmware="${WORKDIR}/$_firmware"
> fi
>
>- mkdir -p ${D}/lib/firmware/brcm
>- install -m 0644 $_firmware ${WORKDIR}/brcmfmac43430-sdio.txt
>${D}/lib/firmware/brcm
>+ mkdir -p ${D}/${nonarch_base_libdir}/firmware/brcm
>+ install -m 0644 $_firmware ${WORKDIR}/brcmfmac43430-sdio.txt
>${D}${nonarch_base_libdir}/firmware/brcm
> }
>
> FILES_${PN}-bcm43430 += " \
>- /lib/firmware/brcm/brcmfmac43430-sdio.txt \
>+ ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
> "
>--
>2.14.3
>
>--
>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Rocko branch maintenance
Thanks Paul for your help with this BSP layer. You were a real help with pyro branch until now and I'm happy to see that you want to continue the same great work with rocko. I know that maintaining multiple stable branches is not an easy task so I'll take the pyro one. We will be able to maintain two stable branches in this way which should be great for our users. If anybody is interested in maintaining older stable release, please ping me and we can sort out something. On 25 October 2017 09:50:02 BST, Paul Barker wrote: >Hi all, > >I'd like to put myself forward as stable branch maintainer for >meta-raspberrypi again. The plan is to maintain rocko for 12 months in >line with the Yocto Project's current maintenance period. I'm >currently looking after pyro and I think it's gone well over the last >6 months. Obviously, pyro will also continue to be maintained until >it's around 12 months old. > >However, if anyone else wants to help spread the load then feel free >to step forward and propose yourself for rocko branch maintenance. > >Cheers, > >-- >Paul Barker >Togán Labs Ltd -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"
On Wed, Sep 27, 2017 at 02:45:07PM -0300, Otavio Salvador wrote: > Hello Martin, > > On Wed, Sep 27, 2017 at 2:34 PM, Martin Jansa wrote: > ... > >> Martin, do you have any idea how other alternative we have? > > > > In theory you can set QT_PACKAGES_ARCH to MACHINE_ARCH in rpi-base.inc > > to make it explicit, but that's also really bad (as e.g. rpi2 and rpi3 > > will each build it's own qtwebengine and all it's deps even when it > > should be the same for both). > > Agreed and that was the reason of we create MACHINE_SOCARCH in > meta-freescale. It allows for SoC specific packages but compatible > across machines. > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 Merged to master in the meanwhile. -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"
On Wed, Sep 27, 2017 at 4:23 PM, Martin Jansa wrote: > * this reverts commit 04b37dbdb79638b17a670280058400ffaf1b6ccb. > * this makes qtbase and everything which depends on some qt* recipe to > be effectivelly MACHINE_ARCH > > Signed-off-by: Martin Jansa > --- > dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend | 3 --- > 1 file changed, 3 deletions(-) > delete mode 100644 dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%. > bbappend > > diff --git a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend > b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend > deleted file mode 100644 > index ae3f1d3..000 > --- a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend > +++ /dev/null > @@ -1,3 +0,0 @@ > -# Copyright (C) 2017 O.S. Systems Software LTDA. > - > -PACKAGECONFIG_GL_rpi = "gles2 eglfs" What would be the solution though? -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] enable serial communication pi 3
On Wed, Sep 13, 2017 at 6:58 PM, Ayoub Zaki wrote: > > > On 13.09.2017 19:55, Khem Raj wrote: > > > > On Wed, Sep 13, 2017 at 12:27 AM, Ayoub Zaki > wrote: > >> I ran into the same problem: >> >> ENABLE_UART = "1" is not enough you should also add INSTALL_append= " >> rpi-config" to your local.conf and Serial port will be enabled. >> > > this should be automatically pulled in if you built a sdcard image. > > I'm using Wic so it does not work unless I extend the machine config with : > MACHINE_EXTRA_RRECOMMENDS += " bcm2835-bootfiles rpi-config" > That is correct. It is because the sdcard generation class includes this dependency when building an sdcard. BTW: bcm2835-bootfiles depends on rpi-config. About wic, this sounds like an issue anyway. wic uses IMAGE_BOOT_FILES. This variable includes the blobs provided by bcm28350-bootfiles and, in the same place, the config gets deployed (due to the dependency above). But in the wic case nobody triggers the compilation of these packages making wic to just ignore that specific entry in IMAGE_BOOT_FILES. This sounds like a bug to me. If you agree could you create an issue in github and maybe help us fix it as well? At this point I think bcm2835-bootfiles should be a MACHINE_ESSENTIAL_EXTRA_RDEPENDS. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Could not inherit file classes/pypi.bbclass
On Mon, Sep 11, 2017 at 1:40 PM, yahia farghaly wrote: > ok,thanks it is now building. i have another question, i don't need to use > the meta-gstreamer1.0 layer if i will use the gstreamer in your multimedia > layer with *IMAGE_INSTALL_append = gstreamer ?* > I personally haven't used that layer and the gstreamer is provided by poky: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes- multimedia/gstreamer . -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Could not inherit file classes/pypi.bbclass
On 11 Sep 2017 12:51, "yahia farghaly" wrote: i cloned the latest pyro version with meta-raspberry pi . i added meta-raspberrypi to bblayer and adjust the machine ?= "raspberry pi" when i bitbake rpi-hwup-image*.* it throws me the error of *ERROR: ParseError at /home/yahia/Desktop/elinux_dev/bake_factory/git_versions/poky/meta-raspberrypi/recipes-devtools/python/rpi-gpio_0.6.3.bb:8 <http://rpi-gpio_0.6.3.bb:8>: Could not inherit file classes/pypi.bbclass* There is a dependency in the README which you missed in the bblayers. Namely meta-python. -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/5] rpi-gpio: Update to 0.6.3
On Thu, Sep 7, 2017 at 2:24 PM, Andrei Gherzan wrote:
> As well integrate with meta-oe bbclass pypi.
>
> Signed-off-by: Andrei Gherzan
> ---
> recipes-devtools/python/rpi-gpio_0.6.2.bb | 21 -
> recipes-devtools/python/rpi-gpio_0.6.3.bb | 14 ++
> 2 files changed, 14 insertions(+), 21 deletions(-)
> delete mode 100644 recipes-devtools/python/rpi-gpio_0.6.2.bb
> create mode 100644 recipes-devtools/python/rpi-gpio_0.6.3.bb
>
> diff --git a/recipes-devtools/python/rpi-gpio_0.6.2.bb
> b/recipes-devtools/python/rpi-gpio_0.6.2.bb
> deleted file mode 100644
> index 9c72168..000
> --- a/recipes-devtools/python/rpi-gpio_0.6.2.bb
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -DESCRIPTION = "A module to control Raspberry Pi GPIO channels"
> -HOMEPAGE = "http://code.google.com/p/raspberry-gpio-python/";
> -SECTION = "devel/python"
> -LICENSE = "MIT"
> -LIC_FILES_CHKSUM = "file://LICENCE.txt;md5=9b95630a648966b142f1a0dcea001c
> b7"
> -
> -SRCNAME = "RPi.GPIO"
> -
> -SRC_URI = "\
> - http://pypi.python.org/packages/source/R/RPi.GPIO/${
> SRCNAME}-${PV}.tar.gz \
> - file://0001-Remove-nested-functions.patch \
> - "
> -SRC_URI[md5sum] = "9db86fd5f3bae872de9dbb068ee0b096"
> -SRC_URI[sha256sum] = "82acff0ef6bbe3cdf6f4dbdd73d96a
> dd5294bb94baf7f51c1d901861af3c2392"
> -
> -S = "${WORKDIR}/${SRCNAME}-${PV}"
> -
> -inherit distutils
> -
> -COMPATIBLE_MACHINE = "^rpi$"
> -
> diff --git a/recipes-devtools/python/rpi-gpio_0.6.3.bb
> b/recipes-devtools/python/rpi-gpio_0.6.3.bb
> new file mode 100644
> index 000..d0ff00a
> --- /dev/null
> +++ b/recipes-devtools/python/rpi-gpio_0.6.3.bb
> @@ -0,0 +1,14 @@
> +DESCRIPTION = "A module to control Raspberry Pi GPIO channels"
> +HOMEPAGE = "http://code.google.com/p/raspberry-gpio-python/";
> +SECTION = "devel/python"
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://LICENCE.txt;md5=9b95630a648966b142f1a0dcea001c
> b7"
> +
> +PYPI_PACKAGE = "RPi.GPIO"
> +inherit pypi distutils
> +
> +SRC_URI += "file://0001-Remove-nested-functions.patch"
> +SRC_URI[md5sum] = "e4abe1cfb5eacebe53078032256eb837"
> +SRC_URI[sha256sum] = "a5fc0eb5e401963b6c0a03650da6b4
> 2c4005f02d962b81241d96c98d0a578516"
> +
> +COMPATIBLE_MACHINE = "^rpi$"
> --
> 2.7.4
>
Please forgive the missing tag. I will not resend to avoid more emails.
I'll add it if a new version is needed.
Sorry once again,
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 5/5] userland: Update to current master HEAD
Signed-off-by: Andrei Gherzan
---
recipes-graphics/userland/userland_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-graphics/userland/userland_git.bb
b/recipes-graphics/userland/userland_git.bb
index 8ff1411..1fc0717 100644
--- a/recipes-graphics/userland/userland_git.bb
+++ b/recipes-graphics/userland/userland_git.bb
@@ -16,7 +16,7 @@ COMPATIBLE_MACHINE = "^rpi$"
SRCBRANCH = "master"
SRCFORK = "raspberrypi"
-SRCREV = "50d3cb5f4ee95a9513bb9f94d661947e9e6ac085"
+SRCREV = "3caf0cd4a61f46b71eff49422c36e1cd2727ab45"
SRC_URI = "\
git://github.com/${SRCFORK}/userland.git;protocol=git;branch=${SRCBRANCH} \
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 4/5] omxplayer: Update to current master HEAD
Signed-off-by: Andrei Gherzan --- recipes-multimedia/omxplayer/omxplayer_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-multimedia/omxplayer/omxplayer_git.bb b/recipes-multimedia/omxplayer/omxplayer_git.bb index 0e0f9ba..713dacf 100644 --- a/recipes-multimedia/omxplayer/omxplayer_git.bb +++ b/recipes-multimedia/omxplayer/omxplayer_git.bb @@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" DEPENDS = "libpcre libav virtual/egl boost freetype dbus openssl samba libssh libomxil coreutils-native curl-native" PR = "r4" -SRCREV = "061425a5eabf6e9ee43229911c073a863d144038" +SRCREV = "b8ff59dccd9307f10dad71bec2525a95bd6c603b" SRC_URI = "git://github.com/popcornmix/omxplayer.git;protocol=git;branch=master \ file://0001-Remove-Makefile.include-which-includes-hardcoded.patch \ file://0002-Libraries-and-headers-from-ffmpeg-are-installed-in-u.patch \ -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 3/5] pi-blaster: Update to current master HEAD
License in the README was moved a couple of lines below. Signed-off-by: Andrei Gherzan --- recipes-devtools/pi-blaster/pi-blaster.inc| 2 +- recipes-devtools/pi-blaster/pi-blaster_git.bb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/recipes-devtools/pi-blaster/pi-blaster.inc b/recipes-devtools/pi-blaster/pi-blaster.inc index 6ea4fa3..3cb79cc 100644 --- a/recipes-devtools/pi-blaster/pi-blaster.inc +++ b/recipes-devtools/pi-blaster/pi-blaster.inc @@ -2,7 +2,7 @@ DESCRIPTION = "This project enables PWM on the GPIO pins you request of a Raspbe HOMEPAGE = "https://github.com/sarfata/pi-blaster/"; SECTION = "devel/libs" LICENSE = "MIT" -LIC_FILES_CHKSUM = "file://README.md;beginline=212;endline=239;md5=a012868ef5f83b9f257af253d7cb07a3" +LIC_FILES_CHKSUM = "file://README.md;beginline=225;endline=252;md5=a012868ef5f83b9f257af253d7cb07a3" SRC_URI = "git://github.com/sarfata/pi-blaster \ file://remove-initscript-lsb-dependency.patch \ diff --git a/recipes-devtools/pi-blaster/pi-blaster_git.bb b/recipes-devtools/pi-blaster/pi-blaster_git.bb index ac812ab..730f9d3 100644 --- a/recipes-devtools/pi-blaster/pi-blaster_git.bb +++ b/recipes-devtools/pi-blaster/pi-blaster_git.bb @@ -1,3 +1,3 @@ require pi-blaster.inc -SRCREV = "9f45eb23a8a3b2d1c08d08a6d68f206fe91ecf4c" +SRCREV = "1035ad7dffb270c40eec1bb3a654171a755fba98" -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/5] python-sense-hat: Update to 2.2.0
As well integrate with meta-oe bbclass pypi.
Signed-off-by: Andrei Gherzan
---
recipes-devtools/python/python-sense-hat_2.1.0.bb | 28 ---
recipes-devtools/python/python-sense-hat_2.2.0.bb | 24 +++
2 files changed, 24 insertions(+), 28 deletions(-)
delete mode 100644 recipes-devtools/python/python-sense-hat_2.1.0.bb
create mode 100644 recipes-devtools/python/python-sense-hat_2.2.0.bb
diff --git a/recipes-devtools/python/python-sense-hat_2.1.0.bb
b/recipes-devtools/python/python-sense-hat_2.1.0.bb
deleted file mode 100644
index e990a28..000
--- a/recipes-devtools/python/python-sense-hat_2.1.0.bb
+++ /dev/null
@@ -1,28 +0,0 @@
-SUMMARY = "Python module to control the Raspberry Pi Sense HAT used in the
Astro Pi mission"
-HOMEPAGE = "https://github.com/RPi-Distro/python-sense-hat";
-SECTION = "devel/python"
-LICENSE = "BSD"
-LIC_FILES_CHKSUM = "file://LICENCE.txt;md5=d80fe312e1ff5fbd97369b093bf21cda"
-
-SRCNAME = "sense-hat"
-
-SRC_URI =
"https://pypi.python.org/packages/source/s/${SRCNAME}/${SRCNAME}-${PV}.tar.gz";
-
-SRC_URI[md5sum] = "71217f15ea963040f06e2f50722186ca"
-SRC_URI[sha256sum] =
"c6c76707c0ea514e4b0f1f96f1b5b79755875891aae037df7434b6aad7b9dbca"
-
-S = "${WORKDIR}/${SRCNAME}-${PV}"
-
-inherit setuptools
-
-DEPENDS += " \
-jpeg \
-zlib \
-freetype \
-"
-
-RDEPENDS_${PN} += " \
-python-numpy \
-python-rtimu \
-python-imaging \
-"
diff --git a/recipes-devtools/python/python-sense-hat_2.2.0.bb
b/recipes-devtools/python/python-sense-hat_2.2.0.bb
new file mode 100644
index 000..f7c4e34
--- /dev/null
+++ b/recipes-devtools/python/python-sense-hat_2.2.0.bb
@@ -0,0 +1,24 @@
+SUMMARY = "Python module to control the Raspberry Pi Sense HAT used in the
Astro Pi mission"
+HOMEPAGE = "https://github.com/RPi-Distro/python-sense-hat";
+SECTION = "devel/python"
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://LICENCE.txt;md5=d80fe312e1ff5fbd97369b093bf21cda"
+
+inherit setuptools pypi
+
+PYPI_PACKAGE = "sense-hat"
+
+SRC_URI[md5sum] = "69929250cb72349a8a82edf2584b1d83"
+SRC_URI[sha256sum] =
"f000998d042d96ed722d459312e1bebd0107f9f3015cd34b3e4fabcab9c800af"
+
+DEPENDS += " \
+jpeg \
+zlib \
+freetype \
+"
+
+RDEPENDS_${PN} += " \
+python-numpy \
+python-rtimu \
+python-imaging \
+"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/5] rpi-gpio: Update to 0.6.3
As well integrate with meta-oe bbclass pypi.
Signed-off-by: Andrei Gherzan
---
recipes-devtools/python/rpi-gpio_0.6.2.bb | 21 -
recipes-devtools/python/rpi-gpio_0.6.3.bb | 14 ++
2 files changed, 14 insertions(+), 21 deletions(-)
delete mode 100644 recipes-devtools/python/rpi-gpio_0.6.2.bb
create mode 100644 recipes-devtools/python/rpi-gpio_0.6.3.bb
diff --git a/recipes-devtools/python/rpi-gpio_0.6.2.bb
b/recipes-devtools/python/rpi-gpio_0.6.2.bb
deleted file mode 100644
index 9c72168..000
--- a/recipes-devtools/python/rpi-gpio_0.6.2.bb
+++ /dev/null
@@ -1,21 +0,0 @@
-DESCRIPTION = "A module to control Raspberry Pi GPIO channels"
-HOMEPAGE = "http://code.google.com/p/raspberry-gpio-python/";
-SECTION = "devel/python"
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://LICENCE.txt;md5=9b95630a648966b142f1a0dcea001cb7"
-
-SRCNAME = "RPi.GPIO"
-
-SRC_URI = "\
-
http://pypi.python.org/packages/source/R/RPi.GPIO/${SRCNAME}-${PV}.tar.gz \
- file://0001-Remove-nested-functions.patch \
- "
-SRC_URI[md5sum] = "9db86fd5f3bae872de9dbb068ee0b096"
-SRC_URI[sha256sum] =
"82acff0ef6bbe3cdf6f4dbdd73d96add5294bb94baf7f51c1d901861af3c2392"
-
-S = "${WORKDIR}/${SRCNAME}-${PV}"
-
-inherit distutils
-
-COMPATIBLE_MACHINE = "^rpi$"
-
diff --git a/recipes-devtools/python/rpi-gpio_0.6.3.bb
b/recipes-devtools/python/rpi-gpio_0.6.3.bb
new file mode 100644
index 000..d0ff00a
--- /dev/null
+++ b/recipes-devtools/python/rpi-gpio_0.6.3.bb
@@ -0,0 +1,14 @@
+DESCRIPTION = "A module to control Raspberry Pi GPIO channels"
+HOMEPAGE = "http://code.google.com/p/raspberry-gpio-python/";
+SECTION = "devel/python"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENCE.txt;md5=9b95630a648966b142f1a0dcea001cb7"
+
+PYPI_PACKAGE = "RPi.GPIO"
+inherit pypi distutils
+
+SRC_URI += "file://0001-Remove-nested-functions.patch"
+SRC_URI[md5sum] = "e4abe1cfb5eacebe53078032256eb837"
+SRC_URI[sha256sum] =
"a5fc0eb5e401963b6c0a03650da6b42c4005f02d962b81241d96c98d0a578516"
+
+COMPATIBLE_MACHINE = "^rpi$"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH v2 1/2] bluez5: add functions/variables to enabling bluetooth on another raspberrypi
On Wed, Sep 6, 2017 at 10:18 AM, Paul Barker wrote:
> On Tue, Sep 5, 2017 at 11:34 PM, Yusuke Mitsuki
> wrote:
> > functions/variables in this bbappend implemented for only raspberrypi3.
> > But these must be able to used to enabling bluetooth on another
> raspberrypi that has bluetooth feature such as raspberrypi0-wifi.
> >
> > The simple solution is a duplicating these but it is not good ideas for
> maintainance.
> >
> > Add functions/variables follows to simplify to enabling bluetooth on
> another raspberrypi that has bluetooth.
> > - BCM_BT_SOURCES
> > - enable_bcm_bluetooth()
> > - BCM_BT_FIRMWARE
> > - BCM_BT_SERVICE
> >
> > Signed-off-by: Yusuke Mitsuki
> > ---
> > recipes-connectivity/bluez5/bluez5_%.bbappend | 18 ++
> > 1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/recipes-connectivity/bluez5/bluez5_%.bbappend
> b/recipes-connectivity/bluez5/bluez5_%.bbappend
> > index 956d776..b2fbf22 100644
> > --- a/recipes-connectivity/bluez5/bluez5_%.bbappend
> > +++ b/recipes-connectivity/bluez5/bluez5_%.bbappend
> > @@ -1,6 +1,6 @@
> > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> >
> > -SRC_URI_append_raspberrypi3 = " \
> > +BCM_BT_SOURCES = " \
> > file://BCM43430A1.hcd \
> > file://0001-bcm43xx-Add-bcm43xx-3wire-variant.patch \
> > file://0002-bcm43xx-The-UART-speed-must-be-reset-after-the-firmw.patch
> \
> > @@ -9,7 +9,7 @@ SRC_URI_append_raspberrypi3 = " \
> > file://brcm43438.service \
> > "
> >
> > -do_install_append_raspberrypi3() {
> > +enable_bcm_bluetooth() {
> > install -d ${D}/lib/firmware/brcm/
> > install -m 0644 ${WORKDIR}/BCM43430A1.hcd ${D}/lib/firmware/brcm/
> BCM43430A1.hcd
> >
> > @@ -19,8 +19,18 @@ do_install_append_raspberrypi3() {
> > fi
> > }
> >
> > -FILES_${PN}_append_raspberrypi3 = " \
> > +BCM_BT_FIRMWARE = " \
> > /lib/firmware/brcm/BCM43430A1.hcd \
> > "
> >
> > -SYSTEMD_SERVICE_${PN}_append_raspberrypi3 = " brcm43438.service"
> > +BCM_BT_SERVICE = " brcm43438.service"
> > +
> > +SRC_URI_append_raspberrypi3 = " ${BCM_BT_SOURCES}"
> > +
> > +do_install_append_raspberrypi3() {
> > +enable_bcm_bluetooth
> > +}
> > +
> > +FILES_${PN}_append_raspberrypi3 = " ${BCM_BT_FIRMWARE}"
> > +
> > +SYSTEMD_SERVICE_${PN}_append_raspberrypi3 = " ${BCM_BT_SERVICE}"
> > --
> > 2.7.4
> >
>
> This and the follow up patch look excellent, should be easy to modify
> in the future if we need to.
>
> We have switched to using github pull requests for meta-raspberrypi.
> Could you open a pull request on
> https://github.com/agherzan/meta-raspberrypi with these changes
> please? Let me know if you have any issues doing that.
>
+1 from my side. Thanks for this change. We still try to keep patches
rolling to the mailing list too but the main development now happens
through PRs in github.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] bluez5: add functions for raspberrypi0-wifi
On Fri, Aug 25, 2017 at 9:17 PM, Yusuke Mitsuki <
mickey.happygolu...@gmail.com> wrote:
> okay. I will try.
>
> 2017-08-25 17:51 GMT+09:00 Paul Barker :
>
>> On Thu, Aug 24, 2017 at 1:05 PM, Yusuke Mitsuki
>> wrote:
>> > hciattach on raspberrypi0-wifi failed because BCM43430A1.hcd is not
>> found.
>> >
>> > Paches that in order to use bluetooth with BCM43430 are not enabled.
>> > Functions are only enabled with raspberrypi3 in bluez5_%.bbappend like
>> as follows:
>> >
>> > - SRC_URI_append_raspberrypi3
>> > - do_install_append_raspberrypi3()
>> > - FILES_${PN}_append_raspberrypi3
>> > - SYSTEMD_SERVICE_${PN}_append_raspberrypi3
>> >
>> > These should be enabled with raspberrypi0-wifi too.
>> >
>> > Signed-off-by: Yusuke Mitsuki
>> > ---
>> > recipes-connectivity/bluez5/bluez5_%.bbappend | 25
>> +
>> > 1 file changed, 25 insertions(+)
>> >
>> > diff --git a/recipes-connectivity/bluez5/bluez5_%.bbappend
>> b/recipes-connectivity/bluez5/bluez5_%.bbappend
>> > index 956d776..075dc2b 100644
>> > --- a/recipes-connectivity/bluez5/bluez5_%.bbappend
>> > +++ b/recipes-connectivity/bluez5/bluez5_%.bbappend
>> > @@ -24,3 +24,28 @@ FILES_${PN}_append_raspberrypi3 = " \
>> > "
>> >
>> > SYSTEMD_SERVICE_${PN}_append_raspberrypi3 = " brcm43438.service"
>> > +
>> > +SRC_URI_append_raspberrypi0-wifi = " \
>> > +file://BCM43430A1.hcd \
>> > +file://0001-bcm43xx-Add-bcm43xx-3wire-variant.patch \
>> > +file://0002-bcm43xx-The-UART-speed-must-be-reset-after-the-firmw.patch
>> \
>> > +file://0003-Increase-firmware-load-timeout-to-30s.patch \
>> > +file://0004-Move-the-43xx-firmware-into-lib-firmware.patch \
>> > +file://brcm43438.service \
>> > +"
>> > +
>> > +do_install_append_raspberrypi0-wifi() {
>> > +install -d ${D}/lib/firmware/brcm/
>> > +install -m 0644 ${WORKDIR}/BCM43430A1.hcd
>> ${D}/lib/firmware/brcm/BCM43430A1.hcd
>> > +
>> > +if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true',
>> 'false', d)}; then
>> > +install -d ${D}${systemd_unitdir}/system
>> > +install -m 0644 ${WORKDIR}/brcm43438.service
>> ${D}${systemd_unitdir}/system
>> > +fi
>> > +}
>> > +
>> > +FILES_${PN}_append_raspberrypi0-wifi = " \
>> > +/lib/firmware/brcm/BCM43430A1.hcd \
>> > +"
>> > +
>> > +SYSTEMD_SERVICE_${PN}_append_raspberrypi0-wifi = " brcm43438.service"
>>
>> I don't like the amount of duplication here. Could you define some
>> common variables and use those in the appends? This will make it
>> easier to change/upgrade in the future and avoid risk of the
>> duplicates falling out of sync with each other.
>>
>> Eg.
>>
>> RPI_WIFI_SOURCES = ""
>>
>> SRC_URI_append_raspberrypi3 = "${RPI_WIFI_SOURCES}"
>> SRC_URI_append_raspberrypi0-wifi = "${RPI_WIFI_SOURCES}"
>>
>>
I know Michal worked on this not long ago. Michal, could you give us some
hints here? Maybe backport the changes in resinOS?
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip] Wifi driver on CHIP boards?
On Wed, Aug 30, 2017 at 11:44 PM, Drew Moseley wrote: > Has anyone managed to use the onboard WIFI for the CHIP boards in the > current meta-chip repo? I added the kernel-module-r8723bs and rtl8723bs > packages to my build and setup a wpa_supplicant.conf that works on other > boards but I get error messages about power save. A few google searches > suggested some power save changes but nothing I tried worked. > > root@chip:~# ifup wlan0 > Successfully initialized wpa_supplicant > [ 172.875000] rtl8723bs: accquire FW from file:rtlwifi/rtl8723bs_nic.bin > [ 174.225000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > [ 174.235000] RTL8723BS: set bssid:00:00:00:00:00:00 > ioctl[SIOCSIWAP]: Operation not permitted > udhcpc (v1.24.1) started > Sending discover... > [ 175.855000] RTL8723BS: nolinked power save enter > Sending discover... > Sending discover... > No lease, forking to background > root@chip:~# [ 184.58] RTL8723BS: nolinked power save leave > [ 184.80] RTL8723BS: set bssid:20:c9:d0:18:7a:95 > [ 184.81] RTL8723BS: set ssid [caribbean] fw_state = 0x0088 > [ 194.605000] RTL8723BS: nolinked power save enter > [ 195.85] RTL8723BS: nolinked power save leave > [ 196.06] RTL8723BS: set bssid:00:00:00:00:00:00 > > We use the same packages in resinos to add wifi support and everything seems sane. However we only tested with NM not directly with wpa. ref: https://github.com/resin-os/resin-chip/pull/23 Andrei -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] kernel-yocto class requires BSP definition now
Hello all, Since... commit b6f78c7a27d6d3acae63cf1fdb7b56c11c919830 Author: Bruce Ashfield Date: Sun Aug 20 22:58:21 2017 -0400 kernel-yocto: ensure that only valid BSPs are built There was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched. This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot). With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user. [YOCTO: #11878] (From OE-Core rev: 44aea7b87307795fe4e089c51d45afccaa2f6525) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie ... the build fails for cases where there is no scc definition used. meta-raspberrypi was using this for configuration fragments feature but without defining any scc or using any feature branches etc. This got broken now since finding BSP definition files is a requirement in the class. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] userland: Add missing EGL_CAST defines
On Fri, Jul 14, 2017 at 2:31 PM, Khem Raj wrote: > On Fri, Jul 14, 2017 at 2:03 AM, Andrea Galbusera > wrote: > > Needed by libepoxy > > > > Signed-off-by: Andrea Galbusera > > --- > > .../0015-EGL-glplatform.h-define-EGL_CAST.patch| 32 > ++ > > recipes-graphics/userland/userland_git.bb | 1 + > > 2 files changed, 33 insertions(+) > > create mode 100644 recipes-graphics/userland/ > userland/0015-EGL-glplatform.h-define-EGL_CAST.patch > > > > diff --git > > a/recipes-graphics/userland/userland/0015-EGL-glplatform.h-define-EGL_CAST.patch > b/recipes-graphics/userland/userland/0015-EGL-glplatform. > h-define-EGL_CAST.patch > > new file mode 100644 > > index 000..5a80a26 > > --- /dev/null > > +++ b/recipes-graphics/userland/userland/0015-EGL-glplatform. > h-define-EGL_CAST.patch > > @@ -0,0 +1,32 @@ > > +From 382e3b16cbcc09d825540d5bd3e45a2fca4484fe Mon Sep 17 00:00:00 2001 > > +From: Andrea Galbusera > > +Date: Fri, 14 Jul 2017 09:52:54 +0200 > > +Subject: [PATCH] EGL/glplatform.h: define EGL_CAST > > + > > +C++ / C typecast macros for special EGL handle values: used by libepoxy > code > > +The definition comes from the updated version of this header in mesa. > > + > > +Upstream-Status: Pending > > +--- > > + interface/khronos/include/EGL/eglplatform.h | 7 +++ > > + 1 file changed, 7 insertions(+) > > + > > +diff --git a/interface/khronos/include/EGL/eglplatform.h > b/interface/khronos/include/EGL/eglplatform.h > > +index 1f7c930..c39d425 100644 > > +--- a/interface/khronos/include/EGL/eglplatform.h > > b/interface/khronos/include/EGL/eglplatform.h > > +@@ -202,4 +202,11 @@ EGLAPI void EGLAPIENTRY BEGL_ > GetDefaultDriverInterfaces(BEGL_DriverInterfaces *i > > + #include "interface/khronos/common/khrn_client_mangle.h" > > + #endif > > + > > ++/* C++ / C typecast macros for special EGL handle values */ > > ++#if defined(__cplusplus) > > ++#define EGL_CAST(type, value) (static_cast(value)) > > ++#else > > ++#define EGL_CAST(type, value) ((type) (value)) > > ++#endif > > ++ > > + #endif /* __eglplatform_h */ > > +-- > > LGTM > please merge it Your wish is my command :) Merged in master after builds passed. Thanks for you contribution, Andrea. Regards, Andrei -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] userland: Add missing EGL_CAST defines
Hello,
On Fri, Jul 14, 2017 at 10:03 AM, Andrea Galbusera wrote:
> Needed by libepoxy
>
> Signed-off-by: Andrea Galbusera
> ---
> .../0015-EGL-glplatform.h-define-EGL_CAST.patch| 32
> ++
> recipes-graphics/userland/userland_git.bb | 1 +
> 2 files changed, 33 insertions(+)
> create mode 100644 recipes-graphics/userland/
> userland/0015-EGL-glplatform.h-define-EGL_CAST.patch
>
> diff --git
> a/recipes-graphics/userland/userland/0015-EGL-glplatform.h-define-EGL_CAST.patch
> b/recipes-graphics/userland/userland/0015-EGL-glplatform.
> h-define-EGL_CAST.patch
> new file mode 100644
> index 000..5a80a26
> --- /dev/null
> +++ b/recipes-graphics/userland/userland/0015-EGL-glplatform.
> h-define-EGL_CAST.patch
> @@ -0,0 +1,32 @@
> +From 382e3b16cbcc09d825540d5bd3e45a2fca4484fe Mon Sep 17 00:00:00 2001
> +From: Andrea Galbusera
> +Date: Fri, 14 Jul 2017 09:52:54 +0200
> +Subject: [PATCH] EGL/glplatform.h: define EGL_CAST
> +
> +C++ / C typecast macros for special EGL handle values: used by libepoxy
> code
> +The definition comes from the updated version of this header in mesa.
> +
> +Upstream-Status: Pending
> +---
> + interface/khronos/include/EGL/eglplatform.h | 7 +++
> + 1 file changed, 7 insertions(+)
> +
> +diff --git a/interface/khronos/include/EGL/eglplatform.h
> b/interface/khronos/include/EGL/eglplatform.h
> +index 1f7c930..c39d425 100644
> +--- a/interface/khronos/include/EGL/eglplatform.h
> b/interface/khronos/include/EGL/eglplatform.h
> +@@ -202,4 +202,11 @@ EGLAPI void EGLAPIENTRY BEGL_
> GetDefaultDriverInterfaces(BEGL_DriverInterfaces *i
> + #include "interface/khronos/common/khrn_client_mangle.h"
> + #endif
> +
> ++/* C++ / C typecast macros for special EGL handle values */
> ++#if defined(__cplusplus)
> ++#define EGL_CAST(type, value) (static_cast(value))
> ++#else
> ++#define EGL_CAST(type, value) ((type) (value))
> ++#endif
> ++
> + #endif /* __eglplatform_h */
> +--
> +2.7.4
> +
> diff --git a/recipes-graphics/userland/userland_git.bb
> b/recipes-graphics/userland/userland_git.bb
> index 26bbfaf..893fcba 100644
> --- a/recipes-graphics/userland/userland_git.bb
> +++ b/recipes-graphics/userland/userland_git.bb
> @@ -34,6 +34,7 @@ SRC_URI = "\
> file://0012-implement-buffer-wrapping-interface-for-dispmanx.patch \
> file://0013-Implement-triple-buffering-for-wayland.patch \
> file://0014-GLES2-gl2ext.h-Define-GL_R8_EXT-and-GL_RG8_EXT.patch \
> +file://0015-EGL-glplatform.h-define-EGL_CAST.patch \
> "
> S = "${WORKDIR}/git"
>
Looks good to me.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] rpi-base: wic: generate entries for u-boot
On Thu, Jun 29, 2017 at 9:01 PM, Andrea Galbusera wrote:
> This commit allow wic generated images to work when we want u-boot to
> load the kernel image.
>
> Augment IMAGE_BOOT_FILES with the proper entries when KERNEL_IMAGETYPE
> is "uImage". More specifically add u-boot image and boot.scr to deployed
> files
> and give the proper name to the kernel image accordingly.
>
> Signed-off-by: Andrea Galbusera
> ---
> conf/machine/include/rpi-base.inc | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/conf/machine/include/rpi-base.inc b/conf/machine/include/rpi-
> base.inc
> index 4a0ea2a..71bb071 100644
> --- a/conf/machine/include/rpi-base.inc
> +++ b/conf/machine/include/rpi-base.inc
> @@ -83,7 +83,9 @@ def make_dtb_boot_files(d):
>
> IMAGE_BOOT_FILES ?= "bcm2835-bootfiles/* \
> ${@make_dtb_boot_files(d)} \
> - ${KERNEL_IMAGETYPE};${SDIMG_KERNELIMAGE} \
> + ${@bb.utils.contains('KERNEL_IMAGETYPE', 'uImage',
> '${KERNEL_IMAGETYPE}', '${KERNEL_IMAGETYPE};${SDIMG_KERNELIMAGE}', d)} \
> + ${@bb.utils.contains('KERNEL_IMAGETYPE', 'uImage',
> 'u-boot.bin;${SDIMG_KERNELIMAGE}', '', d)} \
> + ${@bb.utils.contains('KERNEL_IMAGETYPE', 'uImage',
> 'boot.scr;boot.scr', '', d)} \
> "
>
> # The kernel image is installed into the FAT32 boot partition and does
> not need
>
Merged to master. Thanks.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip] Jenkins, reviews and mailing list
On Tue, Jun 27, 2017 at 5:18 AM, Petter Mabacker wrote: > On Mon, 2017-06-26 at 17:12 +0100, Andrei Gherzan wrote: > > On Mon, Jun 26, 2017 at 2:29 PM, Trevor Woerner > wrote: > > On Mon, Jun 26, 2017 at 9:21 AM, Andrei Gherzan wrote: > > We've been testing a setup with meta-raspberrypi which seems to work > fine: > > PR to github integrated with a jenkins server and use mailing list for > > discussions. > > > > I propose to copy the same setup to meta-chip too. > > That's all fine. As the maintainer (thank you!) you're welcome to use > whatever workflow with which you're the happiest... as long as you > update the "Contributing" section of the README :-) > > > Sure. That makes sense. > > > Hi Andrei, > > I fully agree with Trevor, just update the README and lets rock! :) But > like you say I also believe it's good if people can take the time to also > send the patches to mailing list, so we don't risk losing those valuable > discussions that often is initated through the mailing list (since more > people will track the changes that way). My opinion is that this have work > good for meta-raspberrypi, so cannot see any reasons why it should work > great for meta-chip as well. > > Let us know when jenkins is up-and-running! > All is up and running. README updated too https://github.com/agherzan/meta-chip/pull/13 . Cheers, Andrei -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip][PATCH V3 0/4] Initial attempt at flashing instructions.
Hi, On Thu, Jun 29, 2017 at 2:12 AM, wrote: > From: Drew Moseley > > * V3: > > Cleanup README. > > Add CHIP_UBI_PAGE_SIZE variable to reuse the data from the machine > configuration. > Merged to master. Thanks, Drew. Andrei -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip][PATCH V2 0/3] Initial attempt at flashing instructions.
On Wed, Jun 28, 2017 at 2:06 PM, Drew Moseley wrote: > > On Jun 28, 2017, at 9:03 AM, Trevor Woerner wrote: > > On Sun, Jun 25, 2017 at 3:55 PM, wrote: > > From: Drew Moseley > > * V2: > > Updated README and layer dependencies. > > Added error checking to flashing script > > * V1: > > This set of patches adds the native tools and target components needed to > reflash the CHIP boards. Additionally a shell script is added to the > deploy > directory showing how to kick off a flash update. It's not ideal as I've > hardcoded a max size for the UBI image into the script and didn't see much > of an alternative. It does function though. > > > > Looks and works great! Thanks for investigating and getting this working > :-) > > Tested-by: Trevor Woerner > > > FYI, additional discussion is ongoing at https://github.com/ > agherzan/meta-chip/pull/9. I’ll have a V3 in a few days. The V3 changes > are primarily cosmetic. > Correct. There are some small things to tweak. Nothing major and it will get in soon. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip] Jenkins, reviews and mailing list
On Mon, Jun 26, 2017 at 2:29 PM, Trevor Woerner wrote: > On Mon, Jun 26, 2017 at 9:21 AM, Andrei Gherzan wrote: > > We've been testing a setup with meta-raspberrypi which seems to work > fine: > > PR to github integrated with a jenkins server and use mailing list for > > discussions. > > > > I propose to copy the same setup to meta-chip too. > > That's all fine. As the maintainer (thank you!) you're welcome to use > whatever workflow with which you're the happiest... as long as you > update the "Contributing" section of the README :-) > Sure. That makes sense. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-chip] Jenkins, reviews and mailing list
Hello all, We've been testing a setup with meta-raspberrypi which seems to work fine: PR to github integrated with a jenkins server and use mailing list for discussions. I recommend people pushing their patches to the mailing list too even if they send pull requests so people who don't use github that much can have a chance to be informed on what is changing. We've been dragging this setup for a couple of months (I think) now and it looks great especially easing the work of the maintainer. I propose to copy the same setup to meta-chip too. We will be using the same server for jenkins (https://yocto-ci.resin.io/) and the github repository https://github.com/agherzan/meta-chip . Yes, I am aware of multiple forks of the same repository but given that this repository saw some activity lately I will consolidate the work hoping that the other repositories will contribute back to it. Any comments? Regards, Andrei -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: deploy vfat partition
On Thu, Jun 22, 2017 at 10:11 PM, Matthew McClintock wrote: > On Wed, Jun 21, 2017 at 9:26 AM, Andrei Gherzan wrote: > > P.S.: Would really be helpful to push a PR to github too so I can merge > it > > easier. > > > FYI: https://github.com/agherzan/meta-raspberrypi/pull/86 > > -M > Looks good. Merged in master. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: deploy vfat partition
On Sun, Jun 18, 2017 at 7:51 PM, Matthew McClintock
wrote:
> On Sat, Jun 17, 2017 at 11:41 AM, Khem Raj wrote:
> > On Sat, Jun 17, 2017 at 8:20 AM, Tom Rini wrote:
> >> On Fri, Jun 16, 2017 at 06:05:07PM -0700, Khem Raj wrote:
> >>> On Fri, Jun 16, 2017 at 12:12 PM, Matthew McClintock
> >>> wrote:
> >>> > This is useful to update the bootloader/vfat partition from u-boot
> when
> >>> > you don't want to update everything:
> >>> >
> >>> > U-Boot> tftpboot 0x100 tmp/0VXje
> >>> > Waiting for Ethernet connection... done.
> >>> > Using sms0 device
> >>> > TFTP from server 192.168.0.1; our IP address is 192.168.0.26
> >>> > Filename 'image.vfat'.
> >>> > Load address: 0x100
> >>> > Loading: ## 40 MiB
> >>> > 2.1 MiB/s
> >>> > done
> >>> > Bytes transferred = 41943040 (280 hex)
> >>> > U-Boot> mmc part
> >>> >
> >>> > Partition Map for MMC device 0 -- Partition Type: DOS
> >>> >
> >>> > PartStart SectorNum Sectors UUIDType
> >>> > 1 819281920 a63a4fbc-01 0c Boot
> >>> > 2 90112 163840 a63a4fbc-02 83
> >>> > U-Boot> mmc erase 0x2000 0x14000
> >>> >
> >>> > MMC erase: dev # 0, block # 8192, count 81920 ... 81920 blocks
> erased:
> >>> > OK
> >>> > U-Boot> mmc write 0x100 0x2000 0x14000
> >>> >
> >>> > MMC write: dev # 0, block # 8192, count 81920 ... 81920 blocks
> written:
> >>> > OK
> >>> > U-Boot>
> >>> >
> >>> > Signed-off-by: Matthew McClintock
> >>> > ---
> >>> > classes/sdcard_image-rpi.bbclass | 8
> >>> > 1 file changed, 8 insertions(+)
> >>> >
> >>> > diff --git a/classes/sdcard_image-rpi.bbclass
> b/classes/sdcard_image-rpi.bbclass
> >>> > index af3e807..27a0dfc 100644
> >>> > --- a/classes/sdcard_image-rpi.bbclass
> >>> > +++ b/classes/sdcard_image-rpi.bbclass
> >>> > @@ -72,6 +72,10 @@ SDIMG = "${IMGDEPLOYDIR}/${IMAGE_NAME}
> .rootfs.rpi-sdimg"
> >>> > # Additional files and/or directories to be copied into the vfat
> partition from the IMAGE_ROOTFS.
> >>> > FATPAYLOAD ?= ""
> >>> >
> >>> > +# SD card vfat partition image name
> >>> > +SDIMG_VFAT = "${IMGDEPLOYDIR}/${IMAGE_NAME}.vfat"
> >>> > +SDIMG_LINK_VFAT = "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.vfat"
> >>> > +
> >>> > IMAGE_CMD_rpi-sdimg () {
> >>> >
> >>> > # Align partitions
> >>> > @@ -145,6 +149,10 @@ IMAGE_CMD_rpi-sdimg () {
> >>> > echo "${IMAGE_NAME}" > ${WORKDIR}/image-version-info
> >>> > mcopy -i ${WORKDIR}/boot.img -v
> ${WORKDIR}/image-version-info ::
> >>> >
> >>> > +# Deploy vfat partition
> >>> > +cp ${WORKDIR}/boot.img ${SDIMG_VFAT}
> >>> > +ln -sf ${SDIMG_VFAT} ${SDIMG_LINK_VFAT}
> >>> > +
> >>>
> >>> it is of use if I am not using u-boot ? is there any penalty ?
>
> Other than just having another thing copied into tmp there is no
> effect, even if you're not using u-boot.
>
> >>
> >> The stock firmware also uses a vfat partition, so this could just as
> >> easily hold those contents.
> >
> > yes it does, can it do the same operations like u-boot ?
>
I think what Khem is trying to say is if we don't need it (because I don't
think there is any use for it when using proprietary bootloader) can we
deploy it only in the case of uboot bootloader section?
P.S.: Would really be helpful to push a PR to github too so I can merge it
easier.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip][PATCH] chip: Make sure to append to MACHINE_EXTRA_RRECOMMENDS rather than overwriting
On Mon, Jun 12, 2017 at 12:56 PM, wrote: > From: Drew Moseley > > Signed-off-by: Drew Moseley > --- > conf/machine/chip.conf | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Looks good. Merged to master. Thanks. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip][PATCH] chip: Unclude kernel-image and kernel-devicetree in all images.
Hi, On Tue, Jun 6, 2017 at 11:13 PM, wrote: > From: Drew Moseley > > Add the kernel-image and kernel-devicetree packages to > MACHINE_ESSENTIAL_EXTRA_RDEPENDS to ensure they are deployed > into the UBI image since that is where UBoot expects to find > it. > > Signed-off-by: Drew Moseley > --- > conf/machine/chip.conf | 3 ++- > recipes-core/images/chip-hwup-image.bb | 6 -- > 2 files changed, 2 insertions(+), 7 deletions(-) Merged to master. Thanks for your contribution. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH v2] pi-blaster: update to include proper rpi3 support
On Thu, Jun 8, 2017 at 3:39 PM, Petter Mabäcker wrote: > Update to latest available revision, in order to include proper rpi3 > support as well as latest fixes. > > LIC_FILES_CHKSUM for the license text in README.md is changed to handle > fixes of whitespace and newlines in the license text, introduced by the > pi-blaster commit: '0e1a1df Cleaning up the README'. > > Signed-off-by: Petter Mabäcker > --- > .../files/remove-initscript-lsb-dependency.patch | 37 > -- > recipes-devtools/pi-blaster/pi-blaster.inc | 2 +- > recipes-devtools/pi-blaster/pi-blaster_git.bb | 2 +- > 3 files changed, 30 insertions(+), 11 deletions(-) > Merged to master Petter. Thanks for this. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] pi-blaster: update to include proper rpi3 support
On Thu, Jun 8, 2017 at 5:22 AM, Khem Raj wrote:
> On Wed, Jun 7, 2017 at 9:09 PM, Petter Mabäcker wrote:
> > 2017-06-08 00:54 skrev Khem Raj:
> >
> >
> > On Wed, Jun 7, 2017 at 2:17 PM Petter Mabäcker
> wrote:
> >>
> >> Update to latest available revision, in order to include proper rpi3
> >> support as well as latest fixes.
> >>
> >> Signed-off-by: Petter Mabäcker
> >> ---
> >> .../files/remove-initscript-lsb-dependency.patch | 37
> >> --
> >> recipes-devtools/pi-blaster/pi-blaster.inc | 2 +-
> >> recipes-devtools/pi-blaster/pi-blaster_git.bb | 2 +-
> >> 3 files changed, 30 insertions(+), 11 deletions(-)
> >>
> >> diff --git
> >> a/recipes-devtools/pi-blaster/files/remove-initscript-lsb-
> dependency.patch
> >> b/recipes-devtools/pi-blaster/files/remove-initscript-lsb-
> dependency.patch
> >> index 7ea9a3b..c8afe60 100644
> >> ---
> >> a/recipes-devtools/pi-blaster/files/remove-initscript-lsb-
> dependency.patch
> >> +++
> >> b/recipes-devtools/pi-blaster/files/remove-initscript-lsb-
> dependency.patch
> >> @@ -1,13 +1,28 @@
> >> -Remove dependencies on LSB functions
> >> +From 1338f98a279616f4e5e9ea30a25d1dfa0c7df5d6 Mon Sep 17 00:00:00 2001
> >> +From: =?UTF-8?q?Petter=20Mab=C3=A4cker?=
> >> +Date: Sun, 4 Jun 2017 12:22:40 +0200
> >> +Subject: [PATCH] Remove dependencies on LSB functions
> >> +MIME-Version: 1.0
> >> +Content-Type: text/plain; charset=UTF-8
> >> +Content-Transfer-Encoding: 8bit
> >> +
> >> +See this as a rebase of the previous 'Remove dependencies on LSB
> >> +functions patch' with only minor modifications from the original
> version,
> >> +based on the work done by Alex Lennon
> in
> >> +'25fd817 pi-blaster: Added recipe'.
> >>
> >> Upstream-Status: Inappropriate [configuration]
> >>
> >> -Signed-off-by: Alex Lennon
> >> +Signed-off-by: Petter Mabäcker
> >> +---
> >> + debian/pi-blaster.init | 38 +++---
> >> + 1 file changed, 7 insertions(+), 31 deletions(-)
> >>
> >> -diff -ur git.org/pi-blaster.boot.sh git/pi-blaster.boot.sh
> >> git.org/pi-blaster.boot.sh 2014-05-20 14:49:44.378582168 +0100
> >> -+++ git/pi-blaster.boot.sh 2014-05-20 14:51:08.330582386 +0100
> >> -@@ -28,12 +28,12 @@
> >> +diff --git a/debian/pi-blaster.init b/debian/pi-blaster.init
> >> +index b142d70..01a686c 100644
> >> +--- a/debian/pi-blaster.init
> >> b/debian/pi-blaster.init
> >> +@@ -28,12 +28,12 @@ SCRIPTNAME=/etc/init.d/$NAME
> >> [ -r /etc/default/$NAME ] && . /etc/default/$NAME
> >>
> >> # Load the VERBOSE setting and other rcS variables
> >> @@ -22,7 +37,7 @@ diff -ur git.org/pi-blaster.boot.sh
> >> git/pi-blaster.boot.sh
> >>
> >> #
> >> # Function that starts the daemon/service
> >> -@@ -77,48 +77,23 @@
> >> +@@ -77,48 +77,24 @@ do_stop()
> >>
> >> case "$1" in
> >> start)
> >> @@ -52,6 +67,7 @@ diff -ur git.org/pi-blaster.boot.sh
> >> git/pi-blaster.boot.sh
> >> # 'force-reload' alias
> >> #
> >> - log_daemon_msg "Restarting $DESC" "$NAME"
> >> ++ echo "Restarting $DESC" "$NAME"
> >> do_stop
> >> - case "$?" in
> >> -0|1)
> >> @@ -67,11 +83,14 @@ diff -ur git.org/pi-blaster.boot.sh
> >> git/pi-blaster.boot.sh
> >> - log_end_msg 1
> >> - ;;
> >> - esac
> >> -+ do_start
> >> ++do_start
> >> ;;
> >> *)
> >> - echo "Usage: $SCRIPTNAME {start|stop|status|restart|
> force-reload}"
> >> >&2
> >> -+ echo "Usage: $SCRIPTNAME {start|stop|restart}" >&2
> >> ++ echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
> >> exit 3
> >> ;;
> >> esac
> >> +--
> >> +1.9.1
> >> +
> >> diff --git a/recipes-devtools/pi-blaster/pi-blaster.inc
> >> b/recipes-devtools/pi-blaster/pi-blaster.inc
> >> index a3beccc..a548957 100644
> >> --- a/recipes-devtools/pi-blaster/pi-blaster.inc
> >> +++ b/recipes-devtools/pi-blaster/pi-blaster.inc
> >> @@ -2,7 +2,7 @@ DESCRIPTION = "This project enables PWM on the GPIO pins
> >> you request of a Raspbe
> >> HOMEPAGE = "https://github.com/sarfata/pi-blaster/";
> >> SECTION = "devel/libs"
> >> LICENSE = "MIT"
> >> -LIC_FILES_CHKSUM =
> >> "file://README.md;beginline=157;endline=170;md5=
> f20832f31126609af5a7bf2340014540"
> >> +LIC_FILES_CHKSUM =
> >> "file://README.md;beginline=212;endline=239;md5=
> a012868ef5f83b9f257af253d7cb07a3"
> >
> >
> > What changed here ?
> >
> > The license is added in the end of the README.md so in this case some
> > additional description + modifications earlier in the README.md caused
> the
> > license text to move place. When it comes to the license text I could
> only
> > find changes in whitespace and newlines. They seems to have been caused
> by
> > the pi-blaster commit: '0e1a1df Cleaning up the README'
> >
> > BR Petter
> >
> > $ diff -Naur ec5e1b4c.README.md README.md | tail -n 38
> >
>
> perfect add few lines to the commit message about this
That would be nice.
--
Re: [yocto] [PATCH][meta-raspberrypi] linux-raspberrypi_dev: don't use AUTOREV
On Thu, Jun 1, 2017 at 12:23 PM, Paul Barker wrote: > On Thu, Jun 1, 2017 at 8:10 AM, Martin Jansa > wrote: > > And it's not clear from the diff you send, but like linux-yocto-dev.bb > > example above, the recipe needs to be renamed from > linux-raspberrypi_dev.bb > > to linux-raspberrypi-dev.bb to make it different provider. > > > > On Thu, Jun 1, 2017 at 9:08 AM, Martin Jansa > wrote: > >> > >> Yes, Paul approach looks good to me, I think it was what was suggested > in > >> first replies to my SRCREV change and I agree with that, I just haven't > had > >> time to send updated patch. > >> > >> Paul if you have the patch ready please send it, thanks!. > >> > > I've submitted the patch via GitHub as per the new contributing > instructions for meta-raspberrypi. > > https://github.com/agherzan/meta-raspberrypi/pull/82 > > Funny. This was exactly what I wanted to propose. If the warning noise does not bother anyone, I'm up for this solution. PR merged to master. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH][meta-raspberrypi] linux-raspberrypi_dev: don't use AUTOREV
On Tue, May 30, 2017 at 6:29 PM, Khem Raj wrote: > On Tue, May 30, 2017 at 10:25 AM, Andre McCurdy > wrote: > > On Tue, May 30, 2017 at 10:15 AM, Paul Barker > wrote: > >> On 30 May 2017 5:08 p.m., "Khem Raj" wrote: > >> > >> On Tue, May 30, 2017 at 12:57 AM, Martin Jansa > >> wrote: > >>> * use latest revision in rpi-4.11.y branch > >>> * using AUTOREV causes bitbake to run git ls-remote on the github.com > >>> repository in order > >>> to convert AUTOREV to currently latest SRCREV even when you don't use > >>> linux-raspberrypi_dev > >>> at all, just happen to have meta-raspberrypi layer in your > >>> bblayers.conf, that's bad for > >>> people who want to be able to build without network access > (completely > >>> from premirror) > >>> > >> > >> These branches get rebased often so locking SRCREV caused another > >> kind of problem. what we can do is. > >> > >> 1. Let user like you override the SRCREC via a bbappend or conf file. > >> so change the assignment to ?= > >> 2. Delete the recipe completely. We lose some of upstream testing. > >> > >> We should be able to skip the recipe if it isn't selected as the > preferred > >> version and/or provider of "virtual/kernel". I'm out at the minute so > can't > >> look at it now but will try to take a look later this week. > > > > The linux-yocto-dev.bb recipe contains an example of doing that. > > > > ah perfect. Thats what we need here > > http://cgit.openembedded.org/openembedded-core/tree/meta/ > recipes-kernel/linux/linux-yocto-dev.bb?h=master#n28 > > please rename the recipe to be linux-raspberrypi-dev.bb and add the magic > above and send a v2 > > Using the magic above we still hardcode a revision there. So if a user wants to compile the recipe without setting the preferred provider it will fail. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to replace an arch*.inc file?
Hi, On Sat, May 27, 2017 at 2:34 AM, Paul D. DeRocco wrote: > I'd like to try the Linaro version of arch-armv8.inc in an RPi3 project, > because it has an ilp32 tune option. What's the correct way to incorporate > this? > Probably the easiest way would be to create a new machine configuration. Where is this linaro version of arch-armv8? -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Very strange issue where bitbake hangs at do_rootfs
On Fri, May 26, 2017 at 5:19 PM, Khem Raj wrote: > On Fri, May 26, 2017 at 5:52 AM, Andrei Gherzan wrote: > > Hello all, > > > > I moved recently on a new arch linux host and everything works fine with > one > > exception: when I build a custom distribution based on morty with many > > packages including kernel-modules (beaglebone), the build system hangs > > without any details. I hooked into package_manager.py RPM install and > > streamed output from `process = subprocess.Popen(cmd.split(), > > stderr=subprocess.STDOUT, stdout=subprocess.PIPE)` and it seems that it > > hangs in different places every time. Output example: > > > > --- > > > > Result of kernel-module-industrialio-sw-trigger postinst: 0 > > debug: Processing > > kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b@beaglebone in > > /work/resin/resinos/resin-beaglebone/build/tmp/work/ > beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rpms/ > beaglebone/kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b.beaglebone.rpm > > 1428:Installing kernel-module.. > [ > > 55%] > > Output from kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b@beaglebone: > > Executing kernel-module-lm8333 postinst with: /bin/sh > > /work/resin/resinos/resin-beaglebone/build/tmp/work/ > beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rootfs/// > oe_install/tmp/rpm-tmp.76459 > > 1 > > > > # kernel-module-lm8333 - postinst > > #!/bin/sh > > if [ -z "$D" ]; then > > depmod -a 4.4.55+ > > else > > # image.bbclass will call depmodwrapper after everything is > > installed, > > # no need to do it here as well > > : > > fi > > Result of kernel-module-lm8333 postinst: 0 > > debug: Processing > > kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b@beaglebone in > > /work/resin/resinos/resin-beaglebone/build/tmp/work/ > beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rpms/ > beaglebone/kernel-module-tca8418-keypad-4.4.55+git0+ > 903eb64c68-r22b.beaglebone.rpm > > 1429:Installing kernel-module.. > [ > > 55%] > > Output from > > kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b@beaglebone: > > Executing kernel-module-tca8418-keypad postinst with: /bin/sh > > /work/resin/resinos/resin-beaglebone/build/tmp/work/ > beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rootfs/// > oe_install/tmp/rpm-tmp.76459 > > 1 > > > > --- > > > > If I don't install kernel-modules build succeeds. > > > > Any hints on how to debug this further? I can't seem to find anything > > relevant in smart output. > > > > yeah rolling ditros are always intesting when you want to build fixed > releases from past. > one of things that helped me in past was to pin python3 to 3.5 but a > clean reinstall of arch > I got that problem solved automagically > Downgraded to 3.5 and didn't help sadly. Regards, Andrei -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Very strange issue where bitbake hangs at do_rootfs
Hello all, I moved recently on a new arch linux host and everything works fine with one exception: when I build a custom distribution based on morty with many packages including kernel-modules (beaglebone), the build system hangs without any details. I hooked into package_manager.py RPM install and streamed output from `process = subprocess.Popen(cmd.split(), stderr=subprocess.STDOUT, stdout=subprocess.PIPE)` and it seems that it hangs in different places every time. Output example: --- Result of kernel-module-industrialio-sw-trigger postinst: 0 debug: Processing kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b@beaglebone in /work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rpms/beaglebone/kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b.beaglebone.rpm 1428:Installing kernel-module.. [ 55%] Output from kernel-module-lm8333-4.4.55+git0+903eb64c68-r22b@beaglebone: Executing kernel-module-lm8333 postinst with: /bin/sh /work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rootfs///oe_install/tmp/rpm-tmp.76459 1 # kernel-module-lm8333 - postinst #!/bin/sh if [ -z "$D" ]; then depmod -a 4.4.55+ else # image.bbclass will call depmodwrapper after everything is installed, # no need to do it here as well : fi Result of kernel-module-lm8333 postinst: 0 debug: Processing kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b@beaglebone in /work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rpms/beaglebone/kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b.beaglebone.rpm 1429:Installing kernel-module.. [ 55%] Output from kernel-module-tca8418-keypad-4.4.55+git0+903eb64c68-r22b@beaglebone: Executing kernel-module-tca8418-keypad postinst with: /bin/sh /work/resin/resinos/resin-beaglebone/build/tmp/work/beaglebone-poky-linux-gnueabi/resin-image/1.0-r0/rootfs///oe_install/tmp/rpm-tmp.76459 1 --- If I don't install kernel-modules build succeeds. Any hints on how to debug this further? I can't seem to find anything relevant in smart output. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip][PATCH] Fix unclosed file
On Mon, Nov 28, 2016 at 7:51 PM, Frank Meerkoetter <
meerkoet...@googlemail.com> wrote:
> WARNING: /projects/meta-chip/recipes-kernel/linux/linux-chip_git.bb:
> :14: ResourceWarning: unclosed file <_io.TextIOWrapper
> name='/projects/meta-chip/recipes-kernel/linux/linux-chip/defconfig'
> mode='r' encoding='UTF-8'>
> ---
> recipes-kernel/linux/linux-chip_git.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/recipes-kernel/linux/linux-chip_git.bb
> b/recipes-kernel/linux/linux-chip_git.bb
> index 6f0b193..38df4ad 100644
> --- a/recipes-kernel/linux/linux-chip_git.bb
> +++ b/recipes-kernel/linux/linux-chip_git.bb
> @@ -69,4 +69,6 @@ python () {
> if 'CONFIG_KERNEL_LZO=y\n' in configfile.readlines():
> depends = d.getVar('DEPENDS', False)
> d.setVar('DEPENDS', depends + ' lzop-native')
> +
> +configfile.close()
> }
Fixed in master and pyro. Thank you.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip][PATCH] Fix missing LICENSE field for u-boot-chip
On Mon, Nov 28, 2016 at 8:45 PM, Frank Meerkoetter < meerkoet...@googlemail.com> wrote: > ERROR: /projects/meta-chip/recipes-bsp/u-boot/u-boot-chip_git.bb: This > recipe does not have the LICENSE field set (u-boot-chip) > ERROR: Failed to parse recipe: /data/projects/rpi-a2dp-sink/ > meta-chip/recipes-bsp/u-boot/u-boot-chip_git.bb > --- > recipes-bsp/u-boot/u-boot-chip_git.bb | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/recipes-bsp/u-boot/u-boot-chip_git.bb b/recipes-bsp/u-boot/ > u-boot-chip_git.bb > index 60db3e0..a5f2624 100644 > --- a/recipes-bsp/u-boot/u-boot-chip_git.bb > +++ b/recipes-bsp/u-boot/u-boot-chip_git.bb > @@ -2,6 +2,7 @@ require recipes-bsp/u-boot/u-boot.inc > > DESCRIPTION = "U-Boot port for C.H.I.P. boards" > > +LICENSE = "GPLv2+" > LIC_FILES_CHKSUM = "file://Licenses/README;md5= > 0507cd7da8e7ad6d6701926ec9b84c95" > > DEPENDS += "dtc-native" > > Fixed in master and pyro. Thank you. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Pi 0 minimal consumption reached with Yocto?
Hi, On Wed, May 17, 2017 at 10:36 AM, Julien Gueytat wrote: > Hi everyone, > > I'd like to try out the Pi 0 for a Time-lapse photography project. > I want to power it up with a solar rechargeable battery. Those kind of > battery that can be found on Amazon does bring at most 1.5W. > So... Let's say 100mA during the daylight. > > The question is : > Do you know what is the minimal consumption of a Pi0? > And if we can setup some idle mode during night? > > Best!! I don't think anybody did any power consumption investigations and provided results here but if you do, please do share with us. It would be nice to have it documented. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Pyro branch
Hi, On Tue, May 16, 2017 at 11:31 AM, Andrei Gherzan wrote: > On Mon, May 15, 2017 at 10:14 AM, Paul Barker wrote: >> Hi all, >> >> Yocto Project 2.3 has now been released so I think it's time to create >> a pyro branch for meta-raspberrypi. >> > > I'm setting up today mirroring jobs in jenkins so we can only work in > github and all the other repos will get updated automatically. As well > I'll merge whatever is left in github and start a branch as soon as I > finish with this. pyro branch is up. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Pyro branch
On Mon, May 15, 2017 at 10:14 AM, Paul Barker wrote: > Hi all, > > Yocto Project 2.3 has now been released so I think it's time to create > a pyro branch for meta-raspberrypi. > I'm setting up today mirroring jobs in jenkins so we can only work in github and all the other repos will get updated automatically. As well I'll merge whatever is left in github and start a branch as soon as I finish with this. > I've briefly discussed stable branch maintainership with Andrei and > I'd like to volunteer as maintainer of the pyro branch. That should > spread the workload out a little bit. Does anyone have any thoughts or > objections to that? -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] rpi0-w wifi&bluetooth problem
Hello, On Tue, May 16, 2017 at 5:34 AM, 김재환 wrote: > Hi. > > > > i build core-image-minimal for rpi0-w. > > it works nicely but not working wlan0 and bluetooth. > > > > so i tried this post > <https://raspinterest.wordpress.com/2017/02/28/configure-wlan0-and-bluetooth-in-yocto-raspberry-pi-3/>. > but still not working. > > > > the error was > > $ifup wlan0 > > Successfully initialized wpa_supplicant > > rfkill: cannot get wiphy information > > Could not read interface wlan0 flags: No such device > > WEXT: could not set interface 'wlan0' UP > > wlan0: Failed to initialize driver interface > > ifconfig: SIOCGIFFLAGS No such device > > > > anybody solve this problem? > Can you pastebin a dmesg log, please? I want to confirm that my theory is correct. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Pull requests and jenkins
On Fri, May 12, 2017 at 7:34 PM, Paul Barker wrote: > On Fri, May 12, 2017 at 7:05 PM, Andrei Gherzan wrote: >> Hi all, >> >> I know I promised long ago but finally I took a Friday to invest into >> github pull requests integrated with a jenkins server. >> >> The first PR on which I worked for this integration is >> https://github.com/agherzan/meta-raspberrypi/pull/67 . This PR: >> - migrates Readme to markdown file - any objections about this? >> - adds badges for jenkins builds and gitter room >> - add info about pull requests >> >> As well I pushed a PR from an external fork for testing - >> https://github.com/agherzan/meta-raspberrypi/pull/68 . This adds a log >> entry in gitignore which won't hurt anyway. >> >> Now, what I propose is to start using pull requests as main way of >> contributing and mailing list as an additional (optional) way of >> advertising changes. We will keep it though for general discussions >> but keep contributions and issues (bug tracking) in github. >> >> About the jenkins server. The current setup is the following: for each >> PR, jenkins triggers rpi-basic-image for rpi, rpi2 and rpi3 using the >> target branch as the one on which the dependencies will be checked out >> (poky, meta-oe etc). If all three builds succeed then the PR is >> approved. I plan to start to add weekly builds for master and last two >> branches (morty and krogoth at this point) and additional boards. But >> for now I think it's a good start. >> >> Thoughts? >> > > This looks great, cheers for setting it up! > > I'm doing nightly builds of my setup but that's a bit non-standard > (custom distro, musl libc, u-boot enabled, etc). For meta-raspberrypi > itself I think you've got it right - test against the appropriate > branch of poky without changing the default configuration too much. > > For the readme, I think we should split off > "docs/optional-build-configuration.md", "docs/board-configuration.md" > and maybe "docs/contributing.md" files to shorten the top-level file. > Does that sound sensible? We did touch this subject a little bit in private but in summary this is a topic that I really want to address in the near future: documentation. We start to have a pretty big readme and on the long term that is not feasible. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] Make CMDLINE overridable from outside
On Fri, May 12, 2017 at 8:13 PM, Paul Barker wrote:
> On Fri, Apr 28, 2017 at 4:37 PM, Gianfranco Costamagna
> wrote:
>> currently there is no way to override the default CMDLINE, lets set if only
>> if not already set from outside
>>
>> Signed-off-by: Gianfranco Costamagna
>> ---
>> recipes-kernel/linux/linux-raspberrypi.inc | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc
>> b/recipes-kernel/linux/linux-raspberrypi.inc
>> index cf61cce..9265d55 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>> @@ -21,7 +21,7 @@ KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
>> KERNEL_DEFCONFIG_raspberrypi3-64 ?= "bcmrpi3_defconfig"
>>
>> # CMDLINE for raspberrypi
>> -CMDLINE = "dwc_otg.lpm_enable=0 console=serial0,115200 root=/dev/mmcblk0p2
>> rootfstype=ext4 rootwait"
>> +CMDLINE ?= "dwc_otg.lpm_enable=0 console=serial0,115200 root=/dev/mmcblk0p2
>> rootfstype=ext4 rootwait"
>>
>> # Add the kernel debugger over console kernel command line option if enabled
>> CMDLINE_append = ' ${@base_conditional("ENABLE_KGDB", "1",
>> "kgdboc=serial0,115200", "", d)}'
>> --
>> 2.7.4
>>
>
> This looks good, I'll add it to my queue to test next week unless
> Andrei has time to pick it up. We've all been a bit busy, sorry you've
> not had a response sooner!
My fault. Completely missed this one. I added a review in github. All
it needs is a commit summary tweak.
Andrei
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] Pull requests and jenkins
Hi all, I know I promised long ago but finally I took a Friday to invest into github pull requests integrated with a jenkins server. The first PR on which I worked for this integration is https://github.com/agherzan/meta-raspberrypi/pull/67 . This PR: - migrates Readme to markdown file - any objections about this? - adds badges for jenkins builds and gitter room - add info about pull requests As well I pushed a PR from an external fork for testing - https://github.com/agherzan/meta-raspberrypi/pull/68 . This adds a log entry in gitignore which won't hurt anyway. Now, what I propose is to start using pull requests as main way of contributing and mailing list as an additional (optional) way of advertising changes. We will keep it though for general discussions but keep contributions and issues (bug tracking) in github. About the jenkins server. The current setup is the following: for each PR, jenkins triggers rpi-basic-image for rpi, rpi2 and rpi3 using the target branch as the one on which the dependencies will be checked out (poky, meta-oe etc). If all three builds succeed then the PR is approved. I plan to start to add weekly builds for master and last two branches (morty and krogoth at this point) and additional boards. But for now I think it's a good start. Thoughts? -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 2/2] mesa-gl: Enable gbm for rpi
Hi, On Wed, May 10, 2017 at 7:48 AM, Khem Raj wrote: > weston needs gbm support which is not > in userland > > Signed-off-by: Khem Raj > --- > recipes-graphics/mesa/mesa-gl_%.bbappend | 1 + > 1 file changed, 1 insertion(+) > create mode 100644 recipes-graphics/mesa/mesa-gl_%.bbappend > > diff --git a/recipes-graphics/mesa/mesa-gl_%.bbappend > b/recipes-graphics/mesa/mesa-gl_%.bbappend > new file mode 100644 > index 000..7897125 > --- /dev/null > +++ b/recipes-graphics/mesa/mesa-gl_%.bbappend > @@ -0,0 +1 @@ > +PACKAGECONFIG_append_rpi = " gbm" > -- Merged to master. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/2] userland: Add missing GLES2 defines
Hi,
On Wed, May 10, 2017 at 7:48 AM, Khem Raj wrote:
> Needed by weston
>
> Signed-off-by: Khem Raj
> ---
> ...-gl2ext.h-Define-GL_R8_EXT-and-GL_RG8_EXT.patch | 30
> ++
> recipes-graphics/userland/userland_git.bb | 1 +
> 2 files changed, 31 insertions(+)
> create mode 100644
> recipes-graphics/userland/userland/0014-GLES2-gl2ext.h-Define-GL_R8_EXT-and-GL_RG8_EXT.patch
>
> diff --git
> a/recipes-graphics/userland/userland/0014-GLES2-gl2ext.h-Define-GL_R8_EXT-and-GL_RG8_EXT.patch
>
> b/recipes-graphics/userland/userland/0014-GLES2-gl2ext.h-Define-GL_R8_EXT-and-GL_RG8_EXT.patch
> new file mode 100644
> index 000..2232d4b
> --- /dev/null
> +++
> b/recipes-graphics/userland/userland/0014-GLES2-gl2ext.h-Define-GL_R8_EXT-and-GL_RG8_EXT.patch
> @@ -0,0 +1,30 @@
> +From 55a66f56a14eb8c3ae8294860e49efc9c9598c46 Mon Sep 17 00:00:00 2001
> +From: Khem Raj
> +Date: Wed, 10 May 2017 06:39:34 +
> +Subject: [PATCH] GLES2/gl2ext.h: Define GL_R8_EXT and GL_RG8_EXT
> +
> +weston code uses these defines
> +Upstream-Status: Pending
> +
> +Signed-off-by: Khem Raj
> +---
> + interface/khronos/include/GLES2/gl2ext.h | 3 +++
> + 1 file changed, 3 insertions(+)
> +
> +diff --git a/interface/khronos/include/GLES2/gl2ext.h
> b/interface/khronos/include/GLES2/gl2ext.h
> +index 4eacf7f..283e3e1 100644
> +--- a/interface/khronos/include/GLES2/gl2ext.h
> b/interface/khronos/include/GLES2/gl2ext.h
> +@@ -327,6 +327,9 @@ typedef void* GLeglImageOES;
> + #define GL_RGBX_BRCM0x80EE
> + #endif
> +
> ++#define GL_R8_EXT 0x8229
> ++#define GL_RG8_EXT 0x822B
> ++
> + /* GL_EXT_texture_type_2_10_10_10_REV */
> + #ifndef GL_EXT_texture_type_2_10_10_10_REV
> + #define GL_UNSIGNED_INT_2_10_10_10_REV_EXT 0x8368
> +--
> +1.9.1
> +
> diff --git a/recipes-graphics/userland/userland_git.bb
> b/recipes-graphics/userland/userland_git.bb
> index 9526fae..1176ef2 100644
> --- a/recipes-graphics/userland/userland_git.bb
> +++ b/recipes-graphics/userland/userland_git.bb
> @@ -33,6 +33,7 @@ SRC_URI = "\
> file://0011-build-shared-library-for-vchostif.patch \
> file://0012-implement-buffer-wrapping-interface-for-dispmanx.patch \
> file://0013-Implement-triple-buffering-for-wayland.patch \
> +file://0014-GLES2-gl2ext.h-Define-GL_R8_EXT-and-GL_RG8_EXT.patch \
> "
> S = "${WORKDIR}/git"
>
Merged to master.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] how to apply custom kernel configuration?
On Sat, May 6, 2017 at 6:14 PM, Khem Raj wrote: > On Sat, May 6, 2017 at 9:45 AM, Andrea Galbusera wrote: >> Hi! >> >> I was wondering how to apply some extra kernel configuration from a custom >> layer via a bbappend. I know that with meta-raspberrypi there exist some >> variables you can define in local.conf that will drive how the kernel is >> configured: but what about some very specific device driver nobody than me >> is interest in? To me it seems it doesn't deserve a dedicated global oe >> variable. >> >> Some investigation showed this topic already came up on the list from time >> to time in the past (most recently in [1]). To me it looks like there is >> some common desire to get rid of the current "magic" carried out by >> linux-rpi.inc by moving the linux-raspberrypi recipes into the configuration >> fragments style. >> >> In the short term, my question are: how do you guys manage to add your >> custom kernel configurations? Do you rely on full blown static defconfigs? >> Have you found any reliable way to do "differential" configurations with the >> current state of metadata? >> >> In a longer term, I'd really like to help moving towards supporting >> configuration fragments for linux-raspberrypi, but I suspect it'd be a too >> much hard task for my current understanding of the whole kernel >> configuration workflow. Do you know of anyone already working on this or >> does anyone have a clear idea of what is needed to get the work done? Some >> times ago I tried to resurrect [2], but with no luck, probably due to some >> changes that happened in the linux-yocto files in the meanwhile. >> >> Comments from gurus are welcome! ;-) > > I have been hinting at using yocto kernel tooling. Idea is worth a pull > request > care sending one ? I'm not using config fragments myself but I was under the impression that we do support it. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Stable branch plans
Hello all, On Tue, May 2, 2017 at 12:19 PM, Paul Barker wrote: > Hi all, > > I've now got a bit of a vested interest in the next meta-raspberrypi > stable branch as I'm planning to use it as a demo platform for our new > Oryx distro. > I like that most of the people around meta-rpi have direct interest based on products they maintain / develop. This makes us all closely evolved. > In the past, the stable branch hasn't been created for a while after > the corresponding oe-core release. The changes made to the stable > branch after this haven't always been as conservative as I'd have > liked as well but that's just one opinion. I think we all agree that this is a trade off. We went down the late branch off strategy because stability was not of highest importance. And to be honest you can always "know" where to checkout even if you don't have a branch. I recommend an aggregation repository with submodules if you want to seal a specific setup. On the other hand I saw many times people getting confused on what branch to use. And I do think that the general trend is to match the branch name across all the layers you are using in your product. > > I'd like to propose the following for the pyro branch: > > * We should create the pyro branch within a week or two of the oe-core > pyro release. > > * After the pyro branch is created, changes on the pyro branch should > roughly follow the oe-core stable branch policy > (https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Policies). > I don't think we need to be incredibly strict but I do think we should > avoid making changes which may affect the behaviour of existing > recipes/bbappends. I would like us to keep doing stable-branch kernel > updates and adding new MACHINE definitions where possible without > affecting existing MACHINEs. > > This would make the pyro branch perfect for my use case. But obviously > I'm not the meta-raspberrypi maintainer and I'm not the only person > with a use case. So I'd like to know what others think of this, is > this a good plan for meta-raspberrypi stable branches or should we be > more relaxed? > > (I raised similar questions in response to another thread but I think > that email may have been missed by a few people so I'm starting a new > thread here in expectation that the oe-core pyro release is imminent) > I would vote for this too. Early branch off using stability branches. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] rpi-base: fix make_dtb_boot_files() for raspberrypi3-64
On Fri, Apr 21, 2017 at 10:37:52AM +0200, Andrea Galbusera wrote:
> Building the stock wic image for raspberrypi3-64 failed to find dtbs listed in
> IMAGE_BOOT_FILES. This patch updates the make_dtb_boot_files() function to
> account for dtbs listed in KERNEL_DEVICETREE that do include a path prefix:
> this is the case for things like broadcom/bcm2710-rpi-3-b.dtb (the dts dir
> layout in the kernel sources is different for arm64). Use the same approach
> already used for overlays/ dir. While at it also fix a typo in dtb overlay
> code path comments.
>
> Signed-off-by: Andrea Galbusera
> ---
> conf/machine/include/rpi-base.inc | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/conf/machine/include/rpi-base.inc
> b/conf/machine/include/rpi-base.inc
> index 517d5ba..4a0ea2a 100644
> --- a/conf/machine/include/rpi-base.inc
> +++ b/conf/machine/include/rpi-base.inc
> @@ -61,16 +61,17 @@ def make_dtb_boot_files(d):
>
> def transform(dtb):
> if dtb.endswith('dtb'):
> -# eg: bcm2708-rpi-b.dtb has:
> +# eg: whatever/bcm2708-rpi-b.dtb has:
> # DEPLOYDIR file: ${KERNEL_IMAGETYPE}-bcm2708-rpi-b.dtb
> # destination: bcm2708-rpi-b.dtb
> -src = '{}-{}'.format(imgtyp, dtb)
> -dst = dtb
> +base = os.path.basename(dtb)
> +src = '{}-{}'.format(imgtyp, base)
> +dst = base
> return '{};{}'.format(src, dst)
> elif dtb.endswith('dtbo'):
> # overlay dtb:
> # eg: overlays/hifiberry-amp.dtbo has:
> -# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbp
> +# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbo
> # destination: overlays/hifiberry-amp.dtbo
> base = os.path.basename(dtb)
> src = '{}-{}'.format(imgtyp, base)
> --
> 2.7.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
Merged to master. Thanks.
--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] rpi-base: fix make_dtb_boot_files() for raspberrypi3-64
On Fri, Apr 21, 2017 at 05:04:40PM +0100, Andrei Gherzan wrote:
> On Fri, Apr 21, 2017 at 10:37:52AM +0200, Andrea Galbusera wrote:
> > Building the stock wic image for raspberrypi3-64 failed to find dtbs listed
> > in
> > IMAGE_BOOT_FILES. This patch updates the make_dtb_boot_files() function to
> > account for dtbs listed in KERNEL_DEVICETREE that do include a path prefix:
> > this is the case for things like broadcom/bcm2710-rpi-3-b.dtb (the dts dir
> > layout in the kernel sources is different for arm64). Use the same approach
> > already used for overlays/ dir. While at it also fix a typo in dtb overlay
> > code path comments.
> >
> > Signed-off-by: Andrea Galbusera
> > ---
> > conf/machine/include/rpi-base.inc | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/conf/machine/include/rpi-base.inc
> > b/conf/machine/include/rpi-base.inc
> > index 517d5ba..4a0ea2a 100644
> > --- a/conf/machine/include/rpi-base.inc
> > +++ b/conf/machine/include/rpi-base.inc
> > @@ -61,16 +61,17 @@ def make_dtb_boot_files(d):
> >
> > def transform(dtb):
> > if dtb.endswith('dtb'):
> > -# eg: bcm2708-rpi-b.dtb has:
> > +# eg: whatever/bcm2708-rpi-b.dtb has:
> > # DEPLOYDIR file: ${KERNEL_IMAGETYPE}-bcm2708-rpi-b.dtb
> > # destination: bcm2708-rpi-b.dtb
> > -src = '{}-{}'.format(imgtyp, dtb)
> > -dst = dtb
> > +base = os.path.basename(dtb)
> > +src = '{}-{}'.format(imgtyp, base)
> > +dst = base
> > return '{};{}'.format(src, dst)
> > elif dtb.endswith('dtbo'):
> > # overlay dtb:
> > # eg: overlays/hifiberry-amp.dtbo has:
> > -# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbp
> > +# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbo
>
> Looks good to me but this seems like a typo.
Scratch that. Looks good all together.
--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] rpi-base: fix make_dtb_boot_files() for raspberrypi3-64
On Fri, Apr 21, 2017 at 10:37:52AM +0200, Andrea Galbusera wrote:
> Building the stock wic image for raspberrypi3-64 failed to find dtbs listed in
> IMAGE_BOOT_FILES. This patch updates the make_dtb_boot_files() function to
> account for dtbs listed in KERNEL_DEVICETREE that do include a path prefix:
> this is the case for things like broadcom/bcm2710-rpi-3-b.dtb (the dts dir
> layout in the kernel sources is different for arm64). Use the same approach
> already used for overlays/ dir. While at it also fix a typo in dtb overlay
> code path comments.
>
> Signed-off-by: Andrea Galbusera
> ---
> conf/machine/include/rpi-base.inc | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/conf/machine/include/rpi-base.inc
> b/conf/machine/include/rpi-base.inc
> index 517d5ba..4a0ea2a 100644
> --- a/conf/machine/include/rpi-base.inc
> +++ b/conf/machine/include/rpi-base.inc
> @@ -61,16 +61,17 @@ def make_dtb_boot_files(d):
>
> def transform(dtb):
> if dtb.endswith('dtb'):
> -# eg: bcm2708-rpi-b.dtb has:
> +# eg: whatever/bcm2708-rpi-b.dtb has:
> # DEPLOYDIR file: ${KERNEL_IMAGETYPE}-bcm2708-rpi-b.dtb
> # destination: bcm2708-rpi-b.dtb
> -src = '{}-{}'.format(imgtyp, dtb)
> -dst = dtb
> +base = os.path.basename(dtb)
> +src = '{}-{}'.format(imgtyp, base)
> +dst = base
> return '{};{}'.format(src, dst)
> elif dtb.endswith('dtbo'):
> # overlay dtb:
> # eg: overlays/hifiberry-amp.dtbo has:
> -# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbp
> +# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbo
Looks good to me but this seems like a typo.
--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/3] raspberrypi2.conf: Make SERIAL_CONSOLE overwritable
On Thu, Apr 20, 2017 at 06:18:14PM +0100, Andrei Gherzan wrote: > Signed-off-by: Andrei Gherzan > --- > conf/machine/raspberrypi2.conf | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/conf/machine/raspberrypi2.conf b/conf/machine/raspberrypi2.conf > index 9b4c02a..a17289c 100644 > --- a/conf/machine/raspberrypi2.conf > +++ b/conf/machine/raspberrypi2.conf > @@ -7,7 +7,7 @@ DEFAULTTUNE ?= "cortexa7thf-neon-vfpv4" > require conf/machine/include/tune-cortexa7.inc > include conf/machine/include/rpi-base.inc > > -SERIAL_CONSOLE = "115200 ttyAMA0" > +SERIAL_CONSOLE ?= "115200 ttyAMA0" > > UBOOT_MACHINE = "rpi_2_config" > VC4_CMA_SIZE ?= "cma-256" > -- > 2.12.2 > Entire patch set merged to master and morty. -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 2/3] raspberrypi3-64.conf: Make SERIAL_CONSOLE overwritable
Signed-off-by: Andrei Gherzan --- conf/machine/raspberrypi3-64.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/machine/raspberrypi3-64.conf b/conf/machine/raspberrypi3-64.conf index 7e99da1..5e2b80c 100644 --- a/conf/machine/raspberrypi3-64.conf +++ b/conf/machine/raspberrypi3-64.conf @@ -35,7 +35,7 @@ KERNEL_DEVICETREE = " \ overlays/vc4-kms-v3d.dtbo \ " -SERIAL_CONSOLE = "115200 ttyS0" +SERIAL_CONSOLE ?= "115200 ttyS0" VC4_CMA_SIZE ?= "cma-256" UBOOT_MACHINE = "rpi_3_config" -- 2.12.2 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 3/3] raspberrypi3.conf: Use a stand alone machine configuration
As well make all the variables assigned in a way that they can be
overwritten so we can give maximum flexibility to distros.
Signed-off-by: Andrei Gherzan
---
conf/machine/raspberrypi3.conf | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/conf/machine/raspberrypi3.conf b/conf/machine/raspberrypi3.conf
index 1ac5928..884d875 100644
--- a/conf/machine/raspberrypi3.conf
+++ b/conf/machine/raspberrypi3.conf
@@ -2,10 +2,14 @@
#@NAME: RaspberryPi 3 Development Board
#@DESCRIPTION: Machine configuration for the RaspberryPi 3
-MACHINEOVERRIDES = "raspberrypi2:${MACHINE}"
-include conf/machine/raspberrypi2.conf
+DEFAULTTUNE ?= "cortexa7thf-neon-vfpv4"
+require conf/machine/include/tune-cortexa7.inc
+include conf/machine/include/rpi-base.inc
MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-bcm43430"
-SERIAL_CONSOLE = "115200 ttyS0"
+SDIMG_KERNELIMAGE ?= "kernel7.img"
+KERNEL_DEFCONFIG ?= "bcm2709_defconfig"
+UBOOT_MACHINE ?= "rpi_2_config"
+SERIAL_CONSOLE ?= "115200 ttyS0"
VC4_CMA_SIZE ?= "cma-256"
--
2.12.2
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
