where I'm at with the 440gx and reading nvram

[Ronald G. Minnich]

440gx agpset, page 4-2 has a nice map of the memory. 4-4 shows the
extended bios at 4GB-2M. When I do this: 
 unsigned long l = 0xffe00000;
  unsigned long flashsize = 0x200000;
  void *v;
  v = ioremap_nocache (l, flashsize);
  if (! v) {
        printk("ioremap failed\n");
        return;
  }

And I probe that memory I only read 0xff. Bad. It's acting like I'm
getting all 1's due to some control chip rejecting the memory cycle. I'd
be happier with a trap ...

So I check the PIIX4E manual, page 60 (section 4.1.9), it shows that 
register 4f controls what happens with accesses to the high 2MB of the 4GB
region. If you set bit 2 of 4f, requests should be forwarded. This bit is
set on my machine, but no dice anyway.

Any other thoughts welcome. This is really annoying. We have to get this
working ...

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Jeff Garzik]

"Ronald G. Minnich" wrote:
> 440gx agpset, page 4-2 has a nice map of the memory. 4-4 shows the
> extended bios at 4GB-2M. When I do this:
>  unsigned long l = 0xffe00000;
>   unsigned long flashsize = 0x200000;
>   void *v;
>   v = ioremap_nocache (l, flashsize);
>   if (! v) {
>         printk("ioremap failed\n");
>         return;
>   }
>
> And I probe that memory I only read 0xff. Bad. It's acting like I'm
> getting all 1's due to some control chip rejecting the memory cycle. I'd
> be happier with a trap ...

ioremap is a linux kernel function.  are you using readb() and writeb()
to access the token (not pointer!) returned from ioremap_nocache?

[Ronald G. Minnich]

On Mon, 24 Jan 2000, Jeff Garzik wrote:
> ioremap is a linux kernel function.  are you using readb() and writeb()
> to access the token (not pointer!) returned from ioremap_nocache?

yes but ... note that in asm/io.h, there's no real difference on the
pentium between readb and writeb and just using __va of the token.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Jeff Garzik]

"Ronald G. Minnich" wrote:
> On Mon, 24 Jan 2000, Jeff Garzik wrote:
> > ioremap is a linux kernel function.  are you using readb() and writeb()
> > to access the token (not pointer!) returned from ioremap_nocache?
>
> yes but ... note that in asm/io.h, there's no real difference on the
> pentium between readb and writeb and just using __va of the token.

Right, but if you already use readb/writeb it doesn't matter what
platform or CPU on which you are running.

[David Christensen]

What about the Chip Select on the NVRAM part?  Do you know what drives it?
There might be a GPIO from the PIIX4 or even the SIO that you have to enable
first.  I've also seen designs with custom security ASICs to control access
to the flash part to prevent the flash from being overwritten by a virus.

Dave

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of
Ronald G. Minnich
Sent: Monday, January 24, 2000 3:39 PM
To: [e-mail]
Subject: [OpenBIOS] where I'm at with the 440gx and reading nvram

440gx agpset, page 4-2 has a nice map of the memory. 4-4 shows the
extended bios at 4GB-2M. When I do this:
 unsigned long l = 0xffe00000;
  unsigned long flashsize = 0x200000;
  void *v;
  v = ioremap_nocache (l, flashsize);
  if (! v) {
        printk("ioremap failed\n");
        return;
  }

And I probe that memory I only read 0xff. Bad. It's acting like I'm
getting all 1's due to some control chip rejecting the memory cycle. I'd
be happier with a trap ...

So I check the PIIX4E manual, page 60 (section 4.1.9), it shows that
register 4f controls what happens with accesses to the high 2MB of the 4GB
region. If you set bit 2 of 4f, requests should be forwarded. This bit is
set on my machine, but no dice anyway.

Any other thoughts welcome. This is really annoying. We have to get this
working ...

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Ronald G. Minnich]

I'm actually getting somewhere now via a different path.

I have mmaped 0xffe00000 from /dev/mem and I can see the BIOS. I'm not
looking at what's in it, but the contents of 0xf0000 and 0xffe00000 do
match.

This also revealed a bug in the linux do_mmap code: it doesn't correctly
handle the case of mmap'ing the tail end of memory ...

Now to try to kick the nvram a little. This will require setting a write
enable bit in the bridge, which I do know is not set normally. No big
deal. It's still a mystery to me why the darn thing was not visible
in-kernel, but oh well: I prefer user-mode code for this sort of thing
anyway.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message