coreboot

coreboot@coreboot.org

10 participants
39710 discussions

V2 EPIA PIRQ problem.
by ron minnich 02 Oct '03

02 Oct '03

HMM. We're running 2.4.22. pci-irq.c has this: { "VIA", PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, pirq_via_get, pirq_via_set }, { "VIA", PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C596, pirq_via_get, pirq_via_set }, { "VIA", PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, pirq_via_get, pirq_via_set }, no 8231 to be seen. So, what's up? did some clever committer just set the right IRQ in 0:12.0 and linux is not even setting IRQs? Inquiring minds want to know! How are EPIA interrupts getting set? Another example of why, I guess, we need to set interrupts in linuxbios, not in the kernel. The kernel is not always up to date. ron

1 0

V2 EPIA update
by ron minnich 02 Oct '03

02 Oct '03

The IRQ table is the same as in V1. LinuxBIOS claims it gets copied to the 0xf0000 address and that it is good. But ... linux still claims the no known irq for ... problem. ron

1 0

epia code.
by ron minnich 02 Oct '03

02 Oct '03

Some errors crept in due to a commit I made this morning, if you get compile errors try again. status is IRQ table copies and verifies, but fails in linux: via-rhine.c:v1.10-LK1.1.19 July-12-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html PCI: No IRQ known for iinterrupt pin Af device 00:12.0. Please try using pci=biosirq. eth0: VIA VT6102 Rhine-II at 0x1800, 00:40:63:ca:eb:c5, IRQ 0. eth0: MII PHY found at addresis 1, status 0x7advertising 05e1 Link 0000. looks like the table is bad ... Checking IRQ routing tables... Inconsistent IRQ routing table size /home/rminnich/src/bios/freebios2/src/arch/i386/boot/pirq_routing.c: 29:check_pirq_routing_table() - irq_routing_table located at: 0x00009ca0 /home/rminnich/src/bios/freebios2/src/arch/i386/boot/pirq_routing.c: 44:check_pirq_routing_table() - Interrupt Routing Table not valid Copying IRQ routing tables to 0xf0000...done. Verifing priq routing tables copy at 0xf0000...succeed Wrote linuxbios table at: 00000500 - 00000af0 checksum c456 oops. Try to fix now. ron

1 0

V2 EPIA
by ron minnich 02 Oct '03

02 Oct '03

OK, it's coming up with IRQs set up. Tested and committed just now. Apologies in advance: a PC-ism has crept into src/devices/pci_device.c, for setting IRQs. I let this happen as I'd like to see some ideas on how bad this is, and where that code should really be. We can move it as needed. But we do need this code, and it's not badly done at all (Thanks Kevin!) EPIA is now happily running linux and trying to become a bproc slave node. I'm done for the day, and I'm waiting for all your good ideas on what we do with SPD :-) ron

1 0

V1 SiS 630 VGA problem - any advice?...
by Lee Weekes 02 Oct '03

02 Oct '03

Hi, Sorry to ask a v1 question when your steaming away on v2 but I could really do with some advice as I'm a little stuck on a port. I've been working through what I thought would be a simple port to a SiS 630 based board and used the Winfast as a skeleton as the board is similar par a Winbond w83697hf rather than the 950 and the 630ST rather than the 630 but all the code for these basically existed in the tree. I also wanted to use the 256k flash and not a DOC but again used winfast-flash.config as a basis. I have managed to make the board boot Linux ok using Linuxbios, however when I tried to get VGA to work I get serious problems. I firstly did run into the same problem as a few have in the past namely with the following: biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x20 edx 0x9d2e biosint: ebp 0x12060 esp 0xff6 edi 0xe0ac esi 0x846a2 biosint: ip 0x3 cs 0x0 flags 0x46 biosint: Unsupport int #0x6 I managed to track down that these calls for me were due to not having read access to a needed area of shadow memory. I reversed the defined statement in northsouthbridge/sis/630/southbridge.c (!defined(STD_FLASH) to defined(STD_FLASH)) and this appeared to correct this problem as it now gets passed the opcode fault and the memory area can now be read. The problem is now my machine freezes shortly after as shown below. I can't understand why the machine would freeze at this point though and wondered if anyone had any idea's or pointers what I can do to correct it? INSTALL REAL-MODE IDT DO THE VGA BIOS PCI_CLASS_DISPLAY_VGA: 300 found VGA: vid=1039, did=6300 0x55 0xaa 0x60 0xe9 0x5f 0x2 0x32 0x2e 0x30 0x33 0x2e 0x30 0x32 0x20 0x2d 0x31 biosint: # 0x1a, eax 0xb102 ebx 0xeb21 ecx 0x16300 edx 0x1039 biosint: ebp 0x14c64 esp 0xfce edi 0x10c8c esi 0x80000 biosint: ip 0x762 cs 0xeb21 flags 0x46 0xb102: return 0x100 biosint: # 0x15, eax 0xf401 ebx 0x105 ecx 0x10100 edx 0x1039 biosint: ebp 0x14c64 esp 0xfce edi 0x10c8c esi 0x80000 biosint: ip 0x76b cs 0xeb21 flags 0x46 biosint: Unsupport int #0x15 biosint: # 0x7, eax 0x300001f ebx 0x0 ecx 0x0 edx 0x3c4 biosint: ebp 0x10fae esp 0xfce edi 0x1379c esi 0x800eb biosint: ip 0x5b4 cs 0xeb21 flags 0x216 biosint: Unsupport int #0x7 // <-- Int7 call looks out of place? biosint: # 0x At the point it freezes the last post code visible is 11 (was EC just before and I can't see 11 anywhere in the linuxbios tree) and I also get 1 continuous beep sounded from the buzzer which sounds worrying. I'm wondering if the change I made that appeared to correct the opcode problem isn't as good as I previously thought and if anyone has any suggestions as to where I can attack this new issue as I'm a little stumped? Thanks, Lee

1 0

Re: V1 SiS 630 VGA problem - any advice?...
by ron minnich 02 Oct '03

02 Oct '03

I think your best bet is to forget vga support, enable the sis fb lite patch for the kernel, and let the kernel bring up sis fb. ron

1 0

V2 and EPIA
by ron minnich 01 Oct '03

01 Oct '03

OK, I just loaded from flash. Next step is to fix the PIRQ, then look at SPD and memory setup. The fix, for now, is this in auto.c static void enable_mainboard_devices(void) { device_t dev; /* dev 0 for southbridge */ dev = pci_locate_device(PCI_ID(0x1106,0x8231), 0); if (dev == PCI_DEV_INVALID) { die("Southbridge not found!!!\n"); } pci_write_config8(dev, 0x50, 7); pci_write_config8(dev, 0x51, 0xff); } This is a mainboard-specific setting for the VIA EPIA. and in main: static void main(void) { unsigned long x; /* init_timer();*/ outb(5, 0x80); enable_vt8231_serial(); enable_mainboard_devices(); uart_init(); console_init(); . . . So at the moment I am loading from FLASH! Ethernet is up, etc: Linux is happy. Just need PIRQ. ron

3 3

A limit in V2 for PCI setup
by ron minnich 30 Sep '03

30 Sep '03

In v2, it is pretty much impossible to do PCI setup BEFORE the PCI scan is called and device trees are built. Sometimes, however, you need to be able to work on PCI before the scan, e.g. to enable certain functions. I don't want this code in mainboard auto.c -- that's a bad way to go. See the below comment. /* we need to do things in this function so that PCI scan will find * them. One problem here is that we can't use ANY of the new device * stuff. This work here precedes all that. * Fundamental problem with linuxbios V2 architecture. * You can't do pci control in the C code without having done a PCI scan. * But in some cases you need to to pci control in the c code before doing * a PCI scan. But you can't use arch/romcc_io.h (the code you need) * because * that has functions with the same name but different type signatures * (e.g. device_t is a struct in C code, and is an unsigned long in * romcc code). * This needs to get fixed. We need low-level pci scans * in the C code. */ I think my fix is to make a copy of romcc_io.h, with different names and type signatures, for use by functions that need to work with PCI before the PCI scan has been done. comments welcome. I'll do this after lunch unless I hear strong counterarguments that will get me what I need. Thanks ron

2 1

VIA EPIA SPD
by ron minnich 30 Sep '03

30 Sep '03

I'm getting a bad feeling about SPD on EPIA. I have tried to scan SPD on both a normal bios and linuxbios, and I don't get any real data back. The SMBUS hardware all acts correctly, but on linuxbios every SPD byte reads back as 0, and on the normal bios every spd byte reads back as 3. now, on earlier VIA platforms I have had, SPD has only been connected to one slot, not all slots. I have some concern that SPD is not wired at all on EPIA. VIA had expressed concern to me about the many errors in low-end SEEROMs used on DRAM, and felt that SPD was not always a good way to go. Can anyone out there confirm or deny my speculation on SPD on EPIA? SPD scan code available on request. ron

2 2

mptables and missing devices
by Stefan Reinauer 30 Sep '03

30 Sep '03

Hi, is there a reason why the mptable creation uses dev_find_slot() to find the bridges instead of dev_find_device()? Since it does not even check whether the device it finds is the one it wants this sounds rather dangerous. Taking the PCI_CLASS field into regard, it should be possible to search for all bridges in the system and generate the necessary mptable entries from the information gathered from the devices (SUBORDINATE_BUS, SECONDARY_BUS) Am I digging in the dark? Stefan -- Architecture Team SuSE Linux AG

3 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot