coreboot

coreboot@coreboot.org

11 participants
39712 discussions

RE: Freebios2 recovery progress...
by YhLu 21 Oct '04

21 Oct '04

You changes all mb config for AMD/Iwill/IBM....that took some time. If there is on board scsi, I want to set subsystem id, I need to put that in Config.lb? YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Thursday, October 21, 2004 4:08 AM To: LinuxBIOS Subject: Freebios2 recovery progress... I have managed to get another chunk of merging and bug fixing done tonight. I now have pci subsystem vendor and subsystem id's being set on the arima hdama, so the board is now identifiable with lspci. I have bumped the LinuxBIOS minor version so we can track these changes. All of the superio chips should not work or at least be very close except the weird via superio/pci hybrid that I could not make sense of. I have changed all of the references to chip_control to chip_operations. And fixed up the usage while I was in the neighborhood if I could clearly see what the fix should be. So Config.lb for most of the Opteron ports should work, or at least be very close now. It is time for me to break off and head home. Eric _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

Freebios2 recovery progress...
by ebiederman＠lnxi.com 21 Oct '04

21 Oct '04

I have managed to get another chunk of merging and bug fixing done tonight. I now have pci subsystem vendor and subsystem id's being set on the arima hdama, so the board is now identifiable with lspci. I have bumped the LinuxBIOS minor version so we can track these changes. All of the superio chips should not work or at least be very close except the weird via superio/pci hybrid that I could not make sense of. I have changed all of the references to chip_control to chip_operations. And fixed up the usage while I was in the neighborhood if I could clearly see what the fix should be. So Config.lb for most of the Opteron ports should work, or at least be very close now. It is time for me to break off and head home. Eric

2 1

M789 power loss restart
by Alexander Amelkin 21 Oct '04

21 Oct '04

I bought several M789 motherboards for my company to make Linux-based routers. The boards seemed very well suitable for such needs and we previously used similar boards (787cl+ and others, not from PC Chips). The HUGE problem is that the board does not support Power Loss Restart function. That means that if power goes out, then our routers stop working and never resume, even if the power returns. Our routers are ususally installed in places that are hardly reachable and it takes several hours to bring them back up after the power outage. Power outages are often that long that UPS can't handle it. Nobody cares of it, because the outage usually covers the whole building or district. However when the power returns to the building, people want their Internet back. But the router is down due to no "power loss restart". :( Previously with 787cl+ motherboard it helped to short-circuit the 14th and the 15th pins of the ATX connector so the PSU stayed on. With M789CLU such a trick does not work. The PSU stays on, but the MB doesn't boot. Does anybody know how can I make the board to be always on? Is there any port register that I should write to? Or is it a CMOS bit? The board is built around VIA CLE266/VIA8235 chipset. Thanks in advance for any hints. Alexander Amelkin, MSCS Head of hardware design dept. TRC FIORD, JSC

2 2

hanging 'Setting fixed MTRRs' 810lmr
by Christof Murgott 21 Oct '04

21 Oct '04

