Как происходит загрузка на ARM?

640x480x8 — это уже 300 КиБ, половина conventional памяти.

:) Если бы так было, то на PC игрушки бы не появились. Для адресации в режиме 640x480 хватало и 38 КиБ, просто использовались слои.

Какое там было разрешение и куда отображался фреймбуфер?

Понятия «фрейбуфер» не было, а память видеоадаптера, например, в режиме 640x480 мапилась на 0xA000:0x0000.

:) Если бы так было, то на PC игрушки бы не появились. Для адресации в режиме 640x480 хватало и 38 КиБ, просто использовались слои.

Поясни. 640x480x8(bits-per-pixel)/8(bits-per-byte) = 307200 B = 300 KiB.

Понятия «фрейбуфер» не было, а память видеоадаптера, например, в режиме 640x480 мапилась на 0xA000:0x0000.

Фреймбуфер в моём понимании — это любая область памяти, которая содержит кадр целиком, попиксельно. Если он был в памяти видеоадаптера — отлично. Если она была замаплена в верхнюю память (начиная с 0xA000) — ещё лучше, я об этом и спрашивал. Только что значит :0x0000?

Поясни. 640x480x8(bits-per-pixel)/8(bits-per-byte) = 307200 B = 300 KiB.

Каждая точка - 1 пиксель, в байте - 8 точек, а вот чтобы задать цвет нужны 4 бита - соответственно 4 слоя. Все слои мапились по одному адресу, но была возможность маскировать в какой слой писать, а в какой нет. Поищи в интернете организацию памяти в EGA, были картинки это поясняющие.

По поводу адресов, так адресовали в реальном режиме на 16-битных процессорах. Размер сегмента не превышал 64 КиБ, поэтому первым шел сегментный адрес, а вторым смещение в сегменте. Физический адрес для 0xA000:0x0000 - 0xA00000.

Каждая точка - 1 пиксель, в байте - 8 точек, а вот чтобы задать цвет нужны 4 бита - соответственно 4 слоя. Все слои мапились по одному адресу, но была возможность маскировать в какой слой писать, а в какой нет. Поищи в интернете организацию памяти в EGA, были картинки это поясняющие.

Ммм, bueno. Ещё и 16 цветов всего в палитре. Окей, вопрос снимается.

Но мы вроде про VGA говорили исходно. Там тоже было так? Или всё-таки был настоящий фреймбуфер?

По поводу адресов, так адресовали в реальном режиме на 16-битных процессорах. Размер сегмента не превышал 64 КиБ, поэтому первым шел сегментный адрес, а вторым смещение в сегменте. Физический адрес для 0xA000:0x0000 - 0xA00000.

А, это был не диапазон, а сегмент:смещение. Я количество нулей неправильно прочёл, думал, ты имел в виду два физических адреса.

Известно, куда: где-то в нижнем диапазоне адресов...

Ну... Думаю, там тоже было где-то в нижних 4G.

Кури u-boot spl direct kernel load. ЕМНИП можно прямо с ext раздела загрузить ядро и отправить на выполнение.

Но мы вроде про VGA говорили исходно. Там тоже было так?

Да. По ровно той же причине — в 1мб уже не оставалось размеченных участков, поэтому для доступа к видеопамяти было только 64K, что для такого способа хватало. В SVGA пришлось делать уже более накладный способ с переключением страниц видеопамяти в это окно (это стало рождением видеодрайверов). Прямой доступ к фреймбуферу появился только в 1994 и только в защищённом режиме.

Прямой доступ к фреймбуферу появился только в 1994 и только в защищённом режиме.

ну тащемта область графической памяти cga/ega - таки тоже можно считать фреймбуфером (т.к. там рисуется кадр целиком).

ну тащемта область графической памяти cga/ega - таки тоже можно считать фреймбуфером

Ни у того ни у другого нельзя :) У EGA видеопамять 640*350*4bpp/8bit=112000, а окошко всего 64к, поэтому там и используются слои. У CGA же нет своей видеопамяти и картинку он рисует прямо из оперативной памяти, отчего там довольно геморно было графику ручками писать — чтобы не было снега, с CGAшным RAMDAC надо было вручную по тактам синхронизироваться, ладно хоть 808[68] одну частоту имели.

Эталон выборочного цитирования.

Нижний диапазон адресов PCI — это немного более конкретное указание, чем «нижние 4G».

Нижний диапазон адресов PCI — это немного более конкретное указание, чем «нижние 4G».

Было бы неплохо, если бы ты ещё объяснил, почему это всё важно. И как это относится к реальному режиму.

Никак. Я задал тебе вопрос, ты не ответил и сказал что-то вроде «как будто ты знаешь ответ на аналогичный вопрос для своего компьютера». Ну вот, знаю.

Ну вот, знаю.

Ok, молодец. Дальше-то что?

Это я хотел у тебя спросить, что дальше. :)

Ты ж поднял вопрос о том, куда мапился фреймбуфер. Видимо, это какое-то значение имело?

Я смутно помню, что фреймбуфер в vesa 2.0 я так и не пробовал. Видимо, испугался защищенного режима, для которого непонятно было, как писать. Теперь вот интересно, а какой адрес там функции vesa возвращали, указывал ли он в адреса PCI. Конкретные адреса не гуглятся, а пробовать слишком лень.

Могу сказать за Raspberry Pi, если еще не было:
1. Создаешь в начале флешки раздел FAT16 емнип.
2. Кидеаешь туда файлы bootcode.bin, и start.elf (первый вроде бы содержит в себе что-то типа части биоса, а второй — загрузчик ОС). Оба файла стандартные и предоставляются производителем.
3. Закидываешь свое ядро и обзываешь его kernel.img (это должен быть object-файл).

Все кроме kernel.img грузиться на GPU.

PS: я мог все перепутать:)

На GPU?

насчет EGA - да, попутал.

CGA - своя память есть. https://upload.wikimedia.org/wikipedia/commons/5/55/IBM_Color_Graphics_Adapte... - 8 штук MCM4517 (16Кх1) внизу

Да, там биос с GPU стартует.

графическим интерфейсом с мышкой

У меня лично была 486 материнка, где биос как раз был с графическим интерфейсом, с мышкой и окошками
Выглядело вот так https://www.youtube.com/watch?v=MgIxv6EIJNY

Раньше под х86 подобное тоже было, например, какие-нибудь виабушные NEC PC, где как бы тот же интел, но обычный DOS или шиндошс95 на них не поставить, надо специальные версии

Karateka, F-19, F-117 - это всё шло на Искре 1030.

И арканоид!

А на 286 с тем же мегабайтом шёл вполне себе графический и многоуровневый Eye of Beholder. Помню, как там червяк из-за угла вылез, я чуть не блеванул с испуга...

Могу сказать за Raspberry Pi

Вау, вот это интересно!

Кидеаешь туда файлы bootcode.bin, и start.elf (первый вроде бы содержит в себе что-то типа части биоса, а второй — загрузчик ОС). Оба файла стандартные и предоставляются производителем.

А исходники на это добро есть? Ну или хотя бы толковая документация на «часть биоса», если вдруг кто-нибудь :) захочет это из своей нестандартной ОС вызвать.

Ну это Распберри. Думаю в документации на сайте есть и исходники и детальная дока.
Вообще в интернете куча статей на эту тему. Гуглиться по «Raspberry PI bare metal» или типа того.. Там будет инфа как писать код под чистое желео, и включительно с подробными пояснениями, как этот код будет грузиться.

Тут есть и про TrustZone и про Secure Boot и про UEFI и про U-Boot на примере NXP QorIQ LS1046A:

https://www.nxp.com/docs/en/supporting-information/QORIQ_LS1046A_BSP_V0-4_REV...

+ почитай еще Referenfce Manual на него

Исходники:

TrustZone: https://github.com/qoriq-open-source/ppa-generic

UEFI: https://github.com/qoriq-open-source/uefi

U-Boot: https://github.com/qoriq-open-source/u-boot

Интересно, такого не видел никогда.

Сам интересуюсь сабжем так как с недавнего времени являюсь обладателем одноплатника Orange Pi PC. Насколько я понял, копаясь в теме, ARM отличается от IBM PC тем, что последний является конструктором, а устройства на базе ARM - не расширяемые в принципе, всё просто напаяно на одной плате, следовательно при загрузке процедура BIOS POST, во время которой происходит определение подключённых к шине устройств, не нужна, да и самого BIOSа в привычном понимании нет. При загрузке с флешки грузится SPL, который является загрузчиком загрузчика, потом грузится u-boot - это собственно сам загрузчик операционной системы, причём он должен быть собран конкретно под данное устройство, при этом в память также загружается dtb (Device Tree Binary) уникальный для каждого устройства, без которого работа невозможно. После идёт загрузка ядра Linux.

Могу сказать за Raspberry Pi, если еще не было: 1. Создаешь в начале флешки раздел FAT16 емнип. 2. Кидеаешь туда файлы bootcode.bin, и start.elf (первый вроде бы содержит в себе что-то типа части биоса, а второй — загрузчик ОС). Оба файла стандартные и предоставляются производителем. 3. Закидываешь свое ядро и обзываешь его kernel.img (это должен быть object-файл).

Все кроме kernel.img грузиться на GPU.

PS: я мог все перепутать:)

На счёт ядра точно путаешь (или на малинке и апельсинке) имя образа отличается.
Ядро должно называться uImage Ещё есть script.bin, это типа конфигурационный скрипт для u-boot, только не вкурил как он работает.
Начало связки SPL+u-boot+dtb должно находится в 8 секторе флешки (где-то между MBR и FAT32-разделом), его туда при помощи dd закидывают.

еще абрамс забыли )

Тред не читал, была ли ссылка не знаю, но вот

https://habrahabr.ru/post/338806/ — «Загрузка ОС на ARM»

Я просто когда-то давно это все руками делал на каком-то воркшопе. Ни u-boot'ом, ни файлом uimage там и не пахло.