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?

catarial · 2024-11-07T17:59:25Z

wait, that was a mistake evse_board_support isnt a module

@Abby-Wheelis Should I roll back evse_board_support as well?

I would roll back the entire contents of the module, including the subfolders, is that different from what you did? Is evse_board_support a separate module?

I already did roll back the entire module. Here's the patch file I'm using

https://github.com/catarial/meta-charin-demo/blob/main/recipes-core/everest/files/0001-rollback-uMWC-BSP-to-2024.6.0.patch

ed-watt · 2024-11-07T18:03:40Z

@catarial, I realized that the config file needs this line changed: https://github.com/catarial/meta-charin-demo/blob/65c65c7a029b72bf30f5a94dd6a1da23fc91bf38/recipes-core/everest/files/config-charin.yaml#L92

Device in the iso15118_charger config should be set to eth1

device: eth1

shankari · 2024-11-07T18:06:31Z

I am pretty sure that the PLC "modem" is exposed as a serial interface and not an ethernet interface. @ed-watt do you know where you saw that it was an ethernet interface?

ed-watt · 2024-11-07T18:14:25Z

EvseSlac module takes a device config that the manifest.yaml describes as "Ethernet device used for PLC". That was already set to eth1 in the config that Aria linked and I think it would error out if that was not a PLC device based on the EvseSlac module code. It defaults to eth1 also if not set explicitly and maybe the yocto build configuration ensures that the PLC device gets enumerated as eth1 consistently.

The EvseV2G module on the other hand is set to auto in our config and defaults to eth0 if not set. The auto setting also seems to end up choosing eth0 from my experience with SIL and the uMW testing we've done so far. That is happening here too, see these log messages:

iso15118_charge  :: TCP server on eth0 is listening on port [fe80::e65f:1ff:fec7:dbde%2]:61341
iso15118_charge  :: TLS server on eth0 is listening on port [fe80::e65f:1ff:fec7:dbde%2]:64109

This needs to be set to eth1, the ethernet interface for the PLC where the charging messages will arrive, or else the V2G messages will not get seen by the EvseV2G module. We saw this in our recent lab testing and fixed by changing auto to eth1.

shankari · 2024-11-07T19:21:40Z

Interesting. I went back and double-checked my notes, and the firmware update is indeed via the serial port.

$ ./umwc_fwupdate /dev/serial0 ../share/everest/modules/YetiDriver/firmware/yetiR1_2.1_firmware.bin

Reading through the Pionix documentation, I see that there are two boards:

power delivery: Yeti in BelayBox, custom in uMWC to deliver 1W of power
HLC, including the PLC module: Yak, with an RP4 compute module included

I guess the power delivery board (uMWC-Yeti) is connected to the Yak board via a serial port (aka "10 pin connector for high level board with control UART"). The uMWC-Yeti has separate firmware because "the very basic state machine for states A-F remains in the microcontroller. This basic state machine is essential for electrical safety as it is the actual decision point for switching power on/off etc." So we update the firmware over a serial port. And since we are dealing with the uMWC-Yeti instead of the Yeti, we can't use the same firmware as the Belay Box.[1]

When we ssh into the uMWC, we are running on the Yak board, and can see the PLC modem as an ethernet port. The BSP driver runs on the Yak and communicates with the uMWC-Yeti over the serial port.

Ah I understand all this so much better now; hopefully it helps some others too 😄

[1] I still don't understand why the firmware needs to be so different. Presumably they are using the same microcontroller (STM32), if they use the same input and output pins as the open hardware, the same firmware can theoretically be used for both, right? I thought it might be because the classic Yeti communicates with a power controller while the uMWC-Yeti outputs the 1W of power directly, but that can't be true because the output is at 1000V, which a regular CPU can't output. It must also have a power controller. Something to think about and understand better after CharIN

Abby-Wheelis · 2024-11-07T23:52:17Z

Debugging techniques:

MQTT explorer (install on laptop) with ssh tunnel to charger port 1883
- for hardware: everest-telemetry/livedata/1/power_path_controller (cp state, pwn duty cycle)
- everest_external/umwc/# - also for low-level hardware info
using journal control to check the logs for the everest.service
swapping configs: edit the specific file - TBD
config folder convention /etc/everest
Wifi is hardcoded for now, best to change hotspot to match credentials: ssid="umwc-wifi" and password="umwc_everest"
logs for V2G set by a path in the config

-> to be safe, pull of journalctl logs before powering down, as they're only somewhat persistent, depends on the size
-> if hitting an error, will retry a few times, but you might need to try restarting the service / checking the status of the service
-> sudo uninstalled, use su to get root privledges
-> will send user/pass credentials via teams and/or write them on a card to keep with the hardware

tried for packet sniffer, but not currently working, maybe we can try to get it working for testival, some obstacles encountered - error at the end of the attempted packet captured, as triggered by EVSE manager -- could test in software by potentially faking out with MQTT ---- failing with a blank error now so debugging will take a while

Ethernet: 192.168.1.100

catarial · 2024-11-07T23:58:15Z

Results of 11/7 testing:

wifi now working with the yocto image after configuring wpa_supplicant correctly, increasing ability to test/make updates on the fly. I'll add the overrided config to my build tomorrow.
the Sept release (2024.9.0) is working on the uMWC basically out of the box with and firmware v1.0
With this config
Able to complete an AC ISO15118-2 EIM charging session, seeing all the same logs you would expect to see on SIL
See logs from charging session here:
Tried ISO15118-2 EIM DC charging session, also running through startup, charging, and stopping with the messages you'd expect in SIL
same as above but with DIN
want to get OCPP working in software in prep for managed charging patches

catarial · 2024-11-07T23:59:10Z

Ethernet: 192.168.1.100

For ethernet, make sure your interface is configured to be on the same subnet

shankari · 2024-11-08T00:01:52Z

the Sept release (2024.9.0) is working on the uMWC basically out of the box with and firmware v1.0

what is firmware v1.0? I would suggest putting in a month for now; and we should suggest to the community that the firmware also has proper release numbering. You could also post this into the Zulip Chat.

Congrats! It turned out to be fairly easy at the end, but I know it took a lot of effort to get here.

catarial · 2024-11-08T16:20:10Z

the Sept release (2024.9.0) is working on the uMWC basically out of the box with and firmware v1.0

what is firmware v1.0? I would suggest putting in a month for now; and we should suggest to the community that the firmware also has proper release numbering. You could also post this into the Zulip Chat.

I have no idea. It should be either the firmware version that came with the charger when it was bought or whatever firmware was flashed most recently.

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 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

catarial commented Nov 7, 2024

ed-watt commented Nov 7, 2024

shankari commented Nov 7, 2024

ed-watt commented Nov 7, 2024 • edited Loading

shankari commented Nov 7, 2024 • edited Loading

Abby-Wheelis commented Nov 7, 2024

catarial commented Nov 7, 2024

catarial commented Nov 7, 2024

shankari commented Nov 8, 2024

catarial commented Nov 8, 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

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

ed-watt commented Nov 7, 2024 •

edited

Loading

shankari commented Nov 7, 2024 •

edited

Loading

shankari commented Nov 11, 2024 •

edited

Loading

catarial commented Nov 15, 2024 •

edited

Loading