[freebsd] 13.0 memstick не грузится

Valentin Nechayev netch at netch.kiev.ua
Fri Dec 31 22:52:51 EET 2021


hi,

 Fri, Dec 31, 2021 at 17:28:29, spell wrote about "Re: [freebsd] 13.0 memstick не грузится": 

> Агаааа, вот оно что.
> А в dmesg.boot сообщения между real memory и available memory - это этот же список
> доступных сегментов?

Да.

> Интересно, почему мой биос подробил память аж на 6 кусков (в вашем примере всего 3).

Модели разные. Объём памяти разный. Модули памяти разного состава...

Если подробно, то картина выглядит так. В x86 сохраняется
совместимость с
1) 16-битным режимом и границей доступной памяти в 1MB;
2) 32-битным режимом и границей доступной памяти в 4GB.

Первое приводит к тому, что адреса 0xA0000-0xFFFFF (кусок между
первыми 640kB и границей 1MB) розданы исторически, ещё от первых IBM
PC, под видеопамять старых режимов и под BIOS (реально под RAM, в
которую скопирована часть BIOS). Кроме того, несколько первых и
последних килобайт занято под данные BIOS (включая ACPI).

Второе аналогично выглядит так, что часть адресов ниже границы 4GB
занято под спец. роли: например, local APIC ядра процессора - от
0xFEE0_0000 до 0xFEE0_0FFF. Менять это тоже не хотят.
Некоторые устройства могут так же требовать себе области памяти в
32-битной адресации (ниже 4GB), это можно определить прочитав их PCI
конфигурацию.

Теперь... представим себе 8GB RAM одним модулем. Если бы можно было
разместить его связным куском, он был бы от 0 до 0x1_FFFF_FFFF. Но
описанные требования приводят к тому, что
1) должен быть максимум в интервале от 0 до 0x9FFFF (те самые 640kB),
с потерей на данные BIOS, которые должны быть доступны и в реальном
режиме;
2) должен быть разумный объём (а для 32-битных систем - максимум) от
0x10_0000 до, например, 0xDFFF_FFFF (например - может быть больше или
меньше);
3) всё остальное должно быть представлено выше границы 4GB и максимум
от того, что осталось от выделения под видеопамять, shadow BIOS и всё
такое (терять больше условно 1MB тут нежелательно, обидятся).
4) устройство должно быть как можно проще с точки зрения контроллера
памяти (никаких сложений-вычитаний адресов, только изменение отдельных
битов).

И вот надо сделать чтобы вывалившиеся 512MB ниже 4GB были всё-таки
доступны выше. Один из вариантов: сделать чтобы участок 8GB-16GB
контроллером памяти мапился в тот же модуль, а через карту памяти BIOS
запретить софту доступ к нему. Тогда получится карта вида:
1) 0x1000-0x9EFFF (4kB в начале и в конце BIOS откусил под данные);
2) 0x10_0000-0xDFFF_FFFF (регулярный доступ, откушено 512MB на адреса
устройств);
3) 0x1_0000_0000-0x1_FFFF_FFFF (регулярный доступ к остатку модуля);
4) 0x2_E000_0000-0x2_FFFF_FFFF (512MB которые не доступны в первых
4GB, доступны здесь).
При этом в контроллере памяти включена логика вида: участки
0-0x1_FFFF_FFFF и 0x2_0000_0000-0x3_FFFF_FFFF одинаково отображены на
один и тот же модуль (но у первого выкушены приоритетно 2 диапазона
под I/O), и если просто сканировать их - получится вроде бы 16GB, но
BIOS знает, что реально второй идентичен первому, и разрешает из него
только тот кусок в 512MB, который "обошли" в первом 8GB.

А на другой машине вдруг окажется, что, например, установлены модуль
на 8GB и модуль на 16GB, причём BIOS решил замапить с нуля тот, что
16GB. Тогда он замапит этот 16GB дважды, из второго отображения
разрешит те же 512MB, а 8GB модуль замапит с адреса 0x8_0000_0000
(32GB) и уже только один раз.

И с каждой новой версией северного моста (последние 10-12 лет
интегрирован в процессор) эта логика может чуть меняться. Ну и ревизии
BIOS могут её менять.

Гуглить можно по аббревиатурам типа TOLUD, TOUUD, документам типа "10th
Generation Intel Core Processor Families datasheet" и т.п. - там это
всё расписано подробнее.

И таки с Новым годом всех :))


-netch-


More information about the freebsd mailing list