Buildroot-Status für AM62x

Zu Beginn eines jeden Projekts prüfen wir gemeinsam mit unseren Kunden, welche Art von Plattform sie benötigen werden. Handelt es sich um ein kleines, vielleicht sogar batteriebetriebenes Gerät mit geringem Bedarf an Performance oder Bandbreite, entscheiden wir uns in der Regel für die nRF52-Serie oder nRF9160-Mikrocontroller, entsprechend der Anforderungen an die Konnektivität. Diese sind bereits sehr leistungsfähig, wenn aber noch mehr Leistung, eine komplexere Software oder eine schnelle Ethernet- oder LTE-Verbindung benötigt wird, empfehlen wir die Verwendung des grandcentrix Linux Gateway Blueprint. Dabei handelt es sich um einen von uns vorgefertigten Single-Board-Computer, den wir an die spezifischen Kundenanforderungen anpassen. Er verfügt über eine SAMA5 CPU von Microchip. Dies ist zwar seit vielen Jahren unser zuverlässiges Standardprodukt, aber der Markt für Embedded-CPUs hat sich stark entwickelt. Für uns war es an der Zeit, eine neue CPU zu finden, die noch schneller ist und mit mehr Arbeitsspeicher ausgestattet werden kann, damit wir das IoT-Gateway von morgen entwickeln können. Mit der neuen AM62x-Plattform von Texas Instruments haben wir einen geeigneten Nachfolger gefunden. Sie wird in vier Footprint-kompatiblen Varianten mit 1, 2 oder 4 Kernen angeboten, die mit bis zu 1,4 GHz laufen. Dies ermöglicht uns die Entwicklung eines einzigen Entwurfs, der je nach den Anforderungen unserer Kunden nach oben oder unten skaliert werden kann. Die Erstellung eines neuen Blueprints und das Kennenlernen einer neuen CPU ist kein einfaches Unterfangen. Zum Beispiel bietet TI nur eine Linux-Distribution an, die auf Yocto basiert, aber wir wollen Buildroot verwenden. Es gibt noch keine offizielle Unterstützung für diese Plattform durch Buildroot, also müssen wir einige Dinge selbst erledigen. Folgen Sie uns auf unserem Weg, diese Plattform zum Laufen zu bringen und unseren neuen Blueprint zu erstellen! In diesem ersten Artikel erfahren Sie, wie unser Team Buildroot auf dem AM62x Entwicklungskit von TI zum Laufen gebracht hat.

Dimitri Mizenko — Embedded Software Developer

12. September 2023

Ziele

In diesem Artikel behandeln wir folgende Zielsetzungen:

  • Ein Bild von einer SD-Karte booten
  • Unser eigenes SD-Karten-Bild über buildroot erstellen
  • Flashen des externen eMMC-Flashs über USB-DFU
  • Versuch, von dem externen eMMC-Flash zu booten

Die Hardware

Wir werden das AM62x-Starterkit verwenden, das bei Texas Instruments erhältlich ist. Dieses Kit dient als Ausgangspunkt für die Evaluierung und Erreichung unserer Ziele. Ausführliche Informationen über das Starterkit finden Sie im User Guide. Zur besseren Veranschaulichung haben wir ein Bild der Entwicklungsplatine beigefügt, auf dem alle Hauptkomponenten zu sehen sind.

(Bilder wurden von Texas Instruments zur Verfügung gestellt, sie sind Teil des AM62x SK EVM User’s Guide - Copyright © 2023 Texas Instruments Incorporated)

Während unserer Betrachtung konzentrieren wir uns auf die folgenden relevanten Komponenten:

  • Bootmode-Auswahlschalter
  • Mikro-USB FTDI UART
  • Micro-SD-Kartensteckplatz
  • DRD (2.0) USB-C
  • 16GB eMMCe

Mit den Bootmode Selection Switches wird der geeignete Bootmodus für das Starterkit ausgewählt, um sicherzustellen, dass es korrekt hochgefahren wird. Für die Protokollierung des Bootvorgangs und die Einrichtung unserer primären Schnittstelle mit dem Starterkit werden wir uns auf den Micro-USB FTDI UART verlassen. Diese Schnittstelle ermöglicht es uns, den Bootvorgang zu verfolgen und zu analysieren. Um unser Image zu speichern, wird der Micro SD-Card Slot verwendet. Später werden wir die DRD (2.0) USB-C-Schnittstelle zum Flashen der 16 GB eMMC über USB-DFU verwenden.

Initial Board Bring Up

Das erste Einrichten des Starterkits kann mit dem mitgelieferten pre-build image durchgeführt werden. Die Anweisungen zum Flashen des Images finden Sie in der SDK-Dokumentation. Beachten Sie bitte die hervorgehobenen Hinweise in der Dokumentation und benennen Sie die Datei tiboot3.bin entsprechend um. Die korrekte Position der Boot-Schalter entnehmen Sie bitte der unten stehenden Abbildung:

Eine vollständige Liste der verfügbaren Boot-Schalter-Optionen finden Sie hier. Nachdem wir die SD-Karte eingesteckt und das Board eingeschaltet haben, können wir das Boot-Protokoll auf dem UART beobachten. Dieses Protokoll liefert uns Informationen über den Bootvorgang.

U-Boot SPL 2021.01-g74fc69c889 (May 30 2022 - 16:40:44 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.3.2--v08.03.02 (Jolly Jellyfi')
Trying to boot from MMC2
Loading Environment from MMC... *** Warning - No MMC card found, using default environment

Starting ATF on ARM64 core...

NOTICE:  BL31: v2.6(release):08.03.00.003-dirty
NOTICE:  BL31: Built : 16:35:46, May 30 2022

U-Boot SPL 2021.01-g74fc69c889 (May 30 2022 - 16:39:30 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.3.2--v08.03.02 (Jolly Jellyfi')
Trying to boot from MMC2


U-Boot 2021.01-g74fc69c889 (May 30 2022 - 16:39:30 +0000)

SoC:   AM62X SR1.0
Model: Texas Instruments AM625 SK
EEPROM not available at 0x50, trying to read at 0x51
Board: AM62-SKEVM rev E3
DRAM:  2 GiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1, mmc@fa20000: 2
Loading Environment from MMC... OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
SD/MMC found on device 1
Failed to load 'boot.scr'
1490 bytes read in 2 ms (727.5 KiB/s)
Loaded env from uEnv.txt
Importing environment from mmc1 ...
Running uenvcmd ...
1 bytes read in 2 ms (0 Bytes/s)
Already setup.
18448896 bytes read in 734 ms (24 MiB/s)
44485 bytes read in 4 ms (10.6 MiB/s)
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Device Tree to 000000008fef2000, end 000000008fffffff ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

[...]

 _____                    _____           _         _   
|  _  |___ ___ ___ ___   |  _  |___ ___  |_|___ ___| |_ 
|     |  _| .'| . | . |  |   __|  _| . | | | -_|  _|  _|
|__|__|_| |__,|_  |___|  |__|  |_| |___|_| |___|___|_|  
              |___|                    |___|            

Arago Project <http://arago-project.org> am62xx-evm ttyS2

Arago 2021.09 am62xx-evm ttyS2

am62xx-evm login:

AM62x Boot-Prozess

Bevor wir unser eigenes SD-Karten-Image mit Buildroot erstellen können, müssen wir den Boot-Prozess und die beteiligten Dateien verstehen. Der erste Schritt besteht darin, das SD-Karten-Image zu untersuchen. Wir werden sehen, dass die SD-Karte zwei Partitionen hat: die Boot-Partition und die Root-Partition.

❯ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    1    58G  0 disk
├─sda1        8:1    1 132,6M  0 part /run/media/$USER/boot
└─sda2        8:2    1   2,8G  0 part /run/media/$USER/root

Die Root-Partition enthält den Kernel und das gesamte Dateisystem, während die Boot-Partition alle Dateien enthält, die zum Booten des Linux-Kernels und damit des Betriebssystems erforderlich sind. Ein genauerer Blick auf die Boot-Partition offenbart die folgenden Dateien:

❯ tree /run/media/$USER/boot
/run/media/$USER/boot
├── tiboot3.bin
├── tispl.bin
├── u-boot.img
├── uEnv.txt
└── wificfg

Laut dem Boot Flow Diagramm beginnt der Bootvorgang damit, dass das AM6x-ROM die Datei tiboot3.bin lädt. tiboot3.bin lädt dann den R5 SPL-Bootloader, der wiederum die Datei tispl.bin lädt. tispl.bin lädt dann den A53 SPL-Bootloader, der das u-boot.img-Image zum Starten des A53 U-Boot-Bootloaders verwendet. Schließlich lädt A53 U-Boot den Linux-Kernel und das Betriebssystem wird gestartet.

Der vereinfachte Bootvorgang lässt sich wie folgt zusammenfassen:

AM6x ROM -> tiboot3.bin -> tispl.bin -> u-boot.img -> Linux Kernel
AM6x ROM -> R5-SPL      -> A53 SPL   -> A53 U-Boot  -> Linux Kernel

Ergänzung der Buildroot-Unterstützung

Diese Kenntnisse wollen wir nun zusammenführen und Buildroot-Unterstützung hinzufügen. Glücklicherweise müssen wir nicht bei Null anfangen, da TI bereits dabei ist, Buildroot-Unterstützung hinzuzufügen. Um dies zu erreichen, können wir die von TI zur Verfügung gestellten Patches verwenden und die bereitgestellten Build-Schritte befolgen, um das Image zu erzeugen. Bitte beachten Sie auch, dass wir uns auf den GP (General Purpose)-Bau konzentrieren werden, um die Komplexität zu reduzieren. Weitere Informationen zu den verschiedenen Gerätetypen finden Sie hier.

# clone the buildroot repository
❯ git clone --branch 2023.05.x <https://github.com/buildroot/buildroot.git>

# download the patch files
❯ curl -s -L <https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/buildroot_2D00_am64_2D00_sk_2D00_am62_2D00_sk_2D00_patch_2D00_v9_2D00_22_2D00_jun_2D00_2023.tar.gz> | tar -xvzf - -C buildroot/

# apply patch files
❯ git -C buildroot am *.patch

# build GP image
❯ echo "BR2_TARGET_TI_K3_IMAGE_GEN_SOC_TYPE_GP=y" >> buildroot/configs/am62x_sk_defconfig

# configure buildroot to build the am62x
❯ make -C buildroot am62x_sk_defconfig

# build the sd card image
❯ make -C buildroot

Sobald Buildroot die Erstellung abgeschlossen hat, befindet sich die Datei sd-card.img im Ordner buildroot/output/images. Diese Datei kann mit den zuvor beschriebenen Methoden auf die SD-Karte geflasht werden. Nach dem Einlegen der SD-Karte und dem Einschalten des Starterkits können wir beobachten, wie unser Board mit dem neu erstellten Image hochfährt.

U-Boot SPL 2021.01 (Jul 11 2023 - 10:54:39 +0200)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
SPL initial stack usage: 13424 bytes
Trying to boot from MMC2
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
Loading Environment from MMC... *** Warning - No MMC card found, using default environment

Starting ATF on ARM64 core...

NOTICE:  BL31: v2.8(release):2023.05-51-gd133e0550e-dirty
NOTICE:  BL31: Built : 10:45:24, Jul 11 2023
I/TC: 
I/TC: OP-TEE version: 2023.05-51-gd133e0550e-dev (gcc version 11.4.0 (Buildroot 2023.05-51-gd133e0550e-dirty)) #1 Tue Jul 11 08:45:19 UTC 2023 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check <https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html>
I/TC: Primary CPU initializing
I/TC: SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
I/TC: HUK Initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2021.01 (Jul 11 2023 - 10:46:41 +0200)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
Trying to boot from MMC2


U-Boot 2021.01 (Jul 11 2023 - 10:46:41 +0200)

SoC:   AM62X SR1.0 GP
Model: Texas Instruments AM625 SK
EEPROM not available at 0x50, trying to read at 0x51
Board: AM62-SKEVM rev E3
DRAM:  2 GiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1, mmc@fa20000: 2
Loading Environment from MMC... OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
SD/MMC found on device 1
Failed to load 'boot.scr'
Failed to load 'uEnv.txt'
19212800 bytes read in 234 ms (78.3 MiB/s)
42219 bytes read in 3 ms (13.4 MiB/s)
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Device Tree to 000000008fef2000, end 000000008fffffff ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[...]
[    2.852563] wl18xx_driver wl18xx.2.auto: Direct firmware load for ti-connectivity/wl18xx-conf.bin failed with error -2
done
[    2.863382] wlcore: ERROR could not get configuration binary ti-connectivity/wl18xx-conf.bin: -2
[    2.872725] wlcore: WARNING falling back to default config
Saving 256 bits of non-creditable seed for next boot
Starting network: OK

Welcome to Buildroot
buildroot login:

eMMC über USB-DFU flashen

Fahren wir nun mit dem Flashen der eMMC mittels USB-DFU fort. Die Dokumentation zu diesem Thema finden Sie unter den folgenden Links:

Unser erster Schritt besteht darin, eine tiboot3.bin-Datei zu erstellen, die den USB-DFU-Modus umfasst. Da die aktuelle Buildroot-Patch-Serie derzeit nicht die Generierung einer zweiten, eigenständigen tiboot3.bin unterstützt, müssen wir vorübergehend die am62x_sk_defconfig modifizieren. Nachfolgend finden Sie die notwendige Änderung, die vorgenommen werden muss:

# enable tiboot3.bin with usb-dfu support
❯ sed -i 's/"am62x_evm_r5"/"am62x_evm_r5_usbdfu"/' buildroot/configs/am62x_sk_defconfig

Bevor Sie die Datei tiboot3.bin neu erstellen, ist es wichtig, die bestehende Datei zu sichern. Diese Sicherung wird beim Booten von der eMMC verwendet.

# backup old tiboo3.bin
❯ cp buildroot/output/images/tiboot3.bin buildroot/output/images/tiboot3-backup.bin

Um die Datei tiboot3.bin neu zu erstellen, müssen wir die folgenden Schritte durchführen:

# update config
❯ make -C buildroot am62x_sk_defconfig

# rebuild tiboot3.bin files
❯ make -C buildroot ti-k3-r5-loader-dirclean ti-k3-r5-loader-rebuild ti-k3-image-gen-rebuild

Nachdem die vorherigen Schritte durchgeführt wurden, besteht die nachste Aufgabe darin, die Boot-Schalter auf dem Starterkit zu konfigurieren, um den USB-Peripherie-Boot-Modus zu aktivieren. Beachten Sie die Abbildung unten, um die Boot-Schalter entsprechend einzustellen:


Wenn die Karte über den DRD (2.0) USB-C-Anschluss mit Strom versorgt wird, wird sie als USB-Gerät erkannt.

❯ sudo dmesg

[618527.385115] usb 3-1.1.1.1.3: new high-speed USB device number 24 using xhci_hcd
[618527.500990] usb 3-1.1.1.1.3: New USB device found, idVendor=0451, idProduct=6165, bcdDevice= 2.00
[618527.500995] usb 3-1.1.1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[618527.500997] usb 3-1.1.1.1.3: Product: AM62x DFU
[618527.500998] usb 3-1.1.1.1.3: Manufacturer: Texas Instruments, Inc.
[618527.501000] usb 3-1.1.1.1.3: SerialNumber: 01.00.00.00

Außerdem lässt er sich mit dfu-util ermitteln:

❯ sudo dfu-util -l

Found DFU: [0451:6165] ver=0200, devnum=25, cfg=1, intf=0, path="3-1.1.1.1.3", alt=1, name="SocId", serial="01.00.00.00"
Found DFU: [0451:6165] ver=0200, devnum=25, cfg=1, intf=0, path="3-1.1.1.1.3", alt=0, name="bootloader", serial="01.00.00.00"

Nun können wir die tiboot3.bin sowie tispl.bin und u-boot.img hochladen. Wir beginnen mit dem Hochladen der Datei tiboot3.bin mit dem folgenden Befehl:

❯ sudo dfu-util -R -a bootloader -D buildroot/output/images/tiboot3.bin --device 0451

Allerdings tritt ein Fehler auf, wenn der R5 SPL versucht, zu booten.

U-Boot SPL 2021.01 (Jul 11 2023 - 11:30:52 +0200)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
SPL initial stack usage: 13424 bytes
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Bei diesem Problem scheint es sich um einen bekannten Fehler zu handeln, der durch die Anwendung des in den Workarounds genannten Fixes behoben werden kann. Anstatt den Fix anzuwenden, werden wir jedoch einen etwas anderen Ansatz wählen und eine neuere Version von u-boot verwenden, um das Problem zu umgehen. Daher werden wir auf die Version 09.00.00.001 von u-boot aktualisieren.

# upgrade u-boot version
❯ sed -i 's/ti-u-boot-08.06.00.007/ti-u-boot-09.00.00.001/g' buildroot/configs/am62x_sk_defconfig

Wenn wir nun die zuvor beschriebene Prozedur wiederholen, erhalten wir das folgende Boot-Protokoll:

U-Boot SPL 2023.04 (Jul 11 2023 - 11:38:07 +0200)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
SPL initial stack usage: 13392 bytes
Trying to boot from DFU

Fahren wir fort und laden die Dateien tispl.bin und u-boot.img hoch. Zunächst können wir überprüfen, ob der Bootloader zwei neue Abschnitte angezeigt hat, in die wir die Dateien hochladen können:

❯ sudo dfu-util -l

Found DFU: [0451:6165] ver=0223, devnum=20, cfg=1, intf=0, path="3-1.1.1.1.3", alt=1, name="u-boot.img", serial="UNKNOWN"
Found DFU: [0451:6165] ver=0223, devnum=20, cfg=1, intf=0, path="3-1.1.1.1.3", alt=0, name="tispl.bin", serial="UNKNOWN"

Wir können die Dateien hochladen, indem wir die folgenden Schritte ausführen:

❯ sudo dfu-util -R -a tispl.bin -D buildroot/output/images/tispl.bin --device 0451
❯ sudo dfu-util -R -a u-boot.img -D buildroot/output/images/u-boot.img --device 0451

Dies sollte nun den Start von U-Boot auslösen. Als Referenz sollte das Protokoll wie folgt aussehen:

U-Boot SPL 2023.04 (Jul 11 2023 - 11:38:07 +0200)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
SPL initial stack usage: 13392 bytes
Trying to boot from DFU
################################################DOWNLOAD ... OK
Ctrl+C to exit ...
################################################DOWNLOAD ... OK
Ctrl+C to exit ...
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
Loading Environment from nowhere... OK
init_env from device 10 not supported!
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.8(release):2023.05-51-gd133e0550e-dirty
NOTICE:  BL31: Built : 10:45:24, Jul 11 2023
I/TC: 
I/TC: OP-TEE version: 2023.05-51-gd133e0550e-dev (gcc version 11.4.0 (Buildroot 2023.05-51-gd133e0550e-dirty)) #1 Tue Jul 11 08:45:19 UTC 2023 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check <https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html>
I/TC: Primary CPU initializing
I/TC: SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
I/TC: HUK Initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2021.01 (Jul 11 2023 - 10:46:41 +0200)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
Trying to boot from DFU
####DOWNLOAD ... OK
Ctrl+C to exit ...

U-Boot 2021.01 (Jul 11 2023 - 10:46:41 +0200)

SoC:   AM62X SR1.0 GP
Model: Texas Instruments AM625 SK
EEPROM not available at 0x50, trying to read at 0x51
Board: AM62-SKEVM rev E3
DRAM:  2 GiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1, mmc@fa20000: 2
Loading Environment from MMC... OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1
Hit any key to stop autoboot:  0 
MMC: no card present
SD/MMC found on device 1
MMC: no card present
MMC: no card present
MMC: no card present
MMC: no card present
MMC: no card present
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!
Bad Linux ARM64 Image magic!
=>

Von diesem Punkt aus müssen wir U-Boot so konfigurieren, dass Datei-Uploads auf den eMMC-Flash möglich sind. Laut x können wir dies erreichen, indem wir die folgenden Schritte in U-Boot ausführen:

=> env set dfu_alt_info ${dfu_alt_info_emmc}
=> dfu 0 mmc 0

Leider ist dies nicht die ganze Geschichte und es wird nicht wie erwartet funktionieren und beim Hochladen des rootfs-Teils fehlschlagen. Um zu verstehen, warum das so ist, müssen wir die Variable dfu_alt_info_emmc und ihre Funktion untersuchen. Der erste Schritt besteht darin, den Inhalt der Variablen zu überprüfen.

=> env print dfu_alt_info_emmc
dfu_alt_info_emmc=rawemmc raw 0 0x800000 mmcpart 1;rootfs part 0 1 mmcpart 0;tiboot3.bin.raw raw 0x0 0x400 mmcpart 1;tispl.bin.raw raw 0x400 0x1000 mmcpart 1;u-boot.img.raw raw 0x1400 0x2000 mmcpart 1;u-env.raw raw 0x3400 0x100 mmcpart 1;sysfw.itb.raw raw 0x3600 0x800 mmcpart 1

Device Firmware Upgrade (DFU) beschreibt den Inhalt der Variable dfu_alt_info und was ihre Elemente bewirken. Wir können sehen, dass der rootfs-Zugriff über rohen Partitionszugriff rootfs part 0 1 mmcpart 0 erfolgt, während alle anderen Partitionen als roher mmc-Gerätezugriff deklariert sind. Diese Konfiguration impliziert, dass zum Hochladen eines rootfs eine dedizierte Partition für U-Boot zum Schreiben verfügbar sein muss. Der eMMC-Flash hat drei physische Partitionen (boot0, boot1 und rootfs). Dies kann mit dem unten stehenden Befehl beobachtet werden.

=> mmc info
Device: mmc@fa10000
Manufacturer ID: 13
OEM: 14e
Name: S0J56
Bus Speed: 200000000
Mode: HS200 (200MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 14.8 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 14.8 GiB WRREL
Boot Capacity: 31.5 MiB ENH
RPMB Capacity: 4 MiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected

Um erfolgreich auf die rootfs-Partition schreiben zu können, muss eine Partitionstabelle vorhanden sein. Dies kann mit U-Boot und dem Befehl gpt erreicht werden. Führen Sie dazu die folgenden Schritte aus:

=> env set uuid_gpt_disk 37c84ec5-8cc8-42e6-85d0-dfd0ebde3257
=> env set uuid_gpt_rootf e56d6d53-45ad-4331-944d-7c311283f39
=> gpt write mmc 0 $partitions

Das Setzen der Variablen uuid_gpt_disk und uuid_gpt_rootfs ist notwendig, da die Variable partitions von ihrer Existenz abhängt. Bitte stellen Sie sicher, dass Sie die Werte von uuid_gpt_disk und uuid_gpt_rootfs richtig setzen, da sie für das ordnungsgemäße Funktionieren der partitions-Variable unerlässlich sind.

=> env print partitions
partitions=uuid_disk=${uuid_gpt_disk};name=rootfs,start=0,size=-,uuid=${uuid_gpt_rootfs}

Die UUIDs können mit Tools wie dem Befehlszeilentool uuidgen erzeugt werden. Bitte beachten Sie, dass ein Neustart erforderlich sein kann, damit die Partitionen vollständig verfügbar sind. Sie können die Partitionen überprüfen, indem Sie den folgenden Befehl ausführen:

=> gpt verify mmc 0 $partitions
Verify GPT: success!

Die Partitionstabelle kann auch mit dem folgenden Befehl untersucht werden:

=> mmc part

Partition Map for MMC device 0  --   Partition Type: EFI

Part	Start LBA	End LBA		Name
	Attributes
	Type GUID
	Partition GUID
  1	0x00000022	0x01da3fde	"rootfs"
	attrs:	0x0000000000000000
	type:	ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
	guid:	e8be8e22-817f-1640-b82d-e3c79ef7c3eb

Jetzt können wir endlich alle benötigten Dateien hochladen, indem wir den DFU-Modus in U-Boot aktivieren und das dfu-util zum Hochladen verwenden:

=> env set dfu_alt_info ${dfu_alt_info_emmc}
=> dfu 0 mmc 0

# please note that here we use the tiboot3-backup.bin file
❯ sudo dfu-util -a tiboot3.bin.raw -D buildroot/output/images/tiboot3-backup.bin --device 0451

❯ sudo dfu-util -a tispl.bin.raw -D buildroot/output/images/tispl.bin --device 0451
❯ sudo dfu-util -a u-boot.img.raw -D buildroot/output/images/u-boot.img --device 0451
❯ sudo dfu-util -R -a rootfs -D buildroot/output/images/rootfs.ext4 --device 0451

Nachdem alle Dateien erfolgreich hochgeladen wurden, können wir überprüfen, ob das rootfs gefüllt ist, indem wir den Inhalt des rootfs überprüfen:

=> ls mmc 0
<DIR>       4096 .
<DIR>       4096 ..
<DIR>      16384 lost+found
<SYM>          7 bin
<DIR>       4096 boot
<DIR>       4096 dev
...

Booten von eMMC

Schließlich müssen wir U-Boot so konfigurieren, dass es von der eMMC bootet:

=> env set mmcdev 0
=> env set bootpart 0
=> mmc partconf 0 1 1 1
=> mmc bootbus 0 2 0 0
# in case you want to have the config persistent
=> saveenv

Nun kann der Boot-Befehl ausgeführt werden, und U-Boot sollte den Linux-Kernel von der eMMC laden und das Betriebssystem starten. Zusätzlich können die Boot-Schalter für eMMC-Boot konfiguriert werden, so dass das Starterkit von der eMMC starten kann.

Fazit

Geschafft! Wir haben Buildroot auf die neue AM62x CPU von Texas Instruments portiert und dabei eine neuere U-Boot Version als die offiziell unterstützte verwendet. In einem späteren Artikel werden wir zeigen, wie wir unsere eigene Blueprint-Hardware auf Basis des AM62x entwickelt haben.

Wenn Sie Unterstützung bei einem Embedded-Projekt benötigen, kontaktieren Sie uns! Unsere Software- und Hardware-Experten können Sie unterstützen, von einem kleinen Mikrocontroller-basierten Projekt bis hin zu einem kompletten Linux-basierten IoT Edge-Gerät.