Re: RFC: Deprecating io_block_mapping

On Thu, 2005-05-26 at 13:30 -0700, Mark A. Greer wrote:

Benjamin Herrenschmidt wrote:

quoted

- There is _one_ important point to keep in mind, but that has always
been true: None of this work before MMU_init(), 
 

This is very true and raises a couple issues that we should fix while 
we're at it:

1) There are progress calls in MMU_init which will try to access the 
uart before its possible to create a mapping to the uart's regs 
(assuming you don't make a hack to map them and that you set up 
ppc_md.progress in your platform_init routine).  We should either get 
rid of those calls in MMU_init, provide an acceptable way to make 
temporary pre-MMU_init mappings, or make sure nobody sets up 
ppc_md.progress until ioremap is working (and also get rid of the calls 
in MMU_init b/c they're never used).

Or have the implementation of progress() check if the mapping was done
or not ... In any ways, I always disliked ppc_md.progress deeply. It's
ugly and clutters the code. It has never proven very useful to me vs.
having an early console.

2) Some firmwares don't provide any info on how much memory is in the 
system but MMU_init needs to know that.  So the platform code has to 
read the SPD from the mem sticks via i2c, read the mem ctlr, or read a 
board reg that has the info.  All of those require access to hw regs 
before or during MMU_init.  I should be able to get rid of this one by 
figuring out the amount of memory in the bootwrapper and passing it in 
to the kernel.  I am assuming that all the boards with this problem use 
the bootwrapper.  I think that's a safe assumption but I'll have to verify.

Yes, the boot wrapper is the way to go here.

BTW, these are the reasons that I made that set_bat hack that Dan is so 
fond of.  :)  I'll get rid of that hack but I need an answer to 1) first.

Mark