(Including Demo videos at end of the description) Due to the pandemic in the past few years, lacking chips became one of the reasons that vendors cannot produce products. That affects industry, automotive and IT, etc. In addition, many countries propose new policies/acts which start to investigate the source of products recently. Therefore, keeping the flexibility of the usage of parts to maintain the robustness of productivity and service is an important skill. This talk will list the toolchains & debug tools for common chip architectures and share some development experience. This talk will share how to use the open source toolchain and debug tools to develop and debug, then flash the program to the ARM Cortex-M development board. The same idea can be used on other chip’s development boards. Will have some examples for ARM Cortex-A and RISC-V 32 & 64 Bits environment. Besides, will share the experience of sending patches to the debug tool and co-working with upstream, too. Demo Videos: * Develop with Nuvoton's NuTiny-SDK-NUC472 https://www.youtube.com/watch?v=Yz9uw2_9KS8 * Develop with Longan Nano https://www.youtube.com/watch?v=IFqDM_GLUfo * Boot Custom Linux Image on Raspberry Pi 4B https://www.youtube.com/watch?v=t3PjTtf5MvU * Boot Linux on QEMU RISC-V 64 Bits VM https://www.youtube.com/watch?v=8c7zfvJYzSo * Develop with Arduino Nano https://www.youtube.com/watch?v=sU7X9Q35hhY

1. Share the Experience of
Using Embedded
Development Board
潘建宏 Jian-Hong Pan (StarNight)
@ COSCUP 2023

2. Who am I
潘建宏 / Jian-Hong Pan (StarNight)
Endless OS Foundation
You can find me at
● http://www.slideshare.net/chienhungpan/
● GitHub: starnight
● Twitter: starnight_pan
● Email:
jhp [AT] endlessos.org
chienhung.pan [AT] gmail.com

3. Background
● Due to the pandemic in the past few years, lacking chips has become one of
the reasons that vendors cannot produce products. That affects industry,
automotive and IT, etc.
● Many countries propose new policies/acts which start to investigate the
source of products recently.
Therefore, keeping the flexibility of the usage of parts to maintain the robustness
of productivity and service is an important skill.

4. Well-Known Chip Architectures
Including MCU and CPU
● PIC
● x86(_64)
● ARM (8, 32 and 64 bits)
● AVR (8 and 32 bits)
● RISC-V (32, 64 bits and …)
● … and more

5. Development Environment
Common
GCC, GDB, make … or known as toolchain
Embedded system
OpenOCD, JTAG, USB to serial (option) and Board Support Package (BSP)
Cross Compiler
{arch}-{project …}-{gcc, gdb, ld, objcopy, objdump …}
Host (x86_64)
Cross compile
source code
Target (ARM, RISC-V)
Executable binary

6. Examples
Microcontroller Unit (MCU) Level
● Cortex-M4: Nuvoton’s NuTiny-SDK-NUC472
● RISC-V (32 bits): Sipeed Longan Nano
Central Processor Unit (CPU) Level
● Cortex-A72: Raspberry Pi 4B
● RISC-V (64 bits): QEMU Virtual Machine

7. Start from MCU Level First

8. ARM Cortex-M Comparison
Arm Core Cortex-M0 … Cortex-M4 … Cortex-M23 …
ARM architecture ARMv6-M ARMv7E-M
ARMv8-M
Baseline
Instruction pipeline 3 stages 3 stages 2 stages
Multiply instructions
32x32 = 32-bit result
Yes
Multiply instructions
32x32 = 64-bit result
No Yes No
Divide instructions
32/32 = 32-bit quotient
No Yes
DSP instructions No Yes NO
TrustZone security instructions No No Optional
Reference: Table: ARM Cortex-M instruction variations of ARM Cortex-M

