Explore how an LED can get you started with the Linux kernel

Preface

Recently, I need to use the LED subsystem in a project. It is relatively simple to turn on a light in embedded Linux. As long as you write a specific value to the corresponding file in the directory corresponding to a certain light, you can make the LED turn on/off/flash.

# echo 1 > /sys/class/leds/green/brightness // Turn on the LED
# echo 0 > /sys/class/leds/green/brightness // Turn off the LED
# echo heartbeat > /sys/class/leds/green/trigger // Make the LED flash like a heartbeat

LED Trigger

Of course, the lighting function used in the project is a little more complicated than the one introduced above. It is similar to the hard disk light, that is, the LED will flash when the hard disk is read or written. I vaguely feel that this function should be related to the trigger file, because when I cat this file, there is the word mmc0 in it.

Then write mmc0 into trigger and see what effect it will have.

# echo mmc0 > /sys/class/leds/green/trigger
# cat /sys/class/leds/green/trigger
none rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock 
kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock 
kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock 
[mmc0] heartbeat default-on ir-power-click axp20x-usb-online

Writing data to disk

# touch aa | sync

Magically, I discovered that every time a command was executed to write data to the disk, the green light on the board would flash once.

By consulting the information, I learned that this is a function related to the LED trigger.

For a moment, I thought

• Why can writing mmc0 into tigger turn the LED into a hard disk light?
• Why can we control the on and off of the light by writing 1/0 to the brightness file?
• Why does the LED flash when a timer is written into the trigger file? At the same time, two files, delay_on and delay_off, are generated, and they can be used to control the flashing frequency of the light?

All kinds of doubts came to my mind, and I was eager to understand the principles behind these functions.

Start exploring

Problems drive action. List the questions you want to know first.

Where do the directories corresponding to the various lights come from?

• How are the triggers in trigger generated?
• Why does the LED turn on/off when writing 1/0 to brightness?
• Why do two files, delay_on and delay_off, appear when writing a timer into a trigger?

Let's start the research, and start with what I thought of last night: led_classdev_register("aaa") will generate an LED directory.

LED Device Registration

Let's do an experiment to determine whether led_classdev_register() will generate a directory corresponding to the LED light.

I randomly found a place that can be run and added the following lines of code, hoping that the aaa directory can be generated in the leds directory

	struct led_classdev *cdev;
	int ret;
	cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
	if (!cdev)
		return -ENOMEM;
	cdev->name = "aaa";
	// cdev->brightness_set = ebsa110_led_set;
	// cdev->brightness_get = ebsa110_led_get;
	// cdev->default_trigger = "heartbeat";
	ret = led_classdev_register(NULL, cdev);
	if (ret < 0) {
		kfree(cdev);
		return ret;
	}

Compile, burn, run, view

# ls /sys/class/leds/
aaa green

Sure enough, the directory aaa that I hoped to appear was generated under leds, and my confidence increased greatly!

Later, I traced the underlying call relationship:

led_classdev_register()
	of_led_classdev_register() // register a new object of led_classdev class.
		led_classdev_next_name()
		device_create_with_groups()
		led_add_brightness_hw_changed()
		list_add_tail() // add to the list of leds
		led_update_brightness()
		//led_trigger_set_default()

leds directory

Now that I know how a certain light is registered, I want to know how the leds directory is generated. I searched the code and it is not difficult to find it. The following is the function call relationship related to generating the leds directory:

subsys_initcall(leds_init);
leds_init() // Create the leds class, that is, generate the /sys/class/leds directory class_create()
		__class_create()
			__class_register()
				kset_register()

comprehend by analogy

Later, I checked the information and found that /sys/class/leds is a class. A class represents a kernel subsystem. There are many subsystems like this in the kernel.

Each directory in /sys/class/ is a class and also a subsystem.

# ls /sys/class/
ata_device extcon mdio_bus ptp sound
ata_link gpio mem pwm spi_master
ata_port graphics misc rc thermal
bdi hwmon mmc_host regulator tty
block i2c-adapter net rtc udc
bsg i2c-dev phy scsi_device vc
dma input power_supply scsi_disk vtconsole
drm leds pps scsi_host watchdog

Each class has specific instantiation objects, such as green, aaa

# ls /sys/class/leds/
aaa green

Each object has corresponding member methods/attributes, such as brightness, trigger

# ls /sys/class/leds/aaa/
brightness power trigger
max_brightness subsystem uevent

It's so much like a class in C++! In fact, it is a class, a simple comparison

I will slowly study the registration logic in the specific class when I have time later. Continue our route exploration. Note that my exploration route has changed here. It is no longer limited to exploring the LED subsystem, but has begun to expand to the kernel outside the LED subsystem.

Generation of class directory

Now we come to the class directory. After knowing where the leds directory came from, we are wondering where the class directory above it came from.

Follow the code and get

