coreboot January 2008

coreboot@coreboot.org

79 participants
347 discussions

r3065 build service
by coreboot information 20 Jan '08

20 Jan '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "stepan" checked in revision 3065 to the coreboot source repository and caused the following changes: Change Log: give it 2k more space for abuild. let's look into this anyways, but get rid of the impression that the cheetah on fam10 is broken just because we're using a too new compiler for abuild. (trivial) Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3065&device=serengeti_che… 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

2 1

r3066 - trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10
by svn＠coreboot.org 20 Jan '08

20 Jan '08

Author: stepan Date: 2008-01-20 02:59:43 +0100 (Sun, 20 Jan 2008) New Revision: 3066 Modified: trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb Log: last try i hope. Building with a payload changes the result of the rom image. Even if the rom image size is not changed, it can make the linking fail. It's almost a heisen-bug, only there if you don't watch. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb =================================================================== --- trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb 2008-01-20 00:24:23 UTC (rev 3065) +++ trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb 2008-01-20 01:59:43 UTC (rev 3066) @@ -13,7 +13,7 @@ romimage "fallback" option USE_FALLBACK_IMAGE=1 - option ROM_IMAGE_SIZE=0x20800 + option ROM_IMAGE_SIZE=0x21000 option COREBOOT_EXTRA_VERSION=".0-fallback" payload __PAYLOAD__ end

1 0

r3065 - trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10
by svn＠coreboot.org 20 Jan '08

20 Jan '08

Author: stepan Date: 2008-01-20 01:24:23 +0100 (Sun, 20 Jan 2008) New Revision: 3065 Modified: trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb Log: give it 2k more space for abuild. let's look into this anyways, but get rid of the impression that the cheetah on fam10 is broken just because we're using a too new compiler for abuild. (trivial) Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb =================================================================== --- trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb 2008-01-19 09:43:48 UTC (rev 3064) +++ trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb 2008-01-20 00:24:23 UTC (rev 3065) @@ -13,7 +13,7 @@ romimage "fallback" option USE_FALLBACK_IMAGE=1 - option ROM_IMAGE_SIZE=0x20000 + option ROM_IMAGE_SIZE=0x20800 option COREBOOT_EXTRA_VERSION=".0-fallback" payload __PAYLOAD__ end @@ -26,4 +26,4 @@ option COREBOOT_EXTRA_VERSION=".0-failover" end -buildrom ./coreboot.rom ROM_SIZE "fallback" "failover" \ No newline at end of file +buildrom ./coreboot.rom ROM_SIZE "fallback" "failover"

1 0

[PATCH] filo: 'make clean' fixes
by Uwe Hermann 19 Jan '08

19 Jan '08

See patch. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

2 2

r42 - trunk/filo-0.5
by svn＠openbios.org 19 Jan '08

19 Jan '08

Author: uwe Date: 2008-01-19 22:08:06 +0100 (Sat, 19 Jan 2008) New Revision: 42 Modified: trunk/filo-0.5/Makefile Log: Properly cleanup null.o and builtin.o upon 'make clean'. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/filo-0.5/Makefile =================================================================== --- trunk/filo-0.5/Makefile 2008-01-16 14:40:04 UTC (rev 41) +++ trunk/filo-0.5/Makefile 2008-01-19 21:08:06 UTC (rev 42) @@ -60,7 +60,7 @@ +$(MAKE) -C $(patsubst _clean_%,%,$@) clean clean: $(SUBDIRS_CLEAN) - rm -f filo.elf filo config.h filo.iso + rm -f filo.elf filo config.h filo.iso null.o builtin.o distclean: clean rm -f Config Config.bak include/arch

1 0

r3064 build service
by coreboot information 19 Jan '08

19 Jan '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "uwe" checked in revision 3064 to the coreboot source repository and caused the following changes: Change Log: Add Bingxun Shi <bingxunshi(a)gmail.com> to the list of contributors (trivial). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3064&device=serengeti_che… 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

2 1

pci_check_sanity is confusing; do we need VSA to read LX CS5536 config registers? ; how to handle VSA?
by ron minnich 19 Jan '08

19 Jan '08

pci_sanity_check is confusing. It looks like this: static int pci_sanity_check(const struct pci_bus_operations *o) { u16 class, vendor; unsigned bus; int devfn; struct bus pbus; /* Dummy device */ #define PCI_CLASS_BRIDGE_HOST 0x0600 #define PCI_CLASS_DISPLAY_VGA 0x0300 #define PCI_VENDOR_ID_COMPAQ 0x0e11 #define PCI_VENDOR_ID_INTEL 0x8086 #define PCI_VENDOR_ID_MOTOROLA 0x1057 for (bus = 0, devfn = 0; devfn < 0x100; devfn++) { class = o->read16(&pbus, bus, devfn, PCI_CLASS_DEVICE); vendor = o->read16(&pbus, bus, devfn, PCI_VENDOR_ID); printk(BIOS_SPEW, "%s: read @ devfn %04x class %04x vendor %04x\n", __FUNCTION__, devfn, class, vendor); if (((class == PCI_CLASS_BRIDGE_HOST) || (class == PCI_CLASS_DISPLAY_VGA)) || ((vendor == PCI_VENDOR_ID_INTEL) || (vendor == PCI_VENDOR_ID_COMPAQ) || (vendor == PCI_VENDOR_ID_MOTOROLA))) { return 1; } } printk(BIOS_ERR, "PCI: Sanity check failed\n"); return 0; } So, why does finding an intel or moto or whatever mean it is sane? What if you have no intel or moto? Or Bridge or VGA? In the lspci from the alix1c, under standard bios, however, there is a host bridge at 0:1.0. But under current v3, which does not run VSA, a config read of 0:1.0 returns an 0xffff for all config registers. Anyway, I added this: if (((class == PCI_CLASS_BRIDGE_HOST) || (class == PCI_CLASS_DISPLAY_VGA)) || ((vendor == PCI_VENDOR_ID_INTEL) || (vendor == PCI_VENDOR_ID_COMPAQ) || (vendor == PCI_VENDOR_ID_AMD) || <<<<<<---------------------------------------------------------- (vendor == PCI_VENDOR_ID_MOTOROLA))) { return 1; } I.e. check AMD too. Now it returns, but still, this is really weird: devfn 00 (the north) returns 0xffff for the vendor and class. In fact the first devfn that gets any AMD vendor id is devfn 0x78! I thought that even without VSA, a pci config read of 0:1.0 would give me something reasonable back. But the devices that are found without VSA are 0:c.0, 0:d.0, and then 0:f.0 etc. 0:1.0 and 0:1.2 are not seen with pci config reads ... Marc is this for real? I need VSA to do a config read of the geode companion? Inquiring minds want to know, but I think they're going to sleep first. I am wondering for VSA if we should not have a post-ram step where we find all LAR entries with names like prestage2/* and run them. Still not sure of the right approach for VSA. Is VSA so special that we shouldn't worry about handling it in the general case? thanks ron

5 5

corebootV3??
by joe＠smittys.pointclark.net 19 Jan '08

19 Jan '08

So, With the name change what is LinuxBIOSv3 going to be? coreboot v1? coreboot v3? Thanks - Joe

3 3

svn: switching subversion from LinuxBIOS to coreboot
by Carl-Daniel Hailfinger 19 Jan '08

19 Jan '08

As you may have noticed, svn up doesn't work anymore for old trees. svn switch (with or without --relocate) will fail with an error. You are stuck. But you wanted to keep that tree. Desparation fills your mind. And then you google for help and all you see is "subversion can't do such a switch". Before you trash your trees and bang your head against the wall: Use my trick to beat svn into cooperation. Sit back and relax. Enter a v3 tree. Type the two commands below and be happy. svn switch svn://linuxbios.org/repository/coreboot-v3 . svn switch --relocate svn://linuxbios.org/repository/coreboot-v3 svn://coreboot.org/repository/coreboot-v3 . Enter a v2 tree. Type the two commands below and be happy. svn switch svn://linuxbios.org/repos/trunk/coreboot-v2 . svn switch --relocate svn://linuxbios.org/repos/trunk/coreboot-v2 svn://coreboot.org/repos/trunk/coreboot-v2 . That's it. Have fun! Regards, Carl-Daniel

6 12

r3063 build service
by coreboot information 19 Jan '08

19 Jan '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "uwe" checked in revision 3063 to the coreboot source repository and caused the following changes: Change Log: Small superiotool fix to detect more Winbond W83627EHF chips. The patch is tested on actual hardware. As per datasheet the ID should be 0x886? for those chips. Not mentioned in the datasheet, but sensors-detect says 0x8853 is also possible. Also, the ASUS A8V-E Deluxe (W83627EHF) has an ID of 0x8854 (verified on actual hardware). So assume all 0x88?? IDs to mean W83627EHF/EF/EHG/EG. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3063&device=serengeti_che… 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

← Newer
1
...
12
13
14
15
16
17
18
...
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