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

[spell at itl.ua]

31 декабря 2021 г., 22:52, "Valentin Nechayev" <netch at netch.kiev.ua> написал:

> 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 могут её менять.

Разобралась, но это же кошмар...
Принцип KISS вышел из чата.