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

[Peter Korsgaard <peter@korsgaard.com>]

>>>>> "Damien" == Damien Le Moal <Damien.LeMoal@wdc.com> writes:

Hi,

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

Thanks.

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

Ok. Would BR2_PACKAGE_BUSYBOX_INDIVIDUAL_BINARIES make sense to save RAM
on NOMMU (I don't really have any nommu experience)?

From a maintenance PoV I would prefer to keep the number of busybox
configs to a minimum, but if we cannot get it to work properly with a
(possibly tweaked) busybox-minimal, then so be it.


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

Interesting, why does init fail but /bin/sh doesn't? It is the same
busybox binary, and init does not look that big:

size init/lib.a shell/hush.o
   text    data     bss     dec     hex filename
    635       0       0     635     27b halt.o (ex init/lib.a)
   5907       0       0    5907    1713 init.o (ex init/lib.a)
  51649     904       0   52553    cd49 shell/hush.o

Is it because of the scripts that init executes?


 > 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 :)

;)

If we could get the normal init working, then the mounts would be
working. A logo could be printed by getty (see our
BR2_TARGET_GENERIC_ISSUE logic).


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

Ok, can you just add a small comment to the file to explain that?


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

BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="<version>"

See the other defconfigs for examples.


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

Odd. This was with a clean build on current master after applying your
patch 5.


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

Ok, thanks.


 >> > +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 think it makes sense to add it now, it is quite easy to do. See
package/Config.in.host and one of the packages listed there,
E.G. python-lxml. Also see the documentation:

https://buildroot.org/downloads/manual/manual.html#_literal_config_in_host_literal_file


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

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

I believe it should be. It would make it more similar to other boards
and a bit faster/easier to update.


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

How does XIP work with cpio/initramfs? Isn't XIP about storing the
application uncompressed in a filesystem in the flash and executing it
directly from there?

How about XIP for the kernel?


 > Let me dig again in elf2flt to see if I can get something more solid.

Great, thanks!

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot