Date   

[ptest-runner][PATCH 3/4] utils.c: Use a thread to read from child

Anibal Limon
 

In order to handle large output add a thread for read from childs using
a pipe and remove non-blocking option.

Modify bash unittest to output large data and cover this scenario.

[YOCTO #14220]

Signed-off-by: Aníbal Limón <anibal.limon@linaro.org>
---
Makefile | 2 +-
tests/data/bash/ptest/run-ptest | 4 +-
utils.c | 112 +++++++++++++++++++++-----------
3 files changed, 78 insertions(+), 40 deletions(-)

diff --git a/Makefile b/Makefile
index 3cca17b..1aa1830 100644
--- a/Makefile
+++ b/Makefile
@@ -31,7 +31,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
all: $(SOURCES) $(EXECUTABLE)

$(EXECUTABLE): $(OBJECTS)
- $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
+ $(CC) $(LDFLAGS) $(OBJECTS) -pthread -lutil -o $@

tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)

diff --git a/tests/data/bash/ptest/run-ptest b/tests/data/bash/ptest/run-ptest
index 09f997f..f36e077 100755
--- a/tests/data/bash/ptest/run-ptest
+++ b/tests/data/bash/ptest/run-ptest
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash

echo "bash"
printf "Hello World!,stderr\n" >&2
@@ -7,3 +7,5 @@ printf "Hello World!,stderr2\n" >&2
echo "bash3"
echo "bash4"
printf "Hello World!,stderr3\n" >&2
+
+echo {1..1000000}\\n
diff --git a/utils.c b/utils.c
index d784736..84cb570 100644
--- a/utils.c
+++ b/utils.c
@@ -39,6 +39,7 @@
#include <string.h>
#include <time.h>
#include <unistd.h>
+#include <pthread.h>

#include <sys/ioctl.h>
#include <sys/resource.h>
@@ -53,6 +54,11 @@
#define WAIT_CHILD_POLL_TIMEOUT_MS 200
#define WAIT_CHILD_BUF_MAX_SIZE 1024

+static struct {
+ int fds[2];
+ FILE *fps[2];
+} _child_reader;
+
static inline char *
get_stime(char *stime, size_t size, time_t t)
{
@@ -269,6 +275,44 @@ close_fds(void)
}
}

+static void *
+read_child(void *arg)
+{
+ struct pollfd pfds[2];
+ int r;
+
+ pfds[0].fd = _child_reader.fds[0];
+ pfds[0].events = POLLIN;
+ pfds[1].fd = _child_reader.fds[1];
+ pfds[1].events = POLLIN;
+
+ do {
+ r = poll(pfds, 2, WAIT_CHILD_POLL_TIMEOUT_MS);
+ if (r > 0) {
+ char buf[WAIT_CHILD_BUF_MAX_SIZE];
+ ssize_t n;
+
+ if (pfds[0].revents != 0) {
+ n = read(_child_reader.fds[0], buf, WAIT_CHILD_BUF_MAX_SIZE);
+ if (n > 0)
+ fwrite(buf, (size_t)n, 1, _child_reader.fps[0]);
+ }
+
+ if (pfds[1].revents != 0) {
+ n = read(_child_reader.fds[1], buf, WAIT_CHILD_BUF_MAX_SIZE);
+ if (n > 0)
+ fwrite(buf, (size_t)n, 1, _child_reader.fps[1]);
+ }
+
+ }
+
+ fflush(_child_reader.fps[0]);
+ fflush(_child_reader.fps[1]);
+ } while (1);
+
+ return NULL;
+}
+
static inline void
run_child(char *run_ptest, int fd_stdout, int fd_stderr)
{
@@ -292,22 +336,15 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
}

