[COMMIT] pirq_routing.c

[Eric W. Biederman]

ollie lho <ollie at sis.com.tw> writes:

> On Thu, 2002-11-14 at 13:11, Ronald G. Minnich wrote:
> > I get this now. So in other words, it is not getting copied, but the
> > kernel is finding the table in FLASH since it is uncompressed. Now I
> > wonder why linuxbios would try to copy to f0000, since that is a FLASH
> > area. I think it is because linuxbios is now thinking that the memory hole
> > at 0xf0000 is not there, and that it is dram. We need to see what
> > assumptions linuxbios is making about the memory hole at 0xf0000.
> > Something has changed recently.
> > 
> 
> The reason LinuxBIOS copying the table to 0xf0000 is that the kernel 
> will search the table in certain memory regions which includes 
> 643rd Kb and 0xf0000-1Mb. For uncompressed LinuxBIOS in Flash rom, the
> copy is not neceressary since the table is uncompressed and in the 
> memory region under kernel's search. For DoC, we have to make the F 
> segment mapped to DRAM and copy the table to F segment. I have no idea
> what to do if you are using a compressed LinuxBIOS with Flash Rom.

With LinuxBIOS in Flash rom it should be just as safe to make the F
segment mapped to DRAM as it is in the DOC case.  Until memory is
setup we run out of the Rom chip but after that the two cases are
effectively identical.   But if you are going to use compression,
and be more space efficient in the Rom chip the F segment needs
to be setup as RAM or you cannot setup the pirq table.

Given the slow speed of flash rom chips i suspect the decompressor
will actually speed things up a bit.

Eric