31 декабря 2021 г., 22:52, "Valentin Nechayev" <ne...@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 вышел из чата. _______________________________________________ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd