Благодарю за ответы. Попробую ответить на возникшие вопросы: В соответствии
Проблемы с ремаппингом при запуске AWARD BIOS на виртуалке
- Что-то подобное может-быть возможно было бы сделать
- Благодарю за ответы. Попробую ответить на возникшие вопросы: В соответствии
- OK просто фраза автора "были в очередной раз
- Ну, я лично фразу автора понял как
- To Savely Я возможно неправильно выразился -
- P.P.S. Ну, что за "старый гигабитовский AWARD" -
- P.S. На мой первый взгляд -
- С утра пытался написать, но трезвость мешала, счас
- Если раньше код по адресу 0xe8000
Прошивка и настройка BIOS, переделка и ремонт материнских плат, БП, видеокарт, HDD.
ROM.by 2002-2014 (c) apple_rom
Благодарю за ответы.
Попробую ответить на возникшие вопросы:
В соответствии с тегами в качестве подопытного был выбран Award BIOS от платы Q35M-S2 . Версия F7. Чипсет - Q35 (в официальной ветке QEMU уже года 2-3 в качестве альтернативы 440-му). Собственно решение задачи запуска реального BIOS на QEMU сводится именно к дописыванию в QEMU недостающей функциональности. В частности в QEMU был неполностью реализован механизм PAM. Из-за этого BIOS зависал сильно раньше. После самодельного исправления - появился определенный прогресс. Очередной затык случился на описанном выше месте. Так как никаких изменений в BIOS не вносилось, то не работать сам по себе он не может, но, зато, QEMU может некорректно имитировать реальную систему, что тут, очевидно, и произошло. Также, все значения которые есть в ОЗУ и в регистрах являются следствием работы QEMU и BIOS, вручную никакие области памяти не менялись.
Переходы в 0xe8000 случались и раньше, но конфигурация PAM была другой, обрабатывался код из ОЗУ. Сейчас исполняется код из флешки и есть мысль что тут что-то не так, как надо. Очередная идея - автор BIOS рассчитывал на те инструкции, которые попали в кэш (в самом QEMU кэш как сущность не очень заметен). Но, во-первых: как это проверить, во-вторых: странным выглядит рассчет на то, что некие данные должны быть в кэше (а если их нет, а если было прерывание и т.д....).
Гугление по адресу 0xe8000, как и по ioport 0xA2 ничего не принесло -не удалось найти упоминаний о том, что это какие-либо особенные значения.
QEMU сейчас вполне корректно интерпретирует значения записанные в PAM и перенаправление в PCI вполне законно с точки зрения логики работы PAM регистров. Но есть подозрение что на маппинг может влиять что-то еще. Что именно - пока не знаю. Думал в сторону MTRR регистров проца, но там задается только политика кэширования, конкретно ремаппингом эти регистры не занимаются.