On Tue, Apr 03, 2018 at 06:32:07PM +0300, Kyösti Mälkki wrote:
[...]
I'm dealing an early bring-up problem on a modern architecture without serial ports and wondering if that would a good way to debug it.
Probably M.2 is not very useful for you... try to look for LPC signals, some boards have TPM add-on connector with the required signals for POST display.
That's a good idea, although on this board the TPM is very hard to get to, which is nice for moderate physical security, but not great for debugging. I'm bummed that the LPC lines aren't brought out to the M.2 and MiniPCIe; perhaps I'll find an alternate use of the boards when they arrive.
What ended up working for me was the PC speaker since there is no other I/O available so early. I'd really like to thank Uwe Hermann and the other devs of libpayload/speaker.c -- I was able to port their driver functions to execute very soon after the reset vector and confirm code execution with beeps and busy waiting.
On Tue, Apr 3, 2018 at 2:30 PM Trammell Hudson hudson@trmm.net wrote:
What ended up working for me was the PC speaker since there is no other I/O available so early. I'd really like to thank Uwe Hermann and the other devs of libpayload/speaker.c -- I was able to port their driver functions to execute very soon after the reset vector and confirm code execution with beeps and busy waiting.
now you've done it. Boot tunes here we come.
On 03.04.2018 23:29, Trammell Hudson wrote:
What ended up working for me was the PC speaker since there is no other I/O available so early. I'd really like to thank Uwe Hermann and the other devs of libpayload/speaker.c -- I was able to port their driver functions to execute very soon after the reset vector and confirm code execution with beeps and busy waiting.
You might have missed `src/drivers/pc80/pc/spkmodem.c` [1].
Nico