[Buildroot] [PATCH 1/1] configs/qemu: add qemu_riscv64_virt_defconfig

[Buildroot] [PATCH 1/1] configs/qemu: add qemu_riscv64_virt_defconfig

[Mark Corbin]

Add RISC-V 64-bit defconfig for QEMU virt machine.

Tested with QEMU 2.12.1

Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
---
 board/qemu/riscv64-virt/linux.config | 24 ++++++++++++++++++++++++
 board/qemu/riscv64-virt/readme.txt   | 22 ++++++++++++++++++++++
 configs/qemu_riscv64_virt_defconfig  | 24 ++++++++++++++++++++++++
 3 files changed, 70 insertions(+)
 create mode 100644 board/qemu/riscv64-virt/linux.config
 create mode 100644 board/qemu/riscv64-virt/readme.txt
 create mode 100644 configs/qemu_riscv64_virt_defconfig

diff --git a/board/qemu/riscv64-virt/linux.config b/board/qemu/riscv64-virt/linux.config
new file mode 100644
index 0000000000..bf9f4f5ab7
--- /dev/null
+++ b/board/qemu/riscv64-virt/linux.config
@@ -0,0 +1,24 @@
+CONFIG_ARCH_RV64I=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=8
+CONFIG_PCI=y
+CONFIG_SYSVIPC=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+# CONFIG_WIRELESS is not set
+CONFIG_VIRTIO_BLK=y
+CONFIG_NETDEVICES=y
+CONFIG_VIRTIO_NET=y
+# CONFIG_ETHERNET is not set
+# CONFIG_WLAN is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_VIRT_DRIVERS=y
+CONFIG_VIRTIO_MMIO=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT4_FS=y
+CONFIG_TMPFS=y
+
diff --git a/board/qemu/riscv64-virt/readme.txt b/board/qemu/riscv64-virt/readme.txt
new file mode 100644
index 0000000000..be563c969e
--- /dev/null
+++ b/board/qemu/riscv64-virt/readme.txt
@@ -0,0 +1,22 @@
+Run the emulation with:
+
+  qemu-system-riscv64 -M virt -kernel <path-to-bl>/bbl -append "root=/dev/vda ro console=ttyS0" -drive file=<path-to-buildroot>/output/images/rootfs.ext2,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -netdev user,id=net0 -device virtio-net-device,netdev=net0 -nographic
+
+The Buildroot generated vmlinux image will need to be combined with the Berkeley Boot Loader (BBL) as follows:
+
+  export RISCV=<path-to-buildroot>/output/host
+  export PATH=$PATH:$RISCV/bin
+  git clone https://github.com/riscv/riscv-pk
+  cd riscv-pk
+  mkdir build
+  cd build
+  ../configure \
+    --host=riscv64-buildroot-linux-gnu \
+    --with-payload=<path-to-buildroot>/output/images/vmlinux
+  make
+
+The resulting 'bbl' file can then be used with the qemu command above.
+  
+The login prompt will appear in the terminal that started Qemu.
+
+Tested with QEMU 2.12.92
diff --git a/configs/qemu_riscv64_virt_defconfig b/configs/qemu_riscv64_virt_defconfig
new file mode 100644
index 0000000000..387bf3b4c4
--- /dev/null
+++ b/configs/qemu_riscv64_virt_defconfig
@@ -0,0 +1,24 @@
+# Architecture
+BR2_riscv64=y
+
+# System
+BR2_SYSTEM_DHCP="eth0"
+
+# Filesystem
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_GENERIC_GETTY=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
+
+# Linux headers same as kernel, a 4.15 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_15=y
+
+# Kernel
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_GIT=y
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/riscv/riscv-linux.git"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="riscv-linux-4.15"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/riscv64-virt/linux.config"
+
+# Binutils configuration
+BR2_BINUTILS_VERSION_2_30_X=y
-- 
2.17.1

[Buildroot] [PATCH 1/1] configs/qemu: add qemu_riscv64_virt_defconfig

[Thomas Petazzoni]

Hello,

On Fri, 31 Aug 2018 15:38:53 +0100, Mark Corbin wrote:
> Add RISC-V 64-bit defconfig for QEMU virt machine.
> 
> Tested with QEMU 2.12.1
> 
> Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>

Thanks Mark for those contributions. Could you keep your RISC-V
contributions that depend on each other in a patch series, so that the
dependency between the patches is clear ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/1] configs/qemu: add qemu_riscv64_virt_defconfig

[Christopher McCrory]

On Fri, Aug 31, 2018 at 7:40 AM Mark Corbin <mark.corbin@embecosm.com>
wrote:

