[yocto] Yocto Project Status WW25'19

2019-06-18 Thread sjolley.yp.pm 
Current Dev Position: YP 2.8 M2

Next Deadline: YP 2.8 Milestone 2 Cutoff July 14th, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Paul
*   SWAT team rotation: Paul -> Ross on June 21, 2019
*   SWAT team rotation: Ross -> Amanda on June 28, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*   Bug Triage meeting Thursday June 20th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday July 2nd at 8am PDT (
 https://zoom.us/j/990892712) 
*   Twitch - Next event is Tuesday 9th July at 8am PDT (
 https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*   2.8 M1 has been through QA and is waiting on responses from YP TSC
members on release readiness. It had more issues that would be ideal but
most were relatively minor and are being worked upon, several with known
causes now with fixes in master. As such its likely to be released.
*   Stephen is recovering from the accident and will now respond to
emails. We're pleased to have him back and wish him a continued speedy
recovery!
*   Mailing lists are proving to be a tricky subject. Some people are
having trouble with emails not making it to the lists which we recognise is
a serious issue. Equally, our groups.io plan isn't proving workable without
major user visible change due to the current domain structure we have. It is
being worked on as a priority to find a way forward.
*   We have a new "newcomer" bug category which are bugs suited to
someone new to the project. These can be seen here:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
*   We're grateful to Sandy, WindRiver and Michael for helping get
patchtest back into operation. Its tests are looking like they could do with
a little improvement but it is catching some issues and great to see
progress with it again.
*   During M2 Richard plans to look into our options for changing
runqueue to better support more advanced sstate usage. This may have an
impact on how quickly patches merge as the work there is involved and needs
focus.
*   We'd like to remind people that where test suites exist, we'd
appreciate it if people would run them before they send patches, e.g.
"oe-selftest -r devtool" or "oe-selftest -r wic".

 

Planned Releases for YP 2.8:

*   M1 is built and out of QA
*   M2 Cutoff 14th July
*   M2 Release 26th July
*   M3 Cutoff (Feature Freeze) 25th Aug
*   M3 Release 6th Sept
*   M4 Cutoff 30th Sept
*   2.8 (M4) Final Release 25th Oct

 

Planned upcoming dot releases:

*   YP 2.7.1 (Warrior) is planned for build imminently now that 2.8 M1
is done
*   YP 2.6.3 (Thud) is intended for build after 2.7.1 is complete and
before 2.8 M2

 

Tracking Metrics:

*   WDD 2479 (last week 2478) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1511 (last week 1507)
*   Patches in the Pending State: 641 (43%) [last week 641 (43%)]

 

Key Status Links for YP:

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

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

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

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

*Cell:(208) 244-4460

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

 

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

Re: [yocto] cortexa9t2hf instead of cortexa9hf

2019-06-18 Thread Zoran Stojsavljevic 
> bitbake is still just a parser of the metadata and executor of our
> tasks, it doesn't (and shouldn't) need to know anything about arm silicons.

You precisely formulated my latest thoughts in one sentence. :-)

Cheers,
Zoran
___

