2

I'm booting Linux on arm64 using FIT multi image (image + initrd + DTB). If I increase the initrd size (from 16 MB -> 20MB) the board hangs at "starting kernel"). However if I change the load address of bootm (from 0x2000000 to 0x1000000) it boots successfully. Any pointers on why this is booting at lower load address? What is the relationship between bootm multi image load address and final jump addresses of Image, initrd and FDT?

It seems when the FIT bin is loaded at 0x2000000 its over writing kernel or DTB. If I connect JTAG I can see that kernel is jumping to head.S but goes to undefined state.

  • Board config : 2 GB ram (0x00000000 - 0x8000000)
  • Init high enabled (so initrd is relocated to high mem)
  • FDT_high=0xffffffffffffffff so DTB is used in place.
  • FDT load adress is (0x9000000)

Console output:

## Current stack ends at 0x7f6cc6c0 *  kernel: cmdline image address = 0x02000000
## Loading kernel from FIT Image at 02000000 ... 
Using 'config@1' configuration 
Verifying Hash Integrity ... OK 
Trying 'kernel@0' kernel subimage 
 Description:  linux-mvl-4.4 
 Type:         Kernel Image 
 Compression:  uncompressed 
 Data Start:   0x020000bc 
 Data Size:    12473856 Bytes = 11.9 MiB 
 Architecture: AArch64 
 OS:           Linux 
 Load Address: 0x00080000 
 Entry Point:  0x00080000 
Verifying Hash Integrity ... OK 
kernel data at 0x020000bc, len = 0x00be5600 (12473856) 
*  ramdisk: using config 'config@1' from image at 0x02000000 
## Loading ramdisk from FIT Image at 02000000 ... 
Using 'config@1' configuration 
Trying 'ramdisk@0' ramdisk subimage 
 Description:  initramfs 
 Type:         RAMDisk Image 
 Compression:  lzma compressed 
 Data Start:   0x02be5764 
 Data Size:    22356891 Bytes = 21.3 MiB 
 Architecture: AArch64 
 OS:           Linux 
Can't get 'load' property from FIT 0x02000000, node: offset 12474104,    
name ramdisk@0 (FDT_ERR_NOTFOUND) 
 Load Address: unavailable 
Can't get 'entry' property from FIT 0x02000000, node: offset 12474104, name ramdisk@0 (FDT_ERR_NOTFOUND)
Entry Point:  unavailable 
Verifying Hash Integrity ... OK
Can't get 'load' property from FIT 0x02000000, node: offset 12474104, name 
ramdisk@0 (FDT_ERR_NOTFOUND) 
ramdisk start = 0x02be5764, ramdisk end = 0x04137aff 
*  fdt: using config 'config@1' from image at 0x02000000 
## Checking for 'FDT'/'FDT Image' at 02000000 
## Loading fdt from FIT Image at 02000000 ... 
Using 'config@1' configuration 
Trying 'fdt@1' fdt subimage 
  Description:  P1 fdt 
  Type:         Flat Device Tree 
  Compression:  uncompressed 
  Data Start:   0x0413eadc 
  Data Size:    28899 Bytes = 28.2 KiB 
  Architecture: AArch64 
 Verifying Hash Integrity ... OK 
 Loading fdt from 0x0413eadc to 0x09000000 
 Booting using the fdt blob at 0x9000000 
 of_flat_tree at 0x09000000 size 0x000070e3 
 Loading Kernel Image ... OK 
 kernel loaded at 0x00080000, end = 0x00c65600 
 ## initrd_high = 0x80000000, copy_to_ram = 1 
 Loading Ramdisk to 7e179000, end 7f6cb39b ... OK 
ramdisk load start = 0x7e179000, ramdisk load end = 0x7f6cb39b 
using: FDT 
## DT length 41187 
Using Device Tree in place at 0000000009000000, end 000000000900a0e2 
mci_find_sb_node.....no Device found 
DevID=100001f found on MCi bus 0 
DevID=1000021 found on MCi bus 1 
## Transferring control to Linux (at address 80000)... 

######## Starting kernel ...

Printenv:

baudrate=115200 
bl_ver=rxam-c1_V0.0.9.5
bootargs=console=ttyS0,115200 root=/dev/ram rw mtdparts=pxa3xx_nand-     0:1m(oops),1m(reserved),-(fs) ubi.mtd=fs
bootcmd=run bootcmd_nand
bootcmd_nand=nand read $fdt_addr 0x000000 0x100000&&nand read $loadaddr     0x100000 0x1200000&&setenv bootargs $console ubi.mtd=9,4096   root=ubi0:rootfs rootfstype=ubifs rw chk_data_crc rootdelay=2&&mochi reset&& mochi init&& mochi init armada70x0_1 &&booti $loadaddr - $fdt_addr
bootcmd_usb=setenv dtb_image armada-3900-axis_$fw_ver.dtb && set       kernel_image Image_$fw_ver && usb reset; ext2load usb 0:1 $loadaddr $kernel_image; ext2load usb 0:1 $fdt_addr $dtb_image; setenv bootargs $console root=/dev/sda1 rw rootdelay=2; mochi reset&& mochi init&& mochi init armada70x0_1&& booti $loadaddr - $fdt_addr
bootdelay=2
bootfile=/tftpboot/gpxelinux.0
boottftp=tftp 0x2000000 /tftpboot/part.bin && bootm 0x2000000
console=console=ttyS0,115200
eraseenv=env default -fa &&saveenv
ethact=mvpp2-0
ethprime=mvpp2-0
fdt_addr=0x1000000
fdt_high=0xffffffffffffffff
fdtcontroladdr=7f6ccca0 
fw_ver=rxam-c1_V0.0.9.5
gatewayip=10.4.50.254
hostname=Axel
ipaddr=192.168.1.1
kernel_addr=0x2000000
loadaddr=0x2000000
mtddevname=fs
mtddevnum=0
mtdids=nand0=pxa3xx_nand-0
mtdparts=mtdparts=pxa3xx_nand-0:1m(oops),1m(reserved),-(fs)
nad=setenv dtb_image armada-3900-axis_$fw_ver.dtb && tftpboot $fdt_addr  $dtb_image&&nand erase 0x000000 0x100000&&nand write $fdt_addr 0x000000 $filesize
naf=setenv fs_image rootfs_$fw_ver.ubi && tftpboot $loadaddr $fs_image  &&nand erase 0x1300000 0x1EB00000&&nand write $loadaddr 0x1300000 $filesize
nak=setenv kernel_image Image_$fw_ver && tftpboot $loadaddr $kernel_image &&nand erase 0x100000 0x1200000&&nand write $loadaddr 0x100000 $filesize
netmask=255.255.255.0
nob=setenv bl_image flash-image_$bl_ver.bin && tftpboot $loadaddr  $bl_image &&sf probe 0:0 && sf update $loadaddr 0 $filesize
partition=nand0,0
preboot=printenv bl_ver;printenv fw_ver
rootpath=/srv/nfs/
serverip=172.19.35.87
set_bootargs=setenv bootargs $console $root    ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none       nfsroot=$serverip:$rootpath $extra_params
stderr=serial@512000
stdin=serial@512000
stdout=serial@512000
tftpdir=/tftpboot/gumulla
upgradeall=run naf &&run nak &&run nad &&run nob&& reset

.its:

/*
 * U-boot FIT source file
 */

/dts-v1/;

/ {
        description = "platform-config";
        #address-cells = <1>;

        images {
                kernel@0 {
                        description = "linux-mvl-4.4";
                        data = /incbin/("Image");
                        type = "kernel";
                        arch = "arm64";
                        os = "linux";
                        compression = "none";
                        load = <0x80000>;
                        entry = <0x80000>;
                };

                ramdisk@0 {
                        description = "initramfs";
                        data = /incbin/("initramfs.lzma");
                        type = "ramdisk";
                        arch = "arm64";
                        os = "linux";
                        compression = "lzma";
                };

                /* P0 fdt */
                fdt@0 { 
                        description = "P0 fdt";
                        data = /incbin/("z1-sgmii-1g.dtb");
                        type = "flat_dt";
                        arch = "arm64";
                        compression = "none";
                        load = <0x9000001>;
                };

                /* P1 fdt */
                fdt@1 { 
                        description = "P1 fdt";
                        data = /incbin/("db-axis.dtb");
                        type = "flat_dt";
                        arch = "arm64";
                        compression = "none";
                        load = <0x9000000>;
                };
        };

        configurations {
                default = "config@0";

                /* P0 image */
                config@0 {
                        description = "P0 image";
                        kernel = "kernel@0";
                        ramdisk = "ramdisk@0";
                        fdt = "fdt@0";
                        hash@1 {
                                algo = "sha1";
                        };
                };

                /* P1 image */
                config@1 {
                        description = "P1 image";
                        kernel = "kernel@0";
                        fdt = "fdt@1";
                        ramdisk = "ramdisk@0";
                        hash@1 {
                                algo = "sha1";
                        };
                };
        };
};

New log after uboot relocation enabled:

## Current stack ends at 0x7f6cc6c0 *  kernel: cmdline image address = 0x02000000
## Loading kernel from FIT Image at 02000000 ...
Using 'config@1' configuration
Verifying Hash Integrity ... OK
Trying 'kernel@0' kernel subimage
  Description:  linux-mvl-4.4
  Type:         Kernel Image
  Compression:  uncompressed
  Data Start:   0x020000bc
  Data Size:    12473856 Bytes = 11.9 MiB
  Architecture: AArch64
  OS:           Linux
  Load Address: 0x00080000
  Entry Point:  0x00080000
