**Резюме:**

В этом каталоге находится исходный код U-Boot, загрузчика для встраиваемых плат на базе PowerPC, ARM, MIPS и некоторых других процессоров. U-Boot можно установить в загрузочное ПЗУ и использовать для инициализации и тестирования оборудования или загрузки и запуска прикладного кода.

Разработка U-Boot тесно связана с Linux: некоторые части исходного кода происходят из дерева исходных текстов Linux, у нас есть общие заголовочные файлы, и были приняты специальные меры для поддержки загрузки образов Linux.

Некоторое внимание было уделено тому, чтобы сделать это программное обеспечение легко настраиваемым и расширяемым. Например, все команды монитора реализованы с одним и тем же интерфейсом вызова, так что очень легко добавлять новые команды. Кроме того, вместо постоянного добавления редко используемого кода (например, утилит тестирования оборудования) в монитор, вы можете загружать и запускать его динамически.

**Статус:**

Как правило, все платы, для которых существует файл конфигурации по умолчанию в каталоге configs/, были протестированы до некоторой степени и могут считаться «работающими». Фактически, многие из них используются в производственных системах.

В случае возникновения проблем вы можете использовать

    scripts/get_maintainer.pl <путь>

чтобы определить людей или компании, ответственных за различные платы и подсистемы. Или посмотрите журнал git.

**Где получить помощь:**

Если у вас есть вопросы, проблемы или предложения по U-Boot, отправьте сообщение в список рассылки U-Boot по адресу <u-boot@lists.denx.de>. Также существует архив предыдущего трафика списка рассылки — пожалуйста, поищите в архиве, прежде чем задавать часто задаваемые вопросы. Пожалуйста, смотрите https://lists.denx.de/pipermail/u-boot и https://marc.info/?l=u-boot.

**Где взять исходный код:**

Исходный код U-Boot поддерживается в репозитории Git по адресу https://source.denx.de/u-boot/u-boot.git; вы можете просмотреть его онлайн по адресу https://source.denx.de/u-boot/u-boot. Ссылки «Теги» на этой странице позволяют вам загрузить архивы tar любой версии, которая может вас заинтересовать. Официальные выпуски также доступны с файлового сервера DENX через HTTPS или FTP. https://ftp.denx.de/pub/u-boot/, ftp://ftp.denx.de/pub/u-boot/.

**Откуда мы пришли:**

