problem about ioapic

[aaron lwe]

On Sat, Apr 19, 2008 at 1:37 PM, aaron lwe  wrote:
> On Sat, Apr 19, 2008 at 5:01 AM, Rudolf Marek  wrote:
> > Hi,
> >
> > What northbridge it is? I think you need two things:
> >     /* Set APIC to FSB message bus. */
> >     l[0] = 0x3;
> >     val = l[4];
> >     l[4] = (val & 0xFFFFFE) | 1;
> >
> > (this is in the vt8237r_lpc.c) so If you use this you should be safe.
> >
> > Second thing you need is to route the APIC messages through chipset
> > correctly.
> >  I think this is D0F7/D11F7 0x7c bit 3. In fact you need to have correct
> > values there for the whole 0x70-0x7f range.
> >
> > Also, it seems you will need some timer overrides:
> >   /* IRQ0 -> APIC IRQ2. */
> >     current +=

acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)
> >                                             current, 0, 0, 2, 0x0);
> >
> > Thanks,
> >
> > Rudolf
>
> The northbridge is CN700. I'll try this on Monday, thanks.

Hi,

I've programmed CN700 D0F7 Rx70-7F with the factory BIOS value, but
 the problem remained.
 And I've tried both to use acpi madt table(when acpi enabled) and
 mptable(when acpi off), so I
 guess it shouldn't be a configuration tables's problem.

The CN700 D0F7 Rx7c's value is 0 and it's not mentioned on the
 datasheet, and there is no D11F7
 on VT8237R, I wonder if I misunderstood your meaning?

Thanks

[aaron lwe]

On Mon, Apr 21, 2008 at 11:49 AM, aaron lwe  wrote:
> Hi,
>
> I've programmed CN700 D0F7 Rx70-7F with the factory BIOS value, but
>   the problem remained.
>   And I've tried both to use acpi madt table(when acpi enabled) and
>   mptable(when acpi off), so I
>   guess it shouldn't be a configuration tables's problem.
>
> The CN700 D0F7 Rx7c's value is 0 and it's not mentioned on the
>   datasheet, and there is no D11F7
>   on VT8237R, I wonder if I misunderstood your meaning?
>
> Thanks

My fault, I messed up D0F3 Rx86 / D0F7 RxE6, it should be 0x2d.
now kernel boots ok, only the ethernet card has problem with getting an irq.
I'll see if it's a table configuration problem.

Thanks.

[Rudolf Marek]

> > The CN700 D0F7 Rx7c's value is 0 and it's not mentioned on the
> >   datasheet, and there is no D11F7
> >   on VT8237R, I wonder if I misunderstood your meaning?

D11F7 it is for VT8237A/S
> My fault, I messed up D0F3 Rx86 / D0F7 RxE6, it should be 0x2d.
> now kernel boots ok,

cool
> only the ethernet card has problem with getting an irq.
> I'll see if it's a table configuration problem.

I think I dont have the IRQ in my tables for for asus a8v-e SE because they use 
gigabit card. Just add it to ACPI/MADT table.

And dont forget to copy the shadow RAM register settings from NB back to 
southbridge, (D0F7 registers around 0x60, check the NB code of k8t890) or
the dd if=/dev/sda of=/dev/null will not work and DMA will timeout just after 
you will all memory with the buffers - and lastly the 0xC0000-0xEFFFF, which 
will fail the DMA.

Also dont forget to setup v-link to something reasonable + the v-link 
compensation values.

Rudolf

[aaron lwe]

> I think I dont have the IRQ in my tables for for asus a8v-e SE because they
> use gigabit card. Just add it to ACPI/MADT table.

It turned out that the ethernet card get its memory mapped address at
0xfec00000,
which should be reserved. I manually add 0xfec00000 and 0xfee00000 in
filo as two
reserved regions when doing a e820 map convert and then linux
automatically changed
ethernet card's memory base address to 0x40000000, problem solved.
I haven't time to see this pci memory allocation issuse, just make it
work this way for now.
and coreboot doesn't seem to have a way to reserve a memory region, does it?
> And dont forget to copy the shadow RAM register settings from NB back to
> southbridge, (D0F7 registers around 0x60, check the NB code of k8t890) or
>  the dd if=/dev/sda of=/dev/null will not work and DMA will timeout just
> after you will all memory with the buffers - and lastly the 0xC0000-0xEFFFF,
> which will fail the DMA.

Thanks for the information.

I've another MB with a C7+CN700+VT8237R, and I cannot make apic work on it yet.
The worked MB is VIA eden + CN700 + VT8237R.
I put the following code in vt8237r_lpc.c:
l[0] = 0x1;
val = l[4];
printk_debug("ioapic ver is %d\n", val);
and the result is 0. the result is right when using the worked MB.
So I guess maybe C7 has more to configure than just the code in lapic.c.

Thanks,

[Rudolf Marek]

aaron lwe wrote:
> > I think I dont have the IRQ in my tables for for asus a8v-e SE because they
> > use gigabit card. Just add it to ACPI/MADT table.
>
> It turned out that the ethernet card get its memory mapped address at
> 0xfec00000,
> which should be reserved. I manually add 0xfec00000 and 0xfee00000 in
> filo as two
> reserved regions when doing a e820 map convert and then linux
> automatically changed
> ethernet card's memory base address to 0x40000000, problem solved.
> I haven't time to see this pci memory allocation issuse, just make it
> work this way for now.
> and coreboot doesn't seem to have a way to reserve a memory region, does it?

No it does not. You can only make holes to memory map. Question is why the PCI 
allocator in coreboot did this. Imho there is somehere some minus so it starts 
bellow the fec00000 (at least for K8).
> > And dont forget to copy the shadow RAM register settings from NB back to
> > southbridge, (D0F7 registers around 0x60, check the NB code of k8t890) or
> >  the dd if=/dev/sda of=/dev/null will not work and DMA will timeout just
> > after you will all memory with the buffers - and lastly the 0xC0000-0xEFFFF,
> > which will fail the DMA.
>
> Thanks for the information.
>
> I've another MB with a C7+CN700+VT8237R, and I cannot make apic work on it yet.
> The worked MB is VIA eden + CN700 + VT8237R.
> I put the following code in vt8237r_lpc.c:
> l[0] = 0x1;
> val = l[4];
> printk_debug("ioapic ver is %d\n", val);
> and the result is 0. the result is right when using the worked MB.
> So I guess maybe C7 has more to configure than just the code in lapic.c.

But the IOAPIC is independent of CPU lapic. It seems that some memory routing is 
wrong?

Rudolf

[aaron lwe]

> But the IOAPIC is independent of CPU lapic. It seems that some memory
> routing is wrong?

Hi,

Yes, you're right. LB accidentally configured the integrated ethernet
card's memory base address to be 0xfec00000, and that made cpu
accessing memory at 0xfec00000 problematic. Wired since the worked MB
has exactly the same problem but it has no problem accessing
0xfec00000 as IO-APIC memory only linux cannot make the ethernet card
work without changing its base memory address.

Thanks.