On Tue, Jun 18, 2019 at 9:03 PM Martin Jansa  wrote:
>
> On Tue, Jun 18, 2019 at 08:47:32PM +0200, Zoran Stojsavljevic wrote:
> > > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > > (not "armv7a").
> >
> > I think this is impossible for the current state of YOCTO affairs. I
> > do not think bitbake is able to determine type of arm silicon, since
>
> Have you read the commit which enabled thumb by default for MACHINEs
> which support it?
>
> bitbake is still just a parser of the metadata and executor of our
> tasks, it doesn't (and shouldn't) need to know anything about arm silicons.
>
> DEFAULTTUNE is still set in the MACHINE config (through one of the .inc
> files) and ARM_INSTRUCTION_SET is just another variable which says if
> it should include -mthumb or -marm by default in TUNE_CCARGS, read
> conf/machine/include/arm/feature-arm-thumb.inc
>
> Cheers,
>
> > it needs to implement the following instruction somewhere beneath (in
> > privileged mode):
> > asm volatile("mrc p15, 0, r0, c0, c0, 0" : "=r"(reg_value) );
> >
> > But according to the variable MACHINE (example: MACHINE ??=
> > "beaglebone"), it is able to determine that the platform is a type of
> > armv7a.
> >
> > My two cent worth thinking,
> > Zoran
> > ___
> >
> >
> > On Tue, Jun 18, 2019 at 7:13 PM Martin Jansa  wrote:
> > >
> > > On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> > > > Thanks for explaining this.
> > > > I take some time to read about thumb/thumb2. The feedback is mixed. It 
> > > > seems to generate more compact code, but some say it speeds up, others 
> > > > it slows down because of reduced function set - and it can cause 
> > > > strange effects.
> > > > And mixing this causes time to switch processor mode. So, as I am not 
> > > > an expert in this and can't decide what ist best on per function base 
> > > > and speed is of highest priority, I think I better should use not 
> > > > thumb(2).
> > > >
> > > > So, do I get it right that with this cortexa9t2hf I just have the 
> > > > option to compile it for thumb2? But without using a dedicated compiler 
> > > > option it generates same "standard" arm code and the difference is just 
> > > > to adapt all the Makefiles for this suffix.
> > > >
> > > > According to Martin I can get the previous setting by just set 
> > > > ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid 
> > > > that I lose other kinds of optimisation. (I am just a user not an 
> > > > expert in arm architecture).
> > >
> > > I didn't say anything about changing the DEFAULTTUNE.
> > >
> > > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > > (not "armv7a").
> > >
> > > > On the other hand for those like me it is better go the standard way. 
> > > > Once I am sure compiler results will not become worse (see above) I go 
> > > > for the pain and renaming my toolchain/makefiles/stuff.
> > >
> > > The results should be almost the same, maybe slightly better, depends on
> > > the actual code as Khem mentioned.
> > >
> > > But if this causes you a lot of pain "renaming my 
> > > toolchain/makefiles/stuff"
> > > then you should probably spend the time on your tooling instead of
> > > replacing one hardcoded value with another.
> > >
> > > Cheers,
> > >
> > > >
> > > > Thanks for you taking the time.
> > > > Arno
> > > >
> > > > > Hello Arno,
> > > > >
> > > > > Let me try to explain my point of view. Since here (my best guess) we
> > > > > have some asynchronous bitbake code which went South upon introducing
> > > > > T2 HW extension.
> > > > >
> > > > > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > > > > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > > > > media coprocessor) exists in both of them. In other words:
> > > > > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> > > > >
> > > > > Point [2]:
> > > > > > bitbake gives me in 2.5:
> > > > > > TUNE_FEATURES= "arm armv7a vfp thumb neon 
> > > > > > callconvention-hard cortexa9"
> > > > > > TARGET_FPU   = "hard"
> > > > > >
> > > > > > and in 2.7:
> > > > > > TUNE_FEATURES= "arm vfp cortexa9 neon thumb 
> > > > > > callconvention-hard"
> > > > > > TARGET_FPU   = "hard"
> > > > >
> > > > > These two lines are the same: you are able to use 32b arm mode, 16bit
> > > > > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > > > > extension as well. The Cortex in both cases is A9.
> > > > >
> > > > > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > > > > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > > > > and I have no idea if this is done intentionally or not.
> > > > >
> > > > > Because of

Re: [yocto] cortexa9t2hf instead of cortexa9hf

2019-06-18 Thread Martin Jansa 
On Tue, Jun 18, 2019 at 08:47:32PM +0200, Zoran Stojsavljevic wrote:
> > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > (not "armv7a").
> 
> I think this is impossible for the current state of YOCTO affairs. I
> do not think bitbake is able to determine type of arm silicon, since

Have you read the commit which enabled thumb by default for MACHINEs
which support it?

bitbake is still just a parser of the metadata and executor of our
tasks, it doesn't (and shouldn't) need to know anything about arm silicons.

DEFAULTTUNE is still set in the MACHINE config (through one of the .inc
files) and ARM_INSTRUCTION_SET is just another variable which says if
it should include -mthumb or -marm by default in TUNE_CCARGS, read
conf/machine/include/arm/feature-arm-thumb.inc

Cheers,

