Re: [linux-yocto] [V2] : [yocto-4.18]: intel-socfpga: arch: arm64: dts: add altr, sysmgr-syscon property for Ethernet driver

[Bruce Ashfield]

On 12/2/18 9:46 PM, meng...@windriver.com wrote:

From: Limeng 

Hi Bruce,

Could you please help to merge below one patch into linux-yocto, kernel 4.18, 
branch is v4.18/standard/intel-socfpga
  
0001-arch-arm64-dts-add-altr-sysmgr-syscon-property-for-E.patch


  socfpga_stratix10.dtsi |5 +
  1 file changed, 5 insertions(+)

v2:
There is context conflict in V1 patch. fix the conflict in v2 as below
change
reg = <0xffd12000 0x1000>;
into
reg = <0xffd12000 0x228>;


Thanks. This applied to the tree and is now merged.

Bruce



thanks,
Limeng




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

[yocto] Wanted: Volunteers and demos for OpenEmbedded FOSDEM stand

[Paul Barker]

Hi all,

We've got an OpenEmbedded stand again at FOSDEM this year! The event will be 
held on 2nd & 3rd Feb 2019 at the usual location of ULB Campus du Solbosch in 
Brussels.

I'll be present most of each day to run the stand but we need some additional 
volunteers to help out. Ideally we need 3-4 volunteers for each day so that we 
can load balance a bit and have chance for breaks and coffee runs. If you're 
interested in volunteering could you reply to this email for now, we'll 
probably get a list up on the OE wiki nearer the event.

We also need some demos to show off. I don't really have much myself this year 
sadly. Demos should show off the benefits of OpenEmbedded (such as building the 
same image for multiple machines). Ideally we would have a couple of hardware 
devices to show off along with a demo of Toaster, the layer index and other 
visual parts of the tooling on a laptop. Demos may include commercial hardware 
but please remember that we have limited stand space and want to show off the 
OpenEmbedded project and related open source technologies - a sales demo of a 
proprietary product isn't appropriate. If you've got some form of demo to bring 
along then please let me know by email reply.

Cheers,

-- 
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.4.4 RC1

[Jain, Sangeeta]

>-Original Message-
>From: richard.pur...@linuxfoundation.org 
>Sent: Tuesday, 4 December, 2018 11:57 PM
>To: Jain, Sangeeta ; Jolley, Stephen K
>; Eggleton, Paul ;
>Graydon, Tracy ; Erway, Tracey M
>; yocto@yoctoproject.org
>Cc: Sangal, Apoorv ; Kirkiris, Nectar
>
>Subject: Re: QA cycle report for 2.4.4 RC1
>
>On Wed, 2018-11-28 at 07:07 +, Jain, Sangeeta wrote:
>> The test cases run for 2.4.4 RC1 are same as run for 2.4 release.
>
>Ok, but I'm not sure they're correct. Are the test cases we're talking about 
>also
>run for the 2.5 release? I'll explain more below.
>
For 2.5 dot release, we'll run the test cases which we run for 2.5 master 
release.
>> > Thanks for running the QA for this. I do have some
>> > questions/observations.
>> >
>> > Firstly, this report is a little misleading as there are only two
>> > bugs mentioned but 8 failures. The full report shows other bugs
>> > which were for example reopened or already open.
>> In report, only new bugs are mentioned. All the bugs which are
>> reopened/already existing are not listed in report mail but can be
>> seen in full report.
>> However, if its creating any confusion/inconvenience, going forward I
>> can mention all the failing bugs in report.
>
>I think it would be useful to have a complete summary of the bugs found, in
>particular the reopened ones as otherwise it gives a misleading view of the
>release status.
>
Sure.
>> > Taking the above bugs first, I believe they're both manual versions
>> > of tests which are already automated. I believe the automated tests
>> > have passed and there appears to be some kind of problem with the
>> > manual execution such as the wrong process being documented. I'm not
>> > quite sure why these are being run manually? Was the list of manual
>> > tests we received from Intel incorrect?
>> The list manual test we run for 2.4.4 is same as we run for 2.4
>> release. This test case is automated later than 2.4 release and is
>> still manual as per 2.4 test plan in Testopia. It's an irony that in
>> Yocto Project we don't have any tracking of a test case converting
>> into automated in which release, and no system that we can update test
>> cases in Dot releases. I am trying to streamline the tracking of test
>> case evolution, so as to avoid such scenarios in future.
>
>Taking:
>
>https://bugzilla.yoctoproject.org/show_bug.cgi?id=13033
>
>as an example, I believe the automated version is:
>
>http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/cases/prse
>rvice.py?h=rocko#n52
>
>which was present in the first 2.4 release.
>
>Its also present in pyro:
>
>http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/prservice.
>py?h=pyro#n54
>
>and morty:
>http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/prservice.
>py?h=morty#n51
>krogoth:
>http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/prservice.
>py?h=krogoth#n52
>jethro:
>http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/prservice.
>py?h=jethro#n51
>
>so has been there since at least 2.0.
>
>So either I'm wrong about this being an automated version of the test, or we
>really shouldn't be running this test manually but it isn't a problem of 
>changing
>test criteria between point releases.
>
>I'd also note that nobody from QA has replied to my question in the bugzilla.
>
For
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13033
 test case has been run manually for 2.4 release as per Testopia data. 
