LINUX.ORG.RU
ФорумTalks

делаем образ загрузочной SD

 bootrom, , , ,


1

1

… чтобы могло пойти не так?

Всех приветствую. Раз сегодня пятница, расскажу вам прохладную историю.

Нужно мне сделать загрузочную флешку для одной железки на базе процессора sitara (это Техас Инструментс, это где Хьюстон, быки и пи… впрочем об этом в другой раз).

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

sudo fdisk -c=dos -S 63 -H 255 /dev/sdb
n
p
1
63
144584
t
1
b
a
1
w

Дальше форшмачим: sudo mkfs.vfat -F 32 -n "boot" /dev/sdb1

монтируем, копируем SPL+u-boot+main_img..

И все работает. Да, волшебная строчка для fdisk, рождалась в диких корчах и муках. Тем не менее, если воткнуть sd в железку, она бодро загрузится и будет работать.

Дальше мне захотелось странного. Хочу не скрипт, который будет печь sd-карту. А скрипт, который будет печь образ, который можно потом, просто закинуть на любую sd через dd или еще как.

В целом вроде как ничего хитрого:

IMG=./sd_image
dd if=/dev/zero of=$IMG bs=1M count=200
cat << END | fdisk -c=dos -S 63 -H 255 ${IMG}   
... < тут все тоже самое что и для sdb
END
DEV=`sudo losetup --find --show --partscan ${IMG}`
sudo mkfs.vfat -F 32 -n "boot"   ${DEV}p1 
sudo mount -t vfat ${DEV}p1 ./p1 
cp ./MLO bla-bla-bla
sudo umount ....
sudo losetup --detach $DEV 

Получили такие же первых 63 сектора. И такой же размер первого раздела с таким же набором файлов. Дальше, делаем:

dd if=$IMG of=/dev/sdb

Втыкаем в железку.. и ничего!

В чем сакральная разница?

★★★★★
Ответ на: комментарий от Xenius

хорошая попытка.

Зануляем первые 100M, опять размечаем, форматируем и копируем и все работает. На той же флешке!

yax123 ★★★★★
() автор топика

Сними образ с рабочей SD-карты и с нерабочей SD-карты. И проверяй что там отличается.

vbr ★★★★★
()
Ответ на: комментарий от vbr

Ну да, отличается, чуток. Времена у файлов. Какие-то свойства у структур FS (я еще не опустился до того чтобы фат32 в хексах парсить). Но я же не делаю никаких дополнительных телодвижений лишних.

yax123 ★★★★★
() автор топика
Ответ на: комментарий от yax123

Сравни сами файлы через diff -r например. А вообще непонятно. Может быть у тебя при неудачной загрузке просто сама карта криво вставилась или ещё что.

Xenius ★★★★★
()
Ответ на: комментарий от yax123

Скопируй раздел с FS побайтово с рабочего образа в нерабочий, чтобы не отличался и проверь, стал ли он рабочим. Если стал, значит надо копать глубже. Если не стал, значит свойства структур ФС уже не будут отличаться и можно разбираться, что теперь отличается.

Если бы это было GPT, там в конце устройства backup таблица, которая создастся, когда ты fdisk используешь на реальном устройстве и будет не в том месте, когда ты fdisk используешь на файле-образе, если только ты этот образ не создал с идеально подогнанным размером. В теории это не должно быть фатальной проблемой, но мало ли. Но у тебя MBR, поэтому такая теория вроде не проходит.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от Xenius

Такое тоже бывает и часто (крайне не удачный лоток), но я перепроверяю каждый раз, чищу контакты и т.д

yax123 ★★★★★
() автор топика
Ответ на: комментарий от yax123

Когда происходит что-то необъяснимое - самое вероятное, что ты ошибся где-то по невнимательности. А так, только ты сам можешь определить, что идёт не так.

Единственное у тебя лишний cat который не нужен, просто fdisk ... << END достаточно

Xenius ★★★★★
()
Ответ на: комментарий от Xenius

у тебя лишний cat

это копипаста из скрипта от техаса, который размечает диск.

Насчет того что я где-то невнимателен, это первое что мне пришло в голову. Но я даже придумать не могу где мог ошибиться. Вот использую сообщество как желтую утку.

yax123 ★★★★★
() автор топика

