(Victron Energy) Venus OS: Unterschied zwischen den Versionen

Aus TippvomTibb
Zur Navigation springen Zur Suche springen
Zeile 535: Zeile 535:
 
Auf geht's.
 
Auf geht's.
  
 +
<div class="toccolours mw-collapsible mw-collapsed" style="width:600px; overflow:auto;">
 +
<div style="font-weight:bold;line-height:1.6;">Receiver Sketch</div>
 +
<div class="mw-collapsible-content">
 +
<pre>
 
(base) chris@worker:/opt/venus> make raspberrypi2-venus-image
 
(base) chris@worker:/opt/venus> make raspberrypi2-venus-image
 
export MACHINE=raspberrypi2 && . ./sources/openembedded-core/oe-init-build-env build sources/bitbake && bitbake venus-image
 
export MACHINE=raspberrypi2 && . ./sources/openembedded-core/oe-init-build-env build sources/bitbake && bitbake venus-image
Zeile 584: Zeile 588:
 
meta-venus          = "master:25d0e4732df87eae88a7b913ad5126511fc49b0a"
 
meta-venus          = "master:25d0e4732df87eae88a7b913ad5126511fc49b0a"
 
meta                = "dunfell_venus:b3be78d80c0c788147758714580695bfa9df0e8f"
 
meta                = "dunfell_venus:b3be78d80c0c788147758714580695bfa9df0e8f"
 +
</pre>
 +
</div></div>
 +
 +
Gut 1 Stunde spaeter mit 16 Kernen, ~3 GHz (5852 BogoMips) und thermischer Belastung :-)
 +
 +
[333296.607648] mce: CPU8: Core temperature above threshold, cpu clock throttled (total events = 2200869)
 +
[333296.607649] mce: CPU0: Core temperature above threshold, cpu clock throttled (total events = 2200871)
 +
 +
dann ein Ergebnis.
  
 
=Bei Gelegenheit=
 
=Bei Gelegenheit=

Version vom 4. November 2022, 10:23 Uhr

Allgemeines

Images

Die Images (CerboGX, RasPi u.a.) findet man unter https://updates.victronenergy.com/feeds/venus/release/images/

oder hier https://professional.victronenergy.com/downloads/firmware/


Die 'swu'-Varianten beziehen sich vermutlich auf SWUpdate https://updates.victronenergy.com/feeds/venus/release/images/

Die 'large'-Varianten beinhalten zusaetzlich den Node-RED- und SignalK-Support.


Hinweise: https://stackoverflow.com/questions/68895797/swupdate-error-no-suitable-swu-image-found


VenusOS mit QEMU

Das waere zum Testen eine Erleichterung. So richtig gefunden habe ich zu dem Thema nichts verwertbares. Ein Versuch ist hier dokumentiert.

Erste Schritte mit Buster

Zum Einlesen. https://www.raspberry-pi-geek.de/ausgaben/rpg/2014/04/raspberry-pi-emulieren/

Mein aktueller QEMU ist die Version 5.2.0. 

qemu-system-arm --help
QEMU emulator version 5.2.0 (SUSE Linux Enterprise 15)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
usage: qemu-system-arm [options] [disk_image]

'disk_image' is a raw hard disk image for IDE hard disk 0

Mit 

qemu-system-arm -machine help

erhaelt man eine Uebersicht ueber die unterstuetzten Hardwareplatformen. Mit raspi2(b) koennte es klappen, raspi3 und raspi4 werden (noch) nicht unterstuertzt.

Die einfachste Startvariante (ohne Optionen) waere neben der Maschine einfach noch ein Diskimage anzugeben.

Mal mit 2020-02-13-raspbian-buster in /opt/QEMU/Buster probieren.

4/8/16 GB SDCard erzeugen;-) 

dd if=/dev/irgendein.img bs=1024 count=16777216

oder 

qemu-img create noobliteqemu.img 16G

Die beiden Ergebnisse von 'dd' und 'qemu-img' habe ich noch nicht verglichen. qemu-img ist viel maechtiger. dd und andere Befehle wie compare, convert, check, ... sind in qemu-img als subcommand integriert. Die unterstuetzten Formate lassen erahnen was mit qemu-img noch alles moeglich ist (Stichwort: VirtualBox, vmware). 

Supported formats: blkdebug blklogwrites blkverify bochs cloop compress copy-on-read dmg file ftp ftps gluster host_cdrom host_device http https iscsi iser luks nbd nfs null-aio null-co nvme qcow qcow2 qed quorum raw rbd replication sheepdog ssh throttle vdi vhdx vmdk vpc vvfat

Ich war zu voreilig. Das Anlegen einer virtuellen SD-Karte benoetigt man nur wenn man das "Image" in Form einer Dateisammlung vorliegen hat. Im Falle 'buster' steckt in dem zip das img drin. Diese z.B. 2020-02-13-raspbian-buster.img beinhaltet alles was man braucht. In ihm stecken 2 Partitionen (boot und root), die man nach dem Erstellen des LOOP-Devices auch beide mounten kann/muss.

Zuerst mal nur losetup eingeben um eine freie Loop-Device-Nummer zu finden. 

losetup -P /dev/loopX 2020-02-13-raspbian-buster.img   (X = Nummer eines freies LOOP-Device)

fdisk /dev/loopX

zeigt die 2 Partitionen. 

mount /dev/loopXp1 /mnt/sdcard_boot

mount /dev/loopXp2 /mnt/sdcard_root

losetup -d /dev/loopX

Anmerkungen:

Beim Anlegen des Loop-Device gibt man am besten die Option -P mit an. Damit werden vom Kernel dann auch moegliche Partitionen loopXp1, loopXp2, ... gleich mit angeboten.

Die passende DTB-Datei ist entweder bcm2709-rpi-2-b.dtb oder bcm2710-rpi-2-b.dtb. Das urspruengliche DTS-Datei koennte u.a. von hier stammen. Um aber zum Beispiel den Inhalt von zwei dtb Dateien zu vergleichen ist es einfacher sie erst in den Quellcode umzuwandeln. Dazu dient der DeviceTreeCompiler (dtc). Mit z.B. dem Kommando 

dtc -I dtb -O dts bcm2710-rpi-2-b.dtb > bcm2710-rpi-2-b.dts

laesst sich der DeviceTree lesbar machen. Z.B. hat mich gewundert, dass es 2 raspi2 dtbs gibt aber kein Hinweis auf den Unterschied. Hier die Aufloesung. 

diff bcm2709-rpi-2-b.dts bcm2710-rpi-2-b.dts 
5,6c5,6
<       compatible = "raspberrypi,2-model-b\0brcm,bcm2836";
<       model = "Raspberry Pi 2 Model B";
---
>       compatible = "raspberrypi,2-model-b-rev2\0brcm,bcm2837";
>       model = "Raspberry Pi 2 Model B rev 1.2";
55c55
<                       coefficients = <0xfffffde6 0x635d8>;
---
>                       coefficients = <0xfffffde6 0x64960>;
67c67
<               ranges = <0x7e000000 0x3f000000 0x1000000 0x40000000 0x40000000 0x40000>;
---
>               ranges = <0x7e000000 0x3f000000 0x1000000 0x40000000 0x40000000 0x1000>;
800c800
<                       compatible = "brcm,bcm2836-thermal";
---
>                       compatible = "brcm,bcm2837-thermal";
989,991c989,992
<                       compatible = "arm,cortex-a7";
<                       reg = <0xf00>;
<                       clock-frequency = <0x2faf0800>;
---
>                       compatible = "arm,cortex-a53";
>                       reg = <0x00>;
>                       enable-method = "spin-table";
>                       cpu-release-addr = <0x00 0xd8>;
997,999c998,1001
<                       compatible = "arm,cortex-a7";
<                       reg = <0xf01>;
<                       clock-frequency = <0x2faf0800>;
---
>                       compatible = "arm,cortex-a53";
>                       reg = <0x01>;
>                       enable-method = "spin-table";
>                       cpu-release-addr = <0x00 0xe0>;
1005,1007c1007,1010
<                       compatible = "arm,cortex-a7";
<                       reg = <0xf02>;
<                       clock-frequency = <0x2faf0800>;
---
>                       compatible = "arm,cortex-a53";
>                       reg = <0x02>;
>                       enable-method = "spin-table";
>                       cpu-release-addr = <0x00 0xe8>;
1013,1015c1016,1019
<                       compatible = "arm,cortex-a7";
<                       reg = <0xf03>;
<                       clock-frequency = <0x2faf0800>;
---
>                       compatible = "arm,cortex-a53";
>                       reg = <0x03>;
>                       enable-method = "spin-table";
>                       cpu-release-addr = <0x00 0xf0>;
1213,1216c1217,1220
<               v7_cpu0 = "/cpus/cpu@0";
<               v7_cpu1 = "/cpus/cpu@1";
<               v7_cpu2 = "/cpus/cpu@2";
<               v7_cpu3 = "/cpus/cpu@3";
---
>               cpu0 = "/cpus/cpu@0";
>               cpu1 = "/cpus/cpu@1";
>               cpu2 = "/cpus/cpu@2";
>               cpu3 = "/cpus/cpu@3";

Die bcm2710-rpi-2-b.dtb ist fuer die Rev1.2 mit Cortex A53 CPU wie sie auch im Raspi3 verwendet wird. 

qemu-system-aarch64     -M raspi3     -append "rw earlyprintk=ttyAMA0,115200 loglevel=8 console=ttyAMA0,115200 root=PARTUUID=ea7d04d6-02 rootfstype=ext4 rootwait"     -cpu cortex-a53     -dtb boot/bcm2710-rpi-3-b.dtb     -drive id=hd-root,file=2020-02-13-raspbian-buster.img,format=raw     -kernel boot/kernel8.img     -m 1024     -serial mon:stdio

Eine kleine Huerde gabe es noch. In der Append Option war noch die UUID der Rootpartition anzugeben. Die habe ich mit 

grep UUID *

in der Boot-Partition ausgelesen.

Yahoo!

QEMU Raspi Buster Startup.png

Jetzt noch schnell mit 'pi' und 'raspberry' auf der Konsole anmelden und los geht's.

Mist. Maus und Tastatur im GUI gehen nicht. Der Hinweis hier brachte keinen Erfolg. Der Bootvorgang blieb haengen ebenso bei den Optionen: 

-device usb-mouse -device usb-kbd -show-cursor

Sobald irgendwas mit USB aktiviert wird gibt's eine CPU Exception.

Mal schauen was die Hilfsskripte unter [1] anders machen. 

worker:/opt/QEMU/Buster # extract_kernel.sh 2020-02-13-raspbian-buster.img 
info: setting up loop-device for 2020-02-13-raspbian-buster.img
info: mounting /dev/loop9p1
info: copying files from boot-partition
info: cleanup of loop-mount
id: ‘’: no such user: No such file or directory
info: please change ownership of kernel-files manually

extract_kernel.sh legt die dtb und img Dateien im aktuellen Verzeichnis ab. Der Fehler des Befehl id ruehrt aus der Tatsache, dass ich das extract-Kommando als root (nicht sudo) ausgefuehrt habe.

Der Junge der die Helper-Skripte geschrieben hat ist gut. Vor der zweiten Anwendung von extract_kernel.sh, um die geanderte cmdline.txt auszulesen, habe ich vorsichtshalber eine Kopie cmdline.txt.first angelegt und siehe da, nach der Skript-Ausfuehrung gibt es da eine cmdline.1st. Die Kopie haette ich mir sparen koennen.

Nach dem Umwandeln der img in eine qcow2 und starten mit raspi2.sh gehen auch Maus und Tastatur. Nach diesem Erfolg nun auf zur Venus;-)

VenusOS fuer Raspi2

Erst mal alle aktuellen Versionen 2.92 herunterladen.

  • 2 x swu (SoftWareUpdate)
  • 2 x wic (wic Extension ???)

Jeweils 'Large' und 'Normal'.

Das Skript extract_kernel.sh bricht mit einem Fehler ab und extrahiert aus der wic-Datei nur 2 von 4 dtb -Dateien.

Das Kernel legt im wic nicht in der Boot-Partition, sondern im root/boot. 

/boot/zImage-5.10.110-rpi-venus-3

Der Start mit raspi2.sh bringt zwar den blauen victron energy Startbildschirm bleibt aber haengen.

Was mich irritiert ist die Tatsache, dass der Cerbo 2 Partitionen rootfs vorhaelt. Damit ist es moeglich nach einem Update auf die alte Installation zuruekzugreifen und dass es einen Datenpartition (data) gibt, die sich aber nicht auf der SD-Karte befinden und somit auch nicht gemountet werden kann.

Ein Blick in Cerbo: 

root@einstein:~# ls -l /dev/mmc*
brw-rw----    1 root     disk      179,   0 Oct 23 07:47 /dev/mmcblk1
brw-rw----    1 root     disk      179,   8 Oct 23 07:47 /dev/mmcblk1boot0
brw-rw----    1 root     disk      179,  16 Oct 23 07:47 /dev/mmcblk1boot1
brw-rw----    1 root     disk      179,   1 Oct 23 07:47 /dev/mmcblk1p1
brw-rw----    1 root     disk      179,   2 Oct 23 07:47 /dev/mmcblk1p2
brw-rw----    1 root     disk      179,   3 Oct 23 07:47 /dev/mmcblk1p3
brw-rw----    1 root     disk      179,   4 Oct 23 07:47 /dev/mmcblk1p4
brw-rw----    1 root     disk      179,   5 Oct 23 07:47 /dev/mmcblk1p5

root@einstein:~# mount | grep mmcblk
/dev/mmcblk1p2 on / type ext4 (rw,relatime)
/dev/mmcblk1p5 on /data type ext4 (rw,noatime)

root@einstein:~# ls -l /data
drwxr-xr-x    3 root     root          4096 Nov  1 13:00 conf
drwxr-xr-x    2 www-data root          4096 Oct 29 06:51 db
drwxr-xr-x    2 root     root          4096 Jan  1  2010 etc
drwxr-xr-x    4 root     root          4096 Jan  1  1970 home
drwx------    2 root     root          4096 Apr  9  2022 keys
drwxr-xr-x   53 root     root          4096 Oct 29 09:56 log
drwx------    2 root     root         16384 Jan  1  1970 lost+found
drwxr-xr-x    3 root     root          4096 Jan  1  1970 themes
drwxr-xr-x    3 root     root          4096 Jan  1  1970 var
drwxr-xr-x    2 root     root          4096 Oct 23 07:48 venus
drwxr-xr-x    2 root     root          4096 Apr  9  2022 vrmfilescache

An der Stelle muss ich erst mal aufgeben, da ich keine Moeglichkeit sehe wie ich den Grund des 'haengenden' Bootvorgangs erkennen kann. Da die normalen Methoden des Bootens () ab dem Splash-Screen nicht erkennbar sind versuche ich einen Umweg ueber den Selbstbau eines Images.

VenusOS Github

Venus OpenSource ist von Github zu klonen. Die Anleitung findet sich hier. 

git clone https://github.com/victronenergy/venus.git

Aber spaetestens bei 

make prereq

muss man die Entscheidung treffen, alles auf einem Debian-System zu bewerkstelligen oder recht muehsam das apt-get durch zypper oder yast zu ersetzen.

Es werden folgende Pakete benoetigt:

  • sed
  • wget
  • cvs
  • subversion
  • git-core
  • coreutils
  • unzip
  • texi2html
  • texinfo
  • docbook-utils
  • gawk
  • python-pysqlite2
  • diffstat
  • help2man
  • make
  • gcc
  • build-essential
  • g++
  • desktop-file-utils
  • chrpath
  • u-boot-tools
  • imagemagick
  • zip
  • python-gobject
  • python-gtk2
  • python-dev

Zum Bauen der Images benutzt Victron Energy scheinbar 'Yocto'('OpenEmbedded'). Da auf der Github-Seite im Readme der Befehl 'bitbake' benutzt wird und sich im Image ein Verzeichnis dunfell befindet was auf die Yocto_version 3.1 hinweist.

Die Installation von Yocto ist hier sehr gut beschrieben und schnell ausgefuehrt. Auch das erste TestImage ist recht schnell erstellt. Einzig die Emulation ist bei einer Prozessor-Auslastung von >100% doch recht langsam. Ich haette wahrscheinlich noch mehrere Kerne zuordnen muessen. Das soll mich jetzt nicht weiter stoeren, sondern mal schauen wie man aus den Quellen von VenusOS ein eigenes Image hinbekommt.

Openembedded(-core) muss nicht eigens installiert werden, sondern dies wird mit dem Befehl 'make fetch' gleich mit erledigt.

Beim erste Starten ist 'make fetch' mit Fehlermeldung abgebrochen. 

--------------- sources/meta-noto - git@github.com:victronenergy/meta-noto.git -------------
Cloning into 'sources/meta-noto'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Ich hatte bei meinem Github-Account noch keinen ssh-Schluessel hinterlegt. Das ist aber einfach zu loesen.

Mit 

ssh-keygen (Alle defaults mit Enter bestaetigen)

eine Schluesselpaar erzeugen und den Inhalt des Publickey in home/<user>/.ssh/id_rsa.pub beim eigenen Github-Konto unter 'Setting' und 'SSH and GPG Keys' als neuen SSH-Key einkopieren. Mit 

ssh -vT git@github.com

laest sich testen, ob alles fuer einen SSH-GitClone in Ordnung ist.

make fetch
(base) chris@worker:/opt/venus> make fetch
ln -s configs/dunfell conf

--------------- sources/bitbake - https://github.com/victronenergy/bitbake.git -------------
Cloning into 'sources/bitbake'...
remote: Enumerating objects: 56839, done.
remote: Total 56839 (delta 0), reused 0 (delta 0), pack-reused 56839
Receiving objects: 100% (56839/56839), 20.49 MiB | 6.69 MiB/s, done.
Resolving deltas: 100% (40059/40059), done.
Already on 'dunfell_venus'
Your branch is up to date with 'origin/dunfell_venus'.
branch 'dunfell_venus' set up to track 'origin/dunfell_venus'.
Set git config log.follow=true, to handle all the recipe renames

--------------- sources/meta-noto - git@github.com:victronenergy/meta-noto.git -------------
Cloning into 'sources/meta-noto'...
Warning: Permanently added the ECDSA host key for IP address '140.82.121.3' to the list of known hosts.
remote: Enumerating objects: 199, done.
remote: Counting objects: 100% (33/33), done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 199 (delta 19), reused 17 (delta 17), pack-reused 166
Receiving objects: 100% (199/199), 33.82 KiB | 364.00 KiB/s, done.
Resolving deltas: 100% (94/94), done.
branch 'master_venus' set up to track 'origin/master_venus'.
Switched to a new branch 'master_venus'
branch 'master_venus' set up to track 'origin/master_venus'.
Set git config log.follow=true, to handle all the recipe renames

--------------- sources/meta-openembedded - git@github.com:victronenergy/meta-openembedded.git -------------
Cloning into 'sources/meta-openembedded'...
remote: Enumerating objects: 174625, done.
remote: Counting objects: 100% (2/2), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 174625 (delta 0), reused 0 (delta 0), pack-reused 174623
Receiving objects: 100% (174625/174625), 55.79 MiB | 6.50 MiB/s, done.
Resolving deltas: 100% (102240/102240), done.
Already on 'dunfell_venus'
Your branch is up to date with 'origin/dunfell_venus'.
branch 'dunfell_venus' set up to track 'origin/dunfell_venus'.
Set git config log.follow=true, to handle all the recipe renames

--------------- sources/meta-qt4 - https://github.com/victronenergy/meta-qt4.git -------------
Cloning into 'sources/meta-qt4'...
remote: Enumerating objects: 440, done.
remote: Counting objects: 100% (71/71), done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 440 (delta 23), reused 41 (delta 16), pack-reused 369
Receiving objects: 100% (440/440), 138.87 KiB | 5.79 MiB/s, done.
Resolving deltas: 100% (207/207), done.
Already on 'dunfell'
Your branch is up to date with 'origin/dunfell'.
branch 'dunfell' set up to track 'origin/dunfell'.
Set git config log.follow=true, to handle all the recipe renames

--------------- sources/meta-qt6 - git@github.com:victronenergy/meta-qt6.git -------------
Cloning into 'sources/meta-qt6'...
remote: Enumerating objects: 3658, done.
remote: Counting objects: 100% (166/166), done.
remote: Compressing objects: 100% (109/109), done.
remote: Total 3658 (delta 98), reused 108 (delta 57), pack-reused 3492
Receiving objects: 100% (3658/3658), 625.36 KiB | 1.52 MiB/s, done.
Resolving deltas: 100% (2846/2846), done.
Already on '6.2_venus'
Your branch is up to date with 'origin/6.2_venus'.
branch '6.2_venus' set up to track 'origin/6.2_venus'.
Set git config log.follow=true, to handle all the recipe renames

--------------- sources/meta-swupdate - git@github.com:victronenergy/meta-swupdate.git -------------
Cloning into 'sources/meta-swupdate'...
remote: Enumerating objects: 768, done.
remote: Counting objects: 100% (84/84), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 768 (delta 77), reused 75 (delta 75), pack-reused 684
Receiving objects: 100% (768/768), 117.28 KiB | 659.00 KiB/s, done.
Resolving deltas: 100% (298/298), done.
Already on 'dunfell_venus'
Your branch is up to date with 'origin/dunfell_venus'.
branch 'dunfell_venus' set up to track 'origin/dunfell_venus'.
Set git config log.follow=true, to handle all the recipe renames

--------------- sources/meta-victronenergy - https://github.com/victronenergy/meta-victronenergy.git -------------
Cloning into 'sources/meta-victronenergy'...
remote: Enumerating objects: 23040, done.
remote: Counting objects: 100% (5960/5960), done.
remote: Compressing objects: 100% (2295/2295), done.
remote: Total 23040 (delta 3510), reused 5698 (delta 3348), pack-reused 17080
Receiving objects: 100% (23040/23040), 3.60 MiB | 6.48 MiB/s, done.
Resolving deltas: 100% (13038/13038), done.
Already on 'master'
Your branch is up to date with 'origin/master'.
branch 'master' set up to track 'origin/master'.
Set git config log.follow=true, to handle all the recipe renames

--------------- sources/openembedded-core - https://github.com/victronenergy/openembedded-core.git -------------
Cloning into 'sources/openembedded-core'...
remote: Enumerating objects: 453431, done.
remote: Counting objects: 100% (22/22), done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 453431 (delta 4), reused 3 (delta 3), pack-reused 453409
Receiving objects: 100% (453431/453431), 167.13 MiB | 6.68 MiB/s, done.
Resolving deltas: 100% (311480/311480), done.
Already on 'dunfell_venus'
Your branch is up to date with 'origin/dunfell_venus'.
branch 'dunfell_venus' set up to track 'origin/dunfell_venus'.
Set git config log.follow=true, to handle all the recipe renames

Die Aufforderung nach 'git config log.follow=true' ergab allerdings eine Fehlermeldung. Der Befehl muss lauten: 

git config --add log.follow true

An dieser Stelle ist man wohl soweit Images zu erzeugen. Das Readme gibt dazu folgendes an. 

# build all, this will take a while though... it builds for all MACHINES as found
# in conf/machines.
make venus-images

# build for a specific machine
make ccgx-venus-image
make beaglebone-venus-image

# build the swu file only
make ccgx-swu

# build from within the bitbake shell.
# this will have the same end result as make ccgx-swu
make ccgx-bb
bitbake venus-swu

Da sind bei weitem nicht alle im Makefile hinterlegten Routinen.

make

(base) chris@worker:/opt/venus> make usage:

Setup 

 make prereq
  - Installs required host packages for Debian based distro's.

Checking out: 

 make CONFIG='jethro' fetch
  - Downloads public available repositories needed to build for jethro.
 make CONFIG='jethro' fetch-all
  - Downloads all repositories needed to build for jethro, needs victron git access.

 note: It is assumed you only checkout once, iow switching between CONFIGs is not
       supported on purpose, since it would require resetting git branches forcefully
       and that might throw away any pending, not yet pushed work.
       After a 'rm -rf sources && make clean' fetching should work again

Building: 

 Venus uses swupdate (https://github.com/sbabic/swupdate) for reliable firmware updates
   make beaglebone-swu
     - Builds a swu file for the beaglebone, which can be installed by sd / usb / or remotely
   make beaglebone-swu-large
     - Builds the large variant of the same
   make swus
     - Builds swu files for all MACHINES
   make swus-large
     - Builds swu files for all MACHINES_LARGE

 Building (bootable) images is also supported, but it depends on the machine
   make beaglebone-venus-image
     - Build an image for the beaglebone. beaglebone can be substituted by another supported MACHINE.
   make venus-images
     - Build images for all MACHINES supported for this CONFIG.

 Optional packages
   make beaglebone-machine
     - Builds everything for a given machine. This includes the image / optional packages
       etc. Hence this make take some time (building java, nodejs etc). I doesn't build a sdk
   make machines
     - like above, but for all MACHINES

 Software development kits
   make sdks
      Builds a SDK per architecture. This takes time!

 Venus
   make venus
     - builds everything supported, all MACHINES and optional things.

Problem resolving: 

 make beaglebone-bb
   - Drops you to a shell with oe script being sourced and MACHINE set.
 make clean-keep-sstate
   - Throw away the tmp / deploy dir but keep sstate (the cached build output) to quickly
     repopulate them. If you run out of disk space / want to cleanup deploy this can help you..
 make clean
   - Throw away the tmp / deploy dir, including sstate.

Checking in: 

 make update-repos.conf
   - Updates repos.conf to the checked out git branches. It still needs to be committed to git though.

Internals / needed when modifying whitelist etc: 

 make build/conf/bblayers.conf
   - Creates the bblayers.conf by looking at the repositories being checkout in sources
     and being in metas.whitelist, if it doesn't exist. Just remove the mentioned file if
     you want to update it forcefully, it will be regenerated.

multiconfig targets exists, which contain mc-, which is mainly useful for big builds on a machine which can run many threads in parallel. For common tasks it is slower since it parses more configs.

'Setup' und 'Checking out' sind vorerst erledigt, jetzt kommt Building.

Mit 

cat ./configs/dunfell/machines

sieht man welche Maschinen unterstuetzt werden. 

MACHINES=einstein nanopi raspberrypi2 raspberrypi4 beaglebone ccgx canvu500
MACHINES_LARGE=einstein nanopi raspberrypi2 raspberrypi4 beaglebone

Auf geht's.

Receiver Sketch
(base) chris@worker:/opt/venus> make raspberrypi2-venus-image
export MACHINE=raspberrypi2 && . ./sources/openembedded-core/oe-init-build-env build sources/bitbake && bitbake venus-image

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'.

Other commonly useful commands are:
 - 'devtool' and 'recipetool' handle common recipe tasks
 - 'bitbake-layers' handles common layer tasks
 - 'oe-pkgdata-util' handles common target package tasks
WARNING: Host distribution "opensuseleap-15.3" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Parsing recipes: 100% |###############################################################################################################| Time: 0:00:45
Parsing of 2415 .bb files complete (0 cached, 2415 parsed). 3552 targets, 411 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "opensuseleap-15.3"
TARGET_SYS           = "arm-ve-linux-gnueabi"
MACHINE              = "raspberrypi2"
DISTRO               = "venus"
DISTRO_VERSION       = "v3.00~6"
TUNE_FEATURES        = "arm vfp cortexa7 neon vfpv4 callconvention-hard"
TARGET_FPU           = "hard"
meta-noto            = "master_venus:768f69385083228845a28744fdd9c8f0fcf2a3e8"
meta-multimedia      
meta-networking      
meta-oe              
meta-python          
meta-webserver       = "dunfell_venus:ad916e910a790a1cc7c43bdc654c2da81b8cb17f"
meta-qt4             = "dunfell:a0ad970456578710cf665296262e9f90bac1ccfd"
meta-qt6             = "6.2_venus:8927654c3e57e8240bb59faf16a60b6f0293a8e7"
meta-swupdate        = "dunfell_venus:27bd67dacb29bddb1758f4fd34f37c1e8ffeb257"
meta-alternatives    
meta-bsp             
meta-third-party     
meta-ve-software     
meta-venus           = "master:25d0e4732df87eae88a7b913ad5126511fc49b0a"
meta                 = "dunfell_venus:b3be78d80c0c788147758714580695bfa9df0e8f"

Gut 1 Stunde spaeter mit 16 Kernen, ~3 GHz (5852 BogoMips) und thermischer Belastung :-) 

[333296.607648] mce: CPU8: Core temperature above threshold, cpu clock throttled (total events = 2200869)
[333296.607649] mce: CPU0: Core temperature above threshold, cpu clock throttled (total events = 2200871)

dann ein Ergebnis.

Bei Gelegenheit

[2]

Links

https://www.raspberry-pi-geek.de/ausgaben/rpg/2014/04/raspberry-pi-emulieren/

https://www.raspberry-pi-geek.de/ausgaben/rpg/2021/04/qemu-5-2-mit-verbesserter-unterstuetzung-fuer-raspberry-pi/

https://github.com/bablokb/pi-qemu-helper/blob/main/raspi_.sh

https://wiki.beyondlogic.org/index.php?title=Understanding_RaspberryPi_Boot_Process

Abgerufen von „https://tippvomtibb.de/wiki/index.php?title=(Victron_Energy)_Venus_OS&oldid=2357“