Re: [Buildroot] [PATCH v5 05/10] board: Add Sipeed MAIX-bit support

On 2021/10/28 10:21, Sean Anderson wrote:

On 10/27/21 9:07 PM, Damien Le Moal wrote:

quoted

On 2021/10/27 22:51, Peter Korsgaard wrote:

quoted

  > diff --git a/board/canaan/k210-common/busybox-tiny.config b/board/canaan/k210-common/busybox-tiny.config
  > new file mode 100644
  > index 0000000000..7adcaf1db9
  > --- /dev/null
  > +++ b/board/canaan/k210-common/busybox-tiny.config
  > @@ -0,0 +1,241 @@
  > +#
  > +# Additional config changes for busybox-minimal.config
  > +# to reduce the size of the busybox executable.
  > +#
  > +
  > +#
  > +# Settings
  > +#
  > +# CONFIG_INCLUDE_SUSv2 is not set
  > +# CONFIG_LONG_OPTS is not set
  > +# CONFIG_LFS is not set
  > +# CONFIG_FEATURE_DEVPTS is not set
  > +# CONFIG_FEATURE_SYSLOG_INFO is not set
  > +# CONFIG_FEATURE_SYSLOG is not set
  > +
  > +#
  > +# Build Options
  > +#
  > +CONFIG_NOMMU=y

That is already taken care of in package/busybox/busybox.mk

Right. I overlooked that. This should not be needed. Will check.

quoted

Did you verify if all of these tweaks are needed? This looks pretty
extensive. Perhaps we should update busybox-minimal with some of these
instead?

busybox-minimal is fine but gives a larger busybox executable. I added this tiny
config to save memory when running and avoid failures due to memory allocation
when executing complex-ish shell commands spawning multiple shells (e.g. pipes).

quoted

  > diff --git a/board/canaan/k210-common/rootfs_overlay/init b/board/canaan/k210-common/rootfs_overlay/init
  > new file mode 120000
  > index 0000000000..a0b71977c0
  > --- /dev/null
  > +++ b/board/canaan/k210-common/rootfs_overlay/init
  > @@ -0,0 +1 @@
  > +/sbin/init
  > \ No newline at end of file

Why? Isn't fs/cpio/init suitable?

In the past, I was getting errors mounting devtmpfs. Trying again now, it seems
to be working as expected. This added init does adds mount of sysfs and procfs
for convenience, but the main point is that the last exec starts the interactive
shell instead of /sbin/init. The default busybox init executable is way too big
and fails to run.

I could just overlay /sbin/init as a symlink to /bin/sh.

I do like the sysfs and proc automatic mount though, and the cute logo added :)

quoted

  > diff --git a/board/canaan/k210-common/rootfs_overlay/sbin/init b/board/canaan/k210-common/rootfs_overlay/sbin/init
  > new file mode 100755
  > index 0000000000..6ec4748c03
  > --- /dev/null
  > +++ b/board/canaan/k210-common/rootfs_overlay/sbin/init
  > @@ -0,0 +1,27 @@
  > +#!/bin/sh
  > +
  > +# Mount sysfs and procfs
  > +/bin/mount -t sysfs sysfs /sys
  > +/bin/mount -t proc proc /proc
  > +
  > +# Use the /dev/console device node from devtmpfs if possible to not
  > +# confuse glibc's ttyname_r().
  > +# This may fail (E.G. booted with console=), and errors from exec will
  > +# terminate the shell, so use a subshell for the test
  > +if (exec 0</dev/console) 2>/dev/null; then
  > +    exec 0</dev/console
  > +    exec 1>/dev/console
  > +    exec 2>/dev/console
  > +fi
  > +
  > +# Print a fun logo :)
  > +echo "          __  _"
  > +echo "         / / (_) ____   _   _ __  __"
  > +echo "        / /  | ||  _ \\ | | | |\\ \\/ /"
  > +echo "       / /___| || | | || |_| | >  < "
  > +echo "      /_____/|_||_| |_| \\____|/_/\\_\\"
  > +echo "    64-bits RISC-V Kendryte K210 NOMMU"
  > +echo ""
  > +
  > +# Start interactive shell
  > +exec /bin/sh

Cute, but why can't we use the normal busybox init / inittab?

The default binary init is way too big and fails to run (ENOMEM). Even if we
could run it, it would stay around and consume memory for nothing.
That is why I just go straight to an interactive shell here.

quoted

  > diff --git a/configs/sipeed_maix_bit_defconfig b/configs/sipeed_maix_bit_defconfig
  > new file mode 100644
  > index 0000000000..bbbe00d44d
  > --- /dev/null
  > +++ b/configs/sipeed_maix_bit_defconfig
  > @@ -0,0 +1,14 @@
  > +BR2_riscv=y
  > +BR2_PACKAGE_HOST_ELF2FLT=y
  > +# BR2_USE_MMU is not set
  > +BR2_INIT_NONE=y
  > +BR2_ROOTFS_OVERLAY="board/canaan/k210-common/rootfs_overlay"
  > +BR2_LINUX_KERNEL=y

You don't specify the kernel version, so it will change every time we
bump it, please specify a known good version.

Any version including and above 5.13 work fine. How do I do that ?

quoted

I gave it a try here, and it fails to boot with 5.14.14:

[...]> [    0.253373] i2c /dev entries driver

quoted

[    0.258022] random: get_random_bytes called from 0x000000008000569a with crng_init=0
[    0.271672] Freeing unused kernel image (initmem) memory: 608K
[    0.276809] This architecture does not have kernel memory protection.
[    0.283241] Run /init as init process
[    0.289488] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[    0.296422] SMP: stopping secondary CPUs
[    0.300340] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 ]---

Any idea why?

I was getting the same when elf2flt had problems (buggy relocation). What I sent
is working for me doing this:

make clean
make sipeed_maix_bit_defconfig
make

And flashing loader.bin gives me a working shell.

Not sure what is going on. It seems that elf2flt riscv support is still very
fragile. I need to address the comments I got on my PR and dig further to check
that I am not overlooking anything.

quoted

  > +BR2_LINUX_KERNEL_DEFCONFIG="nommu_k210"
  > +BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/sipeed/maix-bit/linux-dtb.config"
  > +BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y
  > +BR2_LINUX_KERNEL_IMAGE_NAME="loader.bin"

I see you are adding documentation at the end of the series, but perhaps
it would make sense to add a host package for python3-kflash to make
this work out of the box?

Yes, we could. Do you want this with this series ? Or adding it later is OK ?
I need to check how to add a host package. Not sure how to do that...

I suggest [1]. It is faster. Though if you want to compile your own
'ISP' it will take a bit of tweaking.

[1] https://github.com/loboris/ktool

Just tried this and it does not work for me. I get:

Greeting fail, check serial port (SLIP receive timeout (wait frame start))

Tried different options, baudrate etc, but all give the same. Not sure what is
going on.

quoted

quoted

  > +BR2_LINUX_KERNEL_DEFCONFIG="nommu_k210_sdcard"
  > +BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/sipeed/maix-bit/linux-dtb.config"
  > +BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y
  > +BR2_LINUX_KERNEL_IMAGE_NAME="loader.bin"
  > +BR2_PACKAGE_BUSYBOX_CONFIG="package/busybox/busybox-minimal.config"
  > +# BR2_PACKAGE_IFUPDOWN_SCRIPTS is not set
  > +BR2_TARGET_ROOTFS_EXT2=y

We have genimage in buildroot so it is easy to create a full sd card
image with the right partition as well. I also see that there is some
k210 support in u-boot nowadays, would a setup with u-boot in the SPI
flash and kernel + rootfs on the SD card not be nicer?

+Sean who did all the k210 U-Boot work.

This should work. I have not tested with a recent kernel. If you have
/{uImage,k210.dtb} on the mmc it will be loaded. See
include/configs/sipeed-maix.h for details. And feel free to send a patch
to adapt that to your use-case.

OK. Will give it a try after revisiting elf2flt.

quoted

I have not tried but I think it should work. And as long as the final memory
usage is the same (e.g. U-Boot not sticking around in memory), things should be
all OK.

It doesn't stick around. No SBI either so Linux owns the whole machine
once it comes up.

Great. There should be no issue then.

quoted

quoted

Any specific reason to keep the kernel in the SPI flash?

Not really for now. It is just very simple to use :)

Going forward though, I hope to be able to use XIP to execute busybox from there
directly. There are patches out there for this board and got report that it is
working with nommu. But that is more for the cpio case than the sdcard case.

Can you link to that series? I made an attempt in [2] but never went
beyond reading (and perhaps writing? I don't remember).

I do not have the patches nor a link to them. The developer mentioned that he
has it running on 5.13 on the Maixduino board. Let me ping him again to get a
status update.

[2] https://lore.kernel.org/u-boot/20210205043924.149504-1-seanga2@gmail.com/ (local)

--Sean

-- 
Damien Le Moal
Western Digital Research
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot