coreboot

coreboot@coreboot.org

8 participants
39709 discussions

a few changes for HDAMA
by ron minnich 06 Aug '03

06 Aug '03

1. PIRQ table derived from standard bios, but it is still wrong. 2. have a hook in arima/hdama/mainboard.c for CONF_PASS_PRE_BOOT, but it is a no-op 3. targets/arima/hdama/Config.lb now enables SMP and sets max_cpus to 2 ron

2 2

OK, HDAMA is up as a cluster node
by ron minnich 06 Aug '03

06 Aug '03

The PIRQ is indeed wrong. So I booted a bproc phase 2 configured with IO-APIC support and all is well, since the _MP_ is correct. Gee, this is nice. I guess what we should do is dynamically generate PIRQ from the _MP_ table? That's for later. ron

2 1

Re: smp, newconfig, hdama
by YhLu 05 Aug '03

05 Aug '03

Why not try 64 bit? Yinghai Lu -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年8月5日 16:20 收件人: YhLu 抄送: linuxbios(a)clustermatic.org 主题: Re: smp, newconfig, hdama On Tue, 5 Aug 2003, YhLu wrote: > You need to change _RAMBASE to 0x4000. thank you, that did it. I now have an HDAMA running as a 2-cpu bproc slave node, in 32-bit mode, with an IBM T23 laptop as the master. ron

2 1

Re: smp, newconfig, hdama
by YhLu 05 Aug '03

05 Aug '03

You need to change _RAMBASE to 0x4000. Regards Yinghai Lu -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年8月5日 15:39 收件人: linuxbios(a)clustermatic.org 主题: smp, newconfig, hdama fails. ah well it was too good to last. LinuxBIOS is saying that CPU #1 did not initialize. just FYI, this is doubtless a "setup" problem. ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

smp, newconfig, hdama
by ron minnich 05 Aug '03

05 Aug '03

fails. ah well it was too good to last. LinuxBIOS is saying that CPU #1 did not initialize. just FYI, this is doubtless a "setup" problem. ron

1 0

XIP for K8
by ron minnich 05 Aug '03

05 Aug '03

Stefan can you send me your info on what you did for XIP? Just want to make sure what I do makes sense. ron

1 0

[PATCH] fix to pcibios.c
by SONE Takeshi 05 Aug '03

05 Aug '03

Hi, A realmode BIOS function in the LinuxBIOS didn't work properly (at least for me while trying to call int10h ax=4f01 of VGA BIOS), and below is the fix. With this fix, more boards and video cards might be able to use built-in VGA BIOS support of LinuxBIOS. Also I'm writing some code to switch video mode to VESA SuperVGA and get mode information (address of framebuffer etc) from VGA BIOS, then load 256-color logo image into the SuperVGA screen. It would be nice if it can pass mode information to the kernel (via LinuxBIOS table?) so we can use vesafb... Index: pcibios.c =================================================================== RCS file: /cvsroot/freebios/freebios/src/bioscall/pcibios.c,v retrieving revision 1.3 diff -u -r1.3 pcibios.c --- pcibios.c 22 May 2003 12:59:58 -0000 1.3 +++ pcibios.c 1 Aug 2003 08:17:10 -0000 @@ -50,7 +50,7 @@ unsigned short func = (unsigned short) eax; int retval = -1; unsigned short devid, vendorid, devfn; - int devindex; + short devindex; /* Use short to get rid of gabage in upper half of 32-bit register */ unsigned char bus; struct pci_dev *dev; @@ -76,7 +76,8 @@ *peax = 0; // busnum is an unsigned char; // devfn is an int, so we mask it off. - busdevfn = dev->bus->secondary | (dev->devfn & 0xff); + busdevfn = (dev->bus->secondary << 8) + | (dev->devfn & 0xff); printk_debug("0x%x: return 0x%x\n", func, busdevfn); *pebx = busdevfn; retval = 0;

2 1

more on HDAMA PIRQ table
by ron minnich 05 Aug '03

05 Aug '03

It looks pretty wrong in the BIOS. Here are the entries for 2:3.0 and 2:4.0. This translates to (bus,devfn) of (2,0x18) and (2,0x20) {0x2,0x18, {{0x4, 0xdef8}, {0, 0xdef8}, \ {0, 0xdef8}, {0, 0xdef8}}, 0x7, 0}, First, the slot is 7, not 0 as it should be for on-board. {0x2,0x20, {{0x4, 0xdef8}, {0, 0xdef8}, \ {0, 0xdef8}, {0, 0xdef8}}, 0x8, 0}, The slot is 8, not 0. Also, the IRQ line id is 4, and the hardware shows it as 1. So everything about this table is busted .... I'll try to fix it, but this is a worrisome sign for the future, in that we seem to find more and more broken IRQ tables. ron

1 0

Re: HDAMA status
by YhLu 05 Aug '03

05 Aug '03

Ron, I have checked the mptable.c and irq_table.c for hdama. They seem got some problem. And you maybe need to re-produce the two files. Regards Yinghai Lu -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年8月5日 10:46 收件人: linuxbios(a)clustermatic.org 主题: HDAMA status currently, I'm having PIRQ routing problems. Etherboot loads the kernel just fine, and here's something very odd: etherboot says the two MACs are at 1:3.0 and 1:4.0; the kernel says the macs are at 2:3.0 and 2:4.0. This is odd. Any one out there have a simple explanation for me? Also the PIRQ in the CVS looked quite wrong, but dumping the PIRQ from a running BIOS and using that fails as well. I've gone so far as to have LinuxBIOS just jam the same interrupts the standard bios uses by doing this in mainboard/arima/hdama/mainboard.c static void enable(struct chip *chip, enum chip_pass pass) { struct mainboard_arima_hdama_config *conf = (struct mainboard_arima_hdama_config *)chip->chip_info; switch (pass) { default: break; case CONF_PASS_PRE_BOOT: { struct device *p; /* PIRQ is still wrong. Just set ethernet for now */ p = dev_find_slot(1, 0x18); pci_write_config8(p, 0x3c, 0xb); p = dev_find_slot(1, 0x20); pci_write_config8(p, 0x3c, 0xb); printk_err("JAM ethernet to IRQ 11!\n"); break; } } } But it didn't help at all. I also tried doing the same crude thing to device 2:3.0 but that did not help. This business of the gige appearing on different busses is very odd; any explanation here? Hints welcome :-) ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

Re: linking static to dynamic devices
by YhLu 05 Aug '03

05 Aug '03

If you want cpufixup called by per cpu, you may need to modify cpu_initialize function and maybe add one pass for it. Regards Yinghai Lu -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年8月5日 6:54 收件人: linuxbios(a)clustermatic.org 主题: linking static to dynamic devices The next obvious step is to link static to dynamic devices. One issue is that we define CPUs statically, up to the maximum the mainboard can take. But they may not be there. How do we express this? Greg had some ideas, so he may jump in once he gets off the plane. I do think the new static architecture will allow for things like cpufixup() calls per-cpu, etc. but we'll see. ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

3 2

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