Книга: Embedded Linux Primer: A Practical, Real-World Approach

Сноски из книги

· #1

 See Appendix A, "GNU Public License," for the complete text of the license.

· #2

Most 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.

· #3

If all the copyright holders agreed, the software could, in theory, be released under a new license, a very unlikely scenario indeed!

· #4

ATCA platforms are introduced in Chapter 3, "Processor Basics."

· #5

See www.compactflash.org.

· #6

Remember, 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.

· #7

Directly in the logical sense. The actual circuitry may contain bus buffers or bridge devices, etc.

· #8

We discuss ramdisk file systems in much detail in Chapter 9, "File Systems."

· #9

Real-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.

· #10

In this discussion, the word task is used to denote any thread of execution, regardless of the mechanism used to spawn, manage, or schedule it.

· #11

Many 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.

· #12

However, there is seldom a good reason to change it.

· #13

The term thread here is used in the generic sense to indicate any sequential flow of instructions.

· #14

In fact, it wouldn't even compile or link, much less run.

· #15

This package is important enough to warrant its own chapter. Chapter 11, "BusyBox," covers BusyBox in detail.

· #16

Linux has support for some basic processors that do not contain MMUs, but this is not considered a mainstream use of Linux.

· #17

32-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.

· #18

32-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.

· #19

These are the author's own opinions based on market observation and not based on any scientific data.

· #20

On the Freescale website, navigate to Media Center, Press Releases. This one was dated 10/31/2005 from Austin, Texas.

· #21

Source: www.mips.com/content/PressRoom/PressReleases/2003-12-22

· #22

Other 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.

· #23

Reported by ARM to be the top-selling toy during the Christmas 2005 shopping season in the United States.

· #24

VMEbus 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.

· #25

We talk about the kernel build system and makefiles shortly.

· #26

Throughout 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.

· #27

Executable and Linking Format, a de-facto standard format for binary executable files.

· #28

The linker script file has a peculiar syntax. The details can be found in the documentation for the GNU linker.

· #29

Not all these makefiles are directly involved in building the kernel. Some, for example, build documentation files.

· #30

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.

· #31

As mentioned, you can use the configuration editor of your choice, such as make xconfig or make menuconfig.

· #32

Better yet, make a backup copy of your .config file.

· #33

We have intentionally removed many options under ARM system type and Intel IXP4 xx Implementation Options to fit the picture on the page.

· #34

In 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.

· #35

Always assume that features advance faster than the corresponding documentation, so treat the docs as a guide rather than indisputable facts.

· #36

The 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."

· #37

The 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.

· #38

Not 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.

· #39

The term machine as used here refers to a specific hardware reference platform.

· #40

Often called Instruction Pointer, the register which holds the address of the next machine instruction in memory.

· #41

Modifying head.S for your custom platform is highly discouraged. There is almost always a better way. See Chapter 16, "Porting Linux," for additional information.

· #42

Modifying head.S for your custom platform is highly discouraged. There is almost always a better way. See Chapter 16, "Porting Linux," for additional information.

· #43

Normally, 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.

· #44

You 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.

· #45

Userland is an often-used term for any program, library, script, or anything else in user space.

· #46

Especially the sections on function attributes, type attributes, and variable attributes.

· #47

Often embedded systems do not have user accounts other than a single root user.

· #48

BusyBox commands are covered in Chapter 11.

· #49

Device nodes are explained in detail in Chapter 8.

· #50

In 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.

· #51

When busybox is invoked via the sh symbolic link, it spawns a shell. We cover this in detail in Chapter 11.

· #52

This inittab is a nice example of a small, purpose-built embedded system.

· #53

It just so happens that on this particular board, our physical SDRAM starts at 256MB.

· #54

Out 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.

· #55

do_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 .

· #56

Some 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.

· #57

The details differ, depending upon architecture, processor, and details of the hardware design.

· #58

This data was taken directly from the 405GP user's manual, referenced at the end of this chapter.

· #59

This 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.

· #60

In an acknowledgment of the number of bootloaders in existence, the YAMON user's guide bills itself as Yet Another MONitor.

· #61

The terms module and device driver are used here interchangeably.

· #62

This 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.

· #63

Hosting a target board and NFS root mount are covered in detail in Chapter 12, "Embedded Development Environment".

· #64

If 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".

· #66

Reference to this standard is found in the " Suggestions for Additional Reading," at the end of this chapter.

· #67

Actually, the open() call is a C library wrapper function around the Linux sys_open() system call.

· #68

This practice is not unique to open source. Copyright and patent infringement is an ongoing concern for all developers.

· #69

The 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.

· #70

File systems can be made mountable by nonroot users, as with cdrom.

· #71

A file on a file system is represented by an internal ext2 data structure called an inode.

· #72

Metadata 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.

· #73

Converting a file system in this manner should be considered a development activity only.

· #74

It 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.

· #75

The size was fixed in the kernel configuration when we enabled the MTD RAM test device in the Linux kernel configuration.

· #76

The 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.

· #77

We cover the details of symbolic links shortly.

· #78

We covered the details of System V initialization in Chapter 6.

· #79

Webster'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.

· #80

See SIG_KERNEL_COREDUMP_MASK in .../kernel/signal.c for a definition of which signals generate a core dump.

· #81

Signals and their associated numbers are defined in .../asm-<arch>/signal.h in your Linux kernel source tree.

· #82

Actually, support for the underlying engine that cbrowser uses is in the Linux build system.

· #83

See man ldconfig for details on creating a linker cache for your target system.

· #84

Sometimes an all-zeros address is appropriate in this context. However, we are investigating why the program bailed abnormally, so we should consider this suspect.

· #85

See man hosts for details of this system administration file.

· #86

The analysis utility is a Perl script supplied with the mTRace package.

· #87

A reference for the Dwarf2 Debug Information Specification is provided at the end of this chapter.

· #88

S-record files are an ASCII representation of a binary file, used by many device programmers and software binary utilities.

· #89

See 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.

· #90

Inline functions are like macros, but with the advantage of compile-time type checking.

· #91

Notwithstanding the comments made earlier about KGDB over Ethernet.

· #92

As 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."

· #93

Remember to use your cross-version of readelffor example, ppc_44x-readelf for the PowerPC 44x architecture.

· #94

A reference for the Dwarf debug specification appears at the end of this chapter in Section 14.6.1, "Suggestions for Additional Reading."

· #95

A helpful shortcut for macro development is the gdb source command. This command opens and reads a source file containing macro definitions.

· #96

The symbol _end is defined in the linker script file during the final link.

· #97

As 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.

· #98

An entry in the host system's /etc/hosts file enables the symbolic IP address reference.

· #99

All these filenames are unique, so they can be found without full pathname references.

· #100

Remember to use your cross-version of strip, for example ppc_82xx-strip.

· #101

It 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.

· #102

Of course, your compiler also needs to know the location of target files such as architecture-specific system and library header files.

· #103

We 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.

· #104

Refer back to Listing 14-5 in Chapter 14.

· #105

Refer back to Listing 14-5 in Chapter 13

· #106

By "homes," we mean a public source code repository, such as a web server on the Internet.

· #107

By convention, parameters in C are passed in these PowerPC registers.

· #108

The AMCC PPC405 is a perfect example of this. The interested reader is encouraged to examine the BAT registers in this processor.

· #109

Refer to the Programming Environments Manual referenced at the end of this chapter for details of the PowerPC DSI exception.

· #110

The initial ramdisk, or initrd, was introduced in Chapter 6.

· #111

We introduced the System.map file in Chapter 4.

· #112

For details of PPC assembly language syntax, see Section 16.5.1, "Suggestions for Additional Reading" at the end of this chapter.

· #113

Each 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.

· #114

To preserve space, we temporarily removed many machine types in Figure 16-4 prior to LITE5200.

· #115

We neglect the context switching time for interrupt processing because it is often negligible compared to interrupt off time.

· #116

Robert 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.

· #117

Interestingly, 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.

· #118

Also called HARDIRQs.

· #119

See Linux Kernel Development, referenced at the end of this chapter, to learn more about softirqs.

· #120

See www.rdrop.com/users/paulmck/RCU/ for an in-depth discussion of RCU.

· #121

We 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.

----

Оглавление книги


Генерация: 0.039. Запросов К БД/Cache: 0 / 0
поделиться
Вверх Вниз