coreboot

coreboot@coreboot.org

5 participants
39572 discussions

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

HDAMA status
by ron minnich 05 Aug '03

05 Aug '03

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

1 0

linking static to dynamic devices
by ron minnich 05 Aug '03

05 Aug '03

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

2 1

config tool problem on early python
by ron minnich 05 Aug '03

05 Aug '03

OK, I see the problem, and I'll talk to greg about it. He is on the way to Oz so it will take another day or so. ron

1 0

Re: Weird behaviour with new config method
by ebiederman＠lnxi.com 05 Aug '03

05 Aug '03

ron minnich <rminnich(a)lanl.gov> writes: > interesting. I am loading linux direct from flash and it works fine with > the new config method. Now I'll have to try etherboot and see what's up. > > this is complicated as my tree is in an intermediate state, but I hope to > work it out monday. Something very peculiar is going on at the moment as I can't even get a configuration to build. Eric bash-2.05a$ ./buildtarget arima/hdama/ make: `config.py' is up to date. Configuring TARGET hdama Creating directory arima/hdama/hdama Will place Makefile, crt0.S, etc. in arima/hdama/hdama Configuring ROMIMAGE fallback Configuring DIR /config/Config.lb Configuring DIR /lib/Config.lb Configuring DIR /console/Config.lb Configuring DIR /stream/Config.lb Configuring DIR /devices/Config.lb Configuring DIR /pc80/Config.lb Configuring DIR /boot/Config.lb Configuring PART mainboard, path arima/hdama Configuring PART arch, path i386 Adding init file: config/crt0.base Configuring DIR lib/Config.lb Configuring DIR boot/Config.lb Configuring DIR smp/Config.lb End PART arch WARNING: Option CONFIG_SMP using default value 0 Configuring PART northbridge, path amd/amdk8 End PART northbridge Configuring PART southbridge, path amd/amd8111 End PART southbridge Configuring PART southbridge, path amd/amd8131 End PART southbridge Configuring PART superio, path NSC/pc87360 End PART superio Configuring DIR /pc80/Config.lb Warning, object/driver mc146818rtc previously defined Configuring PART cpu, path p5 End PART cpu Configuring PART cpu, path p6 End PART cpu Configuring PART cpu, path k7 End PART cpu Configuring PART cpu, path k8 End PART cpu End PART mainboard WARNING: Option AMD8111_DEV using default value 0x3800 WARNING: Option CONFIG_IDE_STREAM using default value 0 Traceback (most recent call last): File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 2137, in ? if (not parse('board', fp.read())): File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1782, in parse return wrap_error_reporter(P, rule) File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/yappsrt.py", line 162, in wrap_error_reporter try: return getattr(parser, rule)() File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1716, in board romstmts = self.romstmts() File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1701, in romstmts romimage = self.romimage() File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1680, in romimage romstmt = self.romstmt(1) File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1671, in romstmt mainboard = self.mainboard(C) File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1650, in mainboard if (C): mainboard(PATH) File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1034, in mainboard partpop() File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1087, in partpop print "WARNING: Option %s using default value %s" % (i, getformated(i, curpart.image)) File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 884, in getformated return (f % v.contents()) TypeError: an integer is required

3 14

VGA
by YhLu 04 Aug '03

04 Aug '03

Ron, How about VGA support status on LinuxBIOS? I also wonder if AGP addon card need init too. Regards Yinghai Lu

3 2

HDAMA status at LANL
by ron minnich 04 Aug '03

04 Aug '03

well, to sum up, on a 1 CPU system with arima/hdama - etherboot is working fine - linux loading from flash is working fine - once linux is loaded, it can't find an IRQ for the on-board ethernet. There is a PIRQ problem I will try to fix tomorrow. What's really neat, is that the fear level of cvs update is greatly reduced. A week or two ago I tar'ed up the tree every time I did a cvs update, for fear that I'd be left with a busted tree. The tree is solid enough that this worry is over. The K8 is moving fast! We hope to have a 4-node bproc cluster working this week. There will be some more interesting K8 news next week :-) In a day or two we start the NEWISYS port. ron

1 0

Re: Yh Lu's patches
by YhLu 04 Aug '03

04 Aug '03

