On Thu, 2005-05-26 at 13:30 -0700, Mark A. Greer wrote: > Benjamin Herrenschmidt wrote: > > > - 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
