LINUX.ORG.RU
Форум — Development  

U-boot и Cubieboard. Одноплатники. SD-карты. Загрузка.

 , ,


0

2

Allwinner A20 процы и подобные им семейства sunxi имеют где-то внутри прошитый на заводе загрузчик BROM прямо на кристалле, который при наличии SD-слота и правильно выставленных пинах смотрит в этот SD-слот на блочное устройство по смещению 8 килобайт, читает оттуда то-ли 8, то-ли 32KB так называемого SPL-загрузчика (Secondary Program Loader) и далее тупо исполняет код оттуда. Этот SPL может быть хоть вашей инновационной OS мигающей светодиодами, хоть тупым кодом который грузит ещё 100 мегабайт с флешки и исполняет их. Но обычно SPL содержит код, который загружает по какому-то смещению лежащий там где-то дальше U-Boot с жирностью до 32 КБ, который уже умеет парсить прям настоящие ext4 (не в полном смысле монтировать и запускать журнал, а просто хотя-бы читать), этот U-Boot выковыривает из ext4 всякие нужные ему вещи из /boot, главным образом исполняет /boot/boot.cmd, грузит ядро и дальше уже передаёт управление на linux и далее завертелось.

Так вот, вопрос в том, откуда U-Boot знает что на флешке читать надо именно ext4 раздел и на этом разделе что-то там ещё находить.

Взял я исходники U-Boot с гитхаба, кросс-компилял их с помощью arm-linux-gnueabihf-gcc-12 вот таким макаром:

export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
make Cubieboard2_defconfig
make -j2

и получил файлик

u-boot-sunxi-with-spl.bin

который закинул на SD-карту таким макаром:

sudo dd if=~/src/u-boot/u-boot-sunxi-with-spl.bin of=/dev/sda bs=1024 seek=8

На данной SD-карте 1 раздел ext4, в которой лежит корень от armbian покоцаный, но настроенный и рабочий. Воткнул это в cubieboard2 железку и она успешно загрузилась.

Я вот не пойму как этот U-Boot понял, что надо парсить именно ext4 FS на этой флешке? Я не нашёл в каких конфигах при сборке у него это было явно записано, в Cubieboard2_defconfig например этого нет.

Там в U-Boot какое-то тупое эвристическое сканирование-перебор всех разделов с попыткой их попарсить и поискать /boot/boot.scr?



Последнее исправление: lesopilorama (всего исправлений: 2)
← Метапрограммирование на препроцессоре
Чем плохо много return? →

Да, он ищет раздел на флешке п пытается найти на нём фс из поддерживаемых. Только не из spl, а уже из большого убута с драйверами, который записан по фиксированному оффсету, если я правильно помню

mittorn ★★★★★
()
Последнее исправление: mittorn (всего исправлений: 1)

Перебирает все разделы, ищет на них boot.scr.

Запустите menuconfig за посмотрите стартовый скрипт. И документацию почитайте.

ValdikSS ★★★★★
()

В u-boot можно конечно любое извращение запихать.

Но обычно все выглядит крайне тривиально - u-boot ищет в своих env bootcmd и исполняет его.

Вот пример от TI (я вставил переносы для лучшести восприятия):

bootcmd=
if test ${dofastboot} -eq 1; then
  echo Boot fastboot requested, resetting dofastboot ...;
  setenv dofastboot 0;
  saveenv;
  echo Booting into fastboot ...;
  fastboot 1;
fi;
if test ${boot_fit} -eq 1; then
  run update_to_fit;
fi;
run findfdt;
run envboot;
run mmcboot;
run emmc_linux_boot;
run emmc_android_boot;

mmcboot=
mmc dev ${mmcdev};  // будем грузится с этого устройства
devnum=${mmcdev};   
devtype=mmc;        
if mmc rescan; then
  echo SD/MMC found on device ${mmcdev};
  if run loadimage; then
    run args_mmc;
    if test ${boot_fit} -eq 1;then
      run run_fit;
    else
     run mmcloados;
    fi;
  fi;
fi;

args_mmc=
run finduuid;
setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}

Ну и так далее.

Нет никаких секретных договоренностей. Только env и куча вложенных вызовов и if-ов.

yax123 ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.
← Метапрограммирование на препроцессоре
Development
Чем плохо много return? →