Compile problems

[Jason Gunthorpe]

On Mon, 26 Jun 2000, David Woodhouse wrote:

> Lets try to avoid it for a while - presumably anyone who adds a DiskOnChip 
> to an ARM system will do the same thing, so the ReadDOC and WriteDOC macros 
> can be defined accordingly for ARM systems, and we'll bury our head in the 
> sand for a little longer until some nutter comes up with a second method 
> for a given architecture and we can no longer ifdef it. :)

Okay, I'm not sure how popular DOC will be long term, thought their new
parts look kind of nice.. (small physical size and all)

> >   unsigned long bank_size;   // Bytes in a bank. size = bank_size*bank_count 

> > So if you have less than 4 meg of chips you end up with spaces between
> > them and the driver has to advoid them and probe differently.  
> 
> I have the same - 16Mb at 0x0, 16Mb at 0x2000000. But it's aliases, not 
> spaces between them - just to make it more interesting. (And I was told it 
> wouldn't be like that, so when I erased the 'second' chip at 0x1000000 I 
> was actually erasing the firmware... :) 

Yes, aliases is what it always should be, in fact my driver counts on it
:> How it works is they just connect up the necessary address lines and
use the E[0-4] lines as chip selects. Chip selects are generated by a PLD.
I expect more elaborate systems will have a PLD that has configurable bank
size..

Usually I think that anything that is not perfectly linear is either that
way because someone is abusing CPU CS lines, or because they expect to
have the option to install larger chips in future.

> I changed the VM setup to present them to the CPU contiguously. If that wasn't
> possible, I'd have done the mask-and-shift necessary in the map driver. Is

That is only possible if you know the chip size in advance, or are willing
to add APIs to dynamically remap this stuff. I have here a socket, you can
plug whatever you want into it. If that happens to be anything less than a
32 meg part you end up with holes. Plus, on my ARM board the mapping of
the flash is done on boot, I'm not sure it can be remapped..

Fortunately it turns out to be not too much code to worry about.

> it really necessary for the user to know about it? Surely it's just a
> physical detail of the wiring?

If the mapping driver knows the chip size in advance it can remap as you
have done and set that value to the mapping size, otherwise I think it is
necessary to have support in a higher layer. It is definately required for
detection, and is only a minor amount of code for
writing/eraseing/reading. For reading I made a seperate function for
speed, the other functions are already so slow nobody will notice :>

Ideally, if the mapping driver can remap then after the detection sequence
it would remap it as necessary and re-detect to get a linear view. Some
drivers (such as windowed ones, maybe this ARM one too) can't remap even
if they wanted to.

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org