initramfs doesn't get linked into kernel

Hi all,

I'm trying to figure out how to get the initramfs image linked in to my kernel zImage. I have selected BR2_TARGET_ROOTFS_INITRAMFS (the only option I can find in the menuconfig containing 'initramfs') but nothing gets linked in to my kernel.

I am using a custom kernel config, and I tried putting the filename of the buildroot-generated .cpio image in as CONFIG_INITRAMFS_SOURCE which linked in successfully, but then it won't boot as it appears you are supposed to put an initramfs configuration filename here instead.

Is it correct that I have to manually put something into CONFIG_INITRAMFS_SOURCE? If so, what should I place here to use the rootfs generated by buildroot?

Many thanks,
Adam.

Dear Adam Nielsen,

If you let Buildroot build your kernel, it does that automatically (see the code in linux/linux.mk). If you build your kernel outside of Buildroot, you have to set CONFIG_INITRAMFS_SOURCE correctly.

If you build your kernel outside of Buildroot, pointing CONFIG_INITRAMFS_SOURCE to the .cpio image works just fine. I'm doing that all the time here. Here's what I have in my kernel configuration:

CONFIG_INITRAMFS_SOURCE="../marvell-rootfs/images/rootfs.cpio"

Could you attach your Buildroot .config, and your kernel configuration file (output/build/linux-x.y.z/.config if you build your kernel with Buildroot) ?

Thanks,

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Hi Thomas,

Ahh ok, so what I did should have worked then. Since then I have added Ethernet support for my board and tried booting with a root filesystem on NFS.
This worked (it mounted the filesystem) but it doesn't seem to be able to
run the init binary (in this case Busybox built by buildroot.) Looking at tcpdump it correctly follows the symlinks and appears to download the busybox binary, but then fails saying it couldn't find init.

I'm not quite sure what the problem is (I'm wondering whether it's a compatibility issue like OABI vs EABI or something) but it's possible this is what was causing the apparent initramfs failure, since it's the same filesystem (I just unzipped the .tar of the root filesystem that buildroot generated, into the NFS share.) I built the kernel with and without EABI support though and there was no difference, so I'm not really sure what it might be.

I'll keep looking into the problem until I'm able to boot with root on NFS, then I'll try initramfs again to see if that works, and report back.

Thanks again,
Adam.

Dear Adam Nielsen,

Again, please post your Buildroot .config and kernel .config. Another issue you might be having if you're building your kernel outside of Buildroot is that you may have enabled the usage of devtmpfs as the /dev strategy, but forgot to enable CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT in your kernel configuration. See
http://buildroot.org/downloads/manual/manual.html#_dev_management for more details.

Best regards,

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Sorry, I didn't post them because I didn't think it would be easy to solve - here they are:

http://www.shikadi.net/files/buildroot/2013-04-28.br.cannot_run_init.config
http://www.shikadi.net/files/buildroot/2013-04-28.k.cannot_run_init.config

I don't think it's an issue with /dev as I don't think the kernel gets that far in the boot process. I am building the kernel outside of buildroot while I'm testing (and I can only do OABI here) but I also copied my changes across and built it through buildroot (so I could enable EABI in the kernel config) but there was no change.

I'll keep investigating, but let me know if you have any insight!

Many thanks,
Adam.

I think I've discovered the problem here. buildroot produces ELF binaries, but I cannot compile a kernel with ELF support because BINFMT_ELF depends on MMU and my platform is arm7tdmi which does not have an MMU.

This means I need to tell buildroot to produce FLAT executables instead of ELF ones. I have enabled elf2flt support in the buildroot config, but it still produces ELF binaries.

Is there an option I am missing to make buildroot generate FLAT executables instead?

Thanks,
Adam.

Dear Adam Nielsen,

I think the elf2flt stuff hasn't been used in a while, so it isn't very surprising that it is broken. Your patches are definitely welcome to fix it, and once it's fixed, I'll add a new toolchain configuration in our autobuilders to test this configuration on a regular basis.

Best regards,

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

I'm happy to do my best to try to fix this, but I'm afraid I might need a little help as I'm not too familiar with buildroot.

I have worked out this so far:

- In order to enable FLAT binaries, you need to disable MMU support in
uClibc. Deselecting the buildroot option BR2_USE_MMU does not change the uClibc option. I am guessing this should happen automatically, but not quite sure how to achieve it.

- Disabling MMU support in uClibc stops the thread components from
compiling. Apparently this is a bug in uClibc? (something about fork() being called vfork() instead)

- Disabling threads entirely in both uClibc and buildroot gets past that
previous problem, but gcc-final then does not compile as some components (libitm and libatomic) need thread support. I am not sure how to tell buildroot to ask GCC to skip compiling libitm and libatomic when thread support has been disabled.

Any tips on this would be much appreciated!

Many thanks,
Adam.

Dear Adam Nielsen,

Most likely should be done in toolchain/uClibc/uclibc.mk.

If uClibc doesn't build for a given configuration, it's definitely something that can be reported to the uClibc developers.

Hum, this is strange, because we do regularly test no-thread toolchains, but not for all gcc versions. Which gcc versions have you tried?

Best regards,

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Ah yes, got this working, thanks. As a side note, in buildroot itself, when BR2_HAS_MMU is *deselected* it should force BR2_ELF2FLT on. I can't see how to do this (set BR2_ELF2FLT to be the inverse of BR2_HAS_MMU) unless I add a dummy option like this:

config BR2_FORCE_ELF2FLT
bool
default y if !BR2_USE_MMU
select BR2_ELF2FLT

Is this correct? It's the only way I can come up with to select another option in response to an option being deselected.

Thanks, I have submitted a bug for this with sample configuration files.

This is with GCC 4.8.0. I was able to get around the problem by adding this to toolchain/gcc/gcc-uclibc-4.x.mk:

# Disable threading when thread implementation is 'none' ifeq ($(BR2_PTHREADS_NONE),y)

EXTRA_GCC_CONFIG_OPTIONS += \
         --enable-threads=single \
         --disable-libitm \
         --disable-libatomic \
         --disable-libmudflap

endif

I'm not sure if this is the correct solution though given your comment about it being regularly tested. If it is I'm happy to submit patches for this stuff if that's easier.

However it may be because disabling thread support in buildroot does not disable thread support in uClibc. The two options must be set manually. It could also be because I am compiling everything without MMU support, if that's not widely tested.

Thanks again,
Adam.

Please ignore this point, it was because I wasn't doing a 'make clean' after disabling thread support, so the uClibc config file wasn't being regenerated.

But the rest of my previous message still applies even after a 'make clean'.

Cheers,
Adam.