Here's my u-boot
## Booting kernel from Legacy Image at 42000000 ...
Image Name: Linux-4.1.8
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3458160 Bytes = 3.3 MiB
Load Address: 70008000
Entry Point: 70008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
And it stuck.
what's the difference between the 42000000 and the 70008000? Should the two be the same?
Booting kernel from Legacy Image at 42000000 ...
This first address is the one where u-boot will look for the (probably compressed) linux kernel image.
Load Address: 70008000
is the address where u-boot will copy the decompressed linux kernel image
Entry Point: 70008000 - linux kernel entry point address
Once the linux image has been decompressed and copied to the load address location, the entry point is the address where to start executing the kernel image, that in this case is exactly the start of the memory area where the kernel has been copied.
You can find further detail # below link:
http://lists.denx.de/pipermail/u-boot/2007-March/020043.html
https://balau82.wordpress.com/2010/04/12/booting-linux-with-u-boot-on-qemu-arm/
Related
I am writing a bootloader for my Arm board (32-bit i.MX6) and want to boot the Linux kernel using a device tree and an initrd file located at a static location in memory.
I looked to U-Boot as a reference and I see I can use the bootm command to provide a kernel, device tree and ramdisk:
Boot application image from memory:
bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg
...'; when booting a Linux kernel,‘arg' can be the address of an initrd image
I know there are two ways to pass information from a bootloader to the kernel, the legacy ATAGS method and the modern device tree method.
With ATAGS this can be achieved with the ATAG_INITRD2 tag which describes the address that a ramdisk is stored in memory. However, with a flattened device tree no ATAGS are passed to the kernel (which is shown in the boot log with the "No ATAGs?" message). I do not see any method to specify a ramdisk when using a device tree.
If I look at the documentation for booting the Linux kernel on Arm I see the following interface is specified:
- CPU register settings
r0 = 0,
r1 = machine type number discovered in (3) above.
r2 = physical address of tagged list in system RAM, or
physical address of device tree block (dtb) in system RAM
In fact, the same document states that an initramfs must be configured prior to booting, yet includes no details on how to do so when booting with a device tree.
Is there some alternative way to achieve this? Is the required information appended to the device tree automatically by U-Boot, or is there an alternative way to notify the kernel of the ramdisk location?
It will be patched in the dtree by the bootloader; e.g.
/ {
chosen {
linux,initrd-start = <0x....>;
linux,initrd-end = <0x....>;
};
I am dealing with android boot.img which is a combination of compressed kernel, ramdisk, and dtb. I see from the serial console log from uboot about the booting process and here's the part that triggers my curiosity
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
CPU: Temperature 27 C
Reset cause: POR
Board: MX6-SabreSD
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE100 ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In: serial
Out: serial
Err: serial
check_and_clean: reg 0, flag_set 0
Fastboot: Normal
flash target is MMC:1
Net: FEC [PRIME]
Normal Boot
Hit any key to stop autoboot: 3 2 1 0
boota mmc1
kernel # 14008000 (7272352)
ramdisk # 15000000 (869937)
fdt # 14f00000 (44072)
## Booting Android Image at 0x12000000 ...
Kernel load addr 0x14008000 size 7102 KiB
Kernel command line: console=ttymxc0,115200 init=/init video=mxcfb0:dev=hdmi,1920x1080M#60,bpp=32 video=mxcfb1:off video=mxcfb:off video=mxcfb3:off vmalloc=256M androidboot.console=ttymxc0 consolebalank=0 androidboot.hardware=freescale cma=384M
## Flattened Device Tree blob at 14f00000
Booting using the fdt blob at 0x14f00000
Loading Kernel Image ... OK
Using Device Tree in place at 14f00000, end 14f0dc27
switch to ldo_bypass mode!
Starting kernel ...
The kernel's address is 14008000, ramdisk 15000000, fdt 14f00000.
I have found out that these values are saved in the boot.img header and when I manually mess with this values, the image will not boot even though the actual contents are not modified.
Why is this address so critical? Why does it have to be these values? why not other values?
One of my own guess is:
these load address values are hardcoded inside the kernel so if I change it in the boot.img header it will cause side-effects. To elaborate my own theory, loading the kernel to the 'modified' load addr won't be a problem. But when actually executing the lines, it will cause severe problems because these codes are fixed to work with the proper 'load addr'.
Is my theory wrong? If so, I'd be grateful if you could correct me.
After the U-boot finished, it needs to handover the further execution to kernel so that kernel takes care for all further processes. Plus Kernel have some set of routines which are essential to initialize the board.
These set of routines have a entry point start_kernel(). Before this some other routines are also called to execute start_kernel. That can be identified by this linker script and this init.S.
To maintain execution in this procedure kernel need to be started from a particular address, moreover its data segments and other memories are also attached with that so to load and run all these in a proper manner, exact memory location need to be provided.
With this kernel needs the device tree blob for probing the devices attached to it and the rootfs to bring up the user space, here to load the device tree and rootfs exact offsets are needed so that any data should not be missed or corrupted. Every single byte is important for all these execution.
So to safely bootup all these values are being stored in bootloader's configuration.
I am trying to understand how a MLO is loaded into the on-chip of a SOC and do the minimal configuration. I am using TI DM8168 soc.
I have gone through the following link to understand the MLO or x-loader:
http://omappedia.org/wiki/Bootloader_Project
I got to know that the ROM Code loads the MLO (x-loader) to the on-chip RAM of the SoC which do the minimal configuration and finally loads the uboot (universal bootloader), that finally initiates the linux kernel.
My doubt here is that my on-chip RAM size is 64 KB and the MLO size is 116 KB, then how the ROM code is loading the MLO to the on-chip RAM
It seems that the DM8168 has more than 64KiB internal RAM: as explained in
the DM816x AM389x PSP 04.00.01.13 Feature Performance Guide, it has at least two more blocks of internal RAM, referenced OMC0 and OMC1, both being 256KiB in size.
Those two banks can be used by u-boot according to this document:
OCMC0 0x40300000 - 0x4033FFFF OCMC 0 will be used by ROM Code and U-boot. Once Linux kernel boots, OCMC0 is free and kernel can use it. If OCMC0 should not be used to load u-boot if loaded using CCS.
OCMC1 0x40400000 - 0x4043FFFF OCMC 1 will be used by ROM Code and U-boot. Once Linux kernel boots, OCMC0 is free and kernel can use it.
From u-boot-omap3/board/ti/ti8168/config.mk, it seems u-boot is using OMC1
TI_LOAD_ADDR = 0x40400000
This would explain why your 116KiB u-boot image can fit in the DM8168 internal RAM.
What is the role of ZTEXTADDR in Linux kernel ?
From lxr.linux.no, it's an address in RAM that holds address of zImage as sequence below?
A.
uImage (DataFlash/NAND) ---load_to_RAM--->
uImage (# boot_addr) ---decompress_uImage-->
zImage (# ZTEXTADDR) --- decompress_zImage--->
uncompressed image (# ZRELADDR).
or just:
B.
uImage (DataFlash/NAND) ---load_to_RAM--->
uImage (# boot_addr) ---decompress_uImage-->
uncompressed image (# ZRELADDR)
no using ZTEXTADDR in new kernel version for booting process ?
The Linux ARM decompression boot loader is capable of relocating itself when running from RAM. The relocation portion is PC-relative and so it can be loaded at any address. However, if your main image starts from FLASH/ROM, the code can not be relocated; while moving an image in RAM is a simple memmove(), it is much more involved for NOR flash and can be impossible for ROM.
In this case, a compressed boot linker script is used with the ZTEXTADDR as the location of the decompression code. In your diagram, you have a u-boot, which will load the uImage. There is no reason to execute this directly from Flash/ROM. u-boot can copy the image to RAM and there is no need for the ZTEXTADDR value and it should be left as zero.
If your image boots directly from Flash/ROM, without a boot loader then ZTEXTADDR is useful,
zImage (in flash) --> decompress vmlinux.bin to RAM --> run kernel
The zImage may need to be annotated with some chip setup for this to work and would need ATAGS or device trees linked. For this reason, there are many machine variants in boot/compressed; This is not maintainable and these type of files are discouraged. Typically another bootloader loads the image to RAM and the zImage can move itself to whatever destination it needs; I think that is your situation and you should set ZTEXTADDR to zero and forget about it.
I am working on Freescale board imx50evk. I have built the uboot.bin and uImage using LTIB (linux target image builder). At the U-Boot prompt I enter the bootm addr command, and then it hangs after showing the message "Loading Kernel..."
> MX50_RDP U-Boot > boot
MMC read: dev # 0, block # 2048, count 6290 partition # 0 ...
6290 blocks read: OK
## Booting kernel from Legacy Image at 70800000 ...
Image Name: Linux-2.6.35.8
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1323688 Bytes = 1.3 MB
Load Address: a0008000
Entry Point: a0008000
Verifying Checksum ... OK
Loading Kernel Image ...
You need to verify that your board really has RAM at 0xa0008000, which is the kernel "load address". U-Boot is probably trying to copy the image to that region of memory when it appears to hang.
[By your comment, I'll assume that you have verified that main memory does not exist at physical address 0xAXXXXXXX.]
The uImage file that you are using was made from the zImage file using the mkimage utility.
You probably have to manually edit the line that looks like
zreladdr-y := 0xa0008000
in arch/arm/mach-XXX/Makefile.boot for your board. The convention is that this address should be the base of physical RAM plus an offset of 0x8000 (32K). Then adjust the other values in the file. Delete the zImage file and perform another make for the kernel.
While building 3.20 development kernels for rockchip's rk3288 I found using LZO image compression made the device hang at 'Starting the kernel.' I assume it's because of a version miss-match between the build hosts LZO and the deployed decompression code, so it could probably happen with any of the compression algorithms. In my case switch to gzip fixed it.
This is only my assumption for why changing the compression algorithm gave a bootable kernel. Please correct me if I'm wrong.