classes_init()
	kset_create_and_add("class", NULL, NULL); // create a struct kset dynamically and add it to sysfs
		kset_create()
			kobject_set_name()
		kset_register()
			kset_init()
			kobject_add_internal()
				kobject_get()
				kobj_kset_join()
					kset_get()
					list_add_tail()
						__list_add()
						{
							next->prev = new;
							new->next = next;
							new->prev = prev;
						}
				create_dir() // Create a directory

start_kernel()

In fact, after tracing to classes_init(), I don’t need to think about what code to trace below, just keep tracing upwards.

/* kernel */
start_kernel()
	rest_init() // Do the rest non-__init'ed, we're now alive
		kernel_thread(kernel_init, NULL, CLONE_FS);
		kernel_init()
			kernel_init_freeable()
			/*
			 * Ok, the machine is now initialized. None of the devices
			 * have been touched yet, but the CPU subsystem is up and
			 * running, and memory and process management works.
			 *
			 * Now we can finally start doing some real work..
			 */
			do_basic_setup()
			driver_init() // to initialize their subsystems.
				devtmpfs_init()
				devices_init()
				buses_init()
				classes_init() // just classes_init()
				firmware_init()
				hypervisor_init()
				platform_bus_init()
				cpu_dev_init()
				memory_dev_init()
				container_dev_init()
				of_core_init()

As mentioned above, I accidentally tracked down start_kernel(), where the dream began. It was the first time I found that tracking kernel code was so interesting.

Starting kernel …

After tracing to start_kernel(), I couldn't help wondering where this string "Starting kernel ..." was printed. I can see this sentence every time I start uboot. Wouldn't it be great if I could find it? Unfortunately, I couldn't find it in the kernel code.

uboot

At first I thought Starting kernel ... would be printed in start_kernel(), but I didn't find it in the kernel code. At this time, I wondered if it was printed in ubbot. It is reasonable to print this sentence before starting to load the kernel.

I searched in uboot and found

boot_jump_linux()
	announce_and_cleanup()
		printf("\nStarting kernel ...%s\n", fake ? "(fake run for tracing)" : "");

This is where uboot is about to exit and the kernel is about to run.

Attached is the complete call relationship

From uboot to kernel and then to /sys/class, then register the leds class and instantiate an LED light.

/* uboot */
boot_jump_linux()
	announce_and_cleanup()
		printf("\nStarting kernel ...%s\n"); // printf() 
		bootstage_mark_name(BOOTSTAGE_ID_BOOTM_HANDOFF, "start_kernel");
		cleanup_before_linux()
	kernel_entry(0, machid, r2);
/* kernel */
start_kernel()
	rest_init() // Do the rest non-__init'ed, we're now alive
		kernel_thread(kernel_init, NULL, CLONE_FS);
		kernel_init()
			kernel_init_freeable()
			/*
			 * Ok, the machine is now initialized. None of the devices
			 * have been touched yet, but the CPU subsystem is up and
			 * running, and memory and process management works.
			 *
			 * Now we can finally start doing some real work..
			 */
			do_basic_setup()
			driver_init() // to initialize their subsystems.
				devtmpfs_init()
				devices_init()
				buses_init()
				classes_init()
					kset_create_and_add("class", NULL, NULL); // create a struct kset dynamically and add it to sysfs
						kset_create()
							kobject_set_name()
						kset_register()
							kset_init()
							kobject_add_internal()
								kobject_get()
								kobj_kset_join()
									kset_get()
									list_add_tail()
										__list_add()
										{
											next->prev = new;
											new->next = next;
											new->prev = prev;
										}
								create_dir()
				firmware_init()
				hypervisor_init()
				platform_bus_init()
				cpu_dev_init()
				memory_dev_init()
				container_dev_init()
				of_core_init()

subsys_initcall(leds_init);
leds_init() // Create the leds class, i.e. the /sys/class/leds directory class_create()
		__class_create()
			__class_register()
				kset_register()

led_classdev_register()
	of_led_classdev_register() // register a new object of led_classdev class.
		led_classdev_next_name()
		device_create_with_groups()
		led_add_brightness_hw_changed()
		list_add_tail() // add to the list of leds
		led_update_brightness()
		//led_trigger_set_default()

Life entry point

The above is a study of the Linux kernel from the perspective of the LED subsystem. Found the entry point to study the Linux kernel.

When faced with huge things, we often feel fear. This fear prevents us from further research, which leads to our lack of understanding of them and our inability to defeat them.

Two examples:

• A famous marathon runner was telling everyone about his experience of success. He said that he always looked at the route in a car in advance, took note of reference points, and then broke down the distance into sections and ran each section well.
• I got good grades in physics when I was in high school because my way of solving problems was different from others. Others would stare at the last question when they got the test paper and want to get the answer immediately. I would first scan the question, find a few known conditions, and try to deduce the unknown quantities based on the physical formulas. I would deduce bit by bit, and sometimes when I looked closely, the answer would be right in front of me.

From something as small as a question, a subject, or a skill to something as big as work, life, or even the entire life. If we can find an entry point, then we are lucky, and we will use it to lead to success and a better future. I hope everyone will support 123WORDPRESS.COM in the future!