[LinuxBIOS] epia

Ben Hewson ben at hewson-venieri.com
Sun Dec 10 15:37:23 CET 2006


Segher Boessenkool wrote:
>> Booting using a current version, I get the following when enumerating
>> the PCI devices (reading resources)
>>
>> PCI: 00:11.1 20 *  [0x00000c00 - 0x00000c0f] io
>> PCI: 00:11.1 10 *  [0x00000c10 - 0x00000c17] io
>> PCI: 00:11.1 18 *  [0x00000c20 - 0x00000c27] io
>> PCI: 00:11.1 14 *  [0x00000c30 - 0x00000c33] io
>> PCI: 00:11.1 1c *  [0x00000c40 - 0x00000c43] io
>>     
>
> That looks just fine.
>
>   
>> 00:11.1 IDE interface: VIA Technologies, Inc.
>> VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
>> (prog-if 8a [Master SecP PriP])
>>     
>
> It's in legacy mode, the first four BARs are disabled (it uses
> legacy I/O 0x1f0 etc. instead, and the legacy IRQs too).
>
>   
>> One thing I am curious about is that according
>> to the PCI spec (I only have version 2.1) the base address registers
>> start at 10h, so why, in the above , does the IDE controller, and in
>> fact most of the devices on the board use the higher base address
>> registers ?
>>     
>
> Look at <http://www.bswd.com/pciide.pdf>, it'll take away
> your confusion hopefully.  A device can use any BAR it wants,
> it is fine to skip 0x10.
>
>   
>> Another question I have is the fact that 20h contians d001h. The PCI
>> spec does mention that a device  may have don't care bits in the base
>> address. So can I assume that, that is the case here ?
>>     
>
> The low few bits are read-only; bits 01 mean it's an I/O BAR.
> The base address is 0xd000.
>
>   
>> What confuses me is that on an earlier version (head version 2401)  
>> this
>> worked. Comparing the two versions I can see there have been  
>> changes to
>> the PCI parts of the code, but nothing to dramatic, and as I have said
>> no one else seems to be having problems.
>>     
>
> Since the code assigned all five BARs, the controller is in
> non-legacy mode; this means that LinuxBIOS set it up that way,
> since legacy mode is the boot-up default.  Some controllers
> use legacy IRQs even in non-legacy mode, maybe that's your
> problem.  What exactly isn't working?
>   

Ok compiling LB for the same target using the same payload (filo),
compiled on the same system, the earlier version works, baring the odd
system hang. The later versions gets to filo, but it then comes back with

FILO version 0.5 (root at localhost) Sun Nov 12 17:35:53 GMT 2006
boot: hda1:/kern  root=/dev/hda3 console=ttyS0,115200
Detected floating bus
No drive detected on IDE channel 0

I have attached the boot output from both versions. There are only a few
differences in output, mostly to do with PCI 0.11.1 which is the IDE
controller.
The non working version seems to see more resources.

Also when it comes to enabling the IDE controller in compatibilty mode
(reg 0x42) the non working versions reports it contains 0xc9, the
working version reports the same register as 0. According to the
datasheet I have on the southbridge the bottom bits 5-0 in that register
should be 0. It is if the non working version is looking at the wrong
area of memory.

One other thing perhaps you could explain to me, is what exactly is the
"pci_routing_fixup" all about ?

Thanks for the link btw.




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lb_bad
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20061210/55695619/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lb_good
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20061210/55695619/attachment-0001.ksh>


More information about the coreboot mailing list