Hi, I've downloaded the linuxbios source via CVS and the 2.4.19 from ftp.kernel.org, built everything as Antony Stone has explained in this howto[1]. However, the computer (PCCHIPS 810lmr) stalls with the following output on the serial console: LinuxBIOS-1.0.0 Mon Aug 30 09:03:42 CEST 2004 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. POST: 0x39 LinuxBIOS-1.0.0 Mon Aug 30 09:03:42 CEST 2004 booting... POST: 0x40 Finding PCI configuration type. PCI: Using configuration type 1 POST: 0x5f handle_superio start, nsuperio 1 handle_superio: Pass 0, check #0, s 0000bf40 s->super 0000c218 handle_superio: Pass 0, Superio SiS 950 handle_superio: port 0x0, defaultport 0x2e handle_superio: Using port 0x2e handle_superio: Pass 0, done #0 handle_superio done Scanning PCI bus...PCI: pci_scan_bus for bus 0 POST: 0x24 PCI: 00:00.0 [1039/0730] PCI: 00:00.1 [1039/5513] PCI: 00:01.0 [1039/0008] PCI: 00:01.4 [1039/7018] PCI: 00:02.0 [1039/0001] POST: 0x25 PCI: pci_scan_bus for bus 1 POST: 0x24 PCI: 01:00.0 [1039/6300] POST: 0x25 PCI: pci_scan_bus returning with max=01 POST: 0x55 PCI: pci_scan_bus returning with max=01 POST: 0x55 done POST: 0x66 Allocating PCI resources... ASSIGN RESOURCES, bus 0 PCI: 00:00.0 10 <- [0xf8000000 - 0xfbffffff] mem PCI: 00:00.1 10 <- [0x00002410 - 0x00002413] io PCI: 00:00.1 14 <- [0x00002420 - 0x00002423] io PCI: 00:00.1 18 <- [0x00002430 - 0x00002433] io PCI: 00:00.1 1c <- [0x00002440 - 0x00002443] io PCI: 00:00.1 20 <- [0x00002400 - 0x0000240f] io PCI: 00:01.4 10 <- [0x00002000 - 0x000020ff] io PCI: 00:01.4 14 <- [0xfc100000 - 0xfc100fff] mem PCI: 00:02.0 1c <- [0x00001000 - 0x00001fff] bus 1 io PCI: 00:02.0 24 <- [0xf0000000 - 0xf7ffffff] bus 1 prefmem PCI: 00:02.0 20 <- [0xfc000000 - 0xfc0fffff] bus 1 mem ASSIGN RESOURCES, bus 1 PCI: 01:00.0 10 <- [0xf0000000 - 0xf7ffffff] prefmem PCI: 01:00.0 14 <- [0xfc000000 - 0xfc01ffff] mem PCI: 01:00.0 18 <- [0x00001000 - 0x0000107f] io ASSIGNED RESOURCES, bus 1 ASSIGNED RESOURCES, bus 0 Allocating VGA resource done. POST: 0x88 Enabling PCI resourcess...PCI: 00:00.0 cmd <- 07 PCI: 00:00.1 cmd <- 01 PCI: 00:01.0 cmd <- 0c PCI: 00:01.4 cmd <- 03 PCI: 00:02.0 cmd <- 27 PCI: 01:00.0 cmd <- 03 done. Initializing PCI devices... PCI devices initialized POST: 0x89 POST: 0x70 totalram: 248M Initializing CPU #0 POST: 0x60 Enabling cache... Setting fixed MTRRs(0-42647) type: UC I can't do anything with it. So I searched the mailinglist archive and found a patch[2] from Andrew Ip. But nothing changed! Can anybody help me? Bye, Christof The System is running Redhat 7.2 and I have a MD-2802-D08. [1] http://www.linuxbios.org/developer/portguides/M810LR/index.html [2] http://www.clustermatic.org/pipermail/linuxbios/2003-June/003808.html

2 1

RE: FYI: Merge in progress...
by YhLu 21 Oct '04

21 Oct '04

I want to do some change to coherent_ht.c, otherwise s2885 can not be compiled under Loglevel = 8 diff -r freebios2/src/northbridge/amd/amdk8/coherent_ht.c ../freebios2/src/northbridge/amd/amdk8/coherent_ht.c 369a370 > #if 1 377a379 > #endif 394c396 < --- > #if 1 418a421 > #endif 456,457c459,460 < print_debug_hex8(result.cpus); < print_debug(" nodes initialized.\r\n"); --- > print_spew_hex8(result.cpus); > print_spew(" nodes initialized.\r\n"); 511c514 < print_debug("coherent_ht_finalize\r\n"); --- > print_spew("coherent_ht_finalize\r\n"); 539a543 > #if 0 540a545 > #endif 548c553 < print_debug("done\r\n"); --- > print_spew("done\r\n"); -----Original Message----- From: YhLu Sent: Wednesday, October 20, 2004 11:00 AM To: 'Stefan Reinauer' Cc: ebiederman(a)lnxi.com; 'Li-Ta Lo'; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: RE: FYI: Merge in progress... Done. -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Wednesday, October 20, 2004 5:58 AM To: YhLu Cc: ebiederman(a)lnxi.com; Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: Re: FYI: Merge in progress... * YhLu <YhLu(a)tyan.com> [041020 07:13]: > Just check in Tyan update to support new config. Hey Yinghai! It seems you forgot to commit the Options.lb files: freebios2/src/mainboard/tyan/*/Options.lb Currently config creation fails for all tyan boards complaining about this file .. Stefan _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

5 4

RE: FYI: Merge in progress... -- amd8111 enable_dev better suppor t
by YhLu 20 Oct '04

20 Oct '04

Just commit amd8111_better support Comment some line in amd8111/Config.lb Also reenable disable USB2 in amd8111. Regards YH

1 0

RE: FYI: Merge in progress...
by YhLu 20 Oct '04

20 Oct '04

