On Thu, Mar 10, 2005 at 03:01:56PM -0800, ramesh bios wrote:
> Oooh, looks interesting. I did not actually know what
> subtractive decoding is. Now I do. After talking to
> the local PCI guy, it means that the cs5530 will only
> claim the transaction if it doesn't see anyone else
> assert devsel# f
Oooh, looks interesting. I did not actually know what
subtractive decoding is. Now I do. After talking to
the local PCI guy, it means that the cs5530 will only
claim the transaction if it doesn't see anyone else
assert devsel# for some number of cycles. I will try
this out soon. Thanks very much Pe
On Wed, Mar 09, 2005 at 05:08:20PM -0800, ramesh bios wrote:
> Yes, I was, or actually, am doubtful as well. I would
> have thought, for sure, you can turn off the cs5530a's
> claim of reads on that address block. But so far I
> can't find any way to do that, and it doesn't seem
> like anyone else
On Wed, 9 Mar 2005 17:08:20 -0800 (PST), ramesh bios
<[EMAIL PROTECTED]> wrote:
> As for watching the chip select line, I'd love to do
> that but I don't have a logic analyzer or probes. I
> guess I could do it with an LED and a sharpened wire
> but I'd rather not risk damage to my board. :-)
Oh.
Yes, I was, or actually, am doubtful as well. I would
have thought, for sure, you can turn off the cs5530a's
claim of reads on that address block. But so far I
can't find any way to do that, and it doesn't seem
like anyone else has either.
As for watching the chip select line, I'd love to do
that
>
> Looking at Stefan's /dev/bios code I see the use of 6
> to enable write access to the flash. But I don't see
> the ability to disable the CS5530A's claim of the read
> cycle. So no way to map F elsewhere.
I'm kind of doubtful on this. ROM shadowing has been part of chipsets
for a long ti
On Tue, 8 Mar 2005, ramesh bios wrote:
> So what do you guys think I should do? Do you agree
> with my assessment above? The easiest thing to do
> would be to add a linux kernel boot parameter that'll
> allow LinuxBIOS to tell filo to tell the kernel
> exactly where in sdram the uncompressed PIR
After reading Stefan's mention of F0 index 52h in the
CS5530A, I think I'm begining to understand the
problem.
Currently, Fh is mapped to flash. This is because
at reset, the CS5530A decodes that address block and
claims those cycles, generating an ISA bus memory
cycle specifically. I think t
On Fri, 4 Mar 2005, Ronald G. Minnich wrote:
>
>
> On Thu, 3 Mar 2005, ramesh bios wrote:
>
> > Ok, so I tried this specific sequence and it failed.
> >
> > making region read/write
>
> nope. you need to make it write-only,
arg, I'm not thinking, we are running out of high memory and then
On Thu, 3 Mar 2005, ramesh bios wrote:
> Ok, so I tried this specific sequence and it failed.
>
> making region read/write
nope. you need to make it write-only,
> Verifing priq routing tables copy at 0xf...failed,
then copy
The make it read-write.
> Could it be that f is mapped
* ramesh bios <[EMAIL PROTECTED]> [050304 05:12]:
> Ok, so I tried this specific sequence and it failed.
>
> making region read/write
> done making region read/write
> Verifing priq routing tables copy at 0xf...failed,
> f=b0 while 87c0=24
>
> Could it be that f is mapped to the flash
Ok, so I tried this specific sequence and it failed.
making region read/write
done making region read/write
Verifing priq routing tables copy at 0xf...failed,
f=b0 while 87c0=24
Could it be that f is mapped to the flash? I'm
trying to figure out whether that is technically
possible fo
Ok, so I think this means I should:
1. Enable writes for Fh thru F3FFFh (in
gx_setup.inc) using BC_XMAP_3
2. Copy the pirq table to F as in
pirq_routing.c:copy_pirq_routing_table
3. Enable read and writes for Fh thru F3FFFh in
pirq_routing.c:verify_copy_pirq_routing_table using
BC_XMAP
for shadow ram, you need to enable writes to go to ram. Later on, when you
are done with a region, you need to enable reads.
So the way you do this: figure out which one is for 0xf. Enable writes
(2). At the end of the process, you need to set (3) for the area.
And, somebody will have t
Hi,
Thanks for the hint. I see the BC_XMAP registers
touched in nsc/gx1/gx_setup.inc.
.long BC_XMAP_1, 0x60
.long BC_XMAP_2, 0
.long BC_XMAP_3, 0
And from the gx1 spec:
---
GX_BASE+800Ch-800Fh BC_XMAP_3 Register (R/W) Default
Value = h
19:16 F0 F0 Region:
you should try to get shadow ram working.
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Ramesh,
At 04:02 02/03/2005, ramesh bios wrote:
1. Shadow RAM
I guess I would need to find a way to tell the
northbridge to enable shadow RAM for some range around
f. I looked through the CS5530A datasheet and see
shadow registers but no mention of shadowing RAM. Nor
in the GX1 datasheet either
1. Shadow RAM
I guess I would need to find a way to tell the
northbridge to enable shadow RAM for some range around
f. I looked through the CS5530A datasheet and see
shadow registers but no mention of shadowing RAM. Nor
in the GX1 datasheet either. I'm looking for some
register in either the G
On Tue, 1 Mar 2005, ramesh bios wrote:
> Strike that. The issue is somewhere with
> copy_pirq_routing_table. IE: why does the copy to
> f fail. I had assumed that the 500 address was an
> alternate location that the table was copied to. So
> now, I'm looking at that f000 failure.
the copy
On Tue, 1 Mar 2005, ramesh bios wrote:
> ---
> Checking IRQ routing tables...
> /bios/freebios/src/arch/i386/lib/pirq_routing.c:
> 30:check_pirq_routing_table() - irq_routing_table
> located at: 0x8740
> done.
> Copying IRQ routing tables to 0xf...done.
> Verifing priq routing tables
Strike that. The issue is somewhere with
copy_pirq_routing_table. IE: why does the copy to
f fail. I had assumed that the 500 address was an
alternate location that the table was copied to. So
now, I'm looking at that f000 failure.
--- ramesh bios <[EMAIL PROTECTED]> wrote:
> The URL for the
The URL for the Cox/Weinigel thread about PIRQ tables
on the geode gx1 is at:
http://lkml.org/lkml/2002/7/5/104
I'm doing a little bit more analysis of the problem
now. I've been looking at the following block of code
from 2.6.10's pci/irq.c. First of all, LB states this
during bootup:
---
Checkin
On Tue, 1 Mar 2005, Richard Smith wrote:
> I've found that Linux up to 2.6.9 (I haven't tested .10) Dosen't do
> this fully. With my 440bx chipset there are config registers in the
> northbridge that control which IRQ line each of the PCI PIRQ lines are
> routed to. Even with a proper PIRQ ta
On Tue, 1 Mar 2005, ramesh bios wrote:
> Would I be able to test if Linux 2.6.10 is able to
> parse the normal BIOS' PIRQ table by booting linux
> with acpi=off?
no, the problem is that the BIOSes we have seen in some cases just assign
a bunch of IRQs, and ignore their own tables. Hence, the
On Mon, 28 Feb 2005, ramesh bios wrote:
> That's odd. My understanding might be lacking.
>
> I think the PIRQ table parser in 2.6.10 seems to work
> because it works when I use the normal BIOS.
no, it's messy. Some bioses set IRQ settings that don't agree with their
own PIRQ tables. I've se
> > And if that were done, Linux would not need to parse a
> > PIRQ table, yes?
>
> LinuxBIOS does not do that, it provides the tables and requires the OS
> to do so.
I've found that Linux up to 2.6.9 (I haven't tested .10) Dosen't do
this fully. With my 440bx chipset there are config register
* ramesh bios <[EMAIL PROTECTED]> [050301 12:22]:
> Would I be able to test if Linux 2.6.10 is able to
> parse the normal BIOS' PIRQ table by booting linux
> with acpi=off? If it does work at that point, then I
> could assume that the area to be fixed would be the
> PIRQ table generation in LinuxBI
Good point. I did not know about ACPI. Ok, looking
through the source, I don't see ACPI in the gx1 code.
So I presume that this means that LinuxBIOS doesn't
provide ACPI support in the case of the Geode.
Would I be able to test if Linux 2.6.10 is able to
parse the normal BIOS' PIRQ table by bootin
* ramesh bios <[EMAIL PROTECTED]> [050301 08:19]:
> That's odd. My understanding might be lacking.
>
> I think the PIRQ table parser in 2.6.10 seems to work
> because it works when I use the normal BIOS.
Sure normal BIOS does not provide ACPI instead? In such case, PIRQ stays
mostly untouched.
That's odd. My understanding might be lacking.
I think the PIRQ table parser in 2.6.10 seems to work
because it works when I use the normal BIOS. Therefore
allowing the inference that 2.6.10 can read the table
that was generated by the normal BIOS, right? What do
you think? I'm now reading throug
On Mon, 28 Feb 2005, ramesh bios wrote:
> I used Linux 2.6.10. I'm reading through the list
> archive now for any related kernel issues.
>From 2.4.19 on, the IRQ parser for PIRQ tables for geodes is broken.
That could be part of the problem.
ron
_
I used Linux 2.6.10. I'm reading through the list
archive now for any related kernel issues.
Thanks.
--- "Ronald G. Minnich" wrote:
>
>
> On Mon, 28 Feb 2005, ramesh bios wrote:
>
> > PCI: No IRQ known for interrupt pin A of device
> > :00:0b.0.
>
> what kernel?
>
> It matters.
>
>
On Mon, 28 Feb 2005, ramesh bios wrote:
> PCI: No IRQ known for interrupt pin A of device
> :00:0b.0.
what kernel?
It matters.
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Hi all,
I'd been away for a while. I have picked up another
geode gx1 to play with. Previously I used the
irq_tables from the pcm-5823 and that worked just fine
as far as I could tell. This time around, with this
board I hit trouble. I saw the:
PCI: No IRQ known for interrupt pin A of device
34 matches
Mail list logo