> it needs to implement the following instruction somewhere beneath (in
> privileged mode):
> asm volatile("mrc p15, 0, r0, c0, c0, 0" : "=r"(reg_value) );
> 
> But according to the variable MACHINE (example: MACHINE ??=
> "beaglebone"), it is able to determine that the platform is a type of
> armv7a.
> 
> My two cent worth thinking,
> Zoran
> ___
> 
> 
> On Tue, Jun 18, 2019 at 7:13 PM Martin Jansa  wrote:
> >
> > On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> > > Thanks for explaining this.
> > > I take some time to read about thumb/thumb2. The feedback is mixed. It 
> > > seems to generate more compact code, but some say it speeds up, others it 
> > > slows down because of reduced function set - and it can cause strange 
> > > effects.
> > > And mixing this causes time to switch processor mode. So, as I am not an 
> > > expert in this and can't decide what ist best on per function base and 
> > > speed is of highest priority, I think I better should use not thumb(2).
> > >
> > > So, do I get it right that with this cortexa9t2hf I just have the option 
> > > to compile it for thumb2? But without using a dedicated compiler option 
> > > it generates same "standard" arm code and the difference is just to adapt 
> > > all the Makefiles for this suffix.
> > >
> > > According to Martin I can get the previous setting by just set 
> > > ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that 
> > > I lose other kinds of optimisation. (I am just a user not an expert in 
> > > arm architecture).
> >
> > I didn't say anything about changing the DEFAULTTUNE.
> >
> > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > (not "armv7a").
> >
> > > On the other hand for those like me it is better go the standard way. 
> > > Once I am sure compiler results will not become worse (see above) I go 
> > > for the pain and renaming my toolchain/makefiles/stuff.
> >
> > The results should be almost the same, maybe slightly better, depends on
> > the actual code as Khem mentioned.
> >
> > But if this causes you a lot of pain "renaming my toolchain/makefiles/stuff"
> > then you should probably spend the time on your tooling instead of
> > replacing one hardcoded value with another.
> >
> > Cheers,
> >
> > >
> > > Thanks for you taking the time.
> > > Arno
> > >
> > > > Hello Arno,
> > > >
> > > > Let me try to explain my point of view. Since here (my best guess) we
> > > > have some asynchronous bitbake code which went South upon introducing
> > > > T2 HW extension.
> > > >
> > > > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > > > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > > > media coprocessor) exists in both of them. In other words:
> > > > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> > > >
> > > > Point [2]:
> > > > > bitbake gives me in 2.5:
> > > > > TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> > > > > cortexa9"
> > > > > TARGET_FPU   = "hard"
> > > > >
> > > > > and in 2.7:
> > > > > TUNE_FEATURES= "arm vfp cortexa9 neon thumb 
> > > > > callconvention-hard"
> > > > > TARGET_FPU   = "hard"
> > > >
> > > > These two lines are the same: you are able to use 32b arm mode, 16bit
> > > > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > > > extension as well. The Cortex in both cases is A9.
> > > >
> > > > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > > > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > > > and I have no idea if this is done intentionally or not.
> > > >
> > > > Because of that I copied Alex and Ross to CC: into email, so they
> > > > should unveil this mystery (I would prefer "armv7" to stay in bitbake
> > > > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
> > > >
> > > > Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> > > > should return "armv7" as TUNE FEATURE.
> > > >
> > > > Best Regards,
> > > > Zoran
> > > > ___
> > > >
> > > >
> > > > On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens  wrote:
> > > > >
> > > > > Hello Zoran,

Re: [yocto] cortexa9t2hf instead of cortexa9hf

2019-06-18 Thread Zoran Stojsavljevic 
> Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> (not "armv7a").

I think this is impossible for the current state of YOCTO affairs. I
do not think bitbake is able to determine type of arm silicon, since
it needs to implement the following instruction somewhere beneath (in
privileged mode):
asm volatile("mrc p15, 0, r0, c0, c0, 0" : "=r"(reg_value) );

But according to the variable MACHINE (example: MACHINE ??=
"beaglebone"), it is able to determine that the platform is a type of
armv7a.

My two cent worth thinking,
Zoran
___


On Tue, Jun 18, 2019 at 7:13 PM Martin Jansa  wrote:
>
> On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> > Thanks for explaining this.
> > I take some time to read about thumb/thumb2. The feedback is mixed. It 
> > seems to generate more compact code, but some say it speeds up, others it 
> > slows down because of reduced function set - and it can cause strange 
> > effects.
> > And mixing this causes time to switch processor mode. So, as I am not an 
> > expert in this and can't decide what ist best on per function base and 
> > speed is of highest priority, I think I better should use not thumb(2).
> >
> > So, do I get it right that with this cortexa9t2hf I just have the option to 
> > compile it for thumb2? But without using a dedicated compiler option it 
> > generates same "standard" arm code and the difference is just to adapt all 
> > the Makefiles for this suffix.
> >
> > According to Martin I can get the previous setting by just set 
> > ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I 
> > lose other kinds of optimisation. (I am just a user not an expert in arm 
> > architecture).
>
> I didn't say anything about changing the DEFAULTTUNE.
>
> Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> (not "armv7a").
>
> > On the other hand for those like me it is better go the standard way. Once 
> > I am sure compiler results will not become worse (see above) I go for the 
> > pain and renaming my toolchain/makefiles/stuff.
>
> The results should be almost the same, maybe slightly better, depends on
> the actual code as Khem mentioned.
>
> But if this causes you a lot of pain "renaming my toolchain/makefiles/stuff"
> then you should probably spend the time on your tooling instead of
> replacing one hardcoded value with another.
>
> Cheers,
>
> >
> > Thanks for you taking the time.
> > Arno
> >
> > > Hello Arno,
> > >
> > > Let me try to explain my point of view. Since here (my best guess) we
> > > have some asynchronous bitbake code which went South upon introducing
> > > T2 HW extension.
> > >
> > > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > > media coprocessor) exists in both of them. In other words:
> > > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> > >
> > > Point [2]:
> > > > bitbake gives me in 2.5:
> > > > TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> > > > cortexa9"
> > > > TARGET_FPU   = "hard"
> > > >
> > > > and in 2.7:
> > > > TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
> > > > TARGET_FPU   = "hard"
> > >
> > > These two lines are the same: you are able to use 32b arm mode, 16bit
> > > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > > extension as well. The Cortex in both cases is A9.
> > >
> > > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > > and I have no idea if this is done intentionally or not.
> > >
> > > Because of that I copied Alex and Ross to CC: into email, so they
> > > should unveil this mystery (I would prefer "armv7" to stay in bitbake
> > > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
> > >
> > > Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> > > should return "armv7" as TUNE FEATURE.
> > >
> > > Best Regards,
> > > Zoran
> > > ___
> > >
> > >
> > > On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens  wrote:
> > > >
> > > > Hello Zoran,
> > > > thanks. As far as I understand is thumb2 another mode of coding, that 
> > > > might create more compact code.
> > > > But I want to keep all compatible to my previous tool-chain and 
> > > > settings.
> > > > The only file where I can found this "cortexa9t2hf" is
> > > > ./meta/conf/machine/include/tune-cortexa9.inc
> > > > but I can't see how I can control Yocto to generate "cortexa9hf-neon" 
> > > > as before.
> > > > Or have I been wrong the time before?
> > > >
> > > > bitbake gives me in 2.5:
> > > >
> > > > TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> > > > cortexa9"
> > > > TARGET_FPU   = "hard"
> > > >
> > > > and in 2.7:
> > > > TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
> > > > TARGET_FPU

Re: [yocto] cortexa9t2hf instead of cortexa9hf

2019-06-18 Thread Martin Jansa 
On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> Thanks for explaining this.
> I take some time to read about thumb/thumb2. The feedback is mixed. It seems 
> to generate more compact code, but some say it speeds up, others it slows 
> down because of reduced function set - and it can cause strange effects.
> And mixing this causes time to switch processor mode. So, as I am not an 
> expert in this and can't decide what ist best on per function base and speed 
> is of highest priority, I think I better should use not thumb(2).
> 
> So, do I get it right that with this cortexa9t2hf I just have the option to 
> compile it for thumb2? But without using a dedicated compiler option it 
> generates same "standard" arm code and the difference is just to adapt all 
> the Makefiles for this suffix.
> 
> According to Martin I can get the previous setting by just set 
> ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I 
> lose other kinds of optimisation. (I am just a user not an expert in arm 
> architecture).

I didn't say anything about changing the DEFAULTTUNE.

Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
(not "armv7a").

> On the other hand for those like me it is better go the standard way. Once I 
> am sure compiler results will not become worse (see above) I go for the pain 
> and renaming my toolchain/makefiles/stuff.

The results should be almost the same, maybe slightly better, depends on
the actual code as Khem mentioned.

But if this causes you a lot of pain "renaming my toolchain/makefiles/stuff"
then you should probably spend the time on your tooling instead of
replacing one hardcoded value with another.

Cheers,

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

Re: [yocto] devshell env in warrior

2019-06-18 Thread matthew stanger 
Hey Khem,

Check that Makefiles are not overriding CC/CXX/LD etc. some old crufty
> Makefiles I have seen doing that, you might see something like

In the recipe it's caused by 'inherit module', which is needed because part
of the recipe is building modules. I would understand this would unset
CFLAGS and such but am not sure why the devshell should be different that
the environment at the first line of do_compile?

On Tue, Jun 18, 2019 at 10:08 AM Khem Raj  wrote:

> On Mon, Jun 17, 2019 at 4:55 PM matthew stanger 
> wrote:
> >
> > I'm trying to figure out why when running devshell in Warrior CC/CFLAGS
> are not the same as do_compile for a recipe. For example.
> > devshell printenv yields:
> > CC=aarch64-poky-linux-gcc   -fuse-ld=bfd
> -fmacro-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot=
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot-native=
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work-shared/tmobile-7271-kaon-mini/kernel-source=/usr/src/kernel
> >
> > do_compile() {
> > /usr/bin/printenv | sort > debug.log
> > }
> > yields...
> > CC=aarch64-poky-linux-gcc  -mcpu=cortex-a53+crc+crypto
> -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
> -Werror=format-security
> --sysroot=/home/matt/rdk_warrior/build/tmp/work/tmobile_7271_kaon_mini-poky-linux/ursr/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot
> >
> > This causes some very different behavior out of the makefile. The recipe
> I"m working with has no do_configure, and only calls a makefile through
> do_compile. No appends/prepends or custom functions in the recipe. This
> recipe is for a lovely Broadcom driver/userspace glob and I'm trying to
> troubleshoot it with x64 but not being able to get a correct working env
> makes life hard. Any idea's of where I might be going wrong?
> >
>
> Check that Makefiles are not overriding CC/CXX/LD etc. some old crufty
> Makefiles I have seen doing that, you might see something like
>
> CC = ${CROSS_COMPILE}gcc etc. which you should convert to weak defines
> e.g. CC ?= 
>
> > Cheers
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cortexa9t2hf instead of cortexa9hf

2019-06-18 Thread Khem Raj 
On Mon, Jun 17, 2019 at 10:48 AM Arno Steffens  wrote:
>
> Thanks for explaining this.
> I take some time to read about thumb/thumb2. The feedback is mixed. It seems 
> to generate more compact code, but some say it speeds up, others it slows 
> down because of reduced function set - and it can cause strange effects.
> And mixing this causes time to switch processor mode. So, as I am not an 
> expert in this and can't decide what ist best on per function base and speed 
> is of highest priority, I think I better should use not thumb(2).
>
> So, do I get it right that with this cortexa9t2hf I just have the option to 
> compile it for thumb2? But without using a dedicated compiler option it 
> generates same "standard" arm code and the difference is just to adapt all 
> the Makefiles for this suffix.
>
> According to Martin I can get the previous setting by just set 
> ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I 
> lose other kinds of optimisation. (I am just a user not an expert in arm 
> architecture).
> On the other hand for those like me it is better go the standard way. Once I 
> am sure compiler results will not become worse (see above) I go for the pain 
> and renaming my toolchain/makefiles/stuff.
>
> Thanks for you taking the time.

While the gains/losses from using thumb2 ISA depends upon type of
loads you have and nature of code, in general this is most commonly
used ISA in linux distros, so most of the apps would have
been used compiled with this and probably optimized for as well. I
would advise that you do some bench-marking for your loads and then
decide if using thumb2 ISA is right choice for you or not.

if you want to drop thumb2 you can set appropriate default tune in
your machine config and that will do it

DEFAULTTUNE = "cortexa9hf-neon"


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

Re: [yocto] devshell env in warrior

2019-06-18 Thread Khem Raj 
On Mon, Jun 17, 2019 at 4:55 PM matthew stanger  wrote:
>
> I'm trying to figure out why when running devshell in Warrior CC/CFLAGS are 
> not the same as do_compile for a recipe. For example.
> devshell printenv yields:
> CC=aarch64-poky-linux-gcc   -fuse-ld=bfd 
> -fmacro-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
>  
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
>  
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot=
>  
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot-native=
>   
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work-shared/tmobile-7271-kaon-mini/kernel-source=/usr/src/kernel
>
> do_compile() {
> /usr/bin/printenv | sort > debug.log
> }
> yields...
> CC=aarch64-poky-linux-gcc  -mcpu=cortex-a53+crc+crypto 
> -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
> -Werror=format-security 
> --sysroot=/home/matt/rdk_warrior/build/tmp/work/tmobile_7271_kaon_mini-poky-linux/ursr/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot
>
> This causes some very different behavior out of the makefile. The recipe I"m 
> working with has no do_configure, and only calls a makefile through 
> do_compile. No appends/prepends or custom functions in the recipe. This 
> recipe is for a lovely Broadcom driver/userspace glob and I'm trying to 
> troubleshoot it with x64 but not being able to get a correct working env 
> makes life hard. Any idea's of where I might be going wrong?
>

Check that Makefiles are not overriding CC/CXX/LD etc. some old crufty
Makefiles I have seen doing that, you might see something like

CC = ${CROSS_COMPILE}gcc etc. which you should convert to weak defines
e.g. CC ?= 

> Cheers
> --
> ___
> 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] [PATCH 3/3] recipes-bsp/u-boot: update to the latest version

2019-06-18 Thread ayaka 


On 09/05/2019 01:30, Trevor Woerner wrote:

a previous patch of yours did a:
    require recipes-bsp/u-boot/u-boot-common.inc
which defines this SRCREV

my subtle point being: I don't get the impression you're testing your 
patches, or at least not testing them correctly.


I did the test before but I forget to remove the variables in local.conf

Anyway I will start a clean build this time.

Now I met a problem with new gcc 9 on the latest oe, I will fix them 
then flush new patches later.




the fact you're CCing Romain suggests your either using a very old 
branch of https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/ or 
that you're submitting patches to me for 
https://github.com/rockchip-linux/meta-rockchip ?
Unfortunately for me, when 
https://github.com/rockchip-linux/meta-rockchip did a clone of 
https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/, they left 
my and Romain's names as maintainers in the README (along with 
instructions for github)


On Wed, May 8, 2019 at 12:19 PM ayaka > wrote:



On 5/6/19 9:31 PM, Trevor Woerner wrote:
> On Sat 2019-05-04 @ 06:43:34 PM, ayaka wrote:
>> On 5/4/19 11:06 AM, Trevor Woerner wrote:
>>> On Wed 2019-04-24 @ 10:59:18 PM, Randy 'ayaka' Li wrote:
 From: Randy Li mailto:ay...@soulik.info>>

 Signed-off-by: Randy Li mailto:ay...@soulik.info>>
 ---
    recipes-bsp/u-boot/u-boot-rockchip_git.bb
 | 18 ++
    1 file changed, 18 insertions(+)
    create mode 100644