9. NuTiny-SDK-NUC472’s Dev Environment
My host is an Arch Linux (x86_64) system. The target chip is Nuvoton's
NUC472HI8AE, an ARM Cortex-M4 MCU. Therefore, install the “arm-none-eabi-”
toolchain packages:
● arm-none-eabi-binutils
● arm-none-eabi-gcc
● arm-none-eabi-newlib
● arm-none-eabi-gdb
I prefer the Makefile tool. So, make is installed, too.
Note: Nuvoton marks NUC472HI8AE as Not Recommended For New Designs
(NRND) now. Recommended Part Number: M487 Ethernet Series

10. NuTiny-SDK-NUC472 Dev Environment (cont.)
Also, need OpenOCD to flash and debug.
● Upstream OpenOCD must includes these commits at least:
○ flash/nor/numicro: reorder the parts list
○ flash: support Nuvoton M541 & NUC442/472 series
○ tcl: add a configuration file for Nuvoton M541 & NUC442/472 series
The commits have been merged into the master branch.
● Or, downstream Nuvoton OpenOCD
I use this one

11. Nu-Link-Me
NuTiny-EVB-NUC472
NuTiny-SDK-NUC472 Board

12. NUC472-NuTiny’s LED Sample as the Example
Nuvoton has provided the NUC472/442 BSP at
https://github.com/OpenNuvoton/NUC472_442BSP, which follows Common
Microcontroller Software Interface Standard (CMSIS).
$ git clone https://github.com/OpenNuvoton/NUC472_442BSP
$ cd NUC472_442BSP/SampleCode/NUC472-NuTiny/LED/
And, have to add a Makefile into the LED sample code directory, for compile,
clean and flash.

13. CMSIS, Standard and Device Libraries for the Makefile
NUC472/442 BSP provides the libraries:
● CMSIS library is under path Library/CMSIS.
● Standard library is under path Library/StdDriver.
● NUC472/442’s library is under path Library/Device/Nuvoton/NUC472_442.
● NUC472/442’s system clock initialization is at
Library/Device/Nuvoton/NUC472_442/Source/system_NUC472_442.c.
● NUC472/442’s startup file is at
Library/Device/Nuvoton/NUC472_442/Source/GCC/startup_NUC472_442.S.
● NUC472/442’s linker file is at
Library/Device/Nuvoton/NUC472_442/Source/GCC/gcc_arm.ld.

14. Build the LED Application with make
$ make
arm-none-eabi-gcc -I../../../../NUC472_442BSP/Library/CMSIS/Include
-I../../../../NUC472_442BSP/Library/StdDriver/inc
-I../../../../NUC472_442BSP/Library/Device/Nuvoton/NUC472_442/Include -I. -ggdb -Os -Wall -Wextra
-Warray-bounds -mlittle-endian -mthumb -mcpu=cortex-m4 -mthumb-interwork -mfloat-abi=hard
-mfpu=fpv4-sp-d16
-T../../../../NUC472_442BSP/Library/Device/Nuvoton/NUC472_442/Source/GCC/gcc_arm.ld main.c
../../../../NUC472_442BSP/Library/StdDriver/src/clk.c
../../../../NUC472_442BSP/Library/StdDriver/src/gpio.c
../../../../NUC472_442BSP/Library/StdDriver/src/sys.c
../../../../NUC472_442BSP/Library/Device/Nuvoton/NUC472_442/Source/system_NUC472_442.c
../../../../NUC472_442BSP/Library/Device/Nuvoton/NUC472_442/Source/GCC/startup_NUC472_442.S -o
LED.elf
...
arm-none-eabi-objcopy -O ihex LED.elf LED.hex
arm-none-eabi-objcopy -O binary LED.elf LED.bin

15. Flash the built image into NuTiny-SDK-NUC472
Connect the NuTiny-SDK-NUC472 to your host via the USB cable. And, flash:
$ make flash # May need root privilege for opening Nu-Link device
openocd -f "interface/nulink.cfg" -f "target/numicro_m4.cfg" -c "program LED.elf verify reset exit"
…
** Programming Started **
Info : Device ID: 0x00047201
Info : Device Name: NUC472HI8AE
Info : bank base = 0x00000000, size = 0x00080000
Warn : Adding extra erase range, 0x00001770 .. 0x000017ff
Info : Nuvoton NuMicro: Sector Erase ... (0 to 2)
Info : Nuvoton NuMicro: Flash Write ...
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked
After flash, the onboard LED should become blinking.

