coreboot

coreboot@coreboot.org

39717 discussions

RE: [LinuxBIOS] Merge complete....
by YhLu 22 Jun '05

22 Jun '05

1. if not optimize the link in auto.c stage, and let hypertranport.c do the optimization, the hard_reset from reset_bus can works.... 2. if optimize the link in auto.c and hard_reset will be not called, and if call hard_reset from debug device....it works well. 3. if optimize the link in auto.c and reset freq to high value in hypertransport.c, the hard_reset from reset_bus will hang.... YH > -----Original Message----- > From: YhLu > Sent: Wednesday, June 22, 2005 5:37 PM > To: ebiederman(a)lnxi.com > Cc: 'LinuxBIOS' > Subject: RE: [LinuxBIOS] Merge complete.... > > ck804 is using cf9 to do reset, ......may be i lost the > control of that port. > > YH > > > -----Original Message----- > > From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] > > Sent: Wednesday, June 22, 2005 5:29 PM > > To: YhLu > > Cc: 'LinuxBIOS' > > Subject: Re: [LinuxBIOS] Merge complete.... > > > > YhLu <YhLu(a)tyan.com> writes: > > > > > the code reset_bus and scan_bus seem quite neat. > > > > > > but do one simutation, it doesn't work. > > > > > > I set ht frq to 800Mhz in auto.c > > > and reset that in hypertransport.c to 1GHz. > > > > > > it hangs after print out "Reseting board..." > > > > And the nice thing you get at most one reset of the board > everything > > will be setup and tuned first. > > > > > my hard_reset for ck804 doesn't work? > > > hard_reset is suposed to work, because i can do restart and > > > hardwaremain already call that...... > > > > Sounds like that is the problem. Quite possibly there is a > bus number > > change somewhere messing things up. > > > > The other possibility is that there is some tuning problem and the > > board does not come back from the reset. > > > > Eric > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS(a)openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios >

1 0

RE: [LinuxBIOS] Merge complete....
by YhLu 22 Jun '05

22 Jun '05

ck804 is using cf9 to do reset, ......may be i lost the control of that port. YH > -----Original Message----- > From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] > Sent: Wednesday, June 22, 2005 5:29 PM > To: YhLu > Cc: 'LinuxBIOS' > Subject: Re: [LinuxBIOS] Merge complete.... > > YhLu <YhLu(a)tyan.com> writes: > > > the code reset_bus and scan_bus seem quite neat. > > > > but do one simutation, it doesn't work. > > > > I set ht frq to 800Mhz in auto.c > > and reset that in hypertransport.c to 1GHz. > > > > it hangs after print out "Reseting board..." > > And the nice thing you get at most one reset of the board > everything will be setup and tuned first. > > > my hard_reset for ck804 doesn't work? > > hard_reset is suposed to work, because i can do restart and > > hardwaremain already call that...... > > Sounds like that is the problem. Quite possibly there is a > bus number change somewhere messing things up. > > The other possibility is that there is some tuning problem > and the board does not come back from the reset. > > Eric >

1 0

RE: [LinuxBIOS] Merge complete....
by YhLu 22 Jun '05

22 Jun '05

the code reset_bus and scan_bus seem quite neat. but do one simutation, it doesn't work. I set ht frq to 800Mhz in auto.c and reset that in hypertransport.c to 1GHz. it hangs after print out "Reseting board..." my hard_reset for ck804 doesn't work? hard_reset is suposed to work, because i can do restart and hardwaremain already call that...... YH

2 1

RE: [LinuxBIOS] Merge complete....
by YhLu 22 Jun '05

22 Jun '05

Eric, what's the purpose of the bus-> reset_needed? can you talk about reset_bus and scan_bus working sequence...? YH

2 1

RE: [LinuxBIOS] Merge complete....
by YhLu 22 Jun '05

22 Jun '05

unsigned int scan_bus(device_t bus, unsigned int max) { unsigned int new_max; int do_scan_bus; if ( !bus || !bus->enabled || !bus->ops || !bus->ops->scan_bus) { return max; } do_scan_bus = 1; while(do_scan_bus) { int link; new_max = bus->ops->scan_bus(bus, max); do_scan_bus = 0; for(link = 0; link < bus->links; link++) { if (bus->link[link].reset_needed) { if (reset_bus(&bus->link[link])) { do_scan_bus = 1; } else { bus->bus->reset_needed = 1; } } } } return new_max; } suggest change bus to dev, otherwise is some confusing. YH

1 0

RE: [LinuxBIOS] Merge complete....
by YhLu 22 Jun '05

22 Jun '05

or void x86_setup_mtrrs(unsigned address_bits) /* this routine needs to know how many address bits a given processor * supports. CPUs get grumpy when you set too many bits in * their mtrr registers :( I would generically call cpuid here * and find out how many physically supported but some cpus are * buggy, and report more bits then they actually support. */ { /* Try this the simple way of incrementally adding together * mtrrs. If this doesn't work out we can get smart again * and clear out the mtrrs. */ struct var_mtrr_state var_state; if(address_bits != 40) { ---------------------------------------- skip it for AMD printk_debug("\n"); /* Initialized the fixed_mtrrs to uncached */ printk_debug("Setting fixed MTRRs(%d-%d) type: UC\n", 0, NUM_FIXED_RANGES); set_fixed_mtrrs(0, NUM_FIXED_RANGES, MTRR_TYPE_UNCACHEABLE); /* Now see which of the fixed mtrrs cover ram. */ search_global_resources( IORESOURCE_MEM | IORESOURCE_CACHEABLE, IORESOURCE_MEM | IORESOURCE_CACHEABLE, set_fixed_mtrr_resource, NULL); printk_debug("DONE fixed MTRRs\n"); }

1 0

RE: [LinuxBIOS] Merge complete....
by YhLu 22 Jun '05

22 Jun '05

Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB Setting fixed MTRRs(24-88) Type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 8192MB, type WB Setting variable MTRR 1, base: 8192MB, range: 1024MB, type WB Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC DONE variable MTRRs Clear out the extra MTRR's MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic... apic_id: 0 done. i got two copy set fixed mtrr again. Eric, it is good you pass the address bits x86_setup_mtrrs. but for amd it is need to enable the fix mtrr mod enable bit in SYSCFG_MSR. ... amd_mtrr need some change ... YH > -----Original Message----- > From: YhLu > Sent: Wednesday, June 22, 2005 12:54 PM > To: ebiederman(a)lnxi.com > Cc: LinuxBIOS > Subject: RE: [LinuxBIOS] Merge complete.... > > I suugest put > node_link_to_bus > to inconherent_ht.c > > YH > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS(a)openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios >

1 0

RE: [LinuxBIOS] Merge complete....
by YhLu 22 Jun '05

22 Jun '05

I suugest put node_link_to_bus to inconherent_ht.c YH

1 0

RE: [LinuxBIOS] Merge complete....
by YhLu 22 Jun '05

22 Jun '05

> > diff -r freebios_lnxi/src/arch/i386/init/ldscript.lb > > ../freebios2/src/arch/i386/init/ldscript.lb > > 44,49d43 > > < > > < /* Move up the location counter if the start of the > rom section is > > < * too low. > > < */ > > < . = ( ( ( _ROMBASE + ROM_IMAGE_SIZE - 1 ) == > 0xffffffff ) && ( . < > > 0xffff0000 ) ) ? 0xffff0000 : . ; > > < > > there is some problem too. > > for some 8 way opteron system with romcc i need > linuxbios_ram auto.inc > > ---- it is very big entry32.inc --- _start is here > failover.inc jmp > > auto.inc > > out: > > _main in crt0.S > > > > then you will push auto.inc into the top 64k too, but the > 64k can not fit. > > > > So please merge that into main tree... > > I believe you are asking for a change. But I don't quite follow. > > Eric > that is verified, and it is used for romcc with 8 ways opteron, at that case the auto.inc get very big, and it make _start too low, so i put auto.inc before _start, and use jmp to it and after it done, auto.inc will jmp to __main. YH

1 0

RE: [LinuxBIOS] Merge complete....
by YhLu 22 Jun '05

22 Jun '05

if(is_cpu_d0()) { /* Erratum 110 ...*/ msr = rdmsr_amd(CPU_ID_HYPER_EXT_FEATURES); msr.hi |=1; wrmsr_amd(CPU_ID_HYPER_EXT_FEATURES, msr); } if (is_cpu_pre_e0()) { /* Erratum 110 ... */ msr = rdmsr_amd(CPU_ID_EXT_FEATURES_MSR); msr.hi |=1; wrmsr_amd(CPU_ID_EXT_FEATURES_MSR, msr); } also in model_fxx_init.c you miss sth should be if(is_cpu_d0()) { /* Erratum 110 ...*/ msr = rdmsr_amd(CPU_ID_HYPER_EXT_FEATURES); msr.hi |=1; wrmsr_amd(CPU_ID_HYPER_EXT_FEATURES, msr); } if (!is_cpu_pre_e0()) { ------------------------------don't forget ! /* Erratum 110 ... */ msr = rdmsr_amd(CPU_ID_EXT_FEATURES_MSR); msr.hi |=1; wrmsr_amd(CPU_ID_EXT_FEATURES_MSR, msr); } YH > -----Original Message----- > From: Li-Ta Lo [mailto:ollie@lanl.gov] > Sent: Wednesday, June 22, 2005 11:40 AM > To: YhLu > Cc: LinuxBIOS > Subject: RE: [LinuxBIOS] Merge complete.... > > On Wed, 2005-06-22 at 12:34 -0600, Li-Ta Lo wrote: > > On Wed, 2005-06-22 at 11:29 -0700, YhLu wrote: > > > define HARD_RESET_BUS > > > > > > removed, Good, get amd8111 bus from config_bus_map... > > > > > > > Eric, > > > > Is there any reason you put reset.c in every mainboard > directory but > > the only thing in these reset.c is #include "amd8111_reset.c" ? > > > > And node_link_to_bus in amd8111_reset.c and every auto.c? > > -- > Li-Ta Lo <ollie(a)lanl.gov> > Los Alamos National Lab >

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