Можно ещё сравнить образ снятый с карты и файл после fdisk. Это позволит понять отличается ли структура разделов. Аналогично после этапа создания фс(пустой)

cobold ★★★★★
()

попробуй у dd bs=512 выставить, может оно как-то к размеру блока чувствительно (но я сомневаюсь, что это поможет)

mittorn ★★★★★
()
Ответ на: комментарий от yax123

Ну так надо последовательно исключать причины. Например есть образ который не грузится — проверяешь вывод fdisk на обоих вариантах, ты говоришь совпадает, тогда проверяешь файлы на разделе. Может ещё нужны какие-то атрибуты файлов типа системный/скрытый/итд. проверяешь файловую систему, может быть там в одном случае FAT16, а в другом FAT32 например. В общем последовательно проверяешь, что может отличаться.

Xenius ★★★★★
()
Ответ на: комментарий от yax123

Может кто-то знает про графическую тулзу которую можно натравить на дамп раздела, а он там распарсит все байты и покажет что есть что?

yax123 ★★★★★
() автор топика
Ответ на: комментарий от imatveev13

А сам загрузчик на tty не говорит чего не нашел?

У техаса бутром не сильно разговорчивый. У него есть там 8 слов в памяти, в которые он трейсит процесс загрузки, но эти пи-…пи, даже здесь обосрались. Если грузить с sd еще как-то трейс заполняют, а если из emmc то вообще все пустое. Дебилы

yax123 ★★★★★
() автор топика
Ответ на: комментарий от Xenius

пофиг на графику, пусть TUI или еще чего. главное чтобы показывала поля и названия

yax123 ★★★★★
() автор топика

Я с подобным сталкивался, но только на обычных писюках, то есть, BIOS-only компах. Не понимаю почему, но похоже, что в таком образе нет информации о реальном размещении сектора 0, то есть, о CHS-геометрии образа. И получается, что то, что должно находиться в MBR, не попадает в сектор 0, следовательно, не происходит загрузки. Я бы поэкспериментировал с ключиком -g у mkdosfs.

yars068 ★★★★★
()
Ответ на: комментарий от vbr

GPT не привязывает физическое местоположение загрузчика, в отличие от BIOS/MBR разметки.

yars068 ★★★★★
()
Ответ на: комментарий от yars068

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

yax123 ★★★★★
() автор топика
Ответ на: комментарий от yax123

Сделал 2 образа. Один непосредственно на sd карте. Потом снял дамп. Проверил работоспособность.

Второй через файл и монтирование в loop. Тоже дамп. Заливал на sd, проверял на sd (не работает).

Получилось два дампа по 72293К. Я их конвертнул в хекс и дифнул. Вот результат:


--- sd_mbr_p1_bad.bin.hex       2026-04-24 17:10:31.264925166 +0300
+++ sd_mbr_p1_work.bin.hex      2026-04-24 17:10:44.250739946 +0300
@@ -25,7 +25,7 @@
 000001a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
-000001b0: 00 00 00 00 00 00 00 00 95 0a 3d 00 00 00 80 01  ..........=.....
+000001b0: 00 00 00 00 00 00 00 00 a0 40 e6 66 00 00 80 01  .........@.f....
 000001c0: 01 00 0b fe 3f 08 3f 00 00 00 8a 34 02 00 00 00  ....?.?....4....
@@ -2015,10 +2015,10 @@
 00007e00: eb 58 90 6d 6b 66 73 2e 66 61 74 00 02 01 20 00  .X.mkfs.fat... .
-00007e10: 02 00 00 00 00 f8 00 00 20 00 10 00 3f 00 00 00  ........ ...?...
-00007e20: 80 34 02 00 58 04 00 00 00 00 00 00 02 00 00 00  .4..X...........
+00007e10: 02 00 00 00 00 f8 00 00 3f 00 ff 00 3f 00 00 00  ........?...?...
+00007e20: 8a 34 02 00 58 04 00 00 00 00 00 00 02 00 00 00  .4..X...........
 00007e30: 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
-00007e40: 80 00 29 c1 8b a6 62 62 6f 6f 74 20 20 20 20 20  ..)...bboot
+00007e40: 80 00 29 b0 5d 7a 47 62 6f 6f 74 20 20 20 20 20  ..).]zGboot
 00007e50: 20 20 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac    FAT32   ...w|.
