Date   

Re: Yocto server is down

Michael Halstead
 

The router provided by our colocation provider went offline December 13 at 3:07am PST. I've been working with them since to restore service. I'm now on site at the data center with a senior network tech. We should have a timeline for the repair soon.

Until the repair is complete downloads.yoctoproject.org, state.yoctoproject.org, autobuilder.yocto.io, and the typhoon autobulder workers are not available.


-- 
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

On Fri, Dec 13, 2019 at 9:36 AM Armin Kuster <akuster@...> wrote:


On 12/13/19 7:46 AM, FLoraVLogs wrote:
Hi,

I went to "http://downloads.yoctoproject.org/" and I get the following message:

Gateway Timeout

Server error - server 198.145.29.63 is unreachable at this moment.

Please retry the request or contact your administrator.

Kindly assist here.


Thanks. The LF IT department is aware of  this and working towards a solution.

No ETA.

Regards,
Armin

Regards,

Ripu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47662): https://lists.yoctoproject.org/g/yocto/message/47662
Mute This Topic: https://lists.yoctoproject.org/mt/68533979/1024635
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [akuster@...]
-=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47663): https://lists.yoctoproject.org/g/yocto/message/47663
Mute This Topic: https://lists.yoctoproject.org/mt/68533979/1003190
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [mhalstead@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: Yocto server is down

Armin Kuster
 



On 12/13/19 7:46 AM, FLoraVLogs wrote:
Hi,

I went to "http://downloads.yoctoproject.org/" and I get the following message:

Gateway Timeout

Server error - server 198.145.29.63 is unreachable at this moment.

Please retry the request or contact your administrator.

Kindly assist here.


Thanks. The LF IT department is aware of  this and working towards a solution.

No ETA.

Regards,
Armin

Regards,

Ripu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47662): https://lists.yoctoproject.org/g/yocto/message/47662
Mute This Topic: https://lists.yoctoproject.org/mt/68533979/1024635
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [akuster@...]
-=-=-=-=-=-=-=-=-=-=-=-


Yocto server is down

FLoraVLogs <eripflo@...>
 

Hi,

I went to "http://downloads.yoctoproject.org/" and I get the following message:

Gateway Timeout

Server error - server 198.145.29.63 is unreachable at this moment.

Please retry the request or contact your administrator.

Kindly assist here.

Regards,

Ripu


Re: Write contents of recipe variable into a configuration file

Ross Burton <ross.burton@...>
 

On 13/12/2019 10:23, Andy Pont wrote:
Hello,
I’m having a Friday, brain-fade moment.  I want to define a variable within the wpa_supplicant.bbappend file:
WPA_GROUP_NAME = value
This value needs to be propagated into the wpa_supplicant.conf configuration file for the “ctrl_interface_group” setting before the file gets written into the target file system.
 I once saw a recipe that defined something similar as an arbitrary value in the configuration file i.e. in this case we would use:
ctrl_interface_group=$xxxx
...and then used file and string manipulation to put the correct value there during the do_install() phase.
I now can’t find that recipe to see how it was done nor can I work out how it was done.
Use sed:

sed -i -e s/@TOKEN/${WPA_GROUP_NAME}/ ${D}${sysconfdir}/configfile

Ross


Write contents of recipe variable into a configuration file

Andy Pont
 

Hello,

I’m having a Friday, brain-fade moment.  I want to define a variable within the wpa_supplicant.bbappend file:

WPA_GROUP_NAME = value

This value needs to be propagated into the wpa_supplicant.conf configuration file for the “ctrl_interface_group” setting before the file gets written into the target file system.

 I once saw a recipe that defined something similar as an arbitrary value in the configuration file i.e. in this case we would use:

ctrl_interface_group=$xxxx

...and then used file and string manipulation to put the correct value there during the do_install() phase.

I now can’t find that recipe to see how it was done nor can I work out how it was done.

-Andy.
 


[meta-selinux][PATCH] sysvinit: sync bbappend to 2.96

hongxu
 

Since oe-core upgrades sysvinit to 2.96, wildcard its bbappend and
drop the backported patch

