| Загрузка процессоров TI, создание загрузочной флешки SD |
|
| Добавил(а) microsin | ||||||||||||||||||||||||||
|
В этой статье описывается последовательность загрузки (boot sequence) OMAP3 EVM (EValuation Module, оценочная плата разработчика TI). Это перевод документации [1]. [Основная последовательность загрузки (система Linux)] Последовательность загрузки осуществляется в следующем порядке [7]: 1. Boot ROM При включении питания CPU OMAP3 (OMAP это технология TI, означает Open Multimedia Application Platform - открытая платформа мультимедийных приложений, подробности см. в Википедии) начинает загрузку с выполнения внутреннего кода Boot ROM. Этот код фиксированно установлен в CPU на этапе производства, и никак не может быть изменен. Boot ROM опрашивает состояние выводов конфигурации загрузки (boot configuration pins, SW4 на OMAP3 EVM), что укажет ему, где должен находиться первый внешний загрузчик. Возможен выбор вариантов NAND, UART и SD/MMC Card. Затем управление передается в этот внешний загрузчик, который называется x-loader. Приложение x-loader, включенное в Linux PSP, предоставляется TI, и может быть изменено конечным пользователем. Приложение x-loader передает управление в загрузчик u-boot. U-boot это тоже загрузчик, и в этом случае он считается внешним загрузчиком второго уровня. U-boot это приложение, которое передает управление системе Linux. Главная задача u-boot - получить откуда-то код ядра (Linux kernel) и предоставить ядру информацию о местонахождении файловой системы Linux. U-boot может быть сконфигурирован для получения ядра из NAND, SD/MMC Card, UART или Ethernet (через TFTP). U-boot может также указать место корневой файловой системы (root filesystem) в памяти NAND (jffs2), SRAM (ramdisk), SD/MMC card (раздел ext3) или файловая система может быть смонтирована через сетевой протокол IP (NFS). Затем U-boot загружает Linux kernel. Linux kernel монтирует корневую файловую систему (Linux root filesystem). [Загрузка TI SDK] OMAP3 EVM, который включает TI SDK, поставляется с картой SD. Эта карта отформатирована и на ней созданы разделы таким образом, что вся система загружается с этой карты. Здесь есть загружаемый раздел FAT (bootable FAT partition), который содержит x-loader (MLO), u-boot (файл u-boot.bin) и Linux kernel (uImage). Здесь также есть отдельный раздел ext3, где содержится корневая файловая система (Linux root filesystem). Карта Linux SD, предоставляемая с платами Sitara AMx EVM, может быть повторно создана с помощью Sitara Linux SDK. Здесь описывается процесс создания карты SD, которая может быть загружена всем необходимым для запуска системы Linux на Sitara EVM. ВАЖНОЕ ЗАМЕЧАНИЕ: внимательно прочитайте эту инструкцию и поймите её указания перед тем, как запускать любой из описанных здесь скриптов. [Сколько потребуется разделов на карте SD] AM35x EVM или AM37 EVM. Эти EVM используют 3 раздела. На карте будет маленький (примерно 70 мегабайт) загружаемый DOS-раздел для бинарников системы (x-loader, u-boot, uImage), и раздел ext3 (приблизительно 1 гигабайт) для корневой файловой системы (Linux root file system), и еще один раздел ext3 для исполняемого файла инсталлятора Linux и исходного кода SDK. Третий раздел займет все оставшееся пространство карты SD поэтому если у карты объем 2 гигабайта, то третий раздел получит размер около 1 гигабайта. Соответственно если карта размером 4 гигабайта, то третий раздел будет размером около 3 гигабайт.
AM180x EVM или AM1810 EVM. Эти EVM используют 2 раздела. Здесь находится альтернативный скрипт, который создаст на карте 2 раздела, только раздел загрузки и раздел файловой системы. Эти разделы - все что нужно для для загрузки системы с карты SD. Третий раздел опционален. ВНИМАНИЕ: этот процесс запускает форматирование и создание разделов на носителе. Пользователю следует тщательно проверить имена устройств, передаваемых скрипту, используемому в этом процессе. Иначе есть возможность отформатировать и уничтожить файловую систему хоста, где происходит форматирование. Предполагаемое оборудование: • Машина хоста Linux с доступными портами USB для подключения карт-ридера SD (также подойдет виртуальная машина). Необходимое ПО: • Системные бинарники Linux (x-loader, u-boot, uImage). [Как создать на SD-карте 3 раздела] Следующие процедуры относятся к процессорам TI Sitara: AM35x и AM37x. 1. Подготовка скрипта. Создайте файл на хосте Linux с именем mk3PartSDCard. Скопируйте в него содержимое показанного ниже скрипта, и сохраните файл. Этот скрипт создает 3 раздела, далее будет также описан скрипт, создающий 2 раздела. #! /bin/sh # mk3PartSDCard.sh v0.3 # Licensed under terms of GPLv2 DRIVE=$1 dd if=/dev/zero of=$DRIVE bs=1024 count=1024 SIZE=`fdisk -l $DRIVE | grep Disk | awk '{print $5}'`
echo DISK SIZE - $SIZE bytes CYLINDERS=`echo $SIZE/255/63/512 | bc` sfdisk -D -H 255 -S 63 -C $CYLINDERS $DRIVE << EOF ,9,0x0C,* 10,115,,- 126,,,- EOF mkfs.vfat -F 32 -n "boot" ${DRIVE}1
umount ${DRIVE}1
mkfs.ext3 -L "rootfs" ${DRIVE}2
umount ${DRIVE}2
mkfs.ext3 -L "START_HERE" ${DRIVE}3
Этот скрипт требует для запуска один входной параметр, который должен обозначать устройство носителя, установленное в карт-ридер USB. ВАЖНОЕ ЗАМЕЧАНИЕ: не запускайте этот скрипт, если не уверены полностью, что корректно ввели в параметре имя устройства. Если Вы случайно укажете устройство жесткого диска машины хоста, то его содержимое будет уничтожено. Далее будет показано, как правильно определить имя устройства, соответствующее подключенной в ридер карте SD, и как определить имя системного жесткого диска хоста. Как правильно определить нужное имя устройства. Как уже было сказано, скрипту нужно передать один параметр, обозначающий целевой форматируемый носитель. Этот параметр должен однозначно указывать на устройство, используемое для подключения к карт-ридеру USB SD. Для этой цели можно использовать команду df -hT, см. пример ниже. user@UbuntuVbox1004:~$ df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/sda1 ext4 19G 16G 2.5G 87% / none devtmpfs 245M 308K 245M 1% /dev none tmpfs 249M 192K 249M 1% /dev/shm none tmpfs 249M 340K 249M 1% /var/run none tmpfs 249M 0 249M 0% /var/lock none tmpfs 249M 0 249M 0% /lib/init/rw /dev/sdb1 vfat 1.9G 4.0K 1.9G 1% /media/00F8-E7F0 user@UbuntuVbox1004:~$ Показанный выше пример показывает результат выполнения команды df на системе Linux, к которой подключен USB карт-ридер, в котором установлена карта SD. Карт-ридер соответствует устройству /dev/sdb1. Карта SD, установленная в карт-ридер, имеет размер 2 гигабайта, и отформатирована как один стандартный раздел Windows FAT. Это обычное состояние для карты SD, купленной в магазине. Важно отметить, что раздел хоста Linux, где запускаются команды (смонтированный на /) соответствует устройств /dev/sda1. Имя /dev/sda показывает, что машина хоста имеет диск SATA. Если бы машина имела более старый диск IDE, то устройство получило бы имя /dev/hda. Теперь мы четко знаем, что скрипту следует передать имя /dev/sdb, ни в коем случае не /dev/sda. Передача скрипту устройства, связанного с жестким диском машины хоста, попросту разрушит операционную систему Linux на хосте. И еще несколько замечаний. Другие системы могут иметь аппаратуру, размещенную в других устройствах системы. Некоторые системы могут иметь несколько карт-ридеров. Так что один карт-ридер может называться /dev/sdb и другой /dev/sdc. Также может быть, что хост смонтировал жесткий диск IDE на устройстве /dev/hda, и имеет карт-ридер USB SD на имени /dev/sda. В этом случае будет правильным передать скрипту имя /dev/sdat. В любом случае пользователь должен правильно определить, что передавать в параметре скрипта. 2. Сделайте скрипт запускаемым: user@UbuntuVbox1004:~$ chmod 755 mk3PartSDCard 3. Запуск скрипта. После того, как Вы правильно определили имя устройства, которое нужно передать скрипту, необходимо размонтировать любую директорию, которая смонтирована на этом устройстве. В примере запуска команды df, показанном выше, на устройство /dev/sdb1 смонтирована директория /media/disk. Для размонтирования выполните следующую команду: user@Ubuntu1004:~$ umount /dev/sdb1 Скрипт должен быть запущен с правами суперпользователя. В Ubuntu это осуществляется через команду "sudo". Когда sudo запросит пароль, используйте пароль пользователя root. user@Ubuntu1004:~$ sudo ./mk3PartSDCard /dev/sdb Успешное выполнение скрипта в покажет в терминале вывод, подобный показанному ниже. Ошибка, которую может выдать sfdisk (что и показано ниже) может быть безопасно проигнорирована. user@UbuntuVbox1004:~$ sudo ./mk3PartSD /dev/sdb [sudo] password for user: 1024+0 records in 1024+0 records out 1048576 bytes (1.0 MB) copied, 1.53109 s, 685 kB/s Disk /dev/sdb doesn't contain a valid partition table DISK SIZE - 1977614336 bytes Checking that no-one is using this disk right now ... OK Disk /dev/sdb: 240 cylinders, 255 heads, 63 sectors/track sfdisk: ERROR: sector 0 does not have an msdos signature /dev/sdb: unrecognized partition table type Old situation: No partitions found New situation: Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sdb1 * 0+ 8 9- 72261 c W95 FAT32 (LBA) /dev/sdb2 10 124 115 923737+ 83 Linux /dev/sdb3 126 239 114 915705 83 Linux /dev/sdb4 0 - 0 0 0 Empty Successfully wrote the new partition table Re-reading the partition table ... If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1 (See fdisk(8).) mkfs.vfat 3.0.7 (24 Dec 2009) umount: /dev/sdb1: not mounted mke2fs 1.41.11 (14-Mar-2010) Filesystem label=rootfs OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 57856 inodes, 230934 blocks 11546 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=239075328 8 block groups 32768 blocks per group, 32768 fragments per group 7232 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 20 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. umount: /dev/sdb2: not mounted mke2fs 1.41.11 (14-Mar-2010) Filesystem label=START_HERE OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 57232 inodes, 228926 blocks 11446 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=234881024 7 block groups 32768 blocks per group, 32768 fragments per group 8176 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840 Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 27 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. Скрипт будет работать до тех пор, пока в терминале снова не покажется приглашение ввода команды Linux. На этой точке нужно размонтировать все на устройстве /dev/sdb: user@Ubuntu1004:~$ umount /dev/sdb1 user@Ubuntu1004:~$ umount /dev/sdb2 user@Ubuntu1004:~$ umount /dev/sdb3 Теперь физически извлеките карту SD из карт-ридера USB, и снова установите её. Ubuntu автоматически смонтирует на ней новые разделы. Запуск команды df -hT должен показать следующее: user@Ubuntu1004:~$ df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/sda1 ext4 19G 16G 2.5G 87% / none devtmpfs 245M 360K 245M 1% /dev none tmpfs 249M 252K 249M 1% /dev/shm none tmpfs 249M 340K 249M 1% /var/run none tmpfs 249M 0 249M 0% /var/lock none tmpfs 249M 0 249M 0% /lib/init/rw /dev/sdb1 vfat 70M 512 70M 1% /media/boot /dev/sdb2 ext3 888M 18M 826M 3% /media/rootfs /dev/sdb3 ext3 881M 17M 819M 3% /media/START_HERE user@Ubuntu1004:~$ Загрузочный раздел на карте SD (vfat, смонтированный сейчас как /media/boot) по минимуму должен содержать x-loader в файле MLO, файлы u-boot.bin и uImage. Раздел rootfs это корневая файловая файловая система для embedded Linux. [Как создать на SD-карте 2 раздела] Следующие процедуры относятся к процессорам TI Sitara: AM180x и AM1810. Карта SD с двумя разделами может быть создана незначительно модифицированным скриптом, который использовался для создания карты SD с тремя разделами. Сохраните скрипт, описанный ранее, в файл с именем mk2PartSDCard. Используйте для него те же предохранительные процедуры. ВНИМАНИЕ: этот скрипт также опасен при неправильном использовании! #! /bin/sh # mk2PartSDCard.sh v0.1 # Licensed under terms of GPLv2 DRIVE=$1 dd if=/dev/zero of=$DRIVE bs=1024 count=1024 SIZE=`fdisk -l $DRIVE | grep Disk | awk '{print $5}'`
echo DISK SIZE - $SIZE bytes CYLINDERS=`echo $SIZE/255/63/512 | bc` sfdisk -D -H 255 -S 63 -C $CYLINDERS $DRIVE << EOF ,9,0x0C,* 10,114,,, EOF mkfs.vfat -F 32 -n "boot" ${DRIVE}1
umount ${DRIVE}1
mkfs.ext3 -L "rootfs" ${DRIVE}2
После использования этого скрипта на карте SD будет создан раздел с именем "boot" и размером 70M. Второй раздел будет разделом Linux ext3, у него будет имя "rootfs", и он займет все оставшееся пространство карты. Этот скрипт очень хорошо работает с картами на 2 гигабайта. [Копирование на карту системных файлов] Настало время скопировать на карту SD загрузчики, ядро Linux и другие необходимые файлы. Готовые собранные системные файлы включены в Sitara SDK. Для AM35x/37x EVM файлы загрузчика и образа ядра могут быть размещены в загрузочном разделе карты SD. Для AM18x/181x EVM на карту SD нужно записать только образ ядра, потому что эти платы EVM должны иметь загрузчик (u-boot), записанный в SPI flash. Файлы загрузчика и ядра обычно находятся в подкаталоге установки SDK с именем psp/prebuilt-images. Корневая файловая система присутствует в tarball, находящемся в поддиректории инсталляции SDK с именем filesystem. Пример ниже показывает эти места на диске для AM37x SDK. user@UbuntuVbox1004:~/ti-sdk-am37x-evm-4.0.1.0/filesystem$ ls -l total 10504 -rw-r--r-- 1 user user 10751480 2011-01-26 09:13 base-rootfs-am37x-evm.tar.gz drwxr-xr-x 18 user user 4096 2011-02-07 14:40 SDK_NFS user@UbuntuVbox1004:~/ti-sdk-am37x-evm-4.0.1.0/filesystem$ cd .. user@UbuntuVbox1004:~/ti-sdk-am37x-evm-4.0.1.0$ cd psp/prebuilt-images/ user@UbuntuVbox1004:~/ti-sdk-am37x-evm-4.0.1.0/psp/prebuilt-images$ ls -l total 51168 lrwxrwxrwx 1 user user 40 2011-02-11 16:09 MLO -> MLO-am37x-evm-1.46-psp03.00.01.06.sdk-r0 -rwxr-xr-x 1 user user 20060 2011-01-22 09:30 MLO-am37x-evm-1.46-psp03.00.01.06.sdk-r0 -rwxr-xr-x 1 user user 216572 2011-01-22 09:30 u-boot-am37x-evm-2009.11-psp03.00.01.06.sdk-r0.bin lrwxrwxrwx 1 user user 50 2011-02-11 16:09 u-boot.bin -> u-boot-am37x-evm-2009.11-psp03.00.01.06.sdk-r0.bin lrwxrwxrwx 1 user user 13 2011-02-11 16:09 uImage -> uImage-2.6.32 -rw-r--r-- 1 user user 2409528 2011-01-25 17:12 uImage-2.6.32 -rw-r--r-- 1 user user 49743774 2011-01-25 17:12 vmlinux-2.6.32 user@UbuntuVbox1004:~/ti-sdk-am37x-evm-4.0.1.0/psp/prebuilt-images$ Для AM18x/AM181x EVM плата всегда запускает u-boot из SPI flash. Как записать u-boot в SPI flash показано в статье [6]. Для AM35x/37x EVM файлами загрузчика являются MLO и u-boot.bin. Эти два файла должны быть скопированы в загрузочный раздел карты SD. Для всех EVM образом ядра служит файл uImage. Этот файл нужно записать в загрузочный раздел карты SD. Корневая файловая система должна быть записана в раздел rootfs карты SD. Tarball, содержащий корневую файловую систему, доступен в директории filesystem установленного SDK. Здесь может быть два разных tarball-а. Пример ниже показывает, что AM181x SDK содержит два tarball-а с корневой файловой системой. Один имеет в имени префикс tisdk- и относится к файловой системе, поставляемой с retail EVM, и там полная система с Matrix GUI и все приложения примеров. Другой tarball это "базовая" файловая система без дополнительных, она может использоваться для как основа произвольных конфигураций Linux. user@UbuntuVbox1004:~/ti-sdk-am181x-evm-4.0.1.0/filesystem$ ls -l total 75264 -rw-r--r-- 1 user user 11055454 2011-01-26 10:44 base-rootfs-am181x-evm.tar.gz -rw-r--r-- 1 user user 66010750 2011-01-26 10:44 tisdk-rootfs-am181x-evm.tar.gz user@UbuntuVbox1004:~/ti-sdk-am181x-evm-4.0.1.0/filesystem$ Необходимо распаковать (un-tar) одну из этих файловых систем в раздел rootfs карты SD. Простое копирование и метод "drag-and-drop" на существующей файловой системе не сработают. Причина в том, что команда tar, использовавшаяся для создания tarball в SDK, имеет сохраненные полномочия, мягкие ссылки и узды device/file, которые важны в файловой системе. Также эти tarball-ы не создадут новую поддиректорию. Они разработаны для распаковки в раздел rootfs карты SD. Имейте в виду: необходимо использовать команду sudo, когда делаете распаковку tar-пакета файловой системы, чтобы дерево файлов устройств было создано корректно. Самый лучший способ распаковать tar - сначала поменять текущую директорию на /media/rootfs (или на ту директорию, куда смонтирована карта в системе хоста). Затем нужно запустить команду tar, которая распакует tarball в текущую директорию. И наконец, что может быть самым важным, - нужно запустить команду sync некоторое количество раз после того, как корневая файловая система была распакована tar на карту SD. Это обеспечит гарантию, что все данные из буферов кеширования будут сброшены на физический носитель SD (flush data) и корректно записаны. См. пример ниже. user@UbuntuVbox1004:~/ti-sdk-am181x-evm-4.0.1.0/filesystem$ cd /media/rootfs user@UbuntuVbox1004:/media/rootfs$ sudo tar -xzvf ~/ti-sdk-am181x-evm-4.0.1.0/filesystem/tisdk-rootfs-am181x-evm.tar.gz ... ... тут будут еще сообщения, если был использован ключ -v в команде tar ... user@UbuntuVbox1004:/media/rootfs$ sync user@UbuntuVbox1004:/media/rootfs$ sync И конечно же, можно поместить все это в скрипт, что может быть полезно для создания более одной карты SD. Пример ниже показывает скрипт, который копирует системные файлы для AM37x SDK. Перед запуском этого скрипта следует правильно отредактировать в нем все пути. Вот этот скрипт: #! /bin/sh # cpSDCard v0.1 export PATH_TO_SDK= export PATH_TO_SDBOOT= export PATH_TO_SDROOTFS= cp $PATH_TO_SDK/psp/prebuilt-images/MLO $PATH_TO_SDBOOT cp $PATH_TO_SDK/psp/prebuilt-images/u-boot.bin $PATH_TO_SDBOOT cp $PATH_TO_SDK/psp/prebuilt-images/uImage $PATH_TO_SDBOOT cd $PATH_TO_SDROOTFS tar -xzvf $PATH_TO_SDK/filesystem/tisdk-rootfs-am37x-evm.tar.gz sync sync Убедитесь, что поменяли export PATH_TO_SDK... на места расположения PSP, установленного в Вашем SDK. Пример ниже показывает пути для AM37 SDK и смонтированной карты SD. export PATH_TO_SDK=/home/user/ti-sdk-AM37x-evm-4.0.1.0 export PATH_TO_SDBOOT=/media/boot export PATH_TO_SDROOTFS=/media/rootfs Для запуска скрипта cpSDCard используйте команду ./cpSDCard, введенную в терминале. Позвольте скрипту работать, пока в терминале снова не будет выведено приглашение ввода команды. Это займет некоторое время, потому что работа команд "tar" и "sync" может занимать несколько минут. Двоичные файлы на разделе FAT носят следующие реальные имена:
Когда происходит загрузка с карты SD, код OMAP3 Boot ROM будет искать а карте SD файл с именем "MLO", где должен находиться загрузчик первого уровня x-loader. Чтобы запустить загрузку с этой карты SD, перемычки SW4 должны быть установлены в соответствующее положение (SD/MMC boot): SW4 = 00100111 (уровни нуля и единицы, т. е. в данной конфигурации SW4.1 = лог. 1) Здесь "1" соответствует для выключателя позиции "On" (замкнуто). Программа терминала UART, подключенная к UART 1/2 платы EVM, отобразит вывод процесса загрузки платы. Первая секция показывает вывод из x-loader, когда он загружается из карты SD/MMC и запускается. Texas Instruments X-Loader 1.45 (Mar 19 2010 - 19:44:19) Starting X-loader on MMC Reading boot sector 212504 Bytes Read from MMC Starting OS Bootloader from MMC... Starting OS Bootloader... Затем X-loader передает управление u-boot. Загрузчик U-boot ожидает найти "переменные окружения" (environment variables) в памяти NAND. Когда плата загружается первый раз, или если NAND была полностью стерта, u-boot покажет предупреждение о неправильном содержимом NAND (Warning - bad CRC or NAND). В этом случае загрузчик U-boot запишет значения переменных окружения по умолчанию (default environment), которые будет впоследствии использовать для продолжения процесса загрузки. U-Boot 2009.11 (May 06 2010 - 16:57:54) OMAP34xx/35xx-GP ES1.0, CPU-OPP2 L3-165MHz OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 128 MB NAND: 256 MiB *** Warning - bad CRC or NAND, using default environment In: serial Out: serial Err: serial Read back SMSC id 0x92200000 Die ID #731c0000000000000156087c0a023021 Net: smc911x-0 Hit any key to stop autoboot: 0 Переменные окружения по умолчанию разработаны для загрузки системы Linux с карты SD, так что нет необходимости останавливать процесс загрузки. И в следующий раз, когда загрузится плата EVM, корректные значения default environment будут находиться в памяти NAND, так что предупреждение "bad NAND" выводиться не будет. U-boot дает пользователю 2-3 секунды на остановку процесса загрузки. Для этого нажмите любую клавишу в окне терминала UART, и u-boot выведет следующее приглашение ввода команд: OMAP3_EVM # В этом приглашении можно использовать несколько полезных команд, которые стоит запомнить. printenv. Для отображения переменных окружения введите "printenv" или просто "pri". OMAP3_EVM #
OMAP3_EVM # printenv
bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run
loaduimage; then run mmcboot; else run nandboot; f
i; fi; else run nandboot; fi
bootdelay=2
baudrate=115200
bootfile=uImage
loadaddr=0x82000000
usbtty=cdc_acm
console=ttyS0,115200n8
mmcargs=setenv bootargs console=${console} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
nandargs=setenv bootargs console=${console} root=/dev/mtdblock4 rw rootfstype=jffs2
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand ...; run nandargs; onenand read ${loadaddr} 280000
400000; bootm ${loadaddr}
stdin=serial
stdout=serial
stderr=serial
dieid#=731c0000000000000156087c0a023021
ethact=smc911x-0
Environment size: 873/131068 bytes OMAP3_EVM # Показанные выше переменные окружения это переменные по умолчанию, которые включены в u-boot из TI SDK. Они будут перезаписаны в любое время, когда содержимое NAND стирается. Однако иначе они будут сохранены в NAND между перезагрузками (или выключением/включением питания), и могут быть модифицированы для того, чтобы повлиять на процесс загрузки Linux. boot. Чтобы продолжить загрузку из u-boot, просто введите команду "boot", и процесс загрузки продолжится, как если бы Вы его не останавливали нажатием любой клавиши при включении питания. Это также эквивалент вводу "run bootcmd". Переменная окружения bootcmd environment это реальная последовательность операторов условия (отделенных друг от друга точками с запятой semicolons), которые выполняют проверку оборудования и ПО для завершения процесса загрузки. OMAP3_EVM # boot ## Booting kernel from Legacy Image at 80000000 ... Image Name: Linux-2.6.32 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2396212 Bytes = 2.3 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux............................................................ ............................................................................... ............ done, booting the kernel. Затем будет выведено несколько сообщений ядра перед появлением приглашения логина (Linux login prompt): dm3730-am3715-evm login: В приглашении логина просто введите "root". [Подробнее про bootcmd] Переменная окружения bootcmd это набор вложенных друг в друга условных операторов. bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi Первый оператор условия "if mmc init" проверяет, подключена ли карта SD/MMC. Если карта присутствует, то следующий условный оператор "if run loadbootscript" проверяет, есть ли на карте SD скрипт загрузки boot.scr. Если этот скрипт присутствует, то он будет выполнен. Скрипт загрузки содержит аргументы загрузки (boot arguments) и команду для реальной загрузки ядра Linux. Таким образом, если скрипт загрузки существует и выполнен, то не будет осуществлен возврат в остальную часть скрипта bootcmd. [Ссылки] 1. Boot Sequence site:processors.wiki.ti.com. |