"Bryan E. Chafy" bchafy@ccs.neu.edu writes:
Apologies if this is a redundant contribution.
None of my pc motherboards have JTAG or HW debug capabilites. And constantly (hot)flashing, changing ram init code, then (hot)flashing again gets old really fast.
:)
romcc helps by reducing typos. But this addresses the problem of understanding what is wrong :)
The other trick that helps is to hard code the memory configuration and put that in the fallback image. And then use a second copy of linuxbios to develop new code. At least that way you don't need to swap the rom chip.
Looking around, I couldnt find any debug tools that would operate at basically the reset vector level. I thought this was the goal of openbios, but I got lost in all the jibberish about 4th and firmware standards.
I think the people who described it as such could not get that low level :) Forth certainly needs memory to work.
So I set out to make a small interactive low level shell with the goal of providing at least some tools to aid in board/memory bringup and debugging. This was nontrivial given the system limitations, however I got a few things to work.
It looks nice. And inspires some more ideas.
Attached is llshell.inc (for linuxbios1, Ive not tried any of the new stuff yet) and llshell_linux (for running/testing inside of linux). It's written entirely in asm and can run in a memoryless early stage (say at the beginning of ram_set_registers or points afterword).
Now if only we can figure out a way to successfully trap exceptions without memory working....
Eric