I'm building a lightweight distribution for the Raspberry Pi (dedicated to mpd player).
As I'd like to add an filesystem extender (like raspbian) I need resize2fs to be build.
But even if in menuconfig I select target -> FS tools-> e2fsprogs -> resize2fs, this binary is not built.
Can't figure why!
Have you got any explanation?
If you enable resize2fs after having already built e2fsprogs, then you need to reconfigure e2fsprogs:
make menuconfig, enable resize2fs
make e2fsprogs-dirclean
make
This is because resize2fs is not a Buildroot package, it is an optional component of the e2fsprogs package. And since Buildroot does not track changes to the package configuration, it does not know it has to rebuild the package in this case.
To better understand, read the Buildroot manual section 8.3. Understanding how to rebuild packages. Section 8.2. Understanding when a full rebuild is necessary would is very useful too.
Related
I have a custom board with imx6dl chip and peripherals. I have compiled u-boot, zImage and rootfs from examples provided by manufacturer. But when i try to build yocto from git repo with latests releases, it fails to run (some drivers not working, board is loading and display interface, but touchscreen is not working for ex.),
Is there any way to include precompiled binaries zImage, u-boot and device table to bitbake recipes? I'm very new to yocto project, and only need to get bootable image with working drivers and qt5.
If you have a working boot chain (e.g. u-boot, kernel and device tree) that you have built out-of-yocto, then you might try building a rootfs only. This requires two main settings, to be made in your local.conf to get started. Please don't firget that this is just a starting point, and it is highly advised to get the kernel/bootloader build sorted out really soon.
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy to have no kernel being built, and something like MACHINE="qemuarm" to set up an armv7 build on poky later than version 3.0. The core-image-minimal target should at least be enough to drop you in a shell for starters, and then you can proceed from there.
Additionally, it might be qorth asking the board vendor or the yocto community (#yocto on the freenode server) if they know about a proper BSP layer. FSL things are quite nicely supported these days, and if your board is closely related to one of the well-known ones, you've got a high chance that meta-freescale just does the trick nicely.
Addition:
#Martin pointed out the mention of Qemu is misleading. This is just the easiest way to make Yocto build a userland for the armv7-architecture which the imx6dl is based on. The resulting root filesystem should be sufficiently compatible to get started, before moving on to more tuned MACHINE configuration.
I want to build v4l2-ctl tool in buildroot (from 2019.02.4) linux system.
But v4l2-ctl is legacy (has been deprecated and replaced by a single option to build all the libv4l utilities).
I try to setup BR2_PACKAGE_LIBV4L_UTILS, to get v4l2-ctl, but after make, in linux system there is no v4l2-clt tool.
Do not understand: where is v4l2-ctl? How to build v4l2-ctl?
I got it:
It is need to rebuild buildroot's packet again:
make libv4l-dirclean
then
make libv4l-rebuild
then
make
and v4l2-ctl will appear in target usr/bin directory
I tried:
git checkout 2018.05
make qemu_x86_64_defconfig
make BR2_JLEVEL="$(nproc)" "$(pwd)/output/images/rootfs.ext2"
but it still built the kernel at:
output/images/bzImage
I want to do that because:
I'm making a setup where you can pick between multiple different root filesystems, so I will need to build Linux kernel manually for the other root filesystems, and would not like Buildroot to waste time building it again
I don't want to wait 5 seconds every time for Buildroot to parse 100 Makefile configs when I want to rebuild the kernel :-)
I'm using LINUX_OVERRIDE_SRCDIR with Linux on a submodule, so Linux the headers should match the source I will use for the build.
Is there a fundamental dependency between, say, glibc and the kernel build, or is it just a weird use case never catered for?
Ah, I noticed now that any loadable kernel modules need to go on the rootfs and would require a kernel build, and that build does have some .ko in the rootfs.
Well, just disable BR2_LINUX_KERNEL and Buildroot will no longer build the kernel.
I have an embedded linux "proof-of-concept" project that wants to add some packages to an existing piece of hardware with a read-only filesystem. I am very new (1 week) to Yocto but it seems like it is possible. Looking for a general road map of how to achieve this, but any detailed strategy ideas would be helpful to keep in mind as I RTFYM.
It is a networked device, running on ARMv5t hardware.
64GB SD/MMC card is available (empty) and mounted.
telnet, nfs, busybox utils available.
no resident dev tools
The packages I need to add are openssl, python, zeromq, pyzmq, and perhaps other python modules in the future. I cannot place these into the rootfs because it is read-only, but they can reside on the sd card. I am trying to understand how to use Yocto to create this set of packages and collect them together as a build output. What I have so far:
EXTERNAL_TOOLCHAIN and meta-sourcery recipe is working
I can build python and pyzmq independently with bitbake -b
Don't know how to add pyzmq or other modules to python tree
How to build & collect just these items without building entire image?
The python part is running on the hardware but I just hand-copied it to the nfs folder. I am asking if this is a valid approach and if so, to add some directional detail. I hope I have provided enough information.
A project I've inherited uses a very old version of buildroot, but I'd like to change it to use a feature that was added only in a later buildroot release.
Is there a straightforward way of updating a buildroot setup to use a later release?
e.g. if I save out a defconfig file and import that in a later buildroot release, would that just work, or are there practical reasons why not? Are there additional configuration files I'd need to carry across (e.g. kernel, busybox, etc)? Thanks!
No.
In fact, it's worse that that.
You can start by using a newer Buildroot version with your old default configuration file, but you will need to check the resulting configuration carefully for deprecated packages and packages whose versions are not compatible with whatever application software you might be adding to the Buildroot filesystem. The names of some packages (e.g. opencv) change over time, so you need to eyeball the resulting .config file to make sure that all of the packages that you need are there.
If you build a toolchain or Linux kernel in Buildroot (commonly done but not generally good practice), then you need to make sure that the new configuration is set to build the old version of the kernel and compiler. These might be too old to build some of the packages in the newer version of Buildroot.
If you upgrade your kernel at the same time that you upgrade Buildroot, then you need to port your old kernel config file to the new kernel version. Since the kernel configuration options change frequently, you will probably need to start from defconfig for your board and then use make menuconfig to manually add the configs that you need.
Busybox is a bit less volatile, so there is a chance that your old config will work.
If your old Buildroot configuration uses postbuild or postimage scripts, you will need to review them, but my guess is that they will not need any changes.
You should allocate at least a week for this work, maybe more, depending on the complexity of the configuration. Remember that if you are forced to use an older vendor kernel due to patches for a specific SoC, for example, the Freescale 2.6.33.9 kernel for the BSC9131, then the upgrade that you want to do might not be possible without doing six to twelve months of work to port the vendor's kernel patches to a newer kernel version.
Cheers.