static inline int
-wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)
+wait_child(pid_t pid, int timeout, int *timeouted)
{
- struct pollfd pfds[2];
struct timespec sentinel;
clockid_t clock = CLOCK_MONOTONIC;
int looping = 1;
- int r;

int status = -1;
int waitflags;

- pfds[0].fd = fds[0];
- pfds[0].events = POLLIN;
- pfds[1].fd = fds[1];
- pfds[1].events = POLLIN;
-
if (clock_gettime(clock, &sentinel) == -1) {
clock = CLOCK_REALTIME;
clock_gettime(clock, &sentinel);
@@ -332,32 +369,12 @@ wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)
if (waitpid(pid, &status, waitflags) == pid)
looping = 0;

- r = poll(pfds, 2, WAIT_CHILD_POLL_TIMEOUT_MS);
- if (r > 0) {
- char buf[WAIT_CHILD_BUF_MAX_SIZE];
- ssize_t n;
-
- if (pfds[0].revents != 0) {
- while ((n = read(fds[0], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0)
- fwrite(buf, (size_t)n, 1, fps[0]);
- }
-
- if (pfds[1].revents != 0) {
- while ((n = read(fds[1], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0) {
- fflush(fps[0]);
- fwrite(buf, (size_t)n, 1, fps[1]);
- fflush(fps[1]);
- }
- }
-
- clock_gettime(clock, &sentinel);
- }
+ clock_gettime(clock, &sentinel);

if (WIFEXITED(status))
status = WEXITSTATUS(status);
}

- fflush(fps[0]);
return status;
}

@@ -426,6 +443,7 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
time_t duration;
int slave;
int pgid = -1;
+ pthread_t tid;

if (opts.xml_filename) {
xh = xml_create(ptest_list_length(head), opts.xml_filename);
@@ -435,18 +453,32 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,

do
{
- if ((rc = pipe2(pipefd_stdout, O_NONBLOCK)) == -1)
+ if ((rc = pipe(pipefd_stdout)) == -1)
break;

- if ((rc = pipe2(pipefd_stderr, O_NONBLOCK)) == -1) {
+ if ((rc = pipe(pipefd_stderr)) == -1) {
close(pipefd_stdout[0]);
close(pipefd_stdout[1]);
break;
}
- fprintf(fp, "START: %s\n", progname);
+
if (isatty(0) && ioctl(0, TIOCNOTTY) == -1) {
fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
}
+
+ _child_reader.fds[0] = pipefd_stdout[0];
+ _child_reader.fds[1] = pipefd_stderr[0];
+ _child_reader.fps[0] = fp;
+ _child_reader.fps[1] = fp_stderr;
+ rc = pthread_create(&tid, NULL, read_child, NULL);
+ if (rc != 0) {
+ fprintf(fp, "ERROR: Failed to create reader thread, %s\n", strerror(errno));
+ close(pipefd_stdout[0]);
+ close(pipefd_stdout[1]);
+ break;
+ }
+
+ fprintf(fp, "START: %s\n", progname);
PTEST_LIST_ITERATE_START(head, p)
char *ptest_dir = strdup(p->run_ptest);
if (ptest_dir == NULL) {
@@ -485,8 +517,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,

} else {
int status;
- int fds[2]; fds[0] = pipefd_stdout[0]; fds[1] = pipefd_stderr[0];
- FILE *fps[2]; fps[0] = fp; fps[1] = fp_stderr;

if (setpgid(child, pgid) == -1) {
fprintf(fp, "ERROR: setpgid() failed, %s\n", strerror(errno));
@@ -496,17 +526,20 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
fprintf(fp, "%s\n", get_stime(stime, GET_STIME_BUF_SIZE, sttime));
fprintf(fp, "BEGIN: %s\n", ptest_dir);

- status = wait_child(child, opts.timeout, fds, fps, &timeouted);
+
+ status = wait_child(child, opts.timeout, &timeouted);
+
+
entime = time(NULL);
duration = entime - sttime;

if (status) {
- fprintf(fps[0], "\nERROR: Exit status is %d\n", status);
+ fprintf(fp, "\nERROR: Exit status is %d\n", status);
rc += 1;
}
- fprintf(fps[0], "DURATION: %d\n", (int) duration);
+ fprintf(fp, "DURATION: %d\n", (int) duration);
if (timeouted)
- fprintf(fps[0], "TIMEOUT: %s\n", ptest_dir);
+ fprintf(fp, "TIMEOUT: %s\n", ptest_dir);

if (opts.xml_filename)
xml_add_case(xh, status, ptest_dir, timeouted, (int) duration);
@@ -517,6 +550,9 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
PTEST_LIST_ITERATE_END
fprintf(fp, "STOP: %s\n", progname);

+ pthread_cancel(tid);
+ pthread_join(tid, NULL);
+
close(pipefd_stdout[0]); close(pipefd_stdout[1]);
close(pipefd_stderr[0]); close(pipefd_stderr[1]);
} while (0);
--
2.31.0


[ptest-runner][PATCH 2/4] utils.c: Fix exit status of a child

Anibal Limon
 

Modify testcase to validate the actual exit status.

[YOCTO #14217]

Signed-off-by: Aníbal Limón <anibal.limon@linaro.org>
---
tests/data/fail/ptest/run-ptest | 3 +++
tests/utils.c | 2 +-
utils.c | 3 +++
3 files changed, 7 insertions(+), 1 deletion(-)
mode change 100644 => 100755 tests/data/fail/ptest/run-ptest

diff --git a/tests/data/fail/ptest/run-ptest b/tests/data/fail/ptest/run-ptest
old mode 100644
new mode 100755
index e69de29..f4e5d0b
--- a/tests/data/fail/ptest/run-ptest
+++ b/tests/data/fail/ptest/run-ptest
@@ -0,0 +1,3 @@
+#!/bin/bash
+
+exit 10
diff --git a/tests/utils.c b/tests/utils.c
index 132d98f..105e0c8 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -234,7 +234,7 @@ END_TEST
static void
search_for_fail(const int rp, FILE *fp_stdout)
{
- const char *fail_str = "ERROR: Exit status is";
+ const char *fail_str = "ERROR: Exit status is 10";
char line_buf[PRINT_PTEST_BUF_SIZE];
int found_fail = 0;
char *line = NULL;
diff --git a/utils.c b/utils.c
index 43ab03b..d784736 100644
--- a/utils.c
+++ b/utils.c
@@ -352,6 +352,9 @@ wait_child(pid_t pid, int timeout, int *fds, FILE **fps, int *timeouted)

clock_gettime(clock, &sentinel);
}
+
+ if (WIFEXITED(status))
+ status = WEXITSTATUS(status);
}

fflush(fps[0]);
--
2.31.0


[ptest-runner][PATCH 1/4] utils.c: get_available_ptests allow to specify relative directories

Anibal Limon
 

Fixes,

$ ./ptest-runner -d ./tests/data bash

Signed-off-by: Aníbal Limón <anibal.limon@linaro.org>
---
utils.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/utils.c b/utils.c
index a4e190e..43ab03b 100644
--- a/utils.c
+++ b/utils.c
@@ -34,6 +34,7 @@
#include <poll.h>
#include <pty.h>
#include <signal.h>
+#include <limits.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
@@ -85,6 +86,9 @@ get_available_ptests(const char *dir)
struct dirent **namelist;
int fail;
int saved_errno = -1; /* Initalize to invalid errno. */
+ char realdir[PATH_MAX];
+
+ realpath(dir, realdir);

do
{
@@ -93,7 +97,7 @@ get_available_ptests(const char *dir)
if (head == NULL)
break;

- if (stat(dir, &st_buf) == -1) {
+ if (stat(realdir, &st_buf) == -1) {
PTEST_LIST_FREE_CLEAN(head);
break;
}
@@ -104,7 +108,7 @@ get_available_ptests(const char *dir)
break;
}

- n = scandir(dir, &namelist, NULL, alphasort);
+ n = scandir(realdir, &namelist, NULL, alphasort);
if (n == -1) {
PTEST_LIST_FREE_CLEAN(head);
break;
@@ -130,7 +134,7 @@ get_available_ptests(const char *dir)
}

if (asprintf(&run_ptest, "%s/%s/ptest/run-ptest",
- dir, d_name) == -1) {
+ realdir, d_name) == -1) {
fail = 1;
saved_errno = errno;
free(d_name);
--
2.31.0


package_rpm and file conflicts.

Randall <randall.crook@...>
 

HI,

Building up a customization layer over the top of poke to install 3rd party RPM files at build time. These packages contain some basic global configuration changes for the destination environment. 

Unfortunately I am getting RPM file conflicts (EG: /etc/network/interfaces) when I go to build. How can force the package installation allowing for the conflicting file from the custom layer to over write the files in the base packages?

EG:

 file /etc/network/interfaces conflicts between attempted installs of router-1.0-r0.noarch and init-ifupdown-1.0-r7.qemuarm64
 file /etc/udhcpc.d/50default conflicts between attempted installs of router-1.0-r0.noarch and busybox-udhcpc-1.24.1-r0.aarch64


M+ & H bugs with Milestone Movements WW12

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW12 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

11449

Allow overriding classes to override overridden classes

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

11746

oe-selftest: capture self.logger messages in XML output

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

12090

bitbake resident server reconnect needed ?

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

12368

persistent bitbake server does not re-parse if previous build was ctrl+C'd

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

12937

Consistent naming scheme for deployed artifacts

randy.macleod@...

Martin.Jansa@...

3.3 M3

3.4 M1

 

12970

uninative file should be versionned

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

12986

Failed to expand SRCPV on updateding SRC_URI using pn overrides and BBCLASSEXTEND

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13183

bitbake-layers crashes with incorrect layer configuration data is given (expected proper error printing and exit with error)

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13278

If git protocol doesn't work, you get a tar.gz clone from PREMIRROR which has git protocol origin

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13424

devupstream doesn't work with mutilib

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13448

bitbake master appears to expand variables it should not need to

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13599

Enhancement: Detect variables that shouldn't be defined in image scope, but in global (distro) scope

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13699

Prolonged recipe parsing times after removing tmp when the resident bitbake server is used

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13711

Parsing fails on externalsrc recipe containing both git and file in SRC_URI

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13729

Changing siteinfo files doesn't change task checksum

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13742

HashEquiv server should have a read-only port or endpoint

randy.macleod@...

dl9pf@...

3.3 M3

3.4 M1

 

13823

fetch2: PREMIRROR and SRC_URI with users on both url yields invalid username

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13886

bitbake resident server does not honour --runonly or --runall options

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

13975

cve-checker: save to alternate file format like JSON

randy.macleod@...

chee.yang.lee@...

3.3 M3

3.4 M1

 

13973

change siginfo data format to json for reproducibility? (siginfo files currently not reproducible)

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

14021

Remove debug_domain logic

randy.macleod@...

JPEWhacker@...

3.4

3.4 M1

 

14088

Attempting to override RDEPENDS_${PN} from global config doesn't work

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

14123

Intermittent FileNotFound error on autobuilder oe-selftest-debian

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

14125

busybox wget ssl is exposed to MitM attack due to CVE-2018-1000500

randy.macleod@...

shachar@...

3.3 M3

3.3 M4

 

14156

gitsm: submodules are fetched as mirrored and not working as expected

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

 

14227

Intermittent oe-selftest fails with bash 5.1 do_compile

richard.purdie@...

richard.purdie@...

3.3 M3

3.3 M4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW12!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

randy.macleod@...

4

richard.purdie@...

2

JPEWhacker@...

2

yifan.yu@...

1

dorindabassey@...

1

kergoth@...

1

steve@...

1

Grand Total

12

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.3

Stephen Jolley
 

All,

Below is the list as of top 42 bug owners as of the end of WW12 of who have open medium or higher bugs and enhancements against YP 3.3.   There are 28 possible work days left until the final release candidates for YP 3.3 needs to be released.

Who

Count

ross@...

24

bluelightning@...

14

richard.purdie@...

9

mark.morton@...

7

JPEWhacker@...

7

akuster808@...

5

raj.khem@...

4

Qi.Chen@...

4

chee.yang.lee@...

4

trevor.gamblin@...

4

idadelm@...

3

timothy.t.orling@...

3

mostthingsweb@...

3

sakib.sajal@...

3

matthewzmd@...

2

ydirson@...

2

limon.anibal@...

2

bruce.ashfield@...

2

jeanmarie.lemetayer@...

2

stacygaikovaia@...

2

nicolas.dechesne@...

2

randy.macleod@...

2

jaewon@...

2

alejandro@...

2

yoctoproject@...

1

dorindabassey@...

1

mark.hatle@...

1

devendra.tewari@...

1

kergoth@...

1

twoerner@...

1

aehs29@...

1

anuj.mittal@...

1

jon.mason@...

1

pokylinux@...

1

mhalstead@...

1

mshah@...

1

mister_rs@...

1

hongxu.jia@...

1

john.kaldas.enpj@...

1

matt.ranostay@...

1

kexin.hao@...

1

open.source@...

1

Grand Total

132

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 366 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [meta-rockchip][PATCH] Add machine definitions for NanoPi-M4 boards

Joshua Watt
 

On 3/22/21 2:30 PM, Yann Dirson wrote:
Hi Joshua,

Le lun. 22 mars 2021 à 19:24, Joshua Watt <jpewhacker@gmail.com> a écrit :

On 3/22/21 9:59 AM, Yann Dirson wrote:

Hi Trevor,

Le lun. 22 mars 2021 à 15:47, Trevor Woerner <twoerner@gmail.com> a écrit :

On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@blade-group.com wrote:

This supports both the 2GB and 4GB versions of the board. This is not
done with 2 different machine definitions since only u-boot has to
change between those two configurations, but with a NANOPIM4_HW variable
to set in local.conf.

Traditionally in meta-rockchip this is done using two separate machine files
with all the common things factored into a common include file. See
tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
examples.

I would prefer if the same thing was done here.

Damned that was how I did my first patch, I just felt it was much
better this way :(

Digging up that original commit re rerolling.


Wouldn't it be useful to have a standard way to specify such hardware
variants, that
would be recognized as such by the layer index ?

FWIW, I'd rather u-boot could automatcially detect what variant of the board it's running on and do the right thing (usually, just selecting the proper DTB from the FIT image). The only reason I did not do this on the rock-pi-4 is because there doesn't appear to be a way for u-boot to detect which variant it's on :/
Wait, it's only the dtb used by u-boot which is different in this
case, the kernel uses a single dtb for both variants.
Those probably get embedded inside the bootloader, in any case they
are not those embedded in the fitImage.

#include "rk3399-nanopi4-u-boot.dtsi"
-#include "rk3399-sdram-ddr3-1866.dtsi"
+#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"

I have no clue how easily the two boards could be told one from the
other (let alone if that can be done safely),
and I feel that would rather be uboot-side work, rather than something
to be solved on the yocto side.
Ah, I was referring to the DTB used by the Kernel (which u-boot can switch), not the DTB used by u-boot itself (which AFAIK is compiled into u-boot and cannot be changed).








Re: [meta-rockchip][PATCH] Add machine definitions for NanoPi-M4 boards

Yann Dirson
 

Hi Joshua,

Le lun. 22 mars 2021 à 19:24, Joshua Watt <jpewhacker@gmail.com> a écrit :


On 3/22/21 9:59 AM, Yann Dirson wrote:

Hi Trevor,

Le lun. 22 mars 2021 à 15:47, Trevor Woerner <twoerner@gmail.com> a écrit :

On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@blade-group.com wrote:

This supports both the 2GB and 4GB versions of the board. This is not
done with 2 different machine definitions since only u-boot has to
change between those two configurations, but with a NANOPIM4_HW variable
to set in local.conf.

Traditionally in meta-rockchip this is done using two separate machine files
with all the common things factored into a common include file. See
tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
examples.

I would prefer if the same thing was done here.

Damned that was how I did my first patch, I just felt it was much
better this way :(

Digging up that original commit re rerolling.


Wouldn't it be useful to have a standard way to specify such hardware
variants, that
would be recognized as such by the layer index ?

FWIW, I'd rather u-boot could automatcially detect what variant of the board it's running on and do the right thing (usually, just selecting the proper DTB from the FIT image). The only reason I did not do this on the rock-pi-4 is because there doesn't appear to be a way for u-boot to detect which variant it's on :/
Wait, it's only the dtb used by u-boot which is different in this
case, the kernel uses a single dtb for both variants.
Those probably get embedded inside the bootloader, in any case they
are not those embedded in the fitImage.

#include "rk3399-nanopi4-u-boot.dtsi"
-#include "rk3399-sdram-ddr3-1866.dtsi"
+#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"

I have no clue how easily the two boards could be told one from the
other (let alone if that can be done safely),
and I feel that would rather be uboot-side work, rather than something
to be solved on the yocto side.







--
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech


Re: do_populate_cve_db CERTIFICATE_VERIFY_FAILED

Darcy Watkins
 

In case anyone else is affected by this…

 

  1. I tried building inside a Docker container based on Ubuntu 20.04 (and the buildtools removed) and the CVE database was populated properly (and CVE reports generated, etc).
  2. It failed during my first attempt, but that was because the buildtools were still present in the workspace.

 

From this, I conclude that using older OS like CentOS with buildtools, though it may be OK for more basic Yocto builds, it has issues when you attempt to make use of the meta-security layer.  I believe that the problem is related to the certificate validation tools of buildtool’s host python replacement used to run bitbake, etc.

 

So I suggest that if affected and if you need to continue using the older OS as your build host’s OS, use a Docker container such as that documented at CROPs.

 

 

 

Regards,

 

Darcy

 

Darcy Watkins ::  Senior Staff Engineer, Firmware

 

SIERRA WIRELESS

Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100

13811 Wireless Way  :: Richmond, BC Canada V6V 3A4

[M4]

dwatkins@... :: www.sierrawireless.com

 

From: <yocto@...> on behalf of "Darcy Watkins via lists.yoctoproject.org" <dwatkins=sierrawireless.com@...>
Reply-To: Darcy Watkins <dwatkins@...>
Date: Wednesday, March 17, 2021 at 9:45 AM
To: "yocto@..." <yocto@...>
Subject: [yocto] do_populate_cve_db CERTIFICATE_VERIFY_FAILED

 

Hi,

 

Anyone else encounter this?

 

WARNING: cve-update-db-native-1.0-r0 do_populate_cve_db: Failed to fetch CVE data ([SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1108))

 

I am not sure how to resolve this.  After googling on the subject, I found nothing really helpful.  Most hits suggest that the certificates are out of date.  I tried various suggested ways to resolve it, but nothing works.

 

Furthermore, as I dig into this, it becomes apparent that this could be confused by the different python3 that are on the system.  ‘which python3’ points to a python3 that is in the buildtools.  So I have a python3 from my CentOS 7 distro, there appears to be one as part of the buildtools (needed when you use CentOS).  Then there is python3-native and finally the python3 that is built for the target.

 

I suspect that this may be related to the python3 in the buildtools.  Anyone using a newer distro not requiring buildtools may not be affected.

 

I am using CentOS7, Yocto ‘dunfell’ (including the buildtools) and building for an NXP Layerscape target.  This particular build adds meta-security and the meta-security-isafw sub-layer (along with prerequisites).

 

 

Regards,

 

Darcy

 

Darcy Watkins ::  Senior Staff Engineer, Firmware

 

SIERRA WIRELESS

Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100

13811 Wireless Way  :: Richmond, BC Canada V6V 3A4

[M4]

dwatkins@... :: www.sierrawireless.com


Re: [meta-rockchip][PATCH] Add machine definitions for NanoPi-M4 boards

Joshua Watt
 


On 3/22/21 9:59 AM, Yann Dirson wrote:
Hi Trevor,

Le lun. 22 mars 2021 à 15:47, Trevor Woerner <twoerner@...> a écrit :
On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@... wrote:
This supports both the 2GB and 4GB versions of the board.  This is not
done with 2 different machine definitions since only u-boot has to
change between those two configurations, but with a NANOPIM4_HW variable
to set in local.conf.
Traditionally in meta-rockchip this is done using two separate machine files
with all the common things factored into a common include file. See
tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
examples.

I would prefer if the same thing was done here.
Damned that was how I did my first patch, I just felt it was much
better this way :(

Digging up that original commit re rerolling.


Wouldn't it be useful to have a standard way to specify such hardware
variants, that
would be recognized as such by the layer index ?

FWIW, I'd rather u-boot could automatcially detect what variant of the board it's running on and do the right thing (usually, just selecting the proper DTB from the FIT image). The only reason I did not do this on the rock-pi-4 is because there doesn't appear to be a way for u-boot to detect which variant it's on :/








Re: [error-report-web][PATCH V2] Add local.conf and auto.conf into error details

Richard Purdie
 

On Mon, 2021-03-22 at 15:32 +0000, Richard Purdie via lists.yoctoproject.org wrote:
Sorry about the delay on this, we do really need to get this resolved.
I'm wondering if we should replace the angled brackets test with
https://github.com/mozilla/bleach which would then remove the need
for these workarounds.

Would you be able to update the patch for the others issues please
and then we can look at this one separately?
I just sent out an as yet untested patch which may fix some of the quoting
issues by using bleach. I'd still need to add it to the requirements file...

Cheers,

Richard


[error-report-web] [PATCH] Post/parser: Use bleach to sanitse XSS input

Richard Purdie
 

Instead of searching for "<", use bleach to sanity input to avoid
any XSS issues.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
Post/parser.py | 26 +++++++++-----------------
1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/Post/parser.py b/Post/parser.py
index f411e02..536e872 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -9,6 +9,7 @@
# Licensed under the MIT license, see COPYING.MIT for details

import json, re
+import bleach
from Post.models import Build, BuildFailure, ErrorType
from django.conf import settings
from django.utils import timezone
@@ -19,21 +20,6 @@ class Parser:
def __init__(self, data):
self.data = data.decode('utf-8')

- # returns true if the values contain '<' char
- # Ignore the failures field (which is an array anyway)
- # Ignore any non-str fields too [YOCTO #14208]
- def contains_tags (self, data):
- for key,val in data.items():
- if key == 'failures':
- continue
-
- if not isinstance(val, str):
- continue
-
- if '<' in val:
- return True
- return False
-
def parse(self, request):
build_fails_logged = []

@@ -42,8 +28,14 @@ class Parser:
except:
return { 'error' : 'Invalid json' }

- if self.contains_tags(jsondata) == True:
- return { 'error' : 'Invalid characters in json' }
+ # Bleach data going directly into the database so that
+ # displaying in any of the graphing doesn't introduce XSS
+ for key,val in jsondata.items():
+ if key == 'failures':
+ continue
+ if not isinstance(val, str):
+ continue
+ jsondata[key] = bleach.clean(val)

b = Build.objects.create()
try:
--
2.30.2


Re: Enabling Serial console via uart1(serial1) in cm3(rpi3) kernel 5.4. #cm3 #dunfell

Zoran
 

Why am I (only, seems) always answering NON YOCTO issues in the YOCTO
thread??? ;-)
_______

OK. The good sign about what U R talking is shown here:
[ 0.000885] printk: console [tty1] enabled

But now another issue I'm facing when I'm enabling console
via this ttsS0 port i.e.
[ 13.280639] ttyS ttyS0: 2 input overrun(s)
It is on the several places:
[ 6.480654] ttyS ttyS0: 2 input overrun(s)
[ 7.962826] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex,
lpa 0xCDE1
[ 7.973416] ttyS ttyS0: 2 input overrun(s)
[ 11.883822] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 11.893705] ttyS ttyS0: 2 input overrun(s)
[ 13.268076] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state
recovery directory
[ 13.280639] ttyS ttyS0: 2 input overrun(s)

It seems that the solution for this problem is:
https://www.linuxquestions.org/questions/linux-kernel-70/tty-usb-input-overruns-4175512707/

Namely:
https://www.linuxquestions.org/questions/linux-kernel-70/tty-usb-input-overruns-4175512707/#post5215591

I fixed the problem with increasing the N_TTY_BUF_SIZE from 4096 to 131072
(file /include/linux/tty.h) and recompiled the linux kernel. I'm getting no more tty
input overrun(s).
Please, let us know.

Zee
_______





On Mon, Mar 22, 2021 at 10:19 AM <prashantsingh@dialtronics.com> wrote:

Hi Zoran,
here is the cat /proc/cmdline output of my cm3-

coherent_pool=1M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:AD:85:CA vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait kgdboc=ttyAMA0,115200

Earlier my issue was that I was no getting /dev/ttyS0 terminal in my yocto image for cm3.
But going through the web I got that setting 1 to CONFIG_SERIAL_8250_RUNTIME_UARTS solved that issue and now I'm getting ttyS0 in my /dev directory.

But now another issue I'm facing when I'm enabling cosole via this ttsS0 port i.e.
[ 13.280639] ttyS ttyS0: 2 input overrun(s)

here is my dmesg output:

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.4.64-v7 (oe-user@oe-host) (gcc version 9.3.0 (GCC)) #1 SMP Fri Sep 11 12:57:30 UTC 2020
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi Compute Module 3 Rev 1.0
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Reserved memory: created CMA memory pool at 0x37400000, size 64 MiB
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.000000] On node 0 totalpages: 242688
[ 0.000000] Normal zone: 2133 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 242688 pages, LIFO batch:63
[ 0.000000] percpu: Embedded 20 pages/cpu s50060 r8192 d23668 u81920
[ 0.000000] pcpu-alloc: s50060 r8192 d23668 u81920 alloc=20*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 240555
[ 0.000000] Kernel command line: coherent_pool=1M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:AD:85:CA vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait kgdboc=ttyAMA0,115200
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 880444K/970752K available (9216K kernel code, 716K rwdata, 2684K rodata, 1024K init, 849K bss, 24772K reserved, 65536K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 29805 entries in 59 pages
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] random: get_random_bytes called from start_kernel+0x328/0x508 with crng_init=0
[ 0.000000] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[ 0.000006] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[ 0.000020] Switching to timer-based delay loop, resolution 52ns
[ 0.000288] Console: colour dummy device 80x30
[ 0.000885] printk: console [tty1] enabled
[ 0.000960] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
[ 0.001009] pid_max: default: 32768 minimum: 301
[ 0.001232] LSM: Security Framework initializing
[ 0.001477] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.001524] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.002936] Disabling memory control group subsystem
[ 0.003081] CPU: Testing write buffer coherency: ok
[ 0.003674] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.004651] Setting up static identity map for 0x100000 - 0x100060
[ 0.004873] rcu: Hierarchical SRCU implementation.
[ 0.005586] smp: Bringing up secondary CPUs ...
[ 0.006748] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.008417] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.009943] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.010479] smp: Brought up 1 node, 4 CPUs
[ 0.010528] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[ 0.010557] CPU: All CPU(s) started in HYP mode.
[ 0.010582] CPU: Virtualization extensions available.
[ 0.011597] devtmpfs: initialized
[ 0.027564] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4
[ 0.028074] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.028132] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[ 0.031459] pinctrl core: initialized pinctrl subsystem
[ 0.032650] NET: Registered protocol family 16
[ 0.036992] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[ 0.041879] audit: initializing netlink subsys (disabled)
[ 0.042183] audit: type=2000 audit(0.040:1): state=initialized audit_enabled=0 res=1
[ 0.043730] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[ 0.043770] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.044019] Serial: AMBA PL011 UART driver
[ 0.046056] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[ 0.070160] raspberrypi-firmware soc:firmware: Attached to firmware from 2020-09-11 14:25, variant start
[ 0.080196] raspberrypi-firmware soc:firmware: Firmware hash is ecd571f7947fb751a266d8591b0573d4d975fbe6
[ 0.132933] bcm2835-dma 3f007000.dma: DMA legacy API manager, dmachans=0x1
[ 0.135178] SCSI subsystem initialized
[ 0.135460] usbcore: registered new interface driver usbfs
[ 0.135556] usbcore: registered new interface driver hub
[ 0.135703] usbcore: registered new device driver usb
[ 0.137691] clocksource: Switched to clocksource arch_sys_counter
[ 1.382483] VFS: Disk quotas dquot_6.6.0
[ 1.382646] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 1.382869] FS-Cache: Loaded
[ 1.383168] CacheFiles: Loaded
[ 1.394807] thermal_sys: Registered thermal governor 'step_wise'
[ 1.395207] NET: Registered protocol family 2
[ 1.396283] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[ 1.396360] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 1.396501] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 1.396713] TCP: Hash tables configured (established 8192 bind 8192)
[ 1.396898] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 1.396973] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 1.397287] NET: Registered protocol family 1
[ 1.398427] RPC: Registered named UNIX socket transport module.
[ 1.398462] RPC: Registered udp transport module.
[ 1.398488] RPC: Registered tcp transport module.
[ 1.398515] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 1.400297] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 7 counters available
[ 1.404004] Initialise system trusted keyrings
[ 1.404281] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[ 1.416225] FS-Cache: Netfs 'nfs' registered for caching
[ 1.416897] NFS: Registering the id_resolver key type
[ 1.416978] Key type id_resolver registered
[ 1.417005] Key type id_legacy registered
[ 1.417043] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 1.418451] Key type asymmetric registered
[ 1.418482] Asymmetric key parser 'x509' registered
[ 1.418551] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 1.418590] io scheduler mq-deadline registered
[ 1.418618] io scheduler kyber registered
[ 1.423548] bcm2708_fb soc:fb: FB found 1 display(s)
[ 1.437559] Console: switching to colour frame buffer device 90x30
[ 1.446253] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 720x480
[ 1.452896] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
[ 1.458395] bcm2835-rng 3f104000.rng: hwrng registered
[ 1.461812] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[ 1.468540] vc-sm: Videocore shared memory driver
[ 1.472180] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[ 1.489107] brd: module loaded
[ 1.505307] loop: module loaded
[ 1.509860] Loading iSCSI transport class v2.0-870.
[ 1.513862] libphy: Fixed MDIO Bus: probed
[ 1.517035] usbcore: registered new interface driver lan78xx
[ 1.520267] usbcore: registered new interface driver smsc95xx
[ 1.523303] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[ 2.254610] Core Release: 2.80a
[ 2.257707] Setting default values for core params
[ 2.260769] Finished setting default values for core params
[ 2.464194] Using Buffer DMA mode
[ 2.467200] Periodic Transfer Interrupt Enhancement - disabled
[ 2.470261] Multiprocessor Interrupt Enhancement - disabled
[ 2.473253] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 2.476233] Dedicated Tx FIFOs mode
[ 2.479874] WARN::dwc_otg_hcd_init:1072: FIQ DMA bounce buffers: virt = b7504000 dma = 0xf7504000 len=9024
[ 2.486063] FIQ FSM acceleration enabled for :
Non-periodic Split Transactions
Periodic Split Transactions
High-Speed Isochronous Endpoints
Interrupt/Control Split Transaction hack enabled
[ 2.500574] dwc_otg: Microframe scheduler enabled
[ 2.500642] WARN::hcd_init_fiq:457: FIQ on core 1
[ 2.503411] WARN::hcd_init_fiq:458: FIQ ASM at 80728fa4 length 36
[ 2.506123] WARN::hcd_init_fiq:496: MPHI regs_base at bb810000
[ 2.508797] dwc_otg 3f980000.usb: DWC OTG Controller
[ 2.511499] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[ 2.514279] dwc_otg 3f980000.usb: irq 56, io mem 0x00000000
[ 2.517028] Init: Port Power? op_state=1
[ 2.519717] Init: Power Port (0)
[ 2.522754] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[ 2.528327] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.531293] usb usb1: Product: DWC OTG Controller
[ 2.534211] usb usb1: Manufacturer: Linux 5.4.64-v7 dwc_otg_hcd
[ 2.537146] usb usb1: SerialNumber: 3f980000.usb
[ 2.540771] hub 1-0:1.0: USB hub found
[ 2.543657] hub 1-0:1.0: 1 port detected
[ 2.547238] dwc_otg: FIQ enabled
[ 2.547248] dwc_otg: NAK holdoff enabled
[ 2.547258] dwc_otg: FIQ split-transaction FSM enabled
[ 2.547274] Module dwc_common_port init
[ 2.547609] usbcore: registered new interface driver usb-storage
[ 2.550721] mousedev: PS/2 mouse device common for all mice
[ 2.554936] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[ 2.560496] sdhci: Secure Digital Host Controller Interface driver
[ 2.563302] sdhci: Copyright(c) Pierre Ossman
[ 2.566769] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
[ 2.570026] sdhci-pltfm: SDHCI platform and OF driver helper
[ 2.573709] ledtrig-cpu: registered to indicate activity on CPUs
[ 2.576947] hidraw: raw HID events driver (C) Jiri Kosina
[ 2.580129] usbcore: registered new interface driver usbhid
[ 2.583142] usbhid: USB HID core driver
[ 2.586528] ashmem: initialized
[ 2.590509] vchiq: vchiq_init_state: slot_zero = (ptrval)
[ 2.595277] [vc_sm_connected_init]: start
[ 2.605012] [vc_sm_connected_init]: end - returning 0
[ 2.610026] Initializing XFRM netlink socket
[ 2.613006] NET: Registered protocol family 17
[ 2.616003] Key type dns_resolver registered
[ 2.619492] Registering SWP/SWPB emulation handler
[ 2.622506] registered taskstats version 1
[ 2.625154] Loading compiled-in X.509 certificates
[ 2.628349] Key type ._fscrypt registered
[ 2.630977] Key type .fscrypt registered
[ 2.644359] uart-pl011 3f201000.serial: cts_event_workaround enabled
[ 2.647220] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[ 2.655430] printk: console [ttyS0] disabled
[ 2.658305] 3f215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 31250000) is a 16550
[ 3.678083] printk: console [ttyS0] enabled
[ 3.685731] KGDB: Registered I/O driver kgdboc
[ 3.693806] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[ 3.705593] sdhost: log_buf @ (ptrval) (f7507000)
[ 3.761622] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[ 3.772680] of_cfs_init
[ 3.778301] of_cfs_init: OK
[ 3.785362] Waiting for root device /dev/mmcblk0p2...
[ 3.797847] Indeed it is in host mode hprt0 = 00021501
[ 3.891131] random: fast init done
[ 3.936402] mmc0: new high speed MMC card at address 0001
[ 3.946012] mmcblk0: mmc0:0001 4FTE4R 3.64 GiB
[ 3.953973] mmcblk0boot0: mmc0:0001 4FTE4R partition 1 4.00 MiB
[ 3.963473] mmcblk0boot1: mmc0:0001 4FTE4R partition 2 4.00 MiB
[ 3.972635] mmcblk0rpmb: mmc0:0001 4FTE4R partition 3 512 KiB, chardev (245:0)
[ 3.985330] mmcblk0: p1 p2
[ 4.007759] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ 4.011189] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 4.017529] Indeed it is in host mode hprt0 = 00001101
[ 4.031809] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 4.050759] devtmpfs: mounted
[ 4.102220] Freeing unused kernel memory: 1024K
[ 4.128140] Run /sbin/init as init process
[ 4.278133] usb 1-1: New USB device found, idVendor=0424, idProduct=9514, bcdDevice= 2.00
[ 4.292686] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 4.303966] hub 1-1:1.0: USB hub found
[ 4.311058] hub 1-1:1.0: 5 ports detected
[ 4.647797] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[ 4.730514] udevd[115]: starting version 3.2.9
[ 4.745524] random: udevd: uninitialized urandom read (16 bytes read)
[ 4.756762] random: udevd: uninitialized urandom read (16 bytes read)
[ 4.766616] random: udevd: uninitialized urandom read (16 bytes read)
[ 4.788165] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00, bcdDevice= 2.00
[ 4.802823] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 4.814602] udevd[117]: starting eudev-3.2.9
[ 4.818138] smsc95xx v1.0.6
[ 4.923876] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:ad:85:ca
[ 5.161891] i2c /dev entries driver
[ 5.216319] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 5.972781] random: crng init done
[ 5.979289] random: 2 urandom warning(s) missed due to ratelimiting
[ 6.470391] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[ 6.480654] ttyS ttyS0: 2 input overrun(s)
[ 7.962826] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[ 7.973416] ttyS ttyS0: 2 input overrun(s)
[ 11.883822] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 11.893705] ttyS ttyS0: 2 input overrun(s)
[ 13.268076] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[ 13.280639] ttyS ttyS0: 2 input overrun(s)
[ 13.294215] NFSD: Using legacy client tracking operations.
[ 13.304013] NFSD: starting 90-second grace period (net f00004c1)
[ 1014.267771] usb 1-1.2: new high-speed USB device number 4 using dwc_otg
[ 1014.399220] usb 1-1.2: New USB device found, idVendor=0b95, idProduct=772b, bcdDevice= 0.02
[ 1014.408345] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1014.416278] usb 1-1.2: Product: AX88772B
[ 1014.420431] usb 1-1.2: Manufacturer: ASIX Elec. Corp.
[ 1014.425889] usb 1-1.2: SerialNumber: 000001