16. Flash & Debug with GDB via OpenOCD and Nu-Link
Host
OpenOCD
Built Binary
Target Machine
NuTiny-EVB-NUC472
Nu-Link-Me
as the JTAG

17. 1. Start the gdb server with Nu-Link and the numicro M4 configs:
$ openocd -f "interface/nulink.cfg" -f "target/numicro_m4.cfg"
…
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain
JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : Nu-Link firmware_version 6535, product_id (0x00012009)
Info : Adapter is Nu-Link
Info : IDCODE: 0x2BA01477
Info : [NuMicro.cpu] Cortex-M4 r0p1 processor detected
Info : [NuMicro.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for NuMicro.cpu on 3333
Info : Listening on port 3333 for gdb connections
[NuMicro.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x00000f5c msp: 0x20010000

18. 2. Have the gdb client connecting to the gdb server listening on port 3333 to
debug the LED.elf flashed on the MCU chip Nuvoton NUC472HI8AE:
$ arm-none-eabi-gdb LED.elf
...
Reading symbols from LED.elf...
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: Overlapping regions in memory map: ignoring
Reset_Handler () at
../../../../NUC472_442BSP/Library/Device/Nuvoton/NUC472_442/Source/GCC/startup_NUC472_442.S:268
268 ldr r1, =__etext
(gdb) hbreak main.c:86
Hardware assisted breakpoint 1 at 0x3a2: file main.c, line 86.
(gdb) continue
Continuing.
Breakpoint 1, main () at main.c:86
86 PB10 = 0;
(gdb)
Use hbreak (hardware-assisted breakpoint) to add a break point, instead of break.
Reference: 5.1.1 Setting Breakpoints

19. RISC-V Capability, RISC-V@Andes as the Example
AndeStar™ V5 Architecture:
● Supports both 32-bits (RV32) and 64-bits (RV64)
● 32-bit N25, N25F, D25F, A25 and A27;
64-bit NX25, NX25F, AX25, and AX27
● N25F, NX25F, A25 and AX25 supports single and double precision floating
point for high-precision data computations
● D25F, A25 and AX25 supports DSP/SIMD instructions
Reference: RISC-V@Andes

20. Sipeed Longan Nano's Dev Environment
According to Longan Nano’s introduction, the target chip is a GD32VF103 MCU
using Andes’ core with RISC-V 32 bits ISA. Therefore, install the “riscv64-elf-”
toolchain packages:
● riscv64-elf-binutils
● riscv64-elf-gcc
● riscv64-elf-newlib
● riscv64-elf-gdb
The make is a preferred tool and need OpenOCD to flash and debug.

21. List riscv64-elf- Toolchain Supported Architectures
$ riscv64-elf-gcc --version | head -n1
riscv64-elf-gcc (Arch Linux Repositories) 12.2.0
$ riscv64-elf-gcc --print-multi-lib
.;
rv32i/ilp32;@march=rv32i@mabi=ilp32
rv32im/ilp32;@march=rv32im@mabi=ilp32
rv32iac/ilp32;@march=rv32iac@mabi=ilp32
rv32imac/ilp32;@march=rv32imac@mabi=ilp32
rv32imafc/ilp32f;@march=rv32imafc@mabi=ilp32f
rv64imac/lp64;@march=rv64imac@mabi=lp64
rv64imafdc/lp64d;@march=rv64imafdc@mabi=lp64d

22. Tweak Longan Nano’s BSP
GD32VF103 Microcontroller has GD32VF103_Firmware_Library. However, it
suggests Nuclei SDK!?
$ git clone https://github.com/Nuclei-Software/nuclei-sdk
$ cd nuclei-sdk
I have some modification to use the bare-metal toolchain “riscv64-elf-”:
● Use common RISC-V 64 bare-metal toolchain
● Set ISA spec version as 2.2 to support extension zicsr
● Use mainline OpenOCD’s gd32vf103.cfg as the config. Besides, I use FTDI
FT232HQ board as the the JTAG interface. So, use um232h.cfg as the config.

23. Have an LED Application as the Example
Add the LED application referring to sibling helloworld:
$ ls application/baremetal/led/
main.c Makefile npk.yml
1. Get into the led app:
$ cd application/baremetal/led
2. Disable the optimization for GDB with -O0.
3. Build:
$ make SOC=gd32vf103 BOARD=gd32vf103c_longan_nano all
4. Flash:
$ make SOC=gd32vf103 BOARD=gd32vf103c_longan_nano upload
5. It will light RGB LEDs in order periodically.

24. Flash & Debug with GDB via OpenOCD and FTDI
Host
OpenOCD
Built Binary
Target Machine
Sipeed Longan Nano
FTDI FT232H
as the JTAG

25. JTAG interface
Reference: Longan Documentation -> PIN Map & Longan-DOC with Apache License Version 2.0

26. 1. Connect the TCK, TDO, TDI, TMS and GND pins between FT232H and the
Sipeed Longan Nano board.
2. Start the gdb server with FT232H as JTAG interface and GD32VF103 as the
target configs:
$ openocd -f interface/ftdi/um232h.cfg -f target/gd32vf103.cfg
…
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at the low
speed (100 kHz)
Warn : To remove this warnings and achieve reasonable communication speed with the target, set
"adapter speed" or "jtag_rclk" in the init scripts.
Info : clock speed 100 kHz
Info : JTAG tap: gd32vf103.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology
Corporation), part: 0x0005, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor
(Beijing) Inc), part: 0x9000, ver: 0x7)
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 5 -expected-id 0x790007a3"
Info : datacount=4 progbufsize=2
Info : Examined RISC-V core; found 1 harts
Info : hart 0: XLEN=32, misa=0x40901105
Info : starting gdb server for gd32vf103.cpu on 3333
Info : Listening on port 3333 for gdb connections

