coreboot

coreboot@coreboot.org

39717 discussions

Re: [LinuxBIOS] VGA
by Richard Smith 08 Sep '05

08 Sep '05

On 9/8/05, Narahari, Narasimhaiah (IE10) <Narahari.Narasimhaiah(a)honeywell.com> wrote: > Hi everyone, > > I have a small question to ask, > I am trying to boot windows 2000 on SC2200 Geode based board. I have > downloaded Linuxbiosv1 from the cvs repository. And my doubt is, > > What are the requirements other than generating VGABIOS and TESTBIOS (i386 > emulation) for bringing up VGA on Linuxbiosv1? Lots. VGA is troublesome in V1. First off you have to decide what method you are going to use other than running testbios directly on the command line there are 2 more 1. You instruct linuxbios to attempt to switch to realmode call the bios and then return to normal. 2. You boot ADLO as a payload and let it run the VGABios. For option 1 you will have to search the mail archives. There are some options you have to enable. For option 2 you need to read the ADLO payload documentation on the wiki. -- Richard A. Smith

2 1

[LinuxBIOS] VGA
by Narahari, Narasimhaiah (IE10) 08 Sep '05

08 Sep '05

Hi everyone, I have a small question to ask, I am trying to boot windows 2000 on SC2200 Geode based board. I have downloaded Linuxbiosv1 from the cvs repository. And my doubt is, What are the requirements other than generating VGABIOS and TESTBIOS (i386 emulation) for bringing up VGA on Linuxbiosv1? With regards, narahari

1 0

[LinuxBIOS] node id and core id in internal tree
by Lu, Yinghai 08 Sep '05

08 Sep '05

Eric, It seems that cpu_path and cpu_bus_path in include/device/path.h are not used. So what do you prefer struct apic_path { unsigned apic_id; unsigned node id; unsigned core_id; } Or struct cpu_path { unsigned id; unsigned apic_id; unsigned node_id; unsigned core_id; } YH ________________________________ From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Lu, Yinghai Sent: Wednesday, September 07, 2005 9:09 AM To: Stefan Reinauer; Eric W. Biederman; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] Re: topics for linuxbios summit eric> > Before we generate ACPI or anything else we need to move the relevant eric> > information eric> > into the internal device tree. eric> > YH: Good point, But I worry that we make LinuxBIOS more complicated. Stepan: No, the information has to be reorganized. Currently pirq and mptables Stepan: have to be hand crafted, and this is the complicated thing. Instead the Stepan: abstract information should be put to the configuration filess, if it Stepan: can not be probed. YH: I suggest to add 1. one node id to ram_resource, so the index will be (idx<<8 | nodeid), So I can re-use ram_resource in pci_domain for SRAT creating. 2. for apci_cluster_id, will add two fields core_id and node_id, ( instantiate it when cpu_init)... 3. pci device: add pci_irq_routing, and pci_possiable_resource ( for apci _PRT and _PRS...) how about ioapci in the internal tree? YH

1 0

[LinuxBIOS] serial debug messages workaround
by Doug Bell 07 Sep '05

07 Sep '05

We're working on bringing up linuxbios on the epia-sp. We found the serial output is locking up strangely in a busy wait within src/pc80/serial.c: static void uart_tx_byte(unsigned char data) { uart_wait_to_tx_byte(); // this one causes trouble outb(data, TTYS0_BASE + UART_TBR); /* Make certain the data clears the fifos */ uart_wait_until_sent(); } If the uart_wait_to_tx_byte() call is removed, there is no lockup on serial output. The lockup on serial output always occurs in the same place, based on whatever would be printed. It's not random at all across reboots, however it is fairly random as regards code changes. That is, if you have a loop that prints stuff out, then try to print out some other stuff, somewhere along the line it will lock up during printing. Where it locks up is always the same place in the serial output stream, provided the code remains unchainged. The uart is inside the VT1211 superio device. Does anyone have any clue as to why this is locking up. As a workaround we've just commented out the uart_wait_to_tx_byte() for now, but that's nonstandard and might break other things. We are not yet checking in any code. Thanks for any advice/ideas.

1 0

[LinuxBIOS] FYI on the linuxbios summit: Richard Bruner, AMD Fellow, will lead off
by Ronald G Minnich 07 Sep '05

07 Sep '05

We're going to have the privelege of hearing from Richard Bruner of AMD for the first hour-long talk at the linuxbios summit. Hope to see you all there. ron

1 0

RE: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16
by Lu, Yinghai 07 Sep '05

07 Sep '05

8111 and 8131 only have 4 bit apic id. YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of ebiederman(a)lnxi.com Sent: Wednesday, September 07, 2005 8:40 AM To: yhlu Cc: linuxbios(a)openbios.org; Lu, Yinghai Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 yhlu <yinghailu(a)gmail.com> writes: > at such case We need to enable 8 bit ext apic id mode for Opteron. So Opteron > could use 0x10 above. > and leave 0-0x0f to the device that can not support 8 bit apic id. > > I'm considering to align apic id lifting to the way that Norma BIOS does. Are io-apics limited to apic ids 0x0-0x0f as well? My memory says to me the limit should be 0x0-0xff... Eric -- LinuxBIOS mailing list LinuxBIOS(a)openbios.org http://www.openbios.org/mailman/listinfo/linuxbios

1 0

[LinuxBIOS] LNXI Merge: lnxi-patch-06/16
by jason schildt 07 Sep '05

07 Sep '05

DESCRIPTION: ---------------------------------------------- ## lnxi-patch-6 ## src/cpu/x86/tsc/delay_tsc.c cpu_relax() gets called unconditionally. DIFFSTAT: ---------------------------------------------- delay_tsc.c | 4 ---- 1 files changed, 4 deletions(-) PATCH: ---------------------------------------------- Index: delay_tsc.c =================================================================== --- delay_tsc.c (revision 1105) +++ delay_tsc.c (working copy) @@ -159,11 +159,7 @@ count = rdtscll(); stop = clocks + count; while(stop > count) { -#ifdef CONFIG_SMP -#if CONFIG_SMP == 1 cpu_relax(); -#endif -#endif count = rdtscll(); } } -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx

4 6

RE: [LinuxBIOS] Re: topics for linuxbios summit
by Lu, Yinghai 07 Sep '05

07 Sep '05

Did you notice that our list can not searched by google now? YH -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Wed 9/7/2005 1:30 AM To: Eric W. Biederman; linuxbios(a)openbios.org; Lu, Yinghai Subject: Re: [LinuxBIOS] Re: topics for linuxbios summit * yhlu <yinghailu(a)gmail.com> [050907 06:04]: > > Before we generate ACPI or anything else we need to move the relevant > > information > > into the internal device tree. > > YH: Good point, But I worry that we make LinuxBIOS more complicated. No, the information has to be reorganized. Currently pirq and mptables have to be hand crafted, and this is the complicated thing. Instead the abstract information should be put to the configuration filess, if it can not be probed. > 11. LinuxBIOS Maintenance. How can we do better? > YH: I agree we need > b. move back the list and public source tree to US. what's wrong with the status quo? Stefan

2 1

RE: [LinuxBIOS] Re: topics for linuxbios summit
by Lu, Yinghai 07 Sep '05

07 Sep '05

eric> > Before we generate ACPI or anything else we need to move the relevant eric> > information eric> > into the internal device tree. eric> > YH: Good point, But I worry that we make LinuxBIOS more complicated. Stepan: No, the information has to be reorganized. Currently pirq and mptables Stepan: have to be hand crafted, and this is the complicated thing. Instead the Stepan: abstract information should be put to the configuration filess, if it Stepan: can not be probed. YH: I suggest to add 1. one node id to ram_resource, so the index will be (idx<<8 | nodeid), So I can re-use ram_resource in pci_domain for SRAT creating. 2. for apci_cluster_id, will add two fields core_id and node_id, ( instantiate it when cpu_init)... 3. pci device: add pci_irq_routing, and pci_possiable_resource ( for apci _PRT and _PRS...) how about ioapci in the internal tree? YH

1 0

RE: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16
by Lu, Yinghai 07 Sep '05

07 Sep '05

>Are io-apics limited to apic ids 0x0-0x0f as well? > >My memory says to me the limit should be 0x0-0xff... before enable ext_apic_id, Opteron only can use 4 bit for apic id, So only 16 apic id. After enable ext_apic_id in every opteron, it will use 8 bit for apic id, So we got 256 apic id. Then CPU can use 0x10 above apic id. some io apic device only support 4 bit apic id, So We can leave 0x0-0xf to them. that is for AMD, it is said that intel's from p4 has 256 for default. I cut and paste something for you from Kernel list. > - 1: 82489DX -- communication using a five-wire inter-APIC bus, 8-bit > physical ID, 32-bit logical ID, etc., > > - 2: Pentium-style -- communication using a three-wire inter-APIC bus, > 4-bit physical ID, 8-bit logical ID, etc., > > - 3: P4-style -- communication using the system bus, 8-bit physical ID, > 8-bit logical ID, etc. >According to what AMD told us, all K8 CPUs support 8-bit APIC IDs >("extended APIC IDs" in their speak), but they are only enabled >"when both ApicExtId and ApicExtBrdCst in the HyperTransport Transaction >Control Register are set". YH

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