Почему перемещение кода выполняется в U-boot собственно? - PullRequest
Новая
       79

Почему перемещение кода выполняется в U-boot собственно?

0 голосов
/ 18 мая 2018

Я пытаюсь понять процесс загрузки BeagleBone Black, просматривая исходный код.Предположим, что Iam хранит файлы MLO и u-boot.img на карте micro-SD и заставляет BeagleBone загружаться с SD-карты.

Насколько я понимаю, сначала выполняется код ПЗУ, и загружается файл MLO из MMC.во внутреннюю SRAM SOC.Файл MLO содержит код для x-loader, загрузчика программ второго этапа (SPL).SPL затем устанавливает DRAM и копирует загрузчик программ третьей ступени (собственно U-boot) в DRAM.Собственно U-boot непосредственно запускает свое выполнение из DRAM.

Архитектурно-зависимая часть собственно U-boot находится в каталоге arch / arm / исходных кодов U-boot.Код, относящийся к SPL, находится в каталоге spl /. (При выполнении make mrproper, за которым следует make SPL, * .o файлы создаются только в каталоге spl /)

Для правильной U-загрузки, я думаю, этоэто поток выполнения - arch / arm / cpu / armv7 / start.S находится в векторе сброса (поэтому он запускается первым), и после некоторой инициализации он вызывает процедуру _main, расположенную в arch / arm / lib / crt0.S.

В crt0.S вызывается board_init_f (), который устанавливает DRAM (и что-то еще), а затем возвращается туда, где он остановился (в main_).Позже он вызывает функцию relocate_code, которая снова перемещает ее в DRAM. 

ENTRY(_main)

/*
 * Set up initial C runtime environment and call board_init_f(0).
 */

#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
        ldr     r0, =(CONFIG_SPL_STACK)
#else
        ldr     r0, =(CONFIG_SYS_INIT_SP_ADDR)
#endif
        bic     r0, r0, #7      /* 8-byte alignment for ABI compliance */
        mov     sp, r0
        bl      board_init_f_alloc_reserve
        mov     sp, r0
        /* set up gd here, outside any C code */
        mov     r9, r0
        bl      board_init_f_init_reserve

        mov     r0, #0
        bl      board_init_f

#if ! defined(CONFIG_SPL_BUILD)

/*
 * Set up intermediate environment (new sp and gd) and call
 * relocate_code(addr_moni). Trick here is that we'll return
 * 'here' but relocated.
 */

        ldr     r0, [r9, #GD_START_ADDR_SP]     /* sp = gd->start_addr_sp */
        bic     r0, r0, #7      /* 8-byte alignment for ABI compliance */
        mov     sp, r0
        ldr     r9, [r9, #GD_BD]                /* r9 = gd->bd */
        sub     r9, r9, #GD_SIZE                /* new GD is below bd */

        adr     lr, here
        ldr     r0, [r9, #GD_RELOC_OFF]         /* r0 = gd->reloc_off */
        add     lr, lr, r0
#if defined(CONFIG_CPU_V7M)
        orr     lr, #1                          /* As required by Thumb-only */
#endif
        ldr     r0, [r9, #GD_RELOCADDR]         /* r0 = gd->relocaddr */
        b       relocate_code
here:

Почему для правильной U-загрузки необходимо снова настроить DRAM и переместить себя, если это уже было сделано SPL?Я что-то здесь упускаю?

1 Ответ

0 голосов
/ 18 мая 2018

Почему для правильной U-boot необходимо заново настроить DRAM и переместить себя, если это уже было сделано SPL?

Перемещение в верхнюю часть памяти позволяет максимизировать непрерывное свободное пространство.
Вы можете создать / связать и загрузить U-Boot по этому адресу высокой памяти (чтобы сохранить в копии),Но всякий раз, когда вы перестраиваете U-Boot с добавленными функциями и размер изображения увеличивается, этот адрес загрузки должен быть пересчитан.
Это также означает, что SPL должен быть изменен.

BTW «setup DRAM» обычно рассматривается как инициализация контроллера DRAM, чего на этом этапе не делается.
Помимо перемещения его кода, U-Boot также имеетдля перемещения стека и кучи, иначе среды выполнения C.

Я что-то здесь упускаю?

Удобнее загружать U-Boot в середине основногопамяти, а затем пусть U-Boot переместится в верхнюю память.

...