— начать с источников 8xxrom;
— создать проект PPCBoot (https://sourceforge.net/projects/ppcboot);
— очистить код;
— упростить добавление пользовательских плат;
— сделать возможным добавление других процессоров [PowerPC];
— расширить функции, особенно:
  * предоставить расширенный интерфейс для загрузчика Linux;
  * загрузка S-Record;
  * сетевая загрузка;
  * ATA диск / SCSI... загрузка;
— создать проект ARMBoot (https://sourceforge.net/projects/armboot);
— добавить другие семейства процессоров (начиная с ARM);
— создать проект U-Boot (https://sourceforge.net/projects/u-boot);
— текущая страница проекта: см. https://www.denx.de/wiki/U-Boot.

**Названия и написание:**

«Официальное» название этого проекта — «Das U-Boot». Написание «U-Boot» должно использоваться во всех письменных текстах (документация, комментарии в исходных файлах и т. д.). Пример:

Это файл README для проекта U-Boot.

Имена файлов и т.д. должны быть основаны на строке «u-boot». Примеры:

include/asm-ppc/u-boot.h

#include <asm/u-boot.h>

Переменные имена, константы препроцессора и т.д. должны основываться либо на строке «u_boot», либо на «U_BOOT». Пример:

U_BOOT_VERSION      u_boot_logo
IH_OS_U_BOOT        u_boot_hush_start

**Конфигурация программного обеспечения:**

Выбор архитектуры процессора и типа платы:
---------------------------------------------------

Для всех поддерживаемых плат имеются готовые к использованию конфигурации по умолчанию; просто введите «make <board_name>_defconfig».

Пример: Для модуля TQM823L введите:

cd u-boot
make TQM823L_defconfig

Примечание: Если вы ищете файл конфигурации по умолчанию для платы, которую вы привыкли использовать, но которой сейчас нет, проверьте файл doc/README.scrapyard на наличие списка более не поддерживаемых плат. **U-Boot может быть собран изначально для запуска на хосте Linux с использованием платы «песочницы»**. Это позволяет разрабатывать функции, которые не зависят от конкретной платы или архитектуры, на родной платформе. Песочница также используется для запуска некоторых тестов U-Boot.

Подробнее см. в doc/arch/sandbox/sandbox.rst.

**Последовательность инициализации платы:**

Это предполагаемый поток запуска для плат. Он должен применяться как для SPL, так и для самого U-Boot (то есть они оба следуют одним и тем же правилам).

Примечание: «SPL» означает «Secondary Program Loader», что объясняется более подробно далее в этом файле.

В настоящее время SPL в основном использует отдельный путь кода, но названия функций и роли каждой функции одинаковы. Некоторые платы или архитектуры могут не соответствовать этому. По крайней мере, большинство ARM-плат, использующих CONFIG_SPL_FRAMEWORK, соответствуют этому.

Выполнение обычно начинается с файла start.S, специфичного для архитектуры (и, возможно, для процессора):
* arch/arm/cpu/armv7/start.S;
* arch/powerpc/cpu/mpc83xx/start.S; 
* arch/mips/cpu/start.S и т. д.
Оттуда вызываются три функции; цель и ограничения каждой из этих функций описаны ниже.

lowlevel_init():
* цель: основная инициализация, чтобы позволить выполнению достичь board_init_f();
* нет global_data или BSS;
* стека нет (ARMv7 может иметь его, но он скоро будет удалён);
* не должен настраивать SDRAM или использовать консоль;
* должен делать только самое необходимое, чтобы выполнение могло перейти к board_init_f().
* эта функция почти никогда не требуется;
* нормально вернуться из этой функции.

board_init_f():
* цель: настроить машину, готовую к запуску board_init_r(), то есть SDRAM и последовательный UART;
* доступна global_data;
* стек находится в SRAM;
* BSS недоступен, поэтому нельзя использовать глобальные/статические переменные, только переменные стека и global_data.

Примечания, не относящиеся к SPL:
* вызывается dram_init() для настройки DRAM. Если это уже сделано в SPL, это ничего не даст.

Примечания для SPL:
* можно переопределить всю функцию board_init_f() своей собственной версией по мере необходимости;
* preloader_console_init() можно вызвать здесь в крайнем случае;
* следует настроить SDRAM, и всё, что необходимо для работы UART;
* нет необходимости очищать BSS, это сделает crt0.S;
* для определённых сценариев на некоторых архитектурах ранний BSS *может* быть доступен (через CONFIG_SPL_EARLY_BSS путём перемещения очистки BSS до входа в board_init_f()), но делать это не рекомендуется. Вместо этого настоятельно рекомендуется спроектировать любые изменения или дополнения кода таким образом, чтобы они не зависели от доступности BSS во время board_init_f(), как указано в других разделах этого README, чтобы поддерживать совместимость и согласованность во всей кодовой базе.
* должно нормально возвращаться из этой функции (не вызывать board_init_r() напрямую).

Здесь очищается BSS. Для SPL, если определено CONFIG_SPL_STACK_R, то в этот момент стек и global_data перемещаются ниже CONFIG_SPL_STACK_R_ADDR. Для не-SPL U-Boot перемещается для запуска в верхней части памяти.

board_init_r():
* цель: основное выполнение, общий код;
* доступна global_data;
* SDRAM доступна;
* доступен BSS, все статические/глобальные переменные могут использоваться;
* выполнение в конечном итоге переходит к main_loop().

Примечания, не относящиеся к SPL:
* U-Boot перемещён в верхнюю часть памяти и теперь работает оттуда.

Примечания для SPL:
* стек опционально находится в SDRAM, если определены CONFIG_SPL_STACK_R и CONFIG_SYS_FSL_HAS_CCI400.
Определено для SoC с кэш-когерентным межсоединением CCN-400

CONFIG_SYS_FSL_HAS_CN504
Определено для SoC с кэш-когерентным межсоединением CN-504.

Необходимо настроить следующие параметры:
* Тип ЦП: определить ровно один, например, CONFIG_MPC85XX.
* Тип платы: определить ровно одну, например, CONFIG_MPC8540ADS.
* Опции 85xx CPU:
    * CONFIG_SYS_PPC64 — указывает, что ядро является 64-битным PowerPC. Реализация соответствует категории «64» стандарта Power ISA. Это необходимо для соответствия требованиям ePAPR, помимо прочих возможных причин.

CONFIG_SYS_FSL_ERRATUM_A004510

Включает обходной путь для решения проблемы A004510. Если он установлен, то также должны быть установлены CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV и CFG_SYS_FSL_CORENET_SNOOPVEC_COREONLY.

CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV
CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV2 (необязательно)

Определяет одну или две версии SoC (младшие 8 бит SVR), для которых следует применять обходной путь A004510.

Остальная часть SVR либо не имеет отношения к решению о наличии ошибки (например, p2040 против p2041), либо подразумевается целью сборки, которая управляет установкой CONFIG_SYS_FSL_ERRATUM_A004510.

Дополнительную информацию об этой ошибке см. в примечании Freescale App Note 4493.

CFG_SYS_FSL_CORENET_SNOOPVEC_COREONLY

Это значение, которое нужно записать в CCSR со смещением 0x18600 в соответствии с обходным путём A004510.

CONFIG_SYS_FSL_SINGLE_SOURCE_CLK

Single Source Clock — это режим тактирования, присутствующий в некоторых SoC FSL. В этом режиме используется один дифференциальный тактовый сигнал для подачи тактовых импульсов на sysclock, ddrclock и usbclock.

**Общие параметры CPU:**

CONFIG_SYS_FSL_DDR

Используется драйвер Freescale DDR. Этот тип контроллера DDR встречается в mpc83xx, mpc85xx, а также в некоторых ядрах ARM SoC.

CFG_SYS_FSL_DDR_ADDR

Базовый адрес памяти Freescale DDR, отображаемый в памяти.

CONFIG_SYS_FSL_IFC_CLK_DIV

Определяет делитель тактовой частоты системной платы (тактовый вход в контроллер IFC).

CONFIG_SYS_FSL_LBC_CLK_DIV

Определяет делитель тактовой частоты системной платы (тактовый вход в eLBC-контроллер).

CFG_SYS_FSL_DDR_SDRAM_BASE_PHY

Физический адрес с точки зрения контроллеров DDR. Он такой же, как CFG_SYS_DDR_SDRAM_BASE для всех SoC Power. Но он может отличаться для SoC ARM.

**Параметры ARM:**

CFG_SYS_EXCEPTION_VECTORS_HIGH

Выбирает высокие векторы исключений ядра ARM, например не очищает бит V регистра c1 CP15.

COUNTER_FREQUENCY

Общая частота источника тактового сигнала таймера.

COUNTER_FREQUENCY_REAL

Частота источника тактового сигнала таймера в реальном времени, если она отличается от COUNTER_FREQUENCY, и её можно определить только во время выполнения.

**Интерфейс ядра Linux:**

CONFIG_OF_LIBFDT

Новые версии ядра ожидают, что настройки встроенного ПО будут переданы с использованием уплощённых деревьев устройств (на основе концепций открытой прошивки).

CONFIG_OF_LIBFDT * Новая поддержка на основе libfdt
* Добавляет команду «fdt»
* Команда bootm автоматически обновляет fdt

OF_TBCLK — базовая частота.

Платы с двигателями QUICC требуют OF_QE для установки MAC-адресов UCC.

CONFIG_OF_IDE_FIXUP

U-Boot может определить, присутствует ли устройство IDE или нет. Если нет и активирована эта новая опция конфигурации, U-Boot удаляет узел ATA из DTS перед загрузкой Linux, поэтому драйвер Linux IDE не проверяет устройство и не даёт сбой. Это необходимо для проблемного оборудования (uc101), где к сигналу IDE5V_DD7 не подключён подтягивающий резистор.

**Параметры загрузки vxWorks:**

bootvx создаёт действительную строку загрузки, используя следующие переменные среды: bootdev, bootfile, ipaddr, netmask, serverip, gatewayip, hostname, othbootargs. Загружает образ vxWorks, указанный в bootfile.

Примечание: если определена среда «bootargs», она переопределит значения по умолчанию, описанные выше.

**Конфигурация кэша для ARM:**

CFG_SYS_PL310_BASE — физический базовый адрес пространства регистров контроллера PL310.

**Последовательные порты:**

CFG_PL011_CLOCK

Если у вас есть UART Amba PrimeCell PL011, установите эту переменную на тактовую частоту UART.

CFG_PL01x_PORTS

Если у вас есть Amba PrimeCell PL010 или... **PL011 UARTs на вашей плате**

Определите это как список базовых адресов для каждого (поддерживаемого) порта. См., например, include/configs/versatile.h.

CONFIG_SERIAL_HW_FLOW_CONTROL

Определите эту переменную, чтобы включить аппаратное управление потоком в последовательном драйвере. Текущим пользователем этой опции является драйвер drivers/serial/nsl16550.c.

**Удаление команд**

Если команды не нужны для загрузки, вы можете отключить CONFIG_CMDLINE, чтобы удалить их. В этом случае командная строка будет недоступна, и когда U-Boot захочет выполнить команду загрузки (при запуске), он вызовет board_run_command() вместо этого. Это может значительно уменьшить размер образа для очень простых процедур загрузки.

**Поддержка регулярных выражений:**

CONFIG_REGEX

Если эта переменная определена, U-Boot связан с библиотекой SLRE (Super Light Regular Expression), которая добавляет поддержку регулярных выражений к некоторым командам, таким как «env grep» и «setexpr».

**Сторожевой таймер:**

CFG_SYS_WATCHDOG_FREQ

Некоторые платформы автоматически вызывают WATCHDOG_RESET() из обработчика прерываний таймера каждые CFG_SYS_WATCHDOG_FREQ прерывания. Если он не установлен файлом конфигурации платы, по умолчанию используется CONFIG_SYS_HZ/2 (т. е. 500). Установка CFG_SYS_WATCHDOG_FREQ на 0 отключает вызов WATCHDOG_RESET() от обработчика прерывания таймера.

**GPIO-поддержка:**

Опция CFG_SYS_I2C_PCA953X_WIDTH определяет список пар чип-ngpio, которые сообщают драйверу PCA953X количество контактов, поддерживаемых конкретным чипом.

Обратите внимание, что если устройство GPIO использует I2C, то интерфейс I2C также должен быть настроен. Смотрите раздел Поддержка I2C ниже.

**Трассировка ввода-вывода:**

Когда выбрана CONFIG_IO_TRACE, U-Boot перехватывает все обращения к вводу-выводу и может проверять их контрольную сумму или записывать их список в память. Подробности см. в команде iotrace. Это полезно для тестирования драйверов устройств, поскольку может подтвердить, что драйвер ведёт себя одинаково до и после изменения кода. В настоящее время это поддерживается на sandbox и arm. Чтобы добавить поддержку для вашей архитектуры, добавьте «#include <iotrace.h>» в конец arch/<arch>/include/asm/io.h и test.

Пример вывода команды iotrace stats приведён ниже. Обратите внимание, что даже если буфер трассировки исчерпан, контрольная сумма всё равно будет продолжать работать.

iotrace включён
Начало:  10000000    (начальный адрес буфера)
Размер:   00010000    (размер буфера)
Смещение: 00000120    (текущее смещение буфера)
Вывод:   10000120    (начало + смещение)
Счётчик:  00000018    (количество записей трассировки)
CRC32:   9526fb66    (CRC32 всех записей трассировки)

**Временные метки:**

При выборе CONFIG_TIMESTAMP временная метка (дата и время) образа печатается командами образа, такими как bootm или iminfo. Эта опция автоматически включается при выборе CONFIG_CMD_DATE.

**Поддержка меток разделов (disklabels):**

Нуль или более из следующих:

CONFIG_MAC_PARTITION  Таблица разделов Apple MacOS.
CONFIG_ISO_PARTITION   Таблица разделов ISO, используемая на CDROM и т. д.
CONFIG_EFI_PARTITION     Таблица разделов GPT, обычно используется, когда EFI является загрузчиком. Обратите внимание на ограничение раздела 2 ТБ; см. disk/part_efi.c
CONFIG_SCSI) вы должны настроить поддержку хотя бы одного типа раздела, отличного от MTD.

**Сетевая поддержка (PCI):**

CONFIG_E1000_SPI

Вспомогательный код для прямого доступа к шине SPI на Intel 8257x. Это не делает ничего полезного, если вы не установите хотя бы один из CONFIG_CMD_E1000 или CONFIG_E1000_SPI_GENERIC.

CONFIG_NATSEMI

Поддержка чипов National dp83815.

CONFIG_NS8382X

Поддержка гигабитных чипов National dp8382[01].

**Сетевая поддержка (другое):**

CONFIG_CALXEDA_XGMAC

Поддержка устройства Calxeda XGMAC.

CONFIG_LAN91C96

Поддержка. **Для чипов LAN91C96 в локальной сети SMSC**

CONFIG_LAN91C96_USE_32_BIT
Включите 32-битную адресацию.

CFG_SYS_DAVINCI_EMAC_PHY_COUNT
Определите, если у вас больше одного PHY.

CONFIG_FTGMAC100
Поддержка гигабитного SoC Ethernet от Faraday FTGMAC100.

CONFIG_FTGMAC100_EGIGA
Используйте обновление GE-соединения с гигабитным PHY. Определите, если FTGMAC100 подключён к гигабитному PHY. Если ваша система имеет только 10/100 PHY, неправильное поведение может не возникнуть. Обычно PHY возвращает тайм-аут или бесполезные данные при опросе статуса и регистров управления гигабитной связью. Это поведение не повлияет на корректность обновления скорости соединения 10/100.

CONFIG_SH_ETHER
Поддержка встроенного Ethernet-контроллера Renesas.

CFG_SH_ETHER_USE_PORT
Определите количество используемых портов.

CFG_SH_ETHER_PHY_ADDR
Определите адрес ETH PHY.

CFG_SH_ETHER_CACHE_WRITEBACK
Если эта опция установлена, драйвер включает очистку кэша.

**Поддержка TPM:**

CONFIG_TPM
Поддержка устройств TPM.

CONFIG_TPM_TIS_INFINEON
Поддержка Infineon i2c bus TPM устройств. В настоящее время поддерживается только одно устройство на систему.

CONFIG_TPM_TIS_I2C_BURST_LIMITATION
Определите верхний предел количества байтов для пакетной передачи.

CONFIG_TPM_ST33ZP24
Поддержка STMicroelectronics TPM устройств. Требуется поддержка DM_TPM.

CONFIG_TPM_ST33ZP24_I2C
Поддержка STMicroelectronics ST33ZP24 I2C устройств. Требуются CONFIG_TPM_ST33ZP24 и I2C.

CONFIG_TPM_ST33ZP24_SPI
Поддержка STMicroelectronics ST33ZP24 SPI устройств. Требуются CONFIG_TPM_ST33ZP24 и SPI.

CONFIG_TPM_ATMEL_TWI
Поддержка Atmel TWI TPM устройства. Требуется поддержка I2C.

CONFIG_TPM_TIS_LPC
Поддержка универсальных параллельных TPM устройств. В настоящее время поддерживается только одно устройство на систему.

CONFIG_TPM
Включите библиотеку поддержки TPM, которая предоставляет функциональные интерфейсы для некоторых команд TPM. Требуется поддержка TPM-устройства.

CONFIG_TPM_AUTH_SESSIONS
Включите авторизованные функции в библиотеке TPM. Требуются CONFIG_TPM и CONFIG_SHA1.

**USB-поддержка:**

В настоящее время поддерживается только хост-контроллер UHCI (PIP405, MIP405). Включите CONFIG_USB_UHCI. Включите USB-клавиатуру с помощью CONFIG_USB_KEYBOARD и USB-накопители с помощью CONFIG_USB_STORAGE. Поддерживаются USB-клавиатуры и USB-флоппи-диски (TEAC FD-05PUB).

CONFIG_USB_DWC2_REG_ADDR — физический адрес регистров HW-модуля DWC2.

**Устройства USB:**

Определите ниже, если вы хотите использовать USB-консоль. После перестроения прошивки из последовательной консоли выполните команду «setenv stdin usbtty; setenv stdout usbtty» и подключите USB-кабель. Команда Unix «dmesg» должна показать, что найдено новое устройство. Переменную среды usbtty можно установить на gserial или cdc_acm, чтобы ваше устройство отображалось на USB-хосте как Linux gserial устройство или последовательное устройство Common Device Class Abstract Control Model. Если вы выберете usbtty = gserial, вы сможете перечислить хост Linux с помощью # modprobe usbserial vendor=0xVendorID product=0xProductID. В противном случае, используя cdc_acm, достаточно просто установить переменную среды usbtty на cdc_acm. Следующее может быть определено в YourBoardName.h.

Если у вас есть назначенный USB-IF VendorID, вы можете определить свои собственные значения производителя, продукта, VendorID и ProductID в BoardName.h или непосредственно в usbd_vendor_info.h. Если вы не определите CONFIG_USBD_MANUFACTURER, CONFIG_USBD_PRODUCT_NAME, CONFIG_USBD_VENDORID и CONFIG_USBD_PRODUCTID, то... **U-Boot**

Должен притворяться устройством Linux для целевого хоста.

* **CONFIG_USBD_MANUFACTURER** — определите эту строку как название вашей компании:
    * - CONFIG_USBD_MANUFACTURER «my company».

* **CONFIG_USBD_PRODUCT_NAME** — определите эту строку как наименование вашего продукта:
     * - CONFIG_USBD_PRODUCT_NAME «acme usb device».

* **CONFIG_USBD_VENDORID** — определите это как назначенный вам Vendor ID от USB Implementors Forum. Это должен быть подлинный Vendor ID, чтобы не засорять пространство имён USB.
    * - CONFIG_USBD_VENDORID 0xFFFF.

* **CONFIG_USBD_PRODUCTID** — определите это в качестве уникального Product ID для вашего устройства:
    * - CONFIG_USBD_PRODUCTID 0xFFFF.

**Поддержка слоя ULPI**:

Слой ULPI (UTMI Low Pin (count) Interface) PHYs поддерживается через общий слой ULPI. Общий слой получает доступ к ULPI PHY через окно просмотра платформы, поэтому вам нужны и общий слой, и окно просмотра с поддержкой. В настоящее время поддерживается только окно Chipidea/ARC.
Чтобы включить поддержку слоя ULPI, определите CONFIG_USB_ULPI и CONFIG_USB_ULPI_VIEWPORT в файле конфигурации вашей платы. Если вашему ULPI phy требуется другая опорная тактовая частота, чем стандартная 24 МГц, вы должны определить CFG_ULPI_REF_CLK в соответствующее значение в Гц.

**Поддержка MMC**:

CONFIG_SH_MMCIF — поддержка встроенного контроллера MMCIF Renesas.

* CONFIG_SH_MMCIF_ADDR — определение базового адреса регистров MMCIF.
* CONFIG_SH_MMCIF_CLK — определение тактовой частоты для MMCIF.

**Поддержка класса USB Device Firmware Update (DFU)**:

CONFIG_DFU_OVER_USB — включает USB-часть класса DFU USB.

CONFIG_DFU_NAND — включает поддержку для предоставления доступа к устройствам NAND через DFU.

CONFIG_DFU_RAM — включает поддержку для предоставления RAM через DFU. Примечание: спецификация DFU относится к использованию энергонезависимой памяти, но допускает использование вне области спецификации — здесь использование RAM, которое в основном поможет разработчику.

CONFIG_SYS_DFU_DATA_BUF_SIZE — передача Dfu использует буфер перед записью данных на необработанное запоминающее устройство. Сделайте размер (в байтах) этого буфера настраиваемым. Размер этого буфера также можно настроить с помощью переменной среды «dfu_bufsiz».

CONFIG_SYS_DFU_MAX_FILE_SIZE — при обновлении файлов, а не необработанного запоминающего устройства, мы используем статический буфер для копирования файла и затем записываем буфер после того, как нам был предоставлен весь файл. Определите это как максимальный размер файла (в байтах) для буфера. По умолчанию — 4 МиБ, если не определено.

DFU_DEFAULT_POLL_TIMEOUT — тайм-аут опроса [мс], это тайм-аут, который устройство может отправить хосту. Хост должен подождать этот тайм-аут перед отправкой последующего запроса DFU_GET_STATUS устройству.

DFU_MANIFEST_POLL_TIMEOUT — тайм-аут опроса [мс], который устройство отправляет хосту при входе в состояние dfuMANIFEST. Хост ждёт этот тайм-аут, прежде чем снова отправить запрос USB на устройство.

**Поддержка клавиатуры**:

См. справку Kconfig для доступных драйверов клавиатуры.

**Поддержка MII/PHY**:

CONFIG_PHY_CLOCK_FREQ (ppc4xx) — тактовая частота шины MII.

CONFIG_PHY_CMD_DELAY (ppc4xx) — некоторым PHY, таким как Intel LXT971A, требуется дополнительная задержка после выдачи команды перед чтением регистра состояния MII.

**Режим восстановления BOOTP**:

CONFIG_BOOTP_RANDOM_DELAY — если у вас много целей в сети, которые пытаются загрузиться с использованием BOOTP, вы можете захотеть избежать того, что все системы отправляют запросы BOOTP точно в один и тот же момент (что произойдёт, например, при восстановлении после сбоя питания, когда все системы попытаются загрузиться, тем самым перегружая сервер BOOTP. Определение CONFIG_BOOTP_RANDOM_DELAY вызывает случайную задержку перед загрузкой. Отправка запросов BOOTP. Затем вставляются следующие задержки:

1-й запрос BOOTP: задержка 0...1 сек.
2-й запрос BOOTP: задержка 0...2 сек.
3-й запрос BOOTP: задержка 0...4 сек.
4-й и последующие запросы BOOTP: задержка 0...8 сек.

CFG_BOOTP_ID_CACHE_SIZE

Пакеты BOOTP однозначно идентифицируются с помощью 32-битного идентификатора. Сервер скопирует идентификатор из клиентских запросов в ответы, а U-Boot будет использовать его, чтобы определить, является ли он получателем входящего ответа. Некоторые серверы проверяют, не используются ли адреса, прежде чем выдавать их (обычно с помощью ARP-пинга), и поэтому ответ может занять до нескольких сотен миллисекунд. Задержка также может быть вызвана перегрузкой сети. Если время ожидания слишком велико, U-Boot повторно отправит запросы. Чтобы разрешить приём более ранних ответов после этих повторных передач, клиент BOOTP в U-Boot сохраняет небольшой кэш идентификаторов. CFG_BOOTP_ID_CACHE_SIZE управляет размером этого кэша. По умолчанию сохраняются идентификаторы для четырёх невыполненных запросов. Увеличение этого значения позволит U-Boot принимать предложения от клиента BOOTP в сетях с необычно высокой задержкой.

**DHCP расширенные опции:**

* **Согласование локального IP-адреса:** согласование с другими клиентами локальной сети адреса, который не требует явной настройки. Это особенно полезно, если нельзя гарантировать существование DHCP-сервера во всех средах, где должно работать устройство. Дополнительную информацию см. в doc/README.link-local.

* **MAC-адрес из переменных окружения:** FDT_SEQ_MACADDR_FROM_ENV. Исправление дерева устройств с MAC-адресами, последовательно полученными из переменных среды. Эта конфигурация основана на предположении, что неиспользуемые узлы Ethernet в дереве устройств либо отсутствуют, либо их статус помечен как «отключённый».

* **Опции CDP:**
    * CONFIG_CDP_DEVICE_ID — идентификатор устройства, используемый в триггерных кадрах CDP.
    * CONFIG_CDP_DEVICE_ID_PREFIX — двухсимвольная строка, которая добавляется к MAC-адресу устройства.
    * CONFIG_CDP_PORT_ID — строка формата printf, содержащая ASCII-имя порта. Обычно устанавливается как «eth%d», что устанавливает eth0 для первого Ethernet, eth1 для второго и т. д.
    * CONFIG_CDP_CAPABILITIES — 32-разрядное целое число, указывающее возможности устройства; 0x00000010 для обычного хоста, который не выполняет переадресацию.
    * CONFIG_CDP_VERSION — ASCII-строка, содержащая версию программного обеспечения.
    * CONFIG_CDP_PLATFORM — ASCII-строка, содержащая название платформы.
    * CONFIG_CDP_TRIGGER — 32-разрядное целое число, отправляемое при срабатывании.
    * CONFIG_CDP_POWER_CONSUMPTION — 16-разрядное целое число, содержащее энергопотребление устройства в .1 милливатта.
    * CONFIG_CDP_APPLIANCE_VLAN_TYPE — байт, содержащий идентификатор VLAN.

* **Светодиод состояния:** CONFIG_LED_STATUS. Несколько конфигураций позволяют отображать текущее состояние с помощью светодиода. Например, светодиод будет быстро мигать во время выполнения кода U-Boot, перестанет мигать, как только будет получен ответ на запрос BOOTP, и начнёт медленно мигать после запуска ядра Linux (поддерживается драйвером светодиода состояния в ядре Linux). Определение CONFIG_LED_STATUS включает эту функцию в U-Boot.

Дополнительные опции:

* CONFIG_LED_STATUS_GPIO — светодиод состояния можно подключить к контакту GPIO. В таких случаях в качестве реализации драйвера светодиода статуса можно использовать драйвер gpio_led. Определите CONFIG_LED_STATUS_GPIO, чтобы включить драйвер gpio_led в двоичный файл U-Boot.
* CFG_GPIO_LED_INVERTED_TABLE — некоторые подключённые к GPIO светодиоды могут иметь инвертированную полярность, в этом случае контакт GPIO должен быть высоким. **Значение соответствует состоянию светодиода «выключено», а значение GPIO «низкое» соответствует состоянию «включено».** В таких случаях может быть определена CFG_GPIO_LED_INVERTED_TABLE со списком светодиодов GPIO, имеющих инвертированную полярность.

**Поддержка I2C:**

CFG_SYS_NUM_I2C_BUSES содержит количество шин i2c, которые вы хотите использовать.

CFG_SYS_I2C_DIRECT_BUS определяет, если вы не используете мультиплексоры i2c на вашем оборудовании. Если CFG_SYS_I2C_MAX_HOPS не определено или равно 0, то это определение можно опустить.

CFG_SYS_I2C_MAX_HOPS определяет максимальное количество последовательно соединённых мультиплексоров на одной шине i2c. Если вы не используете i2c-мультиплексоры, это определение можно пропустить.

CFG_SYS_I2C_BUSES содержит список шин, которые вы хотите использовать, используется только если CFG_SYS_I2C_DIRECT_BUS не определён. Например, плата с CFG_SYS_I2C_MAX_HOPS = 1 и CFG_SYS_NUM_I2C_BUSES = 9:

CFG_SYS_I2C_BUSES {{0, {I2C_NULL_HOP}}, {0, {{I2C_MUX_PCA9547, 0x70, 1}}}, {0, {{I2C_MUX_PCA9547, 0x70, 2}}}, {0, {{I2C_MUX_PCA9547, 0x70, 3}}}, {0, {{I2C_MUX_PCA9547, 0x70, 4}}}, {0, {{I2C_MUX_PCA9547, 0x70, 5}}}, {1, {I2C_NULL_HOP}}, {1, {{I2C_MUX_PCA9544, 0x72, 1}}}, {1, {{I2C_MUX_PCA9544, 0x72, 2}}}}

Определяет:
* Шину 0 на адаптере 0 без мультиплексора;
* Шину 1 на адаптере 0 с PCA9547 по адресу 0x70 порт 1;
* Шину 2 на адаптере 0 с PCA9547 по адресу 0x70 порт 2;
* Шину 3 на адаптере 0 с PCA9547 по адресу 0x70 порт 3;
* Шину 4 на адаптере 0 с PCA9547 по адресу 0x70 порт 4;
* Шину 5 на адаптере 0 с PCA9547 по адресу 0x70 порт 5;
* Шину 6 на адаптере 1 без мультиплексора;
* Шину 7 на адаптере 1 с PCA9544 по адресу 0x72 порт 1;
* Шину 8 на адаптере 1 с PCA9544 по адресу 0x72 порт 2.

Если у вас нет i2c-мультиплексоров на плате, это определение можно пропустить.

**Устаревшая поддержка I2C**:

Если вы используете программный интерфейс i2c (CONFIG_SYS_I2C_SOFT), то необходимо определить следующие макросы (примеры из include/configs/lwmon.h):

I2C_INIT — команды, необходимые для включения контроллера I2C или настройки портов.

Например: #define I2C_INIT (immr->im_cpm.cp_pbdir |=  PB_SCL)

I2C_ACTIVE — код, необходимый для активации линии данных I2C (управляемой). Если линия данных открыта коллектором, этот параметр может быть пустым.

Например: #define I2C_ACTIVE (immr->im_cpm.cp_pbdir |=  PB_SDA)

I2C_TRISTATE — код, необходимый для перевода линии данных I2C в неактивное состояние (три состояния). Если линия данных открыта коллектором, этот параметр может быть пустым.

Например: #define I2C_TRISTATE (immr->im_cpm.cp_pbdir &= ~PB_SDA)

I2C_READ — код, который возвращает true, если линия данных I2C высокая, false, если она низкая.

Например: #define I2C_READ ((immr->im_cpm.cp_pbdat & PB_SDA) != 0)

I2C_SDA(bit) — если <bit> истинно, устанавливает линию данных I2C высокой. Если оно ложно, очищает его (низкий).

Например: #define I2C_SDA(bit) \
    if(bit) immr->im_cpm.cp_pbdat |=  PB_SDA; \
    else    immr->im_cpm.cp_pbdat &= ~PB_SDA

I2C_SCL(bit) — если <bit> истинно, устанавливает тактовую линию I2C высокой. Если оно ложно, очищает его (низкий).

Например: #define I2C_SCL(bit) \
    if(bit) immr->im_cpm.cp_pbdat |=  PB_SCL; \
    else    immr->im_cpm.cp_pbdat &= ~PB_SCL

I2C_DELAY — эта задержка вызывается четыре раза за такт, поэтому она контролирует скорость передачи данных. Таким образом, скорость передачи данных составляет 1 / (I2C_DELAY * 4). Часто определяется как что-то вроде:

#define I2C_DELAY  udelay(2)

CONFIG_SOFT_I2C_GPIO_SCL / CONFIG_SOFT_I2C_GPIO_SDA — если ваша архитектура поддерживает общую структуру GPIO (asm/gpio.h), вы можете... **Альтернативное определение двух GPIO, которые будут использоваться как SCL / SDA.**

Любые предыдущие макросы I2C_xxx будут иметь соответствующие значения по умолчанию, назначенные GPIO.

Следует определить их как значение GPIO, заданное непосредственно для общих функций GPIO.  

CFG_I2C_MULTI_BUS

Эта опция позволяет использовать несколько шин I2C, каждая из которых должна иметь контроллер. В любой момент времени активна только одна шина. Чтобы переключиться на другую шину, используйте команду «i2c dev». Обратите внимание, что нумерация шин основана на нуле.

CFG_SYS_I2C_NOPROBES

Эта опция определяет список устройств I2C, которые будут пропущены при выдаче команды «i2c probe».

Например:

#define CFG_SYS_I2C_NOPROBES {0x50,0x68}

пропустит адреса 0x50 и 0x68 на плате с одной шиной I2C.

CFG_SYS_RTC_BUS_NUM

Если определено, то это указывает номер шины I2C для RTC. Если не определено, U-Boot предполагает, что RTC находится на шине I2C 0.

CONFIG_SOFT_I2C_READ_REPEATED_START

Определение этого параметра заставит функцию i2c_read() в драйвере soft_i2c выполнить повторный запуск I2C между записью указателя адреса и чтением данных. Если этот параметр не определён, будет использовано поведение по умолчанию выполнения последовательности стоп-старт. Большинство устройств I2C могут использовать любой метод, но некоторые требуют одного или другого.

**Поддержка SPI: CONFIG_SPI**

Включает драйвер SPI (пока протестирован только с EEPROM SPI, также экземпляр работает с Crystal A/D и D/As на плате SACSng).

CFG_SYS_SPI_MXC_WAIT

Время ожидания до завершения передачи SPI. По умолчанию: (CONFIG_SYS_HZ/100) /* 10 мс */

**Поддержка FPGA: CONFIG_FPGA**

Включает подсистему FPGA.

CONFIG_FPGA_<vendor>

Включает поддержку конкретных производителей чипов. (ALTERA, XILINX)

CONFIG_FPGA_<family>

Включает поддержку семейства FPGA. (SPARTAN2, SPARTAN3, VIRTEX2, CYCLONE2, ACEX1K, ACEX)

CONFIG_SYS_FPGA_CHECK_BUSY

Включить проверки статуса занятости интерфейса конфигурации FPGA функцией конфигурации. Эта опция потребует написания функции, специфичной для платы или устройства.

CFG_FPGA_DELAY

Если определена функция, обеспечивающая задержки в драйвере конфигурации FPGA.

CFG_SYS_FPGA_CHECK_ERROR

Проверка ошибок конфигурации во время загрузки битового файла FPGA. Например, прервать конфигурацию Virtex II, если линия INIT_B переходит в низкий уровень (что указывает на ошибку CRC).

CFG_SYS_FPGA_WAIT_INIT

Максимальное время ожидания снятия утверждения линии INIT_B после снятия утверждения PROB_B во время последовательности конфигурации Virtex II. Время ожидания по умолчанию составляет 500 мс.

CFG_SYS_FPGA_WAIT_BUSY

Максимальное время ожидания снятия подтверждения BUSY во время конфигурации Virtex II FPGA. Время ожидания по умолчанию — 5 мс.

CFG_SYS_FPGA_WAIT_CONFIG

Время ожидания после конфигурации FPGA. Время ожидания по умолчанию — 200 мс.

Защита параметров поставщика:

U-Boot считает значения переменных среды «serial#» (серийный номер платы) и «ethaddr» (адрес Ethernet) параметрами, которые устанавливаются один раз поставщиком/производителем платы, и защищает эти переменные от случайного изменения пользователем. После установки эти переменные доступны только для чтения, а попытки записи или удаления отклоняются. Вы можете изменить это поведение:

Если в вашем конфигурационном файле определено CONFIG_ENV_OVERWRITE, защита от записи для параметров поставщика полностью отключена. Любой может изменить или удалить эти параметры.

Того же можно добиться более гибким способом для любой переменной, настроив тип доступа, разрешённый для этих переменных в переменной «.flags», или определив CFG_ENV_FLAGS_LIST_STATIC. Порог превышен, UBI начинает выполнять выравнивание износа путём перемещения данных из стираемого блока с низким счётчиком стираний в стираемые блоки с высоким счётчиком стирания.

Значение по умолчанию должно быть нормальным для SLC NAND-вспышек, NOR-вспышек и других вспышек, срок службы стираемых блоков которых составляет 100 000 или более. Однако в случае MLC NAND-вспышек, которые обычно имеют срок службы стираемого блока менее 10 000, порог следует уменьшить (например, до 128 или 256, хотя он не обязательно должен быть степенью числа 2).

default: 4096

CONFIG_MTD_UBI_BEB_LIMIT
Этот параметр указывает максимальное количество плохих физических стираемых блоков, которое ожидает UBI на устройстве MTD (на 1024 стираемых блока). Если базовая вспышка не допускает плохих стираемых блоков (например, NOR-вспышка), это значение игнорируется.

В технических характеристиках NAND часто указываются минимальное и максимальное значения NVM (количество действительных блоков) для срока службы вспышки. Максимальное ожидаемое количество плохих стираемых блоков на 1024 можно рассчитать как «1024 * (1 - MinNVB / MaxNVB)», что даёт 20 для большинства NAND (MaxNVB — это, по сути, общее количество стираемых блоков на чипе).

Иными словами, если это значение равно 20, UBI попытается зарезервировать около 1,9% физических стираемых блоков для обработки плохих блоков. И это будет 1,9% стираемых блоков всего чипа NAND, а не только раздела MTD, к которому присоединяется UBI. Это означает, что если у вас есть, скажем, чип NAND flash, допускающий максимум 40 плохих стираемых блоков, и он разделён на два одинаковых раздела MTD, UBI зарезервирует 40 стираемых блоков при присоединении раздела.

default: 20

CONFIG_MTD_UBI_FASTMAP
Fastmap — это механизм, который позволяет подключать устройство UBI почти за постоянное время. Вместо сканирования всего устройства MTD ему нужно только найти контрольную точку (называемую fastmap) на устройстве. Встроенная в flash fastmap содержит всю информацию, необходимую для подключения устройства. Использование fastmap имеет смысл только на больших устройствах, где подключение путём сканирования занимает много времени. UBI не будет автоматически устанавливать fastmap на старых образах, но вы можете установить параметр UBI CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT равным 1, если хотите. Обратите внимание, что образы с поддержкой fastmap по-прежнему можно использовать с реализациями UBI без поддержки fastmap. На типичных устройствах flash весь fastmap умещается в один PEB. UBI зарезервирует PEB для хранения двух fastmaps.

CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT
Установите этот параметр, чтобы включить fastmap автоматически на образах без fastmap.
default: 0

CONFIG_MTD_UBI_FM_DEBUG
Включите отладку fastmap UBI
default: 0

- SPL framework
    CONFIG_SPL
    Включите глобальное создание SPL.

    CONFIG_SPL_PANIC_ON_RAW_IMAGE
    Если определено, SPL вызовет panic(), если загруженный образ не имеет сигнатуры. Определение этого полезно, когда код, загружающий образы в SPL, не может гарантировать, что абсолютно все ошибки чтения будут обнаружены. Примером является драйвер MLC NAND LPC32XX, который будет считать, что полностью нечитаемый блок NAND плохой, и его следует пропустить молча.

    CONFIG_SPL_DISPLAY_PRINT
    Для ARM включите дополнительную функцию для печати дополнительной информации о работающей системе.

    CONFIG_SPL_MPC83XX_WAIT_FOR_NAND
    Установите это для NAND SPL на цели PPC mpc83xx, чтобы start.S ждал загрузки остальной части SPL перед продолжением (аппаратное обеспечение начинает выполнение после загрузки только первой страницы, а не полных 4K).

    CONFIG_SPL_UBI
    Поддержка облегчённого сканера и загрузчика UBI (fastmap).

    CONFIG_SYS_NAND_5_ADDR_CYCLE, CONFIG_SYS_NAND_PAGE_SIZE,
    CONFIG_SYS_NAND_OOBSIZE, CONFIG_SYS_NAND_BLOCK_SIZE,
    CONFIG_SYS_NAND_BAD_BLOCK_POS, CFG_SYS_NAND_ECCPOS - **CONFIG_SYS_FLASH_PROTECTION**
    Если определено, используется аппаратная защита секторов флэш-памяти вместо программной защиты U-Boot.

- **CONFIG_SYS_FLASH_CFI:**
    Определить, использует ли драйвер флэш-накопителя дополнительные элементы в общей структуре флэш-памяти для хранения геометрии флэш-памяти.

- **CONFIG_FLASH_CFI_DRIVER**
    Эта опция также включает сборку драйвера cfi_flash в каталоге драйверов.

- **CONFIG_FLASH_CFI_MTD**
    Эта опция включает сборку драйвера cfi_mtd в каталоге драйверов. Драйвер экспортирует CFI flash на уровень MTD.

- **CONFIG_SYS_FLASH_USE_BUFFER_WRITE**
    Использовать буферизованные записи во флэш-память.

- **CONFIG_ENV_FLAGS_LIST_DEFAULT**
— **CFG_ENV_FLAGS_LIST_STATIC**
    Включить проверку значений, заданных переменным среды при вызове env set. Переменные могут быть ограничены только десятичными, шестнадцатеричными или логическими значениями. Если также определён CONFIG_CMD_NET, переменные также могут быть ограничены IP-адресом или MAC-адресом.

    Формат списка:
        type_attribute = [s|d|x|b|i|m]
        access_attribute = [a|r|o|c]
        attributes = type_attribute[access_attribute]
        entry = variable_name[:attributes]
        list = entry[,list]

    Атрибуты типа:
        s — строка (по умолчанию)
        d — десятичное число
        x — шестнадцатеричное число
        b — логическое значение ([1yYtT|0nNfF])
        i — IP-адрес
        m — MAC-адрес

    Атрибуты доступа:
        a — любой (по умолчанию)
        r — только для чтения
        o — однократная запись
        c — изменение по умолчанию

    — **CONFIG_ENV_FLAGS_LIST_DEFAULT**
        Определите это как список (строку), чтобы определить переменную среды «.flags» в стандартной или встроенной среде.

    — **CFG_ENV_FLAGS_LIST_STATIC**
        Определите это как список (строка), чтобы указать проверку, которая должна выполняться, если запись не найдена в переменной среды «.flags». Чтобы переопределить настройку в статическом списке, просто добавьте запись для той же переменной имени в переменную «.flags».

    Если определён CONFIG_REGEX, переменная_имя выше оценивается как регулярное выражение. Это позволяет нескольким переменным определять одни и те же флаги без явного перечисления их для каждой переменной.

Следующие определения, которые касаются размещения и управления данными среды (область переменных); в целом мы поддерживаем следующие конфигурации:

БУДЬТЕ ОСТОРОЖНЫ! Первый доступ к среде происходит довольно рано в процессе инициализации U-Boot (когда мы пытаемся получить настройку скорости передачи данных для консоли). Вы *ДОЛЖНЫ* уже отобразить область NVRAM, иначе U-Boot зависнет.

Обратите внимание, что даже с NVRAM мы всё ещё используем копию среды в ОЗУ: мы могли бы работать с NVRAM напрямую, но мы хотим, чтобы настройки там всегда оставались неизменными, за исключением случаев, когда кто-то использует «saveenv» для сохранения текущих настроек.

БУДЬТЕ ОСТОРОЖНЫ! В некоторых особых случаях локальное устройство не может использовать команду «saveenv». Например, локальное устройство получит среду, хранящуюся в удалённой NOR-флеш-памяти через SRIO или PCIE-канал, но оно не сможет стереть или записать эту NOR-флеш-память через интерфейс SRIO или PCIE.

— **CONFIG_NAND_ENV_DST**

Определяет адрес в ОЗУ, на который код nand_spl должен скопировать среду. Если используется избыточная среда, она будет скопирована в CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE.

Обратите внимание, что среда доступна только для чтения до тех пор, пока монитор не будет перемещён в ОЗУ и не будет создана копия среды в ОЗУ; кроме того, при использовании EEPROM вам придётся использовать env_get_f() до этого для чтения переменных среды.

Среда защищена контрольной суммой CRC32. До того, как монитор будет перемещён в ОЗУ, в результате плохой CRC вы будете работать со встроенной средой по умолчанию — *молча*!!! [Это необходимо, потому что первая переменная среды, которая нам нужна, — это настройка «скорость передачи данных» для консоли — если у нас плохая CRC, у нас ещё нет устройства, где мы могли бы пожаловаться.]

Примечание: после перемещения монитора он будет жаловаться, если по умолчанию... **environment is used; a new CRC is computed как только вы используете команду «saveenv» для сохранения действующей среды.**

- CONFIG_SYS_FAULT_MII_ADDR:
    MII адрес PHY для проверки состояния Ethernet-соединения.

- CONFIG_DISPLAY_BOARDINFO:
  информация о плате, на которой работает U-Boot, отображается при запуске U-Boot. Для этого вызывается функция board checkboard().

- CONFIG_DISPLAY_BOARDINFO_LATE:
  аналогично предыдущему варианту, но эта информация отображается позже, когда stdio запущен и вывод идёт на ЖК-дисплей, если он присутствует.

**Параметры конфигурации низкого уровня (связанные с оборудованием):**

- CONFIG_SYS_CACHELINE_SIZE:
  размер строки кэша процессора.

- CONFIG_SYS_CCSRBAR_DEFAULT:
  физический адрес CCSR по умолчанию (сброс питания) на SOC Freescale PowerPC.

- CFG_SYS_CCSRBAR:
  виртуальный адрес CCSR. В 32-битной сборке это обычно то же значение, что и CONFIG_SYS_CCSRBAR_DEFAULT.

- CFG_SYS_CCSRBAR_PHYS:
  физический адрес CCSR. CCSR можно переместить на новый физический адрес, если это необходимо. В этом случае этот макрос должен быть установлен на этот адрес. В противном случае он должен быть установлен в то же значение, что и CONFIG_SYS_CCSRBAR_DEFAULT. Например, CCSR обычно перемещается на 36-битных сборках. Рекомендуется определить этот макрос через макросы _HIGH и _LOW:

#define CFG_SYS_CCSRBAR_PHYS ((CFG_SYS_CCSRBAR_PHYS_HIGH * 1ull) << 32 | CFG_SYS_CCSRBAR_PHYS_LOW)

- CFG_SYS_CCSRBAR_PHYS_HIGH:
  биты 33–36 CFG_SYS_CCSRBAR_PHYS. Это значение обычно равно 0 (32-разрядная сборка) или 0xF (36-разрядная сборка). Этот макрос используется в коде сборки, поэтому он не должен содержать приведения типов или суффиксов размера целых чисел (например, «ULL»).

- CFG_SYS_CCSRBAR_PHYS_LOW:
  младшие 32 бита CFG_SYS_CCSRBAR_PHYS. Этот макрос используется в коде сборки, поэтому он не должен содержать приведений типов или суффиксов размера целых чисел (например, «ULL»).

- CONFIG_SYS_IMMR: физический адрес внутренней памяти. НЕ ИЗМЕНЯЙТЕ, если вы точно не знаете, что делаете! (11–4) [только системы MPC8xx]

- CFG_SYS_INIT_RAM_ADDR: начальный адрес области памяти, которую можно использовать для начальных данных и стека; обратите внимание, что это должна быть записываемая память, которая работает БЕЗ специальной инициализации, т. е. вы НЕ МОЖЕТЕ использовать обычную RAM, которая станет доступной только после программирования контроллера памяти и выполнения определённых последовательностей инициализации.

U-Boot использует следующие типы памяти:
— MPC8xx: IMMR (внутренняя память процессора).

- CONFIG_SYS_SCCR: регистр управления системными часами и сбросом (15–27).

- CONFIG_SYS_OR_TIMING_SDRAM: тайминг SDRAM.

- CONFIG_SYS_SRIOn_MEM_VIRT: виртуальный адрес области памяти порта SRIO 'n'.

- CONFIG_SYS_SRIOn_MEM_PHYxS: физический адрес области памяти порта SRIO 'n'.

- CONFIG_SYS_SRIOn_MEM_SIZE: размер области памяти порта SRIO 'n'.

- CONFIG_SYS_NAND_BUSWIDTH_16BIT: определяется, чтобы сообщить контроллеру NAND, что чип NAND использует 16-битную шину. Не все драйверы NAND используют этот символ. Пример драйверов, которые его используют:
drivers/mtd/nand/raw/ndfc.c, drivers/mtd/nand/raw/mxc_nand.c.

- CONFIG_SYS_NDFC_EBC0_CFG: устанавливает регистр EBC0_CFG для NDFC. Если не определено, будет использоваться значение по умолчанию.

- CONFIG_SYS_SPD_BUS_NUM: если SPD EEPROM находится на шине I2C, отличной от первой, укажите здесь. Обратите внимание, что значение должно соответствовать тому, с чем может работать ваш драйвер.

- CONFIG_FSL_DDR_INTERACTIVE: включить интерактивную отладку DDR. См. doc/README.fsl-ddr.

- CONFIG_FSL_DDR_SYNC_REFRESH: включить синхронизацию обновления для нескольких контроллеров.

- CONFIG_FSL_DDR_BIST: включить встроенный тест памяти для контроллеров Freescale DDR.

- CONFIG_RMII: включить режим RMII для всех FEC. Обратите внимание, что это глобальный параметр, мы не можем... **Имеются следующие настройки:**

1. **CONFIG_CRC32_VERIFY.** Добавить опцию verify в команду crc32. Синтаксис:

    crc32 -v <адрес> <количество> <crc32>,

где адрес/количество указывают на область памяти, а crc32 — это правильный crc32, который должен быть у этой области.

2. **CONFIG_LOOPW.** Добавить команду памяти «loopw». Она действует только в том случае, если глобально активированы команды памяти (CONFIG_CMD_MEMORY).

3. **CONFIG_CMD_MX_CYCLIC.** Добавить команды памяти «mdc» и «mwc». Это циклические команды «md/mw». Примеры:

    mdc.b 10 4 500 — эта команда будет выводить по 4 байта (10, 11, 12, 13) каждые 500 мс;

    mwc.l 100 12345678 10 — эта команда будет записывать 12345678 по адресу 100 каждые 10 мс.

Эта настройка действует только в случае глобальной активации команд памяти (CONFIG_CMD_MEMORY).

4. **CONFIG_SPL_BUILD.** Установить, когда текущая компиляция предназначена для артефакта, который попадёт в одну из сборок xPL, то есть SPL, TPL или VPL. Код, которому требуется поведение, зависящее от фазы, может проверить это или (если возможно) использовать spl_phase() вместо этого.

Обратите внимание, что CONFIG_SPL_BUILD всегда определяется, когда определена либо CONFIG_TPL_BUILD, либо CONFIG_VPL_BUILD. Это может показаться нелогичным, и, возможно, это следует изменить.

5. **CONFIG_TPL_BUILD.** Установить, когда текущая компиляция предназначена для артефакта, который попадёт в сборку TPL (в отличие от SPL, VPL или U-Boot). Код, которому требуется поведение, зависящее от фазы, может проверить это или (если возможно) использовать spl_phase() вместо этого.

6. **CONFIG_VPL_BUILD.** Установить, когда текущая компиляция предназначена для артефакта, который попадёт в сборку VPL (в отличие от SPL, TPL или U-Boot). Код, которому требуется поведение, зависящее от фазы, может проверить это или (если возможно) использовать spl_phase() вместо этого.

7. **CONFIG_ARCH_MAP_SYSMEM.** Обычно U-Boot (и особенно команда md) использует эффективный адрес. Поэтому нет необходимости рассматривать адрес U-Boot как виртуальные адреса, которые необходимо преобразовать в физические. Однако sandbox требует этого, поскольку он поддерживает собственный небольшой буфер RAM, содержащий всю адресуемую память. Эта опция приводит к тому, что некоторые обращения к памяти отображаются через map_sysmem() / unmap_sysmem().

8. **CONFIG_X86_RESET_VECTOR.** Если определено, включается код вектора сброса x86. Это не нужно, когда U-Boot работает с Coreboot.

**Поддержка прошивки Freescale QE/FMAN:**

Freescale QUICCEngine (QE) и Frame Manager (FMAN) поддерживают загрузку «прошивки», которая закодирована в двоичном формате прошивки QE. Эту прошивку часто необходимо загружать во время загрузки U-Boot, поэтому используются макросы для идентификации устройства хранения (NOR flash, SPI и т. д.) и адреса в этом устройстве.

9. **CONFIG_SYS_FMAN_FW_ADDR.** Адрес в устройстве хранения, где находится микрокод FMAN. Значение этого адреса зависит от того, какой макрос CONFIG_SYS_QE_FMAN_FW_IN_xxx также указан.

10. **CONFIG_SYS_QE_FW_ADDR.** Адрес в устройстве хранения, где находится микрокод QE. Значение этого адреса зависит от того, какой макрос CONFIG_SYS_QE_FMAN_FW_IN_xxx также указан.

11. **CONFIG_SYS_QE_FMAN_FW_LENGTH.** Максимально возможный размер прошивки. В двоичном формате прошивки есть поле, которое указывает фактический размер прошивки, но может оказаться невозможным прочитать какую-либо часть прошивки, если не выделить локальное хранилище для хранения всей прошивки.

12. **CONFIG_SYS_QE_FMAN_FW_IN_NOR.** Указывает, что прошивка QE/FMAN находится в NOR flash, отображаемой как обычная адресуемая память через LBC. CONFIG_SYS_FMAN_FW_ADDR — это виртуальный адрес в NOR flash.

13. **CONFIG_SYS_QE_FMAN_FW_IN_NAND.** Указывает, что прошивка QE/FMAN находится в NAND flash. **Смещение во флеш-памяти NAND.**

- CONFIG_SYS_QE_FMAN_FW_IN_MMC
    Определяет, что микропрограмма QE/FMAN находится на основном устройстве SD/MMC. CONFIG_SYS_FMAN_FW_ADDR — это смещение в байтах на этом устройстве.

- CONFIG_SYS_QE_FMAN_FW_IN_REMOTE
    Определяет, что микропрограмма QE/FMAN расположена в удалённом (главном) пространстве памяти. CONFIG_SYS_FMAN_FW_ADDR является виртуальным адресом, который можно сопоставить из ведомого TLB->ведомого LAW->ведомого SRIO или исходящего окна PCIE->входящего окна мастера->ведущего LAW->адреса ucode в пространстве памяти мастера.

**Поддержка комплекса встроенного ПО Freescale Layerscape Management Complex:**
---------------------------------------------------------
Комплекс встроенного ПО Freescale Layerscape Management (MC) поддерживает загрузку «микропрограммы». Эту микропрограмму часто необходимо загружать во время загрузки U-Boot, поэтому используются макросы для идентификации устройства хранения (NOR flash, SPI и т. д.) и адреса в этом устройстве. 

- CONFIG_FSL_MC_ENET
    Включает драйвер MC для SoC Layerscape.

**Поддержка отладочного сервера Freescale Layerscape:**
-------------------------------------------
Поддержка отладочного сервера Freescale Layerscape поддерживает загрузку «отладочной серверной микропрограммы» и запуск SP boot-rom. Эту микропрограмму часто необходимо загружать во время загрузки U-Boot.

- CONFIG_SYS_MC_RSV_MEM_ALIGN
    Определяет выравнивание зарезервированной памяти, необходимое MC.

**Создание программного обеспечения:**
======================

Создание U-Boot было протестировано в нескольких собственных средах сборки и во многих различных кросс-средах. Конечно, мы не можем поддерживать все возможные существующие версии инструментов кросс-разработки во всех (потенциально устаревших) версиях. В случае проблем с цепочкой инструментов мы рекомендуем использовать ELDK (см. https://www.denx.de/wiki/DULG/ELDK), который широко используется для создания и тестирования U-Boot.

Если вы не используете собственную среду, предполагается, что у вас есть инструменты GNU для кросс-компиляции, доступные в вашем пути. В этом случае вы должны установить переменную среды CROSS_COMPILE в своей оболочке. Обратите внимание, что никаких изменений в Makefile или любых других исходных файлах не требуется. Например, при использовании ELDK на процессоре 4xx введите:

    $ CROSS_COMPILE=ppc_4xx-
    $ export CROSS_COMPILE

U-Boot предназначен для простой сборки. После установки источников вы должны настроить U-Boot для одного конкретного типа платы. Это делается путём ввода:

    make NAME_defconfig

где «NAME_defconfig» — это имя одной из существующих конфигураций; см. configs/*_defconfig для поддерживаемых имён.

Примечание: для некоторых плат могут существовать специальные имена конфигураций; проверьте, доступна ли дополнительная информация от поставщика платы; например, системы TQM823L доступны без (стандартной) поддержки ЖК-дисплея или с поддержкой ЖК-дисплея. Вы можете выбрать такие дополнительные «функции» при выборе конфигурации, то есть:

      make TQM823L_defconfig
    - настроит для простого TQM823L, то есть без поддержки ЖК-дисплея

      make TQM823L_LCD_defconfig
    - настроит для TQM823L с поддержкой U-Boot консоли на ЖК-дисплее

      и т.д.

Наконец, введите «make all», и вы получите несколько рабочих образов U-Boot, готовых к загрузке / установке в вашей системе:

- «u-boot.bin» — необработанный двоичный образ
- «u-board» — образ в формате ELF
- «u-boot.srec» — в формате Motorola S-Record

Пользовательские CPPFLAGS, AFLAGS и CFLAGS можно передать компилятору, установив соответствующие переменные среды KCPPFLAGS, KAFLAGS и KCFLAGS. Например, чтобы рассматривать все предупреждения компилятора как ошибки:

    make KCFLAGS=-Werror

Обратите внимание, что Makefiles предполагают, что вы используете GNU make, поэтому, например, в NetBSD вам может потребоваться использовать «gmake» вместо собственного «make».

Если системная плата, которая у вас есть, не указана, вам потребуется перенести U-Boot на вашу аппаратную платформу. Для этого выполните следующие действия:

1. Создайте новый каталог для хранения кода вашей конкретной платы. Добавьте любые файлы, которые вам нужны. В каталоге вашей платы вам понадобятся как минимум «Makefile» и «<board>.c».
2. Создайте новый файл конфигурации «include/configs/<board>.h» для вашей платы.
3. Если вы переносите U-Boot на новый процессор, также создайте файл: **Создание нового каталога для специфичного кода процессора. Добавление необходимых файлов**

1. Создайте новый каталог для хранения специфичного для вашего процессора кода. Добавьте все необходимые файлы.

4. Запустите команду «make <board>_defconfig» с вашим новым именем.
5. Введите «make», и вы должны получить рабочий файл «u-boot.srec», который будет установлен в вашей целевой системе.
6. Отладьте и решите любые проблемы, которые могут возникнуть. Конечно, этот последний шаг намного сложнее, чем кажется.

**Тестирование модификаций U-Boot, портирование на новое оборудование и т. д.**

Если вы модифицировали исходные коды U-Boot (например, добавили новую плату или поддержку новых устройств, новый процессор и т.д.), ожидается, что вы предоставите обратную связь другим разработчикам. Обратная связь обычно принимает форму «патча», то есть контекстного сравнения с определённой (последней официальной версией или последней версией в репозитории git) версией исходных кодов U-Boot.

Но прежде чем отправить такой патч, пожалуйста, убедитесь, что ваша модификация не нарушила существующий код. По крайней мере, убедитесь, что ВСЕ поддерживаемые платы компилируются БЕЗ каких-либо предупреждений компилятора. Для этого просто запустите скрипт buildman (tools/buildman/buildman), который настроит и соберёт U-Boot для ВСЕХ поддерживаемых систем. Имейте в виду, это займёт некоторое время. Пожалуйста, ознакомьтесь с README buildman или запустите «buildman -H» для получения документации.

Также см. «Руководство по портированию U-Boot» ниже.

**Обзор команд монитора**

go — запустить приложение по адресу «addr».
run — выполнить команды в среде.
bootm — загрузить образ приложения из памяти.
bootp — загрузить образ через сеть с использованием протокола BootP/TFTP.
bootz — загрузить zImage из памяти.
tftpboot — загрузить образ через сеть с помощью протокола TFTP и переменных среды «ipaddr» и «serverip» (и, возможно, «gatewayip»).
tftpput — загрузить файл через сеть с помощью протокола TFTP.
rarpboot — загрузить образ через сеть с использованием протоколов RARP/TFTP.
diskboot — загрузка с устройства IDE.
boots — загрузка файла S-Record через последовательный канал.
loadb — загрузка двоичного файла через последовательный канал (режим kermit).
loadm — загрузка двоичной капли из исходного адреса в адрес назначения.
md — отображение памяти.
mm — изменение памяти (автоинкремент).
nm — изменение памяти (постоянный адрес).
mw — запись в память (заполнение).
ms — поиск в памяти.
cp — копирование памяти.
cmp — сравнение памяти.
crc32 — расчёт контрольной суммы.
i2c — подсистема I2C.
sspi — команды утилиты SPI.
base — печать или установка смещения адреса.
printenv — печать переменных окружения.
pwm — управление каналами ШИМ.
seama — загрузка образа SEAMA NAND.
setenv — установка переменных окружения.
saveenv — сохранение переменных окружения в постоянном хранилище.
protect — включение или отключение защиты записи FLASH.
erase — стирание памяти FLASH.
flinfo — вывод информации о памяти FLASH.
nand — операции с памятью NAND (см. doc/README.nand).
bdinfo — вывод структуры Board Info.
iminfo — вывод информации заголовка для образа приложения.
coninfo — вывод устройств и информации консоли.
ide — подсистема IDE.
loop — бесконечный цикл по диапазону адресов.
loopw — бесконечный цикл записи по диапазону адресов.
mtest — простой тест RAM.
icache — включить или отключить кэш инструкций.
dcache — включить или отключить кеш данных.
reset — выполнение сброса CPU.
echo — эхо аргументов на консоль.
version — печать версии монитора.
help — распечатать онлайн-справку.
? — псевдоним для «help».

**Подробное описание команд монитора**

TODO. На данный момент: просто введите «help <command>».

**Примечание для избыточных Ethernet-интерфейсов**

Некоторые платы поставляются с избыточными Ethernet-интерфейсами; U-Boot поддерживает такие конфигурации и способен автоматически выбирать «рабочий» интерфейс при необходимости. Назначение MAC работает следующим образом:

Сетевые интерфейсы нумеруются eth0, eth1, eth2 и так далее. Соответствующие MAC-адреса можно сохранить в среде как «ethaddr» (=>eth0), «eth1addr» (=>eth1), «eth2addr» и так далее.

Если сетевой интерфейс хранит действительный MAC-адрес (например, в SROM), он используется в качестве адреса по умолчанию, если в среде нет соответствующего параметра; если соответствующая переменная среды установлена, она переопределяет... Настройки в карте; это означает:

o Если SROM имеет действительный MAC-адрес и в среде нет адреса, используется адрес SROM.

o Если в SROM нет действительного адреса и существует определение в среде, то используется значение из переменной среды.

o Если и SROM, и среда содержат MAC-адрес, и оба адреса одинаковы, этот MAC-адрес используется.

o Если и SROM, и среда содержат MAC-адрес, и адреса различаются, используется значение из среды и печатается предупреждение.

o Если ни SROM, ни среда не содержат MAC-адреса, возникает ошибка. Если определено CONFIG_NET_RANDOM_ETHADDR, то в этом случае используется случайный локально назначенный MAC.

Если драйверы Ethernet реализуют функцию write_hwaddr, действительные MAC-адреса будут запрограммированы в оборудование в процессе инициализации. Это можно пропустить, установив соответствующую переменную среды ethmacskip. Соглашение об именах следующее: «ethmacskip» (=>eth0), «eth1macskip» (=>eth1) и т. д.

Форматы изображений:
==============

U-Boot способен загружать (и выполнять другие вспомогательные операции с) изображениями в двух форматах:

Новый формат uImage (FIT)
-----------------------

Гибкий и мощный формат, основанный на Flattened Image Tree — FIT (похож на Flattened Device Tree). Он позволяет использовать изображения с несколькими компонентами (несколько ядер, RAM-диски и т.д.), содержимое защищено SHA1, MD5 или CRC32. Более подробную информацию можно найти в каталоге doc/uImage.FIT.

Старый формат uImage
-----------------

Старый формат изображений основан на двоичных файлах, которые могут быть чем угодно, с предшествующим специальным заголовком; подробности см. в определениях в include/image.h; в основном заголовок определяет следующие свойства изображения:

* Целевая операционная система (предоставляет возможности для OpenBSD, NetBSD, FreeBSD, 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, LynxOS, pSOS, QNX, RTEMS, INTEGRITY;
В настоящее время поддерживаются: Linux, NetBSD, VxWorks, QNX, RTEMS, INTEGRITY).
* Архитектура целевого процессора (предоставляет возможности для Alpha, ARM, Intel x86, IA64, MIPS, Nios II, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
В настоящее время поддерживается: ARM, Intel x86, MIPS, Nios II, PowerPC).
* Тип сжатия (несжатый, gzip, bzip2)
* Адрес загрузки
* Точка входа
* Имя изображения
* Временная метка изображения

Заголовок отмечен специальным магическим числом, а сам заголовок и данные изображения защищены от повреждения контрольными суммами CRC32.

Поддержка Linux:
==============

Хотя U-Boot должен поддерживать любую ОС или автономное приложение, основное внимание при разработке U-Boot всегда уделялось Linux.

U-Boot включает в себя множество функций, которые до сих пор были частью некоторого специального кода «загрузчика» в ядре Linux. Кроме того, любые образы «initrd», которые должны использоваться, больше не являются частью одного большого образа Linux; вместо этого ядро и «initrd» являются отдельными образами. Эта реализация служит нескольким целям:

- одни и те же функции могут использоваться для других ОС или автономных приложений (например, использование сжатых образов для уменьшения занимаемой памяти во Flash-памяти)

- становится намного проще переносить новые версии ядра Linux, потому что U-Boot выполняет много низкоуровневых, зависящих от оборудования вещей

- один и тот же образ ядра Linux теперь можно использовать с разными образами «initrd»; конечно, это также означает, что разные образы ядра можно запускать с одним и тем же «initrd». Это упрощает тестирование (вам не нужно создавать новый образ Linux «zImage.initrd», когда вы просто меняете файл в своём «initrd»). Кроме того, обновление программного обеспечения на месте теперь стало проще.

Linux HOWTO:
============

Перенос Linux на системы на основе U-Boot:
---------------------------------------

U-Boot не может избавить вас от необходимости вносить все необходимые изменения для настройки драйверов устройств Linux для использования с вашим целевым оборудованием (нет, мы не собираемся предоставлять полный интерфейс виртуальной машины для Linux :-).

Но теперь вы можете игнорировать весь код загрузчика (в arch/powerpc/mbxboot).

Просто убедитесь, что ваш специфичный для машины заголовочный файл... Конфигурирование ядра Linux:
-----------------------------

Для U-Boot нет особых требований. Убедитесь, что у вас есть корневое устройство (initial ramdisk, NFS) для вашей целевой системы.

Создание образа Linux:
-----------------------

С U-Boot не используются обычные цели сборки, такие как «zImage» или «bzImage». Если вы используете недавний исходный код ядра, будет существовать новая цель сборки «uImage», которая автоматически создаёт образ, используемый U-Boot. В большинстве старых ядер также есть поддержка цели «pImage», которая была введена для нашего предшествующего проекта PPCBoot и использует на 100% совместимый формат.

Пример:

    make TQM850L_defconfig
    make oldconfig
    make dep
    make uImage

Цель сборки «uImage» использует специальный инструмент (в 'tools/mkimage') для инкапсуляции сжатого образа ядра Linux с информацией заголовка, контрольной суммой CRC32 и т. д. для использования с U-Boot. Вот что мы делаем:

* создаём стандартный образ «vmlinux» ядра (в формате двоичного файла ELF):

* преобразуем ядро в необработанный двоичный образ:

        ${CROSS_COMPILE}-objcopy -O binary \
                -R .note -R .comment \
                -S vmlinux linux.bin

* сжимаем двоичный образ:

        gzip -9 linux.bin

* упаковываем сжатый двоичный образ для U-Boot:

        mkimage -A ppc -O linux -T kernel -C gzip \
            -a 0 -e 0 -n "Linux Kernel Image" \
            -d linux.bin.gz uImage

Инструмент «mkimage» также можно использовать для создания образов RAM-диска для использования с U-Boot, либо отдельно от образа ядра Linux, либо объединённых в один файл. «Mkimage» инкапсулирует образы 64-байтным заголовком, содержащим информацию о целевой архитектуре, операционной системе, типе образа, методе сжатия, точках входа, отметке времени, контрольных суммах CRC32 и т.д.

«Mkimage» можно вызвать двумя способами: чтобы проверить существующие образы и распечатать информацию заголовка, или чтобы создать новые образы.

В первой форме (с опцией «-l») «mkimage» выводит информацию, содержащуюся в заголовке существующего образа U-Boot; это включает проверку контрольной суммы:

    tools/mkimage -l image
      -l ==> список информации заголовка образа

Вторая форма (с опцией «-d») используется для создания образа U-Boot из «файла данных», который используется в качестве полезной нагрузки образа:

    tools/mkimage -A arch -O os -T type -C comp -a addr -e ep \
              -n name -d data_file image
      -A ==> установить архитектуру в 'arch'
      -O ==> установить операционную систему в 'os'
      -T ==> установить тип образа в 'type'
      -C ==> установить тип сжатия 'comp'
      -a ==> установить адрес загрузки в 'addr' (шестнадцатеричный)
      -e ==> установить точку входа в 'ep' (шестнадцатеричная)
      -n ==> установить имя образа в 'name'
      -d ==> использовать данные образа из 'datafile'

Сейчас все ядра Linux для систем PowerPC используют один и тот же адрес загрузки (0x00000000), но адрес точки входа зависит от версии ядра:

- ядра 2.2.x имеют точку входа по адресу 0x0000000C,
- ядра 2.3.x и более поздние имеют точку входа по адресу 0x00000000.

Таким образом, типичный вызов для создания образа U-Boot будет выглядеть так:

    -> tools/mkimage -n '2.4.4 kernel for TQM850L' \
    > -A ppc -O linux -T kernel -C gzip -a 0 -e 0 \
    > -d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/powerpc/coffboot/vmlinux.gz \
    > examples/uImage.TQM850L
    Имя образа:   2.4.4 kernel for TQM850L
    Создано:      среда, 19 июля 2000 г., 02:34:59
    Тип образа:   Образ ядра Linux для PowerPC (сжатый gzip)
    Размер данных: 335725 байт = 327,86 КБ = 0,32 МБ
    Адрес загрузки: 0x00000000
    Точка входа:  0x00000000 **Загрузка Linux и передача плоского дерева устройств:**

Сначала U-Boot должен быть скомпилирован с соответствующими определениями. Более подробное объяснение см. в разделе «Интерфейс ядра Linux» выше. Ниже приведён пример того, как запустить ядро и передать обновлённое плоское дерево устройств:

*=> print oftaddr*
oftaddr=0x300000
*=> print oft*
oft=oftrees/mpc8540ads.dtb
*=> tftp $oftaddr $oft*
Speed: 1000, full duplex
Using TSEC0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.101
Filename 'oftrees/mpc8540ads.dtb'.
Load address: 0x300000
Loading: #
done
Bytes transferred = 4106 (100a hex)
*=> tftp $loadaddr $bootfile*
Speed: 1000, full duplex
Using TSEC0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.2
Filename 'uImage'.
Load address: 0x200000
Loading:############
done
Bytes transferred = 1029407 (fb51f hex)
*=> print loadaddr*
loadaddr=200000
*=> print oftaddr*
oftaddr=0x300000
*=> bootm $loadaddr - $oftaddr*
## Booting image at 00200000 ...
   Image Name:   Linux-2.6.17-dirty
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1029343 Bytes = 1005.2 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x300000
Using MPC85xx ADS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
[snip]

**Подробнее о типах образов U-Boot:**

U-Boot поддерживает следующие типы образов:

*«Автономные программы»* непосредственно запускаются в среде, предоставляемой U-Boot; ожидается, что (если они ведут себя хорошо) вы сможете продолжить работу в U-Boot после возврата из автономной программы.
*«Образы ядра ОС»* обычно представляют собой образы какой-либо встроенной ОС, которая полностью возьмёт на себя управление. Обычно эти программы установят собственный набор обработчиков исключений, драйверов устройств, настроят MMU. **b, e, ?]:**
    tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x1efc, ter=0x0

Hit '?':
    [q, b, e, ?].
    tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x169d, ter=0x0

Hit 'e':
    [q, b, e, ?] ...Stopping timer

Hit 'q':
    [q, b, e, ?] ## Application terminated, rc = 0x0.

**Реализация внутренних компонентов:**
=========================

Нижеизложенное не является полным описанием всех деталей реализации. Однако оно должно помочь понять внутреннюю работу U-Boot и облегчить его перенос на пользовательское оборудование.

**Начальный стек, глобальные данные:**
---------------------------

Реализация U-Boot усложняется тем, что U-Boot начинает работать из ПЗУ (флеш-памяти), обычно без доступа к системной оперативной памяти (потому что контроллер памяти ещё не инициализирован). Это означает, что у нас нет доступных для записи сегментов данных или BSS, а BSS не инициализируется нулями. Чтобы вообще получить работающую среду C, мы должны выделить хотя бы минимальный стек. Варианты реализации этого определяются и ограничиваются используемым процессором: некоторые модели процессоров предоставляют встроенную память (например, область IMMR на процессорах MPC8xx и MPC826x), на других (части) кэш данных можно заблокировать как (неверно) используемую в качестве памяти и т. д.

Крис Халлинан опубликовал хорошее резюме этих проблем в списке рассылки U-Boot:

Тема: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)?
От: «Крис Халлинан» <clh@net1plus.com>
Дата: Пн, 10 февраля 2003 г., 16:43:46 -0500 (22:43 MET)
...

Поправьте меня, если я ошибаюсь, но насколько я понимаю, использование DCACHE в качестве начальной оперативной памяти для стека и т.д. не требует физической оперативной памяти, поддерживающей кэш. Хитрость заключается в том, что кэш используется в качестве временного источника необходимого хранилища до настройки контроллера SDRAM. В рамках этого списка невозможно объяснить детали, но вы можете увидеть, как это работает, изучив архитектуру кэша и работу в руководствах по архитектуре и процессорам.

OCM — это встроенная память, которая, как мне кажется, имеет 4K. Это ещё один вариант для системного проектировщика использовать в качестве области начального стека/RAM до того, как станет доступна SDRAM. Любой вариант должен сработать для вас. Использование CS 4 должно быть нормальным, если ваши разработчики плат не использовали его для чего-то, что могло бы вызвать у вас проблемы во время начальной загрузки! Часто он не используется.

CFG_SYS_INIT_RAM_ADDR должен находиться где-нибудь, чтобы не мешать вашему процессору/плате/системному дизайну. Значение по умолчанию, которое вы найдёте в любом недавнем дистрибутиве u-boot в walnut.h, должно сработать для вас. Я бы установил его на значение больше, чем ваш модуль SDRAM. Если у вас есть модуль SDRAM на 64 МБ, установите его выше 400_0000. Просто убедитесь, что ваша плата не имеет ресурсов, которые должны реагировать на этот адрес! Этот код в start.S существует уже некоторое время и должен работать как есть, когда вы правильно настроите конфигурацию.

— Крис Халлинан
DS4.COM, Inc.

Важно помнить об этом, поскольку это оказывает некоторое влияние на код C для процедур инициализации:
* Инициализированные глобальные данные (сегмент данных) доступны только для чтения. Не пытайтесь их записать.
* Не используйте какие-либо неинициализированные глобальные данные (или неявно инициализированные как нулевые данные — сегмент BSS) вообще — это неопределённо, инициализация выполняется позже (при перемещении в оперативную память).
* Пространство стека очень ограничено. Избегайте больших буферов данных и тому подобного.

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

Выбирая регистр для такой цели, мы... Для реализации кода инициализации на языке C во внутренней двухпортовой оперативной памяти создаётся (небольшой!) начальный стек (в случае процессоров, которые предоставляют такую возможность), или в заблокированной части кэша данных. После этого U-Boot инициализирует ядро процессора, кэши и SIU.

Затем все (потенциально) доступные банки памяти отображаются с использованием предварительного отображения. Например, мы размещаем их на границах 512 МБ (кратные 0x20000000: SDRAM на 0x00000000 и 0x20000000, Flash на 0x40000000 и 0x60000000, SRAM на 0x80000000). Затем программируется UPM A для доступа к SDRAM. С использованием временной конфигурации выполняется простой тест памяти, который определяет размер банков SDRAM.

Если имеется более одного банка SDRAM и банки имеют разный размер, то сначала отображается самый большой. При одинаковом размере первым отображается первый банк (CS2#). Первое отображение всегда выполняется по адресу 0x00000000, а любые дополнительные банки следуют сразу за ним, чтобы создать непрерывную память, начиная с 0.

После этого монитор устанавливается в верхней части области SDRAM и выделяет память для использования malloc() и для глобальных данных Board Info; также код вектора исключений копируется на страницы низкой оперативной памяти и устанавливается окончательный стек.

Только после этого перемещения у вас будет «нормальная» среда C; до этого вы будете ограничены несколькими способами, главным образом потому, что вы работаете из ПЗУ, и потому что код должен быть перемещён по новому адресу в ОЗУ.

Вклад в проект
============
Проекты U-Boot зависят от вклада сообщества пользователей. Если вы хотите принять участие, пожалуйста, ознакомьтесь с разделом «Общие сведения» на странице https://docs.u-boot.org/en/latest/develop/index.html, где мы описываем стандарты кодирования и процесс отправки исправлений.