I'm complety new to this but I finally got around to building a Linux kernel so far so good. I am following a guide here:
A10-OLinuXino-LIME
My problem/concern is now I am in a .config menu and I've been searching online to no avail to determine what does it mean by a modularizes features verse includes, like should I switch to if I want those features to be there?
Any help or advice would be greatly appreciated it! I'm primarily doing this to include WiFi usb drivers I will be needing.
It depends on what system you run this kernel. If it's an embedded system, then you will probably be more concerned about memory benefits. In RAM you can win about several Kbytes per module. For the devices are not represented in the system/hardware, it then has a sense to put some drivers on Modules. Some modules can be taking more time when the kernel starts, and it is probably better to load them later, when the system is running.
You will probably be concerned about disk space, if you put some stuff Compiled-in so you can have a benefit because you don't need to have a module loading utility.
Have a look at this thread as well
I'm primarily doing this to include WiFi usb drivers I will be needing.
Its not necessary to build the complete kernel unless to build a USB WiFi driver. All you need is the kernel headers installed. From make menuconfig select the module you want to build, choose M, save the .config. This will build a module which can be loaded, instead of getting compiled as a part of the vmlinux image.
Related
I may have a couple assumptions of Linux incorrect about the Linux system, and for that I apologize.
I have been educating myself on the Android and Linux systems for a while now and I started looking into installing a custom boot loader and Linux system onto an older Samsung tablet. Immediately upon looking into the feasibility of this, most of the answers I could find were that it wasn't possible because you would need the drivers that are being used by the android kernel to communicate with the OEM hardware in whatever Linux kernel you are installing.
I have one of these tablets rooted and I believe I may have found the drivers I need (not sure on that yet), and so I guess my question is, is it possible to take the drivers and put them into a Linux kernel within a distribution install image and install Linux on the device (using also a custom boot loader)?
I presume because someone hasn't done this before there is a pretty good reason why, but I am basically looking to be able to use Linux on my old tablet without the resources being taken from Android, and personally in my opinion, if I don't need Android and can install Linux straight on to the machine, then why keep it?
In the long run I am looking into LFS to create a custom distribution that can be installed on these tablets, but the most important question to me right now is if I do create this distribution can I get the drivers that the hardware needs (and even then will my kernel be able to use them?).
I also understand that some of these drivers may be proprietary drivers provided by the manufacturer, but I am not looking to profit off of this but instead research the feasibility of a better personal on-the-go computing setup.
I may be terribly wrong on how I may have described some things, so here are some of my assumptions:
The .ko files in the Android /lib/modules/ directory are the static kernel drivers I am looking for for that device.
The drivers aren't written for specifically the Android system, but for all Linux variants and would be compatible with another distribution.
If the drivers were written for the Android system, then one would be able to edit or modify those drivers to work with a different distribution.
One could "put the drivers into an installation image", or if not, then one would have to compile the kernel from source with those static drivers.
TL:DR, If this all just amounts to rambling, here are my specific questions:
Is it possible to copy the static kernel drivers of a rooted Android device to something like the SDcard?
Is it then possible to "put" or "compile" those same static drivers into a Linux distribution before installing it onto said tablet using something like Odin, or the like?
EDIT: As stated in the comments, the question seems too broad to answer, so I'll leave the explanation of the problem and the questions, because they haven't changed, but I have changed the title (it doesn't seem good yet, but it's better than before) so they are more in tune.
What lead me to the question
I want to compile OpenWRT for my board. At the moment I am compiling it to a beagle bone black, and it's quite straight forward since there are tutorials available for that, but it got me thinking. How would I build it for a completely bare board? Like it or not BBB comes with u-boot and a version of linux (Amstrong if I'm not mistaken) so when I build OpenWRT for it maybe many things have already been taken care of for me.
I know that I need to first set up the board to boot from somehere, then it must have the bootloader and finally the kernel (there is the SPL and all that, but ok, let' leave it aside for now).
Hypothetical system
Let's imagine I have a hardware similar to the beaglebone, except it has a dipswitch connected to the boot pins in order to select from where I'm going to boot my device from. Imagine I have set it to boot from ethernet, which means that on startup a bootloader located in ROM will receive a binary file and store it in flash, all that via TFTP.
The questions
At this point I imagine that the binary file given via TFTP is the bootloader, am I right?
So after that I'd need to give the bootloader the kernel?
Does this mean that it is a 2 step process? First load the bootloader an dthen the kernel?
Is it possible to compile both at the same time and load it into the microprocessor?
Does OpenWRT build u-boot as well or do I need to compile it separately? I know it downloads the kernel and compiles it.
How would I build this for production? Imagining that I have to build u-boot and openwrt separately, would I create a script that compiles both and then does the entire process of downloading it into the microprocessor?
Is it possible to pre-configure the kernel so that it doesn't need to be configured after the code is downloaded? I mean, for example, compile it with initialization scripts instead of connecting to the device and configuring this. Is it possible or do I have to connect to the board and configure it manually?
PS: Sorry for such basic questions, but it's my first time compiling the kernel for real, and I've only worked with microcontrollers and RTOSs at most
Let's try to answer the queries one by one
At this point I imagine that the binary file given via TFTP is the bootloader, am I right?
No, It should be the firmware(kernel+HLOS). TFTP is available in uboot or only after SBL(Secondary boot loader) is loaded into memory.
So after that I'd need to give the bootloader the kernel?
bootloader needs to be present in the memory and if required it can get the firmware from ethernet, This can be simply done by changing the uboot env(bootcmd), can also be configured at compile time.
Does this mean that it is a 2 step process? First load the bootloader an dthen the kernel?
Yes, bootloader needs to be loaded earlier, but if you designing a custom board, you can combine the images in a big file and then flash/load that file at once.
Is it possible to compile both at the same time and load it into the microprocessor?
Does OpenWRT build u-boot as well or do I need to compile it separately? I know it downloads the kernel and compiles it.
Yes, Openwrt is very flexible and it compiling uboot, kernel, userspace package at once and create a desired image(based upon user configuration).
How would I build this for production? Imagining that I have to build u-boot and openwrt separately, would I create a script that compiles both and then does the entire process of downloading it into the microprocessor?
You can configure the openwrt to generate the appropriate image(based upon the flash and system requirement) and then flash that image in production(so, simple).
Is it possible to pre-configure the kernel so that it doesn't need to be configured after the code is downloaded? I mean, for example, compile it with initialization scripts instead of connecting to the device and configuring this. Is it possible or do I have to connect to the board and configure it manually?
Yes, use make kernel_menuconfig to configure the kernel parameter at compile time.
Hope, I have answered all the queries!!!
I am trying to build minimal kernel under 1 Mb with Buildroot. It is intended for small board with qspi memory and basic functionality, ethernet, usb, spi, and some GPIO's. Basic terminal access via ssh and UART.
My first thoughts are if it is even possible to modify kernel .config via linux-menuconfig to reach this size.
Also if it is possible to identify the redundant parts without deep knowledge about kernel architecture and exclude them from compilation.
If someone can direct me to good direction how to solve this problem or even specify some tools and ways how to do it would be very helpful.
Thank you!
If you have working build root for your board, than, it's better to continue to work with it. Technic for disabling kernel options should be the same. In the article he reached ~0,7MB uImage with lost a lot of functionality (p40). He started with minimal (bare) config (p27) and add blocks of configs. So instead of identify the redundant parts you can build smallest possible uImage you can boot. Than add to it more options: ext2, serial and so on. Actually this work require a lot of testing. And you probably brake dependencies.
Kernel configs (working and new one) could be compared using diff -Naur, so you can see what changed.
Offtopic:
Looks like yocto officially supported by altera. here are instructions how to build altera-image-minimal. If you fine with it size, than use it and don't spend time on minimizing uImage. If you need extra packages installed into it, than you can ease extend it.
And here are instructions about building Angstrom (yocto based distribution). You can create you custom image based on console-image-minimal.
I use Angstrom in production. Must say, it was really hard to use it first time.
Whether or not you build the kernel with buildroot is not really relevant. The important thing is to configure it so it fits in 1MB. When you build the kernel from buildroot, you can do that with make linux-menuconfig, as you mention.
That said, getting a kernel under 1MB will be quite hard. Biff once did this for an x86-based platform, bifferboard. But that was without networking or USB.
You can refer to the kernel size tuning guide, which has links to some patches to reduce the size. But it's not been updated in a couple of years.
I wanted to validate/test/benchmark set of features I have added to the ext4 kernel_tree/fs.
I came across Spruce Linux file system driver verification. Especially for filesystem.
The project is hosted #https://code.google.com/p/spruce/wiki/GettingStarted.
and this is for x86.
I work on arm target, and I have few questions before starting off.
Has anybody worked on Spruce earlier.
how to use Spruce project for ARM, Do we need to port for ARM?
Is cross compilation straight forward or any changes need to be done.
I have gone through this paper: http://syrcose.ispras.ru/2012/files/submissions/25_syrcose2012_submission_21.pdf
there is no information on ARM and its support.
Please someone explain/help who has any work experience/knowledge on Spruce project.
Spruce was intended to work as follows. It provides a set of tests that make the kernel module for a given file system execute as many paths in the code as possible. It allows to use some external analyzers (such as the tools from KEDR framework) to detect different kinds of errors: memory leaks, etc.
All that was primarily intended for x86.
While it might be possible to port the tests themselves to ARM, one will need to choose the analyzers that work on that platform too. KEDR tools are currently for x86 only but one may try Kmemleak, Fault injection facilities and other tools on ARM instead.
Spruce seems to be a work in progress still. I see, you opened a ticket concerning ARM support in their issue tracker, I think, it is the right thing to do.
I would also suggest to take a look at Phoronix Test Suite. It is currently widely used for testing and benchmarking, including the analysis of file system kernel modules. See this article for example. It seems to work on ARM although I haven't tried it there myself.
The best tool for testing/validating a file system is xfstests. I have written tools to make it easy to validate xfstests for ext4. See: http://thunk.org/gce-xfstests for more details.
There is also an alpha-test level support for using this on ARM directly: http://thread.gmane.org/gmane.comp.file-systems.ext4/53649/focus=53659
This has been used successfully to test ext4 on an Android device, although to be honest, most of the time what I do is to bludgeon an Android kernel until it will build on x86, and then use kvm-xfstests gce-xfstests, since it's much more convenient. In particular with gce-xfstests, I can just do a "fire and forget", and then when the test completes I get a test report in my e-mail. Where as with the Android arm xfstests tarball, the automation isn't done yet, so you have to manually set up an external USB-attached USB device, hook it up via some kind of USB C hub, or if you are going to use an OTG usb adapter, you need to make sure the Android device can receive power while it is also driving the OTG usb port --- and you have to manually set up the chroot. Unless the BSP kernel has been badly abused so you can't figure out how to make it build on x86 (getting the MSM kernel to work on x86 wasn't easy) testing on gce-xfstests may be much simpler at the end of the day.
I am compiling my own Linux kernel and userland tools for a PXE environment meant for cloning and reimaging. Right now, I'm sticking to a specific kernel version and using preconfigured .config's for building the Linux kernel.
I need to change from using preconfigured .config's to automatically generating the default configuration for the specified architecture, and then enabling all ethernet, ATA, SATA, and SCSI drivers.
The reason I want to do this is:
Updating the kernel means updating the preconfigured .config's, which takes too much time to manually do. The way I'm doing it now is using menuconfig, enabling the options I need, and saving the resulting .config to my repository.
I know the kernel I'm building is missing some drivers because I've encountered some PC's that were not able to mount the NFS share because Linux could not find an ethernet device (which I've verified by booting an Ubuntu CD, which did find the ethernet device). I want an automated way of building any Linux kernel version that will guarantee that ALL drivers I need are pulled in.
Using a distribution's configuration pulls in too many unnecessary drivers and features for my purposes. It lengthens the kernel build time from 10-15 mintues to an hour or more, and the resulting image is too big.
Does anyone know how to write a Bash script to accomplish this?
Have you considered using a text editor to modify the .config file.
Then you can modify it using search and replace.
Plus, there are other choices for configuring the kernel than the menu-driven "menuconfig".