Testing Linux Kernel for an embedded device with diferent Debug options - linux

How can one test a Linux Kernel for a specific Target? Also keeping in mind Point 12 from https://www.kernel.org/doc/html/latest/process/submit-checklist.html
Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_ATOMIC_SLEEP, CONFIG_PROVE_RCU and CONFIG_DEBUG_OBJECTS_RCU_HEAD all simultaneously enabled.
Consider the scenario, I want to compile a Linux Kernel for an ARM based target. I have Linux source files and I code on my Ubuntu Host PC. I did some research and found out that there are Linux Kernel self-tests in tools/testing directory. It says on this page from kernel.org
that
These are intended to be small tests to exercise individual code paths in the kernel. Tests are intended to be run after building, installing and booting a kernel.
But when I run this makefile and execute the script, it tests the kernel on my Host system. And it does not test the source files of the Kernel i want to build.
Is my understanding correct?
What I want to do is run this self-test suite after my ARM Target has been booted. Is this possible ? How can one run these selftests or some other kind of tests for Linux Kernel?
My knowledge background: Embedded C developer, Certified Linux Foundation Sysadmin. I have generated custom images for RaspberryPi using Yocto. So i have limited knowledge in Yocto. I have no knowledge in Linux Kernel Driver Development.

Related

How does Root File System works on embedded linux?

I'am learning about embedded systems, and i was able to compile and setup a SAM9x35 EK with buildroot, mounting the bootstrap, the U-Boot, the Linux and The rootfs (Buildroot's basic RFS[root file system]skeleton).
I have LOTS of questions, but one of the most important is:
Pre Question Statements, for context:
I already have a provided JFFS2 with and app inside that is made of several NetBeans (c++) projects.
These projects use kernel built in (if selected in buildroot's menu) libraries
How does it work?
How the rootfs and the netbeans (makefiles) connect to linux packages?
What I mean is, How the kernel manages the makefiles from the netbeans projects?
i.e.: If i create a project that shows a picture on the screen i add some needed packages to the rootfs and then this is flashed to the device. How the kernel knows how to read and run this app? What I have read after doing this question is that Kernel start some script in init.d folder. But I would like a more Conceptual explanation of the interaction between Kernel and Rootfs
Any Explanation could help me because i dont understand how exactly works. The application is a standalone application that is loaded at the start of the linux (power on) and is only that, it runs and uses hardware to go through its different functions.
Please feel free to use links or examples.
Thank you very Much.

Linux porting for RISCV multicore processor

We are developing a multi-core processor with RISCV architecture.
We had already ported Linux for single-core RISCV processor and it is working on our own FPGA based board with busybox rootfs.
I want to port Linux for multi-core RISCV processor now.
My doubts are:
Whether the gnu-riscv-gcc toolchain available now supports multi-core?
Whether spike available now supports multi-core?
Should I make any change to the bbl bootloader (Berkely bootloader) to support multi-core?
What are the changes I should make for my single-core Linux kernel to support multi-core?
The current RISC-V ecosystem already supports SMP Linux.
No changes to the compiler are required for multicore.
Spike can simulate multicore when using the '-p' flag.
BBL supports multicore.
Before building linux, configure it to support SMP.
Any hiccups, are probably due to the toolchain out of sync with the newest privileged spec changes. Last Fall, users successfully built and ran multicore Linux on RISC-V.
This is all expected to work out of the box. My standard testing flow for Linux and QEMU pull requests is to boot a Fedora root filesystem on QEMU via Linux+BBL. Instructions can be found on the QEMU Wiki Article about RISC-V. This will boot in our "virt" board, which uses VirtIO based devices. These devices have standard upstream Linux drivers that are very well supported, so there isn't really any platform-level work to be done.
In addition to the standard VirtIO-based devices, SiFive has devices that are part of the Freedom SOC platform. If you platform differs significantly from SiFive's Freedom platform then you'll need some additional drivers in both Linux and BBL.
We maintain an out-of-tree version of the drivers we haven't cleaned up for upstream yet in freedom-u-sdk, which should give you a rough idea of how much work it is. Running make qemu in that repository will boot Linux on QEMU via BBL, and running make will show you how to flash an SD card image for the HiFive Unleashed board.

How to compile the Linux kernel to be as small as possible?

I'm working on a side project which requires me to configure and compile a tiny Linux System based on Ubuntu.
The result should be a tiny OS with the following features:
A Bootloader
A Kernel
A Process
A Thread
Miscellaneous (if possible)
A File System
Virtual memory
A Console
I read lots of documents about it, one of them being: http://users.cecs.anu.edu.au/~okeefe/p2b/buildMin/buildMin.html#toc3
I deleted the file system, and recompiled the kernel using make xconfig. I tried to deactivate modules and configurations many times, but it's not working for me.
How can I configure the kernel for the OS with only the features I listed above? What options can I disable or enable while still having a working system?
Having the Kernel very small is not important for Ubuntu, so maybe choosing Ubuntu is part of your problem. I would use as starting point what OpenWRT does. They do a good work making the Kernel small and it is easy to get started. OpenWrt Buildroot – Usage
try Linux From Scratch. It is a step by step approach on building a minimal Linux system from which you can evolve later on. http://www.linuxfromscratch.org/.
Use Gentoo Linux distribution - it's great for practicing on creation of Linux systems. Gentoo has excellent setup documentation, for example about configuring the kernel.
And Gentoo is a little easier and faster to setup than Linux From Scratch (LFS). If you want to go deeper, then LFS may be a good learning step too.

Running x86 printer driver binaries on ARMv6

We are porting a solution to ARM that was originally designed to run on x86/x64 Debian based systems.
So far so good however along with this solution we ship out a printer that is compatible and comes with drivers for Linux (x86 and x64), unfortunately the manufacturer does not have ARM drivers for it, nor is capable of compiling some from source code (don't know why).
I've installed the printer with CUPS and used the x86 binary. But of course, whenever I send a task to the printer, the ARM system cannot use the binary and naturally CUPS reports:
/usr/lib/cups/filter/rastertotg2460 failed
I would like to know how I can run x86 binaries on ARM v6 based systems?
The ARM operating system is Raspbian running on a Raspberry Pi B+ board and the binaries (if you want to take a look) are here.
EDIT:
I was also made aware of this proprietary solution that claims to make it possible running x86 binaries on ARM systems, but all demonstrations are for ARM v7 systems, not sure if it will work on Raspbian with a Raspberry Pi B+ board.
I think this is going to require some serious work, but I had it the wrong way around initially.
Since you want to drive the printer, you're going to have to do the x86 emulation "inside" the CUPS system. It's not enough with a stand-alone x86 emulator, since those aim to give you a full x86 system with peripheral hardware and stuff. You don't need that, you just need to drive the printer.
I can imagine using some kind of x86 emulation library inside a CUPS "virtual" driver, which in turn loads the x86 binary you have and feeds it into the emulator. It would then need to expose the expected CUPS environment to the x86 code inside the emulator.
Something like Soft86 might be a good starting-point.

Linux Kernel Examination in Windows

I want to examine the Linux kernel source code using Visual Studio on Windows. But I don't know how to do that. Do I need a virtual machine to run or debug the kernel or is there any special way for me to do that ???
What does "kernel examination" means to you?
Why can't you more simply study the source code of the Linux kernel?
It is free software, you cant fetch its source code from kernel.org
it is extremely likely that your Linux vendor publishes either the source code of his variant of Linux kernel, or patches against vanilla kernel source code. The GPLv2 license of the Linux kernel nearly requires such a behavior.
And a Linux system gives you a lot of tools (objdump, ....) to study ELF executable image (like the Linux kernel mostly is....)
You probably won't be able to compile the Linux kernel with Visual Studio. You need GCC (or a very compatible compiler). Linux source code uses many GCC extensions.
My advice is to install a Linux system on your development machine (you can have a dual boot if you want to keep Windows for games....) and to learn it and to use Linux tools (including emacs, grep, etags etc....) to study the source code of Linux. Remember that Linux is the preferred platform to build the Linux kernel... (if your distribution is Debian or Ubuntu or similar, learn about make-kpkg)
Also read some good books about Advanced Linux Programming and about the Linux kernel (there are many of them).
BTW, you could even customize your GCC compiler, e.g. with a plugin or a MELT extension, to measure, search, or even refactor the source code of the kernel. See also cocinelle.

Resources