recipes-bsp/u-boot/u-boot-rockchip_git.bb


 diff --git a/recipes-bsp/u-boot/u-boot-rockchip_git.bb

b/recipes-bsp/u-boot/u-boot-rockchip_git.bb

 new file mode 100644
 index 000..aa4b84d
 --- /dev/null
 +++ b/recipes-bsp/u-boot/u-boot-rockchip_git.bb

 @@ -0,0 +1,18 @@
 +# Copyright (C) 2019 SUMOMO Computer Assocation
 +# Released under the MIT license (see COPYING.MIT for the terms)
 +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 +
 +include u-boot-rockchip.inc
 +
 +DESCRIPTION = "Rockchip U-Boot"
 +
 +LIC_FILES_CHKSUM =
"file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
 +
 +SRC_URI = " \
 +  git://github.com/rockchip-linux/u-boot.git;branch=release
; \
 +  file://binutils-2.28-ld-fix.patch \
 +  file://gcc7_fixup.patch \
 +  "
 +
 +S = "${WORKDIR}/git"
 +PV = "v2019.01"
>>> This doesn't even get past the fetching stage:
>> I am sorry, I forget that ssh git protocol only work for those
users who
>> uploaded their key to the github, I would change it back to https.
>>>     WARNING: u-boot-rockchip-1_v2019.01-r0 do_fetch: Failed to
fetch URL
git://github.com/rockchip-linux/u-boot.git;branch=release
;,
attempting MIRRORS if available
>>>     ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Fetcher
failure: Unable to find revision
3c99166441bf3ea325af2da83cfe65430b49c066 in branch release even
from upstream
>>>     ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Fetcher
failure for URL:
'git://github.com/rockchip-linux/u-boot.git;branch=release;
'.
Unable to fetch URL from any source.
>>>     ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch:
>>>     ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Function
failed: base_do_fetch
>>>     ERROR: Task

