coreboot January 2008

coreboot@coreboot.org

79 participants
347 discussions

[LinuxBIOS] [PATCH] v3: add a check for a termination member
by Carl-Daniel Hailfinger 23 Jan '08

23 Jan '08

Check for a terminating LAR member which tells us that no further LAR member except the bootblock will be found after this member. The LAR member has a normal MAGIC, but all other parts of struct lar_header are 0xff. That way, adding a new member in place of the terminating member will not need an erase cycle. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: LinuxBIOSv3-larplaceholder/lib/lar.c =================================================================== --- LinuxBIOSv3-larplaceholder/lib/lar.c (Revision 546) +++ LinuxBIOSv3-larplaceholder/lib/lar.c (Arbeitskopie) @@ -58,7 +58,7 @@ int find_file(const struct mem_file *archive, const char *filename, struct mem_file *result) { - char *walk, *fullname; + char *walk, *fullname, *tmp; struct lar_header *header; printk(BIOS_INFO, "LAR: Attempting to open '%s'.\n", filename); @@ -105,10 +105,24 @@ for (walk = archive->start; (walk < (char *)(archive->start + archive->len - sizeof(struct lar_header))) && (walk >= (char *)archive->start); walk += 16) { - if (strncmp(walk, MAGIC, 8) != 0) + if (strncmp(walk, MAGIC, sizeof(header->magic)) != 0) continue; header = (struct lar_header *)walk; + /* The loop below deserves an explanation: The final iteration + * of the loop will access the byte after the header. If that + * iteration has been reached, all checked bytes in the header + * were 0xff. This saves one state variable. + */ + for (tmp = walk + sizeof(header->magic); + tmp <= walk + sizeof(*header); tmp++) { + if (*tmp != (char)0xff) + break; + } + if (tmp == walk + sizeof(*header)) { + printk(BIOS_SPEW, "LAR: termination pseudomember reached.\n"); + break; + } fullname = walk + sizeof(struct lar_header); printk(BIOS_SPEW, "LAR: seen member %s\n", fullname);

5 27

progress on lx
by ron minnich 23 Jan '08

23 Jan '08

With the as-yet uncommitted patch I just posted, we're getting much better results. My comments in [[[]]] LinuxBIOS-3.0.0 Fri Jan 18 08:34:27 PST 2008 starting... Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: seen member bootblock LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: CHECK normal/initram/segment0 @ 0xfff9ae20 start 0xfff9ae70 len 5400 reallen 5400 compression 0 entry 0x00000f0b loadaddress 0x00000000 Entry point is 0xfff9bd7b Hi there from stage1 done preinit done gpio init pll_reset: read msr 0x4c000014 _MSR GLCP_SYS_RSTPLL (4c000014) value is: 0000059c:0000182e Configuring PLL Resetting the processor after PLL configuration for the changes to take effect [[[Note the new message ... So we're through pll reset as before. ]]] LinuxBIOS-3.0.0 Fri Jan 18 08:34:27 PST 2008 starting... Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: seen member bootblock LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: CHECK normal/initram/segment0 @ 0xfff9ae20 start 0xfff9ae70 len 5400 reallen 5400 compression 0 entry 0x00000f0b loadaddress 0x00000000 Entry point is 0xfff9bd7b Hi there from stage1 done preinit done gpio init pll_reset: read msr 0x4c000014 _MSR GLCP_SYS_RSTPLL (4c000014) value is: 0000059c:07de002e Done pll_reset done pll reset [[[I'm skipping the DRAM spew .. nothing new]]] [[I'm skipping the LAR walk to stage 2..]]] dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown [[[ Wha'ts this mean? It means the id is not set in the dts. This will be fixed over time ]]] [[[ But it does not always matter. In the dev_init, I should skip devices of type Unkown anyway.]]] find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 find_constructor: find PCI_DOMAIN: 1022:2080 find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: match [[[OK, that was the dev_init code. The key thing here is the 'match' -- we found the constructor for the north bridge and have set the ops for it. As we add pciid properties to the various dts'es, there will be more matches. ]]] Phase 1: Very early setup... Phase 1: done [[[ here comes the good news ...]]] Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 0 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:01.0): enabled 1 have_resources 0 initialized 0 southbridge(PCI: 00:0f.1): enabled 1 have_resources 0 initialized 0 superio: Unknown device path type: 0 superio(): enabled 0 have_resources 0 initialized 0 domain0(PCI_DOMAIN: 0000): enabled 1 have_resources 0 initialized 0 Phase 2: Early setup... dev_phase2: dev root: dev_phase2: ops 0x00007e20 ops->phase2_setup_scan_bus 0x00000000 dev_phase2: dev cpus: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b dev_phase2: dev device0_0: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b dev_phase2: dev southbridge: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b dev_phase2: dev superio: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b dev_phase2: dev domain0: dev_phase2: ops 0x0000a460 ops->phase2_setup_scan_bus 0x00005b5a Calling phase2 phase2_setup_scan_bus...>> Entering northbridge.c: geodelx_pci_domain_phase2 Enter northbridge_init_early writeglmsr: MSR 0x10000020, val 0x20000000:0x000fff80 writeglmsr: MSR 0x10000021, val 0x20000000:0x080fffe0 sizeram: _MSR MC_CF07_DATA: 10076013:00061a40 sizeram: sizem 0x100MB sysmem_init: enable for 256MBytes Usable RAM: 268304383 bytes sysmem_init: MSR 0x10000028, val 0x2000000f:0xfdf00100 sizeram: _MSR MC_CF07_DATA: 10076013:00061a40 sizeram: sizem 0x100MB SMMGL0Init: 268304384 bytes SMMGL0Init: offset is 0x80400000 SMMGL0Init: MSR 0x10000026, val 0x28fbe080:0x400fffe0 writeglmsr: MSR 0x10000080, val 0x00000000:0x00000003 writeglmsr: MSR 0x40000020, val 0x20000000:0x000fff80 writeglmsr: MSR 0x40000021, val 0x20000000:0x080fffe0 sizeram: _MSR MC_CF07_DATA: 10076013:00061a40 sizeram: sizem 0x100MB sysmem_init: enable for 256MBytes Usable RAM: 268304383 bytes sysmem_init: MSR 0x4000002a, val 0x2000000f:0xfdf00100 SMMGL1Init: SMMGL1Init: MSR 0x40000023, val 0x20000080:0x400fffe0 writeglmsr: MSR 0x40000080, val 0x00000000:0x00000001 writeglmsr: MSR 0x400000e3, val 0x60000000:0x033000f0 CPU_RCONF_DEFAULT (1808): 0x25FFFC02:0x10FFDF00 CPU_RCONF_BYPASS (180A): 0x00000000 : 0x00000000 L2 cache enabled GLPCI R1: system msr.lo 0x00100130 msr.hi 0x0ffdf000 GLPCI R2: system msr.lo 0x80400120 msr.hi 0x8041f000 Exit northbridge_init_early [[[ WOO HOO! north bridge setup and memory setup for 256M!]]] [[[ here comes the bad news ]]] chipsetinit: Could not find the south bridge! [[[ damn!]]] Before VSA: After VSA: Finding PCI configuration type. PCI: Sanity check failed pci_check_direct failed [[[ So, Marc, now what :-) ]]] ron

7 23

I just can't believe it
by ron minnich 23 Jan '08

23 Jan '08

brand new shuttle box phoenix-award bios "keyboard error or no keyboard present" "Press F1 to continue" It's just too funny. Imagine a beowulf of these! ron

8 9

Support for MSI K9A2 Platinum
by Joop Boonen 23 Jan '08

23 Jan '08

Dear all, I'd like to know if there are plans to support the MSI K9A2 Platinum main board? I'm looking at this main board as it also supports SAS. Regards, Joop Boonen.

1 0

linuxbios/coreboot summit in denver, CO
by ron minnich 23 Jan '08

23 Jan '08

Don't try to register for the hotel just yet, as we are getting the conf. rate extended to april 6. But if people could start registering it would help us a great deal with arrangements. Also, potential sponsors, please contact me if you can help support this meeting. If you can buy a six-pack of soda, we'll put your logo on it! No amount too small :-) http://www.hpcsw.org/index.shtml Thanks ron

1 0

[LinuxBIOS] [Fwd: Re: AMD 690G chipset support in LinuxBIOS v2]
by Marc Jones 22 Jan '08

22 Jan '08

Meant to send this to the list. Marc -------- Original Message -------- Subject: Re: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 Date: Mon, 10 Sep 2007 21:05:47 -0600 From: Marc Jones <Marc.Jones(a)AMD.com> To: Darmawan Salihun <darmawan.salihun(a)gmail.com> References: <46893e740709101937j32a4f32bu6dc296a628d36dc6(a)mail.gmail.com> Darmawan Salihun wrote: > Hi all, > I've grepped through the source code last night but haven't found > code for board that uses this chipset. Is there any support coming > down the road? I'm planning to buy a new system for BIOS experiments > in the next few days. This chipset is a candidate for me. I want a > chipset with onboard video and K8 processor. > I choose K8 because the datasheet for the memory controller is > readily available. I'm open for any suggestion(s). Basically, I just > want a system that can run Vista, support multicore processor and can > be used for LinuxBIOS experiments (preferably without soldering stuff > needed). > Anyway, one further question: hot-flashing can be done on SPI > chips as well, right? > > > Regards, > > Darmawan Salihun > -------------------------------------------------------------------- > -= Human knowledge belongs to the world =- Hi Darmawan, Currently there is no support in LinuxBIOS for any ATI(now AMD) chipsets. We do plan to work on this in the next six months but I don't have a specific release date. == Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones@amd.com http://www.amd.com/embeddedprocessors Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones@amd.com http://www.amd.com/embeddedprocessors

7 14

FW: PCI BIOS Extension ROM in v3
by Myles Watson 22 Jan '08

22 Jan '08

> On 22.01.2008 18:59, Myles Watson wrote: > > Coreboot v3 refuses to initialize the VGA in QEMU because the PCI device > > ID's are mismatched. > > > > It turns out that the header has been overwritten by a copyright string, > so > > that v3 is following a bad pointer into the ROM looking for the PCI > device > > IDs and not finding it. Coreboot v2 still successfully initializes the > VGA > > because it skips the vendor check. > > > > The question is if we should make the vendor check a warning instead of > > failing. I realize that the right thing to do is fix the ROM, but there > may > > be other broken ROMs as well. > > > > I'd say we refuse to execute the ROM in v3. If the ROM is broken, we > have no way to determine how broken it is. Unconditional execution may > prevent booting the machine, thereby forcing an out-of-system flash of > coreboot with ROM execution disabled. > > How many ROMs of real hardware are broken that way? If their number is > close to zero, printing a scary warning message will be best. If there > is a large number of such broken ROMs, we can make execution dependent > on some NVRAM setting, which will refuse execution after NVRAM clear. I have no idea how many there are. > Do you know which versions of Qemu ship the broken ROM? Is there already > a patch for it? > 0.9.0, 0.9.1 I haven't seen a patch for it, or anyone else complaining about it. It made me wonder if Coreboot is the only thing that cares if the ROM is broken. Myles Carl-Daniel: I forgot to CC the list last time.

1 0

r3073 - in trunk/coreboot-v2: src/config targets
by svn＠coreboot.org 22 Jan '08

22 Jan '08

Author: hailfinger Date: 2008-01-22 17:09:36 +0100 (Tue, 22 Jan 2008) New Revision: 3073 Modified: trunk/coreboot-v2/src/config/Config.lb trunk/coreboot-v2/targets/buildtarget Log: Use "--build-id=none" as linker flags if build-id is supported. That fixes a compilation failure. Signed-off-by: Marc Karasek <marc.karasek(a)sun.com> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Joseph Smith <joe(a)smittys.pointclark.net> Acked-by: Myles Watson <myles(a)pel.cs.byu.edu> Modified: trunk/coreboot-v2/src/config/Config.lb =================================================================== --- trunk/coreboot-v2/src/config/Config.lb 2008-01-22 16:03:19 UTC (rev 3072) +++ trunk/coreboot-v2/src/config/Config.lb 2008-01-22 16:09:36 UTC (rev 3073) @@ -8,7 +8,7 @@ makedefine GCC_INC_DIR := $(shell LC_ALL=C $(CC) -print-search-dirs | sed -ne "s/install: $.*$/\1include/gp") makedefine CPPFLAGS := -I$(TOP)/src/include -I$(TOP)/src/arch/$(ARCH)/include -I$(GCC_INC_DIR) $(CPUFLAGS) -makedefine CFLAGS := $(CPU_OPT) $(CPPFLAGS) -Os -nostdinc -nostdlib -fno-builtin -Wall +makedefine CFLAGS := $(CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -Os -nostdinc -nostdlib -fno-builtin -Wall makedefine HOSTCFLAGS:= -Os -Wall @@ -38,14 +38,15 @@ action "ar cr coreboot.a $(OBJECTS)" end + makerule coreboot_ram.o depends "$(DRIVER) coreboot.a $(LIBGCC_FILE_NAME)" - action "$(CC) -nostdlib -r -o $@ c_start.o $(DRIVER) coreboot.a $(LIBGCC_FILE_NAME)" + action "$(CC) $(DISTRO_LFLAGS) -nostdlib -r -o $@ c_start.o $(DRIVER) coreboot.a $(LIBGCC_FILE_NAME)" end makerule coreboot_ram depends "coreboot_ram.o $(TOP)/src/config/coreboot_ram.ld ldoptions" - action "$(CC) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_ram.ld coreboot_ram.o" + action "$(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_ram.ld coreboot_ram.o" action "$(CROSS_COMPILE)nm -n coreboot_ram | sort > coreboot_ram.map" end @@ -83,12 +84,12 @@ makerule coreboot_apc.o depends "coreboot_apc.a c_start.o $(LIBGCC_FILE_NAME)" - action "$(CC) -nostdlib -r -o $@ c_start.o coreboot_apc.a $(LIBGCC_FILE_NAME)" + action "$(CC) $(DISTRO_LFLAGS) -nostdlib -r -o $@ c_start.o coreboot_apc.a $(LIBGCC_FILE_NAME)" end makerule coreboot_apc depends "coreboot_apc.o $(TOP)/src/config/coreboot_apc.ld ldoptions" - action "$(CC) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_apc.ld coreboot_apc.o" + action "$(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_apc.ld coreboot_apc.o" action "$(CROSS_COMPILE)nm -n coreboot_apc | sort > coreboot_apc.map" end @@ -121,7 +122,7 @@ makerule coreboot depends "crt0.o $(INIT-OBJECTS) $(COREBOOT_APC) $(COREBOOT_RAM_ROM) ldscript.ld" - action "$(CC) -nostdlib -nostartfiles -static -o $@ -T ldscript.ld crt0.o $(INIT-OBJECTS)" + action "$(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@ -T ldscript.ld crt0.o $(INIT-OBJECTS)" action "$(CROSS_COMPILE)nm -n coreboot | sort > coreboot.map" end Modified: trunk/coreboot-v2/targets/buildtarget =================================================================== --- trunk/coreboot-v2/targets/buildtarget 2008-01-22 16:03:19 UTC (rev 3072) +++ trunk/coreboot-v2/targets/buildtarget 2008-01-22 16:09:36 UTC (rev 3073) @@ -69,9 +69,16 @@ rm -rf .$$.tmp +ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END {exit n}' +build_id=$? +if [ $build_id -ge 1 ] ; then + EXTRA_LFLAGS+=" -Wl,--build-id=none" +fi + for i in $build_dir/Makefile.settings $build_dir/*/Makefile.settings do - echo CFLAGS+=$EXTRA_CFLAGS >>$i + echo DISTRO_CFLAGS+=$EXTRA_CFLAGS >>$i + echo DISTRO_LFLAGS+=$EXTRA_LFLAGS >>$i done exit $?

1 0

[LinuxBIOS] Please add support for MX25L8005 and MX25L3205D
by Harald Gutmann 22 Jan '08

22 Jan '08

Hello! As I've soldered a Sockel for SPI-Chips on my Mainboard (Gigabyte M57SLI4), I'd like to test the Chip's which have more space on it, and i've here. I have those chips, and the sockel but not really skills in programming C, i tried to look at the source code from flashrom, but grepping for "MX25L4005" (which already works) gives just two results. One result is in the flashchips.c file, and the second in flash.h, where in flash.h there is an entry for the MX25L8005 chip. I added in flashchips.c a line for the MX25L8005 chip, and flashrom detects it, but i don't know what the values in those lines are exactly for, but just correcting the first one to 1024 gives the right size output after the chip detction, but verifying after writing to the chip doesn't work. (I think there is some more work to do on the flashrom code, or i just have the wrong values insert in the flashchips.h file.) It would be really fine, if someone of you could implement that correctly, i can and will test if it works. Kind regards, Harald Gutmann

3 14

problems using svn co https://coreboot.org/svn/trunk/coreboot-v2
by bxshi 22 Jan '08

22 Jan '08

when I check out the code by : svn co https://coreboot.org/svn/trunk/coreboot-v2 it begin to download, ...... A coreboot-v2/util/resetcf A coreboot-v2/util/resetcf/resetcf.c A coreboot-v2/util/buildrom A coreboot-v2/util/buildrom/buildrom.c U coreboot-v2 Fetching external item into 'coreboot-v2/util/flashrom' svn: Unknown hostname 'linuxbios.org' ----------------------------------------------------------------- and then it stops, but the download is incomplete. what is the problem? Thanks for help. bxshi

2 1

← Newer
1
...
9
10
11
12
13
14
15
...
35
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 2008