27. 3. Have the gdb client connecting to the gdb server to debug the led.elf flashed
on the MCU chip GD32VF103C8T6:
$ riscv64-elf-gdb led.elf
...
Reading symbols from led.elf...
(gdb) target extended-remote localhost:3333
Remote debugging using localhost:3333
0x080016ee in SysTimer_GetLoadValue ()
at ../../../NMSIS/Core/Include/core_feature_timer.h:151
151 if (high0 != high) {
(gdb) break main.c:68
Breakpoint 1 at 0x8001d9c: file main.c, line 68.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) continue
Continuing.
Breakpoint 1, main () at main.c:68
68 gpio_bit_reset(GPIOC, GPIO_PIN_13);
(gdb)

28. How about CPU Level
Boot Linux System

29. Linux Kernel Boots
Chip
x86(_64)
arm(64)
RISC-V
…
Firmware
BIOS/UEFI
firmwares
…
Bootloader
GRUB
LILO
SYSLINUX
U-Boot
…
Kernel
Linux
(initramfs)
Init
PID 1

30. Build Linux Kernel with arm64 Arch
The cross compilation toolchain’s prefix is “aarch64-linux-gnu-”. Use
aarch64-linux-gnu-gcc as the compiler.
1. Get Linux kernel
$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
2. Build
$ cd linux
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-

31. Have a Blank Disk to Boot QEMU VM
$ fdisk -l blank.img
Disk blank.img: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf80638ed
Device Boot Start End Sectors Size Id Type
blank.img1 * 1 2049 2049 1M b W95 FAT32
blank.img2 2050 8191 6142 3M 83 Linux
Just a quick test!

