Вы не любите кошек?! вы просто не умеете их готовить !! ( см. coreboot)

кто угощал и чем?

Не, нормально. Жаль, что я не в состоянии задать вопрос... Ну, еще увидимся.
P.S. И что ж они там шаманят... Пару "русских" BIOSов на базе Openbios я припомню, "menlow" - надо гуглить.

bios71
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" вставить в код .. а дальше?

.... пока не разобрался , наверно я еще очень молодой линуксоид

но вообще говорят , что это дело вкуса - использовать отладчик или отладочную
печать (которая и так присутствует в изобилии.)

продолжение следует

последним актом на тестирование возможностей coreboot стала USB отладка

сама по себе вещица не очень модная, в основном из-за цены, это вам не вам не 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 побежит дальше

с удовольствием добегаем до последнего посткода и прыгаем в полезную нагрузку

Таким образом coreboot неплохо оживляем на абсолютно ЛЮБОМ железе Menlow,
_______________________________________ ^^^^^^^^^^^^^^^^^ _______ ^^^^^^^^^^

менее чем за месяц, лохом в Линуксе и coreboot, к которым я себя отношу
___________________ ^^^^^^^^^^^^^^^^^^^^^^^^^^

А знание выше описанных "мелочей" позволяет оживлять за считанные дни
(подразумевается: наличие программатора для ROM, или хотябы панельки для горячей замены ROM)

PS: в планах портирование coreboot на железо - Queensbay ( Tunnelcreek + Topcliff)
edc.intel.com/Platforms/Atom-E6xx/

молодцы ребята ... хорошо развивают coreboot
altell.ru/products/hyperbios.html

особенно впечатлило .."поддерживаемые современные чипсеты аппаратных платформ: ..., Intel Q35, Intel QM57, Intel PM55. "

об этом coreboot и не мечтает .. раздавая свой код

А что известно о том что они используют? Владельцев прав на код (то бишь авторов) очень интересует сей момент... Даже бинарник попрет для анализа.

Угу, особенно в совокупности с фото SST39SF020A .

"что они используют?" - мне кажется ключевой фразой ... (т.е. в НАСТОЯЩЕМ времени)

учиться они могли конечно и на coreboot ( успешно "похоронив" учебные проекты), а вот имея/получив доступ к оранжевым книгам от Интел ...
посади студента и он нарисует вам с чистого листа

+ у них гипервизор интегрирован
+ SMM/ACPI должны быть "красивыми", а не как попало (линукс небось переварит и их "обрезанную" версию) для Windows

PS: вы же не будете требовать опубликования моих писем, на основаниии того что я "видел буквы кирилицы в вашем документе" и в последующей жизни (о ужас) буду писать такими же

если там ФСБ и ФСТЭК замешано, то можно про GPL смело забыть.

Почему? Если ДЛЯ ФСБ - еще возможно. А если сертификация - ФСБ и ФСТЭКу глубоко фиолетово, под какой лицензией сертифицируемый продукт.

время загрузки Menlow на моём железе - 2.27 секунды
результаты хотя радуют, но будут похоронены (в угоду основным игрокам БИОСного рынка)

2 sam_k "...емкость памяти у Вас составляет 2048М, думаю в этом и состоит моя основная проблема. Количество используемой памяти у меня составляет 512М,..."

памяти у меня 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 тоже все как напаянная, а по факту - планка в слоте, просто я знаю что для нее нужно, потому как цель была показать работоспособность методики, но можно покапаться и глубже

"05.04.2012 09:06 Компания Google обеспечила в CoreBoot поддержку Intel Sandy Bridge и Ivy Bridge "
opennet.ru/opennews/art.shtml?num=33535

ждем-с, когда ето можно будет пощупать ... и как там будет с AМT ... пытались совсем без АМТ, работает ...первые 30 минут, потом срабатывает защита от кражи т.е. перезагрузка

Sandy Bridge и Ivy Bridge код оказывается уже "внутри", какой-то, это важно ("какой-то")

оживить в принципе можно(до какого-то этапа), но не для простых смертных

для начала вспомним что у нас 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
.......

см.
code.google.com/p/chromium-os/issues/attachmentText?id=34043&aid=340430000...

но и просматривались их "костыли": 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"
.............

см.
groups.google.com/a/chromium.org/forum/?fromgroups#!msg/chromium-os-checki...

судя по методике "оживления", биос (?? или u-boot??) оживляется под виртуальной машиной , а как скорее всего под ней и отлаживается, а как быть с реальным железом ??

т.е. чтото у них получилось, но к coreboot это пока имеет слабое отношение

А как установить coreboot на материнскую плату MS-7715 MSI

870-C45 (FX) V2