> Add RISC-V 64-bit defconfig for QEMU virt machine.
>
> Tested with QEMU 2.12.1
>
> Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
> ---
>  board/qemu/riscv64-virt/linux.config | 24 ++++++++++++++++++++++++
>  board/qemu/riscv64-virt/readme.txt   | 22 ++++++++++++++++++++++
>  configs/qemu_riscv64_virt_defconfig  | 24 ++++++++++++++++++++++++
>  3 files changed, 70 insertions(+)
>  create mode 100644 board/qemu/riscv64-virt/linux.config
>  create mode 100644 board/qemu/riscv64-virt/readme.txt
>  create mode 100644 configs/qemu_riscv64_virt_defconfig
>
>
<snip>

I've been using the Raspberry pi platform,  but I recently saw the HiFive1
[1] and want to try it out. So this patch came at at fortuitous time.

the defconfig as is works and boots up in qemu !
# cat /etc/os-release
NAME=Buildroot
VERSION=2018.08-rc3-00002-gf478e82db1
ID=buildroot
VERSION_ID=2018.08-rc3
PRETTY_NAME="Buildroot 2018.08-rc3"
# uname -a
Linux buildroot 4.15.0 #1 SMP Sat Sep 1 02:17:41 PDT 2018 riscv64 GNU/Linux
# cat /proc/cpuinfo
hart    : 0
isa    : rv64imafdcsu
mmu    : sv48

# dmesg
OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
Linux version 4.15.0 (chrismcc at wednesday) (gcc version 7.3.0 (Buildroot
2018.08-rc3-00002-gf478e82db1)) #1 SMP Sat Sep 1 02:17:41 PDT 2018

So:

Tested-by: Christopher McCrory <chrismcc@gmail.com>



I then added some more packeges, most failed loading libraries

perl works!
# perl -E "say 'Hello World!'"
Hello World!

# bash
bash: error while loading shared libraries: libreadline.so.7: cannot open
shared object file: No such file or directory

# ps ax
ps: error while loading shared libraries: libprocps.so.7: cannot open
shared object file: No such file or directory
# vim /tmp/foo
vim: error while loading shared libraries: libncurses.so.6: cannot open
shared object file: No such file or directory
# httpd -V
httpd: error while loading shared libraries: libpcre.so.1: cannot open
shared object file: No such file or directory

# lsmod
lsmod: error while loading shared libraries: libz.so.1: cannot open shared
object file: No such file or directory
# busybox lsmod
lsmod: /proc/modules: No such file or directory
Module                  Size  Used by    Not tainted

# tcpdump
tcpdump: error while loading shared libraries: libpcap.so.1: cannot open
shared object file: No such file or directory
# sudo pwd
sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"
sudo: unable to load /usr/libexec/sudo/sudoers.so: libz.so.1: cannot open
shared object file: No such file or directory
sudo: fatal error, unable to load plugins



[1] https://www.sifive.com/products/hifive1/


-- 
Christopher McCrory
To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180902/0ab6a031/attachment.html>

[Buildroot] [PATCH 1/1] configs/qemu: add qemu_riscv64_virt_defconfig

[Mark Corbin]

Hello Christopher

