Build Yocto with recent EVerest release #76

shankari · 2024-10-15T18:46:24Z

We can use the release from end of september
We want to have a reproducible process to build yocto images that any of us can run (ideally in a docker container or with a script)
We want to run this yocto image on a raspberry Pi

catarial · 2024-10-17T17:58:55Z

I've successfully built the 'core-image-sato' yocto image as described in the yocto project quick build.

https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html

I used a Debian 12 VM with 4 threads and 8GB of RAM. It took ~12 hours with no downloaded substitutes.

I'm currently working on trying to run the image in a VM outside of the build environment. It looks like right now that Yocto only supports virtualization with QEMU. I think they used to support Virtualbox as suggested by this post I found, but it failed when I tried the config it suggested.

QEMU supports converting images with qemu-img convert. I'm going to investigate the runqemu script that Yocto provides and try to get it converted to a Virtualbox image.

shankari · 2024-10-17T18:03:34Z

There is also a mac version of QEMU (https://wiki.qemu.org/Hosts/Mac). I am 99% sure that the android emulator is built on qemu. I remember seeing that in a menu item or process name, at least in an earlier version of the emulator.

catarial · 2024-10-17T18:13:23Z

There is also a mac version of QEMU (https://wiki.qemu.org/Hosts/Mac). I am 99% sure that the android emulator is built on qemu. I remember seeing that in a menu item or process name, at least in an earlier version of the emulator.

Yes, that's correct. I'm looking into Virtualbox so that we can also test on windows.

shankari · 2024-10-17T18:21:00Z

There is also a qemu for windows?! Note that the android emulator also has an android version. It is only iOS that needs xcode.

https://www.qemu.org/download/

catarial · 2024-10-17T18:25:13Z

Oh, I wasn't aware of that. I'll look into just qemu for now.

catarial · 2024-10-18T18:44:08Z

runqemu qemux86-64 = /home/aria/src/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0/recipe-sysroot-native/usr/bin/qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -drive file=/home/aria/src/poky/build/tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64.rootfs-20241018133209.ext4,if=virtio,format=raw -usb -device usb-tablet -usb -device usb-kbd -cpu IvyBridge -machine q35,i8042=off -smp 4 -m 512 -serial mon:vc -serial null -device virtio-vga -display sdl,show-cursor=on -kernel /home/aria/src/poky/build/tmp/deploy/images/qemux86-64/bzImage -append 'root=/dev/vda rw ip=192.168.7.2::192.168.7.1:255.255.255.0::eth0:off:8.8.8.8 net.ifnames=0 oprofile.timer=1 tsc=reliable no_timer_check rcupdate.rcu_expedited=1 swiotlb=0 '

catarial · 2024-10-18T19:02:55Z

Following this guide to setup yocto dev environment on Mac.

https://github.com/crops/docker-win-mac-docs/wiki/Mac-Instructions

shankari · 2024-10-18T19:49:46Z

Did the runqemu work?

catarial · 2024-10-18T20:00:46Z

Did the runqemu work?

Yes I built yocto on Debian outside of a VM and it worked.

Currently testing building on a Mac

shankari · 2024-10-18T20:48:35Z

Was it faster outside of the VM?
You should record time for each step as you go along.

catarial · 2024-10-21T13:44:34Z

Was it faster outside of the VM? You should record time for each step as you go along.

Yes, it was faster. This time I actually did record the time for it, it was 301 min, ~5 hours.

catarial · 2024-10-21T16:47:14Z

Building a core image for the orangepi zero2

git clone git://git.yoctoproject.org/poky
cd poky
git checkout styhead

meta-sunxi requires the styhead branch

Add required layers for orangepi zero2:

The meta-sunxi layer provides board support packages for Allwinner based boards. It depends on meta-oe, meta-python, and meta-arm

CWD: poky

git clone https://git.openembedded.org/meta-openembedded/
git clone https://git.yoctoproject.org/meta-arm
git clone https://github.com/linux-sunxi/meta-sunxi
source oe-init-build-env

CWD: poky/build - init script changes directory to build

bitbake-layers add-layer ../meta-arm/meta-arm-toolchain
bitbake-layers add-layer ../meta-arm/meta-arm
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-openembedded/meta-python
bitbake-layers add-layer ../meta-sunxi

Edit `conf/local.conf`

Machines added by meta-sunxi

ls ../meta-sunxi/conf/machine
bananapi.conf
bananapi-m2m.conf
bananapi-m2plus.conf
bananapi-m2-zero.conf
bananapi-m64.conf
cubieboard2.conf
cubieboard.conf
cubietruck.conf
forfun-q88db.conf
include
lamobo-r1.conf
licheepi-zero.conf
mangopi-mq-t-t113.conf
marsboard-a10.conf
mele.conf
meleg.conf
nanopi-m1.conf
nanopi-m1-plus.conf
nanopi-neo2.conf
nanopi-neo-air.conf
nanopi-neo.conf
nanopi-neo-plus2.conf
nanopi-r1.conf
olinuxino-a10lime.conf
olinuxino-a10s.conf
olinuxino-a13.conf
olinuxino-a13som.conf
olinuxino-a20.conf
olinuxino-a20lime2.conf
olinuxino-a20lime2-emmc.conf
olinuxino-a20lime.conf
olinuxino-a20som.conf
olinuxino-a64.conf
orange-pi-3lts.conf
orange-pi-lite.conf
orange-pi-one.conf
orange-pi-one-plus.conf
orange-pi-pc2.conf
orange-pi-pc.conf
orange-pi-pc-plus.conf
orange-pi-prime.conf
orange-pi-r1.conf
orange-pi-zero2.conf
orange-pi-zero.conf
orange-pi-zero-plus2.conf
orange-pi-zero-plus2-h3.conf
pcduino3.conf
pcduino.conf
pine64-plus.conf

Add or replace existing value MACHINE ??= "orange-pi-zero2" to build/conf/local.conf

Build your image

Mesa recipes in meta-sunxi cause an error.

ERROR: No recipes in default available for:
    poky/meta-sunxi/recipes-graphics/mesa/mesa-gl_%.bbappend
    poky/meta-sunxi/recipes-graphics/mesa/mesa_%.bbappend

We won't need graphics for the image we're building so I'm just going to remove these.

rm ../meta-sunxi/recipes-graphics/mesa/*

Start the build:

bitbake core-image-full-cmdline

catarial · 2024-10-21T17:14:26Z

Building core-image-full-cmdline for my orangepi-zero2 on my Debian 12 laptop took ~2 hours

aria@cocoa:~/src/poky/build$ time bitbake core-image-full-cmdline
Loading cache: 100% |######################################################################| Time: 0:00:00
Loaded 4523 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "2.9.1"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "orange-pi-zero2"
DISTRO               = "poky"
DISTRO_VERSION       = "5.1"
TUNE_FEATURES        = "aarch64 crc cortexa53 crypto"
TARGET_FPU           = ""
meta                 
meta-poky            
meta-yocto-bsp       = "styhead:86bc5dca182a3fe774e17811a82177a68b27a6bb"
meta-oe              
meta-python          = "master:ce0975675f6ee7fcb4cc6322fc9f65b981e7b2e2"
meta-arm-toolchain   
meta-arm             = "master:e161d8aefbdad732bebdfabc05503e8631241600"
meta-sunxi           = "master:0825f43fe225a8867083228fdc5e2dff4fc50800"

Sstate summary: Wanted 2776 Local 0 Mirrors 0 Missed 2776 Current 0 (0% match, 0% complete)| ETA:  0:00:00
Removing 344 stale sstate objects for arch x86_64: 100% |##################################| Time: 0:00:00
Removing 29 stale sstate objects for arch allarch: 100% |##################################| Time: 0:00:00
NOTE: Executing Tasks
NOTE: Tasks Summary: Attempted 5664 tasks of which 0 didn't need to be rerun and all succeeded.

real	134m22.029s
user	0m26.532s
sys	0m4.966s

catarial · 2024-10-21T17:17:40Z

Output of the orangepi build:

ls -w 1 tmp/deploy/images/orange-pi-zero2/
allwinner
bl31.bin
bl31.elf
bl31-sun50i_h616.bin
bl31-sun50i_h616.elf
boot-orange-pi-zero2-2024.07-r0.scr
boot-orange-pi-zero2.scr
boot.scr
core-image-full-cmdline.env
core-image-full-cmdline-orange-pi-zero2.rootfs-20241021145731.ext4
core-image-full-cmdline-orange-pi-zero2.rootfs-20241021145731.manifest
core-image-full-cmdline-orange-pi-zero2.rootfs-20241021145731.spdx.json
core-image-full-cmdline-orange-pi-zero2.rootfs-20241021145731.tar.gz
core-image-full-cmdline-orange-pi-zero2.rootfs-20241021145731.testdata.json
core-image-full-cmdline-orange-pi-zero2.rootfs-20241021145731.wic.bmap
core-image-full-cmdline-orange-pi-zero2.rootfs-20241021145731.wic.gz
core-image-full-cmdline-orange-pi-zero2.rootfs.ext4
core-image-full-cmdline-orange-pi-zero2.rootfs.manifest
core-image-full-cmdline-orange-pi-zero2.rootfs.spdx.json
core-image-full-cmdline-orange-pi-zero2.rootfs.tar.gz
core-image-full-cmdline-orange-pi-zero2.rootfs.testdata.json
core-image-full-cmdline-orange-pi-zero2.rootfs.wic.bmap
core-image-full-cmdline-orange-pi-zero2.rootfs.wic.gz
core-image-full-cmdline-sunxi-sdcard-image.wks
Image
Image--6.6.28-r0-orange-pi-zero2-20241021145731.bin
Image-orange-pi-zero2.bin
modules--6.6.28-r0-orange-pi-zero2-20241021145731.tgz
modules-orange-pi-zero2.tgz
sun50i-h616-orangepi-zero2--6.6.28-r0-orange-pi-zero2-20241021145731.dtb
sun50i-h616-orangepi-zero2.dtb
sun50i-h616-orangepi-zero2-orange-pi-zero2.dtb
u-boot.bin
u-boot-initial-env
u-boot-initial-env-orange-pi-zero2
u-boot-initial-env-orange-pi-zero2-2024.07-r0
u-boot-orange-pi-zero2-2024.07-r0.bin
u-boot-orange-pi-zero2.bin
u-boot-sunxi-with-spl.bin
u-boot-sunxi-with-spl.bin-orange-pi-zero2
u-boot-sunxi-with-spl.bin-orange-pi-zero2-2024.07-r0

Need to figure out what to do with these files

catarial · 2024-10-21T17:57:50Z

Successful orangepi build on Mac

It got to 50% in 30 minutes and then failed with an error. After I fixed the error it took about another 30 minutes so total time was an hour.

How to build Yocto on Mac

If you your using an older amd64 Mac you can follow this guide, otherwise use this one

Once you have your build container up you need to enter the root shell on it to install some packages and run locale-gen

# Use docker ps to get crops/poky:selfbuilt container id
docker ps
docker exec -it --user=root <container-id> bash
# required packages from https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html
apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 python3-subunit zstd liblz4-tool file locales libacl1
locale-gen en_US.UTF-8

Then go back to your user shell and it should be ready to build an image. See #76 (comment) for how to build an image.

VPN Issues

I had some connection issues while building the docker containers and building yocto while I was connected to the NREL VPN. I just disconnected from the VPN temporarily to get around it. I'm not sure if that's going to be an issue for people who are on site at NREL.

catarial · 2024-10-21T20:21:02Z

Contents of core-image-full-cmdline-sunxi-sdcard-image.wks provide details on preparing an sd card to boot yocto

# short-description: Create SD card image with a boot partition
# long-description:
# Create an image that can be written onto a SD card using dd for use
# with Allwinner arm (32-bit) SoC family
#
# The disk layout used is:
#  - --------------------------- -------------- --------------
# | | u-boot-sunxi-with-spl.bin |     boot     |    rootfs    |
#  - --------------------------- -------------- --------------
# ^ ^                           ^              ^              ^
# | |                           |              |              |
# 0 |                         2MiB  40MiB  40MiB + rootfs + IMAGE_EXTRA_SPACE
#   8KiB 
#

part u-boot --source rawcopy --sourceparams="file=u-boot-sunxi-with-spl.bin" --ondisk mmcblk0 --no-table --align 8
part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 2048 --fixed-size 40
part /     --source rootfs --ondisk mmcblk0 --fstype=ext4 --align 2048

catarial · 2024-10-21T20:26:43Z

Not sure what the part command is it's not in the yocto environment or on my debian system

catarial · 2024-10-21T20:31:09Z

This seems to clarify things

https://linux-sunxi.org/Bootable_SD_card#Partitioning

I don't think part is an actual utility, I think it's just describing how the partitions should be setup

catarial · 2024-10-22T18:55:58Z

I'm running into issues building certain images on Mac. The orange pi image built fine, but when I try to build a qemu image it fails. I'm hoping it's something to do with the build environment and not a problem with MacOS or Docker.

| /usr/src/debug/gcc/13.3.0/gcc/rtl-ssa/changes.cc:840:(.text+0x270): undefined reference to `add_clobbers(rtx_def*, int)'
| collect2: error: ld returned 1 exit status
| make[1]: *** [../../../../../../../work-shared/gcc-13.3.0-r0/gcc-13.3.0/gcc/c/Make-lang.in:87: cc1] Error 1
| make[1]: *** Waiting for unfinished jobs....
| collect2: error: ld returned 1 exit status
| make[1]: *** [../../../../../../../work-shared/gcc-13.3.0-r0/gcc-13.3.0/gcc/cp/Make-lang.in:145: cc1plus] Error 1
| make[1]: Leaving directory '/workdir/poky/build/tmp/work/cortexa57-poky-linux/gcc/13.3.0/gcc-13.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc'
| make: *** [Makefile:4627: all-gcc] Error 2
| ERROR: oe_runmake failed
| WARNING: /workdir/poky/build/tmp/work/cortexa57-poky-linux/gcc/13.3.0/temp/run.do_compile.95994:194 exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
| 	#1: bbfatal_log, /workdir/poky/build/tmp/work/cortexa57-poky-linux/gcc/13.3.0/temp/run.do_compile.95994, line 194
| 	#2: die, /workdir/poky/build/tmp/work/cortexa57-poky-linux/gcc/13.3.0/temp/run.do_compile.95994, line 178
| 	#3: oe_runmake, /workdir/poky/build/tmp/work/cortexa57-poky-linux/gcc/13.3.0/temp/run.do_compile.95994, line 173
| 	#4: do_compile, /workdir/poky/build/tmp/work/cortexa57-poky-linux/gcc/13.3.0/temp/run.do_compile.95994, line 168
| 	#5: main, /workdir/poky/build/tmp/work/cortexa57-poky-linux/gcc/13.3.0/temp/run.do_compile.95994, line 207
ERROR: Task (/workdir/poky/meta/recipes-devtools/gcc/gcc_13.3.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 5706 tasks of which 5655 didn't need to be rerun and 1 failed.

catarial · 2024-10-23T15:03:46Z

Adding everest to a core image

Add this line to build/conf/local.conf

CORE_IMAGE_EXTRA_INSTALL += "everest-core"

Switch to kirkstone branch since that's what everest supports right now

Setup layers:

cd poky
git clone https://git.openembedded.org/meta-openembedded
git clone https://github.com/EVerest/meta-everest.git
cd meta-openembedded
git checkout kirkstone
cd ../meta-everest
git checkout release/kirkstone/2024.9.0-rc3
cd ../
source oe-init-build-env
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-openembedded/meta-python
bitbake-layers add-layer ../meta-openembedded/meta-networking
bitbake-layers add-layer ../meta-everest

Then start the build for your image.

If you run into an issue where elfutils fails to build do to deprecated functions, you can apply a patch that disables the -Werror flag.

Contents of meta/recipes-devtools/elfutils/elfutils_0.186.bb

SRC_URI = "https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
           file://0001-dso-link-change.patch \
           file://0002-Fix-elf_cvt_gunhash-if-dest-and-src-are-same.patch \
           file://0003-fixheadercheck.patch \
           file://0006-Fix-build-on-aarch64-musl.patch \
           file://0001-libasm-may-link-with-libbz2-if-found.patch \
           file://0001-libelf-elf_end.c-check-data_list.data.d.d_buf-before.patch \
           file://0001-skip-the-test-when-gcc-not-deployed.patch \
           file://run-ptest \
           file://ptest.patch \
           file://0001-tests-Makefile.am-compile-test_nlist-with-standard-C.patch \
           file://0001-debuginfod-fix-compilation-on-platforms-without-erro.patch \
           file://0001-debuginfod-debuginfod-client.c-use-long-for-cache-ti.patch \
           "
SRC_URI:append:libc-musl = " \
           file://0003-musl-utils.patch \
           file://0015-config-eu.am-do-not-use-Werror.patch \
           "

Move file://0015-config-eu.am-do-not-use-Werror.patch into the main patches section like so

SRC_URI = "https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
           file://0001-dso-link-change.patch \
           file://0002-Fix-elf_cvt_gunhash-if-dest-and-src-are-same.patch \
           file://0003-fixheadercheck.patch \
           file://0006-Fix-build-on-aarch64-musl.patch \
           file://0001-libasm-may-link-with-libbz2-if-found.patch \
           file://0001-libelf-elf_end.c-check-data_list.data.d.d_buf-before.patch \
           file://0001-skip-the-test-when-gcc-not-deployed.patch \
           file://run-ptest \
           file://ptest.patch \
           file://0001-tests-Makefile.am-compile-test_nlist-with-standard-C.patch \
           file://0001-debuginfod-fix-compilation-on-platforms-without-erro.patch \
           file://0001-debuginfod-debuginfod-client.c-use-long-for-cache-ti.patch \
           file://0015-config-eu.am-do-not-use-Werror.patch \
           "
SRC_URI:append:libc-musl = " \
           file://0003-musl-utils.patch \
           "

catarial · 2024-10-23T16:31:33Z

I started the qemu image and everest wasnt running. It appears everest provides a systemd service, so I'm going to try enabling systemd and seeing what happens after.

I added this to the config to enable systemd.

DISTRO_FEATURES:append = " systemd usrmerge"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

catarial · 2024-10-23T16:40:05Z

Some clarification on the dependencies everest-core pulls in:

@shankari you asked if everest-core contains node-red.

Opening the bitbake file for everest-core, meta-everest/recipes-core/everest/everest-core_2024.9.0-rc3.bb, we can see its dependencies.

inherit cmake pkgconfig systemd python3native

DEPENDS = " \
    everest-cmake \
    boost \
    sigslot \
    pugixml \
    libpcap \
    evcli-native \
    rsync-native \
    nodejs-native \
    everest-framework \
    libocpp \
    libfsm \
    liblog \
    everest-libmodbus \
    libslac \
    libevent \
    libevse-security \
    libcbv2g \
    curl \
    sqlitecpp \
"

It does include nodejs, I'm not sure why.

And then everest-framework depends on these packages.


DEPENDS = "\
    everest-cmake \
    boost \
    websocketpp \
    nlohmann-json \
    json-schema-validator \
    mqttc \
    liblog \
    fmt \
    date \
    catch2 \
    nodejs-native \
    rapidyaml \
    libwebsockets \
    python3-pybind11 \
    python3-pybind11-json \
    libcap \
"

So I don't believe node red is being pulled in. You would have to add it explicitly by adding CORE_IMAGE_EXTRA_INSTALL += "everest-node-red-flows" to the build config

shankari · 2024-10-23T17:14:44Z

Interesting. After the CharIN demo, I think it would be helpful to try both options:

minimal/production: strip out all the extraneous stuff (nodejs/python)
maximal/demo: put in everything + node-red-flows

But for now, we are just going to get this working....

catarial · 2024-10-23T18:19:29Z

everest fails to start, I believe because there's no config file

catarial · 2024-10-23T18:24:42Z

It also depends on mosquitto which is not brought in by everest-core so that will have to be added to the config

CORE_IMAGE_EXTRA_INSTALL += "mosquitto"

then rebuild the image

catarial · 2024-10-23T18:33:28Z

Now that mosquitto installed we can use the example config to startup everest.

cd /etc/everest
cp config-example.yaml config.yaml
systemctl start everest

And then we see that it started successfully

catarial · 2024-10-23T18:34:32Z

@shankari Is there any specific testing you want me to do now that I have this running?

shankari · 2024-11-08T17:22:50Z

The firmware that was flashed most recently is from June 2024, so let's call it the 2024.06 firmware.
I am just curious because from this
#76 (comment)
it looks like there were issues with the BSP initialized with the 2024.06 firmware

What changed?

Abby-Wheelis · 2024-11-08T18:20:46Z

I am just curious because from this
#76 (comment)
it looks like there were issues with the BSP initialized with the 2024.06 firmware

Ah, "yet" turned out to be the key word in that log message, it got initialized/"enabled" shortly after that log, which @ed-watt pointed out and I think @catarial confirmed by adding log statements.

shankari · 2024-11-11T00:26:15Z

@catarial has figured this out, but it requires a Linux machine. Will close after we have a setup that allows others (namely me) to build as well. ETA this week.

catarial · 2024-11-15T21:16:40Z

Running into issues where nodejs requires QEMU to cross compile and it seems like I don't have the proper permissions to run QEMU on NREL's HPC.

shankari · 2024-11-15T21:26:41Z

can we do without nodejs for the yocto build?

catarial · 2024-11-15T21:41:41Z

can we do without nodejs for the yocto build?

@shankari

yes, but we wouldn't be able to use certain modules cause I think some of them use nodejs, the hardware ones should be fine.

shankari · 2024-11-15T21:47:50Z

Right, so can we try with removing that, since the build is fast?! Would be much easier than sshing into my personal server from CharIN if I need to make any last minute changes

catarial · 2024-11-15T21:50:51Z

Right, so can we try with removing that, since the build is fast?! Would be much easier than sshing into my personal server from CharIN if I need to make any last minute changes

@shankari yeah, I just need to figure out how to remove it since I'm pulling in the image from the yeti-yak-sdk

catarial · 2024-11-15T22:37:58Z

It works!

I ran into an issue where the node was writing to RAM instead of local storage so my build files disappeared. To fix that you just need to request local storage with --tmp when calling salloc

catarial · 2024-11-15T22:51:53Z

Building Yocto for NREL HPC users:

This is meant to be run interactively for now, I plan to write an sbatch script in the future.

ssh <user>@kestrel.hpc.nrel.gov
salloc --time=60 --account=mbap --nodes=1 --tmp=120000
# wait a while
source /projects/mbap/joet/envs/kas/bin/activate
cd $TMPDIR
mkdir workdir
cd workdir
git clone https://github.com/catarial/meta-charin-demo
kas shell -E meta-charin-demo/config.yml
module use /projects/mbap/joet/modules
module load diffstat chrpath ccache socat rpcsvc
../poky/scripts/install-buildtools
source ../poky/buildtools/environment-setup-x86_64-pokysdk-linux
bitbake -c build umwc-image
# wait even longer, should take 20-30 minutes

# to save build, copy to /projects/mbap/joet
rsync -aP --no-g tmp/deploy/images/raspberrypi4/ /projects/mbap/joet/<distinct-name>/

You can also copy out all of workdir/build to save for future builds, note that this could be like 50-100 GB

See https://nrel.gov/hpc and https://nrel.github.io/HPC/ for help with HPC

shankari · 2024-11-21T07:17:08Z

@catarial after we save the build, what do we do? How do we run the new code on the uMWC?

shankari · 2024-11-21T14:46:17Z

@catarial can you also generate a build with all the patches from main? I am not able to log into the HPC from here...
That way, I can also see what the build looks like. Tagging you here on GitHub for greater visibility before the official workday starts.

catarial · 2024-11-21T16:09:42Z

@catarial can you also generate a build with all the patches from main? I am not able to log into the HPC from here... That way, I can also see what the build looks like. Tagging you here on GitHub for greater visibility before the official workday starts.

@shankari

Will it be enough to just apply the compile patches

catarial · 2024-11-21T16:20:57Z

@catarial after we save the build, what do we do? How do we run the new code on the uMWC?

Flashing The uMWC After A Yocto Build

Open uMWC
Put pin jumper on the pins that say BOOT next to it.
Connect computer to microusb port on the board
Power on uMWC
Run rpiboot
Navigate to build/tmp/deploy/images/raspberrypi4 from the project directory
Flashing image
- MacOS/Windows: extract yeti-yak-image*.rootfs.wic.bz2 and use something
  like Balena Etcher to flash the image to the drive that shows up
- Linux: The device should show up as /dev/sda if you don't have any other
  HDDs. Use lsblk to verify which device to use. bmaptool copy yeti-yak-image*.rootfs.wic.bz2 /dev/sd<a-z>. You can also use dd if you
  extract the wic.bz2 file but it seems to be slower.
After flashing, unplug microusb and power off uMWC and remove pin jumper.

Connecting Via Ethernet

I configured the charger to use 192.168.1.100 as the address for the ethernet
interface. You need to make sure that the connection on your computer is
configured for this subnet, or change the chargers config to use a different
subnet.

On MacOS and Linux you can go into your network settings after the charger is on
and connected over ethernet. In network settings you can change the settings for
your ethernet connection to be manually configured instead of using DHCP. Set
the ip address to something in this range <192.168.1.<1-255>, but not 100. Set
the subnet mask to 255.255.255.0. Then you should be able to ssh into the
charger

ssh [email protected]

The password for aria is aria123. The password for root is
xihuCbj5eyIk8aRi, I suggest changing that one. I don't have sudo installed
so to get privileges run su and type in the root password.

Setting Up Wifi

I didn't have enough time to add the wifi configs to the build so you have to
copy them manually. I describe this step in my
meta-charin-demo repo as well
copying the everest configs over.

After copying the configs you can setup a hotspot with the name umwc-wifi and
password umwc_everest. Once wifi is setup, you can put the charger back
together and connect over that instead.

Connecting to everest-demo

Change the MQTT_SERVER_ADDRESS in everest.service to the demo's
address. If your connected over wifi, make sure to use your wifi address instead
of the ethernet one that was setup.

Make sure to run systemctl daemon-reload after changing a .service file.

Edit
/usr/share/everest/modules/OCPP201/component_config/standardized/InternalCtrlr.json
Search for the two lines that have localhost. Change both occurrences of
localhost:9000 to <demo address>/ws/cp001

If you're only using one EvseManager, remove EVSE\_2.json and
Connector_2_1.json in /usr/share/everest/modules/OCPP201/component_config/custom

You can change the everest config by either editing everest.service or copying
the new config to /etc/config-charin.yaml.

shankari · 2024-11-21T16:45:21Z

@catarial we don't need it, but I would like the library patches as well if possible.
So we need the compile patches, would be nice to have the library patches, and do not need runtime patches.

catarial · 2024-11-21T17:51:02Z

@shankari

Sorry that took longer than expected, uploading the image to teams right now

shankari · 2024-11-22T01:35:54Z

Alas:

My laptop was doing even worse today morning (it wouldn’t even detect that it was plugged in) so I left it turned off so I could at least copy data off before it died
We had to get testing done by around 1pm, so we really had to start testing as soon as possible. But we were able to perform multiple tests with the stock September release and got a lot of good data.

we will be better prepared for the next testival…

shankari · 2024-11-22T01:40:34Z

I am going to try to build once on my own and then close this issue

shankari · 2025-01-15T03:33:32Z

For the record, the customizations are checked in to @catarial's repo
https://github.com/catarial/meta-charin-demo/

The base image is specified in config.yml.
There are two everest-specific layers, meta-yeti-yak (which is actually from Pionix) and meta-everest.
Both of them are at release/kirkstone/2024.9.0
There are other layers as well, but they are all standard (e.g. meta-arm and meta-raspberrypi)

The patches are applied through files in recipes-*
The ethernet configuration is at recipes-core/systemd and the everest patches are at recipes-core/everest

We are currently applying two patches

    file://enable_iso_dt.patch \
    file://composite_schedule_fixes.patch \

Let's see which others we need.
For now, these are:

manager/demo-patches/change_transfer_mode_to_single_phase.patch
manager/demo-patches/enable_ocpp_logging.patch

The first is really the most important one for setting up AC charging demos using the uMWC in the US.
The second is a nice to have, but we may turn it off if it is too verbose

shankari · 2025-01-15T05:46:25Z

When @catarial shared a build with me earlier, she shared both a wic.bz2 file and a wic.bmap file
The .wic.bz2 file is referred to in #76 (comment) but the bmap file is not. Let's check the internet to see what the bmap file is and what it does.

Ah it is a block map, which can be used to flash quickly.

wrt

MacOS/Windows: extract yeti-yak-image*.rootfs.wic.bz2 and use something like Balena Etcher to flash the image to the drive that shows up

Not sure Balena Etcher supports the bmap file. if the bmaptool is recommended, let's see if we can get it for the mac.
Alas, it looks like we can't
https://duckduckgo.com/?t=ftsa&q=homebrew+bmaptool&ia=web

But wait, it is a python package. Can I just install it using pypi?
Nope, it doesn't appear to be available using pypi.

Can I install it using pip from GitHub?

Nope

$ pip install git+https://github.com/yoctoproject/bmaptool.git
Collecting git+https://github.com/yoctoproject/bmaptool.git
  Cloning https://github.com/yoctoproject/bmaptool.git to /private/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/pip-req-build-urpedi8w
  Running command git clone --filter=blob:none --quiet https://github.com/yoctoproject/bmaptool.git /private/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/pip-req-build-urpedi8w
  Resolved https://github.com/yoctoproject/bmaptool.git to commit 1f542112b8a0ed5f3547f9d4211f05a73b459483
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting gpg>=1.10.0 (from bmaptool==3.8.0)
  Downloading gpg-1.10.0.tar.gz (39 kB)
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error
  
  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> [1 lines of output]
      Could not find gpgme-config.  Please install the libgpgme development package.
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
kshankar-41872s:bmaptool kshankar$ which pip
/Users/kshankar/miniconda-23.5.2/envs/qrcodegen/bin/pip
kshankar-41872s:bmaptool kshankar$ pip install libgpgme
ERROR: Could not find a version that satisfies the requirement libgpgme (from versions: none)
ERROR: No matching distribution found for libgpgme
kshankar-41872s:bmaptool kshankar$ pip install libgpgme-dev
ERROR: Could not find a version that satisfies the requirement libgpgme-dev (from versions: none)
ERROR: No matching distribution found for libgpgme-dev

shankari · 2025-01-15T06:37:24Z

Tried to use rpiboot to mount the raspberry PI, but am running into issues.

RPIBOOT: build-date Jan 14 2025 version 20240422~085300 4a3d3117
Waiting for BCM2835/6/7/2711/2712...
Found device 1 idVendor=0x0a5c idProduct=0x2711
Bus: 1, Device: 3 Path: 1-1.4
Found candidate Compute Module...
Device located successfully
Loading embedded: bootcode4.bin
Initialised device correctly
Found serial number 3
last_serial -1 serial 3Sending bootcode.bin
libusb: warning [darwin_transfer_status] transfer error: timed out
libusb_bulk_transfer sent 0 bytes; returned -7
Failed to write correct length, returned 0

Next steps:

upgrade the version of usbboot
try a different cable, consistent with Stuck in loop - Failed control transfer (-7,24) raspberrypi/usbboot#87

shankari · 2025-01-15T06:44:10Z

Pulled the latest version of usbboot from github, and rebuilt

RPIBOOT: build-date Jan 14 2025 version 20240422~085300 d4aa5041
If the device fails to connect then please see https://rpltd.co/rpiboot for debugging tips.
Waiting for BCM2835/6/7/2711/2712...
Found device 1 idVendor=0x0a5c idProduct=0x2711
Bus: 1, Device: 3 Path: 1-1.4
Found candidate Compute Module...
Device located successfully
Loading embedded: bootcode4.bin
Initialised device correctly
Found serial number 3
last_serial -1 serial 3
Sending bootcode.bin
libusb: warning [darwin_transfer_status] transfer error: timed out
libusb_bulk_transfer sent 0 bytes; returned -7

shankari · 2025-01-15T06:53:01Z

Switched to a different USB port on my laptop. The Yak board now has a green LED turned on and I can see the boot drive loaded. Let's now use dd to image...

There's no lsblk on OSX that I can see, but mount works.

/dev/disk16s1 on /Volumes/boot (msdos, local, nodev, nosuid, noowners, noatime, fskit)

Unmounting, and then using dd

$ diskutil list
/dev/disk16 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *15.6 GB    disk16
   1:             Windows_FAT_32 boot                    53.5 MB    disk16s1
   2:                      Linux                         6.0 GB     disk16s2
                    (free space)                         9.5 GB     -

Fails even though I use sudo

$ sudo dd if=/tmp/umwc-image-raspberrypi4-20241121171724.rootfs.wic of=/dev/disk16
Password:
dd: /dev/disk16: Operation not permitted

This is apparently because of issues with macos sandbox
https://superuser.com/questions/978090/dd-operation-not-permitted-how-to-escape-sandbox

I was also not able to give the terminal "Full Disk Access".
I'm going to give up and use my personal linux machine instead.

shankari · 2025-01-15T07:37:11Z

Personal laptop doesn't have enough resources to install both xcode and command line tools.
Have to use personal linux machine

shankari · 2025-01-28T16:33:13Z

there is an easier option that does not require futzing around with re-flashing, which is to cross-compile.
I know that I successfully got the code to cross-compile after #76 (comment) and used that as the solution for testing in the CEC demo.
https://everest.github.io/nightly/hardware/pionix_belay_box.html#cross-compile-toolchain

However, when I tried to cross-compile last night, I ran into issues with "Illegal instruction". I tried running:

the newer build with working_notify_limit
the older build with 0.0.23
the base build-kit image

and all of them failed with the same error.

I tried running with --platform linux/amd64 and it still didn't work. Unfortunately, the previous, working container was deleted when I cleared out the old containers to start work on the changes for #101 so I can't try to run it again - I should have committed it as an image before I deleted it but the process was fairly straightforward, so I am didn't think it was necessary.

My laptop was upgraded to Sequoia last week, and I installed a new version of docker, but I double checked my messages and my recollection, and the timeline was:

update to Sequoia happened Tuesday afternoon
cross-compile worked Tuesday night
cross-compile not working now

I am not sure exactly why this happened, but there was another update (Sequoia -> Sequoia) last week, which may have something to do with it. It is fairly clear that the error happens because we are trying to run an x86 binary on an arm chip, and the virtualization isn't working for some reason. So something might have changed in the virtualization.

Searching the internet indicates that some flakiness may be due to Rosetta
https://romanzipp.com/blog/maocs-sequoia-docker-resetta-is-only-intended-to-run-silicon

@catarial for visibility

shankari · 2025-01-28T17:01:42Z

Switching to the legacy QEMU emulation seems to have resolved the issues - I ran into the "Illegal instruction" error multiple times while setting up the cross-compile chain before and I didn't this time.

HOWEVER, cross-compiling using x86 seems super weird here. We are running this on a arm chip; why do we need to emulate x86 so that we can compile back to arm?

Well, we know why; it is because the image is not multi-platform. @catarial I wonder if one thing you can work while waiting for additional guidance is resolving the multi-platform issue so that we can lower the emulation overhead and compile arm <-> arm.

This may also resolve the issues around having to patch for arm. It will likely involve a deeper understanding of what docker is doing under the hood wrt virtualization. It will likely not help @mjun70 since he is running on an intel mac anyway, but it may give some insight in case it is a generic virtualization issue

catarial · 2025-01-30T01:52:34Z

Well, we know why; it is because the image is not multi-platform. @catarial I wonder if one thing you can work while waiting for additional guidance is resolving the multi-platform issue so that we can lower the emulation overhead and compile arm <-> arm.

@shankari

I was able to get a successful build of the manager image in this repository on my silicon mac if that's what you mean.

shankari · 2025-01-30T04:14:25Z

I was able to get a successful build of the manager image in this repository on my silicon mac if that's what you mean.

Successful build using which setup? Did you use a docker container? Did you use the cross-compile toolchain?
Which version of the virtualization layer did you use? Let's discuss at tomorrow's meeting.

shankari added this to the CharIN demo prep milestone Oct 15, 2024

shankari mentioned this issue Oct 16, 2024

Build and run custom version of EVerest on the uMWC #51

Closed

shankari assigned catarial Oct 17, 2024

shankari mentioned this issue Nov 11, 2024

[nice to have] figure out how to simulate yocto on a VM #77

Open

the-bay-kay mentioned this issue Nov 14, 2024

📝 ❇️ Test all SIL/HIL Demos #84

Open

3 tasks

Build Yocto with recent EVerest release #76

Build Yocto with recent EVerest release #76

Comments

shankari commented Oct 15, 2024

catarial commented Oct 17, 2024

shankari commented Oct 17, 2024

catarial commented Oct 17, 2024

shankari commented Oct 17, 2024

catarial commented Oct 17, 2024

catarial commented Oct 18, 2024

catarial commented Oct 18, 2024

shankari commented Oct 18, 2024

catarial commented Oct 18, 2024

shankari commented Oct 18, 2024

catarial commented Oct 21, 2024

catarial commented Oct 21, 2024

Building a core image for the orangepi zero2

Add required layers for orangepi zero2:

Edit conf/local.conf

Build your image

catarial commented Oct 21, 2024

catarial commented Oct 21, 2024 • edited Loading

catarial commented Oct 21, 2024 • edited Loading

Successful orangepi build on Mac

How to build Yocto on Mac

VPN Issues

catarial commented Oct 21, 2024

catarial commented Oct 21, 2024

catarial commented Oct 21, 2024 • edited Loading

catarial commented Oct 22, 2024

catarial commented Oct 23, 2024

Adding everest to a core image

catarial commented Oct 23, 2024

catarial commented Oct 23, 2024

shankari commented Oct 23, 2024

catarial commented Oct 23, 2024

catarial commented Oct 23, 2024 • edited Loading

catarial commented Oct 23, 2024 • edited Loading

catarial commented Oct 23, 2024

shankari commented Nov 8, 2024

Abby-Wheelis commented Nov 8, 2024

shankari commented Nov 11, 2024 • edited Loading

catarial commented Nov 15, 2024

shankari commented Nov 15, 2024

catarial commented Nov 15, 2024

shankari commented Nov 15, 2024

catarial commented Nov 15, 2024

catarial commented Nov 15, 2024

catarial commented Nov 15, 2024 • edited Loading

shankari commented Nov 21, 2024

shankari commented Nov 21, 2024

catarial commented Nov 21, 2024

catarial commented Nov 21, 2024

Flashing The uMWC After A Yocto Build

Connecting Via Ethernet

Setting Up Wifi

Connecting to everest-demo

shankari commented Nov 21, 2024

catarial commented Nov 21, 2024

shankari commented Nov 22, 2024

shankari commented Nov 22, 2024

shankari commented Jan 15, 2025

shankari commented Jan 15, 2025

shankari commented Jan 15, 2025

shankari commented Jan 15, 2025

shankari commented Jan 15, 2025 • edited Loading

shankari commented Jan 15, 2025

shankari commented Jan 28, 2025

shankari commented Jan 28, 2025 • edited Loading

catarial commented Jan 30, 2025

shankari commented Jan 30, 2025

Edit `conf/local.conf`

catarial commented Oct 21, 2024 •

edited

Loading

catarial commented Oct 21, 2024 •

edited

Loading

catarial commented Oct 21, 2024 •

edited

Loading

catarial commented Oct 23, 2024 •

edited

Loading

catarial commented Oct 23, 2024 •

edited

Loading

shankari commented Nov 11, 2024 •

edited

Loading

catarial commented Nov 15, 2024 •

edited

Loading

shankari commented Jan 15, 2025 •

edited

Loading

shankari commented Jan 28, 2025 •

edited

Loading