I need pwm-bl.ko kernel module for my Raspberry Pi, but it is not present in my /lib/modules directory. Sure, I can download kernel sources for my kernel version, select necessary modules to build, build and put it into this directory. But how to automate this process? I've found module-assistant utility, but it looks like a list of modules is very limited.
Related
I'd like to manually compile multiple versions of the same Linux kernel which would differ only for few minor things (e.g. debug symbols) and install them on my host. I would need to have the modules installed in different paths so I could compare the different versions of the .ko files.
If possible in the end I would like to have one image called vmlinux-6.0.7-debug and one called vmlinux-6.0.7 and the modules to be installed in /lib/modules/debug and /lib/modules/nodebug
I tried to manually rename the bzImage and to export the INSTALL_DIR but I had no luck.
Anyone can show me the set of commands?
Thanks
I have built a sdcard.img for raspberry pi using Buildroot. When I run apt-get command it throws error "apt-get: command not found". I did not find apt-get/dpkg package to enable in 'make menuconfig' options. Now I'm trying to run cross-compiled opencv program on my Rpi but some shared libraries are missing and I want to install these libraries using apt repository (as I already did it on standard Raspbian Stretch os & program run successfully).
I googled it, there's no solution for Buildroot rasbpbian os. Also I tried downloading and installing .deb packages for apt/apt-get/dpkg, didn't work.
apt-get: command not found
I want to cross-compile a kernel which will have all the necessary packages such as apt/dpkg, bin and lib files. Or for the time being to get the work done need guidance to install apt/dpkg packages on Rpi buildroot os.
Buildroot will never have apt or any package manager. With buildroot you have to decide ahead-of-time what packages you'll want included in your rootfs. Use Raspbian if you want to use apt-get.
robert-orr has already answered your question but I think you are confused about the naming. You cannot rebuild raspbian using buildroot.
Rebuilding raspbian (a debian derivative) is a fairly involved process. You have to implement bootstrapping of a distro (compile a compiler, compile your packages with your compiled compiler, etc.) See Debian Bootstrap for everything needed to create your own distro from source. This is usually done by debian and debian-derivative distributions only.
You can build a simpler image using Buildroot, if that satisfies your needs. Also look at Yocto/OE to see if that satisfies your requirement for building an image from source.
With a Buildroot-generated system, it is not possible to use a package manager, because there is no way to make sure the package binaries will actually work on your system. There are two reasons for this:
Binaries depend on the toolchain (C library, kernel header version, subarchitecture choices, ABI choices). There are hundreds of combinations of these choices possible in Buildroot, it's not possible to build package binaries for all of them. Traditional distros limit the choices to just one per architecture.
How one package is configured affects how other packages can be built. Again, Buildroot offers choices there, while traditional distros choose one (usually enable all features).
In Buildroot, instead of using apt-get, you'd go back to make menuconfig, select the additional packages you want to install, and rebuild the system.
the last week I have been trying to set-up a compiler which can compile to netbsd with mips architecture.
I cannot find anything on the internet how to do this. All documents refer to compiling the kernel to the architecture but not programs.
How can this be so hard....
host is netbsd amd64 machine
Set the compiler appropriately. Point it at the version of gcc in your TOOLDIR. In this case, something like mips--netbsd-gcc. Definitely make sure TOOLDIR is on your path, so the driver can find the proper assembler, proper loader, and proper libraries.
Take a look at the Makefile in any of src/bin/* as an example, and read through the system mk include files referenced (in src/share/mk)
Generally speaking, the goal is to have a working cross-compiler and a filesystem root for the target, all installed on your development machine. The target root is needed since you need all sorts of libraries to build userland applications. Those libraries need to be compiled for the target, not for the host.
Assuming you build everything from source, it goes as follows:
Choose a prefix for the toolchain (say /opt/mips) and another prefix for the root filesystem of the target (say /opt/target). All of those are on your development machine, not on the target!
Configure, build and install the cross-compiler for your target. This goes into the toolchain prefix.
Configure, build and install the kernel for your target, into the target root prefix. This should install the necessary kernel development headers needed later. If you can install such headers without compiling the kernel, more power to you, of course.
Configure, build and install the C library (say glibc) for your target, into the target root.
Configure, build and install whatever other libraries your userland application needs - into the target root.
Finally, configure, build and install the userland application. Once installed into the target root, you can copy it over to the target into the same prefix (say /opt/target as suggested before).
Generally to install into a different prefix - one that overlaps stuff on your build host (like /usr) - you'd need to do some tricks to fool make install into seeing the target prefix instead of your own. A simple approach would be to have a chroot environment on your build host, where you can bind-mount the prefix (say /usr) read-only, with a writable (mount_union) overlay on top of it.
When you build stuff for the target, you need to pass proper arguments to configure, of course.
I compiled various Linux kernel from git repositories. There are times when I copied the kernel to other system and need the kernel header to compile external module.
I tried to run "make headers_install" but it only generated a include/ folder. When I tried to point external module to that folder, it complains it cannot find Makefile.
What is the proper way to package kernel-header for deployment?
Thanks.
Create kernel packages instead, that's "make deb-pkg" for dpkg based distros and "make rpm-pkg" for RPM based ones. These create multiple packages, one of those is a package usable for external modules building. That should be linux-headers-* for the Debian packages and a "devel" package for he RPM versions.
In some ways this is just an expansion of the previous answer. If you look at the file scripts/package/builddeb in the kernel sources you will find script code which selects the files needed for building external modules from a kernel build and puts them into /usr/src/linux-headers-$version. I can find that script code in my local kernel version by searching for the string "# Build kernel header package" in the builddeb file. If you want to do things by hand you could execute that script code manually.
I'm cross-compiling kernel modules and some libraries on x86 for ppc.
Is it possible to create ld.so.cache and modules.dep on my host system?
P.S I'm using ELDK tools.
modules.dep should be generated when the modules are built. It's also a text file so is readable on either architecture.
I'm pretty sure it'd be hard to generate ld.so.cache on anything but the system target system. It's a binary file that built up given the specific libraries available on your rootfs and configuration in /etc/ld.so.conf.
depmod can run just fine against foreign architecture modules. Assuming you've built your kernel and deployed your modules (eg 3rd party modules) to your system-root:
/sbin/depmod -ae -F /path/to/System.map -b /path/to/system/root <kernel-version-name>
Haven't found a solution for ldconfig, yet.