32. Boot the QEMU VM with Linux Kernel & Blank Disk
Install packages: qemu-system-aarch64
$ qemu-system-aarch64
-smp 2
-M virt -cpu cortex-a57
-m 1G
-kernel ~/linux/arch/arm64/boot/Image
--append "console=ttyAMA0 root=/dev/vda2"
-hda ~/qemuimg/blank.img
-serial stdio

33. Linux Kernel Tries to Find init in the Filesystem
…
[ 2.146201] Run /sbin/init as init process
[ 2.148061] Run /etc/init as init process
[ 2.149846] Run /bin/init as init process
[ 2.150521] Run /bin/sh as init process
[ 2.151871] Kernel panic - not syncing: No working init found. Try passing init=
option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
…

34. The Init Process
In Unix-based computer operating systems, init (short for initialization) is the first
process started during booting of the computer system. Init is a daemon process
that continues running until the system is shut down. ~ from init on Wiki
● SysVInit
● Upstart
● Systemd
● OpenRC
● …
● Busybox
$ ls -l /bin/init # on my laptop
lrwxrwxrwx 1 root root 22 Jun 20 05:41 /bin/init -> ../lib/systemd/systemd

35. System Storage Layout
Boot Partition:
● Boot loader
● Kernel, Initial RAM disk, Device Tree Blobs
Root Partition:
● /boot
● /sbin, /bin
● /usr, /lib
● /etc
● /dev, /proc, /sys
● /root
● /tmp, /var, /mnt
● …
init

36. Build a System Image Containing Root Filesystem
1. Have a raw image
2. Format the raw image with designed partitions layout
3. Mount the root partition to the QEMU VM by the architecture
4. Install system packages, applications into the root partition.
Also, known as bootstrap.
5. Prepare config files for the init process into the root partition
6. Prepare /etc/fstab for mount points
7. Prepare config files for other processes into the root partition: Network,
DHCP, DNS …
8. Unmount the root partition
Note: Step 5 ~ 7 depend on the hardware and case by case.

37. Build System Images with GitHub Actions
Build kernel:
https://github.com/starnight/build-kernel/blob/main/.github/workflows/main.yml
Build system image with Alpine container images:
https://github.com/starnight/build-image/blob/main/.github/workflows/image.yml
1. Build root filesystem within the architecture’s container environment, for
example aarch64
2. Create a RAW image and partitions
3. Mount the partitions and deploy the root filesystem into the partitions

38. https://github.com/starnight/build-image/releases
The Images