@@ -2076,7 +2076,7 @@
 000081d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
-000081e0: 00 00 00 00 72 72 41 61 03 25 02 00 ae 06 00 00  ....rrAa.%......
+000081e0: 00 00 00 00 72 72 41 61 0d 25 02 00 ae 06 00 00  ....rrAa.%......
 000081f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa  ..............U.
@@ -2207,10 +2207,10 @@
 00008a00: eb 58 90 6d 6b 66 73 2e 66 61 74 00 02 01 20 00  .X.mkfs.fat... .
-00008a10: 02 00 00 00 00 f8 00 00 20 00 10 00 3f 00 00 00  ........ ...?...
-00008a20: 80 34 02 00 58 04 00 00 00 00 00 00 02 00 00 00  .4..X...........
+00008a10: 02 00 00 00 00 f8 00 00 3f 00 ff 00 3f 00 00 00  ........?...?...
+00008a20: 8a 34 02 00 58 04 00 00 00 00 00 00 02 00 00 00  .4..X...........
 00008a30: 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
-00008a40: 80 00 29 c1 8b a6 62 62 6f 6f 74 20 20 20 20 20  ..)...bboot
+00008a40: 80 00 29 b0 5d 7a 47 62 6f 6f 74 20 20 20 20 20  ..).]zGboot
 00008a50: 20 20 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac    FAT32   ...w|.
@@ -2268,7 +2268,7 @@
 00008dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
-00008de0: 00 00 00 00 72 72 41 61 af 2b 02 00 02 00 00 00  ....rrAa.+......
+00008de0: 00 00 00 00 72 72 41 61 b9 2b 02 00 02 00 00 00  ....rrAa.+......
 00008df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa  ..............U.
@@ -74206,14 +74206,14 @@
 00121df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
-00121e00: 62 6f 6f 74 20 20 20 20 20 20 20 08 00 00 d9 86  boot       .....
-00121e10: 98 5c 98 5c 00 00 d9 86 98 5c 00 00 00 00 00 00  .\.\.....\......
-00121e20: 4d 4c 4f 20 20 20 20 20 20 20 20 20 00 33 d9 86  MLO         .3..
-00121e30: 98 5c 98 5c 00 00 d9 86 98 5c 03 00 26 d2 01 00  .\.\.....\..&...
+00121e00: 62 6f 6f 74 20 20 20 20 20 20 20 08 00 00 f1 85  boot       .....
+00121e10: 98 5c 98 5c 00 00 f1 85 98 5c 00 00 00 00 00 00  .\.\.....\......
+00121e20: 4d 4c 4f 20 20 20 20 20 20 20 20 20 00 c5 f2 85  MLO         ....
+00121e30: 98 5c 98 5c 00 00 f2 85 98 5c 03 00 26 d2 01 00  .\.\.....\..&...
 00121e40: 41 75 00 2d 00 62 00 6f 00 6f 00 0f 00 6d 74 00  Au.-.b.o.o...mt.
 00121e50: 2e 00 69 00 6d 00 67 00 00 00 00 00 ff ff ff ff  ..i.m.g.........
-00121e60: 55 2d 42 4f 4f 54 20 20 49 4d 47 20 00 35 d9 86  U-BOOT  IMG .5..
-00121e70: 98 5c 98 5c 00 00 d9 86 98 5c ed 00 98 83 0b 00  .\.\.....\......
+00121e60: 55 2d 42 4f 4f 54 20 20 49 4d 47 20 00 c7 f2 85  U-BOOT  IMG ....
+00121e70: 98 5c 98 5c 00 00 f2 85 98 5c ed 00 98 83 0b 00  .\.\.....\......
 00121e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

как по мне, отличия не существенные. в первом блоке, отличия в идентификаторе диска во втором, тут большие различия - неясно насколько критично в третьем, тоже 4 и 5 это дубликаты ФС 6 - явно метка времени 7,8 - это уже каталожные записи, тоже отличия явно в метках времени

yax123 ★★★★★
() автор топика
Последнее исправление: yax123 (всего исправлений: 1)
Ответ на: комментарий от yax123

