[yocto] Qt/QML support on i.MX6 ultralite

[Alankar Dhobale]

I am working on getting Qt/QML on i.mx6 Ultra lite. As there is no hardware
GPU on i.MX6 ultralite, I am trying to get qt 2D renderer on it so that
Qt/QML can use software libraries.

 

To do this I have done following

 

1.   Got fsl-community-bsp from morty branch, as morty supports QT
5.7.1, and to use Qt 2D renderer we need Qt 5.7 and above

2.   Then i prepared a build fslc-framebuffer with adding Qt components
support in my recipes, also build meta-toolchain-qt5, installed and
configured SDK to my Qt 5.8

3.   Prepared small Qt-quick application and compiled with same SDK and
trying to run it on i.MX6UL evk. I got an error as EGL_EXT_device_base
missing. 

4.   I found that software libraries are missing for 2D renderer. So I
followed following link and built those libraries and also added includes to
SDK and re-compiled the application

a.
http://doc.qt.io/QtQuick2DRenderer/qtquick2drenderer-installation-guide.html

5.   Now when I try to run the application EGL missing error has gone,
but got an error that Qt plug-in xcb is missing. I am not sure about this
error as I built the image with DISTRO as fslc-framebuffer. Also I am
running the application with -platform eglfs

6.   To confirm my build machine and recipes setup I also built image
for mx6 solox frame buffer, which runs fine and does not show error for xcb

 

Can somebody please help me on this? 

 

Also as Yocto morty is released in Nov 2016, when it will be released for
fsl-community-bsp. Any updates are coming for i.mx6ultralite for software
graphics libraries?

 

Do we expect to get Qt quick 2D renderer support for mx6 ultralite in morty
release for fsl-community-bsp?

 

Kind Regards,

Alankar 

 

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

Re: [yocto] Build only one specific C source from git clone with many C files

[Paul Eggleton]

On Monday, 6 February 2017 11:45:19 AM NZDT Burton, Ross wrote:
> On 6 February 2017 at 11:27, Prasant J  wrote:
> > Is it possible to modify SRC_URI to take only one source file from a
> > git clone and build it?
> 
> No, you can't do that with git.
> 
> One way would be to use the http fetcher to get the file directly from the
> web interface to the kernel.

Well, technically if it's just a directory you want you can use subpath= - 
that doesn't actually prevent fetching the entire repo though, it just changes 
what gets unpacked to the work directory for the recipe.

(Beware - earlier versions of the build system had a nasty bug with subpath=, 
if you're using 1.7.1, 1.8.0 or older I'd suggest not including a leading or 
trailing slash in the subpath value - you don't need them anyway).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 2/3] rmc: Enable reading the contents of an existing fingerprint file

[Jianxun Zhang]

> On Feb 6, 2017, at 2:28 PM, Todor Minchev  
> wrote:
> 
> On Mon, 2017-02-06 at 12:01 -0800, Jianxun Zhang wrote:
>> Tudor,
>> Please refer to my 3 inline comments.
>> 
>>> On Feb 2, 2017, at 2:37 PM, Todor Minchev  
>>> wrote:
>>> 
>>> The contents of an existing fingerprint file can be read and output on
>>> the command line with the following options:
>>> 
>>> ./rmc -F -i input_fingerprint_file
>> Suggest we have a new top option for dumping in parallel with -F to keep 
>> usages clear and simple for users.
> 
> We can use -E to extract both the database and the fingerprint?
> 
> rmc -E -d rmc.db
> rmc -E -f rmc.fingerprint
good idea.
> 
>>> 
>>> Signed-off-by: Todor Minchev 
>>> ---
>>> src/rmc.c | 121 
>>> +++---
>>> 1 file changed, 76 insertions(+), 45 deletions(-)
>>> 
>>> diff --git a/src/rmc.c b/src/rmc.c
>>> index 062dd36..a051ccf 100644
>>> --- a/src/rmc.c
>>> +++ b/src/rmc.c
>>> @@ -14,33 +14,35 @@
>>> #include 
>>> 
>>> #define USAGE "RMC (Runtime Machine configuration) Tool\n" \
>>> -"NOTE: Most of usages require root permission (sudo)\n" \
>>> -"rmc -F [-o output_fingerprint]\n" \
>>> +"NOTE: Most of usages require root permission (sudo)\n\n" \
>>> +"rmc -F [-o output_fingerprint] | -i input_fingerprint\n" \
>>>"rmc -R [-f ] -b  [-o 
>>> output_record]\n" \
>>>"rmc -D  [-o output_database]\n" \
>>> -   "rmc -B  -d  -o output_file\n" \
>>> -   "\n" \
>>> -   "-F: generate board rmc fingerprint of board\n" \
>>> -   "-R: generate board rmc record of board with its fingerprint and file 
>>> blobs.\n" \
>>> -"-f: fingerprint file to be packed in record, rmc will create a 
>>> fingerprint for board and use it internally to\n" \
>>> -"generate record if -f is missed.\n" \
>>> -"-b: files to be packed in record\n" \
>>> -   "-G: generate rmc database file with records specified in record file 
>>> list\n" \
>>> -   "-B: get a flie blob with specified name associated to the board rmc is 
>>> running on\n" \
>>> -   "-d: database file to be queried\n" \
>>> -   "-o: path and name of output file of a specific command\n" \
>>> -   "\n" \
>>> -"Examples (Steps in an order to add board support into rmc):\n" \
>>> -"generate board fingerprint:\n" \
>>> -"rmc -F\n\n" \
>>> -"generate a rmc record for the board with two file blobs, output 
>>> to:\n" \
>>> -"a specified file:\n" \
>>> -"rmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
>>> -"generate a rmc database file with records from 3 different boards:\n" 
>>> \
>>> -"rmc -D board1_record board2_record board3_record\n\n" \
>>> -"query a file blob named audio.conf associated to the board rmc is 
>>> running on in database my_rmc.db and output\n" \
>>> -"to /tmp/new_audio.conf:\n" \
>>> -"rmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
>>> +"rmc -B  -d  -o output_file\n\n" 
>>> \
>>> +  "-F: manage fingerprint file\n" \
>>> +"\t-o output_file: store RMC fingerprint of current board in 
>>> output_file\n" \
>>> +"\t-i input_file: print RMC fingerprint stored in input_file\n\n" \
>>> +  "-R: generate board rmc record of board with its fingerprint and file 
>>> blobs.\n" \
>>> +"\t-f intput_file : input fingerprint file to be packed in record\n\n" 
>>> \
>>> +"\tNOTE: RMC will create a fingerprint for the board and use it to\n" \
>>> +"\tgenerate record if an input fingerprint file is not provided.\n\n" \
>>> +"\t-b: files to be packed in record\n\n" \
>>> +  "-G: generate rmc database file with records specified in record file 
>>> list\n\n" \
>>> +  "-B: get a file blob with specified name associated to the board rmc 
>>> is\n" \
>>> +  "running on\n" \
>>> +"\t-d: database file to be queried\n" \
>>> +"\t-o: path and name of output file of a specific command\n\n" \
>>> +"Examples (Steps in an order to add board support into rmc):\n\n" \
>>> +"1. Generate board fingerprint:\n" \
>>> +"\t./rmc -F\n\n” \
>> Why do we force the rmc in current dir here? rmc can be installed to a 
>> system path like other programs.
> 
> Yes, this can be anywhere.
> 
>> 
>>> +"2. Generate a rmc record for the board with two file blobs and save 
>>> it\n" \
>>> +"to a specified file:\n" \
>>> +"\t./rmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
>>> +"3. Generate a rmc database file with records from 3 different 
>>> boards:\n" \
>>> +"\t./rmc -D board1_record board2_record board3_record\n\n" \
>>> +"4. Query a file blob named audio.conf associated to the board rmc 
>>> is\n" \
>>> +"running on in database my_rmc.db and output to 
>>> /tmp/new_audio.conf:\n" \
>>> +"\t./rmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
>>> 
>>> 
>>> #define RMC_OPT_CAP_F   (1 << 0)
>>> @@ -51,6 +53,7 @@
>>> #define RMC_OPT_O   (1 << 5)
>>> #define RMC_OPT_B   (1 << 6)
>>> #define RMC_OPT_D   (1 << 7)
>>> +#define

Re: [yocto] [PATCH 3/3] rmc: add database extraction functionality

[Todor Minchev]

On Mon, 2017-02-06 at 13:09 -0800, Jianxun Zhang wrote:
> Todor,
> Nice change overall. I haven’t run any test and just share multiple (11) 
> inline comments for this patch.

A patchset incorporating these comments is in progress.

> This should be the last one in the series. Please let me know if I missed any 
> other RMC patches for review.
> 
> I plan to run rmc internal test once we have an updated patch set. We could 
> need to add a new test case for the dumping feature in the future.
> 
> You can refer to the README in rmc project for the pipeline of merging.
> 
> Thanks!
> 
> > On Feb 2, 2017, at 2:37 PM, Todor Minchev  
> > wrote:
> > 
> > The contents of an existing database file can be extracted in the
> > current working directory with the -E option. The top level of the
> > directory tree is rmc_db_dump and all files corresponding to
> > a given record will be saved in a separate sub-directory. The sub-directory
> > name of each record is the signature corresponding to the fingerprint for
> > that record.
> > 
> > Example:
> > ./src/rmc -E -d rmc.db
> > 
> > Successfully extracted rmc.db
> > 
> > Signed-off-by: Todor Minchev 
> > ---
> > inc/rmc_api.h |  9 ++
> > src/lib/api.c | 85 
> > +--
> > src/lib/common/rmcl.c |  3 +-
> > src/rmc.c | 44 +++---
> > 4 files changed, 126 insertions(+), 15 deletions(-)
> > 
> > diff --git a/inc/rmc_api.h b/inc/rmc_api.h
> > index a484389..ce26220 100644
> > --- a/inc/rmc_api.h
> > +++ b/inc/rmc_api.h
> > @@ -74,6 +74,15 @@ extern int rmc_query_file_by_fp(rmc_fingerprint_t *fp, 
> > char *db_pathname, char *
> >  */
> > extern int rmc_gimme_file(char* db_pathname, char *file_name, rmc_file_t 
> > *file);
> > 
> > +
> > +/* extract the contents of a database file and store the files 
> > corresponding to
> > + * each record in a separate directory. The name of each directory is the 
> > signature
> > + * of the fingerpring for that record
> > + * (in) db_pathname: The path and file name of a RMC database file 
> > generated by RMC tool
> > + * return: 0 on success, non-zero on failure.
> > + */
> > +int dump_db(char *db_pathname) ;
> > +
> Please move this into section 1.3, somewhere after next line. It doesn’t 
> belong to section 1.2 “double-action API”

Will do.

> 
> > /* 1.3 - Helper APIs */
> > 
> > /* Free allocated data referred in a fingerprint
> > diff --git a/src/lib/api.c b/src/lib/api.c
> > index 0adb390..aca8d99 100644
> > --- a/src/lib/api.c
> > +++ b/src/lib/api.c
> > @@ -3,6 +3,7 @@
> >  * RMC API implementation for Linux user space
> >  */
> > 
> > +#define _GNU_SOURCE
> > #include 
> > #include 
> > #include 
> > @@ -14,8 +15,11 @@
> > #include 
> > #include 
> > 
> > -#define EFI_SYSTAB_PATH "/sys/firmware/efi/systab"
> > -#define SYSTAB_LEN 4096 /* assume 4kb is enough...*/
> > +#define EFI_SYSTAB_PATH  "/sys/firmware/efi/systab"
> > +#define SYSTAB_LEN   4096 /* assume 4kb is enough...*/
> > +#define DB_DUMP_DIR  "./rmc_db_dump"  /* directory to store db data 
> > dump */
> > +
> > +extern const rmc_uint8_t rmc_db_signature[RMC_DB_SIG_LEN];
> We could have a new small helper API like is_rmcdb(db_blob) in RMCL to hold 
> checker logic at line 357 in this file, so that we can get rid of this line 
> and make the checker reusable. (So far I feel the checker should work in both 
> EFI and Linux contexts.)
> 
> We could even update checker API without bothering its callers in the future. 
> Let me know if it makes sense...

Makes sense

> > 
> > int read_file(const char *pathname, char **data, rmc_size_t* len) {
> > int fd = -1;
> > @@ -325,3 +329,80 @@ int rmc_gimme_file(char* db_pathname, char *file_name, 
> > rmc_file_t *file) {
> > 
> > return ret;
> > }
> > +
> > +/*
> > + * Dump contents of database file
> > + * (in) rmc_db - input database file to extract
> rmc_db VS db_pathname. I think we can remove the comment here, it is already 
> in the header file.
> > + */

OK

> > +int dump_db(char *db_pathname) {
> > +rmc_meta_header_t meta_header;
> > +rmc_db_header_t *db_header = NULL;
> > +rmc_record_header_t record_header;
> > +rmc_uint64_t record_idx = 0;   /* offset of each reacord in db*/
> > +rmc_uint64_t meta_idx = 0; /* offset of each meta in a record */
> > +rmc_uint64_t file_idx = 0; /* offset of file in a meta */
> > +rmc_file_t file;
> > +char *out_dir = NULL, *out_name = NULL;
> > +rmc_size_t db_len = 0;
> > +rmc_uint8_t *rmc_db = NULL;
> > +struct stat s = {0};
> > +
> > +if (read_file(db_pathname, (char **)&rmc_db, &db_len)) {
> > +fprintf(stderr, "Failed to read database file\n\n");
> > +return 1;
> > +}
> > +
> > +db_header = (rmc_db_header_t *)rmc_db;
> > +
> > +/* sanity check of db */
> > +if (strncmp((const char *)db_header->signature,
> > +(const char *)rmc_db_signature, RMC_DB_SIG_LEN))
> >

Re: [yocto] [PATCH 2/3] rmc: Enable reading the contents of an existing fingerprint file

[Todor Minchev]

On Mon, 2017-02-06 at 12:01 -0800, Jianxun Zhang wrote:
> Tudor,
> Please refer to my 3 inline comments.
> 
> > On Feb 2, 2017, at 2:37 PM, Todor Minchev  
> > wrote:
> > 
> > The contents of an existing fingerprint file can be read and output on
> > the command line with the following options:
> > 
> > ./rmc -F -i input_fingerprint_file
> Suggest we have a new top option for dumping in parallel with -F to keep 
> usages clear and simple for users.

We can use -E to extract both the database and the fingerprint?

rmc -E -d rmc.db
rmc -E -f rmc.fingerprint

> > 
> > Signed-off-by: Todor Minchev 
> > ---
> > src/rmc.c | 121 
> > +++---
> > 1 file changed, 76 insertions(+), 45 deletions(-)
> > 
> > diff --git a/src/rmc.c b/src/rmc.c
> > index 062dd36..a051ccf 100644
> > --- a/src/rmc.c
> > +++ b/src/rmc.c
> > @@ -14,33 +14,35 @@
> > #include 
> > 
> > #define USAGE "RMC (Runtime Machine configuration) Tool\n" \
> > -"NOTE: Most of usages require root permission (sudo)\n" \
> > -"rmc -F [-o output_fingerprint]\n" \
> > +"NOTE: Most of usages require root permission (sudo)\n\n" \
> > +"rmc -F [-o output_fingerprint] | -i input_fingerprint\n" \
> > "rmc -R [-f ] -b  [-o 
> > output_record]\n" \
> > "rmc -D  [-o output_database]\n" \
> > -   "rmc -B  -d  -o output_file\n" \
> > -   "\n" \
> > -   "-F: generate board rmc fingerprint of board\n" \
> > -   "-R: generate board rmc record of board with its fingerprint and file 
> > blobs.\n" \
> > -"-f: fingerprint file to be packed in record, rmc will create a 
> > fingerprint for board and use it internally to\n" \
> > -"generate record if -f is missed.\n" \
> > -"-b: files to be packed in record\n" \
> > -   "-G: generate rmc database file with records specified in record file 
> > list\n" \
> > -   "-B: get a flie blob with specified name associated to the board rmc is 
> > running on\n" \
> > -   "-d: database file to be queried\n" \
> > -   "-o: path and name of output file of a specific command\n" \
> > -   "\n" \
> > -"Examples (Steps in an order to add board support into rmc):\n" \
> > -"generate board fingerprint:\n" \
> > -"rmc -F\n\n" \
> > -"generate a rmc record for the board with two file blobs, output 
> > to:\n" \
> > -"a specified file:\n" \
> > -"rmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
> > -"generate a rmc database file with records from 3 different boards:\n" 
> > \
> > -"rmc -D board1_record board2_record board3_record\n\n" \
> > -"query a file blob named audio.conf associated to the board rmc is 
> > running on in database my_rmc.db and output\n" \
> > -"to /tmp/new_audio.conf:\n" \
> > -"rmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
> > +"rmc -B  -d  -o output_file\n\n" 
> > \
> > +  "-F: manage fingerprint file\n" \
> > +"\t-o output_file: store RMC fingerprint of current board in 
> > output_file\n" \
> > +"\t-i input_file: print RMC fingerprint stored in input_file\n\n" \
> > +  "-R: generate board rmc record of board with its fingerprint and file 
> > blobs.\n" \
> > +"\t-f intput_file : input fingerprint file to be packed in record\n\n" 
> > \
> > +"\tNOTE: RMC will create a fingerprint for the board and use it to\n" \
> > +"\tgenerate record if an input fingerprint file is not provided.\n\n" \
> > +"\t-b: files to be packed in record\n\n" \
> > +  "-G: generate rmc database file with records specified in record file 
> > list\n\n" \
> > +  "-B: get a file blob with specified name associated to the board rmc 
> > is\n" \
> > +  "running on\n" \
> > +"\t-d: database file to be queried\n" \
> > +"\t-o: path and name of output file of a specific command\n\n" \
> > +"Examples (Steps in an order to add board support into rmc):\n\n" \
> > +"1. Generate board fingerprint:\n" \
> > +"\t./rmc -F\n\n” \
> Why do we force the rmc in current dir here? rmc can be installed to a system 
> path like other programs.

Yes, this can be anywhere.

> 
> > +"2. Generate a rmc record for the board with two file blobs and save 
> > it\n" \
> > +"to a specified file:\n" \
> > +"\t./rmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
> > +"3. Generate a rmc database file with records from 3 different 
> > boards:\n" \
> > +"\t./rmc -D board1_record board2_record board3_record\n\n" \
> > +"4. Query a file blob named audio.conf associated to the board rmc 
> > is\n" \
> > +"running on in database my_rmc.db and output to 
> > /tmp/new_audio.conf:\n" \
> > +"\t./rmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
> > 
> > 
> > #define RMC_OPT_CAP_F   (1 << 0)
> > @@ -51,6 +53,7 @@
> > #define RMC_OPT_O   (1 << 5)
> > #define RMC_OPT_B   (1 << 6)
> > #define RMC_OPT_D   (1 << 7)
> > +#define RMC_OPT_I   (1 << 8)
> > 
> > static void usage () {
> > fprintf(stdout, USAGE);
> > @@

Re: [yocto] [PATCH 1/3] Makefile: add verbosity and debug options to Makefile

[Todor Minchev]

On Mon, 2017-02-06 at 11:06 -0800, Jianxun Zhang wrote:
> Todor,
> Please refer to my 2 inline comments.
> 
> > On Feb 2, 2017, at 2:37 PM, Todor Minchev  
> > wrote:
> > 
> > By default Makefile verbosity is disabled (V=0). Verbosity can be enabled by
> > setting the V environment variable to any value not equal to 0 (e.g V=1)
> > 
> > Example:
> > make clean V=1; make V=1
> > 
> > A debug version of the rmc binary can be built by using the debug
> > Makefile target. This will include debug symbols and will disable compiler
> > optimizations when compiling rmc.
> > 
> > Example:
> > 
> > make debug
> > 
> > Signed-off-by: Todor Minchev 
> > ---
> > Makefile | 31 +--
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> > 
> > diff --git a/Makefile b/Makefile
> > index 9ade775..d85d8e9 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1,5 +1,12 @@
> > # Copyright (C) 2016 Jianxun Zhang 
> > 
> > +V ?= 0
> > +ifeq ($(V),0)
> > +  VERBOSITY = @
> > +else
> > +  VERBOSITY =
> > +endif
> > +
> I am thinking maybe we should remove ‘@‘ in rules and use -s option of make 
> (in recipe) when we want to mute the output. This should reach the same 
> effect without bothering new variables.
> 
> We still enable/disable output as a whole anyway.
> 
> Let me know if this proposal works for you.

Sounds good. Removing the @ will make it possible to toggle the
verbosity with 'make -s' without introducing any extra variables. 

> 
> > TOPDIR = $(shell if [ -z "$$PWD" ]; then pwd; else echo "$$PWD"; fi)
> > 
> > RMC_TOOL_SRC := $(wildcard src/*.c)
> > @@ -20,28 +27,32 @@ RMC_INSTALL_HEADER_PATH := 
> > $(RMC_INSTALL_PREFIX)/include/rmc/
> > 
> > ALL_OBJS := $(RMC_TOOL_OBJ) $(RMC_LIB_OBJ)
> > 
> > +
> > RMC_CFLAGS := -Wall -I$(TOPDIR)/inc
> > 
> > all: rmc
> > +debug: RMC_CFLAGS += -DDEBUG -g -O0
> > +debug: rmc
> I am not sure if this is necessary because we already have CFLAGS. I think 
> you can reach the same effect without adding a new debug target:
> make CFLAGS='-DDEBUG -g -O0’
> 

Yup, the above will have the same effect as 'make debug'.
I thought that 'make debug' might be a convenient way to build a debug
binary? Do you think it makes sense to keep this extra target for
convenience since it doesn't affect the other usages of make?

> also refer to commit e8b48e6 in rmc project.
> 
> > 
> > $(ALL_OBJS): %.o: %.c
> > -   @$(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> > +   $(VERBOSITY)$(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> > 
> > librmc: $(RMC_LIB_OBJ)
> > -   @$(AR) rcs src/lib/$@.a $^
> > +   $(VERBOSITY)$(AR) rcs src/lib/$@.a $^
> > 
> > rmc: $(RMC_TOOL_OBJ) librmc
> > -   @$(CC) $(CFLAGS) $(RMC_CFLAGS) -Lsrc/lib/ -lrmc $(RMC_TOOL_OBJ) 
> > src/lib/librmc.a -o src/$@
> > +   $(VERBOSITY)$(CC) $(CFLAGS) $(RMC_CFLAGS) -Lsrc/lib/ -lrmc 
> > $(RMC_TOOL_OBJ) \
> > +  src/lib/librmc.a -o src/$@
> > 
> > clean:
> > -   @rm -f $(ALL_OBJS) src/rmc src/lib/librmc.a
> > +   $(VERBOSITY)rm -f $(ALL_OBJS) src/rmc src/lib/librmc.a
> > 
> > .PHONY: clean rmc librmc
> > 
> > install:
> > -   @mkdir -p $(RMC_INSTALL_BIN_PATH)
> > -   @install -m 755 src/rmc $(RMC_INSTALL_BIN_PATH)
> > -   @mkdir -p $(RMC_INSTALL_LIB_PATH)
> > -   @install -m 644 src/lib/librmc.a $(RMC_INSTALL_LIB_PATH)
> > -   @mkdir -p $(RMC_INSTALL_HEADER_PATH)
> > -   @install -m 644 $(RMC_INSTALL_HEADERS) $(RMC_INSTALL_HEADER_PATH)
> > +   $(VERBOSITY)mkdir -p $(RMC_INSTALL_BIN_PATH)
> > +   $(VERBOSITY)install -m 755 src/rmc $(RMC_INSTALL_BIN_PATH)
> > +   $(VERBOSITY)mkdir -p $(RMC_INSTALL_LIB_PATH)
> > +   $(VERBOSITY)install -m 644 src/lib/librmc.a $(RMC_INSTALL_LIB_PATH)
> > +   $(VERBOSITY)mkdir -p $(RMC_INSTALL_HEADER_PATH)
> > +   $(VERBOSITY)install -m 644 $(RMC_INSTALL_HEADERS) 
> > $(RMC_INSTALL_HEADER_PATH)
> > -- 
> > 2.11.0
> > 
> 


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

[yocto] Reminder: Yocto Project Technical Team Meeting - Tuesday, Feb 7, 2017 8:00 AM US Pacific Time

[Jolley, Stephen K]

Tuesday, Feb. 7, 2017 8:00 AM US Pacific Time



Agenda:



* Opens collection - 5 min (Stephen)

* Yocto Project status - 5 min (Stephen/team)

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

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

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

* Opens - 10 min

* Team Sharing - 10 min



We encourage people attending the meeting to logon the Yocto Project IRC 
chancel during the meeting (optional):



Yocto IRC: http://webchat.freenode.net/?channels=#yocto

IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html



Conference Details:

Company:   WIND RIVER SYS

Ready-Access Number: 8007302996/9139049836

Access Code: 2705751


For International numbers see: 
https://www.yoctoproject.org/tools-resources/community/monthly-technical-call


Thanks,

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

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

Re: [yocto] [PATCH 3/3] rmc: add database extraction functionality

[Jianxun Zhang]

Todor,
Nice change overall. I haven’t run any test and just share multiple (11) inline 
comments for this patch.

This should be the last one in the series. Please let me know if I missed any 
other RMC patches for review.

I plan to run rmc internal test once we have an updated patch set. We could 
need to add a new test case for the dumping feature in the future.

You can refer to the README in rmc project for the pipeline of merging.

Thanks!

> On Feb 2, 2017, at 2:37 PM, Todor Minchev  
> wrote:
> 
> The contents of an existing database file can be extracted in the
> current working directory with the -E option. The top level of the
> directory tree is rmc_db_dump and all files corresponding to
> a given record will be saved in a separate sub-directory. The sub-directory
> name of each record is the signature corresponding to the fingerprint for
> that record.
> 
> Example:
> ./src/rmc -E -d rmc.db
> 
> Successfully extracted rmc.db
> 
> Signed-off-by: Todor Minchev 
> ---
> inc/rmc_api.h |  9 ++
> src/lib/api.c | 85 +--
> src/lib/common/rmcl.c |  3 +-
> src/rmc.c | 44 +++---
> 4 files changed, 126 insertions(+), 15 deletions(-)
> 
> diff --git a/inc/rmc_api.h b/inc/rmc_api.h
> index a484389..ce26220 100644
> --- a/inc/rmc_api.h
> +++ b/inc/rmc_api.h
> @@ -74,6 +74,15 @@ extern int rmc_query_file_by_fp(rmc_fingerprint_t *fp, 
> char *db_pathname, char *
>  */
> extern int rmc_gimme_file(char* db_pathname, char *file_name, rmc_file_t 
> *file);
> 
> +
> +/* extract the contents of a database file and store the files corresponding 
> to
> + * each record in a separate directory. The name of each directory is the 
> signature
> + * of the fingerpring for that record
> + * (in) db_pathname: The path and file name of a RMC database file generated 
> by RMC tool
> + * return: 0 on success, non-zero on failure.
> + */
> +int dump_db(char *db_pathname) ;
> +
Please move this into section 1.3, somewhere after next line. It doesn’t belong 
to section 1.2 “double-action API”

> /* 1.3 - Helper APIs */
> 
> /* Free allocated data referred in a fingerprint
> diff --git a/src/lib/api.c b/src/lib/api.c
> index 0adb390..aca8d99 100644
> --- a/src/lib/api.c
> +++ b/src/lib/api.c
> @@ -3,6 +3,7 @@
>  * RMC API implementation for Linux user space
>  */
> 
> +#define _GNU_SOURCE
> #include 
> #include 
> #include 
> @@ -14,8 +15,11 @@
> #include 
> #include 
> 
> -#define EFI_SYSTAB_PATH "/sys/firmware/efi/systab"
> -#define SYSTAB_LEN 4096 /* assume 4kb is enough...*/
> +#define EFI_SYSTAB_PATH  "/sys/firmware/efi/systab"
> +#define SYSTAB_LEN   4096 /* assume 4kb is enough...*/
> +#define DB_DUMP_DIR  "./rmc_db_dump"  /* directory to store db data dump 
> */
> +
> +extern const rmc_uint8_t rmc_db_signature[RMC_DB_SIG_LEN];
We could have a new small helper API like is_rmcdb(db_blob) in RMCL to hold 
checker logic at line 357 in this file, so that we can get rid of this line and 
make the checker reusable. (So far I feel the checker should work in both EFI 
and Linux contexts.)

We could even update checker API without bothering its callers in the future. 
Let me know if it makes sense...

> 
> int read_file(const char *pathname, char **data, rmc_size_t* len) {
> int fd = -1;
> @@ -325,3 +329,80 @@ int rmc_gimme_file(char* db_pathname, char *file_name, 
> rmc_file_t *file) {
> 
> return ret;
> }
> +
> +/*
> + * Dump contents of database file
> + * (in) rmc_db - input database file to extract
rmc_db VS db_pathname. I think we can remove the comment here, it is already in 
the header file.
> + */
> +int dump_db(char *db_pathname) {
> +rmc_meta_header_t meta_header;
> +rmc_db_header_t *db_header = NULL;
> +rmc_record_header_t record_header;
> +rmc_uint64_t record_idx = 0;   /* offset of each reacord in db*/
> +rmc_uint64_t meta_idx = 0; /* offset of each meta in a record */
> +rmc_uint64_t file_idx = 0; /* offset of file in a meta */
> +rmc_file_t file;
> +char *out_dir = NULL, *out_name = NULL;
> +rmc_size_t db_len = 0;
> +rmc_uint8_t *rmc_db = NULL;
> +struct stat s = {0};
> +
> +if (read_file(db_pathname, (char **)&rmc_db, &db_len)) {
> +fprintf(stderr, "Failed to read database file\n\n");
> +return 1;
> +}
> +
> +db_header = (rmc_db_header_t *)rmc_db;
> +
> +/* sanity check of db */
> +if (strncmp((const char *)db_header->signature,
> +(const char *)rmc_db_signature, RMC_DB_SIG_LEN))
> +return 1;
> +
> +/* create the top level directory */
> +if (stat(DB_DUMP_DIR, &s) == -1) {
> +if(mkdir(DB_DUMP_DIR, 0755)) {
> +fprintf(stderr, "Failed to create %s directory\n\n", out_name);
I think we should not go any further when we cannot create the top dir.
> +}
> +}
> +
> +/* query the meta. idx: start of record */
> +record_idx = sizeof(rmc_db_he

Re: [yocto] [PATCH 2/3] rmc: Enable reading the contents of an existing fingerprint file

[Jianxun Zhang]

Tudor,
Please refer to my 3 inline comments.

> On Feb 2, 2017, at 2:37 PM, Todor Minchev  
> wrote:
> 
> The contents of an existing fingerprint file can be read and output on
> the command line with the following options:
> 
> ./rmc -F -i input_fingerprint_file
Suggest we have a new top option for dumping in parallel with -F to keep usages 
clear and simple for users.

> 
> Signed-off-by: Todor Minchev 
> ---
> src/rmc.c | 121 +++---
> 1 file changed, 76 insertions(+), 45 deletions(-)
> 
> diff --git a/src/rmc.c b/src/rmc.c
> index 062dd36..a051ccf 100644
> --- a/src/rmc.c
> +++ b/src/rmc.c
> @@ -14,33 +14,35 @@
> #include 
> 
> #define USAGE "RMC (Runtime Machine configuration) Tool\n" \
> -"NOTE: Most of usages require root permission (sudo)\n" \
> -"rmc -F [-o output_fingerprint]\n" \
> +"NOTE: Most of usages require root permission (sudo)\n\n" \
> +"rmc -F [-o output_fingerprint] | -i input_fingerprint\n" \
> "rmc -R [-f ] -b  [-o output_record]\n" 
> \
> "rmc -D  [-o output_database]\n" \
> - "rmc -B  -d  -o output_file\n" \
> - "\n" \
> - "-F: generate board rmc fingerprint of board\n" \
> - "-R: generate board rmc record of board with its fingerprint and file 
> blobs.\n" \
> -"-f: fingerprint file to be packed in record, rmc will create a 
> fingerprint for board and use it internally to\n" \
> -"generate record if -f is missed.\n" \
> -"-b: files to be packed in record\n" \
> - "-G: generate rmc database file with records specified in record file 
> list\n" \
> - "-B: get a flie blob with specified name associated to the board rmc is 
> running on\n" \
> - "-d: database file to be queried\n" \
> - "-o: path and name of output file of a specific command\n" \
> - "\n" \
> -"Examples (Steps in an order to add board support into rmc):\n" \
> -"generate board fingerprint:\n" \
> -"rmc -F\n\n" \
> -"generate a rmc record for the board with two file blobs, output to:\n" \
> -"a specified file:\n" \
> -"rmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
> -"generate a rmc database file with records from 3 different boards:\n" \
> -"rmc -D board1_record board2_record board3_record\n\n" \
> -"query a file blob named audio.conf associated to the board rmc is 
> running on in database my_rmc.db and output\n" \
> -"to /tmp/new_audio.conf:\n" \
> -"rmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
> +"rmc -B  -d  -o output_file\n\n" \
> +  "-F: manage fingerprint file\n" \
> +"\t-o output_file: store RMC fingerprint of current board in 
> output_file\n" \
> +"\t-i input_file: print RMC fingerprint stored in input_file\n\n" \
> +  "-R: generate board rmc record of board with its fingerprint and file 
> blobs.\n" \
> +"\t-f intput_file : input fingerprint file to be packed in record\n\n" \
> +"\tNOTE: RMC will create a fingerprint for the board and use it to\n" \
> +"\tgenerate record if an input fingerprint file is not provided.\n\n" \
> +"\t-b: files to be packed in record\n\n" \
> +  "-G: generate rmc database file with records specified in record file 
> list\n\n" \
> +  "-B: get a file blob with specified name associated to the board rmc is\n" 
> \
> +  "running on\n" \
> +"\t-d: database file to be queried\n" \
> +"\t-o: path and name of output file of a specific command\n\n" \
> +"Examples (Steps in an order to add board support into rmc):\n\n" \
> +"1. Generate board fingerprint:\n" \
> +"\t./rmc -F\n\n” \
Why do we force the rmc in current dir here? rmc can be installed to a system 
path like other programs.

> +"2. Generate a rmc record for the board with two file blobs and save 
> it\n" \
> +"to a specified file:\n" \
> +"\t./rmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
> +"3. Generate a rmc database file with records from 3 different 
> boards:\n" \
> +"\t./rmc -D board1_record board2_record board3_record\n\n" \
> +"4. Query a file blob named audio.conf associated to the board rmc is\n" 
> \
> +"running on in database my_rmc.db and output to /tmp/new_audio.conf:\n" \
> +"\t./rmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
> 
> 
> #define RMC_OPT_CAP_F   (1 << 0)
> @@ -51,6 +53,7 @@
> #define RMC_OPT_O   (1 << 5)
> #define RMC_OPT_B   (1 << 6)
> #define RMC_OPT_D   (1 << 7)
> +#define RMC_OPT_I   (1 << 8)
> 
> static void usage () {
> fprintf(stdout, USAGE);
> @@ -78,7 +81,7 @@ static void dump_fingerprint(rmc_fingerprint_t *fp) {
> static int write_fingerprint_file(const char* pathname, rmc_fingerprint_t 
> *fp) {
> int i;
> int first = 0;
> -
> +/* TODO - do we need to open/close file multiple times to write each 
> field */
> for (i = 0; i < RMC_FINGER_NUM; i++) {
> if (write_file(pathname, &fp->rmc_fingers[i].type, 
> sizeof(fp->rmc_fingers[i].type)

Re: [yocto] [PATCH 1/3] Makefile: add verbosity and debug options to Makefile

[Jianxun Zhang]

Todor,
Please refer to my 2 inline comments.

> On Feb 2, 2017, at 2:37 PM, Todor Minchev  
> wrote:
> 
> By default Makefile verbosity is disabled (V=0). Verbosity can be enabled by
> setting the V environment variable to any value not equal to 0 (e.g V=1)
> 
> Example:
> make clean V=1; make V=1
> 
> A debug version of the rmc binary can be built by using the debug
> Makefile target. This will include debug symbols and will disable compiler
> optimizations when compiling rmc.
> 
> Example:
> 
> make debug
> 
> Signed-off-by: Todor Minchev 
> ---
> Makefile | 31 +--
> 1 file changed, 21 insertions(+), 10 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 9ade775..d85d8e9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,5 +1,12 @@
> # Copyright (C) 2016 Jianxun Zhang 
> 
> +V ?= 0
> +ifeq ($(V),0)
> +  VERBOSITY = @
> +else
> +  VERBOSITY =
> +endif
> +
I am thinking maybe we should remove ‘@‘ in rules and use -s option of make (in 
recipe) when we want to mute the output. This should reach the same effect 
without bothering new variables.

We still enable/disable output as a whole anyway.

Let me know if this proposal works for you.

> TOPDIR = $(shell if [ -z "$$PWD" ]; then pwd; else echo "$$PWD"; fi)
> 
> RMC_TOOL_SRC := $(wildcard src/*.c)
> @@ -20,28 +27,32 @@ RMC_INSTALL_HEADER_PATH := 
> $(RMC_INSTALL_PREFIX)/include/rmc/
> 
> ALL_OBJS := $(RMC_TOOL_OBJ) $(RMC_LIB_OBJ)
> 
> +
> RMC_CFLAGS := -Wall -I$(TOPDIR)/inc
> 
> all: rmc
> +debug: RMC_CFLAGS += -DDEBUG -g -O0
> +debug: rmc
I am not sure if this is necessary because we already have CFLAGS. I think you 
can reach the same effect without adding a new debug target:
make CFLAGS='-DDEBUG -g -O0’

also refer to commit e8b48e6 in rmc project.

> 
> $(ALL_OBJS): %.o: %.c
> - @$(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> + $(VERBOSITY)$(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> 
> librmc: $(RMC_LIB_OBJ)
> - @$(AR) rcs src/lib/$@.a $^
> + $(VERBOSITY)$(AR) rcs src/lib/$@.a $^
> 
> rmc: $(RMC_TOOL_OBJ) librmc
> - @$(CC) $(CFLAGS) $(RMC_CFLAGS) -Lsrc/lib/ -lrmc $(RMC_TOOL_OBJ) 
> src/lib/librmc.a -o src/$@
> + $(VERBOSITY)$(CC) $(CFLAGS) $(RMC_CFLAGS) -Lsrc/lib/ -lrmc 
> $(RMC_TOOL_OBJ) \
> +  src/lib/librmc.a -o src/$@
> 
> clean:
> - @rm -f $(ALL_OBJS) src/rmc src/lib/librmc.a
> + $(VERBOSITY)rm -f $(ALL_OBJS) src/rmc src/lib/librmc.a
> 
> .PHONY: clean rmc librmc
> 
> install:
> - @mkdir -p $(RMC_INSTALL_BIN_PATH)
> - @install -m 755 src/rmc $(RMC_INSTALL_BIN_PATH)
> - @mkdir -p $(RMC_INSTALL_LIB_PATH)
> - @install -m 644 src/lib/librmc.a $(RMC_INSTALL_LIB_PATH)
> - @mkdir -p $(RMC_INSTALL_HEADER_PATH)
> - @install -m 644 $(RMC_INSTALL_HEADERS) $(RMC_INSTALL_HEADER_PATH)
> + $(VERBOSITY)mkdir -p $(RMC_INSTALL_BIN_PATH)
> + $(VERBOSITY)install -m 755 src/rmc $(RMC_INSTALL_BIN_PATH)
> + $(VERBOSITY)mkdir -p $(RMC_INSTALL_LIB_PATH)
> + $(VERBOSITY)install -m 644 src/lib/librmc.a $(RMC_INSTALL_LIB_PATH)
> + $(VERBOSITY)mkdir -p $(RMC_INSTALL_HEADER_PATH)
> + $(VERBOSITY)install -m 644 $(RMC_INSTALL_HEADERS) 
> $(RMC_INSTALL_HEADER_PATH)
> -- 
> 2.11.0
> 

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

[yocto] Yocto Project Status WW06’17

[Jolley, Stephen K]

Current Dev Position: YP 2.3 M3

Next Deadline: YP 2.3 M3 by Feb. 27, 2017


SWAT team rotation: Ross -> Leo on Feb. 3, 2017.

SWAT team rotation: Leo-> Juro on Feb. 10, 2017.

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


Key Status/Updates:

·The issues encountered in M2-rc1, particularly from the oeqa changes 
have meant we’ve taken M2 to another rc build which is now in QA. We decided to 
include several recipe specific sysroot (RSS) fixes in that as well.

·There have been several patches submitted to try and improve the 
performance of RSS. On higher spec machines, the performance seems to be 
reasonable and the performance issues we’ve seen have tended to be on 
older/slower hardware where disk IO (triggered by limited memory) may be a 
particular bottleneck. We’re probably starting to reach the point of 
diminishing returns for performance improvements which most of the ones we’ve 
been able to identify having been implemented by now.

·The 2.2.1 release will happen after M2.

·Patch merging continues to be steady and we’re aware we’re continuing 
to lag behind.

·ELC may distract people and continue to impact patch merging progress 
amongst other things.


Proposed upcoming dot releases:

YP 2.2.1 Release by Jan. 20, 2017 (Will be after YP 2.3 M2 is out of QA)

YP 2.1.3 Cut off May 8, 2017

YP 2.1.3 Release by May 19, 2017

YP 2.2.2 Cut off May 22, 2017

YP 2.2.2 Release by June 2, 2017


Key YP 2.3 Dates:

YP 2.3 M2 Release is targeted for Feb. 3, 2017

YP 2.3 M3 Cutoff is Feb 27, 2017

YP 2.3 M3 Release is Mar. 10, 2017

YP 2.3 M4 Cutoff is April 3, 2017

YP 2.3 M4 Release is April 28, 2017


Tracking Metrics:

WDD 2667 (last week 2630)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

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

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

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


[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
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:stephen.k.jol...@intel.com

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

[yocto] 请教关于linux-yocto_3.8.bbappend里面的内容

[liangzi]

你好：
请问meta-fsl-arm-2.1/recipes-kernel/linux/目录下面的linux-yocto_3.8.bbappend文件里面
#SRCREV_machine_pn-linux-yocto_mini2440 ?= 
"a4d2a08f3bfc57ff5d7d1307fb23f52f1e681aca"
#SRCREV_meta_pn-linux-yocto_mini2440 ?= 
"459165c1dd61c4e843c36e6a1abeb30949a20ba7"
其中 这些数字是从哪里得到的呢 谢谢

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

Re: [yocto] [meta-rockchip][PATCH 2/7] machine: Add machine file for the rk3288 linux Boards

[Jacob Chen]

Hi all,

Thanks for reviewing, I will looking at comments and suggestions after 
the other work finished.


: )



在 2017年01月27日 22:37, Romain Perier 写道:

Hey,

Could you:
- Make one patch per new machine file and not one patch for all new 
added machine
- Add a clear @DESCRIPTION for each board, see an example here: 
https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/conf/machine/firefly-rk3288.conf

- Write a clear and an understandable commit message for your new patches

@Trevor: What do you think about this rk-linux.inc ? I don't like 
this, either its name and what it contains.


That's it for now.
Thanks for your patches


2017-01-19 15:04 GMT+01:00 Jacob Chen >:


Evb-rk3288 is the offical evaluate board, add it to help myself
develop.

Fennec-rk3288 and Tinker-rk3288 is rk3288 based SBCs.
.
Tinker Boards:

http://www.cnx-software.com/2017/01/05/asus-tinker-board-is-a-raspberry-pi-3-alternative-based-on-rockchip-rk3288-processor/



Signed-off-by: Jacob Chen mailto:jacob-c...@rock-chips.com>>
---
 conf/machine/evb-rk3288.conf  | 12 
 conf/machine/fennec-rk3288.conf   | 12 
 conf/machine/include/rk-linux.inc | 20 
 conf/machine/tinker-rk3288.conf   | 13 +
 4 files changed, 57 insertions(+)
 create mode 100644 conf/machine/evb-rk3288.conf
 create mode 100644 conf/machine/fennec-rk3288.conf
 create mode 100644 conf/machine/include/rk-linux.inc
 create mode 100644 conf/machine/tinker-rk3288.conf

diff --git a/conf/machine/evb-rk3288.conf
b/conf/machine/evb-rk3288.conf
new file mode 100644
index 000..88a5f78
--- /dev/null
+++ b/conf/machine/evb-rk3288.conf
@@ -0,0 +1,12 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: EVB 3288
+
+include conf/machine/include/rk3288.inc
+include conf/machine/include/rk-linux.inc
+
+KERNEL_DEVICETREE = "rk3288-evb-act8846.dtb"
+
+UBOOT_MACHINE = "evb-rk3288_defconfig"
diff --git a/conf/machine/fennec-rk3288.conf
b/conf/machine/fennec-rk3288.conf
new file mode 100644
index 000..a85045f
--- /dev/null
+++ b/conf/machine/fennec-rk3288.conf
@@ -0,0 +1,12 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: FENNEC RK3288
+
+include conf/machine/include/rk3288.inc
+include conf/machine/include/rk-linux.inc
+
+KERNEL_DEVICETREE = "rk3288-fennec.dtb"
+
+UBOOT_MACHINE = "fennec-rk3288_defconfig"
diff --git a/conf/machine/include/rk-linux.inc
b/conf/machine/include/rk-linux.inc
new file mode 100644
index 000..6abaa0d
--- /dev/null
+++ b/conf/machine/include/rk-linux.inc
@@ -0,0 +1,20 @@
+# Rockchip BSP default settings
+
+PREFERRED_PROVIDER_virtual/egl = "mali-userspace"
+PREFERRED_PROVIDER_virtual/libgles1 = "mali-userspace"
+PREFERRED_PROVIDER_virtual/libgles2 = "mali-userspace"
+PREFERRED_PROVIDER_virtual/libopencl = "mali-userspace"
+
+# Workaround: libmali.so provided by rk having no SONAME field in it
+# so add it to fix rdepends problems
+ASSUME_SHLIBS += "libEGL.so:mali-userspace"
+ASSUME_SHLIBS += "libGLESv1_CM.so:mali-userspace"
+ASSUME_SHLIBS += "libGLESv2.so:mali-userspace"
+ASSUME_SHLIBS += "libOpenCL.so:mali-userspace"
+ASSUME_SHLIBS += "libgbm.so:mali-userspace"
+ASSUME_SHLIBS += "libwayland-egl.so:mali-userspace"
+
+PREFERRED_PROVIDER_virtual/kernel = "linux-rockchip"
+PREFERRED_PROVIDER_virtual/bootloader = "u-boot-rockchip"
+
+IMAGE_CLASSES += "rockchip-next-image"
diff --git a/conf/machine/tinker-rk3288.conf
b/conf/machine/tinker-rk3288.conf
new file mode 100644
index 000..0464133
--- /dev/null
+++ b/conf/machine/tinker-rk3288.conf
@@ -0,0 +1,13 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: Tinker RK3288
+#@DESCRIPTION: ASUS Tinker Board is a Raspberry Pi 3 Alternative
based on Rockchip RK3288 Processor.
+
+include conf/machine/include/rk3288.inc
+include conf/machine/include/rk-linux.inc
+
+KERNEL_DEVICETREE = "rk3288-miniarm.dtb"
+
+UBOOT_MACHINE = "miniarm-rk3288_defconfig"
--
2.7.4




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

Re: [yocto] Build only one specific C source from git clone with many C files

[Burton, Ross]

On 6 February 2017 at 11:27, Prasant J  wrote:

> Is it possible to modify SRC_URI to take only one source file from a
> git clone and build it?
>

No, you can't do that with git.

One way would be to use the http fetcher to get the file directly from the
web interface to the kernel.

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

[yocto] [PATCH][yocto-docs] poky.ent: Fix Debian essential packages

[Jussi Kukkonen]

pip3, pexpect do not exist on any Debian version. Replace with
python3-pip, python3-pexpect.

Signed-off-by: Jussi Kukkonen 
---
 documentation/poky.ent | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/poky.ent b/documentation/poky.ent
index 46e1137..e7d76bd 100644
--- a/documentation/poky.ent
+++ b/documentation/poky.ent
@@ -61,7 +61,7 @@
 
 
 
+ build-essential chrpath socat cpio python python3 python3-pip 
python3-pexpect">
 https://lists.yoctoproject.org/listinfo/yocto

[yocto] Build only one specific C source from git clone with many C files

[Prasant J]

Hi,

I want to build only spidev_test.c from kernel sources
(kernel/Documentation/spi/spidev_test.c)

Is it possible to modify SRC_URI to take only one source file from a
git clone and build it?


Any inputs will be of help!


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

[yocto] live core-image-minimal 'Waiting for removable media ...' problem

[Belisko Marek]

Hi,

I'm adding new bsp layer for x86_64 machine and I successfully build
core-image-minimal. I burn iso file to usb key and after startup I can
see grub options. When choose boot option I can see kernel is booted
and init script from initrd is started but I see only : Waiting for
removable media and that's it (I have CONFIG_DEVTMPFS=y and also
CONFIG_DEVTMPFS_MOUNT=y). Any ideas what to check and why it's not
proceeding. I looked to initscrip and it looks for rootfs.img in
/run/media (maybe run folder doesn't exists?) Using jethro release
(maybe eudev issue?) Many thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto