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

[Damien Le Moal <Damien.LeMoal@wdc.com>]

On 2021/10/28 10:21, Sean Anderson wrote:
> On 10/27/21 9:07 PM, Damien Le Moal wrote:
>> On 2021/10/27 22:51, Peter Korsgaard wrote:
>>>   > 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.
>>
>>> 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).
>>
>>>   > 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 :)
>>
>>>   > 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.
>>
>>>   > 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 ?
>>
>>>
>>> I gave it a try here, and it fails to boot with 5.14.14:
>> [...]> [    0.253373] i2c /dev entries driver
>>> [    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.
>>
>>>   > +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.

> 
>>>   > +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.

>> 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.

>>> 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/
> 
> --Sean
> 


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