Signed-off-by: Hongxu Jia <hongxu.jia@...>
---
.../sysvinit-fix-is_selinux_enabled.patch | 71 -------------------
....88dsf.bbappend => sysvinit_2.9%.bbappend} | 2 +-
...88dsf_selinux.inc => sysvinit_selinux.inc} | 2 -
3 files changed, 1 insertion(+), 74 deletions(-)
delete mode 100644 recipes-core/sysvinit/files/sysvinit-fix-is_selinux_enabled.patch
rename recipes-core/sysvinit/{sysvinit_2.88dsf.bbappend => sysvinit_2.9%.bbappend} (64%)
rename recipes-core/sysvinit/{sysvinit-2.88dsf_selinux.inc => sysvinit_selinux.inc} (74%)

diff --git a/recipes-core/sysvinit/files/sysvinit-fix-is_selinux_enabled.patch b/recipes-core/sysvinit/files/sysvinit-fix-is_selinux_enabled.patch
deleted file mode 100644
index 62703b1..0000000
--- a/recipes-core/sysvinit/files/sysvinit-fix-is_selinux_enabled.patch
+++ /dev/null
@@ -1,71 +0,0 @@
-From 0db0276202094c8d902fc93a18eca453b6211f8a Mon Sep 17 00:00:00 2001
-From: Xin Ouyang <Xin.Ouyang@...>
-Date: Thu, 12 Apr 2012 10:48:04 +0800
-Subject: [PATCH] sysvinit: Fix is_selinux_enabled() for libselinux
-
-is_selinux_enabled()!=1 means SELinux is disabled by kernel
-or SELinux is enabled but policy is not loaded.
-Only at this time, /sbin/init program should call
-selinux_init_load_policy() to detect whether SELinux is enabled
-and to load SELinux policy.
-
-This is fixed already in the upstream sysvinit,
-http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/init.c?root=sysvinit&r1=72&r2=90
----
- src/init.c | 33 +++++++++++++--------------------
- 1 files changed, 13 insertions(+), 20 deletions(-)
-
-diff --git a/src/init.c b/src/init.c
-index 27532ad..75ccf25 100644
---- a/src/init.c
-+++ b/src/init.c
-@@ -54,10 +54,6 @@
-
- #ifdef WITH_SELINUX
- # include <selinux/selinux.h>
--# include <sys/mount.h>
--# ifndef MNT_DETACH /* present in glibc 2.10, missing in 2.7 */
--# define MNT_DETACH 2
--# endif
- #endif
-
- #ifdef __i386__
-@@ -2869,22 +2865,19 @@ int main(int argc, char **argv)
-
- #ifdef WITH_SELINUX
- if (getenv("SELINUX_INIT") == NULL) {
-- const int rc = mount("proc", "/proc", "proc", 0, 0);
-- if (is_selinux_enabled() > 0) {
-- putenv("SELINUX_INIT=YES");
-- if (rc == 0) umount2("/proc", MNT_DETACH);
-- if (selinux_init_load_policy(&enforce) == 0) {
-- execv(myname, argv);
-- } else {
-- if (enforce > 0) {
-- /* SELinux in enforcing mode but load_policy failed */
-- /* At this point, we probably can't open /dev/console, so log() won't work */
-- fprintf(stderr,"Unable to load SELinux Policy. Machine is in enforcing mode. Halting now.\n");
-- exit(1);
-- }
-- }
-- }
-- if (rc == 0) umount2("/proc", MNT_DETACH);
-+ if (is_selinux_enabled() != 1) {
-+ if (selinux_init_load_policy(&enforce) == 0) {
-+ putenv("SELINUX_INIT=YES");
-+ execv(myname, argv);
-+ } else {
-+ if (enforce > 0) {
-+ /* SELinux in enforcing mode but load_policy failed */
-+ /* At this point, we probably can't open /dev/console, so log() won't work */
-+ fprintf(stderr,"Unable to load SELinux Policy. Machine is in enforcing mode. Halting now.\n");
-+ exit(1);
-+ }
-+ }
-+ }
- }
- #endif
- /* Start booting. */
---
-1.7.5.4
-
diff --git a/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend b/recipes-core/sysvinit/sysvinit_2.9%.bbappend
similarity index 64%
rename from recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
rename to recipes-core/sysvinit/sysvinit_2.9%.bbappend
index 9df30b6..4ec2267 100644
--- a/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
+++ b/recipes-core/sysvinit/sysvinit_2.9%.bbappend
@@ -1 +1 @@
-require ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'sysvinit-2.88dsf_selinux.inc', '', d)}
+require ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'sysvinit_selinux.inc', '', d)}
diff --git a/recipes-core/sysvinit/sysvinit-2.88dsf_selinux.inc b/recipes-core/sysvinit/sysvinit_selinux.inc
similarity index 74%
rename from recipes-core/sysvinit/sysvinit-2.88dsf_selinux.inc
rename to recipes-core/sysvinit/sysvinit_selinux.inc
index fcfbdb7..2e54330 100644
--- a/recipes-core/sysvinit/sysvinit-2.88dsf_selinux.inc
+++ b/recipes-core/sysvinit/sysvinit_selinux.inc
@@ -2,8 +2,6 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

B = "${S}"

-SRC_URI += "file://sysvinit-fix-is_selinux_enabled.patch"
-
inherit selinux

DEPENDS += "${LIBSELINUX}"
--
2.21.0


Re: Raspberry pi 4 recipe and layer issues.

Josef Holzmayr <holzmayr@...>
 

On Thu, Dec 12, 2019 at 10:20:03PM +0000, Ed Vidal wrote:
Hi AllAny and all help is appreciated.  Thanks in advance.
I want to install 6 software packages needed for FPGA Development.These are icestorm, arachne-pnr, yosys, nextpnr, verilator, and zipcpu.I have created 4 of the recipes (icestorm_0.1.bb, arachne-pnr_0.1.bb, yosys_0.1.bb, and nextpnr_0.1.bb)using the recipetool & bitbake-layers, and I added these to a meta-yosys-tools layer.
https://github.com/develone/meta-yosys-tools.git
I can now execute "bitbake icestorm" which is a python and C++ Makefile project.The first time the recipe goes thru the python build and gets an error existing the shell.If I rerun "bitbake icestorm" I get 
| iceprog.c:27:10: fatal error: ftdi.h: No such file or directory|    27 | #include <ftdi.h>|       |          ^~~~~~~~Which is the 2nd C++ program in the Makfile.On the rpi4-64 all that is needed are the following steps to build icestorm git clone https://github.com/cliffordwolf/icestorm.git cd icestorm  make real 33m4.774s user 32m39.073s sys 0m19.247s I first tried using the cross compiler with little sucess.  This is why I trying to generate the recipes to build using bitbake instead. These are the location of the header files, needed to be added to the cross compiler sdkwhich I installed for rpi4 using the following commands. "bitbake meta-toolchain" "bitbake core-image-sato -c populate_sdk_ext" "./poky-glibc-x86_64-meta-toolchain-aarch64-raspberrypi4-64-toolchain-3.0.1.sh"
  /usr/include/libftdi1/ftdi.h/usr/include/pcap/usb.h
As root make install which install to /usr/local/bin & /usr/local/share.Creates /usr/local/bin & /usr/local/sharels /usr/local/bin/icebox.py icebox_diff icebox_maps  icebram   iceprogicebox_asc2hlc icebox_explain icebox_stat  icemulti  icetimeicebox_chipdb icebox_hlc2asc icebox_vlog  icepack   iceunpackicebox_colbuf icebox_html iceboxdb.py  icepll
ls /usr/local/share/icebox/chipdb-1k.txt chipdb-lm4k.txt   timings_lp1k.txt   timings_up5k.txtchipdb-384.txt chipdb-u4k.txt   timings_lp384.txtchipdb-5k.txt timings_hx1k.txt  timings_lp8k.txtchipdb-8k.txt timings_hx8k.txt  timings_u4k.txt
When I executed "bitbake nextpnr", I noticed the boost was built first.  Since then I have added boost to rpi4-core-image-sato which added quite a bit to the image2420113408 without boost and 2839543808 with boost.
This sounds all very much like you just need to sort out your
dependencies. If something needs boost, there should be

DEPENDS = "boost"

in the recipe. If smething needs libftdi, there should be

DEPENDS = "libftdi"

and so on, and so on. Randomly adding things to the image does not solve
those issue, for a simple reason: It guarantees that the thing go into
the image. It does *not* guarantee that they are already around when
some random, other recipe is being built.

So, first and foremost - sort out your dependencies.

There is some introductory information here:
https://youtu.be/IehnEC3GOGU

Greetz

--
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


QA notification for completed autobuilder build (yocto-3.1_M1.rc8)

pokybuild@...
 

A build flagged for QA (yocto-3.1_M1.rc8) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1_M1.rc8


Build hash information:

bitbake: 99d46107ccfcec576238d32cfe7903440857038d
meta-gplv2: a67a5fd160f97129a6afd65f107cd2cbdfec41e7
meta-intel: e1b373f3cbb9acd71efe84d782675025d59b6035
meta-mingw: 126efdad243e1a3bead5b695df6656e94353dd46
oecore: 0f04e81c797d5d337ece4e8638a6b71c75bc0a00
poky: 1abffc542a0571f0d1512b92c1a59d138cf3ea6a



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...


Raspberry pi 4 recipe and layer issues.

Ed Vidal
 

Hi All
Any and all help is appreciated.  Thanks in advance.

I want to install 6 software packages needed for FPGA Development.
These are icestorm, arachne-pnr, yosys, nextpnr, verilator, and zipcpu.
I have created 4 of the recipes (icestorm_0.1.bb, arachne-pnr_0.1.bb, yosys_0.1.bb, and nextpnr_0.1.bb)
using the recipetool & bitbake-layers, and I added these to a meta-yosys-tools layer.

https://github.com/develone/meta-yosys-tools.git

I can now execute "bitbake icestorm" which is a python and C++ Makefile project.
The first time the recipe goes thru the python build and gets an error existing the shell.
If I rerun "bitbake icestorm" I get 

| iceprog.c:27:10: fatal error: ftdi.h: No such file or directory
|    27 | #include <ftdi.h>
|       |          ^~~~~~~~
Which is the 2nd C++ program in the Makfile.
On the rpi4-64 all that is needed are the following steps to build icestorm
git clone https://github.com/cliffordwolf/icestorm.git
cd icestorm 
make
real 33m4.774s
user 32m39.073s
sys 0m19.247s
I first tried using the cross compiler with little sucess.  This is why I trying to generate 
the recipes to build using bitbake instead.
These are the location of the header files, needed to be added to the cross compiler sdk
which I installed for rpi4 using the following commands.
"bitbake meta-toolchain"
"bitbake core-image-sato -c populate_sdk_ext"
"./poky-glibc-x86_64-meta-toolchain-aarch64-raspberrypi4-64-toolchain-3.0.1.sh"

  
/usr/include/libftdi1/ftdi.h
/usr/include/pcap/usb.h

As root make install which install to /usr/local/bin & /usr/local/share.
Creates /usr/local/bin & /usr/local/share
ls /usr/local/bin/
icebox.py icebox_diff icebox_maps  icebram   iceprog
icebox_asc2hlc icebox_explain icebox_stat  icemulti  icetime
icebox_chipdb icebox_hlc2asc icebox_vlog  icepack   iceunpack
icebox_colbuf icebox_html iceboxdb.py  icepll

ls /usr/local/share/icebox/
chipdb-1k.txt chipdb-lm4k.txt   timings_lp1k.txt   timings_up5k.txt
chipdb-384.txt chipdb-u4k.txt   timings_lp384.txt
chipdb-5k.txt timings_hx1k.txt  timings_lp8k.txt
chipdb-8k.txt timings_hx8k.txt  timings_u4k.txt

When I executed "bitbake nextpnr", I noticed the boost was built first.  Since then 
I have added boost to rpi4-core-image-sato which added quite a bit to the image
2420113408 without boost and 2839543808 with boost.

Let me know if I can provide additional information.

Best Regards


Edward Vidal Jr. e-mail develone@... 915-595-1613


Re: meta-intel stuck on bootup #yocto

Dan O'Donovan
 