On 02/09/18 16:09, Christopher McCrory wrote:
>
>
> On Fri, Aug 31, 2018 at 7:40 AM Mark Corbin <mark.corbin@embecosm.com
> <mailto:mark.corbin@embecosm.com>> wrote:
>
>     Add RISC-V 64-bit defconfig for QEMU virt machine.
>
>     Tested with QEMU 2.12.1
>
>     Signed-off-by: Mark Corbin <mark.corbin@embecosm.com
>     <mailto:mark.corbin@embecosm.com>>
>     ---
>     ?board/qemu/riscv64-virt/linux.config | 24 ++++++++++++++++++++++++
>     ?board/qemu/riscv64-virt/readme.txt? ?| 22 ++++++++++++++++++++++
>     ?configs/qemu_riscv64_virt_defconfig? | 24 ++++++++++++++++++++++++
>     ?3 files changed, 70 insertions(+)
>     ?create mode 100644 board/qemu/riscv64-virt/linux.config
>     ?create mode 100644 board/qemu/riscv64-virt/readme.txt
>     ?create mode 100644 configs/qemu_riscv64_virt_defconfig
>
>
> <snip>
>
> I've been using the Raspberry pi platform,? but I recently saw the
> HiFive1 [1] and want to try it out. So this patch came at at
> fortuitous time.
The HiFive1 only has 16K of on-board RAM and no DRAM controller. To run
Linux you'd need a Hifive Unleashed. Alternatively, you can boot Linux
on a lowRISC core using a Nexys4 DDR FPGA board from Digilent which is
only $265. I plan to try this soon, but I haven't worked out how to
combine my Buildroot kernel image with the lowRISC version of the BBL
bootloader yet...another job for my TODO list.
>
> the defconfig as is works and boots up in qemu !
> # cat /etc/os-release
> NAME=Buildroot
> VERSION=2018.08-rc3-00002-gf478e82db1
> ID=buildroot
> VERSION_ID=2018.08-rc3
> PRETTY_NAME="Buildroot 2018.08-rc3"
> # uname -a
> Linux buildroot 4.15.0 #1 SMP Sat Sep 1 02:17:41 PDT 2018 riscv64
> GNU/Linux
> # cat /proc/cpuinfo
> hart??? : 0
> isa??? : rv64imafdcsu
> mmu??? : sv48
>
> # dmesg
> OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> Linux version 4.15.0 (chrismcc at wednesday) (gcc version 7.3.0
> (Buildroot 2018.08-rc3-00002-gf478e82db1)) #1 SMP Sat Sep 1 02:17:41
> PDT 2018
>
> So:
>
> Tested-by: Christopher McCrory <chrismcc@gmail.com
> <mailto:chrismcc@gmail.com>>
>
>
>
> I then added some more packeges, most failed loading libraries
>
> perl works!
> # perl -E "say 'Hello World!'"
> Hello World!
>
> # bash
> bash: error while loading shared libraries: libreadline.so.7: cannot
> open shared object file: No such file or directory
>
> # ps ax
> ps: error while loading shared libraries: libprocps.so.7: cannot open
> shared object file: No such file or directory
> # vim /tmp/foo
> vim: error while loading shared libraries: libncurses.so.6: cannot
> open shared object file: No such file or directory
> # httpd -V
> httpd: error while loading shared libraries: libpcre.so.1: cannot open
> shared object file: No such file or directory
>
> # lsmod
> lsmod: error while loading shared libraries: libz.so.1: cannot open
> shared object file: No such file or directory
> # busybox lsmod
> lsmod: /proc/modules: No such file or directory
> Module????????????????? Size? Used by??? Not tainted
>
> # tcpdump
> tcpdump: error while loading shared libraries: libpcap.so.1: cannot
> open shared object file: No such file or directory
> # sudo pwd
> sudo: error in /etc/sudo.conf, line 0 while loading plugin
> "sudoers_policy"
> sudo: unable to load /usr/libexec/sudo/sudoers.so: libz.so.1: cannot
> open shared object file: No such file or directory
> sudo: fatal error, unable to load plugins
I've tried this myself - looks like I have a library path issue to sort
out! The libraries appear to have been built correctly, I suspect that
they are just in unexpected locations.

Regards

Mark
>
>
>
> [1] https://www.sifive.com/products/hifive1/
>
> ?
> -- 
> Christopher McCrory
> To the optimist, the glass is half full.
> To the pessimist, the glass is half empty.
> To the engineer, the glass is twice as big as it needs to be.

-- 
Mark Corbin
Embecosm Ltd.
https://www.embecosm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180904/bb085bdf/attachment.html>

[Buildroot] [PATCH 1/1] configs/qemu: add qemu_riscv64_virt_defconfig

[Thomas Petazzoni]

Hello Mark,

On Fri, 31 Aug 2018 15:38:53 +0100, Mark Corbin wrote:
> Add RISC-V 64-bit defconfig for QEMU virt machine.
> 
> Tested with QEMU 2.12.1

Here you say 2.12.1, in the readme.txt file you say 2.12.92. I assume
one or the other has a typo :-)

>  board/qemu/riscv64-virt/linux.config | 24 ++++++++++++++++++++++++
>  board/qemu/riscv64-virt/readme.txt   | 22 ++++++++++++++++++++++
>  configs/qemu_riscv64_virt_defconfig  | 24 ++++++++++++++++++++++++
>  3 files changed, 70 insertions(+)

Please add an entry in the DEVELOPERS file. When you will do a patch
series with the base RISC-V support:

 - The patch introducing the RISC-V support should add an entry in the
   DEVELOPERS file for you, the arch/Config.in.riscv file and other
   files introduced by this first patch.

 - The patch introducing the RISC-V qemu defconfig should add more
   items to the DEVELOPERS file entry, to list the files related to
   this defconfig.

> diff --git a/board/qemu/riscv64-virt/readme.txt b/board/qemu/riscv64-virt/readme.txt
> new file mode 100644
> index 0000000000..be563c969e
> --- /dev/null
> +++ b/board/qemu/riscv64-virt/readme.txt
> @@ -0,0 +1,22 @@
> +Run the emulation with:
> +
> +  qemu-system-riscv64 -M virt -kernel <path-to-bl>/bbl -append "root=/dev/vda ro console=ttyS0" -drive file=<path-to-buildroot>/output/images/rootfs.ext2,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -netdev user,id=net0 -device virtio-net-device,netdev=net0 -nographic
> +
> +The Buildroot generated vmlinux image will need to be combined with the Berkeley Boot Loader (BBL) as follows:
> +
> +  export RISCV=<path-to-buildroot>/output/host
> +  export PATH=$PATH:$RISCV/bin
> +  git clone https://github.com/riscv/riscv-pk
> +  cd riscv-pk
> +  mkdir build
> +  cd build
> +  ../configure \
> +    --host=riscv64-buildroot-linux-gnu \
> +    --with-payload=<path-to-buildroot>/output/images/vmlinux
> +  make

Then we want to create a package for the BBL, in boot/riscv-pk/. See
boot/boot-wrapper-aarch64/ for an example of bootloader wraps the
kernel image. It depends on the kernel build in Config.in:

config BR2_TARGET_BOOT_WRAPPER_AARCH64
        bool "boot-wrapper-aarch64"
        depends on BR2_aarch64
        depends on BR2_LINUX_KERNEL

And then in the .mk file, we ensure the Linux kernel is built before:

BOOT_WRAPPER_AARCH64_DEPENDENCIES = linux

And we pass the path to the kernel tree (which it needs to get the
kernel image):

BOOT_WRAPPER_AARCH64_CONF_OPTS = \
        --with-kernel-dir=$(LINUX_DIR) \

> +# Filesystem
> +BR2_TARGET_ROOTFS_EXT2=y
> +BR2_TARGET_GENERIC_GETTY=y
> +BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
> +
> +# Linux headers same as kernel, a 4.15 series
> +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_15=y
> +
> +# Kernel
> +BR2_LINUX_KERNEL=y
> +BR2_LINUX_KERNEL_CUSTOM_GIT=y
> +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/riscv/riscv-linux.git"
> +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="riscv-linux-4.15"

This is a branch, so its contents can change anytime. Please use a tag,
of if there's not tag, a full SHA1 designating a specific commit.

> +BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/riscv64-virt/linux.config"
> +
> +# Binutils configuration
> +BR2_BINUTILS_VERSION_2_30_X=y

This should not be needed, because you prevent using binutils 2.28 and
2.29 anyway.

Could you fix those comments, and send an updated version?

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/1] configs/qemu: add qemu_riscv64_virt_defconfig

[Mark Corbin]

Hello Thomas

On 02/09/18 20:47, Thomas Petazzoni wrote:
> Hello Mark,
>
> On Fri, 31 Aug 2018 15:38:53 +0100, Mark Corbin wrote:
>> Add RISC-V 64-bit defconfig for QEMU virt machine.
>>
>> Tested with QEMU 2.12.1
> Here you say 2.12.1, in the readme.txt file you say 2.12.92. I assume
> one or the other has a typo :-)
Oops..typo on my part. I did test against both versions in fact, but
I'll stick with 2.12.1 as it is an official release.
>
>>  board/qemu/riscv64-virt/linux.config | 24 ++++++++++++++++++++++++
>>  board/qemu/riscv64-virt/readme.txt   | 22 ++++++++++++++++++++++
>>  configs/qemu_riscv64_virt_defconfig  | 24 ++++++++++++++++++++++++
>>  3 files changed, 70 insertions(+)
> Please add an entry in the DEVELOPERS file. When you will do a patch
> series with the base RISC-V support:
>
>  - The patch introducing the RISC-V support should add an entry in the
>    DEVELOPERS file for you, the arch/Config.in.riscv file and other
>    files introduced by this first patch.
>
>  - The patch introducing the RISC-V qemu defconfig should add more
>    items to the DEVELOPERS file entry, to list the files related to
>    this defconfig.
>
>> diff --git a/board/qemu/riscv64-virt/readme.txt b/board/qemu/riscv64-virt/readme.txt
>> new file mode 100644
>> index 0000000000..be563c969e
>> --- /dev/null
>> +++ b/board/qemu/riscv64-virt/readme.txt
>> @@ -0,0 +1,22 @@
>> +Run the emulation with:
>> +
>> +  qemu-system-riscv64 -M virt -kernel <path-to-bl>/bbl -append "root=/dev/vda ro console=ttyS0" -drive file=<path-to-buildroot>/output/images/rootfs.ext2,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -netdev user,id=net0 -device virtio-net-device,netdev=net0 -nographic
>> +
>> +The Buildroot generated vmlinux image will need to be combined with the Berkeley Boot Loader (BBL) as follows:
>> +
>> +  export RISCV=<path-to-buildroot>/output/host
>> +  export PATH=$PATH:$RISCV/bin
>> +  git clone https://github.com/riscv/riscv-pk
>> +  cd riscv-pk
>> +  mkdir build
>> +  cd build
>> +  ../configure \
>> +    --host=riscv64-buildroot-linux-gnu \
>> +    --with-payload=<path-to-buildroot>/output/images/vmlinux
>> +  make
> Then we want to create a package for the BBL, in boot/riscv-pk/. See
> boot/boot-wrapper-aarch64/ for an example of bootloader wraps the
> kernel image. It depends on the kernel build in Config.in:
>
> config BR2_TARGET_BOOT_WRAPPER_AARCH64
>         bool "boot-wrapper-aarch64"
>         depends on BR2_aarch64
>         depends on BR2_LINUX_KERNEL
>
> And then in the .mk file, we ensure the Linux kernel is built before:
>
> BOOT_WRAPPER_AARCH64_DEPENDENCIES = linux
>
> And we pass the path to the kernel tree (which it needs to get the
> kernel image):
>
> BOOT_WRAPPER_AARCH64_CONF_OPTS = \
>         --with-kernel-dir=$(LINUX_DIR) \

I had been reluctant to add riscv-pk to Buildroot as a bootloader, as I
see it as an interim solution until riscv support makes it into UBoot or
Barebox. On the other hand, riscv kernel images aren't much use without
it at the moment.

I do have a preliminary riscv-pk package working based on your helpful
pointers to boot-wrapper-aarch64. Do people prefer to add it as
'risc-pk' when it is only the Berkeley Boot Loader part that is
significant? I would have added it as 'bbl', but I can see the potential
confusion when the package/repository is 'riscv-pk'.

Regards

Mark

-- 
Mark Corbin
Embecosm Ltd.
https://www.embecosm.com

[Buildroot] [PATCH 1/1] configs/qemu: add qemu_riscv64_virt_defconfig

[Arnout Vandecappelle]

On 04/09/2018 17:14, Mark Corbin wrote:
> I had been reluctant to add riscv-pk to Buildroot as a bootloader, as I
> see it as an interim solution until riscv support makes it into UBoot or
> Barebox.

 If riscv-pk/bbl offers all the features you need, why would you use U-Boot or
Barebox?

> On the other hand, riscv kernel images aren't much use without
> it at the moment.
> 
> I do have a preliminary riscv-pk package working based on your helpful
> pointers to boot-wrapper-aarch64. Do people prefer to add it as
> 'risc-pk' when it is only the Berkeley Boot Loader part that is
> significant? I would have added it as 'bbl', but I can see the potential
> confusion when the package/repository is 'riscv-pk'.

 Unless there is some convincing reason for it, we prefer to stick with the
upstream name.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/1] configs/qemu: add qemu_riscv64_virt_defconfig

[Thomas Petazzoni]

Hello,

On Tue, 4 Sep 2018 21:57:11 +0200, Arnout Vandecappelle wrote:
> On 04/09/2018 17:14, Mark Corbin wrote:
> > I had been reluctant to add riscv-pk to Buildroot as a bootloader, as I
> > see it as an interim solution until riscv support makes it into UBoot or
> > Barebox.  
> 
>  If riscv-pk/bbl offers all the features you need, why would you use U-Boot or
> Barebox?

For the same reason that you use U-Boot or Barebox on real hardware,
rather than a completely dumb "kernel loader": shell, environment
variables, scripting, etc. I'm not saying this is always needed, but it
seems like some people like those features :-)

> > I do have a preliminary riscv-pk package working based on your helpful
> > pointers to boot-wrapper-aarch64. Do people prefer to add it as
> > 'risc-pk' when it is only the Berkeley Boot Loader part that is
> > significant? I would have added it as 'bbl', but I can see the potential
> > confusion when the package/repository is 'riscv-pk'.  
> 
>  Unless there is some convincing reason for it, we prefer to stick with the
> upstream name.

I agree. It's true that besides the BBL, there is not much in the
riscv-pk repo that would be useful in the context of Buildroot, but
riscv-pk is just as good as riscv-bbl, and riscv-pk has the advantage
of matching the upstream name.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com