Tag Archive

Below you'll find a list of all posts that have been tagged as "linux"

How to build a super simple Linux Based Embedded System Using Buildroot

What’s an embedded system?An embedded system, in simple language, is designed for a specific requirement. It has its own operating software (or operating system), which is designed or specified by you. The coffee machine and the ID card reader at our office are examples of small embedded systems, but there are bigger ones.Have you ever thought of building an embedded system with your choice of hardware and OS modifications and software above it? Believe me; it’s not at all as arduous as it sounds. You need a little knowledge of C, Makefiles (compilation process), shell scripting, and a Linux based workstation, before you start. The process involves an open-source tool called Buildroot. You can download the latest version of Buildroot from www.buildroot.org. Consider you need a system with Linux OS running on an ARM processor with serial, Ethernet, Wi-Fi, and USB modules loaded on it. You can get these pieces of hardware assembled from a hardware vendor or an electronics shop, if you ask for evaluation boards.[Fig: Evaluation board, Lantronix]The term “embedded” is used to indicate memory size restrictions, as it will be expensive to put a lot of memory into a small device. This creates hardware constraints in embedded systems.What about the software or operating system to run on this? Let’s have a look into this in the next section.BuildrootThe executables or software you develop on your PC will usually be only for its own hardware configuration (i.e., x86-based), but our target device is different in this case (i.e., ARM). If you have only one file, we can compile it with hardware specific flags in gcc, but what if we have thousands of files? How to build all the files for a different hardware configuration? Here comes Buildroot into picture.Buildroot is a cross-compilation environment. It provides all the options to compile and build software for specified target hardware. Basically, it’s a cross-compilation platform to generate an image according to the required architecture.Buildroot ConfigurationAs I mentioned earlier, you may download Buildroot and untar it. In Command Prompt, change the directory to the untared folder and issue “make menuconfig”. (You may be asked to install a few GNU-based packages on your host system to support the GUI of Buildroot; install them.)Here it goes; you can see a graphical interface as below.[Fig: Buildroot Main Screen/ Menuconfig]Go through the options, select target hardware or processor in “Target Options” menu. A snippet to select ARM processor is shown below.[Fig: Target Selection]Linux ConfigurationOne of the most important things to remember is the target hardware is different from our host. So, the same Linux OS running on your PC won’t run on the target hardware. We have to specify the Linux kernel as shown below.[Fig: Linux Selection]Once the kernel is downloaded and untared to a directory, you can change to that directory and issue the command “make linux-menuconfig”, to build the Linux OS and select the configuration options. Usually, you can specify the path to save the configuration.Now the “make” from the top directory (i.e., Buildroot) will give you the compiled Linux kernel, which gives you a kernel image in uImage format or one of your choice. Final Linux binary comes around 2MB of size.Busybox configurationOK, we got the kernel now, but have you wondered how Linux commands will be included to the target device? Who will put them into the device? The commands like “ls”, “ifconfig” etc., come with Busybox, which is a software package that provides lite Unix commands. Like Linux, we have to download and configure Busybox. You can change into Busybox directory and configure the stuff needed. Remember, this is an embedded device, and every “bit” matters. So you cannot have all the commands installed over it.Package selectionAs I mentioned repeatedly, because of memory constraints, Busybox selects lightweight commands only—low memory size. They can provide basic functionalities. You may also require a few advanced commands, such as “tar”. The Busybox version doesn’t support “-z” option, but a full version supports that. So you have to select the full target package, not the one which comes with Busybox.Think something like a dhcpv6 server on your target device, but it doesn’t come with Busybox by default, as it’s not a basic requirement. That command may be incorporated on the device by including it on the “Package Selection” menu. You can select “wide-dhcpv6” package under Networking Application to achieve this.Like this, you can go through the entire menu and get whichever package you need for your target.Target selectionYou can select the folder structure on your target device, like /bin, /tmp/, /usr, etc.Final ImageA “make” from the top directory will build the kernel image and root file system image for you.You can get the images at the “topdir/output/build/images” path. Then, you can transfer or load images by following the process mentioned below (or the evaluation board manual). Use conventional method like “tftp” to flash images into the device.Alternatively, use serial download to load the images to the device.If the board is fresh without any loaded binaries, you can use a “flash programmer”, which loads the binary at starting location of the flash.Sounds easy, right? I am here to read your reviews and comments. Please feel free, also, to voice your doubts.

Aziro Marketing

buildroot busybox linux

Understanding Device Mapper and Filter Driver

Device Mapper is a virtual block device driver framework provided by Linux kernel which provides an infrastructure to filter I/O for block devices. It provides a platform for filter drivers also known as targets to map a BIO to multiple block devices, or to modify the BIO while it is in transit in kernel.Figure 1.1 shows the position of the device mapper layer in the kernel I/O architecture. It is positioned between the generic block layer and the I/O scheduler.Figure 1.1Since Device Mapper itself is a block device driver, it registers the functions to handle block I/O with the generic block layer. These functions transform the received BIOs and pass them to corresponding functions from the target device drivers for further processing. The Device Mapper block device driver exports a set of ioctl methods which are used by a userspace program dmsetup. dmsetup creates a mapping between the sectors of the virtual block device and the sectors of the real block device. When this mapping is created, a data structure (mapping device) is generated, which stores all the information about the target and the underlying block drivers. The information regarding the underlying block drivers is stored in a configuration table in the kernel memory.When the generic block layer receives a BIO for an I/O, the BIO is plugged into the request queue of the Device Mapper block driver. The Device Mapper driver now processes the BIO as follows.The BIO is cloned and the end-of-I/O completion handler for the cloned BIO is set to that of Device Mapper’s end-of-I/O handler.The targets for the BIO are looked up in the list of targets, and the cloned BIO is handed over to the appropriate target implementation.The target implementation processes the cloned BIO and modifies the data contained by the BIO.The target driver directs the BIO towards the underlying block device that was mapped by the Device Mapper layer earlier, sets an appropriate end of I/O handler for the BIO and invokes the entry method generic_make_request() for the device driver.Upon completion of the I/O request by the device driver, the cloned BIO’send-of-I/O handler invokes Device Mapper block driver’s end-of-I/O handler, which then notifies the upper layers about the completion of I/O. The above process is depicted in figure 1.2.Linux Filter DriverThis Filter Driver intends to use a design that makes inserting and removing the filter hook into the Block I/O stack. Hook can be dynamically placed and removed into the io stack of the intended block device. The hook can be placed and removed with minimal and almost zero downtime. The IOs will be suspended for a very short time while the hook is placed. The upper layers/applications are not knowledgeable of the hook and will continue performing IO as before i.e the hook is transparent to the upper layers/ applications.The hook is placed for device corresponding to the major number. This means that IO to any minor device which is a child to the hooked major number will be filtered. However IO to only the intended minor device will be recorded.Filter driver is called on every I/O operation. Such drivers are used by backup and snapshot software. The interface to the kernel module will be a character device which will facilitate various IOCTLs through which a user can control and command the kernel module. A filter driver should not affect the normal working of the existing driver stack in any major way.Following is the code snippet for the filter driver hook:void filter_hook(struct request_queue *q, struct bio *bio) { unsigned long sector; unsigned int nr_sectors; int ret = 0, first_minor = 0; if (bio_data_dir(bio) == WRITE) { nr_sectors = bio_sectors(bio); sector = bio->bi_sector; printk(KERN_INFO "Capture %llu:%llu, start %ld, len %x.", MAJOR(bio->bi_bdev->bd_dev), MINOR(bio->bi_bdev->bd_dev), sector, nr_sectors); orig_request_fn(q, bio); } // return ret; } long filter_handle_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { int ret = 0; struct gendisk *gd = NULL; struct block_device *bdev = NULL; orig_request_fn = NULL; bdev = bdget(MKDEV(disk_major, disk_minor)); gd = bdev->bd_disk; if (gd->queue->queue_lock) spin_lock(gd->queue->queue_lock); orig_request_fn = gd->queue->make_request_fn; //Replace the make_request_fn with custom make_request gd->queue->make_request_fn = filter_hook; if (gd->queue->queue_lock) spin_unlock(gd->queue->queue_lock); return ret; }

Aziro Marketing

linux

EXPLORE ALL TAGS

Ansible Test Automation

application containerization

applications

Application Security

application testing

artificial intelligence

asynchronous replication

business intelligence

Cloud Cost Optimization

cloud devops

Cloud Infrastructure

Cloud Interoperability

Cloud Native Solution

Cloud Storage Security

Codeless Automation

Cognitive analytics

Configuration Management

container world conference

continuous-delivery

continuous deployment

continuous integration

data backup and recovery

Descriptive analytics

Descriptive analytics tools

Digital Transformation

dockercon 2019 san francisco

end-to-end-test-automation

High Performance Computing

icinga for monitoring

Image Recognition 2024

kubernetesday bangalore

Low-Code No-Code Platforms

mobile-application-testing

mobile-automation-testing

Predictive analytics tools

prescriptive analysis

Rapid Application Development

raspberry pi

RDMA

real time analytics

realtime analytics platforms

Real-time data analytics

Recovery

Recovery as a service

recovery as service

rsa

rsa 2019

rsa 2019 san francisco

Selenium Test Automation

selenium testng

serverless

Serverless Computing

Site Reliability Engineering

software defined storage

software-testing

software testing trends

software testing trends 2019

storage virtualization

support

Synchronous Replication

testing automation tools

thought leadership articles

trends

tutorials

ui automation testing

ui testing

ui testing automation

vCenter Operations Manager

vmworld 2019 san francisco

VMworld 2019 US

vROM

Web Automation Testing

web test automation

WFH

LET'S ENGINEER

Your Next Product Breakthrough

Book a Free 30-minute Meeting with our technology experts.

Aziro has been a true engineering partner in our digital transformation journey. Their AI-native approach and deep technical expertise helped us modernize our infrastructure and accelerate product delivery without compromising quality. The collaboration has been seamless, efficient, and outcome-driven.

CTO

Fortune 500 company