coreboot March 2004

coreboot@coreboot.org

54 participants
166 discussions

24 Mar '04

It seems the soft reset didn't rest the MB and ... Ollie, Can you check that in S2885? And I think if you changed the hard_reset and soft_reset to bus 1, it may not rest the ht. Regards Yinghai Lu -----邮件原件----- 发件人: YhLu 发送时间: 2004年3月23日 19:22 收件人: ebiederman(a)lnxi.com; Stefan Reinauer; ron minnich 抄送: linuxbios(a)clustermatic.org 主题: S4882 support Eric, The ht reset in auto.c seems not thoroughly. And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can not access 8111 yet). Regards YH LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:33:50 PST 2004 starting... setting up resource map....done. 04 nodes initialized. ht reset -Ram1.00 XÀm1.01 Ram1.02 Ram1.03 Ram2.00 Ram2.01 Ram2.02 Ram2.03 Ram3 Initializing memory: done Initializing memory: done Initializing memory: done Initializing memory: done Clearing LinuxBIOS memory: done Ram4 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:46:40 PST 2004 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating: AMD K8 Enumerating: AMD K8 Enumerating: AMD 8111 Enumerating: Winbond w83627hf Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled PCI: 00:1a.0 [1022/1100] enabled PCI: 00:1a.1 [1022/1101] enabled PCI: 00:1a.2 [1022/1102] enabled PCI: 00:1a.3 [1022/1103] ops PCI: 00:1a.3 [1022/1103] enabled PCI: 00:1b.0 [1022/1100] enabled PCI: 00:1b.1 [1022/1101] enabled PCI: 00:1b.2 [1022/1102] enabled PCI: 00:1b.3 [1022/1103] ops PCI: 00:1b.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... Hyper transport scan link: 1 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed

5 8

S4882 support
by YhLu 24 Mar '04

24 Mar '04

Eric, The ht reset in auto.c seems not thoroughly. And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can not access 8111 yet). Regards YH LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:33:50 PST 2004 starting... setting up resource map....done. 04 nodes initialized. ht reset -Ram1.00 XÀm1.01 Ram1.02 Ram1.03 Ram2.00 Ram2.01 Ram2.02 Ram2.03 Ram3 Initializing memory: done Initializing memory: done Initializing memory: done Initializing memory: done Clearing LinuxBIOS memory: done Ram4 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:46:40 PST 2004 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating: AMD K8 Enumerating: AMD K8 Enumerating: AMD 8111 Enumerating: Winbond w83627hf Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled PCI: 00:1a.0 [1022/1100] enabled PCI: 00:1a.1 [1022/1101] enabled PCI: 00:1a.2 [1022/1102] enabled PCI: 00:1a.3 [1022/1103] ops PCI: 00:1a.3 [1022/1103] enabled PCI: 00:1b.0 [1022/1100] enabled PCI: 00:1b.1 [1022/1101] enabled PCI: 00:1b.2 [1022/1102] enabled PCI: 00:1b.3 [1022/1103] ops PCI: 00:1b.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... Hyper transport scan link: 1 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed

3 4

dynamic hypertransport links
by Stefan Reinauer 24 Mar '04

24 Mar '04

In the progress of getting hypertransport setup completely dynamic, I made the following patch that completely gets rid of the CONNECTION and link name macros in coherent_ht.c (UP, ACROSS, DOWN and CONNECTION_0_1, CONNECTION_0_2, CONNECTION_1_3) Therefore I added two simple helper functions that gain the needed information from generate_row(). This patch probably raises the register pressure during ht setup, but even on a 4p machine I could not see any problems with romcc. Dropping another couple of hardcodes seems like the right thing to do[tm]. If nobody is opposing, I am going to check this into CVS. Stefan -- Stefan Reinauer, SUSE LINUX AG Head of Architecture Development

3 2

答复: ????: dynamic hypertransport links
by YhLu 24 Mar '04

24 Mar '04

The Patch remove the define CONNECTION... But the link is still not initialized right. Regards Yinghai Lu -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2004年3月24日 9:49 收件人: YhLu 抄送: LinuxBIOS Experts 主题: Re: ????: dynamic hypertransport links * YhLu <YhLu(a)tyan.com> [040324 18:45]: > Great, I will try it right now. > > Anyway > > Ldt0 = up > Ldt1 = across > Adt2 = down > > It that right? That is at least the calling scheme I've been using when I wrote the coherent hypertransport setup code originally. Looks right.. Stefan -- Stefan Reinauer, SUSE LINUX AG Head of Architecture Development

1 0

答复: S4882 support
by YhLu 24 Mar '04

24 Mar '04

Sorry it is function 0. -----邮件原件----- 发件人: Li-Ta Lo [mailto:ollie@lanl.gov] 发送时间: 2004年3月24日 9:39 收件人: YhLu 抄送: ebiederman(a)lnxi.com; Stefan Reinauer; ron minnich; LinuxBIOS 主题: re: S4882 support On Wed, 2004-03-24 at 10:43, YhLu wrote: > Eric, > > After check 84/a4/c4, 88/a8/c8 of function 1 of K8 northbridge, the link > speed/width is not init properly. > Is it function 0 ? Ollie > Regards > > YH > > -----邮件原件----- > 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] > 发送时间: 2004年3月23日 23:42 > 收件人: YhLu > 抄送: Stefan Reinauer; ron minnich; linuxbios(a)clustermatic.org > 主题: Re: S4882 support > > YhLu <YhLu(a)tyan.com> writes: > > > Eric, > > > > The ht reset in auto.c seems not thoroughly. > > > > And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can > not > > access 8111 yet). > > Correct. The early hypertransport initialization code is not > complete in the 4P case. That incompleteness triggers the later > fixups. > > I could not test that case, and there were at least some small > difficulties in that it was not obvious how the 4P case should > be extended to work properly. > > Why you are getting stuck in amdk8_scan_chains I do not currently > understand yet. I suspect Stefan's suggestion of a delayed reset > is the appropriate course to implement. > > Eric > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios >

1 0

答复: dynamic hypertransport links
by YhLu 24 Mar '04

24 Mar '04

Great, I will try it right now. Anyway Ldt0 = up Ldt1 = across Adt2 = down It that right? Regards YH. -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2004年3月24日 9:32 收件人: LinuxBIOS Experts 主题: dynamic hypertransport links In the progress of getting hypertransport setup completely dynamic, I made the following patch that completely gets rid of the CONNECTION and link name macros in coherent_ht.c (UP, ACROSS, DOWN and CONNECTION_0_1, CONNECTION_0_2, CONNECTION_1_3) Therefore I added two simple helper functions that gain the needed information from generate_row(). This patch probably raises the register pressure during ht setup, but even on a 4p machine I could not see any problems with romcc. Dropping another couple of hardcodes seems like the right thing to do[tm]. If nobody is opposing, I am going to check this into CVS. Stefan -- Stefan Reinauer, SUSE LINUX AG Head of Architecture Development

2 1

re: S4882 support
by YhLu 24 Mar '04

24 Mar '04

Eric, After check 84/a4/c4, 88/a8/c8 of function 1 of K8 northbridge, the link speed/width is not init properly. Regards YH -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2004年3月23日 23:42 收件人: YhLu 抄送: Stefan Reinauer; ron minnich; linuxbios(a)clustermatic.org 主题: Re: S4882 support YhLu <YhLu(a)tyan.com> writes: > Eric, > > The ht reset in auto.c seems not thoroughly. > > And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can not > access 8111 yet). Correct. The early hypertransport initialization code is not complete in the 4P case. That incompleteness triggers the later fixups. I could not test that case, and there were at least some small difficulties in that it was not obvious how the 4P case should be extended to work properly. Why you are getting stuck in amdk8_scan_chains I do not currently understand yet. I suspect Stefan's suggestion of a delayed reset is the appropriate course to implement. Eric

3 2

答复: ??????: S4882 support
by YhLu 24 Mar '04

24 Mar '04

That's right. YH -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2004年3月24日 7:36 收件人: YhLu 抄送: ebiederman(a)lnxi.com; ron minnich; linuxbios(a)clustermatic.org 主题: Re: ??????: S4882 support * YhLu <YhLu(a)tyan.com> [040324 04:57]: > It seems the soft reset didn't rest the MB and ... > > Ollie, > > Can you check that in S2885? And I think if you changed the hard_reset and > soft_reset to bus 1, it may not rest the ht. I've changed the reset code today so that the same code is used on all K8+AMD8111 systems reset.c went to southbridge/amd/amd8111/amd8111_reset.c In the config file, you can now specify the device doing the hard reset, instead of copy+write the reset code for every new mainboard: default HARD_RESET_BUS=1 default HARD_RESET_DEVICE=5 default HARD_RESET_FUNCTION=0 It would be a lot nicer to find the device dynamically. Maybe that can get fixed together with dynamically creating pirq and the other tables some day.. The Tyan boards currently assume the 8111 reset logic is available at following positions on the PCI bus: s2850 1:2.0 s2880 1:4.0 s2881 1:4.0 s2882 1:4.0 s2885 3:4.0 s4880 1:4.0 Yinghai, is this correct? Stefan -- Stefan Reinauer, SUSE LINUX AG Head of Architecture Development

1 0

coherent_ht_mainboard()
by Stefan Reinauer 24 Mar '04

24 Mar '04

Yinghai, tyan/*/hypertransport.c contain some fixed hypertransport register values poked into the AMD K8 northbridge. This code was earlier called by coherent_ht.c:setup_coherent_ht_domain() but I removed the call some time ago, since I could not see why it is still needed. Does this code provide any crucial functionality that can't be realized in the dynamic code of the current CVS tree? If not, I suggest we drop this code. The same thing could btw work for the different versions of resourcemap.c. The biggest reason for the split off here was that the default resource map did always assume the AMD8111 southbridge on link0 which is not always true. This is fixed by now. The bus numbers should meanwhile be entered correctly by the generic code. So, we could reduce the amount of involved code a lot, flattening out all the nasty exceptions we invented to bend the rules.. Stefan -- Stefan Reinauer, SUSE LINUX AG Head of Architecture Development

2 1

EPIA-M
by M. Renee Hopkins 24 Mar '04

24 Mar '04

I've not seen much traffic on the EPIA-M lately. Was this performance under linuxbios and XFree86 4.3 ever tracked down? Via Bios: (II) VIA(0): Benchmarking video copy. Less is better. (--) VIA(0): Timed libc YUV420 copy... 6317080. Throughput: 56.3 MiB/s. (--) VIA(0): Timed kernel YUV420 copy... 4732303. Throughput: 75.2 MiB/s. (--) VIA(0): Ditch SSE YUV420 copy... Not supported by CPU. (--) VIA(0): Timed MMX YUV420 copy... 3321777. Throughput: 107.1 MiB/s. (--) VIA(0): Timed 3DNow! YUV420 copy... 3219309. Throughput: 110.5 MiB/s. (--) VIA(0): Ditch MMX2 YUV420 copy... Not supported by CPU. (--) VIA(0): Timed Ezra YUV420 copy... 3143254. Throughput: 113.2 MiB/s. (--) VIA(0): Using Ezra YUV42X copy for video. Linux BIos: (II) VIA(0): Benchmarking video copy. Less is better. (--) VIA(0): Timed libc YUV420 copy... 17020122. Throughput: 20.9 MiB/s. (--) VIA(0): Timed kernel YUV420 copy... 9921195. Throughput: 35.9 MiB/s. (--) VIA(0): Ditch SSE YUV420 copy... Not supported by CPU. (--) VIA(0): Timed MMX YUV420 copy... 8576428. Throughput: 41.5 MiB/s. (--) VIA(0): Timed 3DNow! YUV420 copy... 8576433. Throughput: 41.5 MiB/s. (--) VIA(0): Ditch MMX2 YUV420 copy... Not supported by CPU. (--) VIA(0): Timed Ezra YUV420 copy... 8577055. Throughput: 41.5 MiB/s. (--) VIA(0): Using MMX YUV42X copy for video. I will help where I can assist.. Seems AGP isn't the same? M.R. _________________________________________________________________ Check out MSN PC Safety & Security to help ensure your PC is protected and safe. http://specials.msn.com/msn/security.asp

3 2

← Newer
1
2
3
4
5
6
7
8
9
...
17
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 March 2004