Книга: Embedded Linux Primer: A Practical, Real-World Approach
Сноски из книги
· #1See Appendix A, "GNU Public License," for the complete text of the license.
· #2Most professional development managers agree: You can download Linux without charge, but there is a cost (often a substantial one) for development and deployment of any OS on an embedded platform. See Section 1.3.1, "Free Versus Freedom," for a discussion of cost elements.
· #3If all the copyright holders agreed, the software could, in theory, be released under a new license, a very unlikely scenario indeed!
· #4ATCA platforms are introduced in Chapter 3, "Processor Basics."
· #5See www.compactflash.org.
· #6Remember, you can change a 1 to a 0 a byte at a time, but you must erase the entire block to change any bit from a 0 back to a 1.
· #7Directly in the logical sense. The actual circuitry may contain bus buffers or bridge devices, etc.
· #8We discuss ramdisk file systems in much detail in Chapter 9, "File Systems."
· #9Real-time clock modules often contain small amounts of nonvolatile storage, and Serial EEPROMs are another common choice for nonvolatile storage of small amounts of data.
· #10In this discussion, the word task is used to denote any thread of execution, regardless of the mechanism used to spawn, manage, or schedule it.
· #11Many good books cover the details of virtual memory systems. See Section 2.5.1, "Suggestions for Additional Reading," at the end of this chapter, for recommendations.
· #12However, there is seldom a good reason to change it.
· #13The term thread here is used in the generic sense to indicate any sequential flow of instructions.
· #14In fact, it wouldn't even compile or link, much less run.
· #15This package is important enough to warrant its own chapter. Chapter 11, "BusyBox," covers BusyBox in detail.
· #16Linux has support for some basic processors that do not contain MMUs, but this is not considered a mainstream use of Linux.
· #1732-bit and 64-bit refer to the native width of the processor's main facilities, such as its execution units, register file and address bus.
· #1832-bit and 64-bit refer to the native width of the processor's main facilities, such as its execution units, register file and address bus.
· #19These are the author's own opinions based on market observation and not based on any scientific data.
· #20On the Freescale website, navigate to Media Center, Press Releases. This one was dated 10/31/2005 from Austin, Texas.
· #21Source: www.mips.com/content/PressRoom/PressReleases/2003-12-22
· #22Other peripherals include IrDA controller, LCD controller, 2 SPCs, Power management, DMA engine, RTC, Camera interface, LCD controller, h/w hardware acceleration of encryption/decryption, PCI host controller, 4 SPCs, and Security engine.
· #23Reported by ARM to be the top-selling toy during the Christmas 2005 shopping season in the United States.
· #24VMEbus isn't really a hardware reference platform, per se, but based on Eurocard physical standards, the level of compatibility among multiple vendors qualifies it for the label.
· #25We talk about the kernel build system and makefiles shortly.
· #26Throughout this book, three dots preceding any path are used to indicate whatever path it might take on your system to reach the top-level Linux source tree.
· #27Executable and Linking Format, a de-facto standard format for binary executable files.
· #28The linker script file has a peculiar syntax. The details can be found in the documentation for the GNU linker.
· #29Not all these makefiles are directly involved in building the kernel. Some, for example, build documentation files.
Incremental linking is a technique used to generate an object module that is intended to be linked again into another object. In this way, unresolved symbols that remain after incremental linking do not generate errorsthey are resolved at the next link stage.
· #31As mentioned, you can use the configuration editor of your choice, such as make xconfig or make menuconfig.
· #32Better yet, make a backup copy of your .config file.
· #33We have intentionally removed many options under ARM system type and Intel IXP4 xx Implementation Options to fit the picture on the page.
· #34In actuality, the kernel build system is very complicated, but most of the complexity is cleverly hidden from the average developer. As a result, it is relatively easy to add, modify, or delete configurations without having to be an expert.
· #35Always assume that features advance faster than the corresponding documentation, so treat the docs as a guide rather than indisputable facts.
· #36The kernel image is nearly always stored in compressed format, unless boot time is a critical issue. In this case, the image might be called uImage, a compressed vmlinux file with a U-Boot header. See Chapter 7,"Bootloaders."
· #37The term piggy was originally used to describe a "piggy-back" concept. In this case, the binary kernel image is piggy-backed onto the bootstrap loader to produce the composite kernel image.
· #38Not to be confused with the bootloader, a bootstrap loader can be considered a second-stage loader, where the bootloader itself can be thought of as a first-stage loader.
· #39The term machine as used here refers to a specific hardware reference platform.
· #40Often called Instruction Pointer, the register which holds the address of the next machine instruction in memory.
· #41Modifying head.S for your custom platform is highly discouraged. There is almost always a better way. See Chapter 16, "Porting Linux," for additional information.
· #42Modifying head.S for your custom platform is highly discouraged. There is almost always a better way. See Chapter 16, "Porting Linux," for additional information.
· #43Normally, the compiler will complain if a variable is defined static and never referenced in the compilation unit. Because these variables are not explicitly referenced, the warning would be emitted without this directive.
· #44You might have to lower the default loglevel on your system to see these debug messages. This is described in many references about Linux system administration. In any case, you should see them in the kernel log file.
· #45Userland is an often-used term for any program, library, script, or anything else in user space.
· #46Especially the sections on function attributes, type attributes, and variable attributes.
· #47Often embedded systems do not have user accounts other than a single root user.
· #48BusyBox commands are covered in Chapter 11.
· #49Device nodes are explained in detail in Chapter 8.
· #50In actuality, modern Linux kernels create a userspace-like environment earlier in the boot sequence for specialized activities, which are beyond the scope of this book.
· #51When busybox is invoked via the sh symbolic link, it spawns a shell. We cover this in detail in Chapter 11.
· #52This inittab is a nice example of a small, purpose-built embedded system.
· #53It just so happens that on this particular board, our physical SDRAM starts at 256MB.
· #54Out of necessity (space), this is a very simplified description of the sequence of events. The actual mechanism is similar in concept, but several significant details are omitted for clarity. You are encouraged to consult the kernel source code for more details. See .../init/main.c and .../init/do_mounts*.c.
· #55do_basic_setup is called from .../init/main.c and calls do_initcalls(). This causes driver module initialization routines to be called. This was described in detail in Chapter 5 and shown in Listing 5-10 .
· #56Some embedded designs protect the bootloader and provide callbacks to bootloader routines, but this is almost never a good design approach. Linux is far more capable than bootloaders, so there is often little point in doing so.
· #57The details differ, depending upon architecture, processor, and details of the hardware design.
· #58This data was taken directly from the 405GP user's manual, referenced at the end of this chapter.
· #59This is mostly for historical reasons. From the early days of PCs, BIOS programs loaded only the first sector of a disk drive and passed control to it.
· #60In an acknowledgment of the number of bootloaders in existence, the YAMON user's guide bills itself as Yet Another MONitor.
· #61The terms module and device driver are used here interchangeably.
· #62This path is used by Red Hat and Fedora distributions, and is also required by the File System Hierarchy Standard referenced at the end of this chapter. Other distributions might use different locations in the file system for kernel modules.
· #63Hosting a target board and NFS root mount are covered in detail in Chapter 12, "Embedded Development Environment".
· #64If you don't see the messages on the console, either disable your syslogd logger or lower the console loglevel. We describe how to do this in Chapter 14, "Kernel Debugging Techniques".
· #65/proc/modules is part of the proc file system, which is introduced in Chapter 9, "File Systems".
· #66Reference to this standard is found in the " Suggestions for Additional Reading," at the end of this chapter.
· #67Actually, the open() call is a C library wrapper function around the Linux sys_open() system call.
· #68This practice is not unique to open source. Copyright and patent infringement is an ongoing concern for all developers.
· #69The term cylinder was borrowed from the unit of storage on a rotational media. It consists of the data under a group of heads on a given sector of a disk device. Here it is used for compatibility purposes with the existing file system utilities.
· #70File systems can be made mountable by nonroot users, as with cdrom.
· #71A file on a file system is represented by an internal ext2 data structure called an inode.
· #72Metadata is data about the file, as opposed to the file's data itself. Examples include a file's date, time, size, blocks used, and so on.
· #73Converting a file system in this manner should be considered a development activity only.
· #74It is certainly possible to mount /proc anywhere you like on your file system, but all the utilities (including mount) that require proc expect to find it mounted on /proc.
· #75The size was fixed in the kernel configuration when we enabled the MTD RAM test device in the Linux kernel configuration.
· #76The kernel can be configured to operate with a wrong-endian MTD file system, at the cost of reduced performance. In some configurations (such as multiprocessor designs), this can be a useful feature.
· #77We cover the details of symbolic links shortly.
· #78We covered the details of System V initialization in Chapter 6.
· #79Webster's defines nonsense as "an idea that is absurd or contrary to good sense." It is my opinion that developing embedded Linux platforms on a non-Linux/UNIX host is nonsensical.
· #80See SIG_KERNEL_COREDUMP_MASK in .../kernel/signal.c for a definition of which signals generate a core dump.
· #81Signals and their associated numbers are defined in .../asm-<arch>/signal.h in your Linux kernel source tree.
· #82Actually, support for the underlying engine that cbrowser uses is in the Linux build system.
· #83See man ldconfig for details on creating a linker cache for your target system.
· #84Sometimes an all-zeros address is appropriate in this context. However, we are investigating why the program bailed abnormally, so we should consider this suspect.
· #85See man hosts for details of this system administration file.
· #86The analysis utility is a Perl script supplied with the mTRace package.
· #87A reference for the Dwarf2 Debug Information Specification is provided at the end of this chapter.
S-record files are an ASCII representation of a binary file, used by many device programmers and software binary utilities.
· #89See the GCC manual referenced at the end of this chapter in Section 14.6.1, "Suggestions for Additional Reading" for details on the optimization levels.
· #90Inline functions are like macros, but with the advantage of compile-time type checking.
· #91Notwithstanding the comments made earlier about KGDB over Ethernet.
· #92As pointed out earlier, the gdb remote protocol is detailed in the gdb manual cited at the end of this chapter in Section 14.6.1, "Suggestions for Additional Reading."
· #93Remember to use your cross-version of readelffor example, ppc_44x-readelf for the PowerPC 44x architecture.
· #94A reference for the Dwarf debug specification appears at the end of this chapter in Section 14.6.1, "Suggestions for Additional Reading."
· #95A helpful shortcut for macro development is the gdb source command. This command opens and reads a source file containing macro definitions.
· #96The symbol _end is defined in the linker script file during the final link.
· #97As of this writing, there is a bug in gdb that prevents this technique from working properly. Hopefully, by the time you read this, it will be fixed.
· #98An entry in the host system's /etc/hosts file enables the symbolic IP address reference.
· #99All these filenames are unique, so they can be found without full pathname references.
· #100Remember to use your cross-version of strip, for example ppc_82xx-strip.
· #101It is certainly possible to pass these locations to your compiler, linker, and debugger for every invocation, but any good embedded Linux distribution will configure these defaults into the toolchain as a convenience to the developer.
· #102Of course, your compiler also needs to know the location of target files such as architecture-specific system and library header files.
· #103We will use the term system call, but fork() in this context is actually the C library function which in turn calls the Linux sys_fork() system call.
· #104Refer back to Listing 14-5 in Chapter 14.
· #105Refer back to Listing 14-5 in Chapter 13
· #106By "homes," we mean a public source code repository, such as a web server on the Internet.
· #107By convention, parameters in C are passed in these PowerPC registers.
· #108The AMCC PPC405 is a perfect example of this. The interested reader is encouraged to examine the BAT registers in this processor.
· #109Refer to the Programming Environments Manual referenced at the end of this chapter for details of the PowerPC DSI exception.
· #110The initial ramdisk, or initrd, was introduced in Chapter 6.
· #111We introduced the System.map file in Chapter 4.
· #112For details of PPC assembly language syntax, see Section 16.5.1, "Suggestions for Additional Reading" at the end of this chapter.
· #113Each method has its own roots. The struct bd_info originated in U-Boot, and struct bi_record was an attempt to unify across all platforms. Both are supported by many platforms.
· #114To preserve space, we temporarily removed many machine types in Figure 16-4 prior to LITE5200.
· #115We neglect the context switching time for interrupt processing because it is often negligible compared to interrupt off time.
· #116Robert Love explains bottom-half processing in great detail in his book Linux Kernel Development. See Section 17.5.1, "Suggestions for Additional Reading," at the end of this chapter for the reference.
· #117Interestingly, there is much debate on the correct spelling of preemptable! I defer to the survey done by Rick Lehrbaum on www.linuxdevices.com/articles/AT5136316996.html.
· #118Also called HARDIRQs.
· #119See Linux Kernel Development, referenced at the end of this chapter, to learn more about softirqs.
· #120See www.rdrop.com/users/paulmck/RCU/ for an in-depth discussion of RCU.
· #121We refer you again to Robert Love's book for an excellent discussion of the O(1) scheduler, and a delightful diatribe on algorithmic complexity, from which the notation O(1) derives.
- Prentice Hall Open Source Software Development Series
- Foreword
- Preface
- Acknowledgments
- About the Author
- Chapter 1. Introduction
- Chapter 2. Your First Embedded Experience
- Chapter 3. Processor Basics
- Chapter 4. The Linux KernelA Different Perspective
- Chapter 5. Kernel Initialization
- Chapter 6. System Initialization
- Chapter 7. Bootloaders
- Chapter 8. Device Driver Basics
- Chapter 9. File Systems
- Chapter 10. MTD Subsystem
- Chapter 11. BusyBox
- Chapter 12. Embedded Development Environment
- Chapter 13. Development Tools
- Chapter 14. Kernel Debugging Techniques
- Chapter 15. Debugging Embedded Linux Applications
- Chapter 16. Porting Linux
- Chapter 17. Linux and Real Time
- Appendix A. GNU Public License
- Appendix B. U-Boot Configurable Commands
- Appendix C. BusyBox Commands
- Appendix D. SDRAM Interface Considerations
- Appendix E. Open Source Resources
- Сноски из книги
- Содержание книги
- Популярные страницы