Eric, As for cpufixup.c, actually I grab the fragment from raminit.c's set_top_ram. I don't want to make my own, because I can not access the most update code because of 24 hours delay. Fill_last: Can someone raise the bug to LinuxKernel developer team? There are Config.lb and config.lb in the southbridge/amd/amd8111. We should get rid of config.lb. Regards Yinghai Lu -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2003年8月4日 16:35 收件人: ron minnich 抄送: linuxbios(a)clustermatic.org 主题: Re: Yh Lu's patches ron minnich <rminnich(a)lanl.gov> writes: > Can Eric and Stefan and others interested please take a quick look at > this, it is the non-tyan mods from Yh Lu. > > I am going to commit the tyan mods in a few minutes. > > thanks > > ron > diff -uNr ./freebios2/src/cpu/k8/cpufixup.c ../freebios2/src/cpu/k8/cpufixup.c > --- ./freebios2/src/cpu/k8/cpufixup.c 2003-08-04 17:57:43.000000000 -0400 > +++ ../freebios2/src/cpu/k8/cpufixup.c 2003-08-04 19:41:18.000000000 -0400 > @@ -29,15 +29,28 @@ > mmio_basek = tomk; > } > > - /* Setup TOP_MEM */ > - msr.hi = mmio_basek >> 22; > - msr.lo = mmio_basek << 10; > - wrmsr(TOP_MEM, msr); > +#if 1 > + /* Report the amount of memory. */ > + print_debug("cpufixup RAM: 0x"); > + print_debug_hex32(tomk); > + print_debug(" KB\r\n"); > +#endif > + > + /* Now set top of memory */ > + msr.lo = (tomk & 0x003fffff) << 10; > + msr.hi = (tomk & 0xffc00000) >> 22; > + wrmsr(TOP_MEM2, msr); > + > + /* Leave a 64M hole between TOP_MEM and TOP_MEM2 > + * so I can see my rom chip and other I/O devices. > + */ > + if (tomk >= 0x003f0000) { > + tomk = 0x3f0000; > + } // tom_k = 0x3c0000; > + msr.lo = (tomk & 0x003fffff) << 10; > + msr.hi = (tomk & 0xffc00000) >> 22; > + wrmsr(TOP_MEM, msr); > > - /* Setup TOP_MEM2 */ > - msr.hi = tomk >> 22; > - msr.lo = tomk << 10; > - wrmsr(TOP_MEM2, msr); > > /* zero the IORR's before we enable to prevent > * undefined side effects. This bit is redundant. I described the change to Yinghai Lu and he made is own version of it. And in fact it is actively wrong. mmio_basek does a much better job of leaving an I/O hole there, then simply subtracting 64MB from 4GB. > diff -uNr ./freebios2/src/include/console/console.h > ../freebios2/src/include/console/console.h > > --- ./freebios2/src/include/console/console.h 2003-07-19 00:28:21.000000000 > -0400 > > +++ ../freebios2/src/include/console/console.h 2003-08-02 01:40:57.000000000 > -0400 > > @@ -92,34 +92,34 @@ > #define print_debug_char(CH) printk_debug ("%c", (CH)) > #define print_spew_char(CH) printk_spew ("%c", (CH)) > > -#define print_emerg_hex8(HEX) printk_emerg ("%08x", (HEX)) > -#define print_alert_hex8(HEX) printk_alert ("%08x", (HEX)) > -#define print_crit_hex8(HEX) printk_crit ("%08x", (HEX)) > -#define print_err_hex8(HEX) printk_err ("%08x", (HEX)) > -#define print_warning_hex8(HEX) printk_warning("%08x", (HEX)) > -#define print_notice_hex8(HEX) printk_notice ("%08x", (HEX)) > -#define print_info_hex8(HEX) printk_info ("%08x", (HEX)) > -#define print_debug_hex8(HEX) printk_debug ("%08x", (HEX)) > -#define print_spew_hex8(HEX) printk_spew ("%08x", (HEX)) > +#define print_emerg_hex8(HEX) printk_emerg ("%02x", (HEX)) > +#define print_alert_hex8(HEX) printk_alert ("%02x", (HEX)) > +#define print_crit_hex8(HEX) printk_crit ("%02x", (HEX)) > +#define print_err_hex8(HEX) printk_err ("%02x", (HEX)) > +#define print_warning_hex8(HEX) printk_warning("%02x", (HEX)) > +#define print_notice_hex8(HEX) printk_notice ("%02x", (HEX)) > +#define print_info_hex8(HEX) printk_info ("%02x", (HEX)) > +#define print_debug_hex8(HEX) printk_debug ("%02x", (HEX)) > +#define print_spew_hex8(HEX) printk_spew ("%02x", (HEX)) > > -#define print_emerg_hex16(HEX) printk_emerg ("%016x", (HEX)) > -#define print_alert_hex16(HEX) printk_alert ("%016x", (HEX)) > -#define print_crit_hex16(HEX) printk_crit ("%016x", (HEX)) > -#define print_err_hex16(HEX) printk_err ("%016x", (HEX)) > -#define print_warning_hex16(HEX) printk_warning("%016x", (HEX)) > -#define print_notice_hex16(HEX) printk_notice ("%016x", (HEX)) > -#define print_info_hex16(HEX) printk_info ("%016x", (HEX)) > -#define print_debug_hex16(HEX) printk_debug ("%016x", (HEX)) > -#define print_spew_hex16(HEX) printk_spew ("%016x", (HEX)) > +#define print_emerg_hex16(HEX) printk_emerg ("%04x", (HEX)) > +#define print_alert_hex16(HEX) printk_alert ("%04x", (HEX)) > +#define print_crit_hex16(HEX) printk_crit ("%04x", (HEX)) > +#define print_err_hex16(HEX) printk_err ("%04x", (HEX)) > +#define print_warning_hex16(HEX) printk_warning("%04x", (HEX)) > +#define print_notice_hex16(HEX) printk_notice ("%04x", (HEX)) > +#define print_info_hex16(HEX) printk_info ("%04x", (HEX)) > +#define print_debug_hex16(HEX) printk_debug ("%04x", (HEX)) > +#define print_spew_hex16(HEX) printk_spew ("%04x", (HEX)) > > -#define print_emerg_hex32(HEX) printk_emerg ("%032x", (HEX)) > -#define print_alert_hex32(HEX) printk_alert ("%032x", (HEX)) > -#define print_crit_hex32(HEX) printk_crit ("%032x", (HEX)) > -#define print_err_hex32(HEX) printk_err ("%032x", (HEX)) > -#define print_warning_hex32(HEX) printk_warning("%032x", (HEX)) > -#define print_notice_hex32(HEX) printk_notice ("%032x", (HEX)) > -#define print_info_hex32(HEX) printk_info ("%032x", (HEX)) > -#define print_debug_hex32(HEX) printk_debug ("%032x", (HEX)) > -#define print_spew_hex32(HEX) printk_spew ("%032x", (HEX)) > +#define print_emerg_hex32(HEX) printk_emerg ("%08x", (HEX)) > +#define print_alert_hex32(HEX) printk_alert ("%08x", (HEX)) > +#define print_crit_hex32(HEX) printk_crit ("%08x", (HEX)) > +#define print_err_hex32(HEX) printk_err ("%08x", (HEX)) > +#define print_warning_hex32(HEX) printk_warning("%08x", (HEX)) > +#define print_notice_hex32(HEX) printk_notice ("%08x", (HEX)) > +#define print_info_hex32(HEX) printk_info ("%08x", (HEX)) > +#define print_debug_hex32(HEX) printk_debug ("%08x", (HEX)) > +#define print_spew_hex32(HEX) printk_spew ("%08x", (HEX)) This bit is reasonable. I thought I had already committed it but... I typoed and did bit widths instead of nibble widths. > diff -uNr ./freebios2/src/northbridge/amd/amdk8/raminit.c > ../freebios2/src/northbridge/amd/amdk8/raminit.c > > --- ./freebios2/src/northbridge/amd/amdk8/raminit.c 2003-08-04 > 17:59:30.000000000 -0400 > > +++ ../freebios2/src/northbridge/amd/amdk8/raminit.c 2003-08-04 > 18:47:31.000000000 -0400 > > @@ -1124,6 +1124,23 @@ > } > } > > +//BY LYH //Fill next base reg with right value > +static void fill_last(unsigned long node_id,unsigned long base) > +{ > + unsigned i; > + unsigned base_reg; > + base &=0xffff0000; > + device_t device; > + for(device = PCI_DEV(0, 0x18, 1); device <= PCI_DEV(0, 0x1f, 1); device > > ++= PCI_DEV(0, 1, 0)) { > + for(i=node_id+1;i<=7;i++) { > + base_reg=0x40+(i<<3); > + pci_write_config32(device,base_reg,base); > + } > + } > +} > +//BY LYH END > + > static void route_dram_accesses(const struct mem_controller *ctrl, > unsigned long base_k, unsigned long limit_k) > { > @@ -1276,6 +1293,9 @@ > print_debug("\r\n"); > #endif > route_dram_accesses(ctrl, base_k, tom_k); > +//BY LYH > + fill_last(ctrl->node_id, tom_k<<2); > +//BY LYH END > set_top_mem(tom_k); > } This is a bug fix for a buggy kernel. It is extra code but it should not be a real problem. > diff -uNr ./freebios2/src/southbridge/amd/amd8111/config.lb > ../freebios2/src/southbridge/amd/amd8111/config.lb > > --- ./freebios2/src/southbridge/amd/amd8111/config.lb 2003-06-17 > 12:51:05.000000000 -0400 > > +++ ../freebios2/src/southbridge/amd/amd8111/config.lb 1969-12-31 > 19:00:00.000000000 -0500 > > @@ -1,4 +0,0 @@ > -driver amd8111_usb.o > -driver amd8111_lpc.o > -driver amd8111_ide.o > -driver amd8111_acpi.o Hmm. Removing all of those driver statements looks wrong... Eric _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

3 2

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