If the romcc support the function instead using of all inline. It will be very small. Current auto.c ---> part before c_start is near 30K. Regards YH -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Wednesday, October 20, 2004 2:47 PM To: YhLu Cc: 'LinuxBIOS' Subject: Re: FYI: Merge in progress... * YhLu <YhLu(a)tyan.com> [041020 20:20]: > I want to do some change to coherent_ht.c, otherwise s2885 can not be > compiled under Loglevel = 8 > > < print_debug_hex8(result.cpus); > < print_debug(" nodes initialized.\r\n"); > --- > > print_spew_hex8(result.cpus); > > print_spew(" nodes initialized.\r\n"); Printing the number of CPUs found by cht init is not really "spewing". Time to look at CAR again? ;-) (don't hit me) - Last state was that it worked fine on UP systems but did not on SMP. Did anybody analyze this with a HDT? Stefan

4 3

RE: FYI: Merge in progress...
by YhLu 20 Oct '04

20 Oct '04

You still need wbinvd in disable_cache. It is called by raminit.c and without it the mem can not init properly. The amd_early_mtrr_init Only call do_early_mtrr_init But that doesn't include /* Enable the access to AMD RdDram and WrDram extension bits */ msr = rdmsr(SYSCFG_MSR); msr.lo |= SYSCFG_MSR_MtrrFixDramModEn; wrmsr(SYSCFG_MSR, msr); .... /* Disable the access to AMD RdDram and WrDram extension bits */ msr = rdmsr(SYSCFG_MSR); msr.lo &= ~SYSCFG_MSR_MtrrFixDramModEn; wrmsr(SYSCFG_MSR, msr); Also /* Enable caching for 0 - 1MB using variable mtrr */ msr = rdmsr(0x200); msr.hi &= 0xfffffff0; msr.hi |= 0x00000000; msr.lo &= 0x00000f00; msr.lo |= 0x00000000 | MTRR_TYPE_WRBACK; wrmsr(0x200, msr); msr = rdmsr(0x201); msr.hi &= 0xfffffff0; msr.hi |= 0x0000000f; msr.lo &= 0x000007ff; msr.lo |= (~((CONFIG_LB_MEM_TOPK << 10) - 1)) | 0x800; wrmsr(0x201, msr); regards YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Wednesday, October 20, 2004 1:46 PM To: YhLu Cc: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: Re: FYI: Merge in progress... YhLu <YhLu(a)tyan.com> writes: > Comment out disable_cache and enabe_cache in amd_early_mtrr_init you will > get 5s speed up. > > I checked old amd_early_mtrr.inc, it seems it only has enable cache, but no > wbinvd. Right. At the time I had no clue invalidates were a problem. I have just removed the wbinvd, it was just there for good measure. Eric

1 0

RE: FYI: Merge in progress...
by YhLu 20 Oct '04

20 Oct '04

Comment out disable_cache and enabe_cache in amd_early_mtrr_init you will get 5s speed up. I checked old amd_early_mtrr.inc, it seems it only has enable cache, but no wbinvd. Regards YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Wednesday, October 20, 2004 12:50 PM To: YhLu Cc: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: Re: FYI: Merge in progress... YhLu <YhLu(a)tyan.com> writes: > Why enable cache in amd_early_mtrr_init? Usually that is a speed up. I think all I changed was using the C implementation. Previously the assembly was called from Config.lb. > That causes CPU sleep 5s again. That is peculiar. > After get rid of that, the new auto.c stage still cost more 1s than the code > two weeks ago. Hmm. This is certainly worth fixing. And it tends to explain why I have not yet seen the 5s speed up. Eric

2 1

RE: FYI: Merge in progress...
by YhLu 20 Oct '04

20 Oct '04

Why enable cache in amd_early_mtrr_init? That causes CPU sleep 5s again. After get rid of that, the new auto.c stage still cost more 1s than the code two weeks ago. Regards YH -----Original Message----- From: YhLu Sent: Tuesday, October 19, 2004 6:30 PM To: ebiederman(a)lnxi.com Cc: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: RE: FYI: Merge in progress... Suggest you to add two options 1. premem 64 bit support? PCI_MEM_PREF_64BIT_SUPPORT 2. pci mmio optimizing? PCI_MEM_BASE_OPTIMIZATION Regards YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Tuesday, October 19, 2004 4:37 PM To: YhLu Cc: Li-Ta Lo; 'ebiederman(a)lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: Re: FYI: Merge in progress... YhLu <YhLu(a)tyan.com> writes: > Find out the problem, should be typo error. > > /* Now place the memory as high up as it will go */ > mem2->base = resource_max(mem2); > mem1->limit = mem2->base - 1; > mem1->base = resource_max(mem2); > ------> > /* Now place the memory as high up as it will go */ > mem2->base = resource_max(mem2); > mem1->limit = mem2->base - 1; > mem1->base = resource_max(mem1); > > regards Thanks. That was a definite blind spot, on my side. I have now committed the fix. Eric _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

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