[Buildroot] initramfs doesn't get linked into kernel

[Buildroot] initramfs doesn't get linked into kernel

[Adam Nielsen]

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.

[Buildroot] initramfs doesn't get linked into kernel

[Thomas Petazzoni]

Dear Adam Nielsen,

On Sat, 27 Apr 2013 09:37:59 +1000, Adam Nielsen wrote:

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

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

[Buildroot] initramfs doesn't get linked into kernel

[Adam Nielsen]

Hi Thomas,

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

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.

[Buildroot] initramfs doesn't get linked into kernel

[Thomas Petazzoni]

Dear Adam Nielsen,

On Sat, 27 Apr 2013 19:53:20 +1000, Adam Nielsen wrote:

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

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

[Buildroot] initramfs doesn't get linked into kernel

[Adam Nielsen]

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

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.

[Buildroot] initramfs doesn't get linked into kernel

[Adam Nielsen]

>    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'll keep investigating, but let me know if you have any insight!

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.

[Buildroot] initramfs doesn't get linked into kernel

[Thomas Petazzoni]

Dear Adam Nielsen,

On Sat, 04 May 2013 10:29:51 +1000, Adam Nielsen wrote:

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

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

[Buildroot] initramfs doesn't get linked into kernel

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

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.

[Buildroot] initramfs doesn't get linked into kernel

[Thomas Petazzoni]

Dear Adam Nielsen,

On Sat, 04 May 2013 21:35:09 +1000, Adam Nielsen wrote:

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

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

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

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

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

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

[Buildroot] initramfs doesn't get linked into kernel

[Adam Nielsen]

>>    - 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.
>
> Most likely should be done in toolchain/uClibc/uclibc.mk.

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.

>>    - 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)
>
> If uClibc doesn't build for a given configuration, it's definitely
> something that can be reported to the uClibc developers.

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

>>    - 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.
>
> Hum, this is strange, because we do regularly test no-thread
> toolchains, but not for all gcc versions. Which gcc versions have you
> tried?

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.

[Buildroot] initramfs doesn't get linked into kernel

[Adam Nielsen]

> However it may be because disabling thread support in buildroot does not
> disable thread support in uClibc.  The two options must be set manually.

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.