coreboot December 2006

coreboot@coreboot.org

68 participants
183 discussions

Start a nNew thread

Re: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem?
by Lu, Yinghai 14 Dec '06

14 Dec '06

Check your mptable.c to try other irq for slot 4. Current it is (2+i)%4 Try (3+i)%4 and Try (0+i)%4 YH

2 1

Re: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem?
by Lu, Yinghai 13 Dec '06

13 Dec '06

It could be some bug in your 3w-9xxx driver. Or I noticed that Irq 26 is used by card on slot 4 (8131 a) Irq 25 is used by card on slot 3 (8131 a) Irq 30 is used by card on slot 2 (8131 b) Slot 1: is HTX So try to find which one cause problem? YH -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of mcqmcqmcq(a)fastmail.fm Sent: Wednesday, December 13, 2006 12:25 PM To: Lu, Yinghai; linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem? > Do you have Broadcom tg3 card? Try it on that slot to see if it works > well. I can loop a dual-port e1000 back to itself in that slot and pump some bytes. What are we hoping to learn from this (so I can make sure I test for the theory you have in mind)? Toodles, -mcq -- mcqmcqmcq(a)fastmail.fm -- http://www.fastmail.fm - Choose from over 50 domains or use your own -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios

2 1

[LinuxBIOS] Tyan Tiger 133 (S1834) port to v2
by Brian Kemp 13 Dec '06

13 Dec '06

Hello all! I was doing a web search for the latest BIOS for some old motherboards I have lying around when I came across your supported hardware list. I happen to have two Tyan Tiger 133 (S1834) SMP Slot-1 motherboards. I just pulled one from a machine today, complete with P3-500 and terminator card (for the other slot) and I have no plans for it...so I figured I'd try to assist with your efforts. I'm not much of a low-level programmer, but if anyone would like me to ship the motherboard (and enough mounting hardware to get it set up in a blank case) to them, please let me know--I'd be happy to do so. If not, perhaps I can get involved in some low-level stuff, although I lack most of the specific hardware tools and expertise. (I have a Tyan Tiger 100 (S1832) as well, but it's completely different...) Thanks! --Brian

1 0

Re: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem?
by Lu, Yinghai 13 Dec '06

13 Dec '06

Do you have Broadcom tg3 card? Try it on that slot to see if it works well. YH

2 1

[LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem?
by mcqmcqmcq＠fastmail.fm 13 Dec '06

13 Dec '06

Hi guys, There is a problem (I believe the _last_ problem) with the DK8-HTX's IRQs on the 8131's B-bus. I have two 3ware 9550's. If they're both on the A-bus, things work fine and the relevant slice of /proc/interrupts looks like: CPU0 CPU1 CPU2 CPU3 25: 41 0 0 0 IO-APIC-fasteoi 3w-9xxx 30: 17 0 0 0 IO-APIC-fasteoi 3w-9xxx If I move one of them to the B-bus (there's only one physical slot on B), then this becomes: 26: 36650 0 0 0 IO-APIC-fasteoi 3w-9xxx 30: 17 0 0 0 IO-APIC-fasteoi 3w-9xxx The 36650 number increases by about 20000 or so all at once every few minutes. The timer appears to still be ticking away correctly. Accesses to the RAID on the B-bus immediately (deterministically; not 'once every few minutes') lead to a nobody cared that takes the card offline: irq 26: nobody cared (try booting with the "irqpoll" option) Call Trace: <IRQ> [<ffffffff8024ffec>] __report_bad_irq+0x30/0x7d [<ffffffff8025021a>] note_interrupt+0x1e1/0x223 [<ffffffff80250a33>] handle_fasteoi_irq+0x9e/0xc5 [<ffffffff8020a69c>] call_softirq+0x1c/0x28 [<ffffffff8020bbaf>] do_IRQ+0x7b/0xc8 [<ffffffff802088b4>] default_idle+0x0/0x47 [<ffffffff80209a91>] ret_from_intr+0x0/0xa <EOI> [<ffffffff802088dd>] default_idle+0x29/0x47 [<ffffffff80208985>] cpu_idle+0x8a/0xad [<ffffffff8061a673>] start_kernel+0x202/0x207 [<ffffffff8061a15a>] _sinittext+0x15a/0x15e handlers: [<ffffffff8800401e>] (twa_interrupt+0x0/0x5d8 [3w_9xxx]) Disabling IRQ #26 Interestingly enough, the behavior is the _same_ in the Iwill BIOS. I'm wondering if the LB routings are just a copy of broken Iwill routings? Can anybody think of anything to try other than concluding 'bad mobo/noisy wire'? (If a board swap is the next thing to try, that's possible but disruptive.) Bootlogs attached. Thanks again, -mcq -- mcqmcqmcq(a)fastmail.fm -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again

1 0

Re: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled
by Mondrian Nuessle 13 Dec '06

13 Dec '06

> I have to cart it to the rack to actually try the IB, and since I'm > having to hot-swap from the Iwill bios every time I flash (any clue > why flashrom -w when booting under LB fails immediately with "ERASE > FAILED" and trashes the image in flash?) Try to add the following io statements to your src/mainboard/iwill/dk8_htx/Config.lb at the point where the logical device 8 of the superio is intialized: device pnp 2e.8 on # GPIO2 io 0x07 = 0x08ff io 0x30 = 0x01ff io 0x2b = 0xd0ff io 0xf0 = 0xef16 end I hope this does the flash trick :-) Regards, Mondrian -- Mondrian Nuessle University of Mannheim Phone: +49 621 181 2717 Computer Architecture Group Fax: +49 621 181 2713 http://ra.ti.uni-mannheim.de mailto:nuessle@uni-mannheim.de

2 1

[LinuxBIOS] epia
by Ben Hewson 13 Dec '06

13 Dec '06

After some reading on the PCI spec I am sure that enumerating of the PCI devices on my epia board is not working as it should be. I assume everyone here is using a recent version of the code. As no one other than those of us using the epia board are having problems, I must assume it is a problem with the VIA chipset and not a bug in Linuxbios. 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 >From a working system using lspci I have the following 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]) Subsystem: VIA Technologies, Inc. Unknown device 6010 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 Region 4: I/O ports at d000 [size=16] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 06 11 10 60 10h - 1Ch above are all 0, so I assume that there are no BASE ADDRESS registers allocated here. 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 ? 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 ? Or is there some strange bit shifting going on ? 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. The EPIA code is more or less the same, just a few text changes in the debug so was it just working by luck before ? Does anyone have any thoughts on why the enumeration is wrong ? I guess I am looking at a wrongly configured southbridge chip or northbridge chip. Ben.

3 5

Re: [LinuxBIOS] More MCP55 hacking
by Lu, Yinghai 13 Dec '06

13 Dec '06

You need to use 64 bit kernel if you enable pref64 in LinuxBIOS. YH -----Original Message----- From: linuxbios-bounces+yinghai.lu=amd.com(a)linuxbios.org [mailto:linuxbios-bounces+yinghai.lu=amd.com@linuxbios.org] On Behalf Of Ed Swierk Sent: Tuesday, December 12, 2006 4:37 PM To: LinuxBIOS Subject: Re: [LinuxBIOS] More MCP55 hacking On 12/12/06, Lu, Yinghai <yinghai.lu(a)amd.com> wrote: > 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. 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 mailing list linuxbios(a)linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios

3 2

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
by Lu, Yinghai 13 Dec '06

13 Dec '06

-----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of ebiederm(a)xmission.com >Ok due to popular demands here is the slightly fixed patch that works >on both i386 and x86_64. For the i386 version you must not have >HIGHMEM64G enabled. >I just rolled it all into one patch as I'm to lazy to transmit all >3 of them. I got Firmware type: LinuxBIOS Linux version 2.6.19-smp-gc9976797-dirty (root@lbsrv) (gcc version 4.0.2) #196 6 Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq snd-hda-i BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000001000 (reserved) BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000c0000000 (usable) BIOS-e820: 0000000100000000 - 0000000240000000 (usable) dbgp_num: 0 Found EHCI debug port bar: 10 offset: 098 bar: 10 offset: 098 dbgp pre-set_fixmap_nocache PANIC: early exception rip ffffffff809c24b4 error 0 cr2 ffff810000203ff8 Call Trace: [<ffffffff809c24b4>] __set_fixmap+0x84/0x202 [<ffffffff809c05bb>] early_dbgp_init+0x259/0x55c [<ffffffff8022d958>] __call_console_drivers+0x64/0x72 [<ffffffff809b242b>] do_early_param+0x0/0x57 [<ffffffff809c0a20>] setup_early_printk+0x162/0x17e [<ffffffff809b2459>] do_early_param+0x2e/0x57 [<ffffffff8023d051>] parse_args+0x159/0x1f3 [<ffffffff809b24c2>] parse_early_param+0x40/0x4c [<ffffffff809b88ca>] setup_arch+0x1c1/0x636 [<ffffffff809b2534>] start_kernel+0x55/0x208 [<ffffffff809b2173>] _sinittext+0x173/0x177 RIP __set_fixmap+0x84/0x202 With Greg's USB Debug, host and target can talk. target with console=ttyUSB0,115200n8 host with cat /dev/ttyUSB0 But if use minicom in host, it will not show '\r', I guess the usb debug cable eat return char. Greg, Can you add that back in usb_debug by replacing '\n' with '\r', '\n'? With Eric code in LinuxBIOS, it will report "No device found in debug port" YH

4 9

Re: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2
by Lu, Yinghai 13 Dec '06

13 Dec '06

Is the suspend be the job of OS instead of firmware? I wonder if kexec or kdump could load another kernel to dump previous kernel to disk partition or file. Also wonder if you have one kernel to use kexec reload one dumped image? YH

6 9

← Newer
1
...
6
7
8
9
10
11
12
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2006