1, Preparation for Linux Kernel compilation
This blog post is in Exynos4412 Linux Kernel porting process record (I)1 Continue Porting Linux Kernel on the basis of.
0. Analysis of kernel make principle
The reference book is "practice of building embedded Linux core software system" 2.
1. Kernel make process
It is necessary to know two commands and three files: make% config command, make menuconfig command Config file, Makefile file, Kconfig file. The make compilation process of the kernel is composed of them, and they are also members of the Kbuild mechanism. Like learning shell commands, we need to understand how to use them so that there are no obstacles in the process of making a complete Linux kernel,
The following figure shows the process of kernel compilation and the relationship between each link:
2. What is make exynos_defconfig
Execute make exynos_defconfig is to generate a development board related Config file. At this time The config file is initial and cannot completely match your own development board. It is essentially the make% config executed.
3. What is make menuconfig
make menuconfig generates a graphical menu. Write the required configuration to the through the modify menu config file.
4. What is Kconfig
config_ The XXX variable is saved in config, while config is generated by make menuconfig, and Kconfig needs to be read when running make menuconfig.
5. What is Kbulid
From the perspective of compilation process, a build - in will be generated under each compiled directory O files, which are compiled and generated by the source code in their own directory, and build in O file is finally linked to generate vnlinux file, and finally vmlinux is processed by kernel compressor to generate kernel compressed image file zlmage.
In principle, the Kbuild mechanism will only compile the value of obj-y into the kernel. Every Makefile file has this variable, but obj is usually followed by a variable whose value comes from config. For example:
obj-$(CONFIG_EXYNOS_MCPM) += mcpm-exynos.o CFLAGS_mcpm-exynos.o += -march=armv7-a
Variable CONFIG_EXYNOS_MCPM comes from config. If this variable = y, MCPM exynos O will be compiled into the kernel. This is the same as the transplantation of U-Boot.
Therefore, the key to porting kernel drivers is to assign the correct macro definition to y, or m. The method is to modify the Kconfig definition macro and configure menuconfig to assign a value to the macro definition.
6. Kconfig syntax
(1) The basic element of Kconfig file: config entry.
In the Kconfig section above, config is a selection item in the menu. The meanings of each part are:
● ARM is the variable name, which will be displayed in CONFIG_ARM=y or n.
● bool is the type of variable value, which can be y or n.
● behind prompt is the text corresponding to a configuration option that appears in the configuration menu. Without prompt entry, the user cannot display and configure the configuration option in the configuration interface.
● default is the default value of the variable and can be overwritten by the user set value.
● depends on ARM means that the variable can only be set when ARM is set, otherwise the value is n, even if the default is y.
● select indicates that it will affect the variable RTC_LIB, making RTC_LIB should be configured at least as y or m (if it ultimately takes y or m).
● the text in help will be used as the help information in the configuration interface.
Additional notes:
● no dependencies on, default is Y: the default is y. It is generally used for the options that must be set. Do not set prompt at this time.
● with dependencies on, default is Y: if the dependent entry has been set, the default is y; If the dependent entry is not set, n.
● with dependencies on, default is n: if the dependent entry has been set, the default is n; If the dependent entry is not set, n.
● no dependencies on, default n: the default is n. if prompt is not set, this option needs to be set, and other options need to select it.
(2) There are five value types of variables in Kconfig. The most common options in the configuration interface are [< make] and [< make] respectively.
● tristate: y, n, m are acceptable.
● bool (which is a variant of tristate): y.n.
● string: the value is a string, such as: CONFIG_CMDLINE=“root=/dev/hdal ro init=/bin/bash console=ttySACo”.
● hex (which is a variant of string): the value is hexadecimal data string, such as CONFIG_VECTORS_BASE=0xffff0000.
● int (which is a variant of string): the value is decimal data string, such as CONFIG_SPLIT_PTLOCK_CPUS=4096.
(3) Element of Kconfig file: menu.
Several config entries can be configured between menu and endmenu;
Reflected in the configuration menu is System type I >, after pressing this entry, each config entry will appear.
(4) Element of kconfig file: choice.
Several config entries can be defined between choice and endchoice.
Reflected in the configuration menu is ARM system type - >. After pressing this item, each con fig item will appear.
The config entry variable in choice can only have two types: bool or tristate, and cannot have both types of variables at the same time. For bool type variables, only one of the multiple choices can be y; For tristate variables, either set multiple (of course, one) to m, or set only one to y and the rest to n. This is like a hardware has multiple drivers, either choose one to be programmed into the kernel, or compile multiple into modules.
(5) Element of Kconfig file: comment.
It is used to define help information, which will appear in the first line of the configuration interface; It will also appear in the configuration file. config (as a comment).
(6) Element of kconfig file: source.
Since most directories in the kernel source code have their own Kconfig files, a means is needed to organize all Kconfig files as a whole. This is the function of source, which is used to introduce another Kconfig file, which is a bit similar to #include in C language.
config file description:
When the make menuconfig configuration is completed and you exit, select save, and the user's selection will be saved in the top-level directory of the kernel source code config file.
2, Porting kernel for Exynos4412
1. Modify arch / arm / tools / Mach types h
The machine code of u-boot should be consistent with that of linux kernel. On the Internet, most of the machine codes of the modified linux kernel are in arch / arm / tools / Mach types H medium. I configure config when porting u-boot_ MACH_ Type is MACH_TYPE_EXYNOS4412. For the transplantation method of u-boot, please refer to another blog post Steps and principle analysis of Exynos4412 porting 2022 U-Boot Part III 3.
Find arch / arm / include / ASM / Mach types in U-Boot h. Exist
#define MACH_TYPE_TINY4412 4608
#define MACH_TYPE_EXYNOS4412 5030
So, in arch / arm / tools / Mach types In H, follow origen and add the machine code corresponding to exynos4412. As follows:
origen MACH_ORIGEN ORIGEN 3455 exynos4412 MACH_EXYNOS4412 EXYNOS4412 5030
2. Compile device tree
(1) The device tree file / arch / arm / boot / DTS / exynos4412 Origen. In the kernel source file A copy of the file is changed to cbtyn12.exdts-4412 DTS and modify
cp ./arch/arm/boot/dts/exynos4412-origen.dts ./arch/arm/boot/dts/exynos4412-cbt4412.dts gedit ./arch/arm/boot/dts/exynos4412-cbt4412.dts
Only the basic configuration of serial port and network card is reserved:
/dts-v1/;
#include "exynos4412.dtsi"
#include <dt-bindings/clock/samsung,s2mps11.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include "exynos-mfc-reserved-memory.dtsi"
/ {
model = "CBt4412 board based on Exynos4412";
compatible = "samsung,cbt4412", "samsung,exynos4412";
chosen {
bootargs ="console=ttySAC0,115200n8";
};
aliases {
serial0 = "/serial@13800000";
serial1 = "/serial@13800020";
console = "/serial@13800000";
};
memory-controller@12570000 {
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x04000000 0x20000 // Bank0
1 0 0x05000000 0x20000 // Bank1
2 0 0x06000000 0x20000 // Bank2
3 0 0x07000000 0x20000>; // Bank3
compatible = "samsung,exynos4210-srom";
reg = <0x12570000 0x14>;
ethernet@1,0 {
compatible = "davicom,dm9000";
reg = <0x5000000 0x2 0x5000004 0x2>;
interrupt-parent = <&gpx0>;
interrupts = <7 4>;
samsung,srom-page-mode;// normal(1data)page mode configuration
samsung,srom-timing = <9 12 1 9 1 1>;
davicom,no-eeprom;
mac-address = [00 11 22 33 44 55];
};
};
};
(2) Modify the / arch/arm/boot/dts/Makefile file and add our newly created device tree file exynos4412-cbt4412 dts
dtb-$(CONFIG_ARCH_EXYNOS4) += \ exynos4210-i9100.dtb \ exynos4210-origen.dtb \ exynos4210-smdkv310.dtb \ exynos4210-trats.dtb \ exynos4210-universal_c210.dtb \ exynos4412-i9300.dtb \ exynos4412-i9305.dtb \ exynos4412-itop-elite.dtb \ exynos4412-n710x.dtb \ exynos4412-odroidu3.dtb \ exynos4412-odroidx.dtb \ exynos4412-odroidx2.dtb \ exynos4412-origen.dtb \ exynos4412-cbt4412.dtb \
(3) Compile device tree
$ make dtbs DTC arch/arm/boot/dts/exynos4412-cbt4412.dtb
At this point, exynos4412-cbt4412.0 is generated in the arch/arm/boot/dts / directory dtb.
3.menuconfig graphical interface configuration
(1) Open the graphical configuration interface
make menuconfig
(2) Boot options —>
The following is another blog post Boot options configuration of boot settings3.
| option | explain |
|---|---|
| -*- Flattened Device Tree support | Support device tree. |
| [*] Support for the traditional ATAGS boot data passing | Support traditional ATAGS to start data transmission. Unless you rely only on the device tree, it is recommended to select. |
ATAGS is the traditional way for linux kernel to receive parameters, and the other is DTB. When the device is started, BOOT passes three parameters to the kernel. The content of R0 register is a "0", R1 is the machine code (matching with the kernel), and R3 is the address passed by ATAGS or DTB.
| option | explain |
|---|---|
| (0x0) Compressed ROM boot loader base address | default “0” . Storing the base address is very important for the startup of zImage compressed image. |
| (0x0) Compressed ROM boot loader BSS address | default “0”. The BSS address of the boot. |
| [*] Use appended device tree blob to zImage (EXPERIMENTAL) | Use the attached device tree blob for zimage (Experiment). |
With this option, the boot code will look for a device tree binary (DTB) appended to zImage (e.g. cat zImage .dtb > zImage_w_dtb).This is meant as a backward compatibility convenience for those systems with a bootloader that can't be upgraded to accommodate the documented boot protocol using a device tree. Beware that there is very little in terms of protection against this option being confused by leftover garbage in memory that might look like a DTB header after a reboot if no actual DTB is appended to Image. Do not leave this option active in a production kernel if you don't intend to always append a DTB.
Proper passing of the location into r2 of a bootloader provided DTB is always preferable to this option.
| option | explain |
|---|---|
| [*] Supplement the appended DTB with traditional ATAG information | Supplement additional DTB with traditional ATAG information |
Some old bootloaders can't be updated to a DTB capable one, yet they provide ATAGs with memory configuration, the ramdisk address, the kernel cmdline string, etc.Such information is dynamically provided by the bootloader and can't always be stored in a static DTB. To allow a device tree enabled kernel to be used with such bootloaders, this option allows zImage to extract the information from the ATAG list and store it at run time into the appended DTB.
| option | explain |
|---|---|
| [C] Kernel command line type | Kernel command line type. |
| [X] Use bootloader kernel arguments if available | The bootloader(uboot) parameter is preferred. If not, DTB ARGS is used. |
| [N] Extend with bootloader kernel arguments | Using DTB ARGS, the append provided by bootloader is after it. |
| (N) Default kernel command string | Default kernel command line string. |
Because it is much easier to modify environment variables through uboot than the kernel, it is more convenient to use bootloader. The problem is that the kernel configuration variables may be overwritten.
4. Compile and burn the kernel
1. Compile kernel
make uImage
Copy the kernel and device tree files to the / tftpboot directory
cp arch/arm/boot/uImage /CBT-SuperIOT/tftpboot/ cp arch/arm/boot/dts/exynos4412-cbt4412.dtb /CBT-SuperIOT/tftpboot/
2. If only
tftp 41000000 uImage\;bootm 41000000
Then an error will be reported: FDT and ATAGS support not compiled in
[10:05:48:201] ## Booting kernel from Legacy Image at 40008000 ...␍␊ [10:05:48:202] Image Name: Linux-5.15.14-CBT4412ARM␍␊ [10:05:48:216] Image Type: ARM Linux Kernel Image (uncompressed)␍␊ [10:05:48:216] Data Size: 6798528 Bytes = 6.5 MiB␍␊ [10:05:48:216] Load Address: 40008000␍␊ [10:05:48:216] Entry Point: 40008000␍␊ [10:05:48:226] Verifying Checksum ... OK␍␊ [10:05:49:098] Loading Kernel Image␍␊ [10:05:49:198] FDT and ATAGS support not compiled in␍␊
3. If you add a device tree,
tftp 41000000 uImage;tftp 42000000 exynos4412-cbt4412.dtb\;bootm 41000000 - 42000000
Then it will get stuck in the Starting kernel.
[10:57:04:816] CBT4412 #bootm 40008000 - 41000000␍␊ [10:57:16:748] ## Booting kernel from Legacy Image at 40008000 ...␍␊ [10:57:16:756] Image Name: Linux-5.15.14-CBT4412ARM␍␊ [10:57:16:756] Image Type: ARM Linux Kernel Image (uncompressed)␍␊ [10:57:16:766] Data Size: 6798528 Bytes = 6.5 MiB␍␊ [10:57:16:766] Load Address: 40008000␍␊ [10:57:16:774] Entry Point: 40008000␍␊ [10:57:16:774] Verifying Checksum ... OK␍␊ [10:57:17:648] ## Flattened Device Tree blob at 41000000␍␊ [10:57:17:663] Booting using the fdt blob at 0x41000000␍␊ [10:57:17:663] Loading Kernel Image␍␊ [10:57:17:830] Loading Device Tree to 7ae86000, end 7ae943af ... OK␍␊ [10:57:17:907] ␍␊ [10:57:17:907] Starting kernel ...␍␊ [10:57:17:907] ␍␊
Note: the tftp server is already running Exynos4412 Linux Kernel porting process record (I)1 Configuration in is complete.
3, Solve the problem that the U-Boot boot boot kernel is stuck in the Starting kernel
1. Correctly set the download address, loading address and entry address
The download address is the address of burning the kernel; The loading address is the address of the U-Boot copy zImage; The entry address is the address where the kernel starts. Bowen Modification of download address, loading address and entry address4 The analysis is very clear.
| number | condition | Load address | Entry address |
|---|---|---|---|
| 1 | Download address = load address | The copy of the loading address is uImage (image file with header) | Must = load address + 64byte |
| 2 | Download address= Load address | The copy of the loading address is zImage (the header structure is removed) | Must = load address |
Because my uImage information is
Image Name: Linux-5.15.14-CBT4412ARM Created: Sun Jan 16 10:03:01 2022 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6798528 Bytes = 6639.19 KiB = 6.48 MiB Load Address: 40008000 Entry Point: 40008000 Kernel: arch/arm/boot/uImage is ready
The Load Address is the same as the Entry Point. Therefore, the download address cannot be 0x40008000. You can set the download address to 0x41000000.
Therefore, the startup parameter is changed to
tftp 41000000 uImage;tftp 42000000 exynos4412-cbt4412.dtb;bootm 41000000 - 42000000
After rebooting, it is still stuck in the Starting kernel. Nevertheless, I think it is necessary to change the address parameters.
2. Set serial port 0 as the debug terminal
When the console information is executed to the Starting Kernel, it gets stuck. This print message is the last print message of uboot, that is, we can't determine whether the kernel has been started or not.
Generally, the common causes of kernel startup failure are mostly caused by incorrect parameters, that is, the value of r0-r2 register. The Mach ID and tag reference addresses can be printed out through uboot,
After eliminating the error of kernel parameter transmission, lock the problem to the kernel. Most of TI's early processors use Uart2 as the console by default. Because we use Uart0, we need to modify the kernel code.
In the main menu interface of menuconfig, enter / to enter the search interface. Then search UART0 to find symbol: debug_ S3C_ Kconfig option of UART2. As follows:
│ Symbol: DEBUG_S3C_UART0 [=y] │ Type : bool │ Defined at arch/arm/Kconfig.debug:1017 │ Prompt: Use Samsung S3C UART 0 for low-level debug │ Depends on: <choice> && (PLAT_SAMSUNG [=n] || ARCH_S5PV210 [=n] || ARCH_EXYNOS [=y]) │ Location: │ -> Kernel hacking │ -> arm Debugging │ -> Kernel low-level debugging functions (read help!) (DEBUG_LL [=y]) │ (4) -> Kernel low-level debugging port (<choice> [=y]) │ Selects: DEBUG_EXYNOS_UART [=y] && DEBUG_S3C24XX_UART [=n] && DEBUG_S3C64XX_UART [=n] && DEBUG_S5PV210_UART [=n]
It can be seen that at - > kernel hacking ---- > arm debugging, serial port 0 can be set as the debug terminal.
In addition, the following configurations may be required:
│ General setup —>
│ [*] Printk indexing debugfs interface
3. Open printk
One blog post raised a question description : hang on Uncompress done... booting the kernel. This problem is the same as that of the card in the Starting kernel in this article. The solution proposed in this blog post is: open early_printk. The specific steps are as follows:
(a). make menuconfig enter the menu interface and configure early in Kernel hacking_ PRINTK
│ Symbol: EARLY_PRINTK [=y]
│ Type : bool
│ Defined at arch/arm/Kconfig.debug:1897
│ Prompt: Early printk
│ Depends on: DEBUG_LL [=y]
│ Location:
│ -> Kernel hacking
│ (1) -> arm Debugging
(b) The following configurations may not be required
│ Device Drivers —>
│ Character devices —>
│ <*> TTY driver to output user messages via printk
│ (6) ttyprintk log level (1-7)
4. Modify uboot bootargs
Add earlyprintk to uboot bootargs:
setenv bootargs console=ttySAC0,115200n8 earlyprintk
5. Check the bootargs and machine code of the device tree
When starting the kernel, you often stop when you enter the following contents in the serial port, which is caused by the failure of parameter transmission or the incorrect configuration of machine code.
The machine code of u-boot should be consistent with that of linux kernel. On the Internet, most of the machine codes of the modified linux kernel are in arch / arm / tools / Mach types H medium. Find arch / arm / include / ASM / Mach types in u-boot h. I checked that the machine code is correct.
Then check that there is a problem with the bootargs of the device tree. After the changes are correct, compile and burn the dtb file to start the kernel.
The startup information is as follows. Although it is no longer stuck in the Starting kernel, it still fails to start successfully. One reason is that the device tree is incorrect. As can be seen from the startup information, sclk_apll = 0, sclk_mpll = 0，sclk_epll = 0, sclk_vpll = 0, arm_clk = 0. All four key PLL clocks are 0. The second reason is that the root file system is not mounted.
[21:40:10:805] ## Booting kernel from Legacy Image at 41000000 ...␍␊ [21:40:10:805] Image Name: Linux-5.15.14-CBT4412ARM␍␊ [21:40:10:805] Image Type: ARM Linux Kernel Image (uncompressed)␍␊ [21:40:10:835] Data Size: 7038440 Bytes = 6.7 MiB␍␊ [21:40:10:835] Load Address: 40008000␍␊ [21:40:10:835] Entry Point: 40008000␍␊ [21:40:10:835] Verifying Checksum ... OK␍␊ [21:40:11:724] ## Flattened Device Tree blob at 42000000␍␊ [21:40:11:730] Booting using the fdt blob at 0x42000000␍␊ [21:40:11:730] Loading Kernel Image␍␊ [21:40:11:916] Loading Device Tree to 7ae86000, end 7ae943a7 ... OK␍␊ [21:40:11:993] ␍␊ [21:40:11:993] Starting kernel ...␍␊ [21:40:11:993] ␍␊ [21:40:12:426] [ 0.000000] Booting Linux on physical CPU 0xa00␍␊ [21:40:12:429] [ 0.000000] Linux version 5.15.14-CBT4412ARM (exynos4412@exynos4412) (arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.3.1 20210621, GNU ld (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 2.36.1.20210621) #7 SMP PREEMPT Sun Jan 16 16:16:21 CST 2022␍␊ [21:40:12:466] [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d␍␊ [21:40:12:466] [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache␍␊ [21:40:12:477] [ 0.000000] OF: fdt: Machine model: CBt4412 board based on Exynos4412␍␊ [21:40:12:490] [ 0.000000] printk: bootconsole [earlycon0] enabled␍␊ [21:40:12:490] [ 0.000000] Memory policy: Data cache writealloc␍␊ [21:40:12:517] [ 0.000000] Reserved memory: created DMA memory pool at 0x7f800000, size 8 MiB␍␊ [21:40:12:517] [ 0.000000] OF: reserved mem: initialized node region-mfc-right, compatible id shared-dma-pool␍␊ [21:40:12:517] [ 0.000000] Reserved memory: created DMA memory pool at 0x7d400000, size 36 MiB␍␊ [21:40:12:517] [ 0.000000] OF: reserved mem: initialized node region-mfc-left, compatible id shared-dma-pool␍␊ [21:40:12:533] [ 0.000000] Samsung CPU ID: 0xe4412011␍␊ [21:40:12:533] [ 0.000000] Zone ranges:␍␊ [21:40:12:533] [ 0.000000] Normal [mem 0x0000000040000000-0x000000006fffffff]␍␊ [21:40:12:548] [ 0.000000] HighMem [mem 0x0000000070000000-0x000000007fffffff]␍␊ [21:40:12:548] [ 0.000000] Movable zone start for each node␍␊ [21:40:12:548] [ 0.000000] Early memory node ranges␍␊ [21:40:12:548] [ 0.000000] node 0: [mem 0x0000000040000000-0x000000007d3fffff]␍␊ [21:40:12:564] [ 0.000000] node 0: [mem 0x000000007d400000-0x000000007fffffff]␍␊ [21:40:12:564] [ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]␍␊ [21:40:12:585] [ 0.000000] percpu: Embedded 16 pages/cpu s33740 r8192 d23604 u65536␍␊ [21:40:12:592] [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 260608␍␊ [21:40:12:601] [ 0.000000] Kernel command line: console=ttySAC0,115200n8 earlyprintk␍␊ [21:40:12:608] [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)␍␊ [21:40:12:617] [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)␍␊ [21:40:12:627] [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off␍␊ [21:40:12:687] [ 0.000000] Memory: 976224K/1048576K available (10240K kernel code, 1175K rwdata, 4060K rodata, 1024K init, 278K bss, 72352K reserved, 0K cma-reserved, 217040K highmem)␍␊ [21:40:12:700] [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1␍␊ [21:40:12:715] [ 0.000000] trace event string verifier disabled␍␊ [21:40:12:715] [ 0.000000] rcu: Preemptible hierarchical RCU implementation.␍␊ [21:40:12:720] [ 0.000000] ⇥ Trampoline variant of Tasks RCU enabled.␍␊ [21:40:12:751] [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.␍␊ [21:40:12:751] [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16␍␊ [21:40:12:751] [ 0.000000] L2C: platform modifies aux control register: 0x02070000 -> 0x0a470000␍␊ [21:40:12:751] [ 0.000000] L2C: DT/platform modifies aux control register: 0x02070000 -> 0x3a470000␍␊ [21:40:12:767] [ 0.000000] L2C-310 erratum 769419 enabled␍␊ [21:40:12:767] [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9␍␊ [21:40:12:767] [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9␍␊ [21:40:12:778] [ 0.000000] L2C-310 ID prefetch enabled, offset 8 lines␍␊ [21:40:12:778] [ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled␍␊ [21:40:12:792] [ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB␍␊ [21:40:12:792] [ 0.000000] L2C-310: CACHE_ID 0x4100c4c8, AUX_CTRL 0x7e470001␍␊ [21:40:12:871] [ 0.000000] random: get_random_bytes called from start_kernel+0x50c/0x6b8 with crng_init=0␍␊ [21:40:12:877] [ 0.000000] Exynos4x12 clocks: sclk_apll = 0, sclk_mpll = 0␍␊ [21:40:12:884] [ 0.000000] ⇥ sclk_epll = 0, sclk_vpll = 0, arm_clk = 0␍␊ [21:40:12:896] [ 0.000000] Division by zero in kernel.␍␊ [21:40:12:896] [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.14-CBT4412ARM #7␍␊ [21:40:12:906] [ 0.000000] Hardware name: Samsung Exynos (Flattened Device Tree)␍␊ [21:40:12:906] [ 0.000000] [<c0115e28>] (unwind_backtrace) from [<c0110b54>] (show_stack+0x10/0x14)␍␊ [21:40:12:921] [ 0.000000] [<c0110b54>] (show_stack) from [<c0a2be6c>] (dump_stack_lvl+0x40/0x4c)␍␊ [21:40:12:933] [ 0.000000] [<c0a2be6c>] (dump_stack_lvl) from [<c04fb274>] (Ldiv0+0x8/0x10)␍␊ [21:40:12:933] [ 0.000000] [<c04fb274>] (Ldiv0) from [<c01bde48>] (clockevents_config.part.0+0x20/0x7c)␍␊ [21:40:12:947] [ 0.000000] [<c01bde48>] (clockevents_config.part.0) from [<c01bdec4>] (clockevents_config_and_register+0x20/0x2c)␍␊ [21:40:12:947] [ 0.000000] [<c01bdec4>] (clockevents_config_and_register) from [<c0755830>] (exynos4_mct_starting_cpu+0xfc/0x11c)␍␊ [21:40:12:959] [ 0.000000] [<c0755830>] (exynos4_mct_starting_cpu) from [<c012a464>] (cpuhp_invoke_callback+0x158/0x888)␍␊ [21:40:12:974] [ 0.000000] [<c012a464>] (cpuhp_invoke_callback) from [<c012ae64>] (cpuhp_issue_call+0x154/0x1b0)␍␊ [21:40:12:990] [ 0.000000] [<c012ae64>] (cpuhp_issue_call) from [<c012b288>] (__cpuhp_setup_state_cpuslocked+0x108/0x294)␍␊ [21:40:12:990] [ 0.000000] [<c012b288>] (__cpuhp_setup_state_cpuslocked) from [<c012b4ac>] (__cpuhp_setup_state+0x98/0x190)␍␊ [21:40:13:002] [ 0.000000] [<c012b4ac>] (__cpuhp_setup_state) from [<c1026570>] (mct_init_dt+0x260/0x3dc)␍␊ [21:40:13:002] [ 0.000000] [<c1026570>] (mct_init_dt) from [<c10262a0>] (timer_probe+0x74/0xe4)␍␊ [21:40:13:016] [ 0.000000] [<c10262a0>] (timer_probe) from [<c1004c2c>] (time_init+0x28/0x30)␍␊ [21:40:13:031] [ 0.000000] [<c1004c2c>] (time_init) from [<c1000e84>] (start_kernel+0x540/0x6b8)␍␊ [21:40:13:031] [ 0.000000] [<c1000e84>] (start_kernel) from [<00000000>] (0x0)␍␊ [21:40:13:031] [ 0.000000] ------------[ cut here ]------------␍␊ [21:40:13:041] [ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/time/clockevents.c:38 cev_delta2ns+0x11c/0x140␍␊ [21:40:13:054] [ 0.000000] Modules linked in:␍␊ [21:40:13:054] [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.14-CBT4412ARM #7␍␊ [21:40:13:066] [ 0.000000] Hardware name: Samsung Exynos (Flattened Device Tree)␍␊ [21:40:13:066] [ 0.000000] [<c0115e28>] (unwind_backtrace) from [<c0110b54>] (show_stack+0x10/0x14)␍␊ [21:40:13:081] [ 0.000000] [<c0110b54>] (show_stack) from [<c0a2be6c>] (dump_stack_lvl+0x40/0x4c)␍␊ [21:40:13:081] [ 0.000000] [<c0a2be6c>] (dump_stack_lvl) from [<c0128f98>] (__warn+0xec/0x148)␍␊ [21:40:13:092] [ 0.000000] [<c0128f98>] (__warn) from [<c0a292ac>] (warn_slowpath_fmt+0x64/0xbc)␍␊ [21:40:13:105] [ 0.000000] [<c0a292ac>] (warn_slowpath_fmt) from [<c01bd808>] (cev_delta2ns+0x11c/0x140)␍␊ [21:40:13:105] [ 0.000000] [<c01bd808>] (cev_delta2ns) from [<c01bde7c>] (clockevents_config.part.0+0x54/0x7c)␍␊ [21:40:13:116] [ 0.000000] [<c01bde7c>] (clockevents_config.part.0) from [<c01bdec4>] (clockevents_config_and_register+0x20/0x2c)␍␊ [21:40:13:116] [ 0.000000] [<c01bdec4>] (clockevents_config_and_register) from [<c0755830>] (exynos4_mct_starting_cpu+0xfc/0x11c)␍␊ [21:40:13:128] [ 0.000000] [<c0755830>] (exynos4_mct_starting_cpu) from [<c012a464>] (cpuhp_invoke_callback+0x158/0x888)␍␊ [21:40:13:141] [ 0.000000] [<c012a464>] (cpuhp_invoke_callback) from [<c012ae64>] (cpuhp_issue_call+0x154/0x1b0)␍␊ [21:40:13:153] [ 0.000000] [<c012ae64>] (cpuhp_issue_call) from [<c012b288>] (__cpuhp_setup_state_cpuslocked+0x108/0x294)␍␊ [21:40:13:166] [ 0.000000] [<c012b288>] (__cpuhp_setup_state_cpuslocked) from [<c012b4ac>] (__cpuhp_setup_state+0x98/0x190)␍␊ [21:40:13:166] [ 0.000000] [<c012b4ac>] (__cpuhp_setup_state) from [<c1026570>] (mct_init_dt+0x260/0x3dc)␍␊ [21:40:13:177] [ 0.000000] [<c1026570>] (mct_init_dt) from [<c10262a0>] (timer_probe+0x74/0xe4)␍␊ [21:40:13:190] [ 0.000000] [<c10262a0>] (timer_probe) from [<c1004c2c>] (time_init+0x28/0x30)␍␊ [21:40:13:190] [ 0.000000] [<c1004c2c>] (time_init) from [<c1000e84>] (start_kernel+0x540/0x6b8)␍␊ [21:40:13:201] [ 0.000000] [<c1000e84>] (start_kernel) from [<00000000>] (0x0)␍␊ [21:40:13:217] [ 0.000000] ---[ end trace e39a1885fa9bcc5f ]---␍␊
Yang Zhu, et al Practice of building embedded Linux core software system Beijing University of Aeronautics and Astronautics Press, 2013, ↩︎
linux kernel configuration reset, linux kernel configuration – Boot options ↩︎ ↩︎
Modification of download address, loading address and entry address ↩︎