coreboot

coreboot@coreboot.org

39717 discussions

Re: [LinuxBIOS] isue 26
by Ronald G Minnich 23 Nov '05

23 Nov '05

Stefan Reinauer wrote: > * Ronald G Minnich <rminnich(a)lanl.gov> [051123 17:02]: > >>reenable car >> >>it looks like it will apply, but what do you all think? is this thing ok? > > > I definitely want it in, but it still fails on island/aruma. > > I don't consider this a blocker though, since I won't switch the > customer to the new tree unless CAR works anyways so I would appreciate > having it in the tree to settle down and mature. > > Stefan > > I'm leaning to applying the CAR patch (issue 26). This only affects k8. If anyone has a problem with this, let me know ASAP, else I will apply it later today. I think I've resolved about 6 issues, I hope to get more done in the weeks to come. My goals is to have no unresolved issues by dec. 15. ron

3 2

[LinuxBIOS] x86_64: apic id lift patch
by yhlu 23 Nov '05

23 Nov '05

Andi, Please check the patch regarding apicid lifting. For some reason, we need to lift AP apicid but keep the BSP apicid to 0.... Also it solve the E0 later single but have apic id reorder problem... YH diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c --- a/arch/x86_64/kernel/setup.c +++ b/arch/x86_64/kernel/setup.c @@ -786,13 +786,24 @@ static void __init amd_detect_cmp(struct #ifdef CONFIG_SMP int cpu = smp_processor_id(); unsigned bits; + int cores_vir; #ifdef CONFIG_NUMA int node = 0; - unsigned apicid = phys_proc_id[cpu]; + unsigned initial_apicid = phys_proc_id[cpu]; + unsigned apicid = hard_smp_processor_id(); #endif + + cores_vir = c->x86_max_cores; + if(cores_vir == 1) { + unsigned level = cpuid_eax(1); + /* double check if it is E0 later, only E0 later can reorder apicid for single core */ + if ((level & 0xf0f00) >= 0x20f00) { + cores_vir = 2; + } + } bits = 0; - while ((1 << bits) < c->x86_max_cores) + while ((1 << bits) < cores_vir) bits++; /* Low order bits define the core id (index of core in socket) */ @@ -802,32 +813,23 @@ static void __init amd_detect_cmp(struct #ifdef CONFIG_NUMA node = phys_proc_id[cpu]; - if (apicid_to_node[apicid] != NUMA_NO_NODE) - node = apicid_to_node[apicid]; + + if (apicid_to_node[apicid] == NUMA_NO_NODE) + apicid_to_node[apicid] = node; + if (!node_online(node)) { - /* Two possibilities here: + /* One possibilities here: - The CPU is missing memory and no node was created. - In that case try picking one from a nearby CPU - - The APIC IDs differ from the HyperTransport node IDs - which the K8 northbridge parsing fills in. - Assume they are all increased by a constant offset, - but in the same order as the HT nodeids. - If that doesn't result in a usable node fall back to the - path for the previous case. */ - int ht_nodeid = apicid - (phys_proc_id[0] << bits); - if (ht_nodeid >= 0 && - apicid_to_node[ht_nodeid] != NUMA_NO_NODE) - node = apicid_to_node[ht_nodeid]; - /* Pick a nearby node */ - if (!node_online(node)) - node = nearby_node(apicid); + In that case try picking one from a nearby CPU */ + node = nearby_node(apicid); } + numa_set_node(cpu, node); +#endif printk(KERN_INFO "CPU %d(%d) -> Node %d -> Core %d\n", cpu, c->x86_max_cores, node, cpu_core_id[cpu]); #endif -#endif } static int __init init_amd(struct cpuinfo_x86 *c)

5 25

[LinuxBIOS] what's up with linxi-patch-13?
by Ronald G Minnich 23 Nov '05

23 Nov '05

has this been applied? What's the story here. thanks ron

2 2

[LinuxBIOS] abuild.sh issue
by ron minnich 23 Nov '05

23 Nov '05

stefan, I have a patch to abuild.sh on the issue tracker. This patch works as follows: If there is a targets/vendor/mainboard/Config-abuild.lb that will be used instead of the auto-generated one. See what you think. See example targets/digitallogic/msm586seg/Config-abuild.lb This is how it looks. ~/src/LinuxBIOSv2/util/abuild/abuild.sh -t digitallogic/msm586seg ~/src/LinuxBIOSv2/ Processing mainboard/digitallogic/msm586seg (i386: ok) Used existing test target /home/rminnich/src/LinuxBIOSv2//targets/digitallogic/msm586seg/Config- abuild.lb Creating builddir...ok Compiling image ..ok. The msm586seg now builds correctly in abuild. if this patch is ok, I will apply it or you can. Also, note that abuild won't create linuxbios-builds if you specify -t ... this is a bug. ron

3 4

[LinuxBIOS] abuild result
by ron minnich 23 Nov '05

23 Nov '05

oh, wow, what a mess. There's a lot to fix still. We'll be looking at each of these in turn, to try to get them to build. The last batch of patches from people left the tree in a very unhealthy state. We're going to have to watch this a lot more closely. If we can't improve the situation somehow, the only thing I can think of to do is limit people to sending in patches via the issue tracker, and shrinking the set of people who can commit down to a very small circle. Based on what I'm seeing here, the current setup is not working. I have not wanted to do this as we here at LANL don't have tons of free time to monitor patches, but the current situation can not continue. I think the earlier suggestion, of requiring positive evidence that abuild works after a patch, might be right. only problem -- abulid is making mistakes. The digital logic msm586 bulid fails in abuild, and works fine otherwise. oops. thanks ron

4 5

[LinuxBIOS] issue 25: amd k8 microcode support
by Ronald G Minnich 23 Nov '05

23 Nov '05

I have committed this. It was waiting too long. It caused no problems for building arima/hdama once I corrected a few typos. Signed-off-by: Ronald G. Minnich let me know if there are troubles. Will the first person to test this on real hardware please change status to resolved, instead of testing. Stefan, can we have status items of 'builds ok'? It would help. thanks ron

4 9

[LinuxBIOS] support for 3G memhole?
by Ronald G Minnich 22 Nov '05

22 Nov '05

status, anyone? Where is this? ron

3 4

[LinuxBIOS] patch for hole_startk == basek....
by yhlu 22 Nov '05

22 Nov '05

stephan, oille, Please check the memhole patch. when the hole_startk == one node basek, 1. it will modify base reg instead of hole reg 2. or if K8_HW_MEM_HOLE_SIZE_AUTO =1, then hole_startk will be moved to pri node mem middle.... this could solve the problem such as 1. two nodes, and first cpu have 2G installed, and memhole size is set to 2G, or mmio_basek is 2G, ( 2 IB installed). 2. four nodes. and every node has 1 G installed, and mmio will be 1G, and memhole is 1G..... New Mem hole behavoir will be 1. if K8_HW_MEM_HOLE_SIZEK == 0, then don't set mem_hole 2. if it is set, and it make hole_startk <= mmio_basek, will not reset mem hole in northbridge.c 3. if it is set, and it make hole_startk > mmio_basek, memhole will be reset in northbeidge.c 4. if hole_startk met with basek, it will use base reg instead of increase the hole_sizek to make hole_startk to the middle of pri node. YH

2 2

Re: [LinuxBIOS] issue 24
by Lu, Yinghai 22 Nov '05

22 Nov '05

I sent you my latest tall last week.....for aruma, s2881/s2885. Only miss the HW mem hole setting regarding hole_startk == basek.... Regarding apic id lifting 1. final solution will be a. ENABLE_APIC_EXT_ID will decide if lifted apicid b. APIC_ID_OFFSET will decide offset c. LIFT_BSP_APIC_ID will decide if lift BSP's.... 2. Need to put back sth back to cpu_scan_bus... Giant patch? It is already into two patch.... 1. it is in two patch.... one for microcode 2. One for acpi, Serengeti is just for referenc.e I have lost the sync to the public tree....., later I will send my tar ball to Stephan and you instead if needed... YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Ronald G Minnich Sent: Monday, November 21, 2005 4:28 PM To: LinuxBIOS Subject: [LinuxBIOS] issue 24 Yh Lu, could you please look at issue 24, and respond to stefan's issues? Yh Lu, I notice in issue 24, you set the idx to 0x10 in the amd k8 northbridge code, as opposed to the previous 10. Did you change this back? What is the current favorite setting? Did we ever decide if this was really ok? I've not been tracking all the 'lifting' discussions as I should have been -- sorry. At the least, please, can you review this patch and let's try to get it in as a set of patches, not as one giant patch; and, please seperate out the board-specific stuff (serengeti) from the global stuff that affects everything (northbridge/amdk8). What's the state of the ********** 16 *************** lnxi patches? did someone apply them and not mark them, or do we really have to test them all. I'm going to look at issue 31 next ... maybe this one will be easy. I was that close to applying Yh Lu's issue 24 patch, but it scared me. ron -- LinuxBIOS mailing list LinuxBIOS(a)openbios.org http://www.openbios.org/mailman/listinfo/linuxbios

1 0

[LinuxBIOS] issue 24
by Ronald G Minnich 22 Nov '05

22 Nov '05

Yh Lu, could you please look at issue 24, and respond to stefan's issues? Yh Lu, I notice in issue 24, you set the idx to 0x10 in the amd k8 northbridge code, as opposed to the previous 10. Did you change this back? What is the current favorite setting? Did we ever decide if this was really ok? I've not been tracking all the 'lifting' discussions as I should have been -- sorry. At the least, please, can you review this patch and let's try to get it in as a set of patches, not as one giant patch; and, please seperate out the board-specific stuff (serengeti) from the global stuff that affects everything (northbridge/amdk8). What's the state of the ********** 16 *************** lnxi patches? did someone apply them and not mark them, or do we really have to test them all. I'm going to look at issue 31 next ... maybe this one will be easy. I was that close to applying Yh Lu's issue 24 patch, but it scared me. ron

1 0

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