Addresses (0x0)
You've read a number of wiki and forum pages, you've seen the hex numbers ("0x....") and have figured out they are addresses. But, what do they mean?, Why were these addresses chosen?
(This entire discussion is about addresses in the nand Flash and RAM memory areas, not much about external devices on this page.)
The first thing to realize is that, in a command, sometimes an address is in Flash memory and sometimes it is in RAM memory. Even on the same command line, two addresses can be directed at the two memory areas.
Also, sometimes the hex numbers used in commands are addresses, and sometimes they are sizes.
With that in mind, here are some of the more common hex numbers which you might encounter. (With colored images, too.)
Contents |
nand Flash Memory use
0xa0000 (0.62 MB)
The high-address of the Flash block into which the U-Boot image is stored
commonly seen in the command:
- nand write.e 0x800000 0x0 0xa0000
Which is writing U-Boot into the Flash memory between the base (0x0) and 0xa0000, that is between 0.0 to 0.625 MB.
Of course, U-Boot also stores environmental variables. Also, the size of the U-Boot image might grown in future versions, so a little space is left after the image before the next item loaded into Flash.
0x100000 (1 MB)
The lower address of the Flash storage location for the kernel image.
(Also, see the next entry.)
0x400000 (4 MB)
The size of the partition used to contain the kernel image.
This and the previous address are commonly seen together in a command such as:
- nand read.e 0x800000 0x100000 0x400000
Which copies the kernel from Flash into RAM just before execution.
You might notice that 2.6.26 kernels are only around 3 MB in size. Just as with U-Boot, there is extra space reserved for future expansion.
Since the kernel images starts at 0x100000 and is 0x400000 in size, the next available memory will be at 0x100000 + 0x400000 = 0x500000. . .
0x500000 (5 MB)
The starting address of the root file system (rootfs) when in Flash.
Since the root file system is given the remainder of the Flash memory, it will have a size of
- 512 MB - 5 MB = 507 MB
Which gives us another hex number:
0x1fb00000 (507 MB)
The size of Flash memory given to the root file system, which is the remainer of the Flash memory after U-Boot and kernel allocations.
Flash Memory Map
RAM Memory use
0x800000 (8 MB)
This is the default RAM address into which the kernel image is loaded (on the SheevaPlug) for execution.
Why this number? Because 0x0 - 0x800000 are reserved for U-Boot. (Really, look at the messages U-Boot prints when starting, before the kernel is copied.)
I've tested loading the kernel into other RAM addresses, and there does not seem to be a problem. But, if the memory manager is trying to handle two block (one above and one below the kernel), there might be a minor amount of extra work required. Generally, I'd suggest loading the kernel at the low end (0x800000) and allowing all the remaining memory to be managed as a single block.
With that in mind, it is very common to also see this address used in the commands fatload, ext2load, or tftpboot as a safe place to load an image into RAM temporarily before writing it to Flash.
0x001100000 (17 MB)
This is an arbitrary address, which is commonly used to hold initrd (Initial Ram Disk) during new kernel/modules/file-system installation. This just happens to be easy to type and well out of the way of the uncompressed kernel, so there is no risk of initrd being over-written.
0x2000000 (32 MB)
Another arbitrary address, commonly used in tftpboot commands to load files into RAM from the TFTP server. Again, easy to type.
Some forum example use this as the location into which the kernel is loaded and then ran, this is probably not the best idea (see comment about 0x6400000 in the next section).
0x6400000 (100 MB)
This seems to be the location where the U-Boot is instructed to load the kernel for GuruPlugs. See the related note about address 0x800000 (above). There is at least one person (seen on the forums) who loads his GuruPlug kernel into 0x800000 without any problem. So, there does not seem to be any requirement to use 0x6400000, and loading into 0x800000 may very slightly reduce memory management.
Other addresses
Other addresses can be use to temporarily store files in RAM before writing to Flash, so long as they will not be over-written before being written or used. However, for larger files, it will be important to be sure the address is low enough to allow the file to fit into the remaining RAM. It is also important to not write below 0x800000, which would enter into the U-Boot reserved space.
RAM Memory Map with InitRD
RAM Memory Map in Normal Operation
"Storing" initrd and rootfs.tar.gz
Just to prevent any misunderstanding. For someone who has not installed a kernel or set up a machine before, he may ask the questions:
- What is the address where initrd should be stored in Flash?, and
- What is the address where rootfs.tar.gz should be stored in Flash", or After I uncompress rootfs.tar.gz, where should I store the filesystem in flash?
The answer is 'Do not do any of these things'.
When first bringing up the system (with no file system yet existing on the machine), the files rootfs.tar.gz (maybe root.tar.gz) and modules.tar.gz must be available from a source such as USB or TFTP server.
The kernel and initrd are both loaded into RAM. Then, the bootm command is used to run the kernel using initrd as the file system. This goes through a number of steps to install the system, including setting up the module dependencies (from modules.tar.gz) and also setting up the actual (not-RAM) file system. Once that process is finished, all subsequent boots should us the physical partitions and never use initrd again.