Please assist me if you have some clue regarding this issue.

Thanks and Regards.


Re: [meta-rockchip][PATCH] Add machine definitions for NanoPi-M4 boards

Trevor Woerner
 

On Mon, Mar 22, 2021 at 11:00 AM Yann Dirson
<yann.dirson@blade-group.com> wrote:
Wouldn't it be useful to have a standard way to specify such hardware
variants, that
would be recognized as such by the layer index ?
Sure it would! But then you'd have to get all the BSP layer
maintainers to agree on that format and use it… :-/


Re: [meta-rockchip][PATCH] Add machine definitions for NanoPi-M4 boards

Trevor Woerner
 

Hi Yann,

Thanks for the patch updates. I'll look at them soon.

On Mon 2021-03-22 @ 04:31:01 PM, Yann Dirson wrote:
BTW, I'm also unclear on what to do next to better support those
boards: with the default
kernel config only a subset of the hardware is supported, and for
state-of-the-art hw
support we'll also need patches not yet in upstream kernel (from eg.
armbian and libreelec).

I feel it would be good to provide defconfig files for those machines,
but then there are
several options to handle that. Would a minimal hw-focused defconfig
suitable for
`KCONFIG_MODE = "--allnoconfig"` be a good option ?
I feel exactly the same way.

By default all arm64 kernels are configured with the one, in-kernel, generic
arm64 defconfig. That gives me a kernel that is over 11MB in size, and
includes all sorts of useless drivers.