(/opt/oe/configs/z/build-master/meta-rockchip/layers/meta-rockchip/recipes-bsp/u-boot/u-boot-rockchip_git.bb:do_fetch)
failed with exit code '1'
> The problem is that it's trying to fetch commit 3c9916 which
doesn't exist on
> github.com/rockchip-linux/u-boot.git
. That revision is on
upstream U-Boot.
How comes? I didn't write any commit id there, it is based on the
branch
at all.


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

Re: [yocto] [meta-mono][PATCH] mono-5.xx: fix an issue with too long paths in doltlibtool

2019-06-18 Thread Alexander Kanavin 
Ping #2!

Alex

On Mon, 27 May 2019 at 12:22, Alex J Lennon 
wrote:

>
> Thanks for the reminder Alex
> On 27/05/2019 11:16, Alexander Kanavin wrote:
>
> Ping?
>
> Alex
>
> On Mon, 13 May 2019 at 18:25, Alexander Kanavin  
>  wrote:
>
> When build directory is deeply nested, the shebang limit of 127
> characters is hit, which leads to doltlibtool failing to execute.
>
> Signed-off-by: Alexander Kanavin  
> 
> ---
>  recipes-mono/mono/mono-5.xx.inc | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/recipes-mono/mono/mono-5.xx.inc b/recipes-mono/mono/mono-5.xx.inc
> index c36374c..dec2475 100644
> --- a/recipes-mono/mono/mono-5.xx.inc
> +++ b/recipes-mono/mono/mono-5.xx.inc
> @@ -102,3 +102,7 @@ RDEPENDS_${PN} =+ "bash"
>
>  # Workaround for observed race in `make install`
>  PARALLEL_MAKEINST=""
> +
> +# Otherwise the full path to bash is written to the first line of 
> doltlibtool script
> +# which causes build failures with deeply nested build directories
> +CACHED_CONFIGUREVARS += "ac_cv_path_DOLT_BASH='/usr/bin/env bash'"
> --
> 2.17.1
>
>
> --
>
> [image: Dynamic Devices Ltd] 
>
> Alex J Lennon MA (Cantab) MIET MIOD / Director
> DoES Liverpool 1st Floor The Tapestry 68 – 76 Kempston Street Liverpool L3
> 8HL, United Kingdom
>
> mobile: +44 (0)7478 346120
>
> [image: Linkedin]  [image: Skype]
> 
>
> This e-mail message may contain confidential or legally privileged
> information and is intended only for the use of the intended recipient(s).
> Any unauthorized disclosure, dissemination, distribution, copying or the
> taking of any action in reliance on the information herein is prohibited.
> E-mails are not secure and cannot be guaranteed to be error free as they
> can be intercepted, amended, or contain viruses. Anyone who communicates
> with us by e-mail is deemed to have accepted these risks. Company Name is
> not responsible for errors or omissions in this message and denies any
> responsibility for any damage arising from the use of e-mail. Any opinion
> and other statement contained in this message and any attachment are solely
> those of the author and do not necessarily represent those of the company.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto