Re: [9fans] Question on mapping 0xfff00000

Re: [9fans] Question on mapping 0xfff00000

[jmk]

On Tue Mar 20 01:07:24 EST 2001, rminnich@lanl.gov wrote:
> 
> I need to map FLASH at 0xfff00000 into my flash driver. I have tried a
> number of variations, and keep coming back to:
> 
> flashbase = upamalloc(0xfff00000, 0x100000, 0);
> 
> Return value is 0xfff00000. But, any reference to this address provokes a
> fault, which leaves me believing I've got this wrong, even though a walk
> through that code also looks like it does set up the PTEs in the right
> way. The southbridge chip (PIIX4E) also has the right bits set to enable
> FLASH at these high addresses, and I've tested those settings in Linux.
> 
> The general problem is to map the last 2M of the 32-bit address space into
> memory, since on many boards that is the "reserved for BIOS flash" area.
> 
> What am I doing wrong? What's the right way to do this. I'm new to this
> kernel, needless to say. I'm also very happy it is now open source ...
> 
> ron

Looks like an arithmetic overflow problem. The clue is that the return
should be the ending address of the successfully mapped area. But if you
add 0xfff00000+0x100000 you get 0x100000000, which is 0 in 32-bits and the
mapping loop in mmu.c:^mmukmap() is

	pae = pa + size;
	lock(&mmukmaplock);
	while(pa < pae){

where pa = 0xfff00000 and size = 0x100000, so the loop will not be entered.

you could try rewriting the loop to be something like

	while(size > 0){
		...

and wherever you see
		pa += pgsz;
in the loop add
		size =- pgsz;
after it.

I think the comment in /sys/src/boot/pc/memory.c:^upamalloc() (which
contains the same mapping code) says it all. The whole memory thing is
slated for a rewrite but try the above suggestion and let me know how
it turns out.

--jim

Re: [9fans] Question on mapping 0xfff00000

[Ronald G Minnich]

On Tue, 20 Mar 2001 jmk@plan9.bell-labs.com wrote:

> Looks like an arithmetic overflow problem. The clue is that the return
> should be the ending address of the successfully mapped area. But if you
> add 0xfff00000+0x100000 you get 0x100000000, which is 0 in 32-bits and the
> mapping loop in mmu.c:^mmukmap() is

ok, yes, it is an arithmetic overflow. My fix is to not try to map that
last page, as i will not really need it anyway for what I am doing.

Also, it turns out the return for upamalloc is 0 for fail, and the
STARTING address on success. Just FYI.

thanks for the help, that cleared up the problems I was having. I should
have caught that as many times as I've been bitten by the "last page bug"
in various OSes. My driver is now happy.

ron

[9fans] Question on mapping 0xfff00000

[Ronald G Minnich]

I need to map FLASH at 0xfff00000 into my flash driver. I have tried a
number of variations, and keep coming back to:

flashbase = upamalloc(0xfff00000, 0x100000, 0);

Return value is 0xfff00000. But, any reference to this address provokes a
fault, which leaves me believing I've got this wrong, even though a walk
through that code also looks like it does set up the PTEs in the right
way. The southbridge chip (PIIX4E) also has the right bits set to enable
FLASH at these high addresses, and I've tested those settings in Linux.

The general problem is to map the last 2M of the 32-bit address space into
memory, since on many boards that is the "reserved for BIOS flash" area.

What am I doing wrong? What's the right way to do this. I'm new to this
kernel, needless to say. I'm also very happy it is now open source ...

ron