Verifying Hash Integrity ... OK
kernel data at 0x020000bc, len = 0x00be5600 (12473856)
*  ramdisk: using config 'config@1' from image at 0x02000000
## Loading ramdisk from FIT Image at 02000000 ...
Using 'config@1' configuration
Trying 'ramdisk@0' ramdisk subimage
 Description:  initramfs
 Type:         RAMDisk Image
 Compression:  lzma compressed
 Data Start:   0x02be5764
 Data Size:    22365017 Bytes = 21.3 MiB
 Architecture: AArch64
 OS:           Linux
Can't get 'load' property from FIT 0x02000000, node: offset 12474104, name ramdisk@0 (FDT_ERR_NOTFOUND)
 Load Address: unavailable
Can't get 'entry' property from FIT 0x02000000, node: offset 12474104, name ramdisk@0 (FDT_ERR_NOTFOUND)
 Entry Point:  unavailable
 Verifying Hash Integrity ... OK
Can't get 'load' property from FIT 0x02000000, node: offset 12474104, name ramdisk@0 (FDT_ERR_NOTFOUND)
ramdisk start = 0x02be5764, ramdisk end = 0x04139abd
*  fdt: using config 'config@1' from image at 0x02000000
## Checking for 'FDT'/'FDT Image' at 02000000
## Loading fdt from FIT Image at 02000000 ...
Using 'config@1' configuration
Trying 'fdt@1' fdt subimage
 Description:  P1 fdt
 Type:         Flat Device Tree
 Compression:  uncompressed
 Data Start:   0x04140a8c
 Data Size:    28899 Bytes = 28.2 KiB
 Architecture: AArch64
Verifying Hash Integrity ... OK
Loading fdt from 0x04140a8c to 0x09000000
Booting using the fdt blob at 0x9000000
of_flat_tree at 0x09000000 size 0x000070e3
Loading Kernel Image ... OK
kernel loaded at 0x00080000, end = 0x00c65600
## initrd_high = 0x80000000, copy_to_ram = 1
Loading Ramdisk to 7e177000, end 7f6cb359 ... OK
ramdisk load start = 0x7e177000, ramdisk load end = 0x7f6cb359
using: FDT
## DT length 41187
## device tree at 0000000009000000 ... 00000000090070e2 (len=41187 [0xA0E3])
Loading Device Tree to 000000007e16c000, end 000000007e1760e2 ... OK
mci_find_sb_node.....no Device found
DevID=100001f found on MCi bus 0
DevID=1000021 found on MCi bus 1
## Transferring control to Linux (at address 80000)...

######## Starting kernel ...

## Transferring control to Linux Done!
Improve this question
1

3 Answers 3

Reset to default
2

So, as the OP commented, moving the load address fixes the problem. What this highlights is the danger of using fdt_high (or in other cases, initrd_high) to stop U-Boot from relocating contents. In cases like FIT images where U-Boot has a good idea of how large each of the pieces are you generally want to use bootm_size to tell U-Boot how much of memory (from the start of the first bank) to use when relocating contents for OS boot. In this specific case where you want the initrd to be in high memory then you need to use a specific value for fdt_high that is within the space the kernel will see (which varies from architecture and kernel version in some cases, please refer to the OS docs, eg linux/Documentation/arm64/booting.txt).

Improve this answer
4
  • Thanks for the clarification. So, after I enabled U-Boot relocation (by unsetting fdt_high) and assigned boot_size = 2GB( entire ram) and made sure fdt_high set appropriately to match (linux/Documentation/arm64/booting.tx). bootm still doesn't seem to like the load address 0x200000. Also noticed the initrd_start and end seems to calculated based on load address. Does the load address to bootm has any alignment or padding requirements? Commented May 2, 2018 at 1:10
  • Can you please provide the log for this case? Thanks. Commented May 2, 2018 at 22:31
  • Apologies for the long comment! Added the log. linux/Documentation/arm64/booting.txt document states that Linux V > 4.2 supports FDT and initrd placed anywhere in 32GB physical memory window as long as FDT is 8 byte aligned and initrd is 1GB aligned. Though highly doubtful but is it possible that increase in initrd size is causing U-Boot to over write any env or DTB or kernel section when FIT image is loaded at this particular address (0x2000000) ? Commented May 3, 2018 at 0:05
  • Also kernel doesn't boot no matter what fdt_high is set to. Commented May 3, 2018 at 0:10
0

Turns out, when the image size is increased its accessing reserved area of the the ARM psi. Every time image size is increased somehow I have to make sure this address is not touched during the boot.

Improve this answer
-1

You must to recalculate the entry and load property values in the its for the kernel and the fdt nodes according to the available DRAM size, the kernel size and the clobstart chosen to load the itb.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.