[Buildroot] [PATCH 5/5] Add support for Kendryte K210 based RISC-V boards
Thomas Petazzoni
thomas.petazzoni at bootlin.com
Tue Sep 8 09:07:14 UTC 2020
Hello Damien,
On Tue, 8 Sep 2020 08:02:15 +0000
Damien Le Moal <Damien.LeMoal at wdc.com> wrote:
> > configs/qemu_arm_versatile_nommu_defconfig:BR2_PACKAGE_BUSYBOX_CONFIG="package/busybox/busybox-minimal.config"
> > configs/qemu_m68k_mcf5208_defconfig:BR2_PACKAGE_BUSYBOX_CONFIG="package/busybox/busybox-minimal.config"
> > configs/stm32f429_disco_defconfig:BR2_PACKAGE_BUSYBOX_CONFIG="package/busybox/busybox-minimal.config"
> > configs/stm32f469_disco_defconfig:BR2_PACKAGE_BUSYBOX_CONFIG="package/busybox/busybox-minimal.config"
> >
> > Could you try to use this one ?
>
> Yes, the minimal config work. but it gives me a rootfs cpio image of 650KB
> while the one I added is even smaller and results in a rootf of 350KB. 300KB
> saved on a board with only 8MB of SRAM, that is not negligible...
Agreed. Perhaps we should change our busybox-minimal.config ? It would
be nice to diff yours against busybox-minimal.config and see if we can
get to a common conclusion.
As you can imagine, we're trying to avoid the situation where every
single board would have its own custom Busybox configuration file, with
a semi-random selection of tools.
> >> +# Minimal device set before mounting devtpmfs
> >> +/dev/null c 666 0 0 1 3 0 0 -
> >> +/dev/zero c 666 0 0 1 5 0 0 -
> >> +/dev/random c 666 0 0 1 8 0 0 -
> >> +/dev/urandom c 666 0 0 1 9 0 0 -
> >> +/dev/console c 666 0 0 5 1 - - -
> >> +/dev/tty c 666 0 0 5 0 - - -
> >> +/dev/tty0 c 666 0 0 4 0 0 0 -
> >> +/dev/ttySIF0 c 666 0 0 4 64 0 0 -
> >> +/dev/ptmx c 666 0 0 5 2 - - -
> >
> > I see in your /init script that you are mount devtmpfs, so a custom
> > device table for static /dev should not be needed. Could you explain
> > why this device table is necessary ?
>
> The init process is just a shell. So if I do not create at least the console
> files, I see errors "could not open console" when the init process is started by
> the kernel as devtmpfs is not yet mounted. Will check again.
If you enable BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS, then
Buildroot doesn't use any static device table, but since in the
initramfs case devtmpfs is not mounted by the kernel, /dev/console is
created anyway by Buildroot in the image. See fs/cpio/cpio.mk:
define ROOTFS_CPIO_ADD_INIT
if [ ! -e $(TARGET_DIR)/init ]; then \
$(INSTALL) -m 0755 fs/cpio/init $(TARGET_DIR)/init; \
fi
mkdir -p $(TARGET_DIR)/dev
mknod -m 0622 $(TARGET_DIR)/dev/console c 5 1
endef
So, /dev/console should be there without having a custom device table.
This should allow your /init script to run and mount devtmpfs.
BTW, you probably want your /init script to be modeled after
fs/cpio/init, except for the last line where you would exec /bin/sh
instead of exec /sbin/init of course.
> >> +rm -rf "$TARGET_DIR"/var/www > /dev/null 2>&1
> >> +rm -rf "$TARGET_DIR"/media > /dev/null 2>&1
> >
> > What is in /var/www and /media that takes so much space? In a default
> > Buildroot configuration, those folders should be empty.
>
> They are. Frankly, I could drop this. But as that is totally not needed,
> removing them can save a block or so on the cpio image. Memory saving again, but
> likely not much here.
OK, we could keep that I guess then. No need for the >/dev/null 2>&1 I
guess, since rm -rf ignores errors.
> >> diff --git a/board/kendryte/k210/patches/uclibc/0001-Revert-Fix-static-linking-with-GCC-10.patch b/board/kendryte/k210/patches/uclibc/0001-Revert-Fix-static-linking-with-GCC-10.patch
> >
> > None of the uClibc patches here are board-specific, so they should be
> > added to package/uclibc/. In fact, I think the gcc10 patches would fix
> > some build issues we have in our autobuilders:
> >
> > http://autobuild.buildroot.net/?reason=uclibc-1.0.35
>
> I could not get gcc10 builds to work. The static build is broken and uclibc seem
> to imply as much. As I was afraid of the potential impact of these patches on
> other builds, I put them as board specific for now. I intend to send them to
> uclibc too. Thoughts ? Should I keep this as is for now ?
We need to look more closely at the patches, but having them
board-specific is not ideal. Perhaps this is something that can be
worked on with upstream uClibc?
> > So with the normal Busybox init you don't have enough memory? Is this
> > platform using XIP, or is the code loaded into SRAM ? Indeed, 8 MB of
> > SRAM is quite a lot if you are running code from flash. But if indeed
> > the entire kernel is loaded into SRAM because you don't have XIP
> > support, the story is a bit different.
>
> No XIP. Kernel + embedded initramfs and dtb all end up in memory. SD card is not
> working yet, so this is really the only solution for now. Once I get the SD card
> to work, the initramfs can go onto the SD card, which will improve things.
OK. But supporting the SD card will not improve the memory consumption,
just give you more storage space.
> But for now, it is very easy to trigger the oom killer in init phase if care is
> not taken. And I did see it with the default busybox /init shell + /sbin/init
> process. Hence this small init shell script which only mounts devtmpfs and proc
> and exec a shell.
Indeed.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
More information about the buildroot
mailing list