исследования продолжаются ... coreboot система правильная в ней даже

исследования продолжаются ...

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

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

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

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