I've been working off-and-on on a mechanism for meta-rockchip that would allow
users to decide between the default in-kernel arm64 defconfig (which would
be selected by doing nothing) or using a leaner defconfig that I have been
tweaking specifically for each board. Currently I only have a lean defconfig
for rock-pi-4b, but it was my hope to generate defconfigs for all supported
boards.

Ideally I had wanted to leverage the linux-yocto kmeta mechanism to generate
defconfigs dynamically based on the specific machine and specific user
preferences, but that didn't go as smoothly as I was hoping, then I got
distracted by other things.

I had created a spreadsheet with a comparison between the various boards that
would have been a basis for the individual kmeta pieces. Maybe I'll find some
more time to poke at it later this week. I could also push my WIP stuff to
somewhere if you'd like to take a look.

In any case, my point is, I'm very interested in something better than what
currently exists :-)

One thing that I'd like to keep clear in meta-rockchip is to always allow the
user to choose between upstream and "extras". My feeling is: the simplest
build, if the user does nothing explicit, will always pull from pure upstream
with no out-of-tree patches or vendor pieces. But I'm not opposed to having
a mechanism whereby if the user does something explicit, they can choose to
use a vendor tree or make use of out-of-tree patches for various things.

Best regards,
Trevor


Re: [error-report-web][PATCH V2] Add local.conf and auto.conf into error details