И всё-таки, файлы, судя по всему, хоть и получаются одинаковыми (от перемены мест слагаемых контрольная сумма не меняется – но на самом деле она меняется), но загрузчик или загружаемое им ядро не попадает туда, куда должен. Есть у меня образ досовой дискеты 1,44 МиБ. Я скопировал в файл 2880 блоков нулей с дефолтным bs=512, создал на полученном образе файловую систему:

mkdosfs -F12 test.img -n MSDOS622 --mbr

Эту ФС я смонтировал, скопировал туда файлы с образа дискетки, скопировал 446 байт загрузчика (то есть, без таблицы разделов), получил незагружающийся в виртуалке образ. Скопировал в образ весь MBR, все 512 байт, получил тот же результат. Что изменилось? А изменилось местоположение IO.SYS, загрузчик получает управление, выводит сообщение «Non-System disk or disk error\nReplace and press any key when ready» и на этом всё.

yars068 ★★★★★
()
Последнее исправление: yars068 (всего исправлений: 2)
Ответ на: комментарий от yax123

Связь прямая, и у тебя, и у меня образы, изготовленные вручную, не грузятся. Дай мне некоторое время, я найду, что и где поменялось у меня, получу успешно загружающийся образ и попытаюсь найти, где происходит затык у тебя – что именно не может найти твой загрузчик. У нас обоих не совпадают адреса того самого ядра, о котором я писал выше, потому и не грузятся наши образы.

yars068 ★★★★★
()
Ответ на: комментарий от yars068

Если ты смотрел дифф то мог заметить, что отличия только в описателе файловой системы и в каталожных записях. И все. Сами файлы загрузчиков совпадают и размещены одинаково.

Я сделал еще пару образов через loop и через sdb. И сравнил между собой. Оказалось различий чуть меньше. И если откинуть различия между образами сделанными одинаково, то останется разница только тут:


@@ -2076,7 +2076,7 @@
 000081d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
-000081e0: 00 00 00 00 72 72 41 61 03 25 02 00 ae 06 00 00  ....rrAa.%......
+000081e0: 00 00 00 00 72 72 41 61 0d 25 02 00 ae 06 00 00  ....rrAa.%......
 000081f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa  ..............U.

@@ -2268,7 +2268,7 @@
 00008dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
-00008de0: 00 00 00 00 72 72 41 61 af 2b 02 00 02 00 00 00  ....rrAa.+......
+00008de0: 00 00 00 00 72 72 41 61 b9 2b 02 00 02 00 00 00  ....rrAa.+......
 00008df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa  ..............U.
yax123 ★★★★★
() автор топика
Ответ на: комментарий от yax123

Ну отлично, всего два байта. Возьми незагружающуюся SD, попробуй ещё раз, убедись что не загружается, замени два отличающихся байта (03 на 0d и af на b9 или наоборот,) и проверь, будет грузиться или нет. Заменять байты по оффсету можно с помощью dd только аккуратно надо целиться.

Если после этого грузится, замени один байт обратно. Потом ещё раз. Затем попробуй выяснить что это за структура.

Правда нейронка говорит что после rrAa идёт количество свободных кластеров и две штуки - это Struct Signature и Trail Signature. Можно погуглить и найти врёт или нет.

Xenius ★★★★★
()
Последнее исправление: Xenius (всего исправлений: 2)
Ответ на: комментарий от yax123

разница численно одинаковая, 0x0A=2*5. Не могло оказаться так что в одном случае нечто отсчитывается от начала диска, а в другом от начала раздела? Смещение начала раздела относительно начала диска случайно не кратно 5? Если нет, то эта гипотеза отбрасывается

GPFault ★★★
()
Последнее исправление: GPFault (всего исправлений: 2)
Ответ на: комментарий от yax123

Пока что не смотрел. Но кое-что нашёл у себя, хоть и не до конца. Расположение IO.SYS в MBR лежит по смещению 0xF2, а сам файл на ФС лежит в секторе 33, в оригинальном образе дискетки это будет смещение 0x4200. Как искал? Смонтировал оригинальный образ, открыл IO.SYS на чтение, запомнил первые байты и нашёл их поиском в образе. Затем посчитал номер сектора (смещение разделить на размер сектора), получилось 33. Затем, учитывая порядок байт, для х86 – little-endian, нашёл номер сектора в MBR (лучше прямо отделить первые 512 байт от образа, лично мне так проще) – 0х00 0х33, посмотрел фактическое расположение IO.SYS в незагружающемся образе и подставил в MBR по данному в самом начале поста смещению (у меня получилось 0х03 0xBE) этот адрес. Сообщение о несистемном диске исчезло, но процесс дальше пока не идёт – IO.SYS прицепом грузит MSDOS.SYS, расположение которого также нужно поправить, уже в IO.SYS. Делай выводы :)