To answer your question in Bugzilla, we are working on it and will be updated 
asap.

>I'm now worrying about what test cases get run for 2.5 and how these differ 
>from
>what we run against 2.6 and master and what QA summarised in the recent
>documentation of test cases exercise. Perhaps we need to document the manual
>test cases in the 2.5 release too to ensure we have the right set?

 I am working on identifying the test cases which were automated in 2.6 and 
master. And the new test case document summarised by QA team should be aligned 
to latest state of test case, automated or manual.
I am also working on documentation of manual test cases for 2.5 and finding 
which ones are already automated in 2.6, so that we can execute the latest 
state in next release.

>
>Cheers,
>
>Richard


Thanks & Regards,
Sangeeta Jain

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

[yocto] Automate hardware test using oeqa runtime library

[Hussin, Mohamad Noor Alim]

Hi Richard,

I wrote some scripts to test USB mount/unmount, read & write on real hardware. 
I use OEQA runtime library to wrote the test cases. However, these tests only 
work on hardware and not for qemu.
Since these tests run on hardware, I need to add a flag to avoid the tests 
execute on qemu. I am not sure if these tests case should pass on qemu too.

Links below refer to patches of BSP test cases to test USB. There are 2 patches 
files called "bsp-test-helper" and usb.py. bsp-test-helper is a wrapper script 
to execute USB test cases on usb.py file.

USB test cases, usb.py
https://lists.yoctoproject.org/pipermail/yocto/2018-August/042261.html
wrapper script, bsp-test-helper
https://lists.yoctoproject.org/pipermail/yocto/2018-August/042262.html


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

Re: [yocto] x86_64 kernel with i586 userland plus SDK?

[richard . purdie]

