June 2009 - coreboot - mail.coreboot.org

[PATCH] s2895 fix
by Myles Watson June 11, 2009

June 11, 2009

Call real_main if there is a failover image and this is not it. Without this patch normal and fallback just hang... Nice. This is nearly trivial, but since I broke it and it's already been "fixed" once... Boot tested with a failover image. Most of the time I don't use failover, which is why I didn't find the problem sooner. Signed-off-by: Myles Watson <mylesgw(a)gmail.com> Thanks, Myles

2 2

[v2] r4355 - trunk/coreboot-v2/src/mainboard/tyan/s2895
by svn＠coreboot.org June 11, 2009

June 11, 2009

Author: myles Date: 2009-06-11 20:27:41 +0200 (Thu, 11 Jun 2009) New Revision: 4355 Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c Log: Fix s2895 failover booting. Abuild tested and boot tested on s2895 and serengeti_cheetah. Signed-off-by: Myles Watson <mylesgw(a)gmail.com> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c =================================================================== --- trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c 2009-06-09 15:22:47 UTC (rev 4354) +++ trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c 2009-06-11 18:27:41 UTC (rev 4355) @@ -214,6 +214,8 @@ #if HAVE_FAILOVER_BOOT==1 #if USE_FAILOVER_IMAGE==1 failover_process(bist, cpu_init_detectedx); + #else + real_main(bist, cpu_init_detectedx); #endif #else #if USE_FALLBACK_IMAGE == 1

1 0

Hosed ms-7032, I foolishly flashed the bios with a .700
by Phil Neary June 11, 2009

June 11, 2009

Hi all, I'm not really sure how this works, I'm guessing its a bit similar to a forum, but in lieu of creating threads and posting posts, you email instead? Okay the reason for this communication, is I messed up when flashing my bios and flashed it with A7032VMS.700 instead of a .rom or a .bin. I think MSI's flash utility changes the .700 into something usable before it actually flashes the bios to the chip, but their instructions were heavily Windows based and I totally forgot that .EXE's are also for Dos and not just Windows. When it first happened, I tried the AMIBOOT.ROM recovery with the .700 and a few other bios' for my board that I downloaded from MSI, but they haven't worked. I thought it may be down to the fact that they're not .bin's or .rom's. So I recently fixed a friends PC and he has Sata drives so I was able to get the backup.bin from my hard drive and tried renaming it AMIBOOT.ROM and saving it to floppy, but Fedora named it amiboot.rom and I couldn't rename it. I'm not sure if this makes a difference, but it didn't work anyhow. Does Amiboot have to be capitalized? I'm guessing it looks as though the recovery feature isn't going to work? Is there anything I haven't tried yet? I can get a replacement chip for a fiver, but before I do I'd like to find out if that will defiantly work? Or could there be a small chance that a new chip even with the correct bios wouldn't work? I haven't done anything but try the recovery method, so nothing should be damaged. Thank you for reading. Kind regards Phil

2 1

Re: [coreboot] [v3] r1170 - coreboot-v3/util/x86emu
by René Reuter June 10, 2009

June 10, 2009

