Re: [LinuxBIOS] More MCP55 hacking

[Lu, Yinghai]

If still has problem
1. 
#make the SB HT chain on bus 0, default is not (0)
#default SB_HT_CHAIN_ON_BUS0=1
2. 
Power off your target for a while. You may drive it nuts.

YH

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Ed Swierk
Sent: Tuesday, December 12, 2006 3:41 PM
To: LinuxBIOS
Subject: Re: [LinuxBIOS] More MCP55 hacking

On 12/12/06, Lu, Yinghai  wrote:
> ===>
>
> ##HT Unit ID offset, default is 1, the typical one
> #default HT_CHAIN_UNITID_BASE=0x06
>
> ##real SB Unit ID, default is 0x20, mean dont touch it at last
> #default HT_CHAIN_END_UNITID_BASE=0x01
>
> (it will put c51 on unitid 1, and mcp55 on unitid ?)

After commenting out these two options as you suggest, it looks like a
lot more devices are getting initialized; I had to increase HEAPSIZE
to 64 KB to avoid overflowing the heap.

Now, I'm getting an exception during PCI device init; see the attached
boot log.

Does it make sense that the same devices (e.g. 10de:0378) are showing
up on both bus 0 and bus 4?

--Ed

[LinuxBIOS] More MCP55 hacking

[Ed Swierk]

On 12/12/06, Lu, Yinghai  wrote:
> If still has problem
>
> #make the SB HT chain on bus 0, default is not (0)
> #default SB_HT_CHAIN_ON_BUS0=1
> 2.
> Power off your target for a while. You may drive it nuts.

The patch didn't help, but commenting out SB_HT_CHAIN_ON_BUS0 did. Now
the SB is on bus 1 and the devices are getting initialized only once.

Any idea what those "Unable to handle 64-bit address space for bridge
0000:01:03.0" errors are about? The stuff about IO/MEM/PREFETCH
windows being disabled doesn't look good either.

I suppose the first order of business is to get interrupts going, though.

--Ed

[LinuxBIOS] More MCP55 hacking

[Ed Swierk]

Thanks for the help so far. After hacking on mptable.c and
irq_tables.c, there are definite signs of progress: interrupts are
being routed from USB and Ethernet devices.

One code change I had to make outside the motherboard tree was to set
bit 1 of register 0x74 in the LPC device (in
ck804_lpc.c:lpc_common_init()). Without it, the APIC BAR is not
exposed in register 0x14, which causes setup_ioapic() to be passed 0x0
instead of 0xfec00000. I hope this isn't the cause of my next issue:

Now, after Linux says "Write protecting the kernel read-only data", it
just hangs; the next thing it should do is run init.

A few clues:

- after the hang, I still see messages from the USB driver when I plug
or unplug a device, so the serial console is apparently still alive;

- if I pass the "noapic" kernel parameter, the kernel doesn't hang
(but of course interrupts don't get configured properly);

- browsing the kernel source code, the only things that are supposed
happen between that last message and running init are (1) calling
pageattr.c:global_flush_tlb(), (2) calling
mempolicy.c:numa_default_policy(), and (3) opening /dev/console.

I've attached a boot log. As always, any help would be appreciated.

--Ed

[LinuxBIOS] More MCP55 hacking

[Ed Swierk]

On 12/13/06, Ed Swierk  wrote:
> Now, after Linux says "Write protecting the kernel read-only data", it
> just hangs; the next thing it should do is run init.

Never mind; turns out my mptable was broken and timers weren't wired up.

USB and Ethernet are now working nicely. I'll post the code tomorrow.

--Ed

[LinuxBIOS] More MCP55 hacking

[Ed Swierk]

My latest attempt at MCP55 support can be found at
http://www-cs-students.stanford.edu/~eswierk/misc/linuxbios-dfi-lp_ut_nf590....
.

So far it's only been tested on the DFI LANParty UT NF590 motherboard,
booting Linux 2.6.19.

It obviously needs quite a bit of work, including:

- generalizing the CK804 southbridge code; I've simply changed the PCI
IDs and hacked on a few functions

- un-hardcoding various bus and device numbers in irq_tables.c and mptable.c

- reinstating the fallback code that I ripped out in an effort to
simplify the build process

--Ed