Richard Purdie
 

On Fri, 2020-02-14 at 10:42 +0800, Changqing Li wrote:
On 12/11/19 1:45 PM, Changqing Li wrote:
On 11/13/19 6:36 PM, Paul Eggleton wrote:
Hi Changqing,

Some comments below.

On Tuesday, 12 November 2019 9:32:53 PM NZDT
changqing.li@windriver.com wrote:
From: Changqing Li <changqing.li@windriver.com>

+        {% if detail.BUILD.LOCAL_CONF != "" %}
+        <dt></a>Local Conf:</dt>
+        <dd style="white-space: pre-wrap;">{{
detail.BUILD.LOCAL_CONF | safe }}</dd>
+        {% endif %}
+
+        {% if detail.BUILD.AUTO_CONF != "" %}
+        <dt></a>Auto Conf:</dt>
+        <dd style="white-space: pre-wrap;">{{
detail.BUILD.AUTO_CONF | safe }}</dd>
+        {% endif %}
We cannot use the safe filter here - doing so could open up an XSS
vulnerability, since anyone can upload anything to the error-report
application and the content could include links or other malicious
HTML data. We should allow it to be auto-escaped. Is there a
particular issue you were using this to solve?
This is for resolve a problem when there is angle brackets in
local.conf/auto.conf.

I have a patch in oe-core [OE-core] [PATCH] report-error.bbclass:
replace angle brackets with &lt; and &gt;]

when we have below content in local.conf or auto.conf:
BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj<raj.khem@gmail.com>"
send-error-report will fail with "HTTP Error 500: OK"

error-report-web do rudimentary check on all fields that are
passed to the graphs page to avoid any XSS happening, if contains
'<', the server will return error(Invalid characters in json).
fixed by use escape of <> to replace it.

NOTE: with this change, error-report-web need to add filter 'safe'
for the string wanted to display to avoid further HTML escaping
prior to output. Below is how the content displayed on webpage:
with the filter 'safe':
BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj<raj.khem@gmail.com>"
without the filter 'safe':
BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj &lt;raj.khem@gmail.com&gt;"

Do you have good idea to resolve this? Thanks.
Sorry about the delay on this, we do really need to get this resolved.
I'm wondering if we should replace the angled brackets test with
https://github.com/mozilla/bleach which would then remove the need
for these workarounds.

Would you be able to update the patch for the others issues please
and then we can look at this one separately?

Thanks,

Richard


Re: [meta-rockchip][PATCH] Add machine definitions for NanoPi-M4 boards

Yann Dirson
 

BTW, I'm also unclear on what to do next to better support those
boards: with the default
kernel config only a subset of the hardware is supported, and for
state-of-the-art hw
support we'll also need patches not yet in upstream kernel (from eg.
armbian and libreelec).