This fix is breaking v2 when running it with emulation mainboard qemu-x86: Output Log: CBFS: Could not find file pci1013,00b8.rom In cbfs, rom address for PCI: 00:02.0 = 00000000 On mainboard, rom address for PCI: 00:02.0 = c0000 copying VGA ROM Image from 000c0000 to 0xc0000, 0x8c00 bytes Calling Option Rom... oprom: INT# 0x0 oprom: eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c oprom: ebp: 00013f50 esp: 00000ffa edi: 0000ea44 esi: 0001444c oprom: ip: 0556 cs: 0000 flags: 00000246 Oops, exception 0 while executing option rom Unexpected Exception: 0 @ 00:00000556 - Halting Code: 0 eflags: 00000246 eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c edi: 0000ea44 esi: 0001444c ebp: 00013f50 esp: 00000ffa And here it keeps holding. With older revisions v2 works fine. Regards, René 2009/5/29 <svn(a)coreboot.org> > Author: linux_junkie > Date: 2009-05-29 20:42:23 +0200 (Fri, 29 May 2009) > New Revision: 1170 > > Modified: > coreboot-v3/util/x86emu/Config.lb > coreboot-v3/util/x86emu/Makefile > Log: > rename the option CONFIG_PCI_OPTION_ROM_RUN_VM86 to > CONFIG_PCI_OPTION_ROM_RUN_REALMODE. > Signed-off-by: Joseph Smith <joe(a)settoplinux.org> > Acked-by: Stefan Reinauer <stepan(a)coresystems.de> > > Modified: coreboot-v3/util/x86emu/Config.lb > =================================================================== > --- coreboot-v3/util/x86emu/Config.lb 2009-05-29 17:38:46 UTC (rev 1169) > +++ coreboot-v3/util/x86emu/Config.lb 2009-05-29 18:42:23 UTC (rev 1170) > @@ -1,11 +1,11 @@ > uses CONFIG_PCI_OPTION_ROM_RUN_YABEL > -uses CONFIG_PCI_OPTION_ROM_RUN_VM86 > +uses CONFIG_PCI_OPTION_ROM_RUN_REALMODE > > if CONFIG_PCI_OPTION_ROM_RUN_YABEL > dir yabel > dir x86emu > else > - if CONFIG_PCI_OPTION_ROM_RUN_VM86 > + if CONFIG_PCI_OPTION_ROM_RUN_REALMODE > object x86.o > object x86_interrupts.o > object x86_asm.S > > Modified: coreboot-v3/util/x86emu/Makefile > =================================================================== > --- coreboot-v3/util/x86emu/Makefile 2009-05-29 17:38:46 UTC (rev 1169) > +++ coreboot-v3/util/x86emu/Makefile 2009-05-29 18:42:23 UTC (rev 1170) > @@ -37,7 +37,7 @@ > #TODO: remove these, these are .h files from slof, to make the merge > easier... > X86EMU_INCLUDE += -I $(src)/util/x86emu/yabel/compat > endif > -VM86_SRC = x86.c x86_asm.S > +REALMODE_SRC = x86.c x86_asm.S > > ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_X86EMU),y) > LIBX86EMU_SRC=$(patsubst %,x86emu/%,$(X86EMU_SRC)) $(BIOSEMU_SRC) > @@ -47,8 +47,8 @@ > LIBX86EMU_SRC=$(patsubst %,x86emu/%,$(X86EMU_SRC)) $(patsubst > %,yabel/%,$(BIOSEMU_SRC)) > endif > > -ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_VM86),y) > -LIBX86EMU_SRC=$(VM86_SRC) > +ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_REALMODE),y) > +LIBX86EMU_SRC=$(REALMODE_SRC) > endif > > LIBX86EMU_OBJS = $(patsubst %.c,$(obj)/util/x86emu/%.o,$(LIBX86EMU_SRC)) > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

5 18

Is this boar/chipset combination supported?
by saueimer June 9, 2009

June 9, 2009

Hi there, i read the "Will coreboot work on my machine?"-FAQ. Unfortunately I don't own my desired board and chipset yet, but I would like to know if this combination is supported, so i tried to collect some infromation: Board: Jetway JNC62K SocketAM2/AM2+ Mini-ITX (link to the homepage: http://www.jetwaycomputer.com/AMD3.html and as attachment the datasheet) Chipset:cpu AMD AM2 5050X2 Processor AMD Athlon™ X2 Dual-Core Model 5050e OPN Tray ADH5050IAA5DO OPN PIB ADH5050IADOBOX Operating Mode 32 Bit Yes Operating Mode 64 Bit Yes Revision G2 Core Speed (MHz) 2600 Voltages 1.0-1.25V Max Temps (C) 78'C Wattage 45 W L1 Cache Size (KB) 128 L1 Cache Count 2 L2 Cache Size (KB) 512 L2 Cache Count 2 L3 Cache Size (KB) CMOS 65nm SOI Socket AM2 AMD Business Class No Black Edition No Kind regards and thanks for any information!

4 6

Raminit help
by Myles Watson June 9, 2009

June 9, 2009

I've yanked all of the sdram initialization from my s2895 so that I can use my HT device as RAM. I've set up the BARs in the device and in the Opteron so that I should have access to 0-2GB. It hangs here: testx = 5a5a5a5a Copying data from cache to RAM -- switching to use RAM as stack... Somehow the memory accesses aren't reaching my device. I added some debugging, and this line before the debugging: set_var_mtrr(0, 0x08000000, 0x10000000, MTRR_TYPE_WRBACK); Here's the output: xd1000_ram_init: ram_dev=4000000 id=554e1172 xd1000_BARs xd1000_ram_init: testing "RAM" val = ffffffff After loop p=10180020 *p=ffffffff val(@0x08180020)=8189920 *p(08180020) = 8189920 *p(08980020) = ffffffff *p(09180020) = ffffffff *p(09980020) = ffffffff *p(0a180020) = ffffffff *p(0a980020) = ffffffff *p(0b180020) = ffffffff *p(0b980020) = ffffffff *p(0c180020) = ffffffff *p(0c980020) = ffffffff *p(0d180020) = ffffffff *p(0d980020) = ffffffff *p(0e180020) = ffffffff *p(0e980020) = ffffffff *p(0f180020) = ffffffff *p(0f980020) = ffffffff v_esp=000cffe8 It looks like one value sticks but not the rest. Here's the debugging code: printk_debug("%s: testing \"RAM\"", __func__); // Try to force the values out of the cache. *((volatile u32 *)0x08180000) = 0x5a5a5a50; *((volatile u32 *)0x08180008) = 0x5a5a5a51; *((volatile u32 *)0x08180010) = 0x5a5a5a52; *((volatile u32 *)0x08180018) = 0x5a5a5a53; *((volatile u32 *)0x08180020) = 0x5a5a5a54; *((volatile u32 *)0x08180028) = 0x5a5a5a55; *((volatile u32 *)0x08180030) = 0x5a5a5a56; *((volatile u32 *)0x08180038) = 0x5a5a5a57; *((volatile u32 *)0x08180040) = 0x5a5a5a58; *((volatile u32 *)0x09180020) = 0x5a5a5a59; *((volatile u32 *)0x0A180020) = 0x5a5a5a5a; *((volatile u32 *)0x0B180020) = 0x5a5a5a5b; *((volatile u32 *)0x0C180020) = 0x5a5a5a5c; *((volatile u32 *)0x0D180020) = 0x5a5a5a5d; *((volatile u32 *)0x0E180020) = 0x5a5a5a5e; *((volatile u32 *)0x0F180020) = 0x5a5a5a5f; // Check value. val = *((volatile u32 *) 0x08180020); printk_debug(" val = %x\n", val); // Write to various locations. for (p = (volatile u32 *) 0x08180020; p < ((volatile u32 *) 0x10000000); p+=0x200000) *p = (u32) p + 0x00009900; val = *((volatile u32 *) 0x08180020); printk_debug("After loop p=%p *p=%x val(@0x08180020)=%x\n", p, *p, val); //Read them back for (p = (volatile u32 *) 0x08180020; p < ((volatile u32 *) 0x10000000); p+=0x200000) { val = *p; printk_debug(" *p(%p) = %lx\n", p, val); } So I'm going through all the code I disabled trying to figure out what else the Opteron needs to send memory references onto the bus. Any suggestions? Thanks, Myles

4 6

VIA VT8235 + SST39SF020A problem
by Murawski Mateusz June 9, 2009

June 9, 2009

Hi I have Albatron PM266A PRO motherboard (VIA P4M266A/8235 + SST39SF020A) http://www.albatron.com.tw/English/product/mb/pro_detail.asp?rlink=Specific… http://www.sst.com/downloads/datasheet/S71147.pdf Flashrom rev 580 can't detect flash chip. SST39SF020A is marked as OK_PREW http://coreboot.pastebin.com/m779fa4b8

4 5

[flashrom] r581 - trunk
by svn＠coreboot.org June 9, 2009

June 9, 2009

Author: libv Date: 2009-06-09 20:29:30 +0200 (Tue, 09 Jun 2009) New Revision: 581 Modified: trunk/board_enable.c Log: Add board enable for Albatron PM266A boards. There are multiple albatron pm266a boards which all share the same bios image. This means that both the board enable and the subsystem ids are exactly the same. The board enable is the same as the epox EP-8K5A2, namely only raising memw on the superio. Signed-off-by: Luc Verhaegen <libv(a)skynet.be> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Mateusz Murawski <matowy(a)tlen.pl> Modified: trunk/board_enable.c =================================================================== --- trunk/board_enable.c 2009-06-05 20:53:07 UTC (rev 580) +++ trunk/board_enable.c 2009-06-09 18:29:30 UTC (rev 581) @@ -270,7 +270,7 @@ } /** - * Suited for EPoX EP-8K5A2. + * Suited for EPoX EP-8K5A2 and Albatron PM266A. */ static int board_epox_ep_8k5a2(const char *name) { @@ -685,6 +685,7 @@ /* first pci-id set [4], second pci-id set [4], coreboot id [2], vendor name board name flash enable */ {0x8086, 0x1130, 0, 0, 0x105a, 0x0d30, 0x105a, 0x4d33, "acorp", "6a815epd", "Acorp", "6A815EPD", board_acorp_6a815epd}, {0x1022, 0x746B, 0x1022, 0x36C0, 0, 0, 0, 0, "AGAMI", "ARUMA", "agami", "Aruma", w83627hf_gpio24_raise_2e}, + {0x1106, 0x3177, 0x17F2, 0x3177, 0x1106, 0x3148, 0x17F2, 0x3148, NULL, NULL, "Albatron", "PM266A", board_epox_ep_8k5a2}, {0x1022, 0x2090, 0, 0, 0x1022, 0x2080, 0, 0, "artecgroup", "dbe61", "Artec Group", "DBE61", board_artecgroup_dbe6x}, {0x1022, 0x2090, 0, 0, 0x1022, 0x2080, 0, 0, "artecgroup", "dbe62", "Artec Group", "DBE62", board_artecgroup_dbe6x}, {0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118, NULL, NULL, "ASUS", "A7V8-MX SE", board_asus_a7v8x_mx},

1 0

[RFC] Adding struct flashchip * to all chip functions
by Carl-Daniel Hailfinger June 9, 2009

June 9, 2009

Short summary: We need to add struct flashchip * to all chip functions to avoid a big mess once we support multiprotocol capable external programmers. Flashrom has really nice generic routines like probe_jedec. They work perfectly as long as flashrom does not have to care about the bus protocol it should use to talk to the chip. Even current external flashers (nic3com, satasii) work fine because flashrom does not have to care about the bus protocol there either. However, any external flasher supporting multiple bus protocols (and such flashers are being worked on) really wants to know which protocol to use. Unfortunately, chip_read* and chip_write* don't know about the bus protocol. Adding struct flashchip * as parameter to chip_read* and chip_write* would solve the issue quite nicely and improve our abstraction at the same time. Of course, this means every function calling chip_read* and chip_write* has to pass struct flashchip * to them. Ergo, we need struct flashchip * as parameter in the whole call chain. An alternative would be using global variables for current flash chip properties, but that is madness during probe where we want to check for multiple chips. Opinions? Thoughts? Want explanations? Tell me! Regards, Carl-Daniel -- http://www.hailfinger.org/

3 4

build service results for r4354
by coreboot information June 9, 2009

June 9, 2009

Dear coreboot readers! This is the automatic build system of coreboot. The developer "stepan" checked in revision 4354 to the coreboot repository. This caused the following changes: Change 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> Build Log: Configuration of via:epia-m700 has been fixed If something broke during this checkin please be a pain in stepan'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