Вообще-то я тоже их (т.е. его " coreboot") не умею готовить, но кое- какие рецепты у меня уже есть и я решил ими поделиться ...
Изначально к coreboot я относился скорее негативно, и причина более чем банальна - он практически не поддерживает Интел, а то, что поддерживает ужасно старо (не пинайте сильно - но я подразумеваю в виду позицию разработчика coreboot, а не пользователя/прошивателя ).
Нет, ну где я буду искать старые Интелы? (темболее под них "все" налажено) А вот с новыми - проблема. :( нет, все таки есть Атом/i945/ICH7 - но тут мне не повезло "мое" железо не имеет СОМ портов, а отлаживать/оживлять через что-то надо :( .
И вот о, чудо! в конце 2010 умельцы из Индии обьявили о поддержке Menlow !!!! AtomZ530/SCH(US15w )/DDR2 !!!
Все !!! Звезды сошлись, такое пропустить нельзя!!! Подобное железо лежит на столах уж с год.
Начало великого пути осложнялось мелочью, coreboot - это Линукс, а БИОСо-писатели, увы, виндозники. На сайте coreboot по этому поводу присутствует "Геттинг стартет" и "Буилд фром Виндовс" с рекомендацией поставить под виндой "msys+mingw". Кое что я даже сумел сделать ("msys+mingw"), но потом повернул в сторону Линукса.
Курс молодого бойца - и первый линукс предо мной, скачанные исходники coreboot, - и первый собранный ROM прошит в FWH. Тут начались грабли, меня не кто не предупредил, что CONFIG_CBFS_PREFIX просто обязан быть "fallback" , изза чего железо упрямо висло на посткоде 0х10 (когда нибудь я конечно научусь его менять - на мне нужный .. если понадобится ;) ) и после прыжка в защищенный режим правильная "сигнатурка" не находилась.
Потом началась специфика Menlow, СМС код, настройка чипсета/памяти до(!!!!)прыжка на 0xFFFFFFF0, индийцы-то настроили память на 1Gb и напаянной на железку, т.е если СМС код все таки есть (а я его подсунул на этапе создания ROM) то после включения мы прыгнем на 0xFFFFFFF0 и неплохо отработаем в CAR (cache as ram), но придет время инициализировать память а мой СМС код скажет "память на планке, смотри SPD", а coreboot у индийцев с напаянной , приходится править. Кстати, в этом месте у меня первый раз возникла мысль о саботаже в коде, а именно есть место в коде где мы берем параметры памяти из СМС : SOFTSTRP(base, 0x8702) src\northbridge\intel\sch\raminit.c вроде все логично, но под отладчиком вижу - мы берем содержимое адреса базы и к нему прибавляем х8702 получается чушь, а не параметры памяти. Пришлось жестко вбить параметры своей памяти. ...побежали пост коды дальше. ;)
Вторые грабли появились на распределении PCI ресурсов, мы их упорно пытались распределить для LPC хаба (Bus0:Dev1F:Funk0) и уходили в вечный цикл:
seach_bus_resources() в src\devices\device_util.c
пришлось добавить проверку на конкретное PCI устройство и его игнорировать при распределении ресурсов :( .
Наконец все пост коды добегали до конца ... но потребовалась полезная нагрузка ... payloads (на операционку пока не замахнулся ... позже)
В качестве payloads выбрал coreinfo.elf (payloads\coreinfo\build) но в него не входим ... умираем "в момент прыжка в него"это видно в отладчике ...
см. jmp_to_elf_entry() в src\arch\x86\boot\boot.c а именно ...
/* Jump to kernel */
__asm__ __volatile__(
.....
" jmp *%%eax\n\t" вроде как должен прыгнуть по логике на следующую строку ?
"1: /n/t"
а фактически прыгает сам в себя (?! сама команда jmp - 2 байта, а прыгаем на 1!! а что счетчику команд пофиг :( ) из-за чего крушится вся последовательность команд, и пытаясь "идти по каше" уходим в "вечность" :(
собственно весь рассказ к чему ... осваивайте coreboot, все в ваших руках, для чего coreboot и затевался - исходники пред вами ;)
имея "подобное" железо имеет смысл дерзать, задавать "глупые" и не очень вопросы, действуя на тропе популяризации coreboot в русскоговорящем сегменте интернета
;) ;) ;)
перепечатка, ссылки, вопросы, предложения, критика и пр. по теме - всемерно приветствуется
P.S. И что ж они там шаманят... Пару "русских" BIOSов на базе Openbios я припомню, "menlow" - надо гуглить.
IMHO проще сразу привести весь нужный кусок кода:
/* Save the parameters I was passed */ " pushl $0\n\t" /* 20 adjust */ " pushl %0\n\t" /* 16 lb_start */ " pushl %1\n\t" /* 12 buffer */ " pushl %2\n\t" /* 8 lb_size */ " pushl %3\n\t" /* 4 entry */ " pushl %4\n\t" /* 0 elf_boot_notes */ /* Compute the adjustment */ " xorl %%eax, %%eax\n\t" " subl 16(%%esp), %%eax\n\t" " addl 12(%%esp), %%eax\n\t" " addl 8(%%esp), %%eax\n\t" " movl %%eax, 20(%%esp)\n\t" /* Place a copy of coreboot in its new location */ /* Move ``longs'' the coreboot size is 4 byte aligned */ " movl 12(%%esp), %%edi\n\t" " addl 8(%%esp), %%edi\n\t" " movl 16(%%esp), %%esi\n\t" " movl 8(%%esp), %%ecx\n\n" " shrl $2, %%ecx\n\t" " rep movsl\n\t" /* Adjust the stack pointer to point into the new coreboot image */ " addl 20(%%esp), %%esp\n\t" /* Adjust the instruction pointer to point into the new coreboot image */ " movl $1f, %%eax\n\t" " addl 20(%%esp), %%eax\n\t" " jmp *%%eax\n\t" "1: \n\t"Смещение в 20(%%esp) чему равно?
в системе присутствует только 1Гиг памяти
а пытаемся себя копировать под конец 4ёх там естественно все
забито FF(1. Смещение в 20(%%esp) чему равно? => 0xFFFF FFFFF :( )
см. лог:
Loaded segments
Jumping to boot code at 100000
POST: 0xfe
entry = 0x00100000
lb_start = 0x00100000
lb_size = 0x00034000
adjust = 0xffecc000 <--------------------------!!!!
buffer = 0xfff95050 <---------------------------!!!
elf_boot_notes = 0x0011b778
adjusted_boot_notes = 0xfffe7778 <----------------------!!!
см. src\boot\selfboot.c
/* Maximum physical address we can use for the coreboot bounce buffer.
*/
#ifndef MAX_ADDR
#define MAX_ADDR -1UL <------------------------!!!!!!!!!! :(
#endif
после корректировки до реальных значений ... "полезная нагрузка" заработала!!
coreboot система правильная в ней даже присутствует GDB (или точнее "gdb")
и ключик для его активации в файле .config
#
# Debugging
#
CONFIG_GDB_STUB=y
правда при пристальном рассмотрении выясняется что "gdb" таки активируется
когда ключик стоит равен "1" ... или это особенности линукса и мне к ним пора бы и привыкнуть .. ну да ладно пусть будет "1" ... лишь бы работало
пришлось откопать gdb на хостовой машине и запустить примерно так:
stty 19200 -F -dev-ttzS0 ; это я скорость правильную устанавливаю
gdb
(gdb)symbol-file /home/sism/coreboot/build/coreboot_ram
;тут радостный всклик gdb ... что coreboot_ram найден и по нему найден coreboot_ram.debug
(gdb)target remote /dev/ttyS0 ; что собственно дебажить т.е. СОМ порт
могу даже поставить точку останова !!
(gdb)break hardwaremain ; в ответ "все ок" поставлена на строке 57 !
(дальше gdb начинает работоть в режиме печатной машинки - "набирай что хочешь, но в ответ тишина" :( , в порте слышны "$qSupported#37", 4 раза, "$?#3f"", 4 раза, и пр. )
но тут я в логическом тупике ... а что дальше??
нет ... в коде coreboot конечно присутствует замечательная "gdb_stub_breakpoint"
с который ведет в итоге на "call x86_exception" в котором и идет коммуникация
с gdb (а не слишком ли скромна его реализация в coreboot - поймет ли его gdb?)
по логике надо из ассемблера (например из c_start.c) "call gdb_stub_breakpoint" ???
(сначала выключить весь "левый" вывод в порт вроде посткодов и отладки,
тогда coreboot кидает в порт только прекрасные "$S02#b5" по циклу)
или из "С" снова ассемблер: __asm__ volatile "call gdb_stub_breakpoint" ???
как вариант можно попробовать "int 3" вставить в код .. а дальше?
.... пока не разобрался , наверно я еще очень молодой линуксоид
но вообще говорят , что это дело вкуса - использовать отладчик или отладочную
печать (которая и так присутствует в изобилии.)
продолжение следует :)
сама по себе вещица не очень модная, в основном из-за цены, это вам не вам не 3х рублёвый UART кабель, (т.е. рубли европейские), "синяя коробочка" (PLXTech) стоит сотку , а фирменная АМИ-шная "красная коробочка" все полторы тысячи (всё тех-же европейских).
Но каков ее потенциал для embedded просторов (где в основном отсутствуют SuperIO - но оживлять/отлаживать их таки надо)!!
...
для начала простейший метод "прослушки":
- minicom под линуксом должен "слушать" - ttyUSB0 (115200 и пр.)
ttyUSB0 - появляется после подключения красной/синей коробочки к хост машине
после сборки coreboot c ключом - CONFIG_USBDEBUG=y
я сразу увидел хоть чтото на хост машине из ttyUSB0, это чтото было мешаниной реальной отладки/консоли
чтобы тексты приобрели человеческий вид пришлось добавить задержку на посылке
каждого символа, это помогло ... текст стал читаем
отладка обрывалась перед прыжком в RAM из CAR
оно и логично при отсыке символов мы пользуемся структурой лежащей в CAR
а кто ее будет копировать в RAM ? т.е. в "dbgp_init(void)" из src/console/usbdebug_cinsole.c
мы пытаемся копировать чтото от кудато, но в итоге получаем чтото левое чем нельзя пользоваться и вавод отладки , а с ним и процесс загрузки благополучно
умирает :(
если в "dbgp_init" по рабоче-крестьянски вбить в структуру - то что там должно
лежать ... загрузка , а с ней и отладка по USB побежит дальше :)
с удовольствием добегаем до последнего посткода и прыгаем в полезную нагрузку
8-)
Таким образом coreboot неплохо оживляем на абсолютно ЛЮБОМ железе Menlow,
_______________________________________ ^^^^^^^^^^^^^^^^^ _______ ^^^^^^^^^^
менее чем за месяц, лохом в Линуксе и coreboot, к которым я себя отношу ;)
___________________ ^^^^^^^^^^^^^^^^^^^^^^^^^^
А знание выше описанных "мелочей" позволяет оживлять за считанные дни
(подразумевается: наличие программатора для ROM, или хотябы панельки для горячей замены ROM)
PS: в планах портирование coreboot на железо - Queensbay ( Tunnelcreek + Topcliff)
http://edc.intel.com/Platforms/Atom-E6xx/
http://www.altell.ru/products/hyperbios.html
особенно впечатлило .."поддерживаемые современные чипсеты аппаратных платформ: ..., Intel Q35, Intel QM57, Intel PM55. "
об этом coreboot и не мечтает .. раздавая свой код ;)
учиться они могли конечно и на coreboot ( успешно "похоронив" учебные проекты), а вот имея/получив доступ к оранжевым книгам от Интел ...
посади студента и он нарисует вам с чистого листа
+ у них гипервизор интегрирован
+ SMM/ACPI должны быть "красивыми", а не как попало (линукс небось переварит и их "обрезанную" версию) для Windows
PS: вы же не будете требовать опубликования моих писем, на основаниии того что я "видел буквы кирилицы в вашем документе" и в последующей жизни (о ужас) буду писать такими же
:roll:
результаты хотя радуют, но будут похоронены (в угоду основным игрокам БИОСного рынка)
:-(
памяти у меня 1Гбайт, а 512Мбит/1024Мбит/2048Мбит это БИТЫ, SoftStrap манипулирует битам, т.е. ее организация 256Мбайт/512Мбайт/1Гбайт
и 87F1h
Bit[7] - Rank1 Enable
Bit[6:5] Rank 1 Geometry 01b - 512Mbit
........................ 10b - 1024Mbit
........................ 11b - 2048Mbit
Bit[4] Rank 1 Width 0b - x8
......................... 1b - x16
Bit[3] - Rank 0 Enable
Bit[2:1] Rank 0 Geometry ....
Bit[0] Rank 0 Width ....
может у вас х8/х16 не правильно выставлен ?? помните !!! СМС не в байтах, а в БИТАХ !!
в моем СМС выбрано/установлено, что память у меня напаянная, в raminit.c тоже все как напаянная, а по факту - планка в слоте, просто я знаю что для нее нужно, потому как цель была показать работоспособность методики, но можно покапаться и глубже
http://www.opennet.ru/opennews/art.shtml?num=33535
ждем-с, когда ето можно будет пощупать ... и как там будет с AМT ...
оживить в принципе можно(до какого-то этапа), но не для простых смертных
для начала вспомним что у нас SPI флешка и не просто а в дескрипторном режиме,
в предыдущих чипсетах можно было "забыть" включить режим дескриптора , тогда "все" считалось биосом, тут такой номер не пройдет, биос просто не найдется :-(
(привет СМС коду в Атомах)
итак дескрипторный режим помогает софт-стреппу чипсета и нахождению биоса и ОООО счастье мы хоть что-то видим на терминале, в общем кашу .... :-(
оно и понятно, ведь клок-генератор не настроен, придется добавить МЕ код, настройка клока в нем
и так первый членораздельный текст:
coreboot-4.0-2770-g645f2dd-dirty Wed Sep 12 11:34:10 CEST 2012 starting...
Setting up static southbridge registers... done.
Disabling Watchdog reboot... done.
Setting up static northbridge registers... done.
Initializing Graphics...
Back from sandybridge_early_initialization()
POST: 0x38
SMBus controller enabled.
POST: 0x3a
CPU id(306a9): Intel(R) Core(TM) i7-3610QE CPU @ 2.30GHz
AES supported, TXT supported, VT supported
PCH type: QM77, device id: 1e55, rev id 3
Intel ME early init
Intel ME firmware is ready
ME: Requested 32MB UMA
Starting UEFI PEI System Agent
Read scrambler seed 0x00000000 from CMOS 0x70
Read S3 scrambler seed 0x00000000 from CMOS 0x74
find_current_mrc_cache: MRC cache not initialized?
prepare_mrc_cache: at ffb70010, size ffffffff checksum ffffffff
CBFS: Looking for 'mrc.bin'
CBFS: found.
MyLog: call mrc.bin by address: 0xFFFA0000
в вечном цикле :-(
проект собран по стандартной конфигурации: Intel/Emerald Lake2/8Mb (Ivy Bridge)
в ней MRC.BIN (инициализация памяти) находится по адресу 0xFFFA0000
если мы подкорректируем ее до 0xFFFE0000 т.е. как в Sandy Bridge
то увидим чуть больше но все равно умрем т.к. память не проинициализировалась
coreboot-4.0-2770-g645f2dd-dirty Wed Sep 12 11:34:10 CEST 2012 starting...
Setting up static southbridge registers... done.
Disabling Watchdog reboot... done.
Setting up static northbridge registers... done.
Initializing Graphics...
Back from sandybridge_early_initialization()
POST: 0x38
SMBus controller enabled.
POST: 0x3a
CPU id(306a9): Intel(R) Core(TM) i7-3610QE CPU @ 2.30GHz
AES supported, TXT supported, VT supported
PCH type: QM77, device id: 1e55, rev id 3
Intel ME early init
Intel ME firmware is ready
ME: Requested 32MB UMA
Starting UEFI PEI System Agent
Read scrambler seed 0x00000000 from CMOS 0x70
Read S3 scrambler seed 0x00000000 from CMOS 0x74
find_current_mrc_cache: MRC cache not initialized?
prepare_mrc_cache: at ffb70010, size ffffffff checksum ffffffff
CBFS: Looking for 'mrc.bin'
CBFS: found.
MyLog: call MRC.BIN by address : 0xFFFE0000
System Agent Version 18.52.86 Build 120
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : NO
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: Current Working State : Normal
ME: Current Operation State : Bring up
ME: Current Operation Mode : Normal
ME: Error Code : No Error
ME: Progress Phase : BUP Phase
ME: Power Management Event : Pseudo-global reset
ME: Progress Phase State : Waiting for DID BIOS message
Save scrambler seed 0x00000000 to CMOS 0x70
Save s3 scrambler seed 0x00000000 to CMOS 0x74
POST: 0x3b
POST: 0x3c
POST: 0x3d
POST: 0xea
RAM INIT FAILURE!
в общем проект еще сильно сыроват даже для людей с опытом, почему и не присутствует в "официально поддерживаемых" чипсетах/процессорах, хотя и раструбили об этом интернетчики/линуксоиды на радостях
судя по "их" логам:
chronos@localhost / $ cat /sys/firmware/log
coreboot-4.0-r#72f4570 Mon Mar 12 12:52:22 PDT 2012 starting...
Setting up static southbridge registers... done.
Disabling Watchdog reboot... done.
Setting up static northbridge registers... done.
Waiting for MCHBAR to come up...ok
Initializing Graphics...
Back from sandybridge_early_initialization()
SMBus controller enabled.
Intel ME early init
Intel ME firmware is ready
ME: Requested 8MB UMA
Starting UEFI PEI System Agent
Read scrambler seed 0x0000272f from CMOS 0x70
Read S3 scrambler seed 0x0000cac5 from CMOS 0x74
CBFS: Looking for 'u-boot.dtb'
CBFS: found.
prepare_mrc_cache: at ff9ed010, entry 1 size b50 checksum 1c7c
CBFS: Looking for 'mrc.bin'
CBFS: found.
System Agent Version 1.2.2 Build 0
.......
см.
http://code.google.com/p/chromium-os/issues/attachmentText?id=34043&aid=340430000001&name=sys_fimware_log&token=FwGw9rnDcDoUkx5Ii_vWtWbxMII%3A1346338388490
но и просматривались их "костыли": CBFS: Looking for 'u-boot.dtb'
которые позже решили убрать т.е. вылизать код, но получилось как всегда ...
методика пользования костылями так же частично описана:
TEST CASE 1 - newly flashed image:
1) Install the new bios with flashrom and reboot
2) Check that no MRC data was found by Coreboot in firmware log:
"prepare_mrc_cache: invalid MRC data"
3) Check that U-boot wrote training data in firmware log:
"handle_mrc_cache: cached storage mismatch (-1/2895)"
"firmware_storage_spi: before adjustment"
"firmware_storage_spi: offset: 0x1ec000"
"firmware_storage_spi: length: 0xb58"
"firmware_storage_spi: after adjustment"
"firmware_storage_spi: offset: 0x1ec000"
"firmware_storage_spi: length: 0x1000"
"firmware_storage_spi: offset: 0x001ec000"
"firmware_storage_spi: adjusted offset: 0x001ec000"
4) Check the flash to see if it has data in first slot
> flashrom -r /tmp/bios.now
> hexdump -Cv -s $((0x1ec000)) -n $((0x10000)) /tmp/bios.now
TEST CASE 2 - ensure that it uses the saved training data:
1) Reboot
2) Check that Coreboot used the training data in firmware log:
"prepare_mrc_cache: at ff9ec009, entry 0 size b4f checksum 9c"
3) Check that U-boot did not have to update the data in firmware log:
"handle_mrc_cache: cached storage match"
4) Check the flash to see if it still only has data in first slot:
> flashrom -r /tmp/bios.now
> hexdump -Cv -s $((0x1ec000)) -n $((0x10000)) /tmp/bios.now
TEST CASE 3 - ensure that it fills the next slot with new data:
1) Corrupt the seed checksum in CMOS:
> io_write8 0x70 0x78
> io_write8 0x71 0x00
2) Reboot
3) Check that Coreboot did not use cached data in firmware log:
"prepare_mrc_cache: invalid seed checksum"
4) Check that U-boot wrote new training data at new offset in firmware log:
"handle_mrc_cache: cached storage mismatch (2895/2895)"
"firmware_storage_spi: before adjustment"
"firmware_storage_spi: offset: 0x1ed000"
"firmware_storage_spi: length: 0xb58"
"firmware_storage_spi: after adjustment"
"firmware_storage_spi: offset: 0x1ed000"
"firmware_storage_spi: length: 0x1000"
"firmware_storage_spi: offset: 0x001ed000"
"firmware_storage_spi: adjusted offset: 0x001ed000"
.............
см.
https://groups.google.com/a/chromium.org/forum/?fromgroups#!msg/chromium-os-checkins/qtwrXh6ensY/IgccUsOx2lUJ
судя по методике "оживления", биос (?? или u-boot??) оживляется под виртуальной машиной :-( , а как скорее всего под ней и отлаживается, а как быть с реальным железом :-( ??
т.е. чтото у них получилось, но к coreboot это пока имеет слабое отношение
870-C45 (FX) V2