coreboot June 2009

coreboot@coreboot.org

84 participants
500 discussions

[v2] r4354 - in trunk/coreboot-v2/src: mainboard/via/epia-m700 northbridge/via/vx800
by svn＠coreboot.org 09 Jun '09

09 Jun '09

Author: stepan Date: 2009-06-09 17:22:47 +0200 (Tue, 09 Jun 2009) New Revision: 4354 Modified: trunk/coreboot-v2/src/mainboard/via/epia-m700/Options.lb trunk/coreboot-v2/src/northbridge/via/vx800/dram_init.h Log: this port is horribly broken and should not have been checked in. This patch gets us through config, but it fails during build because the original patch duplicated some files for VIA systems. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/coreboot-v2/src/mainboard/via/epia-m700/Options.lb =================================================================== --- trunk/coreboot-v2/src/mainboard/via/epia-m700/Options.lb 2009-06-09 14:44:37 UTC (rev 4353) +++ trunk/coreboot-v2/src/mainboard/via/epia-m700/Options.lb 2009-06-09 15:22:47 UTC (rev 4354) @@ -72,17 +72,17 @@ uses DCACHE_RAM_BASE uses DCACHE_RAM_SIZE uses CONFIG_USE_INIT -uses MAX_RAM_SLOTS -uses USB_ENABLE -uses EHCI_ENABLE -uses HPET_ENABLE -uses USB_PORTNUM -uses FULL_ROM_SIZE -uses FULL_ROM_BASE -uses PAYLOAD_IS_SEABIOS -uses VIACONFIG_TOP_SM_SIZE_MB -uses VIACONFIG_VGA_PCI_10 -uses VIACONFIG_VGA_PCI_14 +#uses MAX_RAM_SLOTS +#uses USB_ENABLE +#uses EHCI_ENABLE +#uses HPET_ENABLE +#uses USB_PORTNUM +#uses FULL_ROM_SIZE +#uses FULL_ROM_BASE +#uses PAYLOAD_IS_SEABIOS +#uses VIACONFIG_TOP_SM_SIZE_MB +#uses VIACONFIG_VGA_PCI_10 +#uses VIACONFIG_VGA_PCI_14 ## New options default USE_DCACHE_RAM = 1 @@ -91,18 +91,18 @@ # default DCACHE_RAM_BASE = 0xfec00000 # HPET may use this. default DCACHE_RAM_SIZE = 8 * 1024 default CONFIG_USE_INIT = 0 -default MAX_RAM_SLOTS = 2 -default USB_ENABLE = 1 -default EHCI_ENABLE = 1 -default HPET_ENABLE = 1 -default USB_PORTNUM = 2 -default FULL_ROM_SIZE = 512 * 1024 -default FULL_ROM_BASE = (0xffffffff - FULL_ROM_SIZE + 1) -default VIACONFIG_TOP_SM_SIZE_MB = 0 +#default MAX_RAM_SLOTS = 2 +#default USB_ENABLE = 1 +#default EHCI_ENABLE = 1 +#default HPET_ENABLE = 1 +#default USB_PORTNUM = 2 +#default FULL_ROM_SIZE = 512 * 1024 +#default FULL_ROM_BASE = (0xffffffff - FULL_ROM_SIZE + 1) +#default VIACONFIG_TOP_SM_SIZE_MB = 0 # default VIACONFIG_VGA_PCI_10 = 0xd0000008 # default VIACONFIG_VGA_PCI_14 = 0xfd000000 -default VIACONFIG_VGA_PCI_10 = 0xf8000008 -default VIACONFIG_VGA_PCI_14 = 0xfc000000 +#default VIACONFIG_VGA_PCI_10 = 0xf8000008 +#default VIACONFIG_VGA_PCI_14 = 0xfc000000 default ROM_SIZE = 512 * 1024 default CONFIG_IOAPIC = 1 Modified: trunk/coreboot-v2/src/northbridge/via/vx800/dram_init.h =================================================================== --- trunk/coreboot-v2/src/northbridge/via/vx800/dram_init.h 2009-06-09 14:44:37 UTC (rev 4353) +++ trunk/coreboot-v2/src/northbridge/via/vx800/dram_init.h 2009-06-09 15:22:47 UTC (rev 4354) @@ -110,7 +110,8 @@ #define SPD_DATA_SIZE 44 //Dram cofig are /*the most number of socket*/ -//#define MAX_RAM_SLOTS 2 +#define MAX_RAM_SLOTS 2 + #define MAX_SOCKETS MAX_RAM_SLOTS #define MAX_DIMMS MAX_SOCKETS /*every sockets can plug one DIMM */ /*the most number of RANKs on a DIMM*/

1 0

build service results for r4353
by coreboot information 09 Jun '09

09 Jun '09

Dear coreboot readers! This is the automatic build system of coreboot. The developer "rminnich" checked in revision 4353 to the coreboot repository. This caused the following changes: Change Log: Fix a little white space issue. Also, don't copy the rom image if it is already in its correct location. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Build Log: Configuration of via:epia-m700 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4353&device=epia-m700&vend… If something broke during this checkin please be a pain in rminnich's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

[v2] r4353 - trunk/coreboot-v2/src/devices
by svn＠coreboot.org 09 Jun '09

09 Jun '09

Author: rminnich Date: 2009-06-09 16:44:37 +0200 (Tue, 09 Jun 2009) New Revision: 4353 Modified: trunk/coreboot-v2/src/devices/pci_rom.c Log: Fix a little white space issue. Also, don't copy the rom image if it is already in its correct location. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/coreboot-v2/src/devices/pci_rom.c =================================================================== --- trunk/coreboot-v2/src/devices/pci_rom.c 2009-06-08 13:05:47 UTC (rev 4352) +++ trunk/coreboot-v2/src/devices/pci_rom.c 2009-06-09 14:44:37 UTC (rev 4353) @@ -55,7 +55,7 @@ rom_address = dev->rom_address; printk_debug("On mainboard, rom address for %s = %lx\n", dev_path(dev), rom_address); - } else { + } else { rom_address = pci_read_config32(dev, PCI_ROM_ADDRESS); printk_debug("On card, rom address for %s = %lx\n", dev_path(dev), rom_address); @@ -126,9 +126,11 @@ extern device_t vga_pri; // the primary vga device, defined in device.c if (dev != vga_pri) return NULL; // only one VGA supported #endif - printk_debug("copying VGA ROM Image from %p to 0x%x, 0x%x bytes\n", + if ((void *)PCI_VGA_RAM_IMAGE_START != rom_header) { + printk_debug("copying VGA ROM Image from %p to 0x%x, 0x%x bytes\n", rom_header, PCI_VGA_RAM_IMAGE_START, rom_size); - memcpy((void *)PCI_VGA_RAM_IMAGE_START, rom_header, rom_size); + memcpy((void *)PCI_VGA_RAM_IMAGE_START, rom_header, rom_size); + } return (struct rom_header *) (PCI_VGA_RAM_IMAGE_START); }

1 0

[v3] r1172 - coreboot-v3/util/x86emu
by svn＠coreboot.org 09 Jun '09

09 Jun '09

Author: rminnich Date: 2009-06-09 13:14:26 +0200 (Tue, 09 Jun 2009) New Revision: 1172 Modified: coreboot-v3/util/x86emu/x86_asm.S Log: There are some problems with the way these interrrupts were managed. First, the CLI erases any knowledge of whether interrupts were enabled or disabled. Second, the STI works badly on qemu; we get an immediate INT #0 as soon as the STI happens. This spurious interrupt doesn't happen on real hardware (YET!)but, that said, I don't think this code should be doing cli and sti. I can't see a reason to enable interrupts at this point in coreboot. This change fixes the observed qemu failures. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: coreboot-v3/util/x86emu/x86_asm.S =================================================================== --- coreboot-v3/util/x86emu/x86_asm.S 2009-06-07 17:36:43 UTC (rev 1171) +++ coreboot-v3/util/x86emu/x86_asm.S 2009-06-09 11:14:26 UTC (rev 1172) @@ -71,11 +71,6 @@ // FIXME: Should this function be called with regparm=0? movl 8(%ebp), %ecx - /* Clear interrupts before making a - * transition to Real Mode - */ - cli - /* Activate the right segment descriptor real mode. */ ljmp $0x28, $RELOCATED(1f) 1: @@ -111,14 +106,11 @@ movl $0x1000, %eax movl %eax, %esp - /* Load our 16 it idt */ + /* Load our 16 bit idt */ xor %ax, %ax mov %ax, %ds lidt __realmode_idt - /* All critical work is done, allow interrupts again */ - sti - /* Set all segments to 0x0000, ds to 0x0040 */ mov %ax, %es mov %ax, %fs @@ -133,11 +125,6 @@ lcall $0xc000, $0x0003 /* ************************************ */ - /* Clear interrupts before making a - * transition to Protected Mode - */ - cli - /* If we got here, just about done. * Need to get back to protected mode */ @@ -161,9 +148,6 @@ /* restore proper idt */ lidt idtarg - /* All critical work is done, allow interrupts again */ - sti - /* and exit */ mov __stack, %esp popal @@ -179,11 +163,6 @@ mov %esp, __stack - /* Clear interrupts before making a - * transition to Real Mode - */ - cli - /* This configures CS properly for real mode. */ ljmp $0x28, $RELOCATED(1f) 1: @@ -228,9 +207,6 @@ mov %ax, %ds lidt __realmode_idt - /* All critical work is done, allow interrupts again */ - sti - /* Set all segments to 0x0000 */ mov %ax, %ds mov %ax, %es @@ -250,11 +226,6 @@ movw $0, %di int $0x10 - /* Clear interrupts before making a - * transition to Protected Mode - */ - cli - /* Ok, the job is done, now go back to protected mode coreboot */ movl %cr0, %eax orl $PE, %eax @@ -274,9 +245,6 @@ /* restore coreboot's 32-bit IDT */ lidt idtarg - /* All critical work is done, allow interrupts again */ - sti - /* Exit */ mov __stack, %esp popal @@ -299,11 +267,6 @@ andl $0xff, %eax pushl %eax /* ... and make it the first parameter */ - /* Clear interrupts before making a - * transition to Protected Mode - */ - cli - /* Switch to protected mode */ movl %cr0, %eax orl $PE, %eax @@ -322,9 +285,6 @@ lidt idtarg - /* All critical work is done, allow interrupts again */ - sti - /* Call the C interrupt handler */ movl $interrupt_handler, %eax call *%eax @@ -344,11 +304,6 @@ mov %ax, %gs mov %ax, %ss - /* Clear interrupts before making a - * transition to Real Mode - */ - cli - /* Disable Protected Mode */ movl %cr0, %eax andl $~PE, %eax @@ -366,9 +321,6 @@ mov %ax, %ds lidt __realmode_idt - /* All critical work is done, allow interrupts again */ - sti - /* Set up our segment registers to segment 0x0000 */ mov %ax, %es mov %ax, %fs

1 0

Re: [coreboot] Via EPIA-N(L) C3/CN400 Support - Help Wanted
by Harrison, Jon (SELEX GALILEO, UK) 09 Jun '09

09 Jun '09

Myles, Thanks for the link, that's exactly what I've been looking for! I seem to have been looking round the coreboot pages for days on end and managed to miss this. I've not had a play with qemu, but have seen it mentioned on the list. I think that's my next port of call. I'll have more of a tinker first. Regards, Jon -----Original Message----- From: coreboot-bounces(a)coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of coreboot-request(a)coreboot.org Sent: 09 June 2009 07:29 To: coreboot(a)coreboot.org Subject: coreboot Digest, Vol 52, Issue 65 *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Send coreboot mailing list submissions to coreboot(a)coreboot.org To subscribe or unsubscribe via the World Wide Web, visit http://www.coreboot.org/mailman/listinfo/coreboot or, via email, send a message with subject or body 'help' to coreboot-request(a)coreboot.org You can reach the person managing the list at coreboot-owner(a)coreboot.org When replying, please edit your Subject line so it is more specific than "Re: Contents of coreboot digest..." Today's Topics: 1. Re: Via EPIA-N(L) C3/CN400 Support - Help Wanted (Myles Watson) 2. Re: Is this boar/chipset combination supported? (saueimer) 3. Re: Is this boar/chipset combination supported? (Stefan Reinauer) 4. Re: [v3] r1170 - coreboot-v3/util/x86emu (ron minnich) 5. Re: Is this boar/chipset combination supported? (ron minnich) 6. Re: Via EPIA-N(L) C3/CN400 Support - Help Wanted (bari) 7. VIA VT8235 + SST39SF020A problem (Murawski Mateusz) 8. Re: [v3] r1170 - coreboot-v3/util/x86emu (Stefan Reinauer) ---------------------------------------------------------------------- Message: 1 Date: Mon, 8 Jun 2009 15:09:15 -0600 From: Myles Watson <mylesgw(a)gmail.com> To: Jon Harrison <bothlyn(a)blueyonder.co.uk> Cc: coreboot(a)coreboot.org Subject: Re: [coreboot] Via EPIA-N(L) C3/CN400 Support - Help Wanted Message-ID: <2831fecf0906081409i3c9ce565t5166997f40949d74(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 > I'm currently working on porting coreboot to the Via EPIA-N(L) i.e. > C3/CN400/VT8237R/Winbond SuperIO. Welcome! > I'm a fairly competent embedded systems designer/coder, and I'm aiming to > get to the point where I can use the EPIA to run a small linux kernel and > custom service from flash to act as a data logger from a custom perpheral to > a SATA disk. > > I'm not NDAd with Via (spent months trying to do this and gave up ?after > getting the run around for so long) ?but have aquired some data on the CN400 > that has allowed me to get this far. I don't have the BIOS Porting Guide, > which suspect would be quite illuminating, if there is anyone out there who > does have this and could review/correct my code for errors I'd appreciate > it. I'm not the right person for that, but hopefully this will help a little anyway. > I've got to the point where I have flashrom programming the board, I have a > working build environment for V2 which is running the early romcc compiled > code and seems to have done the CN400 meminit stuff OK, near as I can tell I > am able to access SDRAM OK from romcc code (the early serial stuff is up and > running OK, and i can get debug out that way), but I'm getting strange > things happening when jumping to copy_and_run_core. A log file would probably be helpful. > I think that the basic problem is a linking/location problem. > > Options.lb doesn't seem to let me turn on print_spew in the gcc code but > works OK in the romcc code, and > the .map file looks suspicious to me with > loads of constants all defined at the same location. It's probably fine, but you can compare with the map file of a working board to see what it looks like. There are several constants defined at the same location, and the build process will usually fail if they're wrong. > I'm happy to do the leg work if someone can give me a steer into how all of > the different ROM_SIZE, ROM_SECTION_SIZE PAYLOAD_SIZE, FALLBACK_SIZE etc. > etc. relate to the linking and location of code. I'm finding this a bit > impenetrable at the moment. Have you seen this page? http://www.coreboot.org/Anatomy_of_a_Failover_coreboot_v2_Image You probably want an image that only contains fallback, which makes life simpler anyway. Have you played around with qemu? It has a single image solution implemented with CBFS (which is new) or you can go back a few revisions to before CBFS. Thanks, Myles ------------------------------ Message: 2 Date: Mon, 8 Jun 2009 23:01:19 +0200 From: saueimer <saueimer(a)googlemail.com> To: coreboot(a)coreboot.org Subject: Re: [coreboot] Is this boar/chipset combination supported? Message-ID: <51ec7b340906081401r592aa780h41beddd0a9510763(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi again, how about the VIA EPIA EX15000G, CX700M2 (PC2-4200U DDR2) mainboard? Is or will this be supported? I am trying to build up a PC for my car so I need a ITX-motherboard and a DVI-Port. Coreboot in cobination with a SSD as harddisk would ensure a very quick boot ;) So if anyone could advise some board to me, if the upper one is not supported, I would really apprechiate it! Thanks in advance! 2009/6/5 Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> > Hi, > > On 05.06.2009 12:59, saueimer wrote: > > Jetway JNC62K SocketAM2/AM2+ Mini-ITX > > > > Unfortunately the NVidia MCP78S chipset is not supported yet and it is > unlikely we'll support it in the future because we don't have the needed > data sheets and programming information. > > Regards, > Carl-Daniel > > -- > http://www.hailfinger.org/ > >

1 0

Via EPIA-N(L) C3/CN400 Support - Help Wanted
by Jon Harrison 09 Jun '09

09 Jun '09

Hi Guys, I'm currently working on porting coreboot to the Via EPIA-N(L) i.e. C3/CN400/VT8237R/Winbond SuperIO. I'm a fairly competent embedded systems designer/coder, and I'm aiming to get to the point where I can use the EPIA to run a small linux kernel and custom service from flash to act as a data logger from a custom perpheral to a SATA disk. I'm not NDAd with Via (spent months trying to do this and gave up after getting the run around for so long) but have aquired some data on the CN400 that has allowed me to get this far. I don't have the BIOS Porting Guide, which suspect would be quite illuminating, if there is anyone out there who does have this and could review/correct my code for errors I'd appreciate it. I've got to the point where I have flashrom programming the board, I have a working build environment for V2 which is running the early romcc compiled code and seems to have done the CN400 meminit stuff OK, near as I can tell I am able to access SDRAM OK from romcc code (the early serial stuff is up and running OK, and i can get debug out that way), but I'm getting strange things happening when jumping to copy_and_run_core. I think that the basic problem is a linking/location problem. Options.lb doesn't seem to let me turn on print_spew in the gcc code but works OK in the romcc code, and the .map file looks suspicious to me with loads of constants all defined at the same location. If anyone is interested in helping me then I'd appreciate it. I'm happy to do the leg work if someone can give me a steer into how all of the different ROM_SIZE, ROM_SECTION_SIZE PAYLOAD_SIZE, FALLBACK_SIZE etc. etc. relate to the linking and location of code. I'm finding this a bit impenetrable at the moment. Alternatively if anyone could suggest a good host debug/emulation environment to workout what's going on....... Thanks, Jon

3 2

[flashrom] SST SST49LF008A and FreeBSD
by Alexander Logvinov 08 Jun '09

08 Jun '09

Hello! I received a mail from FreeBSD user about using flashrom on SuperMicro boxes with FreeBSD amd64. Reading the flashrom works for him alright, but writing doesn't: # uname -a FreeBSD XXXXXXXXXXXXXXXXXX 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 # flashrom -V -w 6dva1197.rom Found chipset "Intel 6300ESB", enabling flash write... OK. Calibrating delay loop... OK. Found chip "SST SST49LF008A" (1024 KB) at physical address 0xfff00000. Flash image seems to be a legacy BIOS. Disabling checks. ERASE FAILED! Here is a verbose log of trunk version: http://pastebin.com/m92cd709 Let'me know if you want more information. Thanks! -- Best regards, Alexander Logvinov

1 0

build service results for r4352
by coreboot information 08 Jun '09

08 Jun '09

Dear coreboot readers! This is the automatic build system of coreboot. The developer "uwe" checked in revision 4352 to the coreboot repository. This caused the following changes: Change Log: Add (commented) line for VGA blob adding (CBFS version) to simplify things for users a bit. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Configuration of via:epia-m700 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4352&device=epia-m700&vend… If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

DSDT Extraction
by Morgan Reed 08 Jun '09

08 Jun '09

Hi all, As an aside to my earlier question, I'm currently looking at the Advanced ACPI stuff (i.e. pulling in the DSDT from the original BIOS). I've extracted the DSDT using the instructions from the wiki, i.e. cat /proc/acpi/dsdt > dsdt; iasl -d dsdt; iasl -tc dsdt.dsl; Initially there are a few errors thrown by the compiler which I had to fix. Now, when I replace coreboot-v2/src/mainboard/via/epia-m/dsdt.c with it I get linker errors (section <section> [<fromaddr>-<toaddr>] overlaps section <section> [<fromaddr>-<toaddr>]), I expect this is to do with the DSDT from coreboot being ~1kB and the one from the dump being ~12kB. Anybody have any suggestions? Oh and a side note, with regards to the DSDT stuff, I believe we can get around the Intellectual Property issues involved in shipping a "real" DSDT (rather than the default minimalist version) if we have one person disassemble the DSDT from the BIOS in question, write a spec and then give it to somebody else to implement in ASL (Chinese walls) though I'm unsure of the practicalities/logistics involved in doing this (That and IANAL). Thanks, Morgan

2 2

[v2] r4352 - trunk/coreboot-v2/targets/kontron/986lcd-m
by svn＠coreboot.org 08 Jun '09

08 Jun '09

Author: uwe Date: 2009-06-08 15:05:47 +0200 (Mon, 08 Jun 2009) New Revision: 4352 Modified: trunk/coreboot-v2/targets/kontron/986lcd-m/Config.lb Log: Add (commented) line for VGA blob adding (CBFS version) to simplify things for users a bit. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/coreboot-v2/targets/kontron/986lcd-m/Config.lb =================================================================== --- trunk/coreboot-v2/targets/kontron/986lcd-m/Config.lb 2009-06-08 03:33:57 UTC (rev 4351) +++ trunk/coreboot-v2/targets/kontron/986lcd-m/Config.lb 2009-06-08 13:05:47 UTC (rev 4352) @@ -11,3 +11,8 @@ end buildrom ./coreboot.rom ROM_SIZE "fallback" + +# Uncomment this and fix the path to your VGA BIOS blob (~/amipci_01.20 here) for on-board VGA support. +# See http://www.coreboot.org/Kontron_986LCD-M_mITX for details. +# pci_rom ~/amipci_01.20 vendor_id=0x8086 device_id=0x27a2 +

1 0

← Newer
1
...
34
35
36
37
38
39
40
...
50
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 June 2009