On Mon, 2018-12-03 at 09:52 +0100, Richard Weinberger wrote:
> On Wed, Nov 28, 2018 at 9:26 PM Richard Weinberger
>  wrote:
> > Richard,
> > 
> > On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
> >  wrote:
> > > > But it seems that building and SDK is currently
> > > > broken/disabled:
> > > > 
> > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e153efde9754a650e555f46cba09680baabd7d7e
> > > 
> > > I see a bug was opened for this but its not valid and this
> > > shouldn't be
> > > an issue. Keep in mind that an SDK contains all multilibs so
> > > "bitbake
> > > X-image -c populate_sdk" would be equivalent to "bitbake libXX-X-
> > > image
> > > -c populate_sdk" and be the same thing. One didn't work so we
> > > remove
> > > that.
> > 
> > My idea was having a 32bit only SDK. In my case I really don't need
> > 64bit userspace.
> > On the other hand, having both 32bit and 64bit libs in the SDK is
> > not
> > a big deal right now.
> > 
> > So I did "bitbake my-image -c populate_sdk" but the resulting SDK
> > seems to contain no
> > 32bits libraries.
> > TOOLCHAIN_TARGET_TASK contains "openssl", so I expected libssl.so
> > present.
> > I did a search for libssl.so and found these files in the SDK
> > install directory:
> > 
> > ./tmp/sysroots/mymachine/usr/lib64/libssl.so.1.0.2
> > ./tmp/sysroots/mymachine/usr/lib/libssl.so.1.0.2
> > 
> > Both files are 64bit shared libraries :-(
> > 
> > What do I miss?
> 
> *kind ping*

This is the bug that Qi opened. The code doesn't do what you want right
now and I'm not sure how easy/hard it would be to make it do the above
:(

Sorry, I hadn't realised we had this problem until you dived into it
although it is kind of obvious in hindsight...

Cheers,

Richard


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

Re: [yocto] Using ICECC to build Thud issue

[Joshua Watt]

On Tue, 2018-12-04 at 10:28 -0600, John Unland wrote:
> Hello everyone, 
> 
> I've been playing around with the icecc.bbclass and a small 2 node
> icecream cluster. At the moment I'm able to compile core-image-
> minimal using Rocko however when building on Thud I get a error (See
> Github gist for error and local.conf config):
> 
> https://gist.github.com/junland/d932bd63ca2c871b99e64eda543ca2fe

Fixed on master:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1da297d35411e923ca3b6accdd37074f5182f019https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5dd8df08c51bc4cc1ef0d5be7656c9bfcf938cca
They should probably be backported to thud.
> My build OS is Ubuntu 18.04 (Workstation) and CentOS 7 (Second build
> server), also I've gotten the same error on a Debian 9 and Oracle
> Linux VM so I highly doubt it's something that has todo with the OS.
> I'd also like to add what the workflow I'm using:
> 
> (As regular user)
> 1. $> git clone -b thud git://git.yoctoproject.org/poky.git
> 
> 2. $> source oe-init-build-env
> 
> 3. (Edit local.conf and place "PARALLEL_MAKE = "-j 10"" and "INHERIT
> += "icecc"" at the end of the config file)
> 
> 4. $> source oe-init-build-env
> 
> 5. $> bitbake core-image-minimal
> 
> Is there something I'm missing here? I've read the section of the
> manual that explains on how to use icecream but it hasn't really
> solved my problem. Any help would be great!
> 
> Thanks!
> 
-- 
Joshua Watt 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Using ICECC to build Thud issue

[John Unland]

Hello everyone,

I've been playing around with the icecc.bbclass and a small 2 node icecream
cluster. At the moment I'm able to compile core-image-minimal using Rocko
however when building on Thud I get a error (See Github gist for error and
local.conf config):

https://gist.github.com/junland/d932bd63ca2c871b99e64eda543ca2fe

My build OS is Ubuntu 18.04 (Workstation) and CentOS 7 (Second build
server), also I've gotten the same error on a Debian 9 and Oracle Linux VM
so I highly doubt it's something that has todo with the OS. I'd also like
to add what the workflow I'm using:

(As regular user)
1. $> git clone -b thud git://git.yoctoproject.org/poky.git

2. $> source oe-init-build-env

3. (Edit local.conf and place "PARALLEL_MAKE = "-j 10"" and "INHERIT +=
"icecc"" at the end of the config file)

4. $> source oe-init-build-env

5. $> bitbake core-image-minimal

Is there something I'm missing here? I've read the section of the manual
that explains on how to use icecream but it hasn't really solved my
problem. Any help would be great!

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

Re: [yocto] QA cycle report for 2.4.4 RC1

[richard . purdie]

On Wed, 2018-11-28 at 07:07 +, Jain, Sangeeta wrote:
> The test cases run for 2.4.4 RC1 are same as run for 2.4 release. 

Ok, but I'm not sure they're correct. Are the test cases we're talking
about also run for the 2.5 release? I'll explain more below.

> > Thanks for running the QA for this. I do have some
> > questions/observations.
> > 
> > Firstly, this report is a little misleading as there are only two
> > bugs mentioned but 8
> > failures. The full report shows other bugs which were for example
> > reopened or
> > already open.
> In report, only new bugs are mentioned. All the bugs which are
> reopened/already existing are not listed in report mail but can be
> seen in full report.
> However, if its creating any confusion/inconvenience, going forward I
> can mention all the failing bugs in report.

I think it would be useful to have a complete summary of the bugs
found, in particular the reopened ones as otherwise it gives a
misleading view of the release status.

> > Taking the above bugs first, I believe they're both manual versions
> > of tests which
> > are already automated. I believe the automated tests have passed
> > and there
> > appears to be some kind of problem with the manual execution such
> > as the
> > wrong process being documented. I'm not quite sure why these are
> > being run
> > manually? Was the list of manual tests we received from Intel
> > incorrect?
> The list manual test we run for 2.4.4 is same as we run for 2.4
> release. This test case is automated later than 2.4 release and is
> still manual as per 2.4 test plan in Testopia. It's an irony that in
> Yocto Project we don't have any tracking of a test case converting
> into automated in which release, and no system that we can update
> test cases in Dot releases. I am trying to streamline the tracking of
> test case evolution, so as to avoid such scenarios in future.

Taking:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=13033

as an example, I believe the automated version is:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/cases/prservice.py?h=rocko#n52

which was present in the first 2.4 release.

Its also present in pyro:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/prservice.py?h=pyro#n54

and morty:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/prservice.py?h=morty#n51
krogoth:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/prservice.py?h=krogoth#n52
jethro:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/prservice.py?h=jethro#n51

so has been there since at least 2.0.

So either I'm wrong about this being an automated version of the test,
or we really shouldn't be running this test manually but it isn't a
problem of changing test criteria between point releases.

I'd also note that nobody from QA has replied to my question in the
bugzilla.

I'm now worrying about what test cases get run for 2.5 and how these
differ from what we run against 2.6 and master and what QA summarised
in the recent documentation of test cases exercise. Perhaps we need to
document the manual test cases in the 2.5 release too to ensure we have
the right set?

Cheers,

Richard

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

[yocto] Yocto Project Status WW48’18

[Jolley, Stephen K]

Current Dev Position: YP 2.7 M1.

Next Deadline: YP 2.7 M1 Cutoff is Dec. 10, 2018


SWAT Team Rotation:

· SWAT lead is currently: Amanda

· SWAT team rotation: Amanda -> Chen on Dec. 7, 2018

· SWAT team rotation: Chen -> Arminon Dec. 14, 2018

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


Key Status/Updates:

· YP 2.4.4 was released

· Some progress has been made on fixing the oe-selftest stability 
issues reported last week. As an idea of scale there have been over 20 
different issues found so far but others continue to appear.

· Patches are merging to master but at a reduced rate due to the 
selftest stability problem.

· Please be aware 2.7 M1 is due to be built on Monday.


Planned Releases for YP 2.7:

· YP 2.7 M1 Cutoff is Dec. 10, 2018

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

· YP 2.7 M2 Cutoff is Jan. 21, 2019

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

· YP 2.7 M3 Cutoff is Feb. 25, 2019

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

· YP 2.7 M4 Cutoff is Apr. 1, 2019

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


Planned upcoming dot releases:

· YP 2.5.2 (Sumo) will be built soon.

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

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

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


Tracking Metrics:

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

· Poky Patch Metrics

oTotal patches found: 1675 (last week 1682)

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


Key Status Links for YP:

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

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

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


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


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

Thanks,

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

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

Re: [yocto] [EXTERNAL] Re: Missing dependencies in recipe-sysroot

[Burton, Ross]

No, you just need to write your makefile correctly.  libgpiod has a
pkg-config file, so instead of hard-coding paths like /usr/lib
(because you don't know that's where it is installed) just use
pkg-config to get the flag:

gcc $(pkg-config --cflags --libs libgpiod) ...

Ross
On Tue, 4 Dec 2018 at 15:14, Georgi Georgiev
 wrote:
>
> OK but. I can use SDKTARGETSYSROOT in my makefile but then it will fail in 
> yocto...So I can't have one makefile for yocto and command line build...I 
> found one tread for similar issue and I will take a look in 
> poky/meta/conf/bitbake.conf tomorrow.
>
> Georgi
>
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Tuesday, December 04, 2018 4:13 PM
> To: Georgi Georgiev 
> Cc: Yocto-mailing-list 
> Subject: Re: [EXTERNAL] Re: [yocto] Missing dependencies in recipe-sysroot
>
> On Tue, 4 Dec 2018 at 14:02, Georgi Georgiev  
> wrote:
> > LIB := -L/usr/lib
>
> ^ don't do that.  That's not where the libraries are.
>
> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [EXTERNAL] Re: Missing dependencies in recipe-sysroot

[Georgi Georgiev]

OK but. I can use SDKTARGETSYSROOT in my makefile but then it will fail in 
yocto...So I can't have one makefile for yocto and command line build...I found 
one tread for similar issue and I will take a look in 
poky/meta/conf/bitbake.conf tomorrow. 

Georgi

-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com] 
Sent: Tuesday, December 04, 2018 4:13 PM
To: Georgi Georgiev 
Cc: Yocto-mailing-list 
Subject: Re: [EXTERNAL] Re: [yocto] Missing dependencies in recipe-sysroot

On Tue, 4 Dec 2018 at 14:02, Georgi Georgiev  
wrote:
> LIB := -L/usr/lib

^ don't do that.  That's not where the libraries are.

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

Re: [yocto] [EXTERNAL] Re: Missing dependencies in recipe-sysroot

[Burton, Ross]

On Tue, 4 Dec 2018 at 14:02, Georgi Georgiev
 wrote:
> LIB := -L/usr/lib

^ don't do that.  That's not where the libraries are.

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

Re: [yocto] [EXTERNAL] Re: Missing dependencies in recipe-sysroot

[Georgi Georgiev]

Thank you Ross,
Compilation issues are gone...Only one DEPENDS appeared to be enough :-). Thank 
you again
But can give me a hand to the following because now I have QA issues during my 
"corrupted" makefile. Is there any way to pass this --sysroot=//recipe-sysroot before -L/usr/lib. Eg somehow the whole path to be like 
-L//recipe-sysroot/usr/lib in my makefile. gcc actually follows 
--sysroot  and /usr/include is to target sysroot...but one annoying warning 
appear and now this is my last issue.
cc1: warning: include location "/usr/include" is unsafe for cross-compilation 
[-Wpoison-system-directories]
QA stage (do_package_qa) does not pass. 
Here is my "corrupted" makefile:

# we will use env from poky CC := arm-linux-gnueabihf-gcc
CFLAGS := -g -Wall -fpic
RM = rm -f $(DEPDIR)/*.d $(OBJDIR)/*.o *~ $(OUTPUT)
DEPDIR := dep
OBJDIR := obj
OUTPUT := libanybus-m40.so.0.0.1

LOCAL_SRC_DIRS := .
LOCAL_SRC_DIRS += abcc_adapt
LOCAL_SRC_DIRS += abcc_drv/src
LOCAL_SRC_DIRS += abcc_drv/src/par
LOCAL_SRC_DIRS += abcc_drv/src/par30
LOCAL_SRC_DIRS += abcc_drv/src/serial
LOCAL_SRC_DIRS += abcc_drv/src/spi

LOCAL_INC_DIRS := .
LOCAL_INC_DIRS += abcc_abp
LOCAL_INC_DIRS += abcc_adapt
LOCAL_INC_DIRS += abcc_drv/inc
LOCAL_INC_DIRS += abcc_drv/src
LOCAL_INC_DIRS += abcc_drv/src/par
LOCAL_INC_DIRS += abcc_drv/src/par30
LOCAL_INC_DIRS += abcc_drv/src/serial
LOCAL_INC_DIRS += abcc_drv/src/spi
LOCAL_INC_DIRS += /usr/include

SRC := $(foreach sdir,$(LOCAL_SRC_DIRS),$(wildcard $(sdir)/*.c))
INC := $(foreach idir,$(LOCAL_INC_DIRS),-I$(idir))
LIB := -L/usr/lib
LDFLAGS := -lgpiod -shared -fPIC -Wl,-soname,libanybus-m40.so.0
OBJ := $(addprefix $(OBJDIR)/,$(notdir $(SRC:.c=.o)))
DEP := $(addprefix $(DEPDIR)/,$(notdir $(OBJ:.o=.d)))

VPATH = $(LOCAL_SRC_DIRS)

ifneq "$(findstring clean,$(MAKECMDGOALS))" "clean"
-include $(DEP)
endif

.PHONY: all clean dirtree
.DEFAULT_GOAL := all

all: $(OUTPUT)

$(OUTPUT): $(OBJ)
$(CC) $(LDFLAGS) -o $@ $(LIB) $^

$(DEPDIR)/%.d: %.c
$(CC) $(LIB) -MM -MF $@ -MP -MT "$(OBJDIR)/$*.o $@" $(CFLAGS) $(INC) $< 


$(OBJDIR)/%.o: %.c
$(CC) $(LIB) $(CFLAGS) $(INC) -c -o $@ $< 

$(OBJ) $(DEP): | dirtree

dirtree:
mkdir -p $(DEPDIR) $(OBJDIR)

clean:
$(RM)

Cordially,
Georgi
-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com] 
Sent: Tuesday, December 04, 2018 12:16 PM
To: Georgi Georgiev 
Cc: Yocto-mailing-list 
Subject: [EXTERNAL] Re: [yocto] Missing dependencies in recipe-sysroot

We've already gone through this on SO but I'll copy/paste here.

On Tue, 4 Dec 2018 at 08:30, Georgi Georgiev  
wrote:
> #The only dependency
>
> RDEPENDS_${PN} = "libgpiod"
>
> RDEPENDS_${PN}-dev = "libgpiod"
>
> RDEPENDS_${PN}-dbg = "libgpiod"

DEPENDS = "libgpiod".  RDEPENDS will build libgpiod at some point, but it won't 
be in the sysroot for compilation.  Before recipe-specific-sysroots this would 
mean it *might* be present, now it reliably won't.

> Then I noticed that the command line is:
>
> arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon -mfloat-abi=hard 
> -mcpu=cortex-a9 --sysroot=//recipe-sysroot -L/usr/lib -g -Wall 
> -fpic .

The problem is the -L/usr/lib, which presumably should be where libgpiod is.  
The makefile is broken, or possibly some tooling that the makefile is calling.  
As you haven't shared the makefile we can't help further.

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

Re: [yocto] [yocto-rocko] : fsl-community-bsp X11 build touch screen calibration issue on iMX6UL

[Alankar Dhobale]

Hi Max,

 

Yes you are right, I used the same bbappend and this resolved the issue, 
perfect solution…

 

I have been struggling with this since couple of days! 

 

Many thanks for your inputs and resolution.

 

I have tested the build for imx6ulevk as well as to our own machine, both 
worked well. Calibration passes correctly and also writes it to 
/etc/pointercal.xinput file and works perfect

 

Thanks once again…

 

Regards

Alankar

 

 

-Original Message-
From: Max Krummenacher [mailto:max.oss...@gmail.com] 
Sent: 04/12/2018 1:08 AM
To: Alankar Dhobale; yocto@yoctoproject.org
Subject: Re: [yocto] [yocto-rocko] : fsl-community-bsp X11 build touch screen 
calibration issue on iMX6UL

 

Hi

 

> Machine: imx6ulevek

> 

> Image: core-image-x11

> 

> The issue I have observed on the device is, Xorg is unable to 

> calibrate the touchscreen, I don't know what has changed but it is 

> unable to calibrate, below is the log I get on prompt

> 

...

> ERROR: XorgPrint Calibrator does not support the supplied 

> --output-type

> 

> Error: unable to apply or save configuration valuesUsing calibration 

> data stored in /etc/pointercal.xinput

> 

 

Does not installing xf86-input-libinput help? xinput-calibrator cannot cope 
with that input backend.

 

I used the following bbappend to achieve this:

 

 

 
http://git.toradex.com/cgit/meta-toradex-demos.git/commit/?h=rocko-next=664a1926af81e49396bfe2681

18969ec2b8718cb

 

Regards

Max

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

Re: [yocto] am335x evmsk screen init:id"00" respawning too fast disabled for 5 minutes yocto sumo

[Stanisavljevic]

Hi Holzmayr and Heiko,

My problem was solved with your advices.
I edited the serial console variable on the machine conf file of my custom 
machine.
It's work fine.
Thank's

n.stanisavljevic

-Message d'origine-
De : Heiko Schocher  
Envoyé : lundi 3 décembre 2018 05:42
À : n.stanisavlje...@polycaptil.fr
Cc : Josef Holzmayr ; yocto@yoctoproject.org
Objet : Re: [yocto] am335x evmsk screen init:id"00" respawning too fast 
disabled for 5 minutes yocto sumo

Hi n.stanisavljevic,

Am 28.11.2018 um 20:55 schrieb Josef Holzmayr:
> Howdy!
> 
> On Wed, Nov 28, 2018 at 03:50:02PM +, n.stanisavlje...@polycaptil.fr 
> wrote:
>> Hello everybody
>>
>> here is an introduction of my situation :
>>
>> I build a custom board from schematic of sitara AM335x-evmsk starter kit.
>> I succeed to make a custom OS with yocto (krogoth version) and to boot this 
>> OS (embedded Linux) on my custom board.
>>
>> This custom board contain a touchscreen (same touchscreen like in the 
>> AM335x-evmsk starter kit).
>>
>> All worked fine on this board while I used krogoth version on yocto.
>>
>> my problem :
>>
>> Few time ago, I decided to migrate to sumo version of yocto.
>> I build with success the OS (embedded Linux) with yocto sumo version for my 
>> custom board, but when I try to boot this OS, it's stop/lock and print the 
>> following message :
>>
>> "INIT:Id'00' respawning too fast : disabled for 5 minutes" (I put a 
>> screenshot of this message ridden on putty).
>> Every 5 minutes I got this message and I can't acces to the user session on 
>> putty and on the touchscreen, all board is locked.
> 
> This is probably because you are basing off something that sets 
> SERIAL_CONSOLES for the yocto-kernel, like
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-b
> sp/conf/machine/beaglebone-yocto.conf?h=master#n23
> 
> If you are using a custom tree which does not use the special driver 
> for the uart, then you should be fine by setting SERIAL_CONSOLES ?= 
> "115200;ttyS0"
> in your MACHINE config

Yep, see also my patch:

https://www.mail-archive.com/yocto@yoctoproject.org/msg42383.html

may it help you ...

bye,
Heiko

> 
>>
>> I don't understand why this problem appear when I build a OS with the sumo 
>> version on Yocto.
>> I have not this problem when I build a OS with the krogoth version on yocto.
>>
>> Somebody can help me to solve this problem ?
>> what can I do ?
>>
> 
> Greetz
> 

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

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

Re: [yocto] Missing dependencies in recipe-sysroot

[Burton, Ross]

We've already gone through this on SO but I'll copy/paste here.

On Tue, 4 Dec 2018 at 08:30, Georgi Georgiev
 wrote:
> #The only dependency
>
> RDEPENDS_${PN} = "libgpiod"
>
> RDEPENDS_${PN}-dev = "libgpiod"
>
> RDEPENDS_${PN}-dbg = "libgpiod"

DEPENDS = "libgpiod".  RDEPENDS will build libgpiod at some point, but
it won't be in the sysroot for compilation.  Before
recipe-specific-sysroots this would mean it *might* be present, now it
reliably won't.

> Then I noticed that the command line is:
>
> arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon -mfloat-abi=hard 
> -mcpu=cortex-a9 --sysroot=//recipe-sysroot -L/usr/lib -g -Wall 
> -fpic .

The problem is the -L/usr/lib, which presumably should be where
libgpiod is.  The makefile is broken, or possibly some tooling that
the makefile is calling.  As you haven't shared the makefile we can't
help further.

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

[yocto] Missing dependencies in recipe-sysroot

[Georgi Georgiev]

Hello,
As probably all yocto people know the sysrootfs policy changed in yocto rocko 
2.4+. So I have the following issue:
I try to make a recipe for a shared library with makefile. The recipe is below 
(I don't claim it is complete. I simply cannot pass building stage):
#==
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = 
"file://${THISDIR}/files/LICENSE;md5=5959e502cb44bafc53b2cc9400e3d4cd"
PR = "r0"

# First try from my local repo and then we will use the big one
SRC_URI = "git:///home/w23698/projects/anybus/Generic;branch=anybus-lib-0.0.1"
SRCREV = "2fe4ce39a651d71f3f8de1c751dff2581de2c526"

S = "${WORKDIR}/git"

PACKAGES = "${PN} ${PN}-dev ${PN}-dbg"
#The only dependency
RDEPENDS_${PN} = "libgpiod"
RDEPENDS_${PN}-dev = "libgpiod"
RDEPENDS_${PN}-dbg = "libgpiod"

do_compile() {
oe_runmake
}

do_install() {
install -d ${D}${libdir}
install -m 0644 ${PN}-m40 ${D}${libdir}
}

What was my surprise when it failed with:
ww.c:6:10: fatal error: gpiod.h: No such file or directory
 |  #include "gpiod.h"
|   ^
| compilation terminated.
Then I noticed that the command line is:
arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon -mfloat-abi=hard 
-mcpu=cortex-a9 --sysroot=//recipe-sysroot -L/usr/lib -g -Wall -fpic 
.
I looked in recipe-sysroot/usr/lib/ and found a minimal set of libraries and 
libgpiod was not there. Neither the header was there in include...

Any suggestions?

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