coreboot January 2005

coreboot@coreboot.org

43 participants
155 discussions

EPIA going immediately to fallback image?
by Al Hooton 21 Jan '05

21 Jan '05

Mainboard: EPIA 800. Building LB appears to go well, using these steps (my Options.lb and Config.lb are listed at the end of this note): - cd <stuff>/targets - ./buildtarget via/epia - cd via/epia/epia - make The build appears to go without a hitch. At that point I write targets/via/epia/epia/linuxbios.rom to my flash part, and boot the board, only to be greeted with this: LinuxBIOS-1.1.7.0Fallback Wed Jan 19 16:11:07 PST 2005 starting... vt8601 init starting Slot 00 is SDRAM 04000000 bytes x2 Slot 01 is empty Slot 02 is empty Slot 03 is empty vt8601 done Can somebody let me know what might cause it to immediately go to the fallback image, instead of the normal image that has my filo payload in it? My Options.lb and Config.lb are below -- I didn't include the build output because it's so big, but if it would help anyone I can send it along. Thanks for any and all help! -Al ------<Options.lb>-------- uses HAVE_MP_TABLE uses HAVE_PIRQ_TABLE uses USE_FALLBACK_IMAGE uses HAVE_FALLBACK_BOOT uses HAVE_HARD_RESET uses HAVE_OPTION_TABLE uses USE_OPTION_TABLE uses CONFIG_ROM_STREAM uses IRQ_SLOT_COUNT uses MAINBOARD uses MAINBOARD_VENDOR uses MAINBOARD_PART_NUMBER uses LINUXBIOS_EXTRA_VERSION uses ARCH uses FALLBACK_SIZE uses STACK_SIZE uses HEAP_SIZE uses ROM_SIZE uses ROM_SECTION_SIZE uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE uses XIP_ROM_SIZE uses XIP_ROM_BASE uses HAVE_MP_TABLE uses CROSS_COMPILE uses CC uses HOSTCC uses OBJCOPY ## ARH -- added to get the EPIA 800 board to use the serial console uses CONFIG_CONSOLE_SERIAL8250 default CONFIG_CONSOLE_SERIAL8250=1 ## ROM_SIZE is the size of boot ROM that this board will use. default ROM_SIZE = 256*1024 ### ### Build options ### ## ## Build code for the fallback boot ## default HAVE_FALLBACK_BOOT=1 ## ## no MP table ## default HAVE_MP_TABLE=0 ## ## Build code to reset the motherboard from linuxBIOS ## default HAVE_HARD_RESET=1 ## ## Build code to export a programmable irq routing table ## default HAVE_PIRQ_TABLE=1 default IRQ_SLOT_COUNT=5 #object irq_tables.o ## ## Build code to export a CMOS option table ## default HAVE_OPTION_TABLE=1 ### ### LinuxBIOS layout values ### ## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy. default ROM_IMAGE_SIZE = 65536 default FALLBACK_SIZE = 131072 ## ## Use a small 8K stack ## default STACK_SIZE=0x2000 ## ## Use a small 16K heap ## default HEAP_SIZE=0x4000 ## ## Only use the option table in a normal image ## #default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE default USE_OPTION_TABLE = 0 default _RAMBASE = 0x00004000 default CONFIG_ROM_STREAM = 1 ## ## The default compiler ## default CROSS_COMPILE="" default CC="$(CROSS_COMPILE)gcc -m32" default HOSTCC="gcc" end ------<Config.lb>------- # Sample config file for EPIA # This will make a target directory of ./epia target epia mainboard via/epia # # Via Epia romimage "normal" option USE_FALLBACK_IMAGE=0 option ROM_IMAGE_SIZE=0x10000 option LINUXBIOS_EXTRA_VERSION=".0Normal" # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf # payload ../../../../tg3--ide_disk.zelf # payload ../../../../../lnxieepro100.ebi # payload ../../../../../../filo.elf payload ../../../../../../filo-0.4.2/filo.elf end romimage "fallback" option USE_FALLBACK_IMAGE=1 option ROM_IMAGE_SIZE=0x10000 option LINUXBIOS_EXTRA_VERSION=".0Fallback" # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf # payload ../../../../tg3--ide_disk.zelf # payload ../../../../../lnxieepro100.ebi # payload ../../../../../../filo.elf payload ../../../../../../filo-0.4.2/filo.elf end buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" -- Al Hooton al-at-hootons-dot-org ======== Maintainer of the linux-based open-source project Parapin. http://www.sf.net/projects/parapin/ ========

4 15

Clarification about TianoCore licensing (fwd)
by Ronald G. Minnich 21 Jan '05

21 Jan '05

An FYI from intel. Thanks, Andrew! ron ---------- Forwarded message ---------- Date: Fri, 21 Jan 2005 10:12:02 -0800 From: Andrew Kelly <akelly(a)collab.net> To: Ronald G. Minnich <rminnich(a)lanl.gov> Subject: Clarification about TianoCore licensing Ron, I noticed on the Linuxbios mailing list that there was a misinterpretation of the TianoCore licensing and I wanted to clear it up. In the thread http://www.clustermatic.org/pipermail/linuxbios/2005-January/010286.html its stated: --------------------------- Grant of License to Use [..] You acknowledge and agree that You will not, directly or indirectly: (i) reverse engineer, decompile, disassemble or otherwise attempt to discover the underlying source code or underlying ideas or algorithms of the Software; (ii) modify, translate, or create derivative works based on the Software; (iii) rent, lease, distribute, sell, resell or assign, or otherwise transfer rights to the Software; or (iv) remove any proprietary notices in the Software. [..] ------------------ This is correct verbage, but it describes the use of the CollabNet platform that the site is built upon, not the source code Intel has opened up (in other words, CollabNet's Enterprise Edition collaborative development platform is indeed proprietary). However this in no way is related to the code being developed using this platform. The license for each project's codebase is defined on a project-by-project basis, with the only restriction being that they are open source (we anticipate other platform firmware-related projects starting up on the site, both from inside and outside of Intel). Section 3 of the site Terms of Service describes this: <snip> 3. Other Licenses This site contains other licenses applicable to content on this site ("Other Licenses"), which are chosen on a project-by-project basis. All content within a project is governed by the license referenced on that project's homepage. All Intel-sponsored projects (as indicated on the project homepage) will be governed by the BSD License from Intel <http://www.tianocore.org/intelbsd.html> , with the exception of the Fat-Driver project, which is governed by the BSD License (Modified for FAT32 by Intel) <http://www.tianocore.org/fat32license.html> . All non-Intel sponsored projects will be governed by the license of choice of the project owner, so long as the license is approved by the Open Source Initiative <http://www.opensource.org/> . <snip> Rest assured the Intel code on TianoCore is released under BSD. Sorry for the confusion, and I'd appreciate it if you'd pass this on when you feel its appropriate. Thanks, Andrew K.

1 0

fallback/normal
by Stefan Reinauer 21 Jan '05

21 Jan '05

Hi, What's the most comfortable way to switch between normal and fallback images in LinuxBIOS on AMD64. I was using lxbios from http://www.llnl.gov/linux/lxbios/lxbios.html But when changing the parameters to Normal, the next boot LinuxBIOS still says "Invalid CMOS LB checksum" and it sets "boot_option" back to Fallback. Stefan

3 2

kudos to the V2 coders
by Richard Smith 20 Jan '05

20 Jan '05

Starting as a complete V2 newbie, in less than 9 hours of work and on the _very_ first successful compile, LinuxBIOS V2 produced serial code output on our IMS board! To all those that worked so hard on the framework. You rock. Looks like it works quite nicely. I've got other things to work on now for a bit and a large mountain called SDRAM is but I'm on the path. -- Richard A. Smith

2 2

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

← Newer
1
2
3
4
5
6
7
8
...
16
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 January 2005