Как стать автором
Обновить

Комментарии 17

Внезапно, всё отлично расписано. Единственное — вокруг highspeed ssd очень много всего вьётся (из идей и технологий) — вроде бы кто-то начал в линуксах пилить поддержку прямого исполнения кода (при условии использования ssd как оперативной памяти). Помню, Интел рассказывал про разные варианты развития 'external PCI-E'. Если победил только NVM, ок. Хотя там вкусности показывали, вроде межблочных кабелей с пропускной способностью PCI-Ex16.
SSD как оперативка — это Сандиск показывает. Требует допиливания прошивок платформ и не выдается ничем, кроме латентности. IOPS и скорость чтения/записи от SAS SSD. Нишу найдет, но при такой производительности и доступности 128GB планок памяти — подозреваю, что ниша будет невелика.

Интел в NVMe входит, поддерживает и развивает. Межблочные кабели возможны, уже сейчас всякие коммутатородеятели ими пользуются для стекирования.
В принципе, так как NVMe поддерживает MPIO, то можно даже дисковые полки делать, но один шнурок окажется узким местом — уже 6 дисков полностью его забивают, а полку можно сделать на 24. Много шнурков? Кабельное хозяйство будет весьма проблематичным.
Не-не-не, там всё сложнее. ELF же. Сама технология называется XIP, и там проблемы больше в районе софта, а не железа.

Во, нашёл статью: lwn.net/Articles/135472/

Да, главное различие XIP'а и RAM в том, что в XIP'е просто нет volatile памяти. Как данные положили, так они и лежат.
Мы с разных позиций рассматриваем :)
XIP не привязан к физическому интерфейсу как таковому.

Статья все таки непосредственно про интерфейсы, которые имеют наибольшую перспективу. С NVMe боролся SCSI Express, но не выдержал, других замечено не было.
О, да, вспомнил, SCSI express. Помер, значит…
Не совсем, но широкой поддержки, на мой взгляд, не получит.
этак и ФантомОС в жизнь пойдет с такими технологиями
Кстати, в современных системах BIOS хранится в flash-памяти. То есть в южном мосте должен быть контроллер NAND Flash. Почему бы его не задействовать для создания ssd-накопителя?
Емнип, там обычный (и не очень) SPI, что очень медленно будет.
Они на ногах экономят? Вроде NAND-память была дешевле, чем SPI.
Подкинуть бы эту идею разработчикам чипсетов… :-)
NOR и SPI флеш ценны другим — малое количество контактов, высокая живучесть и низкая стоимость применения, потому и используются для хранения прошивок.
В южном мосте БИОС не хранится, он хранится на внешней микросхемке, которая подключена по SPI. Т.к. смысла реализовывать флеш на дефицитной площади кристалла нет, ибо код всеравно загружается в оперативку и там исполняется.
Код PEI исполняется прямо из микросхемы, т.к. в момент его исполнения память еще не инициализированна. Чипсет отображает микросхему SPI по адресу 0xFFFFFFFF и ниже, выполнение кода начинается с адреса 0xFFFFFFF0, и обычно там пара нопов и переход на начало секции кода в ядре PEI.
Именно поэтому для PEI-драверов должно быть выполнено требование executable-in-place, т.е. адреса всех переходов должны быть пропатчены заранее, а не при запуске.
Что-то мне подсказывает, что он не отображает её а копирует в память в процессе начальной инициализации, а потом уже передается управление на загрузчик. Отображать кусок памяти с прямым доступом по SPI чрезвычайно накладно. Впрочем, проверить это несложно — достаточно в БИОС добавить модуль который пытается затереть свою же область памяти и выдает на экран результат этого действия.
Да, в принципе сделать это можно и другим способом — логическим анализатором подцепится к интерфейсу и посмотреть на интенсивность обмена с микросхемой в процессе начальной загрузки.
Boot Firmvare Volume не отображается в оперативную память, ибо памяти этой просто нет еще на данном этапе инициализации.
Вот тут есть хорошее описание процесса загрузки UEFI с самого начала.

Я говорю вот об этом:
From the reset vector, execution starts directly from nonvolatile flash storage. This operating mode is known as execute-in-place.
А вы — об этом:
The read performance of nonvolatile storage is much slower than the read performance of DRAM. The performance of code running from flash is therefore much lower than code executed in RAM. Most firmware is therefore copied from slower nonvolatile storage into RAM. The firmware is then executed in RAM in a process known as shadowing.
На самом деле, там еще до копирования в память часть данных копируется в кэш 2 уровня, для которого затем включается No-Eviction Mode (NEM).
Тем не менее, часть кода, хоть и небольшая, действительно исполняется прямо из микросхемы.
Использование протокола QuadSPI дает пропускную способность микросхемы до 40 Мбит\с со временем доступа в 12.5 нс, конечно это намного медленнее RAM, но не настолько, чтобы было заметно человеку.
>>Boot Firmvare Volume не отображается в оперативную память, ибо памяти этой просто нет еще на данном этапе инициализации.

Зато есть CAR (Cache as RAM), чем и Legacy БИОС и Сoreboot, пользовались с момента ее (CAR) появления
Зарегистрируйтесь на Хабре, чтобы оставить комментарий