想修改kernel和ramdisk的地址，有一点疑问？

LYOO

kernel和ramdisk在FLASH中的存储地址以及在SDRAM中加载地址是由bootloader指定的还是由kernel自身指定的？

gotop2004

kernel由bootload決定,ramdisk由kernel決定

martin7wind

bootloader决定了kernel的位置,至于ramdisk,区别于不同的系统,并且事实上在具体系统中ramdisk不只一个,是由烧录过程中人为指定的,决定于系统的需求和内存大小,并不由kernel决定.

LYOO

谢谢楼上的热心回复，让我清楚了一些。
从目前查阅的资料来看(基于u-boot和armlinux)，u-boot通过bootm命令来启内核，bootm接受两个参数，它们分别是kernel镜像和ramdisk镜像的存储地址，即两者在FLASH中的烧写地址，接着u-boot将它们加载到SDRAM中，然后kernel镜像会解压，控制权转到kernel，内核也就启动起来了。现在我不清楚的是：
1.将FLASH中的kernel和ramdisk镜像加载到SDRAM中的地址是怎样确定的？
2.kernel镜像被加载到SDRAM中后，须在SDRAM中再分配一段空间，然后将自身解压到该地址，这个地址又是如何确定的？

mingming

Despite the ability to place zImage anywhere within memory, convention has it that it is loaded at the base of physical RAM plus an offset of 0x8000 (32K). This leaves space for the parameter block usually placed at offset 0x100, zero page exception vectors and page tables. This convention is very common.

mingming

5. Loading the kernel image
Kernel images generated by the kernel build process are either uncompressed "Image" files or compressed zImage files.

The uncompressed Image files are generally not used, as they do not contain a readily identifiable magic number. The compressed zImage format is almost universally used in preference.

The zImage has several benefits in addition to the magic number. Typically, the decompression of the image is faster than reading from some external media. The integrity of the image can be assured, as any errors will result in a failed decompress. The kernel has knowledge of its internal structure and state, which allows for better results than a generic external compression method.

The zImage has a magic number and some useful information near its beginning.

Table 2. Useful fields in zImage head code

Offset into zImage Value Description
0x24 0x016F2818 Magic number used to identify this is an ARM Linux zImage
0x28 start address The address the zImage starts at
0x2C end address The address the zImage ends at


The start and end offsets can be used to determine the length of the compressed image (size = end - start). This is used by several bootloaders to determine if any data is appended to the kernel image. This data is typically used for an initial RAM disk (initrd). The start address is usually 0 as the zImage code is position independent.

The zImage code is Position Independent Code (PIC) so may be loaded anywhere within the available address space. The maximum kernel size after decompression is 4Megabytes. This is a hard limit and would include the initrd if a bootpImage target was used.

Note
Although the zImage may be located anywhere, care should be taken. Starting a compressed kernel requires additional memory for the image to be uncompressed into. This space has certain constraints.

The zImage decompression code will ensure it is not going to overwrite the compressed data. If the kernel detects such a conflict it will uncompress the image immediately after the compressed zImage data and relocate the kernel after decompression. This obviously has the impact that the memory region the zImage is loaded into must have up to 4Megabytes of space after it (the maximum uncompressed kernel size), i.e. placing the zImage in the same 4Megabyte bank as its ZRELADDR would probably not work as expected.

Despite the ability to place zImage anywhere within memory, convention has it that it is loaded at the base of physical RAM plus an offset of 0x8000 (32K). This leaves space for the parameter block usually placed at offset 0x100, zero page exception vectors and page tables. This convention is very common.

6. Loading an initial RAM disk
An initial RAM disk is a common requirement on many systems. It provides a way to have a root filesystem available without access to other drivers or configurations. Full details can be obtained from linux/Documentation/initrd.txt

There are two methods available on ARM Linux to obtain an initial RAM disk. The first is a special build target bootpImage which takes an initial RAM disk at build time and appends it to a zImage. This method has the benefit that it needs no bootloader intervention, but requires the kernel build process to have knowledge of the physical address to place the ramdisk (using the INITRD_PHYS definition). The hard size limit for the uncompressed kernel and initrd of 4Megabytes applies. Because of these limitations this target is rarely used in practice.

The second and much more widely used method is for the bootloader to place a given initial ramdisk image, obtained from whatever media, into memory at a set location. This location is passed to the kernel using ATAG_INITRD2 and ATAG_RAMDISK.

Conventionally the initrd is placed 8Megabytes from the base of physical memory. Wherever it is placed there must be sufficient memory after boot to decompress the initial ramdisk into a real ramdisk i.e. enough memory for zImage + decompressed zImage + initrd + uncompressed ramdisk. The compressed initial ramdisk memory will be freed after the decompression has happened. Limitations to the position of the ramdisk are:

It must lie completely within a single memory region (must not cross between areas defined by different ATAG_MEM parameters)
It must be aligned to a page boundary (typically 4k)
It must not conflict with the memory the zImage head code uses to decompress the kernel or it will be overwritten as no checking is performed.

mingming

去armlinux网站找找，在arch/arm/boot下看看源代码，不知道对你有没有帮助

LYOO

不错，正是我想要的，看来得去armlinux潜潜水。

hello398

you need to change it in bootloader part. For the u-boot, there is command line for the address of kernel and ramdisk. After you change it, save the env. variables to flash.