I feel it would be good to provide defconfig files for those machines,
but then there are
several options to handle that. Would a minimal hw-focused defconfig
suitable for
`KCONFIG_MODE = "--allnoconfig"` be a good option ?

Le lun. 22 mars 2021 à 16:00, Yann Dirson via lists.yoctoproject.org
<yann.dirson=blade-group.com@lists.yoctoproject.org> a écrit :

Hi Trevor,

Le lun. 22 mars 2021 à 15:47, Trevor Woerner <twoerner@gmail.com> a écrit :
On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@blade-group.com wrote:
This supports both the 2GB and 4GB versions of the board. This is not
done with 2 different machine definitions since only u-boot has to
change between those two configurations, but with a NANOPIM4_HW variable
to set in local.conf.
Traditionally in meta-rockchip this is done using two separate machine files
with all the common things factored into a common include file. See
tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
examples.

I would prefer if the same thing was done here.
Damned that was how I did my first patch, I just felt it was much
better this way :(

Digging up that original commit re rerolling.


Wouldn't it be useful to have a standard way to specify such hardware
variants, that
would be recognized as such by the layer index ?



--
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech



--
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech


[meta-rockchip][PATCH v2] Add machine definitions for NanoPi-M4 boards, 2GB and 4GB variants

Yann Dirson
 

From: Yann Dirson <yann@blade-group.com>

---

Changes from v1: split in two distinct machines: nanopi-m4 and nanopi-m4-=
2gb

conf/machine/include/nanopi-m4.inc | 22 +++++++++++++++++++
conf/machine/nanopi-m4-2gb.conf | 8 +++++++
conf/machine/nanopi-m4.conf | 8 +++++++
recipes-kernel/linux/linux-yocto-dev.bbappend | 2 ++
.../linux/linux-yocto-rt_%.bbappend | 2 ++
.../linux/linux-yocto-tiny_%.bbappend | 2 ++
recipes-kernel/linux/linux-yocto_%.bbappend | 2 ++
7 files changed, 46 insertions(+)
create mode 100644 conf/machine/include/nanopi-m4.inc
create mode 100644 conf/machine/nanopi-m4-2gb.conf
create mode 100644 conf/machine/nanopi-m4.conf

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/na=
nopi-m4.inc
new file mode 100644
index 0000000..f6d9c11
--- /dev/null
+++ b/conf/machine/include/nanopi-m4.inc
@@ -0,0 +1,22 @@
+# Copyright (C) 2021 Blade SAS
+# Common definitions for all NanoPi M4 RK3399 board variants
+
+require rk3399.inc
+
+KERNEL_DEVICETREE =3D "rockchip/rk3399-nanopi-m4.dtb"
+
+RK_BOOT_DEVICE =3D "mmcblk1"
+WKS_FILE ?=3D "rock-pi-4.wks"
+IMAGE_FSTYPES +=3D "wic"
+
+WKS_FILE_DEPENDS ?=3D " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?=3D "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+SERIAL_CONSOLES =3D "1500000;ttyS2"
diff --git a/conf/machine/nanopi-m4-2gb.conf b/conf/machine/nanopi-m4-2gb=
.conf
new file mode 100644
index 0000000..9fd7279
--- /dev/null
+++ b/conf/machine/nanopi-m4-2gb.conf
@@ -0,0 +1,8 @@
+# Copyright (C) 2021 Blade SAS
+
+#@TYPE: Machine
+#@NAME: NanoPi M4
+#@DESCRIPTION: NanoPi M4 RK3399 board from FriendlyElec, 2GB variant
+
+require include/nanopi-m4.inc
+UBOOT_MACHINE =3D "nanopi-m4-2gb-rk3399_defconfig"
diff --git a/conf/machine/nanopi-m4.conf b/conf/machine/nanopi-m4.conf
new file mode 100644
index 0000000..648fc75
--- /dev/null
+++ b/conf/machine/nanopi-m4.conf
@@ -0,0 +1,8 @@
+# Copyright (C) 2021 Blade SAS
+
+#@TYPE: Machine
+#@NAME: NanoPi M4
+#@DESCRIPTION: NanoPi M4 RK3399 board from FriendlyElec, 4GB variant
+
+require include/nanopi-m4.inc
+UBOOT_MACHINE =3D "nanopi-m4-rk3399_defconfig"
diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kern=
el/linux/linux-yocto-dev.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ b/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto-rt_%.bbappend b/recipes-ker=
nel/linux/linux-yocto-rt_%.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto-rt_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto-rt_%.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend b/recipes-k=
ernel/linux/linux-yocto-tiny_%.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel=
/linux/linux-yocto_%.bbappend
index e5ea197..7702e3f 100644
--- a/recipes-kernel/linux/linux-yocto_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -6,3 +6,5 @@ COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
+COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
--=20
2.30.2

1141 - 1160 of 53919