39. Boot with the Built Image on Raspberry Pi
Welcome to Alpine Linux 3.18
Kernel 6.4.2 on an aarch64 (/dev/ttyS1)
alpine-arm64 login: root
Welcome to Alpine!
…
alpine-arm64:~# dmesg
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
[ 0.000000] Linux version 6.4.2 (runner@fv-az470-332) (aarch64-linux-gnu-gcc (Ubuntu
11.3.0-1ubuntu1~22.04.1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP
PREEMPT Sat Jul 8 04:19:40 UTC 2023
[ 0.000000] random: crng init done
[ 0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.1
[ 0.000000] efi: UEFI not found.
[ 0.000000] Reserved memory: created CMA memory pool at 0x0000000037400000, size
64 MiB
…

40. Please Refer for More Detail
● Debug Linux Kernel on Raspberry Pi:
Let's trace Linux Kernel with KGDB
● Build Root Filesystem for Raspberry Pi:
Launch the First Process in Linux System

41. Build Linux Kernel with RISC-V 64 Bits Arch
The cross compilation toolchain’s prefix is “riscv64-linux-gnu-”. Use
riscv64-linux-gnu-gcc as the compiler.
1. Get Linux kernel
$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
2. Build
$ cd linux
$ make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- defconfig
$ make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- menuconfig
$ make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu-

42. Boot the kernel with Root Filesystem on QEMU VM
Install packages: qemu-system-riscv and qemu-system-riscv-firmware
The root filesystem can be downloaded from starnight/build-image’s Releases.
$ qemu-system-riscv64
-M virt -smp 4 -m 2G -display none -serial stdio
-kernel ~/linux/arch/riscv/boot/Image
-append "console=ttyS0 root=/dev/vda2 rw rootfstype=ext4"
-drive file=/tmp/simple-alpine-qemu_riscv64.img,format=raw,id=hd0
-device virtio-blk-device,drive=hd0
-netdev user,id=usernet -device virtio-net-device,netdev=usernet

43. Tune the Build Config to Debug RISC-V QEMU VM
● The option CONFIG_SOC_VIRT is for QEMU virtual machine.
● For debug
○ CONFIG_DEBUG_INFO=y
○ # CONFIG_DEBUG_INFO_REDUCED is not set
○ CONFIG_GDB_SCRIPTS=y
○ CONFIG_FRAME_POINTER=y

44. Boot with the Built Image on QEMU VM (RISC-V 64)
Welcome to Alpine Linux 3.18
Kernel 6.4.2 on an riscv64 (/dev/ttyS0)
alpine-arm64 login: root
Welcome to Alpine!
…
alpine-arm64:~# dmesg
[ 0.000000] Linux version 6.4.2 (zack@starnight) (riscv64-linux-gnu-gcc (GCC)
12.2.0, GNU ld (GNU Binutils) 2.39) #3 SMP Sun Jul 9 11:30:02 CST 2023
[ 0.000000] random: crng init done
[ 0.000000] Machine model: riscv-virtio,qemu
[ 0.000000] efi: UEFI not found.
[ 0.000000] OF: reserved mem: 0x0000000080000000..0x000000008003ffff
(256 KiB) map non-reusable mmode_resv0@80000000
…

45. Boot the RISC-V 64 System for Online Debug
Append -S and -s to QEMU command:
$ qemu-system-riscv64 -h
...
-S freeze CPU at startup (use 'c' to start execution)
…
-gdb dev accept gdb connection on 'dev'. (QEMU defaults to starting
the guest without waiting for gdb to connect; use -S too
if you want it to not start execution.)
-s shorthand for -gdb tcp::1234

46. 1. Boot the QEMU virtual machine with debug feature
$ qemu-system-riscv64
-M virt -smp 4 -m 2G -display none -serial stdio
-kernel ~/linux/arch/riscv/boot/Image
-append "console=ttyS0 root=/dev/vda2 rw rootfstype=ext4"
-drive file=/tmp/simple-alpine-qemu_riscv64.img,format=raw,id=hd0
-device virtio-blk-device,drive=hd0
-netdev user,id=usernet -device virtio-net-device,netdev=usernet
-s -S
Note: It freezes CPU at startup

47. 2. Install riscv64-linux-gnu-gdb as the debugger
3. Start RISC-V 64’s GDB in the linux project folder, then debug:
$ cd ~/linux-stable && riscv64-linux-gnu-gdb vmlinux
...
Reading symbols from vmlinux...
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x0000000000001000 in ?? ()
(gdb) break virtnet_probe
Breakpoint 1 at 0xffffffff806b87dc: file drivers/net/virtio_net.c, line 3879.
(gdb) continue
Continuing.
[Switching to Thread 1.2]
Thread 2 hit Breakpoint 1, virtnet_probe (vdev=0xff60000001e6b040) at drivers/net/virtio_net.c:3879
3879 {
(gdb)

48. Reference
● QEMU ARM guest support
● First Kernel Patch
● Linux Documentation/admin-guide/init.rst
● fdisk, mkfs.vfat, mkfs.ext4 and mount
● Alpine
● The Linux Bootdisk HOWTO - 4. Building a root filesystem
● Bootstrapping Alpine Linux
● RISC-V Specifications

50. APPENDIX - AVR’s Development Environment
AVR series MCUs are used widely on Arduino classic boards. Therefore, install
the “avr-” toolchain packages:
● avr-gcc
● avr-gdb
● avr-libc
And, the flash tool: avrdude
Prepared some examples in AVR practice repository.
https://github.com/starnight/AVR-practice