|
Здесь приведен перевод файла README из репозитория U-Boot [1].
# SPDX-License-Identifier: GPL-2.0+
#
# (C) Copyright 2000 - 2013
# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
Summary:
========
Эта директория содержит исходный код проекта U-Boot, загрузчика для плат встраиваемых устройств на основе PowerPC, ARM, MIPS и многих других процессоров, которые могут быть установлены в boot ROM и использованы для инициализации и тестирования оборудования или для загрузки и запуска кода приложения (например, для загрузки и запуска ядра операционной системы Linux).
Разработка U-Boot тесно связана с Linux: некоторые части исходного кода U-Boot были изначально заимствованы из дерева исходников Linux. Используется несколько общих заголовочных файлов, и добавлена поддержка загрузки из образов Linux.
Некоторое внимание было уделено расширяемости и облегчению настройки U-Boot. Например, все команды monitor реализованы с одинаковым интерфейсом вызова, так что очень просто можно добавлять новые команды. Кроме того, вместо постоянного добавления в monitor редко используемого кода (например для утилит тестирования аппаратуры), вы можете его загружать и запускать динамически.
Status:
=======
В целом, все платы, для которых имеется конфигурация по умолчанию в конфигурационных файлах каталога configs/, были в некоторой степени протестированы и могут считаться "рабочими". По факту многие из них используются в реальных производимых и продаваемых системах.
В случае возникновения проблем вы можете использовать
scripts/get_maintainer.pl < path>
... чтобы идентифицировать людей или компании, отвечающие за различные платы и подсистемы. Или просмотрите записи git log.
Где можно получить помощь:
==========================
При возникновении вопросов, проблем, или когда вы хотите что-то привнести в функционал U-Boot, отправьте сообщение в список рассылки U-Boot (mailing list < u-boot@lists.denx.de>). В списке рассылки также есть архив предыдущего трафика, так что пожалуйста перед тем как задавать вопросы пожалуйста просмотрите эту информацию / FAQ. Также см. https://lists.denx.de/pipermail/u-boot и https://marc.info/?l=u-boot
Где можно получить исходный код:
================================
Исходный код U-Boot находится в репозитории Git [1]:
Вы можете просматривать его онлайн по ссылке: https://source.denx.de/u-boot/u-boot .
Ссылки "Tags" на этой страничке позволят вам загрузить tarball-ы любой версии, которая вас заинтересует. Официальные релизы также доступны на файл-сервере 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] CPU
- расширен функционал:
* предоставлен расширенный интерфейс для Linux boot loader
* S-Record download
* network boot
* ATA disk / SCSI ... boot
- создан проект ARMBoot (https://sourceforge.net/projects/armboot)
- добавлены другие семейства CPU (начиная с ARM)
- создан проект U-Boot (https://sourceforge.net/projects/u-boot)
- текущая страничка проекта: https://www.denx.de/wiki/U-Boot
Имена и их интерпретация:
=========================
"Официальное" имя этого проекта "Das U-Boot". Словечко "U-Boot" следует использовать для написания всех текстов (документации, комментариев в файлах исходного кода и т. д..). Например:
This is the README file for the U-Boot project.
Имена файлов должны основываться на строке "u-boot". Например: include/asm-ppc/u-boot.h.
Имена переменных, констант препроцессора и т. п. должны основываться либо на строке "u_boot", либо на строке "U_BOOT". Например: U_BOOT_VERSION, u_boot_logo, IH_OS_U_BOOT, u_boot_hush_start.
Software Configuration:
=======================
Выбор архитектуры процессора и типа платы:
------------------------------------------
Для всех поддерживаемых плат есть готовые к использованию конфигурации по умолчанию. Для выбранной платы компиляция происходит запуском команды "make < имя_платы>_defconfig".
Пример компиляции для модуля TQM823L:
$ cd u-boot
$ make TQM823L_defconfig
Замечание: если вы обнаружили, что для вашей платы использовался определенный конфигурационный файл, но его теперь нет, то проверьте текст doc/README.scrapyard, где имеется список плат, которые больше не поддерживаются.
Sandbox Environment:
--------------------
U-Boot можно собрать для окружения "песочницы" (Sandbox Environment), т. е. как обычное приложение хоста Linux, с помощью платы 'sandbox'. Это позволяет разрабатывать фичи, не зависящие от конкретной платы или архитектуры, на собственной платформе. Песочница также используется для запуска некоторых тестов U-Boot.
Дополнительную информацию см. в doc/arch/sandbox/sandbox.rst.
Нужно сконфигурировать следующие опции:
- CPU Type: определите точно одну, например CONFIG_MPC85XX.
- Board Type: определите точно одну, например CONFIG_MPC8540ADS.
- 85xx CPU Options:
CONFIG_SYS_PPC64 Указывает, что ядро это 64-bit PowerPC реализация (реализует "64" категорию Power ISA). Это необходимо для соблюдения ePAPR, среди других возможных причин.
CONFIG_SYS_FSL_ERRATUM_A004510 Разрешает обход проблемы erratum 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 (optional) Определяет одну или две ревизии SoC (младшие 8 бит SVR), для которых должен быть применен обход проблемы A004510.
Остальная часть SVR либо не относится к решению о том, имеется ли erratum (например p2040 против p2041), либо подразумевается целью сборки (build target), которая контролирует, установлена ли CONFIG_SYS_FSL_ERRATUM_A004510.
Для дополнительной информации об этой ошибке кристалла (erratum) см. Freescale App Note 4493.
CFG_SYS_FSL_CORENET_SNOOPVEC_COREONLY Это значение для записи в CCSR смещению 0x18600, в соответствии с обходом проблемы кристалла A004510.
CONFIG_SYS_FSL_SINGLE_SOURCE_CLK Режим одного источника тактового сигнала (Single Source Clock), который имеется в некоторых кристаллах Freescale (FSL SoC). В этом режиме один дифференциальный тактовый сигнал используется для тактов sysclock, ddrclock и usbclock.
- Опции Generic CPU:
CONFIG_SYS_FSL_DDR Используемый драйвер Freescale DDR. Это тип контроллера DDR, который имеется в mpc83xx, mpc85xx, а также в некоторых ARM core SoC.
CFG_SYS_FSL_DDR_ADDR Freescale DDR memory-mapped register base.
CONFIG_SYS_FSL_IFC_CLK_DIV Определяет делитель platform clock (вход тактов контроллера IFC).
CONFIG_SYS_FSL_LBC_CLK_DIV Определяет делитель platform clock (вход тактов контроллера eLBC).
CFG_SYS_FSL_DDR_SDRAM_BASE_PHY Физический адрес с точки зрения контроллеров DDR. Это то же самое, что и CFG_SYS_DDR_SDRAM_BASE для всех Power SoC. Но это может быть другим для ARM SoC.
- Опции ARM:
CFG_SYS_EXCEPTION_VECTORS_HIGH Выберет векторы верхних исключений ядра ARM, например не очищает бит V регистра c1 в CP15.
COUNTER_FREQUENCY Источник частоты generic timer.
COUNTER_FREQUENCY_REAL Источник частоты generic timer, если реальные такты отличаются от COUNTER_FREQUENCY, и могут быть определены только run time.
- Linux Kernel Interface:
CONFIG_OF_LIBFDT Новые версии kernel ожидают настроек firmware, передаваемых с использованием flattened device trees (основываясь на концепциях open firmware).
CONFIG_OF_LIBFDT
* New libfdt-based support
* Добавлена команда "fdt"
* Команда bootm автоматически обновляет fdt
OF_TBCLK Частота timebase. Платы с QUICC Engines требуют OF_QE, установленной в адреса UCC MAC.
CONFIG_OF_IDE_FIXUP U-Boot может обнаружить, присутствует ли устройство IDE. Если нет, и активирована эта новая опция config, то U-Boot удалит узел ATA из DTS перед загрузкой Linux, так что драйвер Linux IDE не обращается к устройству и крашится. Это необходимо для buggy hardware (uc101), где нет pull down резистора, подключенного к сигналу IDE5V_DD7.
- Параметры vxWorks boot:
bootvx конструирует допустимый поток загрузки (bootline), мспользуя следующие переменные окружения: bootdev, bootfile, ipaddr, netmask, serverip, gatewayip, hostname, othbootargs. Это загрузит образ vxWorks, на который указывает bootfile.
Замечание: если определена переменная окружения "bootargs", то она переназначит умолчания, представленные непосредственно выше.
- Конфигурация кэша для ARM:
CFG_SYS_PL310_BASE физический базовый адрес пространства регистров контроллера PL310.
- Serial Ports:
CFG_PL011_CLOCK Если у вас UART порты Amba PrimeCell PL011, то установите эту переменную в значение частоты тактов UART.
CFG_PL01x_PORTS Если на вашей плате UART порты Amba PrimeCell PL010 или PL011, то определите это для списка базовых адресов каждого (поддерживаемого) порта UART. См. например include/configs/versatile.h
CONFIG_SERIAL_HW_FLOW_CONTROL Определите эту переменную для разрешения аппаратного управления потоком (hw flow control) в serial-драйвер. Драйвер drivers/serial/nsl16550.c использует в настоящий момент эту опцию.
- Удаление команд:
Если для загрузки не нужны команды, то вы можете их удалить запретом опции CONFIG_CMDLINE. В этом случае командная строка будет недоступна, и когда U-Boot захочет выполнить команду boot (при start-up), он будет вместо этого вызывать функцию board_run_command(). Это может значительно уменьшить размер образа для очень простых процедур загрузки.
- Поддержка регулярного выражения:
CONFIG_REGEX Если определена эта переменная, то U-Boot линкуется с библиотекой SLRE (Super Light Regular Expression), которая добавит поддержку regex для некоторых команд, например для "env grep" и "setexpr".
- Watchdog:
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 указывает список пар chip-ngpio, которые указывают драйверу PCA953X количество выводов, поддерживаемых определенным чипом.
Обратите внимание, что если устройство GPIO использует I2C, то интерфейс I2C также должен быть сконфигурирован. См. далее I2C Support.
- Трассировка I/O:
Когда выбрано CONFIG_IO_TRACE, U-Boot интерпретирует все доступы I/O, и может проверить их (checksum) или записать их список в память. Подробнее см. описание команды 'iotrace'. Это полезно для тестирования драйверов устройств, чтобы можно было убедиться, что драйвер ведет себя одинаково до и после изменения кода. В настоящее время поддерживается на sandbox и arm. Для поддержки вашей архитектуры добавьте '#include < iotrace.h>' в конец arch/< arch>/include/asm/io.h и проверьте компиляцию.
Ниже показан пример вывода команды 'iotrace stats'. Обратите внимание, что если был исчерпан буфер трассировки, то checksum все еще будет продолжать работу.
iotrace is enabled
Start: 10000000 (buffer start address)
Size: 00010000 (buffer size)
Offset: 00000120 (current buffer offset)
Output: 10000120 (start + offset)
Count: 00000018 (number of trace records)
CRC32: 9526fb66 (CRC32 of all trace records)
- Поддержка метки времени (timestamp):
Когда выбрано CONFIG_TIMESTAMP, метка времени (дата и время) образа будут выводиться командами образа наподобие bootm или iminfo. Эта опция автоматически разрешена, когда вы выбрали CONFIG_CMD_DATE.
- Поддерживаемые метки разделов (disklabels):
Ноль или большее количество следующего:
CONFIG_MAC_PARTITION Таблица разделов Apple MacOS.
CONFIG_ISO_PARTITION Таблица разделов ISO, используется на CDROM и т. п.
CONFIG_EFI_PARTITION Таблица разделов GPT, обычно когда применен EFI bootloader. Имейте в виду, что существует ограничение на размер раздела 2TB; см. disk/part_efi.c.
CONFIG_SCSI Вы также должны сконфигурировать поддержку как минимум одного раздела типа не MTD.
- Поддержка NETWORK (PCI):
CONFIG_E1000_SPI Код утилиты для прямого доступа к шине SPI на Intel 8257x. Это не приведет ни к чему полезному, если вы не установите как минимум одно из CONFIG_CMD_E1000 или CONFIG_E1000_SPI_GENERIC.
CONFIG_NATSEMI Поддержка для чипов National dp83815.
CONFIG_NS8382X Поддержка для гигабитных чипов National dp8382[01].
- Поддержка NETWORK (другие устройства):
CONFIG_CALXEDA_XGMAC Поддержка для устройства Calxeda XGMAC.
CONFIG_LAN91C96 Поддержка для чипов SMSC LAN91C96.
CONFIG_LAN91C96_USE_32_BIT Определите это для разрешения 32-битной адресации.
CFG_SYS_DAVINCI_EMAC_PHY_COUNT Определите это, если у вас больше трех PHY.
CONFIG_FTGMAC100 Поддержка для Faraday FTGMAC100 Gigabit SoC Ethernet
CONFIG_FTGMAC100_EGIGA Определите это для использования GE link update вместе с gigabit PHY. Определите это, если FTGMAC100 подключен к gigabit PHY. Если у вашей системы есть только 10/100 PHY, то это может не привести к неправильному поведению. Потому что PHY обычно возвратит timeout или бесполезные данные, когда опрашиваются регистры gigabit status и gigabit control. Это поведение не повлияет на корректность обновления скорости 10/100 link.
CONFIG_SH_ETHER Поддержка Renesas on-chip контроллера Ethernet.
CFG_SH_ETHER_USE_PORT Определяет количество используемых портов.
CFG_SH_ETHER_PHY_ADDR Определит адрес ETH PHY.
CFG_SH_ETHER_CACHE_WRITEBACK Если эта опция установлена, то драйвер разрешает cache flush.
- Поддержка TPM:
CONFIG_TPM Поддержка устройств TPM.
CONFIG_TPM_TIS_INFINEON Поддержка для шины Infineon i2c устройств TPM. В настоящий момент поддерживается только одно устройство на систему.
CONFIG_TPM_TIS_I2C_BURST_LIMITATION Определяет верхний предел количества байт в пакете (burst count bytes)
CONFIG_TPM_ST33ZP24 Поддержка для устройств STMicroelectronics TPM. Требует поддержки DM_TPM.
CONFIG_TPM_ST33ZP24_I2C Поддержка устройств STMicroelectronics ST33ZP24 I2C. Требует TPM_ST33ZP24 и I2C.
CONFIG_TPM_ST33ZP24_SPI Поддержка устройств STMicroelectronics ST33ZP24 SPI. Требует TPM_ST33ZP24 и SPI.
CONFIG_TPM_ATMEL_TWI Поддержка устройства Atmel TWI TPM. Требует поддержки I2C.
CONFIG_TPM_TIS_LPC Поддерживает generic parallel port устройств TPM. В настоящее время на систему поддерживается только одно устройство.
CONFIG_TPM Определите это для разрешения библиотеки поддержки TPM, которая предоставляет функциональные интерфейсы для некоторых команд TPM. Требует поддержки для устройства TPM.
CONFIG_TPM_AUTH_SESSIONS Определите это, чтобы разрешить авторизационные функции в библиотеке TPM. Требует CONFIG_TPM и CONFIG_SHA1.
- USB Support:
В настоящее время поддерживается только хост-контроллер UHCI (PIP405, MIP405); для их разрешения определите CONFIG_USB_UHCI. Определите CONFIG_USB_KEYBOARD, чтобы разрешить USB-клавиатуру, и определите CONFIG_USB_STORAGE, чтобы разрешить устройства USB-хранения. Замечание: поддерживаются USB Keyboard и USB Floppy drive (TEAC FD-05PUB).
CONFIG_USB_DWC2_REG_ADDR физический адрес CPU регистров DWC2 HW модуля.
- USB Device:
Задайте определения, показанные далее, если хотите использовать консоль USB. Как только firmware заново собрано из serial console, выдайте команду "setenv stdin usbtty; setenv stdout usbtty" и подключите ваш кабель USB. Unix-команда "dmesg" должна напечатать, что найдено новое устройство. Можно установить переменную окружения usbtty в gserial или cdc_acm, чтобы разрешить обнаружение вашего устройства для хоста USB как Linux gserial device или как Common Device Class Abstract Control Model serial device (CDC ACM). Если вы выбрали usbtty = gserial, то должны быть в состоянии выполнить энумерацию хоста Linux с помощью # modprobe usbserial vendor=0xVendorID product=0xProductID, иначе если используется cdc_acm, то просто установите переменную окружения usbtty для достаточности cdc_acm. Следующее может быть определено в YourBoardName.h.
Если у вас USB-IF с присвоенным VendorID, то вы можете захотеть определить свои специфичные для вендора значения в 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. Это *должен* быть genuine Vendor ID, чтобы избежать нарушения USB namespace - CONFIG_USBD_VENDORID 0xFFFF.
CONFIG_USBD_PRODUCTID Определите это как уникальный Product ID для вашего устройства - CONFIG_USBD_PRODUCTID 0xFFFF.
- Поддержка ULPI Layer:
ULPI (UTMI Low Pin (count) Interface) PHY поддерживаются через generic ULPI layer. Этот generic layer обращается к ULPI PHY через platform viewport, так что вам нужно разрешить как generic layer, так и viewport. В настоящий момент поддерживается только viewport на основе Chipidea/ARC. Чтобы разрешить поддержку ULPI layer, определите CONFIG_USB_ULPI и CONFIG_USB_ULPI_VIEWPORTв вашем файле конфигурации платы. Если ваш ULPI PHY требует другой опорной тактовой частоты, отличающейся от стандартной 24 МГц, то вы должны определить CFG_ULPI_REF_CLK на соответствующее значение в Гц.
- Поддержка MMC:
CONFIG_SH_MMCIF Поддержка для Renesas on-chip MMCIF контроллера.
CONFIG_SH_MMCIF_ADDR Определит базовый адрес регистров MMCIF.
CONFIG_SH_MMCIF_CLK Определит тактовую частоту для MMCIF.
- Поддержка класса USB Device Firmware Update (DFU):
CONFIG_DFU_OVER_USB Разрешит USB-часть DFU USB class.
CONFIG_DFU_NAND Разрешит поддержку доступа к устройствам NAND через DFU.
CONFIG_DFU_RAM Разрешит поддержку доступа к RAM через DFU. Замечание: спецификация DFU относится к использованию non-volatile памяти, однако позволяет использование вне спецификации - здесь это использование RAM, что поможет в основном разработчику.
CONFIG_SYS_DFU_DATA_BUF_SIZE Передача DFU использует буфер перед записью данных в устройство хранения (raw storage device). Сконфигурируйте это для размера буфера (в байтах). Размен этого буфера также конфигурируется через переменную окружения "dfu_bufsiz".
CONFIG_SYS_DFU_MAX_FILE_SIZE Когда обновляются файлы вместо raw storage device, мы используем статический буфер, чтобы копировать файл в него, и затем записать буфер, как только получен файл целиком. Определите это в максимальный filesize (в байтах) для буфера. Если не определено, то используется умолчание 4 MiB.
DFU_DEFAULT_POLL_TIMEOUT Таймаут опроса [мс] это таймаут, с которым устройство может отправлять данные хосту. Хост должен ждать в течение этого таймаута перед передачей устройству запроса DFU_GET_STATUS.
DFU_MANIFEST_POLL_TIMEOUT Таймаут опроса [мс], с каким устройство посылает данные хосту, когда входит в состояние dfuMANIFEST. Хост ждет в течение этого таймаута перед тем, как снова отправить запрос USB в устройство.
- Поддержка клавиатуры:
См. Kconfig для доступных драйверов клавиатуры.
- MII/PHY support:
CONFIG_PHY_CLOCK_FREQ (ppc4xx) Тактовая частота шины MII.
CONFIG_PHY_CMD_DELAY (ppc4xx) Некоторым PHY наподобие Intel LXT971A требуется дополнительная задержка после команды, вставленная перед тем, как может быть прочитан регистр статуса MII.
- BOOTP Recovery Mode:
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-битного ID. Сервер будет копировать ID из запросов клиента в ответы, и U-Boot будет это использовать, чтобы определить, его ли это пакет ответа. Некоторые сервера перед раздачей адреса проверят, что он не используется в сети (обычно с помощью ARP ping), и поэтому ответ занимает до нескольких сотен миллисекунд. На время, необходимое для возврата ответа клиенту, также может влиять загруженность сети. Если это время слишком велико, то U-Boot будет повторно передавать запросы. Чтобы все еще принимались ранее посланные ответы на эти повторные запросы, U-Boot-клиент BOOTP сохраняет небольшой кэш этих ID. Опция CFG_BOOTP_ID_CACHE_SIZE управляет размером этого кэша. По умолчанию хранятся ID до четырех не выполненных запросов. Увеличение этого значения позволит для U-Boot принимать предложения из BOOTP-клиента в сетях с необычно высокой латентностью.
- DHCP Advanced Options:
- Link-local IP address negotiation: Согласование с другими клиентами локальной сети адреса, не требующего явной настройки. Это особенно полезно, если DHCP-сервер не может гарантированно существовать во всех окружениях, где должно работать устройство. Для дополнительной информации см. doc/README.link-local.
- MAC-адрес из переменных окружения
FDT_SEQ_MACADDR_FROM_ENV Исправляет device tree с MAC-адресами, извлеченными последовательно из переменных окружения. Этот конфигурационный элемент работает в предположении, что не используемый узел Ethernet в device-tree либо отсутствует, либо его состояние помечено как "disabled".
- Опции CDP:
CONFIG_CDP_DEVICE_ID Идентификатор устройства, используемый в кадрах CDP trigger.
CONFIG_CDP_DEVICE_ID_PREFIX Строка из 2 символов, предшествующая 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-битное целое число, содержащее энергопотребление устройства в единицах 0.1 милливатт.
CONFIG_CDP_APPLIANCE_VLAN_TYPE Байт, содержащий ID для VLAN.
- Status LED:
CONFIG_LED_STATUS Некоторые конфигурации позволяют показать текущее состояние с помощью LED. Например, LED будет быстро мигать во время работы кода U-Boot, прекратить мигание как только получен ответ на запрос BOOTP, и начать медленно мигать, когда заработало Linux kernel (поддерживается status LED driver в ядре Linux). Определение CONFIG_LED_STATUS разрешает эту фичу в U-Boot.
Дополнительные опции:
CONFIG_LED_STATUS_GPIO Status LED может быть подключен к выводу GPIO. В таких случаях драйвер gpio_led может использоваться как реализация status LED backend. Определите CONFIG_LED_STATUS_GPIO, чтобы включить драйвер gpio_led в бинарник U-Boot.
CFG_GPIO_LED_INVERTED_TABLE Некоторые LED-ы, подключенные к GPIO, могут иметь противоположную полярность, при которой значение GPIO high соответствует состоянию LED off, а значение GPIO low соответствует состоянию LED on. В таких случаях может быть определена CFG_GPIO_LED_INVERTED_TABLE со списком GPIO LED-ов, у которых полярность инверсная.
- Поддержка I2C:
CFG_SYS_NUM_I2C_BUSES Содержит количество шин I2C, которые вы хотите использовать.
CFG_SYS_I2C_BUSES Содержит список шин, которые вы хотите использовать. Пример:
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 port 1
шина 2 на адаптере 0 с PCA9547 на адресе 0x70 port 2
шина 3 на адаптере 0 с PCA9547 на адресе 0x70 port 3
шина 4 на адаптере 0 с PCA9547 на адресе 0x70 port 4
шина 5 на адаптере 0 с PCA9547 на адресе 0x70 port 5
шина 6 на адаптере 1 без мультиплексора
шина 7 на адаптере 1 с PCA9544 на адресе 0x72 port 1
шина 8 на адаптере 1 с PCA9544 на адресе 0x72 port 2
Если на вашей плате нет i2c мультиплексоров, то опустите это определение.
- Поддержка Legacy 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 в состояние активности (с остановленным уровнем выхода). Если у сигнала данных открытый сток, то это определение может быть null.
Например:
#define I2C_ACTIVE (immr->im_cpm.cp_pbdir |= PB_SDA)
I2C_TRISTATE Код, необходимый для перевода линии данных I2C в третье состояние (неактивно). Если у сигнала данных открытый сток, то это определение может быть null.
Например:
#define I2C_TRISTATE (immr->im_cpm.cp_pbdir &= ~PB_SDA)
I2C_READ Код, который возвращает true, если на линии данных I2C уровень лог. 1, и false если уровень лог. 0.
Например:
#define I2C_READ ((immr->im_cpm.cp_pbdat & PB_SDA) != 0)
I2C_SDA(bit) Если bit == true, то установит линию данных I2C в лог. 1. Если false, то очистит её (установит в лог. 0).
Например:
#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 == true, то установит линию тактов I2C в лог. 1, иначе в лог. 0.
Например:
#define I2C_SCL(bit) \
if(bit) immr->im_cpm.cp_pbdat |= PB_SCL; \
else immr->im_cpm.cp_pbdat &= ~PB_SCL
I2C_DELAY Это задержка, которая вставляется 4 раза на период такта, чем управляется скорость передачи данных. Таким образом, скорость данных будет 1 / (I2C_DELAY * 4). Часто определяется примерно так:
#define I2C_DELAY udelay(2)
CONFIG_SOFT_I2C_GPIO_SCL
CONFIG_SOFT_I2C_GPIO_SDA Если ваша архитектура (arch) поддерживает GPIO framework (asm/gpio.h), то вы можете альтернативно определить два порта GPIO, которые используются как SCL и SDA. Любой из предыдущих макросов I2C_xxx будут иметь умолчания, основанные на GPIO, назначенные им соответствующим образом.
Вы должны определить это в значения GPIO, задаваемое непосредственно generic-функциям GPIO.
CFG_SYS_I2C_NOPROBES Эта опция задает список устройств I2C, которые будут пропущены, когда выдается команда i2c probe.
Например:
#define CFG_SYS_I2C_NOPROBES {0x50,0x68}
пропустит адреса 0x50 и 0x68 на плате с одной шиной I2C.
CONFIG_SOFT_I2C_READ_REPEATED_START Это определение заставит функцию i2c_read() в драйвере soft_i2c driver выполнить I2C repeated start между записью указателя адреса и чтением данных. Если это определение опущено, то поведение по умолчанию будет использовать последовательность stop-start. Большинство устройств I2C могут использовать любой метод, но некоторые требуют только одного из них.
- Поддержка SPI:
CONFIG_SPI Разрешит драйвер SPI (пока что тестировалось только с SPI EEPROM, также экземпляр работает с Crystal A/D и D/A-ами на плате SACSng).
CFG_SYS_SPI_MXC_WAIT Таймаут для ожидания завершения транзакции SPI. Умолчание: (CONFIG_SYS_HZ/100) /* 10 мс */
- Поддержка FPGA:
CONFIG_FPGA Разрешит FPGA subsystem.
CONFIG_FPGA_< vendor> Разрешит поддержку определенных вендоров чипов (ALTERA, XILINX).
CONFIG_FPGA_< family> Разрешит поддержку семейства FPGA (SPARTAN2, SPARTAN3, VIRTEX2, CYCLONE2, ACEX1K, ACEX).
CONFIG_SYS_FPGA_CHECK_BUSY Разрешит проверки, что интерфейс конфигурации FPGA занят функцией конфигурации FPGA. Эта опция потребует написания специальной функции платы или устройства.
CFG_FPGA_DELAY Если определено, то предоставляется функция задержки в драйвере конфигурации FPGA.
CFG_SYS_FPGA_CHECK_ERROR Проверка на ошибки конфигурации во время загрузки прошивки FPGA (bitfile loading). Например, произошел abort во время конфигурации Virtex II, если линия INIT_B перешла в лог. 0 (что показывает ошибку CRC).
CFG_SYS_FPGA_WAIT_INIT Максимальное время для ожидания de-assert линии INIT_B после того, как произошел de-assert PROB_B во время последовательности конфигурации Virtex II FPGA. По умолчанию 500 мс.
CFG_SYS_FPGA_WAIT_BUSY Максимальное время ожидания BUSY de-assert в время конфигурации Virtex II FPGA. По умолчанию 5 мс.
CFG_SYS_FPGA_WAIT_CONFIG Время ожидания после конфигурации FPGA. По умолчанию 200 мс.
- Vendor Parameter Protection:
U-Boot рассматривает переменные окружения "serial#" (Board Serial Number) и "ethaddr" (Ethernet Address) как параметры, которые устанавливаются однократно вендором / производителем платы, и защищает эти переменные от случайной модификации пользователем. Будучи однократно установленными, эти переменные становятся read-only, и попытки их записи или удаления отклоняются. Вы можете поменять это поведение:
Если определено CONFIG_ENV_OVERWRITE в вашем файле config, то защита от записи параметров вендора полностью запрещена. Любой может поменять или удалить эти параметры.
Того же результата можно достичь более гибким способом для любой переменной путем конфигурирования типа доступа, чтобы позволить менять эти переменные в переменной ".flags", или определить CFG_ENV_FLAGS_LIST_STATIC.
- Protected RAM:
CFG_PRAM Определите эту переменную, чтобы разрешить резервирование "protected RAM", т. е. RAM, которая не перезаписывается кодом U-Boot. Определение CFG_PRAM сохранит количество kB, которое вы хотите зарезервировать для pRAM. Вы можете перезаписать это значение по умолчанию путем определения переменной окружения "pram" в число kB, которое вы хотите резервировать. Имейте в виду что структура board info все еще будет показывать полный объем RAM. Если было зарезервирована pRAM, то автоматически будет определена переменная окружения "mem", чтобы содержать объем оставшейся RAM в форме, в форме, которая может быть передана в качестве аргумента загрузки в Linux, например:
setenv bootargs ... mem=\${mem}
saveenv
Таким способом вы можете сказать Linux не использовать эту память, что приведет к тому, что содержимое этой памяти будет сохраняться между перезагрузками.
*WARNING* Если конфигурация вашей платы использует автоматическое определение размера RAM, то вы должны убедиться, что этот тест памяти не деструктивен. До настоящего момента следующие конфигурации известны как "pRAM-clean":
IVMS8, IVML24, SPD8xx,
HERMES, IP860, RPXlite, LWMON,
FLAGADM
- Error Recovery:
Замечание: в текущей реализации пространство локальных переменных и пространство глобальных переменных окружения разделены. Локальные переменные это те, которые вы определяете простым вводом 'name=value'. Чтобы после этого обратиться к локальной переменной, вы должны записать '$name' или '${name}'; чтобы выполнить содержимое переменной, непосредственно введите '$name' в приглашении командной строки.
Для работы с глобальными переменными окружения используются setenv/printenv. Чтобы запустить команду, сохраненную в такой переменной, вам нужно использовать команду run и имя переменной, при этом перед именем переменной не нужно вставлять символ '$'. Для сохранения команд и специальных символов в переменной используйте двойные кавычки, окружающие весь текст переменной, вместо обратной косой черты перед точкой с запятой и специальными символами.
- Default Environment:
CFG_EXTRA_ENV_SETTINGS Определите это для содержания любого количества null-terminated строк (пар переменная=значение), которые будут частью окружения по умолчанию, скомпилированного в boot-образ.
Например, поместите что-нибудь подобное в свой файл config платы:
#define CFG_EXTRA_ENV_SETTINGS \
"myvar1=value1\0" \
"myvar2=value2\0"
Warning: этот метод основан на знании внутреннего формата, как окружение сохраняется кодом U-Boot. Это НЕ официальный, экспортированный интерфейс! Хотя вряд ли этот формат скоро изменится, гарантии тоже нет. Вам лучше знать, что здесь делаете.
Замечание: не рекомендуется увлекаться чрезмерным использованием окружения по умолчанию. Обязательно сначала проверьте другие способы настройки окружения такие как команда "source", или команда boot.
CONFIG_DELAY_ENVIRONMENT Нормально окружение загружается, когда плата инициализируется, что обеспечивает ее доступность для U-Boot. В результате окружение недоступно до тех пор, пока она не будет явно загружена позже кодом U-Boot. Вместо этого при использовании CONFIG_OF_CONTROL это контролируется значением /config/load-environment.
- Автоматическое обновление ПО через сервер TFTP:
CONFIG_UPDATE_TFTP
CONFIG_UPDATE_TFTP_CNT_MAX
CONFIG_UPDATE_TFTP_MSEC_MAX Эта опция разрешает и фичу автоматического обновления и управляет ей; более подробное описание см. в doc/README.update.
- Поддержка MTD (команда mtdparts, поддержка UBI):
CONFIG_MTD_UBI_WL_THRESHOLD Этот параметр определяет максимальное отличие между самым большим значением счетчика стираний и самым малым значением счетчика стираний (erase counter value) для eraseblocks устройств UBI. Когда это порог превышен, UBI запускает процедуру уравнивания износа flash (wear leveling) путем перемещения данных из eraseblock-ов с низким erase counter в eraseblock-и с высоким erase counter.
Значение по умолчанию должно быть нормальным для чипов SLC NAND flash, чипов NOR flash и других типов flash, у которых количество перезаписей (eraseblock life-cycle) составляет 100000 или больше. Однако в случае чипов MLC NAND flash, у которых обычно eraseblock life-cycle меньше 10000, порог должен быть уменьшен до 128 или 256, хотя это число необязательно должно быть степенью числа 2.
default: 4096
CONFIG_MTD_UBI_BEB_LIMIT Эта опция указывает максимум плохих физических eraseblock UBI, ожидаемое на устройстве MTD (на 1024 eraseblock-ов). Если базовая flash не допускает плохих eraseblock-ов (например NOR flash), то это значение игнорируется.
Даташиты NAND часто указывают минимум и максимум NVM (Number of Valid Blocks) для надежной работы flash в течение её времени жизни (flash endurance lifetime). Тогда максимальное ожидаемое количество bad eraseblock на 1024 eraseblock-ов может быть вычислено как "1024 * (1 - MinNVB / MaxNVB)", что дает 20 для большинства моделей NAND (MaxNVB в основном общий счетчик eraseblock-ов на чипе).
Другими словами, если это значение равно 20, то UBI попытается зарезервировать около 1.9% физических eraseblock-ов для обработки плохих блоков. И это будет 1.9% eraseblock-ов на всем чипе NAND, а не только на присоединенном MTD-разделе UBI. Это означает, что если у вас flash-чип NAND, допускающий максимум 40 bad eraseblock-ов, и он разделен на два MTD-раздела одинакового размера, то UBI зарезервирует 40 eraseblock-ов при подключении раздела.
default: 20
CONFIG_MTD_UBI_FASTMAP Fastmap это механизм, который позволяет подключать устройсвто UBI за почти постоянное время. Вместо сканирования всего устройства MTD ему только нужно найти контрольную точку (которая называется fastmap) на устройстве. On-flash fastmap содержит всю информацию, необходимую для подключения устройства. Использование fastmap имеет смысл только для больших устройств, когда подключение методом сканирования занимает много времени. UBI не устанавливает fastmap автоматически на старых образах, однако вы можете установить UBI параметр CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT в 1, если хотите это использовать. Имейте в виду, что образы, где разрешен fastmap, по-прежнему можно использовать с реализациями UBI без поддержки fastmap. На обычных устройствах flash вся информация fastmap целиком помещается в один PEB. UBI будет резервировать PEB-ы для хранения двух fastmap.
CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT Установите этот параметр, чтобы автоматически разрешить fastmap на образах без fastmap.
default: 0
CONFIG_MTD_UBI_FM_DEBUG Разрешает UBI fastmap debug.
default: 0
- SPL framework:
CONFIG_SPL Разрешает глобальную сборку SPL.
CONFIG_SPL_PANIC_ON_RAW_IMAGE Когда это определено, SPL будет вызывать panic(), если загруженный образ не имеет подписи. Это определение полезно, когда код, который загружает образы в SPL, не может гарантировать, что будут перехвачены все ошибки чтения. Примером является драйвер LPC32XX MLC NAND, который будет считать, что полностью нечитаемый блок NAND является плохим, и поэтому его следует тихо пропускать.
CONFIG_SPL_DISPLAY_PRINT Для ARM разрешает опциональную функцию печати больше информации о работающей системе.
CONFIG_SPL_MPC83XX_WAIT_FOR_NAND Установите это для NAND SPL на целях компиляции PPC mpc83xx, так что start.S ждет, пока загрузится остальная часть SPL перед продолжением (hardware начнет выполняться после загрузки первой страницы, а не всего 4K).
CONFIG_SPL_UBI Поддержка для lightweight 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
CFG_SYS_NAND_ECCSIZE
CFG_SYS_NAND_ECCBYTES Определяет размер и поведение NAND, которое SPL использует для чтения U-Boot.
CFG_SYS_NAND_U_BOOT_DST Место в памяти, куда загружается U-Boot.
CFG_SYS_NAND_U_BOOT_SIZE Размер образа для загрузки.
CFG_SYS_NAND_U_BOOT_START Точка входа в загруженный образ, куда надо передать управление.
CONFIG_SPL_RAM_DEVICE Поддерживает запуск образа, который уже присутствует в RAM, в бинарнике SPL.
CONFIG_SPL_FIT_PRINT Печать информации об образе FIT добавляет в SPL некоторый код. Так что это нормально запрещено в SPL. Используйте эту опцию, чтобы снова разрешить эту фичу. Это повлияет на вывод команды bootm, когда загружается образ FIT.
- Поддержка прерываний (PPC):
Существуют общие interrupt_init() и timer_interrupt() для всех архитектур (PPC arch). Функция interrupt_init() вызовет interrupt_init_cpu() для специфической инициализации CPU. Функция interrupt_init_cpu() должна установить decrementer_count в подходящее значение. Если CPU сбрасывает decrementer автоматически после прерывания (ppc4xx), он должен установить decrementer_count в 0. Функция timer_interrupt() вызовет timer_interrupt_cpu() с обработкой, специфичной для CPU. Если у платы есть watchdog / status_led / other_activity_monitor, то это работает автоматически из общего timer_interrupt().
Настройки инициализации платы:
------------------------------
Во время инициализации u-boot вызовет несколько специфических для платы функций, чтобы удовлетворялись специальные требования платы, например настройка выводов перед инициализацией драйверов. Чтобы разрешить эти callback-функции, должны быть определены следующие макросы. В настоящее время это отражает специфику архитектуры, так что проверьте код arch/your_architecture/lib/board.c, обычно находящийся в board_init_f() и board_init_r().
CONFIG_BOARD_EARLY_INIT_F Вызывает board_early_init_f().
CONFIG_BOARD_EARLY_INIT_R Вызывает board_early_init_r().
CONFIG_BOARD_LATE_INIT Вызывает board_late_init().
Настройки конфигурации:
-----------------------
CONFIG_SYS_LONGHELP Определяется, когда вы хотите подключить более подробные сообщения help; закомментируйте это, когда у вас не очень много памяти.
CFG_SYS_HELP_CMD_WIDTH Определяется, когда вы хотите поменять ширину команд по умолчанию, перечисленную в выводе команды help.
CONFIG_SYS_PROMPT Это то, что U-Boot печатает в консоль для обозначения приглашения ввода пользователя (prompt user input).
CFG_SYS_BAUDRATE_TABLE Перечислит допустимые настройки baudrate для этой платы.
CFG_SYS_MEM_RESERVE_SECURE Сейчас реализовано только для ARMv8. Если это определено, то размер CFG_SYS_MEM_RESERVE_SECURE вычитается из общего RAM, и не будет сообщаться для OS. Эта память может использоваться как защищенная (secure memory). Переменная gd->arch.secure_ram используется для отслеживания места расположения. В системах, где RAM не 0, или RAM поделена на банки, эта переменная должна заново вычисляться для получения адреса.
CFG_SYS_SDRAM_BASE Физический начальный адрес SDRAM. Здесь _должно_ быть значение 0.
CFG_SYS_FLASH_BASE Физический начальный адрес памяти Flash.
CONFIG_SYS_MALLOC_LEN Размер DRAM, зарезервированной для malloc().
CFG_SYS_BOOTMAPSZ Максимальный размер памяти, отображаемый кодом запуска (startup code) ядра Linux (Linux kernel); все данные, которые должны обрабатываться ядром Linux (bd_info, boot arguments, FDT blob если это используется) должны не превышать этот лимит, если только не определена переменная окружения "bootm_low", и она не нулевая. В таких случаях все данные для Linux kernel должны быть между "bootm_low" и "bootm_low" + CFG_SYS_BOOTMAPSZ. Переменная окружения "bootm_mapsize" поменяет значение CFG_SYS_BOOTMAPSZ. Если CFG_SYS_BOOTMAPSZ не определена, то вместо этого будет использовано значение в "bootm_size".
CONFIG_SYS_BOOT_GET_CMDLINE Разрешает выделение и сохранение kernel cmdline в области между "bootm_low" и "bootm_low" + BOOTMAPSZ.
CONFIG_SYS_BOOT_GET_KBD Разрешает выделение и сохранение kernel-копии bd_info в области между "bootm_low" и "bootm_low" + BOOTMAPSZ.
CONFIG_SYS_FLASH_PROTECTION Если это определено, то используется аппаратная защита секторов flash вместо программной защиты U-Boot.
CONFIG_SYS_FLASH_CFI Определите, если драйвер flash использует дополнительные элементы в общей структуре flash для сохранения геометрии flash.
CONFIG_FLASH_CFI_DRIVER Эта опция также разрешает сборку драйвера cfi_flash в директории drivers.
CONFIG_FLASH_CFI_MTD Эта опция разрешает сборку драйвера cfi_mtd в директории drivers. Драйвер экспортирует CFI flash на слой MTD.
CONFIG_SYS_FLASH_USE_BUFFER_WRITE Использует буферизацию записи в flash.
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]
Типы атрибутов (type_attribute):
s - String (default)
d - Decimal
x - Hexadecimal
b - Boolean ([1yYtT|0nNfF])
i - IP address
m - MAC address
Доступ к атрибутам (access_attribute):
a - Any (default)
r - Read-only
o - Write-once
c - Change-default
CONFIG_ENV_FLAGS_LIST_DEFAULT Определите это для списка (строк), чтобы задать переменную окружения ".flags" в окружении по умолчанию или встроенном окружении.
CFG_ENV_FLAGS_LIST_STATIC Определите это для списка (строк), чтобы задать проверку, которая должна быть осуществлена, если элемент не найден в переменной окружения ".flags". Чтобы переназначить установку в статическом списке, просто добавьте элемент с таким же именем переменной в переменную ".flags".
Если определена опция CONFIG_REGEX, то показанное выше variable_name вычисляется как регулярное выражение. Это позволяет нескольким переменным определить одинаковые флаги без явного перечисления их для каждой переменной.
Следующие определения касаются размещения данных окружения и управления ими (область переменных); в целом поддерживаются следующие конфигурации:
БУДЬТЕ ОСТОРОЖНЫ! Первый доступ к окружению происходит довольно рано в инициализации U-Boot (когда мы пытаемся получить настройку baudrate для консоли). У вас *ДОЛЖНО* быть отображение вашей области NVRAM, иначе U-Boot зависнет.
Обратите внимание, что даже с NVRAM мы все еще используем копию окружения в RAM: мы могли бы работать напрямую с NVRAM, но мы хотим, чтобы настройки всегда оставались нетронутыми кроме случая их явного сохранения командой "saveenv".
БУДЬТЕ ОСТОРОЖНЫ! В некоторых специальных случаях локальное устройство не может использовать команду "saveenv". Например, локальное устройство будет получать окружение, сохраненное в remote NOR flash через линк SRIO или PCIE, но не может делать операции erase, write этой NOR flash через интерфейс SRIO или PCIE.
CONFIG_NAND_ENV_DST Определяет адрес в RAM, куда код nand_spl должен копировать окружение. Если используется резервное окружение, то это будет копироваться в CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE.
Обратите внимание, что окружение read-only до тех пор, пока monitor не будет перемещен в RAM, и не будет создана RAM копия окружения; кроме того, когда используется EEPROM, вам придется применять env_get_f() до этого момента, чтобы прочитать переменные окружения.
Окружение защищено контрольной суммой CRC32. До момента, когда monitor перемещен в RAM, как результат получится неправильная CRC при вашей работе со скомпилированным окружением по умолчанию - *silently*!!! [Это необходимо, потому что первая переменная, которая нам нужна, это настройка "baudrate" для консоли - если у нас будет bad CRC, то у нас еще нет устройства, на которое можно было бы пожаловаться.]
Замечание: как только monitor был перемещен, тогда он начнет жаловаться, если используется окружение по умолчанию; новая CRC вычисляется как только вы используете команду "saveenv" для сохранения корректного окружения.
CONFIG_SYS_FAULT_MII_ADDR Адрес MII блока PHY для проверки состояния линка Ethernet.
CONFIG_DISPLAY_BOARDINFO Отобразит информацию о плате, на которой выполняется U-Boot, при его запуске. Для этого вызывается функция платы checkboard().
CONFIG_DISPLAY_BOARDINFO_LATE Подобна предыдущей опции, но отобразит эту информацию позже, как только заработает stdio, и вывод происходит на LCD, если он присутствует.
Низкоуровневые (относящиеся к оборудованию) опции конфигурации:
---------------------------------------------------------------
CONFIG_SYS_CACHELINE_SIZE Cache Line Size CPU.
CONFIG_SYS_CCSRBAR_DEFAULT По умолчанию (power-on reset) физический адрес CCSR на Freescale PowerPC SOC-чипах.
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 Физический адрес внутренней памяти (Internal Memory). НЕ МЕНЯЙТЕ, если не имеете представления, что делаете! (11-4) [только системы MPC8xx]
CFG_SYS_INIT_RAM_ADDR Начальный адрес области памяти, которая может использоваться для начальных данных и стека; имейте в виду, что это должна быть записываемая память, которая работает без специальной инициализации, например здесь НЕЛЬЗЯ использовать обычную RAM, которая становится доступной только после программирования контроллера памяти и выполнения определенных последовательностей инициализации.
U-Boot использует следующие типы памяти: MPC8xx: IMMR (внутренняя память CPU).
CONFIG_SYS_SCCR Регистр управления системной частотой и сбросом (System Clock and reset Control Register (15-27)).
CONFIG_SYS_OR_TIMING_SDRAM Тайминги SDRAM.
CONFIG_SYS_SRIOn_MEM_VIRT Виртуальный адрес области памяти SRIO port 'n'.
CONFIG_SYS_SRIOn_MEM_PHYxS Физический адрес региона памяти SRIO port 'n'.
CONFIG_SYS_SRIOn_MEM_SIZE Размер региона памяти SRIO port '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-ов. Обратите внимание, что это глобальная опция, у нас не может быть один FEC в стандартном режиме MII, и другой в режиме RMII.
CONFIG_CRC32_VERIFY Добавляет опцию проверки для команды crc32. Синтаксис:
=> crc32 -v < address> < count> < crc32>
Здесь address/count показывает область памяти и crc32, которая должна быть корректной для указанной области.
CONFIG_LOOPW Добавляет команду памяти "loopw". Эта опция имеет эффект только если глобально активированы команды памяти (CONFIG_CMD_MEMORY).
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).
CONFIG_XPL_BUILD Устанавливается, когда текущая компиляция предназначена для артефакта, который окажется в одной из сборок "xPL", т. е. SPL, TPL или VPL. Код, для которого требуется поведение, зависящее от фазы, может проверить это или (где это возможно), вместо этого использовать xpl_phase().
Обратите внимание, что CONFIG_XPL_BUILD "определяется*, когда определено CONFIG_TPL_BUILD либо CONFIG_VPL_BUILD. Это может быть нелогично и, возможно, должно быть изменено.
CONFIG_TPL_BUILD Устанавливается, когда текущая компиляция предназначена для артефакта, который окажется в сборке TPL (в отличие от собственно SPL, VPL или U-Boot). Код, для которого требуется поведение, зависящее от фазы, может проверить это или (где это возможно), вместо этого использовать xpl_phase().
CONFIG_VPL_BUILD Устанавливается, когда текущая компиляция предназначена для артефакта, который окажется в сборке VPL (в отличие от собственно SPL, TPL или U-Boot). Код, для которого требуется поведение, зависящее от фазы, может проверить это или (где это возможно) вместо этого использовать xpl_phase ().
CONFIG_ARCH_MAP_SYSMEM Обычно U-Boot (и в частности команда md) использует эффективный адрес. Поэтому нет необходимости рассматривать адрес U-Boot как виртуальные адреса, которые нужно преобразовать в физические адреса. Однако для sandbox это требуется, потому что sandbox поддерживает свой маленький буфер оперативной памяти, который содержит всю адресуемую память. Эта опция приводит к тому, что некоторые обращения к памяти отображаются через вызовы map_sysmem() / unmap_sysmem().
CONFIG_X86_RESET_VECTOR Если определено, то подключается код x86 reset vector. Это не нужно, когда U-Boot работает из Coreboot.
Freescale QE/FMAN Firmware Support:
-----------------------------------
Оба Freescale QUICCEngine (QE) и Frame Manager (FMAN) поддерживают загрузку "firmware", закодированного в двоичном формате QE firmware. Это firmware часто нуждается в загрузке через U-Boot booting, так что используются макросы для идентификации устройства хранения (NOR flash, SPI, и т. д.) и адреса внутри этого устройства.
CONFIG_SYS_FMAN_FW_ADDR Адрес устройства хранения, где хранится микрокод FMAN. Интерпретация этого адреса зависит также от того, какой указан макрос CONFIG_SYS_QE_FMAN_FW_IN_xxx.
CONFIG_SYS_QE_FW_ADDR Адрес устройства хранения, где хранится микрокод QE. Интерпретация этого адреса зависит также от того, какой указан макрос CONFIG_SYS_QE_FMAN_FW_IN_xxx.
CONFIG_SYS_QE_FMAN_FW_LENGTH Максимально возможный размер firmware. В двоичном формате firmware есть поле, которое указывает актуальный размер firmware, однако может быть нельзя прочитать какую-либо часть firmware, если сначала не будет выделено некоторое локальное хранилище всего firmware целиком.
CONFIG_SYS_QE_FMAN_FW_IN_NOR Указывает, что QE/FMAN firmware находится в NOR flash, отображаемой как обычная адресуемая память через LBC. CONFIG_SYS_FMAN_FW_ADDR это виртуальный адрес в NOR flash.
CONFIG_SYS_QE_FMAN_FW_IN_NAND Указывает, что QE/FMAN firmware находится в NAND flash. CONFIG_SYS_FMAN_FW_ADDR это смещение внутри NAND flash.
CONFIG_SYS_QE_FMAN_FW_IN_MMC Указывает, что QE/FMAN firmware находится на primary-устройстве SD/MMC. CONFIG_SYS_FMAN_FW_ADDR это байтовое смещение на этом устройстве.
CONFIG_SYS_QE_FMAN_FW_IN_REMOTE Указывает, что QE/FMAN firmware находится в remote (master) memory space. CONFIG_SYS_FMAN_FW_ADDR это виртуальный адрес, который может быть отображен из подчиненного TLB->slave, LAW->slave SRIO или PCIE outbound window->master inbound window->master LAW->ucode адреса в область памяти master.
Freescale Layerscape Management Complex Firmware Support:
---------------------------------------------------------
Freescale Layerscape Management Complex (MC) поддерживает загрузку "firmware". Это firmware часто нуждается в загрузке во время U-Boot booting, так что используются макросы для идентификации устройства хранения (NOR flash, SPI, и т. д.) и адреса внутри этого устройства.
CONFIG_FSL_MC_ENET Разрешает MC-драйвер для Layerscape SoC-чипов.
Freescale Layerscape Debug Server Support:
-------------------------------------------
Freescale Layerscape Debug Server Support поддерживает загрузку "Debug Server firmware" и срабатывание SP boot-rom. Это firmware часто нуждается в загрузке во время U-Boot booting.
CONFIG_SYS_MC_RSV_MEM_ALIGN Определяет выравнивание зарезервированной памяти, необходимой MC.
Сборка ПО:
==========
Сборка кода U-Boot была протестирована в нескольких традиционных окружениях и многих различных окружениях кросс-компиляции. Конечно, авторы не могут поддерживать все возможно существующие версии тулчейнов кросс-разработки для всех (и возможно устаревших) версий. В случае проблем с тулчейном рекомендуется использовать ELDK (см. https://www.denx.de/wiki/DULG/ELDK), который экстенсивно используется для сборки и тестирования U-Boot.
Если вы не используете native окружение, то предполагается, что в настроенных путях поиска находятся инструментарий кросс-компиляции GNU. В таком случае необходимо задать для вашего шелла переменную окружения CROSS_COMPILE. Обратите внимание, что не требуется вносить изменение в Makefile или любой другой файл исходного кода. Например, при использовании ELDK на 4xx CPU, введите следующее:
$ CROSS_COMPILE=ppc_4xx-
$ export CROSS_COMPILE
U-Boot разработан таким образом, чтобы упростить сборку. После установки исходного кода вы должны сконфигурировать U-Boot для одного из определенных типов платы. Это делается командой:
.. где "NAME_defconfig" это это имя одной из существующих конфигураций; см. configs/*_defconfig для поддерживаемых имен.
Замечание: для некоторых плат могут существовать специальные имена; проверьте, доступна ли дополнительная информация от вендора платы; например, системы TQM823L доступны без (вариант standard) поддержки LCD и с поддержкой LCD. Вы можете выбрать такие дополнительные "фичи", когда выбираете конфигурацию, например:
- сконфигурирует проект для чистого TQM823L, т. е. без поддержки LCD.
$ make TQM823L_LCD_defconfig
- сконфигурирует TQM823L с консолью U-Boot на LCD.
и т. п.
И наконец, выполните команду "make all", и в результате вы должны получить некоторые рабочие образы U-Boot, готовые для загрузки / установке на вашей системе:
- "u-boot.bin" - двоичный код без дополнительной информации (raw binary image).
- "u-boot" - образ в двоичном формате ELF.
- "u-boot.srec" - образ в формате Motorola S-Record.
Компилятору можно передать специфичные для пользователя опции CPPFLAGS, AFLAGS и CFLAGS путем установки соответствующих переменных окружения KCPPFLAGS, KAFLAGS и KCFLAGS.
Например, чтобы обработать все предупреждения (warnings) как ошибки:
Имейте в виду, что Makefiles предполагают, что вы используете GNU make, так например на NetBSD вам может понадобиться использовать "gmake" вместо традиционного "make".
Если ваша плата не перечислена среди поддерживаемых, то нужно портировать U-Boot на вашу аппаратную платформу. Для этого выполните следующие шаги:
1. Создайте новую директорию, где будет находиться специфический для вашей платы код. Добавьте туда любые необходимые файлы. В вашей директории платы должен быть как минимум файл Makefile и файл "< board>.c".
2. Создайте новый конфигурационный файл include/configs/< board>.h для вашей платы.
3. Если вы портируете U-Boot на новый CPU, то также создайте новую директорию для хранения кода, специфичного для этого CPU. Добавьте туда любые необходимые файлы.
4. Запустите команду "make < board>_defconfig" с вашим новым именем платы.
5. Выполните команду "make", и вы должны получить рабочий файл u-boot.srec для инсталляции на вашей целевой системе.
6. Отлаживайте и решайте любые проблемы, которые могут возникнуть.
Тестирование модификаций U-Boot Modifications, портов на новое железо, и т. п.:
===============================================================================
Если у вас модифицированные исходники U-Boot (например добавлена новая плата или поддержка для новых устройств, новый CPU, и т. д.), то ожидается, что вы предоставите отзыв для других разработчиков. Отзыв обычно имеет вид "патча", например изменение контекста (context diff) по отношению к определенной (последней официальной или последней в репозитории git) версии исходников U-Boot.
Однако перед тем, как предоставить такой патч, пожалуйста проверьте, что ваша модификация не нарушает существующий код. Как минимум убедитесь, что *ВСЕ* поддерживаемые платы компилируются АБСОЛЮТНО БЕЗ любых предупреждений компилятора. Чтобы это сделать, просто запустите скрипт buildman (tools/buildman/buildman), который сконфигурирует и соберет U-Boot для ВСЕХ поддерживаемых систем. Предупреждаем, что это займет время. См. файл buildman README, или запустите 'buildman -H' для его документации.
См. также далее "U-Boot Porting Guide".
Обзор команд Monitor-а:
=======================
go - запустит приложение по адресу 'addr'
run - запустит команды в переменной окружения
bootm - boot образа приложения из памяти
bootp - boot образа через сеть, используя протокол BootP/TFTP
bootz - boot zImage из памяти
tftpboot - boot образа через сеть по протоколу TFTP, и переменные
окружения "ipaddr" и "serverip" (и иногда "gatewayip")
tftpput - выгрузит файл через сеть по протоколу TFTP
rarpboot - boot образа через сеть по протоколу RARP/TFTP
diskboot - boot через IDE devicebootd - boot default, например
run 'bootcmd'
loads - загрузка файла S-Record через последовательное соединение
loadb - загрузка двоичного файла через последовательное соединение
(kermit mode)
loadm - загрузка binary blob из адреса источника по адресу
назначения
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
iminfo - печать информации заголовка для образа приложения
coninfo - печать устройств консоли и соответствующей информации
ide - подсистема IDE
loop - бесконечный цикл по диапазону адресов
loopw - бесконечный цикл записи по диапазону адресов
mtest - простой тест RAM
icache - разрешение или запрет кэша инструкций
dcache - разрешение или запрет кэша данных
reset - выполнение сброса (RESET) для CPU
echo - echo args в консоль
version - печать версии монитора
help - печать встроенной подсказки
? - псевдоним для 'help'
Команды Monitor-а - подробное описание:
=======================================
TODO.
Сейчас просто введите "help < command>".
Примечание по резервированным интерфейсам Ethernet:
===================================================
На некоторых платах есть резервирование интерфейсов Ethernet; U-Boot поддерживает такие конфигурации и может автоматически выбирать "рабочий" интерфейс в случае необходимости. Назначение MAC работает следующим образом:
Сетевые интерфейсы нумеруются eth0, eth1, eth2, ... Соответствующие MAC-адреса могут быть сохранены в окружении как "ethaddr" (=>eth0), "eth1addr" (=>eth1), "eth2addr", ...
Если сетевой интерфейс сохраняет некоторый допустимый MAC-адрес (например в SROM), то он используется как адрес по умолчанию, если НЕТ соответствующей настройки в окружении; если соответствующая переменная окружения установлена, то она отменяет настройки в карте; это значит:
- Если в SROM допустимый MAC-адрес, и нет настроенного адреса в окружении, то используется адрес из SROM.
- Если в SROM нет допустимого адреса, и есть определение в окружении, то используется значение из переменной окружения.
- Если в обоих местах есть MAC-адрес, в SROM, и в окружении, и они одинаковые, то используется этот MAC-адрес.
- Если в обоих местах есть MAC-адрес, в SROM, и в окружении, но они разные, то используется значение из переменной окружения, и печатается предупреждение.
- Если нет определенного MAC-адреса ни в SROM, ни в окружении, то возникает ошибка. Если определено CONFIG_NET_RANDOM_ETHADDR, то в этом случа используется случайный, присвоенный локально MAC-адрес.
Если драйверы Ethernet реализуют функцию 'write_hwaddr', то допустимые MAC-адреса будут запрограммированы в аппаратуру как часть процесса инициализации. Это может быть пропущено путем установки подходящей переменной окружения 'ethmacskip'. Соглашение об именовании следующее: "ethmacskip" (=>eth0), "eth1macskip" (=>eth1), и т. д.
Форматы образа:
===============
U-Boot может выполнить booting (и произвести другие дополнительные операции) для образов в двух форматах:
New uImage format (FIT)
-----------------------
Гибкий и мощный формат, основанный на Flattened Image Tree -- FIT (по аналогии с Flattened Device Tree). Позволяет использовать образы с несколькими компонентами (несколько kernel, ramdisk, и т. д.), где содержимое защищено 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).
* Целевая архитектура CPU (предложено для Alpha, ARM, Intel x86, IA64, MIPS, Nios II, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit; сейчас поддерживаются: ARM, Intel x86, MIPS, Nios II, PowerPC).
* Тип компрессии (uncompressed, gzip, bzip2).
* Адрес загрузки (Load Address).
* Точка входа (Entry Point).
* Имя образа (Image Name).
* Метка времени образа (Image Timestamp).
Заголовок промаркирован специальным идентификатором (Magic Number), и обе части образа - заголовок и данные - защищены от повреждения контрольными суммами CRC32.
Поддержка Linux:
================
Хотя U-Boot должен легко поддерживать любую OS или одиночное приложение, основной акцент в его разработке все равно был сделан на Linux.
U-Boot включает в себя много фич, которые до сих пор были частью некоторого специального кода "boot loader" внутри Linux kernel. Также любые "initrd" используемые образы больше не являются частью одного большого образа Linux; вместо этого kernel и "initrd" это отдельные образы. Эта реализация служит нескольким целям:
- Эти же функции можно использовать для других OS или отдельных приложений (например: использование сжатых образом для уменьшения занимаемого места в памяти Flash).
- Становится намного проще портировать новые версии ядра Linux, потому что U-Boot реализует множество низкоуровневых, аппаратно зависимых вещей.
- Один и тот же образ Linux kernel может теперь использоваться с разными образами "initrd"; конечно, это также означает, что на одном и том же "initrd" можно запускать разные образы kernel. Это упрощает тестирование (вам не нужно делать сборку нового образа Linux "zImage.initrd", когда просто меняете файл в своем "initrd"). Также обновление ПО "по месту" (field-upgrade) становится проще.
Linux HOWTO
===========
Портирование Linux на системы с U-Boot:
---------------------------------------
U-Boot не сможет вас уберечь от необходимости проведения всех нужных модификаций для конфигурирования драйверов устройств Linux, чтобы она работала с вашим целевым железом (у разработчиков не было намерения предоставить полный интерфейс виртуальной машины для Linux :-).
Однако вы можете проигнорировать ВЕСЬ код загрузчика (boot loader code в arch/powerpc/mbxboot).
Просто убедитесь, что ваш специфичный для машины файл заголовка (например include/asm-ppc/tqm8xx.h) подключает то же самое определение структуры информации платы (Board Information), как разработчики определили в include/asm-< arch>/u-boot.h, и проверьте, что ваше определение IMAP_ADDR использует то же самое значение, как в вашей U-Boot конфигурации в CONFIG_SYS_IMMR.
Обратите внимание, что у U-Boot теперь унифицированная модель драйверов (unified driver model). Если вы добавляете новый драйвер, то включите его в модель драйвера. Если uclass недоступен, то рекомендуется его создать. См. doc/driver-model.
Конфигурирование Linux kernel:
------------------------------
Для U-Boot нет специальных требований. Убедитесь, что у вас есть какое-то root устройство (initial ramdisk, NFS) для своей целевой системы.
Сборка образа Linux:
--------------------
С U-Boot не используются "нормальные" цели сборки наподобие "zImage" или "bzImage". Если вы используете свежие исходники kernel, то будет существовать новая цель сборки "uImage", которая автоматически соберет образ, который может использовать U-Boot. Большинство более старых ядер также поддерживают "pImage" target, которая была введена для предшествующего проекта PPCBoot, и использует на 100% совместимый формат.
Пример:
$ make TQM850L_defconfig
$ make oldconfig
$ make dep
$ make uImage
Цель сборки "uImage" использует специальный инструмент (в 'tools/mkimage'), чтобы инкапсулировать сжатый образ Linux kernel с информацией заголовка, CRC32 и т. п. для использования вместе с U-Boot. Вот что мы делаем:
* собираем стандартный образ ядра "vmlinux" (в двоичном формате ELF).
* конвертируем ядро в двоичный сырой образ:
$ ${CROSS_COMPILE}-objcopy -O binary \
-R .note -R .comment \
-S vmlinux 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" может также применяться для создания образов ramdisk-а, чтобы и использовать их с U-Boot, либо отдельно от образа Linux kernel, либо скомбинированными в один файл. Утилита "mkimage" инкапсулирует образы с 64-байтным заголовком, где содержится информация о целевой архитектуре, операционной системе, тип образа, метод компрессии, точки входа, метка времени, контрольные суммы CRC32, и т. п.
"mkimage" может быть вызвана двумя способами: для проверки существующих образов и печати информации заголовка, или для сборки новых образов.
В первой форме (с опцией "-l") mkimage перечислит информацию, содержащуюся в заголовке существующего образа U-Boot; это включает проверку контрольной суммы:
-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' (hex)
-e ==> установит точку входа в 'ep' (hex)
-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
Image Name: 2.4.4 kernel for TQM850L
Created: Wed Jul 19 02:34:59 2000
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327.86 kB = 0.32 MB
Load Address: 0x00000000
Entry Point: 0x00000000
Для проверки содержимого образа (или проверка на наличие повреждений):
-> tools/mkimage -l examples/uImage.TQM850L
Image Name: 2.4.4 kernel for TQM850L
Created: Wed Jul 19 02:34:59 2000
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327.86 kB = 0.32 MB
Load Address: 0x00000000
Entry Point: 0x00000000
ЗАМЕЧАНИЕ: для встраиваемых систем, у которых критично время загрузки, вы можете пожертвовать памятью и установить вместо этого UNCOMPRESSED образ: это потребует больше места в Flash, однако загрузка произойдет намного быстрее, потому что декомпрессия не понадобится:
-> gunzip /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/powerpc/coffboot/vmlinux.gz
-> tools/mkimage -n '2.4.4 kernel for TQM850L' \
-A ppc -O linux -T kernel -C none -a 0 -e 0 \
-d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/powerpc/coffboot/vmlinux \
examples/uImage.TQM850L-uncompressed
Image Name: 2.4.4 kernel for TQM850L
Created: Wed Jul 19 02:34:59 2000
Image Type: PowerPC Linux Kernel Image (uncompressed)
Data Size: 792160 Bytes = 773.59 kB = 0.76 MB
Load Address: 0x00000000
Entry Point: 0x00000000
Подобным образом вы можете собрать образы U-Boot из файла 'ramdisk.image.gz', когда ваше ядро предназначено для использования начального ramdisk:
-> tools/mkimage -n 'Simple Ramdisk Image' \
-A ppc -O linux -T ramdisk -C gzip \
-d /LinuxPPC/images/SIMPLE-ramdisk.image.gz examples/simple-initrd
Image Name: Simple Ramdisk Image
Created: Wed Jan 12 14:01:50 2000
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 566530 Bytes = 553.25 kB = 0.54 MB
Load Address: 0x00000000
Entry Point: 0x00000000
Утилита "dumpimage" может использоваться для дизассемблирования или получения списка содержимого образов, которые были собраны mkimage. Подробности см. в выводе подсказки dumpimage (-h).
Инсталляция образа Linux:
-------------------------
Для загрузки образа U-Boot через последовательный (консоль) интерфейс, вы должны преобразовать образ в формат S-Record:
$ objcopy -I binary -O srec examples/image examples/image.srec
Утилита 'objcopy' не понимает информацию в заголовке образа U-Boot, так что результирующий файл S-Record будет относительно адреса 0x00000000. Для его загрузки по указанному адресу вы должны задать целевой адрес как параметр 'offset' в команде 'loads'.
Пример: установка образа по адресу 0x40100000 (который на TQM8xxL соответствует первому банку Flash):
=> erase 40100000 401FFFFF
.......... done
Erased 8 sectors
=> loads 40100000
## Ready for S-Record download ...
~>examples/image.srec
1 2 3 4 5 6 7 8 9 10 11 12 13 ...
...
15989 15990 15991 15992
[file transfer complete]
[connected]
## Start Addr = 0x00000000
Вы можете проверить, насколько была успешной загрузка, с помощью команды 'iminfo'; это включает верификацию контрольной суммы, так что вы можете быть уверены, что никакого повреждения данных не произошло:
=> imi 40100000
## Checking Image at 40100000 ...
Image Name: 2.2.13 for initrd on TQM850L
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327 kB = 0 MB
Load Address: 00000000
Entry Point: 0000000c
Verifying Checksum ... OK
Boot Linux:
-----------
Команда "bootm" используется для загрузки приложения, которое сохранено в памяти (RAM или Flash). В случае образа Linux kernel, содержимое переменной окружения "bootargs" передается ядру в качестве параметров. Вы можете проверить и модифицировать эту переменную, используя команды printenv и setenv:
=> printenv bootargs
bootargs=root=/dev/ram
=> setenv bootargs root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
=> printenv bootargs
bootargs=root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
=> bootm 40020000
## Booting Linux kernel at 40020000 ...
Image Name: 2.2.13 for NFS on TQM850L
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 381681 Bytes = 372 kB = 0 MB
Load Address: 00000000
Entry Point: 0000000c
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.2.13 (wd@denx.local.net) (gcc version 2.95.2 19991024
(release)) #1 Wed Jul 19 02:35:17 MEST 2000
Boot arguments: root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
time_init: decrementer frequency = 187500000/60
Calibrating delay loop... 49.77 BogoMIPS
Memory: 15208k available (700k kernel code, 444k data, 32k init) [c0000000,c1000000]
...
Если вы хотите выполнить boot Linux kernel с начальным RAM disk, то вы передаете адреса памяти как для kernel, так и для образа initrd (формат PPBCOOT!) в команду "bootm":
=> imi 40100000 40200000
## Checking Image at 40100000 ...
Image Name: 2.2.13 for initrd on TQM850L
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327 kB = 0 MB
Load Address: 00000000
Entry Point: 0000000c
Verifying Checksum ... OK
## Checking Image at 40200000 ...
Image Name: Simple Ramdisk Image
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 566530 Bytes = 553 kB = 0 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
=> bootm 40100000 40200000
## Booting Linux kernel at 40100000 ...
Image Name: 2.2.13 for initrd on TQM850L
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327 kB = 0 MB
Load Address: 00000000
Entry Point: 0000000c
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 40200000 ...
Image Name: Simple Ramdisk Image
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 566530 Bytes = 553 kB = 0 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk ... OK
Linux version 2.2.13 (wd@denx.local.net) (gcc version 2.95.2 19991024
(release)) #1 Wed Jul 19 02:32:08 MEST 2000
Boot arguments: root=/dev/ram
time_init: decrementer frequency = 187500000/60
Calibrating delay loop... 49.77 BogoMIPS
...
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
bash#
Boot Linux и передача FDT:
--------------------------
Сначала U-Boot должен быть скомпилирован с подходящими определениями. См. выше секцию "Linux Kernel Interface" для дополнительной информации. Ниже показан пример, как запускать ядро и передавать обновленное плоское дерево устройств (flat device tree, FDT):
=> 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 поддерживает следующие типы образа:
"Standalone Program" непосредственно запускаемая программа в окружении, предоставленном U-Boot; подразумевается, что (если программа ведет себя хорошо) вы можете продолжить работу в U-Boot после выхода из Standalone Program.
"OS Kernel Image" обычно образ некой Embedded OS, которая полностью берет на себя управление. Обычно такие программы устанавливают свой собственный набор обработчиков исключений (exception handlers), драйверов устройств, настраивают MMU, и т. д. - это означает, что вы не сможете обратно войти в U-Boot без сброса CPU.
"RAMDisk Image" более или менее просто блоки данных и их параметры (address, size), передаваемые в OS kernel, которое запускается.
"Multi-File Image" содержит несколько образов, обычно образ OS (Linux) kernel и один или нескользку образов данных наподобие RAMDisk. Эта конструкция полезна, нарпример когда вы хотите загружаться по сети с помощью BOOTP и т. д., где boot-сервер предоставляет просто один файл образа, но вы например хотите получить OS kernel и образ RAMDisk. "Multi-File Image" начинается со списка размеров образов, каждый размер (в байтах) задается как uint32_t с сетевым порядком байт. Этот список завершается (uint32_t)0. Сразу за завершающим 0 идут образы, друг за другом, все они выровнены на слово uint32_t (байтовый размер кажого образа округляется вверх так, чтобы он нацело делился на 4).
"Firmware Image" двоичный образ, где содержится firmware (наподобие U-Boot или FPGA image), который обынчо будет запрограммирован в память flash.
"Script file" последовательность команд, которая будет выполнена интерпретатором команд U-Boot; эта фича особенно полезна, когда вы конфигурируете U-Boot для использования real shell (hush) в качестве интерпретатора команд.
Boot Linux zImage:
------------------
На некоторых платформах возможна загузка Linux zImage. Это делается командой bootz. Синтаксис bootz такой же, как синтаксис команды bootm.
Имейте в виду, что определение CONFIG_SUPPORT_RAW_INITRD дает возможность порльзователю предоставить kernel с образами raw initrd. Синтаксис немного другой, адрес initrd должен быть дополнен его размером, в следующем формате: < initrd addres>:< initrd size>.
HOWTO для standalone приложений:
================================
Одна из фич U-Boot - вы можете динамически загружать и запускать "standalone" приложения, которые могут использовать некоторые ресурсы U-Boot наподобие функций I/O консоли или обработчиков прерываний.
В исходники U-Boot включены два простых примера:
"Hello World" Demo:
-------------------
Файл examples/hello_world.c содержит маленькую программу приложения "Hello World" Demo; она автоматически компилируется, когда вы делаете сборку U-Boot. Оно сконфигурировано для запуска по адресу 0x00040004, так что вы можете поиграть с ним примерно так:
=> loads
## Ready for S-Record download ...
~>examples/hello_world.srec
1 2 3 4 5 6 7 8 9 10 11 ...
[file transfer complete]
[connected]
## Start Addr = 0x00040004
=> go 40004 Hello World! This is a test.
## Starting application at 0x00040004 ...
Hello World
argc = 7
argv[0] = "40004"
argv[1] = "Hello"
argv[2] = "World!"
argv[3] = "This"
argv[4] = "is"
argv[5] = "a"
argv[6] = "test."
argv[7] = "< NULL>"
Hit any key to exit ...
## Application terminated, rc = 0x0
Другой пример, который демонстрирует, как регистрировать обработчик прерывания CPM с кодом U-Boot, можно найти в файле examples/timer.c. Здесь таймер CPM установлен для генерации прерывания каждую секунду. Обработчик прерывания тривиальный, он просто выводит на печать символ '.', однако это просто демонстрационная программа. Приложение может управляться следующими ключами:
? - печать текущих значений регистров CPM Timer
b - разрешить прерывания и запустить таймер
e - остановить таймер и запретить прерывания
q - выход из приложения
=> loads
## Ready for S-Record download ...
~>examples/timer.srec
1 2 3 4 5 6 7 8 9 10 11 ...
[file transfer complete]
[connected]
## Start Addr = 0x00040004
=> go 40004
## Starting application at 0x00040004 ...
TIMERS=0xfff00980
Using timer 1
tgcr @ 0xfff00980, tmr @ 0xfff00990, trr @ 0xfff00994, tcr @ 0xfff00998,
tcn @ 0xfff0099c, ter @ 0xfff009b0
Hit 'b':
[q, b, e, ?] Set interval 1000000 us
Enabling timer
Hit '?':
[q, b, e, ?] ........
tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0xef6, ter=0x0
Hit '?':
[q, b, e, ?] .
tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x2ad4, ter=0x0
Hit '?':
[q, 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, и упростить его портирование на пользовательское оборудование.
Initial Stack, Global Data:
---------------------------
Реализация U-Boot усложнена тем фактом, что он запускается из ROM (память flash), обычно без доступа к системной RAM (потому что еще не был инициализирован контроллер памяти). Это значит, что у все нет записываемых сегментов Data или BSS, и BSS не была инициализирована нулями. Чтобы получить рабочее C-окружение, нам как минимум нужно выделить минимальный стек. Варианты реализации для этого зависят и ограничиваются используемым CPU: некоторые модели CPU предоставляют встроенную память (наподобие области IMMR на процессорах MPC8xx и MPC826x), в других кэш данных можетбыть заблокирована (неправильно) используемая память, и т. д.
Chris Hallinan хорошо описал эти проблемы в U-Boot mailing list:
Subject: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)?
From: "Chris Hallinan" < clh@net1plus.com>
Date: Mon, 10 Feb 2003 16:43:46 -0500 (22:43 MET)
...
Поправьте меня люди, если я не прав: использование DCACHE в качестве начальной RAM для стека и т. п. не требует физического сохранения RAM кэша. Хитрость в том, что кэш используется как временный запас необходимой памяти перед настройкой контроллера SDRAM. Полное объяснение выходит за рамки этого списка, однако вы можете посмотреть, как это работает, изучив архитектуру и работу кэша в руководстве вашего процессора.
OCM это встроенная в процессор память (On Chip Memory), которая как я надеюсь 4K на 405GP. Другой вариант для разработчика системы, чтобы использовать в качестве начальной области stack/RAM перед тем, как станет доступной SDRAM. Один из этих вариантов должен для вас подойти. Использование CS 4 должно быть успешным, если ваши разработчики платы не использовали это для чего-нибудь, что вас расстроит при начальной загрузке! Его часто не используют.
CFG_SYS_INIT_RAM_ADDR должен быть где-нибудь, что не помешает конструкции ваших процессора, платы, системы. Значение по умолчанию в walnut.h, которое вы найдете в любом свежем дистрибутиве u-boot, должно для вас подойти. Я бы установил значение больше, чем ваш модуль SDRAM. Если у вас SDRAM модуль 64MB, установите больше 4000000. Просто убедитесь, что ваша плата не содержит ресурсов, которые должны отвечать на этот адрес! Соответствующий код в start.S существует уже давно, и он должен работать как есть, если вы правильно настроите конфигурацию.
-Chris Hallinan
DS4.COM, Inc.
Важно помнить следующее, поскольку это оказывает некоторое влияние на код C для процедур инициализации:
* Инициализируемые глобальные данные (data segment) read-only. Не пытайтесь записывать в них.
* Вообще не используйте любые инициализируемые глобальные данные (или неявно инициализированные нулями, как в случае сегмента BSS) - это не определено, инициализация производится позже (когда происходит перенастройка места RAM в адресном пространстве).
* Размер стека очень ограничен. Избегайте больших буферов данных или чего-нибудь подобного.
Наличие только стека в качестве ограничения на записываемую память означает, что мы не можем использовать обычные глобальные данные для обмена информации между кодом. Однако оказалось, что можно значительно упростить реализацию U-Boot путем создания глобальной структуры данных (gd_t), доступной для всех функций. Мы могли бы передать указатель на эти данные в качестве аргумента во _все_ функции, однако это привело бы к раздуванию кода. Вместо этого разработчики использовали фичу компилятора GCC (Global Register Variables) для совместно используемых данных: указатель на глобальные данные (gd) был помещен в регистр, который зарезервирован для этой цели.
При выборе регистра разработчики приняли во внимание ограничения соответствующей спецификации (E)ABI для текущей архитектуры, а также реализацию GCC.
Для PowerPC используются следующие специфические регистры:
R1: указатель стека
R2: зарезервировано для системного использования
R3-R4: передача значения параметра и возврата
R5-R10: передача параметра
R13: указатель на небольшую область данных
R30: GOT-указатель
R31: frame pointer
(U-Boot также использует R12 в качестве внутреннего GOT-указателя. r12 это volatile регистр, так что r12 нужно сбрасывать, когда происходит переход туда и обратно между asm и C) ==> U-Boot будет использовать R2 для хранения указателя на глобальные данные.
Замечание: на PPC мы могли бы использовать статический инициализатор (поскольку адрес глобальной структуры данных известен во время компиляции), однако оказалось, что резервирование регистра приводит к несколько меньшему коду - хотя экономия кода не такая уж и большая (в среднем для всех плат 752 байт для всего образа U-Boot, 624 text + 127 data).
На ARM используются следующие регистры:
R0: аргумент и результат функции
R1-R3: аргумент функции
R9: зависит от платформы
R10: лимит стека (используется только если разрешена проверка стека)
R11: аргумент (frame) указателя
R12: временное рабочее пространство
R13: указатель стека
R14: link register
R15: program counter
==> U-Boot будет использовать R9 для хранения указателя на глобальные данные.
Замечание: на ARM поддерживаются только перенастройка R_ARM_RELATIVE.
На Nios II интерфейс ABI документирован: https://www.altera.com/literature/hb/nios2/n2cpu_nii51016.pdf.
==> U-Boot будет использовать gp для хранения указателя на глобальные данные.
Замечание: на Nios II мы предоставили опцию "-G0" для gcc, и не используем gp для доступа к малым секциям данных, так что gp освобождается.
На RISC-V используются следующие регистры:
x0: аппаратный ноль (zero)
x1: адрес возврата (ra)
x2: stack pointer (sp)
x3: global pointer (gp)
x4: thread pointer (tp)
x5: link register (t0)
x8: frame pointer (fp)
x10-x11: аргументы / значение возврата (a0-1)
x12-x17: аргументы (a2-7)
x28-31: временные значения (t3-6)
pc: program counter (pc)
==> U-Boot будет использовать gp для хранения указателя на глобальные данные.
Инициализация системы:
----------------------
В конфигурации сброса U-Boot стартует на точке входа сброса (на большинстве систем PowerPC это адрес 0x00000100). Поскольку конфигурация сброса для CS0# это зеркало встроенной памяти Flash. Чтобы иметь возможность перенастроить карту памяти, U-Boot затем переходит по своему адресу линковки. Чтобы можно было реализовать код инициализации на C, настраивается (небольшой!) начальный стек во внутренней Dual Ported RAM (в случае CPU, которые предоставляют такую функцию), или в заблокированной части кэша данных. После этого U-Boot инициализирует ядро CPU, кэши и SIU.
Далее все (потенциально) доступные банки отображаются с использованием предварительного сопоставления (preliminary mapping). Например, мы помещаем их на границы 512 MB (кратные 0x20000000: SDRAM на 0x00000000 и 0x20000000, Flash на 0x40000000 и 0x60000000, SRAM на 0x80000000). Затем UPM A программируется для доступа к SDRAM. С использованием временной конфигурации запускается простой тест памяти, который определяет размеры банков SDRAM. Если имеется больше одного банка SDRAM, и банки имеют разный размер, то самый большой банк отображается первым. Для банков одинакового размера первым отображается первый банк (CS2#). Первое отображение всегда осуществляется по адресу 0x00000000, с любыми дополнительными банками, идущими сразу за ним, чтобы получилась непрерывная память, начинающаяся с адреса 0.
Затем monitor инсталлирует сам себя в верхнюю часть области SDRAM, и выделяет память для malloc() и глобальных данных Board Info; также код вектора исключения копируется в нижние страницы RAM, и настраивается конечный вариант стека.
Только после этого переразмещения вы получаете нормальное окружение C; до этого момента вы ограничены несколькими факторами, в основном по той причине, что код работает в ROM, а также потому, что код приходится перемещать на новый адрес в RAM.
Содействие
==========
Проекты U-Boot зависят от вклада сообщества пользователей. Если вы тоже хотите принять участие, то ознакомьтесь с разделом General на сайте https://docs.u-boot.org/en/latest/develop/index.html, где разработчики описывают стандарты кодирования и процесс передачи патчей.
[Ссылки]
1. U-Boot.
2. Загрузчик U-Boot.
3. Загрузчики Blackfin.
4. Загрузка процессоров TI, создание загрузочной флешки SD.
5. Процесс загрузки TI CPU. |