If you are using the meta-intel layer, you could also change your MACHINE to 'intel-corei7-64' instead of 'genericx86-64'.  I'm not sure if it will fix your specific issue but it will at least allow you to benefit from some of the additional features and patches and other tweaks that the meta-intel layer provides.


[meta-zephyr][PATCH 2/2] zephy-kernel-test: update the testcase list for x86

Naveen Saini
 

Updated the test recipes to build against Zephyr v2.0
Code clean up

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
classes/zephyrtest.bbclass | 2 +-
recipes-kernel/zephyr-kernel/zephyr-image.inc | 9 +-
.../zephyr-kernel/zephyr-kernel-test-all.bb | 1 -
.../zephyr-kernel/zephyr-kernel-test.inc | 89 ++++++++++---------
4 files changed, 53 insertions(+), 48 deletions(-)

diff --git a/classes/zephyrtest.bbclass b/classes/zephyrtest.bbclass
index 8a051db..3acc4c3 100644
--- a/classes/zephyrtest.bbclass
+++ b/classes/zephyrtest.bbclass
@@ -14,7 +14,7 @@ python zephyrtest_virtclass_handler () {
e.data.setVar("ZEPHYR_IMAGENAME", pn + ".elf")

# Most tests for Zephyr 1.6 are in the "legacy" folder
- e.data.setVar("ZEPHYR_IMAGE_SRCDIR", "tests/legacy/kernel/" + variant)
+ e.data.setVar("ZEPHYR_SRC_DIR", "tests/kernel/" + variant)
e.data.setVar("ZEPHYR_MAKE_OUTPUT", "zephyr.elf")

# Allow to build using both foo-some_test form as well as foo-some-test
diff --git a/recipes-kernel/zephyr-kernel/zephyr-image.inc b/recipes-kernel/zephyr-kernel/zephyr-image.inc
index cf57dbf..e8b8871 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-image.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-image.inc
@@ -7,14 +7,11 @@ inherit deploy
QEMU_BIN_PATH = "${STAGING_BINDIR_NATIVE}"

ZEPHYR_BASE = "${S}"
-
-do_compile () {
- cd ${S}
- oe_runmake ${ZEPHYR_MAKE_ARGS} -C ${ZEPHYR_IMAGE_SRCDIR}
-}
+OECMAKE_SOURCEPATH = "${S}/${ZEPHYR_SRC_DIR}"

do_deploy () {
- install -D ${ZEPHYR_IMAGE_SRCDIR}/outdir/${BOARD}/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${ZEPHYR_IMAGENAME}
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${ZEPHYR_IMAGENAME}
}

addtask deploy after do_compile
+do_install[noexec] = "1"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test-all.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-test-all.bb
index c45124a..85efd24 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test-all.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test-all.bb
@@ -4,7 +4,6 @@ INHIBIT_DEFAULT_DEPS = "1"
require zephyr-kernel-test.inc

addtask testimage
-deltask configure
deltask compile
deltask install

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
index 6e96ae2..d7572ef 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
@@ -1,52 +1,61 @@
+ZEPHYRTESTS_remove = "fifo fp_sharing lifo mbox mem_heap mem_pool \
+ mem_protect mem_slab msgq mutex pipe profiling sched semaphore \
+ stack threads tickless timer workq"
+
+
+# Exclude tests which does not build for various reasons
+ZEPHYRTESTS_remove = "gen_isr_table spinlock smp mp"

-ZEPHYRTESTS_remove = "test_static_idt test_fifo test_fp_sharing \
- test_sema test_stackprot test_obj_tracing test_stack \
- test_tickless test_timer"

# test_context will fail because QEMU for ARM does not emulate CortexM3 BASEPRI register
-ZEPHYRTESTS_remove_arm += "test_context"
+#ZEPHYRTESTS_remove_arm += ""

# test_critical never finishes in an unpatched QEMU either
-ZEPHYRTESTS_remove_arm += "test_critical"
+#ZEPHYRTESTS_remove_arm += ""

#Remove ARM specific tests
-ZEPHYRTESTS_remove_x86 += "test_context test_arm_irq_vector_table"
+#ZEPHYRTESTS_remove_x86 += ""

#Remove tests not intended for Nios2
-ZEPHYRTESTS_remove_nios2 += "test_context test_mem_safe"
+#ZEPHYRTESTS_remove_nios2 += ""

-# List of all available tests
+# List of all available kernel tests
ZEPHYRTESTS = " \
- test_context \
- test_critical \
- test_early_sleep \
- test_errno \
- test_events \
- test_fifo \
- test_fifo_priv \
- test_fp_sharing \
- test_libs \
- test_lifo \
- test_mail \
- test_mail_priv \
- test_map \
- test_map_priv \
- test_mem_safe \
- test_mutex \
- test_nano_work \
- test_obj_tracing \
- test_pend \
- test_pipe \
- test_pipe_priv \
- test_pool \
- test_sema \
- test_sema_priv \
- test_sleep \
- test_stack \
- test_stackprot \
- test_static_idt \
- test_task \
- test_task_priv \
- test_tickless \
- test_timer \
+ boot_page_table \
+ common \
+ context \
+ critical \
+ device \
+ early_sleep \
+ fatal \
+ fifo \
+ fp_sharing \
+ gen_isr_table \
+ interrupt \
+ lifo \
+ mbox \
+ mem_heap \
+ mem_pool \
+ mem_protect \
+ mem_slab \
+ mp \
+ msgq \
+ mutex \
+ obj_tracing \
+ pending \
+ pipe \
+ poll \
+ profiling \
+ queue \
+ sched \
+ semaphore \
+ sleep \
+ smp \
+ spinlock \
+ stack \
+ threads \
+ tickless \
+ timer \
+ workq \
+ xip \
"
--
2.17.1


[meta-zephyr][PATCH 1/2] zephyr.conf: Enable uninative

Naveen Saini
 

Use uninative by default to allow to build multiple distro
and re-use sstate cache

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/distro/zephyr.conf | 2 ++
1 file changed, 2 insertions(+)

diff --git a/conf/distro/zephyr.conf b/conf/distro/zephyr.conf
index 580ae2a..673152f 100644
--- a/conf/distro/zephyr.conf
+++ b/conf/distro/zephyr.conf
@@ -14,3 +14,5 @@ TEST_SUITES = "zephyr"
TOOLCHAIN_TARGET_TASK += " newlib"
INHERIT += "siteinfo-zephyr"

+INHERIT += "uninative"
+require conf/distro/include/yocto-uninative.inc
--
2.17.1


Re: Build issue - newbie

Morne
 

Please let me know how to check YP version.
In the directory that you checked out the git repo, open the following file:

poky/meta-poky/conf/distro/poky.conf

At the top of the file it will show DISTRO_VERSION and DISTRO_CODENAME

I suspect that you are using different branches of the git repo in the instance where it works, and the instance where it doesn't work.

- Morné


Re: Build issue - newbie

Sujoy Ray
 

Please let me know how to check YP version.


Re: Build issue - newbie

Sujoy Ray
 

I have used the steps described in https://github.com/openbmc/openbmc.
This works in native Ubuntu installation. But fails under VMWare.


Re: Build issue - newbie

Morne
 

ERROR: Layer microsoft-layer is not compatible with the core layer which only supports these series: zeus (layer is compatible with warrior)

The above error happens when I run bitbake obmc-phosphor-image in Ubuntu 16.04 running in VMwarer ( Windows 10 as HOST).
The above command succeeds when I use Ubuntu native installation.
What YP version are you using ?

Can you verify that you are using the same YP version in both cases ?

- Morné


Re: Build issue - newbie

Khem Raj
 

On 12/11/19 9:59 PM, Sujoy Ray wrote:
Hello,
I am trying to build yocto project and having following error:
==========================
ERROR: Unable to start bitbake server (None)
ERROR: Server log for this session (/home/sujoy/OpenBMC/openbmc/build/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 2104 at 2019-12-11 19:23:03.474760 ---
ERROR: Layer microsoft-layer is not compatible with the core layer which only supports these series: zeus (layer is compatible with warrior)
=============================================
The above error happens when I run /bitbake obmc-phosphor-image/ in Ubuntu 16.04 running in VMwarer ( Windows 10 as HOST).
The above command succeeds when I use Ubuntu native installation.
Could anybody please help?
it seems your project has mixed releases of different layers. So please describe how you setup your project. Usually you should be using same release/branch for all layers, unless a layer states otherwise

Thanks,
Sujoy.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#47646): https://lists.yoctoproject.org/g/yocto/message/47646
Mute This Topic: https://lists.yoctoproject.org/mt/68263780/1997914
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [raj.khem@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [meta-rockchip][PATCH] rk3288: Convert to using wic

Trevor Woerner
 

Super awesome! Applied, thanks :-)


Build issue - newbie

Sujoy Ray
 

Hello,
I am trying to build yocto project and having following error:
==========================
ERROR: Unable to start bitbake server (None)
ERROR: Server log for this session (/home/sujoy/OpenBMC/openbmc/build/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 2104 at 2019-12-11 19:23:03.474760 ---
ERROR: Layer microsoft-layer is not compatible with the core layer which only supports these series: zeus (layer is compatible with warrior)
=============================================
 
The above error happens when I run bitbake obmc-phosphor-image in Ubuntu 16.04 running in VMwarer ( Windows 10 as HOST).
 
The above command succeeds when I use Ubuntu native installation. 

Could anybody please help?
Thanks,
Sujoy.


[meta-rockchip][PATCH] rk3288: Convert to using wic

Joshua Watt
 

Coverts the firefly-rk3288, tinker-rk3288, and vyasa-rk3288 machines to
use wic instead of the rockchip-gpt-img class. The rock2-squared machine
has to keep the older image class because u-boot doesn't provided a
combined idbloader for it.

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine/firefly-rk3288.conf | 15 ++++++++++++++-
conf/machine/include/rk3288.inc | 2 --
conf/machine/rock2-square.conf | 6 ++++++
conf/machine/tinker-rk3288.conf | 15 ++++++++++++++-
conf/machine/vyasa-rk3288.conf | 14 ++++++++++++++
wic/firefly-rk3288.wks | 26 ++++++++++++++++++++++++++
wic/tinker-rk3288.wks | 26 ++++++++++++++++++++++++++
wic/vyasa-rk3288.wks | 27 +++++++++++++++++++++++++++
8 files changed, 127 insertions(+), 4 deletions(-)
create mode 100644 wic/firefly-rk3288.wks
create mode 100644 wic/tinker-rk3288.wks
create mode 100644 wic/vyasa-rk3288.wks

diff --git a/conf/machine/firefly-rk3288.conf b/conf/machine/firefly-rk3288.conf
index 0900440..71e0bc3 100644
--- a/conf/machine/firefly-rk3288.conf
+++ b/conf/machine/firefly-rk3288.conf
@@ -10,4 +10,17 @@ require conf/machine/include/rk3288.inc

KERNEL_DEVICETREE = "rk3288-firefly.dtb"
UBOOT_MACHINE = "firefly-rk3288_defconfig"
-GPTIMG_APPEND = "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
+
+WKS_FILE = "firefly-rk3288.wks"
+IMAGE_FSTYPES += "wic"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ ${KERNEL_DEVICETREE} \
+ "
diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index 6e9a09a..b261692 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -12,5 +12,3 @@ SERIAL_CONSOLES = "115200;ttyS2"
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
SPL_BINARY ?= "idbloader.img"

-IMAGE_FSTYPES += "rockchip-gpt-img"
-IMAGE_CLASSES += "rockchip-gpt-img"
diff --git a/conf/machine/rock2-square.conf b/conf/machine/rock2-square.conf
index 737d3ae..46064ee 100644
--- a/conf/machine/rock2-square.conf
+++ b/conf/machine/rock2-square.conf
@@ -11,3 +11,9 @@ require conf/machine/include/rk3288.inc
SPL_BINARY = "u-boot-spl-dtb.bin"
KERNEL_DEVICETREE = "rk3288-rock2-square.dtb"
UBOOT_MACHINE = "rock2_defconfig"
+
+# This board doesn't support the combined idbloader, so resort to the older
+# image class
+IMAGE_FSTYPES += "rockchip-gpt-img"
+IMAGE_CLASSES += "rockchip-gpt-img"
+
diff --git a/conf/machine/tinker-rk3288.conf b/conf/machine/tinker-rk3288.conf
index 9e23f8d..e460d43 100644
--- a/conf/machine/tinker-rk3288.conf
+++ b/conf/machine/tinker-rk3288.conf
@@ -9,4 +9,17 @@ require conf/machine/include/rk3288.inc

KERNEL_DEVICETREE = "rk3288-tinker.dtb"
UBOOT_MACHINE = "tinker-rk3288_defconfig"
-GPTIMG_APPEND = "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
+
+WKS_FILE = "tinker-rk3288.wks"
+IMAGE_FSTYPES += "wic"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ ${KERNEL_DEVICETREE} \
+ "
diff --git a/conf/machine/vyasa-rk3288.conf b/conf/machine/vyasa-rk3288.conf
index bfbd09b..03a436a 100644
--- a/conf/machine/vyasa-rk3288.conf
+++ b/conf/machine/vyasa-rk3288.conf
@@ -12,3 +12,17 @@ KERNEL_DEVICETREE = "rk3288-vyasa.dtb"
KERNEL_EXTRA_ARGS += "LOADADDR=0x02000000"

UBOOT_MACHINE = "vyasa-rk3288_defconfig"
+
+WKS_FILE = "vyasa-rk3288.wks"
+IMAGE_FSTYPES += "wic"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ ${KERNEL_DEVICETREE} \
+ "
diff --git a/wic/firefly-rk3288.wks b/wic/firefly-rk3288.wks
new file mode 100644
index 0000000..5013aea
--- /dev/null
+++ b/wic/firefly-rk3288.wks
@@ -0,0 +1,26 @@
+# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 -
+#
+
+part loader1 --ondisk mmcblk0 --align 32 --size 4000K --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --ondisk mmcblk0 --align 4032 --size 64K
+part reserved2 --ondisk mmcblk0 --align 4096 --size 4096K
+part loader2 --ondisk mmcblk0 --align 8192 --size 4096K --source rawcopy --sourceparams="file=u-boot.bin"
+part atf --ondisk mmcblk0 --align 12288 --size 4096K
+part /boot --ondisk mmcblk0 --align 16384 --size=114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
+part / --ondisk mmcblk0 --align 131072 --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/tinker-rk3288.wks b/wic/tinker-rk3288.wks
new file mode 100644
index 0000000..5013aea
--- /dev/null
+++ b/wic/tinker-rk3288.wks
@@ -0,0 +1,26 @@
+# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 -
+#
+
+part loader1 --ondisk mmcblk0 --align 32 --size 4000K --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --ondisk mmcblk0 --align 4032 --size 64K
+part reserved2 --ondisk mmcblk0 --align 4096 --size 4096K
+part loader2 --ondisk mmcblk0 --align 8192 --size 4096K --source rawcopy --sourceparams="file=u-boot.bin"
+part atf --ondisk mmcblk0 --align 12288 --size 4096K
+part /boot --ondisk mmcblk0 --align 16384 --size=114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
+part / --ondisk mmcblk0 --align 131072 --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/vyasa-rk3288.wks b/wic/vyasa-rk3288.wks
new file mode 100644
index 0000000..3fc9a5b
--- /dev/null
+++ b/wic/vyasa-rk3288.wks
@@ -0,0 +1,27 @@
+# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 -
+#
+
+part loader1 --ondisk mmcblk2 --align 32 --size 4000K --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --ondisk mmcblk2 --align 4032 --size 64K
+part reserved2 --ondisk mmcblk2 --align 4096 --size 4096K
+part loader2 --ondisk mmcblk2 --align 8192 --size 4096K --source rawcopy --sourceparams="file=u-boot.bin"
+part atf --ondisk mmcblk2 --align 12288 --size 4096K
+part /boot --ondisk mmcblk2 --align 16384 --size=114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
+part / --ondisk mmcblk2 --align 131072 --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk2p7 rootfstype=ext4 init=/sbin/init"
+
--
2.23.0

9721 - 9740 of 57384