Obtendo o U-Boot para carregar o dtb da imagem FIT

3

Estou trabalhando para configurar o U-Boot para inicializar apenas o kernel Linux verificado a partir de uma imagem FIT Kernel + fdt. (Tudo é construído sob Yocto). O bin do U-Boot tem uma árvore de dispositivos básica anexada a ele que é inicializada usando, mas a imagem do FIT tem a árvore completa para o kernel.

Eu tenho tudo praticamente funcionando, exceto que quando o kernel é inicializado, o U-Boot está ignorando a árvore de dispositivos na imagem FIT e passando sua própria - baseada no valor de fdtaddr (== 0x11000000):

Hit any key to stop autoboot:  0
reading uImage
3346230 bytes read in 100 ms (31.9 MiB/s)
## Loading kernel from FIT Image at 18000000 ...
No configuration specified, trying default...
Found default configuration: 'conf@1'
   Using 'conf@1' configuration
   Verifying Hash Integrity ... sha1,rsa2048:dev+ OK
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x180000e8
     Data Size:    3304016 Bytes = 3.2 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x10008000
     Entry Point:  0x10008000
     Hash node:    'hash@1'
     Hash algo:    sha1
     Hash value:   ff0333f01a894f81d716605f7c7995d651ff8111
     Hash len:     20
   Verifying Hash Integrity ... sha1+ OK
*  fdt: cmdline image address = 0x11000000
## Checking for 'FDT'/'FDT Image' at 11000000
Wrong FIT format: no description
*  fdt: raw FDT blob
## Flattened Device Tree blob at 11000000
   Booting using the fdt blob at 0x11000000
   of_flat_tree at 0x11000000 size 0x0000505a
   Loading Kernel Image ... OK
## device tree at 11000000 ... 11005059 (len=32858 [0x805A])
   Loading Device Tree to 2f72e000, end 2f736059 ... OK

[NB my U-Boot possui alguns módulos específicos da placa - do fabricante da placa - que podem estar alterando o comportamento padrão do U-Boot]

Eu posso conseguir uma operação correta, se depois que a imagem for carregada, eu "setenv fdtaddr $ {loadaddr}" (== 0x18000000) - então o U-Boot faz encontrar a árvore de dispositivos no FIT imagem e passa isso:

Hit any key to stop autoboot:  0
reading uImage
3346230 bytes read in 101 ms (31.6 MiB/s)
## Loading kernel from FIT Image at 18000000 ...
No configuration specified, trying default...
Found default configuration: 'conf@1'
   Using 'conf@1' configuration
   Verifying Hash Integrity ... sha1,rsa2048:dev+ OK
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x180000e8
     Data Size:    3304016 Bytes = 3.2 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x10008000
     Entry Point:  0x10008000
     Hash node:    'hash@1'
     Hash algo:    sha1
     Hash value:   ff0333f01a894f81d716605f7c7995d651ff8111
     Hash len:     20
   Verifying Hash Integrity ... sha1+ OK
*  fdt: cmdline image address = 0x18000000
## Checking for 'FDT'/'FDT Image' at 18000000
## Loading fdt from FIT Image at 18000000 ...
No configuration specified, trying default...
Found default configuration: 'conf@1'
   Using 'conf@1' configuration
   Trying 'fdt@1' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x18326c2c
     Data Size:    38269 Bytes = 37.4 KiB
     Architecture: ARM
     Hash node:    'hash@1'
     Hash algo:    sha1
     Hash value:   79d5eeb892ef059566c04d98cdc6b30e92a665a2
     Hash len:     20
   Verifying Hash Integrity ... sha1+ OK
Can't get 'load' property from FIT 0x18000000, node: offset 3304372, name fdt@1 (FDT_ERR_NOTFOUND)
   Booting using the fdt blob at 0x18326c2c
   of_flat_tree at 0x18326c2c size 0x0000957d
   Loading Kernel Image ... OK
## device tree at 18326c2c ... 183301a8 (len=50557 [0xC57D])
   Loading Device Tree to 2f72a000, end 2f73657c ... OK

Isso é bom (eu posso adicionar o comando acima para 'default_bootargs'), mas eu me perguntei se eu estou perdendo algum truque 'correto' para obter o mesmo comportamento - eu meio que assumi que se você carregasse uma imagem FIT então -Boot carregaria naturalmente não apenas o kernel, mas também a árvore de dispositivos. (Eu ainda não consegui entender as opções no comando bootm ...)

Obrigado

[Editar:]

/dts-v1/;

/ {
        description = "U-Boot fitImage for MyBoard/4.4/tx6";
        #address-cells = <1>;

        images {
                kernel@1 {
                        description = "Linux kernel";
                        data = /incbin/("linux.bin");
                        type = "kernel";
                        arch = "arm";
                        os = "linux";
                        compression = "none";
                        load = <0x10008000>;
                        entry = <0x10008000>;
                        hash@1 {
                                algo = "sha1";
                        };
                };
                fdt@1 {
                        description = "Flattened Device Tree blob";
                        data = /incbin/("arch/arm/boot/dts/tx6.dtb");
                        type = "flat_dt";
                        arch = "arm";
                        compression = "none";
                        hash@1 {
                                algo = "sha1";
                        };
                };
    };

        configurations {
                default = "conf@1";
                conf@1 {
                        description = "Linux kernel, FDT blob";
            kernel = "kernel@1";
            fdt = "fdt@1";


                        hash@1 {
                                algo = "sha1";
                        };
                        signature@1 {
                                algo = "sha1,rsa2048";
                                key-name-hint = "dev-example";
                sign-images = "kernel", "fdt";
                        };
                };
    };
};

[Editar:]

autoload=no
autostart=no
baseboard=stk5-v3
baudrate=115200
boot_mode=mmc
bootargs_jffs2=run default_bootargs;setenv bootargs ${bootargs} root=/dev/mtdblock3 rootfstype=jffs2
bootargs_mmc=run default_bootargs;setenv bootargs ${bootargs} root=PARTUUID=${rootpart_uuid} rootwait
bootargs_nfs=run default_bootargs;setenv bootargs ${bootargs} root=/dev/nfs nfsroot=${nfs_server}:${nfsroot},nolock ip=dhcp
bootargs_sdcard=run default_bootargs;setenv bootargs ${bootargs} root=/dev/mmcblk0p2 rootwait
bootargs_ubifs=run default_bootargs;setenv bootargs ${bootargs} ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs
bootcmd=run bootcmd_${boot_mode} bootm_cmd
bootcmd_jffs2=setenv autostart no;run bootargs_jffs2;nboot linux
bootcmd_mmc=setenv autostart no;run bootargs_mmc;fatload mmc 0 ${loadaddr} ${bootfile}
bootcmd_net=setenv autoload y;setenv autostart n;run bootargs_nfs;dhcp
bootcmd_sdcard=setenv autostart no;run bootargs_sdcard;fatload mmc 1:1 ${loadaddr} ${bootfile}
bootdelay=1
bootfile=uImage
bootm_cmd=bootm ${loadaddr} - ${fdtaddr}
cpu_clk=792
default_bootargs=setenv bootargs init=/sbin/init console=ttymxc0,115200 ro debug panic=1 ${append_bootargs}; setenv fdtaddr ${loadaddr}
emmc_boot_ack=1
emmc_boot_part=1
ethact=FEC
ethaddr=00:01:02:7f:e5:50
fdtaddr=11000000
fdtsave=mmc partconf 0 ${emmc_boot_ack} ${emmc_boot_part} ${emmc_boot_part};mmc write ${fdtaddr} 0x680 80;mmc partconf 0 ${emmc_boot_ack} ${emmc_boot_part} 0
fdtsize=505a
loadaddr=18000000
nfsroot=/tftpboot/rootfs
otg_mode=device
rootpart_uuid=0cc66cc0-02
splashimage=18000000
stderr=serial
stdin=serial
stdout=serial
touchpanel=edt-ft5x06
ver=U-Boot 2015.10-rc2 (Aug 11 2017 - 18:57:06 +0100)
video_mode=VGA
    
por ColH 11.08.2017 / 16:02

2 respostas

2

A resposta para este problema exato vem da compreensão de que o U-Boot tenta ser extremamente flexível e isso pode levar a algumas confusões às vezes. Olhando para o ambiente fornecido, podemos ver que temos o bootcmd (que é executado quando o atraso de inicialização se esgota) se resume a:

bootm ${loadaddr} - ${fdtaddr}

E isso significa que analisamos $ {loadaddr} para nossa imagem, não para um disco em memória e $ {fdtaddr} para a árvore de dispositivos a ser usada. No caso de um uImage de estilo legado, isso faz sentido, pois o ramdisk e a árvore de dispositivos não estão (provavelmente) contidos no arquivo. No entanto, uma imagem FIT inclui tudo isso e oferece muitos recursos úteis adicionais (que o cartaz deseja usar). O que acontece é que depois de escolher a árvore de dispositivos incluída na imagem FIT, o U-Boot então analisa o restante dos argumentos e olha para $ {fdtaddr} para a árvore de dispositivos usar. Se bootm_cmd foi definido como simplesmente:

bootm ${loadaddr}

em vez disso, funcionaria como esperado.

    
por 14.08.2017 / 22:59
3

adicione carga no nó fdt

fdt@1 {
    description = "Flattened Device Tree blob";
    data = /incbin/("arch/arm/boot/dts/tx6.dtb");
    type = "flat_dt";
    arch = "arm";
    load = <0x18000000>
    compression = "none";
    hash@1 {
        algo = "sha1";
    };
};
    
por 16.08.2017 / 08:22

Tags