yars068 ★★★★★
()
Последнее исправление: yars068 (всего исправлений: 1)
Ответ на: комментарий от GPFault

Пока самое сильное предложение! Надо подумать. Вообще, схема такая. Всё разбито на 512байтовые сектора. В первом сектор мбр. Дальше 62 сектора пустые. С 63 начинается раздел фат32.

В фат32: первые 6 секторов совпадают со след. 6 сек.

yax123 ★★★★★
() автор топика
Последнее исправление: yax123 (всего исправлений: 1)
Ответ на: комментарий от yax123

В твоём случае есть ещё так называемая VBR – Volume Boot Record, которая может содержать загрузчик, и, скорее всего, он там есть – это копия u-boot, которая через chain-loading получает управление от MBR, читает что-то там с раздела в память и передает туда управление.

yars068 ★★★★★
()
Ответ на: комментарий от yars068

Этого ничего там нет. Бутром, ищет на диске mbr, ищет там fat, дальше идет в этот раздел ищет там MLO (другое название SPL), грузит в память и исполняет.

yax123 ★★★★★
() автор топика
Ответ на: комментарий от yars068

которая может содержать загрузчик,

не нужно х86 абстракции тянуть в православный arm.

yax123 ★★★★★
() автор топика

Оказывается в линуксах есть minfo Я натравил его на генерённый раздел и вот что он мне выдал:

--- minfo_sdb1.txt  2026-04-24 19:14:40.333161425 +0300
+++ minfo_file_p1.txt 2026-04-24 19:14:52.625102645 +0300
@@ -1,11 +1,11 @@
device information:
===================
-filename="/dev/sdb1"
-sectors per track: 63
-heads: 255
-cylinders: 9
+filename="./sd_p1.bin"
+sectors per track: 32
+heads: 16
+cylinders: 283

-mformat command line: mformat -t 9 -i /dev/sdb1  -h 255 -s 63 -H 63 ::
+mformat command line: mformat -T 144512 -i ./sd_p1.bin  -h 16 -s 32 -H 63 ::

bootsector information
======================
@@ -18,14 +18,14 @@
small size: 0 sectors
media descriptor byte: 0xf8
sectors per fat: 0
-sectors per track: 63
-heads: 255
+sectors per track: 32
+heads: 16
hidden sectors: 63
-big size: 144522 sectors
+big size: 144512 sectors

похоже mkfs.vfat не очень то корректно на файлах работает.

yax123 ★★★★★
() автор топика
Ответ на: комментарий от yax123

Ну штош. Всем спасибо за ценные советы. Решение выглядит так:

fdisk -c=dos -S 63 -H 255 ${IMG}
mkfs.vfat -F 32 -g 255/63 -n "boot"   ${DEV}p1

В этом случае MBR будет правильной геометрии. И раздел отформатируется так же в правильную геометрию.

Похоже, когда форматируешь реальную sd-карту, mkfs может прочитать из нее геометрию, а для loop0p1 это уже не работает и нужно руками указывать.

Всем спасибо, все свободны.

yax123 ★★★★★
() автор топика
Ответ на: комментарий от yax123

ну и в догонку, если кто будет с этой фигней (ситарой) работать.

Размер загрузочного раздела должен быть равен полному размеру для указанной геометрии.

То есть, кол-во голов и секторов у нас задано (255 и 63).

Кол-во цилиндров выбираем исходя из потребного размера. Например 10 цил. Тогда полный размер будет таким:

255 * 63 * 10 = 160650 секторов по 512байт.

И размечать надо так: p1: 63 160649 160587 78.4M b W95 FAT32 один сектор отняли так как там MBR.

Промахнетесь хоть на один сектор - bootrom откажется грузиться.

yax123 ★★★★★
() автор топика
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)