Колибри PE

Kernel architecture questions
  • У меня такой вопрос: "почему именно SASOS?" (как я понимаю, имеется в виду операционная система с единым адресным пространством, вроде DOS)

    P.S.

    На мой взгляд, это является самым главным основанием сомневаться в продолжении "традиций Kolibri OS" !
  • FireWall
    отдельное адресное пространство для каждого приложения - это второстепенная фича,
    Колибри вполне могла бы входить (2-ой головой) и в SAS x64-режим, оставаясь при этом самой собой на 1-й голове.
    там же есть RIP-адресация, во времена DOSа мы и мечтать о таком не могли.

    : двухголовая Колибри :shock: должна внушать мощные галлюциассоциации с известным геральдическим монстром
  • FireWall
    SAS не единое адресное пространство в стиле DOS, а единое пространство адресов. То есть система с неперекрывающимися адресными пространствами и глобальными адресами. Сами адресные пространства изолированы друг от друга таблицами страниц.
    Мне SAS представлялась идеальным вариантом в сочетании микроядро+PE формат исполняемых файлов. Для монолитного ядра преимущества SAS не столь очевидны, но всё равно интересно попробовать.
  • (1) Насколько я понимаю, Kolibri PE сейчас довольно сильно отстаёт от основной версии. Однако уже имеется загрузчик PE-формата, правда 32-х битный. Это так?

    (2) Вы собираетесь отталкиваться от текущей версии Kolibri PE или сначала привести её в соответствие с основной версией?
  • FireWall
    1)Работа остановилась три года назад. Загрузчик РЕ используется в транке для загрузки драйверов. Более продвинутая версия есть в исходниках newlib.
    2)Я хочу полностью поменять проект и делать новое ядро для амд64.
  • Сделал переход в long mode. Если всё пройдёт успешно на экране появится небольшое сообщение.
    Attachments
    kernel.7z (5 KiB)
    Просто скопируйте ядро в kolibri.img
    Downloaded 374 times
  • На одноголовом AMD Sempron 140 отработала зачётно.
    1-я строчка это CPUID, я так тоже умею
    а вот дальше было интересно взглянуть на код.

    скриншот (по понятным причинам :) ) выслать не могу.

    Кстати, а как выводить текст в Long Mode ?
  • Обычный printf :) А текст выводится ручками, в видеопамять.
    Spoiler:Не уверен, что для АМД флаги cpuid совпадают

    int printf(const char* format, ...);

    static void cpuid(u32_t op, u32_t *eax, u32_t *ebx,
    u32_t *ecx, u32_t *edx)
    {
    asm volatile("cpuid"
    : "=a" (*eax),
    "=b" (*ebx),
    "=c" (*ecx),
    "=d" (*edx)
    : "a" (op), "c" (0)
    : "memory");
    }

    void init64(void)
    {
    static char x86_model_id[64];
    u32_t *v;

    u32_t ops=0;

    u32_t _eax, _ebx, _ecx, _edx;

    v = (u32_t *)x86_model_id;

    cpuid(0x1, &_eax, &_ebx, &_ecx, &_edx);
    if( _ecx & 1)
    ops|= 8;
    if( _ecx & (1<<17))
    ops|= 1;
    if( _ecx & (1<<5))
    ops|= 0x10;
    if( _ecx & (1<<28))
    ops|= 0x200;

    cpuid(0x80000001, &_eax, &_ebx, &_ecx, &_edx);

    if( _edx & (1<<26))
    ops |= 2;
    if( _edx & (1<<29))
    ops |= 4;

    cpuid(0x80000002, &v[0], &v[1], &v[2], &v[3]);
    cpuid(0x80000003, &v[4], &v[5], &v[6], &v[7]);
    cpuid(0x80000004, &v[8], &v[9], &v[10], &v[11]);

    printf("Long mode enabled\n");
    printf("%s\n",v);

    printf("%s%s%s%s%s%s",
    (ops & 1)?"PCID supported\n":"",
    (ops & 2) ? "1Gb pages supported\n":"",
    (ops & 8) ? "SSE3 supported\n":"",
    (ops & 0x10) ? "VMX supported\n":"",
    (ops & 0x200) ? "AVX supported\n":"",
    (ops & 4) ? "long mode supportd\n":"");

    printf("System halted");
    asm volatile ("hlt");
    };
    Появились сомнения, писать ли код в Колибри РЕ или стартануть новую ветку, KPE64. Пока буду выкладывать исходники на фтп. Ещё планирую написать несколько постов с подробным описанием процесса инициализации ядра, что к чему, почему и как.
  • Ну, если ручками, да еще и в видеопамять, тогда уж лучше фреймбуфер Колибри использовать, НЕ ?

    а оттуда и скриншоты можно снимать, и логи записывать, и GUI-мессиджи передавать без велосипедов.

    (это я типа еще раз намекнул что) уже существующий сервис 32-битного ядра мог бы очень упростить отладку и тестирование.
  • Ну, если ручками, да еще и в видеопамять, тогда уж лучше фреймбуфер Колибри использовать, НЕ ?
    Не-а. Я же в текстовом режиме гружусь.
    ...уже существующий сервис 32-битного ядра мог бы очень упростить отладку и тестирование.
    В теории да. А на практике двум пернатым в одной берлоге тяжело ужиться. Тем более что сейчас я инициализацию ядра делаю, а для этого лучше монопольный доступ.
  • Я могу и отдельный svn поднять, или git, для KPE64
  • Правильно определил проц i3 330m, long mode enabled.
    Из хаоса в космос
  • The Pentium 4, Intel Xeon, and P6 family processors provide special support for the physical memory range from 0
    to 4 MBytes, which is potentially mapped by both the fixed and variable MTRRs. This support is invoked when a
    Pentium 4, Intel Xeon, or P6 family processor detects a large page overlapping the first 1 MByte of this memory
    range with a memory type that conflicts with the fixed MTRRs. Here, the processor maps the memory range as
    multiple 4-KByte pages within the TLB. This operation insures correct behavior at the cost of performance. To avoid
    this performance penalty, operating-system software should reserve the large page option for regions of memory
    at addresses greater than or equal to 4 MBytes.
    Атрибуты кеширования страницы сохраняются в TLB чтобы не проверять mtrr каждый раз. Первый мегабайт содержит память с разными атрибутами. И для него процессор разбивает большую страницу на маленькие, что приводит к потере производительности.
    Нет ли смысла зарезервировать первые 4 или 2 Мб для PAE и переместить ядро выше ?
  • да, на АМД тоже первый мегабайт - сплошной паркет из Fixed MTRR.
    надо попробовать сдвинуть физ.адрес ядра выше 4М и сравнить производительность.
  • Who is online

    Users browsing this forum: No registered users and 4 guests