uboot & processo de inicialização do & iImage & linux

Question

Normalmente, em sistemas embarcados, o flash NAND é particionado em quatro partes: -

1. Uma partição para o bootloader (aqui vai o uboot.bin)
2. Uma pequena partição em que o uboot salva suas variáveis de ambiente
3. Uma partição para o kernel (aqui vai uImage.bin)
4. Uma partição para o rootfs

Agora tenho algumas perguntas do meu lado: -

1 > O MCU ARM de 32 bits possui várias interfaces de memória externa, como DRAM & NAND ou NOR flash conectado a ele.    Como o MCU ARM de 32 bits saberá de qual local de endereço no NAND buscar o Uboot?    E em qual endereço na RAM para carregar o Uboot?

2 > Em MCU de 8 bits, como o endereço do vetor AVR RESET é 0x0000 e está na memória FLASH interna.    Como o vetor RESET é especificado para o MCU ARM de 32 bits, pois possui vários tipos diferentes de interfaces de memória externa conectadas a ele.

3 > No caso do MCU ARM de 32 bits, primeiro o Uboot irá entrar na RAM, então ele carregará a imagem compactada na RAM, e então o uboot descompactará o uIMage para o LOADADDR.    Então, para definir LOADADDR (endereço de imagem descompactado) nós temos que levar em consideração o espaço para (uboot em si + uImage compactado ser carregado na RAM)?    Para a imagem como usamos para definir o LOADADDR?

4 > O linux uImage tem rootfs embutidos dentro dele ou é uma entidade separada?    Se rootfs é uma entidade secreta situada na NAND, então como o kernel virá a saber de qual endereço na NAND os rootfs estão mentindo?

    

Answer 1

1) normalmente haverá um deslocamento para cada interface inicializável definida no manual de referência. Por exemplo, você pode inicializar a partir da memória mapeada NOR, NAND, etc. O NOR pode ser 0x1000, NAND 0x4000 por exemplo. O capítulo do manual de referência sobre inicialização irá dizer-lhe.

2) veja 1

3) Muitas vezes, o uboot não pode simplesmente "entrar na RAM". Isso tem que ser feito com um bootloader de primeiro estágio. O U-boot tem o recurso SPL (loader de programa secundário) para fazer isso. O trabalho deste SPL é executado fora do SRAM do processador e para inicializar o DRAM do sistema, para que seja então possível carregar o executável completo do U-boot. U-boot então precisará do LOADADDR adequado para a placa / chip com que você está trabalhando. O U-boot não descompacta o kernel quando está inicializando. Este é tipicamente um trabalho do próprio kernel por razões legadas. Obviamente, seu kernel deve ser capaz de caber em sua memória, e você pode precisar ter certeza de que não está sobrescrevendo outros componentes (rootfs, árvore de dispositivos) quando o kernel se descompacta.

4) Qualquer uma das opções existe e é válida. Se o rootfs for separado, você precisará saber que tipo de sistema de arquivos é. Se for um initramfs, você pode definir onde ele está armazenado em NAND bruto. Se for um sistema de arquivos persistente (ext4), o U-boot precisa saber como processar o mapa de partição. Uma vez feito isso, você realmente passa o caminho do dispositivo, não um endereço para o kernel.