"Bryan E. Chafy" <bchafy(a)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....