[LinuxBIOS] [PATCH] K8T890/VT8237 A8V-E SE (pre)release!

Rudolf Marek r.marek at assembler.cz
Sun Oct 14 23:02:06 CEST 2007


Just some comments to more specific issues:

> 
> USB will return, unfortunately. Not sure why I need it and he doesn't.
> All of these variables can be dropped for now, we'll add them back
> later. This won't be as bad as the i810, I'll keep working on this to
> make sure it's done right in the long run.
> 

I need to fix the disables for VT8237. I will need to disable the via rhine
ethernet chip and some USB direct communication device. perhaps via some config
variable?


>>> +};
>>> Index: src/southbridge/via/vt8237r/vt8237r_lpc.c
>>> ===================================================================

This files has some static resources which I have in plan to document them:

APIC Addr, IRQ9 for acpi
0x400 for SMBus, 0x500 Acpi base
> Can you please explain this a little better? Do these need to be fixed
> up for proper IOAPIC routing? Perhaps a comment for idiots like me?

Well no one here is an idiot... Even not me ;)

http://www.intel.com/design/pentium/datashts/242016.htm

Look to page 65. There is Figure 5-2. Default Configuration for Integrated APIC

I need to setup the apic in virtual wire mode just to connect the pin0 of the
apic through it, so it behaves like there is no apic at all. Because the
interrupts will be handled by i8259 connected directly to pin0

The ICC bus on the picture is no longer implemented as bus but as FSB message,
so I need to turn this on in APIC too.

If linux goes to APIC mode, it will disable the i8259 (mask) and disable this
pin0. The only problem is often with the timer interrupt which might or might
not be connected to APIC pin.  So for this SB is neccessary to

1) program the apic in virtual wire mode
2) program the use of FSB/ICC bus

I did not know much about apic when I was staring the LinuxBIOS stuff but I used
this specs to learn how the stuff works...

>>> +	/* enable SATA LED, disable CPU Frequency Change  */
>>>     
>> Why the CPU freq. change? Can you elaborate?
>>   
> 
> Nope, that's just exactly what the datasheet says. The value matches the
> jetway's bios, and frequency scaling still works, so I'm not sure what
> the deal with it is.

This is just special pin on SB which could be connected to clockchip and it will
trigger lower frequency to PLL. So it is not classic FID/VID stuff at all. But
rather some special kind of handling.
>>
>> Needs some comments.
>>   
> 
> From vt8235, isn't needed on vt8237r, at least not for me.

I have ACPI working, I will check if I need this. But mostly it just clear the
status registers.

>>> +	//FIXME Map 4MB of FLASH into the address space
>>> +	pci_write_config8(dev, 0x41, 0x0);
>>>     
>> Should be the maximum possible, does that make sense? Or it could be
>> a config option.
>>   
> 
> I'll test this soon. Do as you wish with it, I can patch it up later if
> needed.

I think we can enable the rest of the decoding bits in CAR, so LinuxBIOS can use
bigger than strapped flash.


>>> +	/* dma */
>>> +	//pci_write_config8(dev, 0x53, 0x00);
>>> +
>>> +	//enable HPET, ACPI has define to fixed addr
>>> +#define HPET_ADDR  0xfed00000ULL
>>>     
>> Put this at the top of the file or in the *.h file. Does it make sense
>> to make a config option out of it?
>>   
> 
> No config option, it's a fixed address. I'm writing this from the bottom
> up, so the lower posts explain a bit more. Should be at the top of the
> file though, or else hardcoded (or perhaps even defined in acpi files,
> since these seem to be generic values). It might already be defined in
> some acpi file.

I think HPET addr could be set same way like MMCONFIG, so just LB will find some
resource for this and we will fill it in even if the BAR is non-std. I will look
into this too. I need static resource for ACPI table, but I will check.



> 
>>> +void vt8237r_read_resources(device_t dev)
>>> +{
>>> +	struct resource *res;
>>> +
>>> +	pci_dev_read_resources(dev);
>>> +
>>> +	/* fixed APIC resource */
>>> +	res = new_resource(dev, 0x44);
>>> +	res->base = 0xfec00000;
>>>     
>> Is this different from HPET_ADDR? Should it?
>>   
> 
> Yes, this is ioapic not hpet.

Yes  this address is fixed and cannot be changed.


> 

>>> +static void apic_mmconfig_read_resources(device_t dev)
>>> +{
>>> +	struct resource *res;
>>> +	pci_dev_read_resources(dev);
>>> +
>>> +	res = new_resource(dev, 0x40);
>>> +	/* NB APIC fixed to this addr */
>>> +	res->base = 0xfecc0000;
>>>     
>> Hardcoded again. I think this should be a #define in *.h or even a
>> config option, rather than hardcoding it in all places.
>>   
> 
> Another fixed address, I think this one is LAPIC. Config options are not
> an option, these aren't configurable.

This is somehow fixed NB APIC addr. It cant be dynam, configurable

> 
>>> +
>>> +##
>>> +## Build code to export an x86 MP table
>>> +## Useful for specifying IRQ routing values
>>> +##
>>> +default HAVE_MP_TABLE=1
>>> +
>>> +##
>>> +## Build code to export a CMOS option table
>>> +##
>>> +##default HAVE_OPTION_TABLE=1
>>>     
>> Either enable it, or drop cmos.layout below.
>>   
> 
> Huh? afaik it is enabled (with default USE_OPTION_TABLE !=
> USE_FALLBACK_IMAGE below).

It should be disabled now.

RUdolf




More information about the coreboot mailing list