Embedded Linux Development Guide
1 Embedded Linux Development Guide Revision: January 14, NE Henley Court, Suite 3 Pullman, WA (509) Voice (509) Fax This Embedded Linux Development Guide will provide some preliminary knowledge on how to build Linux for Digilent boards based on the Zynq-7000 TM All-Programmable System-on-Chip (ZYNQ AP SoC) to suit your customized hardware designs. This guide takes a bottom-up approach by starting from a hardware design on the ZYNQ AP SoC Board, moving through the necessary preliminary processes, and eventually giving instructions for running and debugging the Linux kernel. Section I: Hardware Customization begins with the Linux Hardware Design Package for ZYNQ AP SoC boards, available on the Digilent Inc. website. This section then illustrates the ZYNQ AP SoC basic architecture and explains how to create customized hardware using Xilinx Platform Studio (XPS) available in the Xilinx ISE Design Suite WebPack. Section II: Device Tree Describe Your Hardware to the Linux Kernel examines how the Linux kernel gathers information about the customized hardware. Section II takes a closer look at a data structure called the Device Tree Blob (DTB), explains how to write a Device Tree Source (DTS) file, and how to compile the source into a DTB file. Section III: U-Boot The Embedded Boot Loader introduces U-Boot, a popular boot loader for Linux used by many embedded systems. Section III presents preliminary knowledge about how to configure and build U-Boot, and provides an introduction of some commonly used U-Boot commands. After explaining all the prerequisites for running The Linux kernel (boot loaders, device trees, etc.), the guide moves to configuring the Linux kernel in Section IV: Linux Kernel Configuration. This section demonstrates customizable features useful for custom hardware design. This section also provides information for building and customizing the kernel, file system customization, and finally running the Linux kernel on ZYNQ AP SoC based boards. During the compilation and running of The Linux kernel on your customized hardware, there is a chance that the kernel will panic and generate an Oops message or completely cease functioning. The Appendix: How to Debug the Linux Kernel introduces you to some simple debugging techniques to follow when errors occur with the Linux kernel. Before creating custom hardware or using the Linux kernel, Digilent Inc. recommends that users have some experience with embedded Linux development on other embedded systems or they have read the Getting Started with Embedded Linux guide for their platform. Moreover, users can read this documentation along with the Embedded Linux Hands-on Tutorial for their specific Zynq AP SoC board. These documents are available on the Digilent Website, Embedded Linux page and the webpage for your product. page 1 of 23
2 Section I: Hardware Customization Before creating your customized hardware, we suggest you start with the Linux Hardware Design Project available on your board s Digilent product webpage. The reference design includes the proper configuration for most of the peripheral devices available on-board your product including the interrupt controller, timer, clock generator, AXI interconnects, etc. that are all essential for Linux to operate properly. Processing System UART1 GPIO SD0 USB0 Application Processor Unit SWDT TTC SLCR MMU NEON/FPU Engine 32KB I Cache GIC Cortex-A9 MPCore CPU 32KB D Cache OCM Interconnect MMU NEON/FPU Engine 32KB I Cache Snoop Control Unit Cortex-A9 MPCore CPU 32KB D Cache 512KB L2 Cache & Controller 256KB OCM BootROM Enet0 QSPI Central Interconnect PL to Memory Interconnect DDR2/3 Memory Controller 512 MB DDR3 Axi Interconnect 1 AXI Interconnect 0 (AXI_LITE) Clock generator AXI DMA AXI DMA Axi Interconnect 2 AXI VDMA Axi_clkgen Axi_gpio (ADAU1761) Axi_i2s_adi (ADAU1761) Axi_iic (ADAU1761) Axi_spdif_tx (ADV7511) Axi_hdmi_tx_16b (ADV7511) Axi_iic (ADV7511) Programmable Logic Figure 1. System Architecture of Linux Hardware Design Project for ZedBoard page 2 of 23
3 The Linux Hardware Design Project posted on the Digilent website usually contains the hardware controllers for all of your product peripheral devices and the GPIO for extension pins (e.g. Pmods, VHDC, FMC, etc.) Before you begin hardware customization, please read the documentation inside the Linux Hardware Design for your product, which explains the hardware in detail, and the Embedded Linux Hands-on Tutorial, which guides you through step by step instructions for making changes to the reference hardware design. First Stage Boot Loader (FSBL) We discuss the First Stage Boot Loader (FSBL) here because of its integral relationship with hardware design. Digilent recommends that you recompile the FSBL every time you make hardware changes. The FSBL will do several simple initialization steps for the Processing System (PS), like setting up a clock generator. It also has board-specific modifications that perform several initialization steps for various on-board devices. For instance, the FSBL for the ZedBoard will toggle the reset pin of USB-OTG to perform a reset before Linux gets loaded. You just need to make a few clicks to generate the FSBL. The project guide within the Linux Hardware Design and hands-on tutorial for your specific board will guide you through it. You can also refer to the ZYNQ Software Developers Guide available on the Xilinx website at page 3 of 23
4 Section II: Device Tree Describe Your Hardware to the Linux Kernel The Linux Kernel is a piece of embedded standalone software running on your hardware. The kernel provides a standardized interface for application programmers to utilize all hardware resources without knowing the details. Thus, the kernel has to know every detail about the hardware it is working on. The Linux Kernel uses the data structure known as Device Tree Blob (DTB) to describe your hardware. Sometimes DTB is called Flat Device Tree (FDT), Device Tree Binary, or simply Device Tree. 1 Section II takes a closer look at the device tree and examines how the Linux kernel interprets and understands your hardware. Device Tree Source (DTS) The Device Tree Source (DTS) file is the source file you use to create the device tree data structure that passes to the kernel during kernel booting. The file is a simple tree structure comprised of nodes and properties. Properties are key-value pairs, and nodes may contain both properties and child nodes. 2 (See Example 1.) Example 1. /dts-v1/; / < model = "Xilinx Zynq ZED"; compatible = "xlnx,zynq-zed"; #address-cells = ; #size-cells = ; interrupt-parent = ; ps7_ddr_0: < device_type = "memory"; reg = ; >; ps7_axi_interconnect_0: < #address-cells = ; #size-cells = ; compatible = "xlnx,ps7-axi-interconnect-1.00.a", "simple-bus"; ranges ; gic: < interrupt-controller; compatible = "arm,cortex-a9-gic"; #interrupt-cells = ; reg = , ; >; We abstracted the part of the device tree source code in Example 1 from the ZedBoard default device tree source file. In the device tree source file / stands for the root node and everything inside the 1 Hallinan, Christopher. Embedded Linux primer: a practical, real-world approach. Upper Saddle River, NJ: Prentice Hall, page 4 of 23
5 brackets <> are either properties of the root nodes or the children of the root node. In Example 1, the first property of the root node is model. String Xilinx Zynq ZED is assigned to it. Property compatible defines the compatibility of the node, and, in this case, is given the compatibility string xlnx,zynq-zed ; The children of the root nodes include the on-board DDR3 SDRAM, ps7_ddr_0, and the central AXI interconnects for the whole system, ps7_axi_interconnect_0. There are many more children of the root nodes in the default DTS file. The following sub-sections introduce the basic structures of nodes and some of the most common node properties. You can find more detailed information about the device tree under folder Documentation/devicetree/ in the Linux kernel source. Device Nodes Example 2 demonstrates the basic structure of device nodes. Example 2. The Name field is the name you assigned to the device tree node. The name of the node is not required, but should be unique in the whole tree if assigned. You can obtain the phandler of the device node with the notation &(name). The part (Generic Address)actually forms the full name of the device node. According to conventions, the full name of the device is usually a generic name followed by the base address of the device. The Generic Name field describes the generic class of the device, such as Ethernet, qspi, i2c, etc. The Base Address field gives the base address for the device node. Some devices are virtual devices that do not have a physical memory mapped in the processor memory space. For these devices, The code drops Address) for devices with no mapped physical memory. In Example 3, the leds defined in the DTS file does not have a base address, because it utilizes a bit in the GPIO controller to control an on-board LED. Example 3. (Name) : (Generic Address) < compatible: (compatibility string) ; reg: ; interrupt-parents: ; interrupts: ; (param1): (string value) ; (param2): ; >; leds < compatible = "gpio-leds"; >; mmc_led < label = "mmc_led"; gpios = ; linux,default-trigger = "mmc0"; >; page 5 of 23
6 Properties Properties are key-value pairs. The value of a property can either be a character string (e.g. the value for compatible property), or a list of either decimal or hexadecimal numbers (e.g. the value of reg property). Each node requires a compatible property. A compatibility string will be assigned to that property. You can use it to match device drivers with devices defined in the device tree. In Example 3, the compatible property for device node leds is set to string gpio-leds, which indicates the gpio-leds driver will be used for the device. Usually, the device node name includes the base address of the device. However, the kernel actually obtains the physical address of device registers via the reg property. The value of the reg property contains a list of paired numbers separated by commas. Each pair begins with the base address of the device, followed by the size of the register space. The corresponding kernel driver can usually obtain the physical memory address with the function platform_get_resource and map the physical memory into kernel virtual memory space by functions such as ioremap. If your device has interrupt functionality, you must specify the interrupt number in the interrupt property and set the interrupt-parent property to the phandler of the interrupt controller. You can obtain the phandler of the interrupt controller with &(name field of interrupt controller). For more in depth information on using the Zynq AP SoC interrupt controller with a device tree, see Documentation/devicetree/bindings/arm/gic.txt within the kernel source. OLED DTS Node: An Example We abstract the following codes from the ZedBoard default device tree. 1 Example 4. gpiops: < compatible = "xlnx,ps7-gpio-1.00.a"; #gpio-cells = ; reg = ; interrupts = ; interrupt-parent = ; gpio-controller; >; zed_oled < compatible = "dglnt,pmodoled-gpio"; /* GPIO Pins */ vbat-gpio = ; vdd-gpio = ; res-gpio = ; dc-gpio = ; /* SPI-GPIOs */ spi-bus-num = ; spi-sclk-gpio = ; spi-sdin-gpio = ; >; page 6 of 23
7 In Example 4, two devices are declared: the GPIO controller for Processing System of ZYNQ, gpiops, and the on-board OLED display, zed_oled. The device tree names the node for the GPIO controller gpiops, with the generic name of gpio and a base address starting from 0xe000a000, according to conventional naming of the node. The full name of gpiops is as shown in the /sys file system and /proc file system. The compatibility string of the GPIO controller is xlnx,ps7-gpio-1.00.a. The device will use the xlnx-gpiops driver by matching the compatibility string of the node with that defined in the driver source code. The reg property defines the gpiops GPIO controller by a physical address that begins from 0xe000a000 with a size of 0x1000 (64KB). The interrupt is connected to the global interrupt controller gic, as the phandler of gic (&gic in the DTS) passes to the interrupt-parent property. The second node shown in Example 4 is a device 55 VBAT with full name zed_oled. It is for the on-board OLED device on the ZedBoard. In the hardware 56 VDD design, the OLED is connected directly to the 57 RES gpiops GPIO controller (pin 55 to pin 60), as GPIO shown in Figure 2. So, you can implement the driver 58 D/C OLED of the on-board OLED for the ZedBoard by getting the GPIO pin number from the zed_oled device node and toggling the corresponding GPIO pins according to the OLED display transmission SCLK SDIN protocol. As a result, the device zed_oled is not actually a device controller with a physical register Figure 2. OLED Hardware Connection space mapped in memory space, but a virtual device defined so that the driver in the kernel knows which GPIO pins are used. So, there is no base address, no register space, address> part in the full name of the device nodes, and no reg properties in the device tree. The device does have a compatibility string so that the corresponding pmodoled-gpio driver can be registered for the device and toggle the GPIO pins to control the OLED display. There are also several properties that specify which GPIO pins to use. 1 Device Tree Compilation The DTS file needs to be compiled into a DTB file that the kernel can understand. The device tree compiler (DTC), located under scripts/dtc in the Linux kernel source, will compile the DTS file into a DTB file with the command: $./scripts/dtc/dtc -I dts -O dtb -o devicetree.dtb digilent_zed.dts The DTC compiler can also de-compile a DTB file back to the DTS file with the command: $./scripts/dtc/dtc -I dtb -O dts -o digilent_zed.dts devicetree.dtb You can view other options for the DTC compiler with the -h option: 1 Structure gpio-specifier is passed to the properties (e.g. vbat-gpio = ). Refer to Documentation/devicetree/bindings/gpio/gpio.txt for more details. page 7 of 23
8 $./scripts/dtc/dtc -h Booting With Device Tree The boot loader needs to load the Device Tree into the system memory before starting the kernel. For Zynq based platforms, the boot loader will load the DTB to a fixed memory address 0x It is defined in line 112 of arch/arm/kernel/head.s page 8 of 23
9 Section III: U-Boot Embedded Linux Boot Loader Zynq AP SoC based platforms utilize a multi-stage booting scheme, consisting of BootROM (Stage 0), FSBL and a Second Stage Boot Loader (SSBL) if required. Section I: Hardware Customization discusses the FSBL in more detail. To boot Linux on the ZedBoard, Digilent Inc. recommends U-Boot, a fully supported Second Stage Boot Loader that prepares the basic environment to boot and run the embedded Linux software. Booting Sequence When you power on the Zynq AP SoC based development platform, the Stage 0 Boot Loader, located in BootROM, will start to run. The codes will check the BootMode pins of the Zynq chip to determine from which interface to load the FSBL. ZYNQ AP SoC based platforms support loading the FSBL from five kinds of interfaces—jtag, QSPI Flash, NAND Flash, NOR Flash, and SD card. Section III will demonstrate booting from the SD Card. Note: You must provide a kernel image, DTB, file systems, etc. to run embedded Linux. These files may take up storage space from several mega-bytes to even a few giga-bytes. An SD card with up to 32GB of storage is the best fit for embedded Linux development. This manual will focus on SD card booting as the fastest and most efficient means of booting. You have to do two things before you can boot with the SD card. First, ensure that you configure the BootMode pins of your board to SD Boot Mode (refer to the documentation Getting Started With Embedded Linux for your board). Second, make sure you have a properly partitioned SD card according to the guidelines in the Getting Started with Embedded Linux for your board. If properly configured, the Stage 0 Boot Loader will load the file BOOT.BIN in the first partition of your SD card into On-Chip Memory (OCM), and start executing from the beginning of OCM. The file BOOT.BIN comprises the FSBL, PL logic bit files, and the SSBL (u-boot.elf in this case). The FSBL will download the PL logic bit file to the PL system, set up the PLL in the PS system and execute some other fundamental bring-up routines for peripheral devices, and finally call up the SSBL to take over control and begin loading the operating system. Digilent Inc. uses U-Boot as the SSBL. U-Boot can obtain a kernel image from an SD Card, partitioned QSPI Flash, and even through Ethernet using TFTP (Trivial FTP) if you have a functional TFTP server. By default, U-Boot starts the procedure called autoboot, which looks for the BootMode pin settings again for the source of the kernel image (in our case, an SD card). So, U-Boot calls the procedure sdboot. The procedure sdboot does three things. First, sdboot reads the kernel image (named zimage as shown below) from the FAT partition and copies it to 0x Second, sdboot reads the DTB file (named as devicetree.dtb in Figure 5) and loads it to 0x Third, sdboot reads the zipped ramdisk file system named ramdisk8m.image.gz (See Example 5.) and loads it to 0x After all the loading, U-Boot starts to run the kernel image from where sdboot loaded it. page 9 of 23
10 Example 5. U-Boot dirty (Jul :07:00) DRAM: 512 MiB MMC: SDHCI: 0 Using default environment In: serial Out: serial Err: serial Net: zynq_gem Hit any key to stop autoboot: 0 Copying Linux from SD to RAM. Device: SDHCI Manufacturer ID: 3 OEM: 5344 Name: SU04G Tran Speed: Rd Block Len: 512 SD version 1.10 High Capacity: Yes Capacity: Bus Width: 1-bit reading zimage bytes read reading devicetree.dtb 5817 bytes read reading ramdisk8m.image.gz bytes read ## Starting application at 0x Uncompressing Linux. done, booting the kernel. [ ] Booting Linux on physical CPU 0 U-Boot Commands Before the autoboot starts, there is a default three-second count down. Users may press any key during the count-down to interrupt the autoboot procedure and type in custom commands to boot the Linux kernel manually. Here are some of the most popular commands: Printenv will print the environment variables of u-boot. (See Example 6.) page 10 of 23
11 Example 6. zed-boot> printenv baudrate= bootcmd=run modeboot bootdelay=3 ethact=zynq_gem ethaddr=00:0a:35:00:01:22 ipaddr= jtagboot=echo TFTPing Linux to RAM. ;tftp 0x8000 zimage;tftp 0x devicetree.dtb;tftp 0x ramdisk8m.image.gz;go 0x8000 kernel_size=0x modeboot=run sdboot qspiboot=sf probe 0 0 0;sf read 0x8000 0x x2c0000;sf read 0x x3c0000 0x40000;sf read 0x x x800000;go 0x8000 ramdisk_size=0x sdboot=echo Copying Linux from SD to RAM. ;mmcinfo;fatload mmc 0 0x8000 zimage;fatload mmc 0 0x devicetree.dtb;fatload mmc 0 0x ramdisk8m.image.gz;go 0x8000 sdboot_linaro=echo Copying Linux from SD to RAM. ;mmcinfo;fatload mmc 0 0x8000 zimage;fatload mmc 0 0x devicetree_linaro.dtb;go 0x8000 serverip= stderr=serial stdin=serial stdout=serial Environment size: 861/65532 bytes Echo will display a string on the serial port. (See Example 7.) Example 7. zed-boot> echo Hullo World Hullo World zed-boot> Mmcinfo will display the information about your Multi-Media Card. Example 8 is for an SD card. Example 8. zed-boot> mmcinfo Device: SDHCI Manufacturer ID: 3 OEM: 5344 Name: SU04G Tran Speed: Rd Block Len: 512 SD version 1.10 High Capacity: Yes Capacity: Bus Width: 1-bit Fatload will load a file from the FAT partition to a specified memory location. The following instruction loads zimage from the MMC (SD Card) first FAT partition to 0x8000 in the processor s memory space. (See Example 9.) page 11 of 23
12 Example 9. zed-boot> fatload mmc 0 0x8000 zimage reading zimage bytes read zed-boot> The sf subsystem allows U-Boot to load a system from SPI Flash. The functions sf subsystem provides include probe, erase, read and write. Probe will probe the FLASH device on the corresponding flash controller into the system (the following codes probe the flash connected to QSPI0. (See Example 10.) Example 10. zed-boot> sf probe 0 SF: Detected S25FL256S_4KB_64KB with page size 256, total 128 KiB 128 KiB S25FL256S_4KB_64KB at 0:0 is now current device Erase will erase the data from FLASH memory. Example 11 erases 0x40000 bytes data starting from address 0 in FLASH. Example 11. sf erase 0 0x40000 Read will read the data from FLASH memory into processor memory. Example 12 reads 0x2c0000 bytes of data from offset 0x in Flash memory into 0x8000 in main memory. Example 12. sf read 0x8000 0x x2c0000 Write will write the data to FLASH memory from processor memory. Example 13 writes 0x3E444 bytes of data from 0x in main memory into Flash memory with 0 offset. Example 13. sf write 0x x3E444 Customize U-Boot Yourself If you want to customize U-Boot, download the source files from the git repository u-bootdigilent at (See Example 14.) Example 14. $git clone The settings of the board you have are located under include/configs/ .h. For example, the configure header file for the ZedBoard is named zynq_zed.h. page 12 of 23
13 Configure U-Boot through a series of macros defined by the board header files. Example 15 shows the main part we abstracted from the ZedBoard configuration header file for the ZedBoard. Example 15. #define CONFIG_EXTRA_ENV_SETTINGS \ «ethaddr=00:0a:35:00:01:22\0» \ «kernel_size=0x140000\0» \ «ramdisk_size=0x200000\0» \ «qspiboot=sf probe 0 0 0;» \ «sf read 0x8000 0x x2c0000;» \ «sf read 0x x3c0000 0x40000;» \ «sf read 0x x x800000;» \ «go 0x8000\0» \ «sdboot_linaro=echo Copying Linux from SD to RAM. ;» \ «mmcinfo;» \ «fatload mmc 0 0x8000 zimage;» \ «fatload mmc 0 0x devicetree_linaro.dtb;» \ «go 0x8000\0» \ «sdboot=echo Copying Linux from SD to RAM. ;» \ «mmcinfo;» \ «fatload mmc 0 0x8000 zimage;» \ «fatload mmc 0 0x devicetree.dtb;» \ «fatload mmc 0 0x ramdisk8m.image.gz;» \ «go 0x8000\0» \ «jtagboot=echo TFTPing Linux to RAM. ;» \ «tftp 0x8000 zimage;» \ «tftp 0x devicetree.dtb;» \ «tftp 0x ramdisk8m.image.gz;» \ «go 0x8000\0» #define CONFIG_IPADDR #define CONFIG_SERVERIP In the environment settings for Example 15, ethaddr defines the initial MAC address of your board and CONFIG_IPADDR defines the IP address of your board when U-Boot is running. The environment variable sdboot defines SD card booting procedure as follows: Echo Copying Linux from SD to RAM ; Display Multi-Media Card (MMC) information by calling function mmcinfo; load zimage from SD Card to Memory at 0x8000; Loading devicetree.dtb to memory at 0x ; loading ram disk image ramdisk8m.image.gz to memory at 0x800000; and start from 0x8000 to run The Linux Kernel. You can change the booting sequence by changing the environment variables here. page 13 of 23
14 Section IV: Linux Kernel Configuration The Linux kernel provides thousands of configurations to allow users to tailor kernel features based on their specific needs. Kernel configuration can be very tedious, so we recommend you begin with the default configuration as a baseline and start adding more features if you need them. Configure the Linux Kernel You can find the default configuration for your Digilent board at arch/arm/configs in the kernel source under the name digilent_ _defconfig (e.g. digilent_zed_defconfig for ZedBoard). You can import the default board configuration by running command: $ make ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi- digilent_ _defconfig The kernel configuration system has several different targets. You can show these configuration targets by typing $make help under the root folder of kernel source. Example 16 demonstrates the most common configuration targets. Example 16. Configuration targets: config — Update current config utilising a line-oriented program nconfig — Update current config utilising a ncurses menu based program menuconfig — Update current config utilising a menu based program xconfig — Update current config utilising a QT based front-end gconfig — Update current config utilising a GTK based front-end oldconfig — Update current config utilising a provided.config as base defconfig — New config with default from ARCH supplied defconfig Refer to kconfig.txt and kconfig-language.txt under the Documentation/kbuild folder for more information concerning the kernel configuration subsystem. Kernel Arguments Some of the configurations can be passed to kernel at boot time, like the default serial port for early printk, the root file system, etc. The default kernel booting arguments can be set in the kernel configuration menu at Boot Options -> Default kernel command string (CONFIG_CMDLINE). However, the bootargs property under node chosen in the device tree can overwrite the default kernel booting arguments. (See Example 17.) Example 17. chosen < bootargs = "console=ttyps0, root=/dev/ram rw initrd=0x800000,8m earlyprintk rootfstype=ext4 rootwait devtmpfs.mount=1"; linux,stdout-path = >; We abstracted the boot arguments in Example17 from the ZedBoard device tree. These boot arguments show that the default console is set to ttyps0 which is the UART0 of the Zynq PS system and the root device is set to a ramdisk with read and write privileges, located at 0x with a size of 8M. Early Printk is allowed and the root file system (i.e. the initial ramdisk image) is ext4. page 14 of 23
15 For more detailed information about kernel parameters, please refer to kernel-parameter.txt under Documentation in the Linux kernel source. File System Customization The Linux Kernel is a standalone program that manages system resources and provides a standardized Application Programming Interface (API) for user applications to interact with hardware. The Linux Kernel requires a file system to become a computer system. Otherwise, the kernel cannot interact with the human and will panic immediately. The Appendix: How to Debug the Linux Kernel discusses procedures for dealing with panics. Configure Root File System You must specify a root file system in the kernel arguments with: root=/dev/ram rw initrd=0x800000,8m rootfstype=ext4 As explained in the previous section, it assigns the root file system to the ramdisk that is loaded into Memory (/dev/ram) at 0x If you want to boot a system like the Linaro Desktop from partition 2 on your SD card, then change the previous argument to: root=/dev/mmcblk0p2 rw rootfstype=ext4 This line points the root file system to the block device /dev/mmcblk0p2 that is the second partition on the SD card. For detailed instructions about how to format your SD card and install Linaro, please refer to the Getting Started With Embedded Linux guides available on Digilent Website, Embedded Linux Page. Boot with Ramdisk The ramdisk image is available at Digilent Website, Embedded Linux Page as well. To customize the ramdisk, you need to decompress it first with the command $ gzip -d ramdisk8m.image.gz The command will remove the zipped file and substitute it with a decompressed file named ramdisk8m.image. Then you can mount the ramdisk8m.image to a directory in your file system with: $ sudo mount ramdisk8m.image /mnt/ramdisk -o loop You can make changes to the file system directly by reading and writing the /mnt/ramdisk folder. After you finished the customization, unmount ramdisk8m.image with the command: $ sudo umount /mnt/ramdisk Zip the file up again with the command: page 15 of 23
16 $ gzip -9 ramdisk8m.image.gz The Ramdisk image will be loaded into the main memory before Linux boots. So, all the changes to the file system during runtime will only take place in the memory and will not get written back to Ramdisk image file when the system shuts down. If you want to preserve your changes, you need to consider hosting the file system on the SD card partition. Boot from SD Card Partition To boot a filesystem loaded on an SD card requires at least two partitions be present on the SD card. The first partition of the SD card should be formatted into FAT to hold design files (BOOT.BIN), the DTB file (devicetree.dtb) and the kernel image (zimage). Format the second partition on the SD into an ext file system (ext4 is recommended) to host the root file system. Most Linux distributions provide tools like parted and fdisk to create a partition table on the SD card. Refer to Getting Started with Embedded Linux found at the Embedded Linux page on the Digilent website for step-bystep instructions on how to partition an SD card to host the root file system. page 16 of 23
17 APPENDIX: How to Debug the Linux Kernel Things may go wrong during your development the kernel may panic and become dead without any notice during boot; there may be no messages that appear on your terminal; the kernel may say Oops at any time; or your system does not work as you expect. If you believe a bug in the Kernel source is responsible for an error, you may file a bug report to us via the link on our Developer s Wiki Page: Before filing a bug report, Digilent Inc. recommends that you do some debugging yourself to try and locate the problem. We encourage our users to file a bug-fix patch if you can locate and solve any problems with the software. This appendix section presents some easy ways to debug the kernel. Debugging Support in Kernel The kernel provides debugging support in its configuration settings that allow you to print out more detailed messages and information about bugs in the software. Debugging support is generally not enabled on deployment, because designers try to optimize the kernel for speed of execution, especially on embedded systems with limited computing resources. Table 1 presents a list of commonly used debugging support configurations that you should consider to enable during your development: Name Menu Location Description CONFIG_DEBUG_DRI VER CONFIG_DEBUG_DRV RES CONFIG_DEBUG_KER NEL CONFIG_DEBUG_BUG VERBOSE CONFIG_DEBUG_INF O CONFIG_EARLY_PRI NTK Device Driver -> Generic Driver Options Device Driver -> Generic Driver Options Kernel Hacking Kernel Hacking Kernel Hacking Kernel Hacking-> Kernel Low-level debugging functions Input a Y here if you want the Driver core to produce a bunch of debug messages to the system log. Choose this selection if you are having a problem with the driver core and want to see more of what is happening. This option enables kernel parameter devres.log. If set to non-zero, devres.log debug messages are printed. Select this if you are having a problem with devres.log or want to debug resource management for a managed device. Input Y here if you are developing drivers or trying to debug and identify kernel problems Input Y here to make BUG() panics output the file name and line number of the BUG() call as well as the EIP and Oops trace. If you type Y here the resulting kernel image will include debugging info resulting in a large kernel image. This adds debug symbols to the kernel and modules, and is needed if you intend to use kernel crashdump or binary object tools like crash, kgdb, LKCD, gdb etc on the kernel. Say Y here only if you plan to debug the kernel. Say Y here if you want to have an early console using kernel low-level debugging functions. Add earlyprintk to your kernel parameter to enable this console. Table 1. Common Debugging Support Configurations page 17 of 23
18 There are more options in the Kernel Hacking menu that you may choose to enable according to your needs. Debug by Printing Printing is always an easy and useful way to debug code. The kernel provides the printk function, which works like printf in traditional C libraries. (See Example 18) Example 18. printk(kern_debug Here I am: %s:%d\n, FUNCTION, LINE ); printk can work at 8 log levels defined in include/linux/printk.h and listed in Table 2. Log Level Name Meaning 0 KERN_EMERG when system is unusable, usually before a kernel crash 1 KERN_ALERT when action must be taken immediately 2 KERN_CRIT 3 KERN_ERR in critical conditions, often related to critical software or hardware failures in error conditions, often used in device drivers to report errors during startup. 4 KERN_WARNING in warning conditions 5 KERN_NOTICE in normal but significant conditions 6 KERN_INFO to print informational messages, often used by device drivers to report information during startup. 7 KERN_DEBUG to print debug-level messages Table 2. Log Level Definitions By default, any message other than KERN_DEBUG will be printed to console during booting. However, printk writes all the messages into a ring buffer with length of LOG_BUF_LEN. You can configure the size with CONFIG_LOG_BUF_SHIFT under General setup in the kernel configuration menu. You can also print all of the messages by running a dmesg command in the shell. Kernel Panic and Oops Messages When errors occur, the kernel reports either a Panic or an Oops Message on the terminal. When the kernel panics, the error is fatal and kernel will not recover from it. However, an Oops message will prompt the kernel to stop any offending processes and keep working. Even if the kernel still appears to be working correctly, it may have already caused some side-effects that could lead to future kernel panics. When the kernel detects a fatal error that it cannot recover from it will call a panic() function. The panic() function displays a message telling users why the panic occurred. After displaying the panic message the kernel then stops every CPU and dumps the stack of CPUs if CONFIG_DEBUG_BUGVERBOSE is selected. The panic message in example 19 shows that the root file page 18 of 23
Источник
