coreboot

coreboot@coreboot.org

11 participants
39714 discussions

Re: buildtarget error
by Richard Smith 20 Jan '05

20 Jan '05

> You should have one per pci slot, as well.. but those should only be > there if something is in the pci slot.. We really need dynamic table > creation for that. > > But all in all, 1 per device in lspci is about right I only have one slot (and only if its loaded) I have many devices soldered onto the board. Eventually perhaps I'll break you guys of this "commercial motherboard only" mentality. *joke* *grin* My question was more along the lines of a device like the south bridge has many devices in that so does each device in there count or just ones that need a PIRQ? -- Richard A. Smith

2 2

V2 questions
by Richard Smith 20 Jan '05

20 Jan '05

I'm starting up the learning curve.... Whats the mapping between the various CPU models in the intel directory and marketing cpu names as I know them like Pentium III, P3 celeron, Pentuim 4, etc. I don't completely grok the fallback and normal stuff. I know the theory but not practice. I know this is a FAQ. Explain it to me and I'll document it for the next guy. Why are all the payloads out of tree? Be nice if there was a payloads directory with some known good payloads. -- Richard A. Smith

4 11

Best price on the EPIA-MII 1.2GHz?
by Adam Talbot 20 Jan '05

20 Jan '05

What is the best price out there on the EPIA-MII 1.2GHz. Can you beat $189 + $9 shipping ($198) http://www.provantage.com/buy-7VIAT00F-via-cle266-ddr-motherboard-technolog… -Adam

3 3

[PROPOSAL] enhanced table dumping
by Stefan Reinauer 20 Jan '05

20 Jan '05

Hi, Porting LinuxBIOS to new motherboards has become easier and easier over the last period of time. There's almost no need for assembler coding anymore, Hypertransport featured systems do a completely automatical setup of their non coherent devices. On K8 systems even the coherent devices get initialized automatically. But there is still one major drawback when it comes to boot an operating system: Passing the information. No, this is not going to be a discussion about whether this or that table is preferred. The problem is simply that for each motherboard these tables have to be redone over and over: The pirq table, the mp table and the acpi tables. This leads to hand made tables that often contain errors or have to be adapted with architectural changes that might have consequences wrt the bus numbering for instance. * pirq tables do need knowledge that is not provided in the config files yet (wiring) * MP tables contain a static "compatibility part" and have to have entries for devices on the bus and their interrupts. This is very similar to the pirq table. But they also need information on available APICs. These could be provided from the device tree. We know we have an 8131 in there, so we know 2 IOAPICs belong on the list. We also know what busses hang off that 8131, so we can generate most of the interrupt tables. * ACPI tables need information on the Apics as well. Now the ACPI implementation I wrote a longer while ago is completely static and basically only works for systems with a single IOAPIC and not very well even on those. Autocreation of those tables should belong to the driver code of each supported device. The information about the 8131 should come from the 8131 code, the information for the 8111 should come from the 8111 code, and so on. The solution could be to enhance the struct device_operations by an additional member write_tables(device_t dev, table_t id) which can be subsequently called by each of the write_*_tables() functions, adding their part to the table. This would also allow to extend the generic information provided by the bridges, by adding such functionality to the mainboard specific code, so we won't end up with something that is worse than now in any case. Roughly thinking, table_t could look like: enum { MPTABLE_CPUS, MPTABLE_APICS, MPTABLE_BUSSES, MPTABLE_DEVICES, ACPI_APICS, ACPI_COMPLETE_TABLES, } table_t; and dev::write_tables() would look similar to this: static void amd8111_write_tables(device_t dev, table_t id) { struct resource *res; switch (id) { case MPTABLE_BUSSES: smp_write_bus(mc, dev.link.secondary, "PCI "); [...] break; case MPTABLE_APICS: res = find_resource(dev, PCI_BASE_ADDRESS_0); if (!res) break; smp_write_ioapic(mc, last_ioapic()+1, AMD8131_IOAPIC_VERSION, res->base); [...] break; case ACPI_COMPLETE_TABLES: acpi_create_hpet(...); [...] break; case ACPI_APICS: // We're adding an APIC to an ACPI MADT: acpi_create_madt_ioapic(...); [...] break; default: // all unneeded and unknown table types are ignored. break; } } Since everything is a device in LinuxBIOS, we could create these tables in a nice and ordered manner. Comments? Flames? Better ideas? Stefan

4 21

buildtarget error
by Richard Smith 20 Jan '05

20 Jan '05

Ok so slowly I'm trying to move to V2. Step 1 was to just try and get some serial action going. I added my CPU and superIO and setup my mainboard directory with a simple config file. I've got a traceback on buildtarget though. So aparently I'm not filling out everything that needs to be filled. My config is really simple with no northbridges or southbridges. Just a cpu. All I want to try to do right now is get the early serial port up. Attached is my mainboard config.lb and options.lb and the output from buildtarget. Perhaps there are some additional debug flags I can turn on for more info? -- Richard A. Smith

3 9

what cpu models are tested?
by Richard Smith 20 Jan '05

20 Jan '05

cpu model_6xx will not build. microcode_MU16930c.h: No such file or directory. I'll play with some others. Also if you forget to provide enough arguments to romcc you get an 'Invalid tolken' error. A nice enhancement would be to count arguments and if they don't match then give a incorrect number of arguments error. -- Richard A. Smith

2 2

memory reported to OS
by Gin 20 Jan '05

20 Jan '05

Is it mandatory to report Reserved Memory region to the OS? For example, the IOAPICs memory-mapped addresses? Would that be a problem if Linux kernel didn't see it be claimed as RESERVED? It seems Linuxbios doesn't claim any memory regions as RESERVED. gin

2 1

problem with PPC
by Greg Watson 20 Jan '05

20 Jan '05

Well, I have a problem. The PPC code, which was working in November, is now no longer working. I rebuilt the Sandpoint image using the same configuration file, but now I just get garbage on the screen. To help me track this down, can anyone who has made changes that are likely to have cause this, please let me know. Greg

1 0

what cpu model is a PIII?
by Richard Smith 19 Jan '05

19 Jan '05

I'm trying to setup my /cpu/intel/socket_PGA370 directory. What cpu model should I use? -- Richard A. Smith

1 0

Re: Small and fast systerm.
by Bari Ari 19 Jan '05

19 Jan '05

Frank wrote: >> >>Just FYI we're working on V2 for the CN400 (Epia-nano). >> >>-Bari > > > The board looks very attractive for an application I'm thinking > about. If I were to go out and buy an Epia board tomorrow, which > one should I get if I want to use V2... Anyone know the status of all the Epia's working with V2? -Bari

4 7

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