On Tue, May 5, 2009 at 9:06 AM, ron minnich rminnich@gmail.com wrote:
On Tue, May 5, 2009 at 5:29 AM, Myles Watson mylesgw@gmail.com wrote:
Someone needs to fix remove then. Right now it moves all entries after it and zeroes the new space. I guess most of my confusion came from the implementation/design gap.
I think it was my confusion, not yours :-)
But I think we have to have clean support for XIP in ROM, which means we have to have a way for cbfs to place a block of code in a designated place.
So can we force the compiler to make everything inside a block relative so that it can be position-independent?
I like the idea of having the ROM stages visible in cbfs.
So do I.
If we are certain we don't need XIP then we don't need this patch. But if we have XIP we can remove some fairly confusing __asm__ code in failover, as well as the attendant load scripts.
Does a normal image need to be XIP?
Also, since the stage header has the entry point as well, we get rid of the need to have a reset vector at the end of the normal and failover ROM images -- a much cleaner way to go.
Yes.
Some suggestions:
- adopt a coarser granularity. Were we to adopt, e.g., 512B as a block
size, then at most the walking code would have to check 4096 items on even a 2 Mbyte ROM (as opposed to the current 128K items)
- zero fill
- NEXT pointer
All of these will work.
I think this is the easy part. The harder problems have to do with what we want to allow to be constrained to a specific location. The fewer of those the better to me.
Thanks, Myles