coreboot January 2011

coreboot@coreboot.org

65 participants
299 discussions

[commit] r6298 - trunk/payloads/external/SeaBIOS
by repository service 25 Jan '11

25 Jan '11

Author: stepan Date: Tue Jan 25 20:27:23 2011 New Revision: 6298 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6298 Log: Fix abuild thanks to Kevin who came up with this Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Acked-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Modified: trunk/payloads/external/SeaBIOS/Makefile.inc Modified: trunk/payloads/external/SeaBIOS/Makefile.inc ============================================================================== --- trunk/payloads/external/SeaBIOS/Makefile.inc Tue Jan 25 07:06:58 2011 (r6297) +++ trunk/payloads/external/SeaBIOS/Makefile.inc Tue Jan 25 20:27:23 2011 (r6298) @@ -1,6 +1,6 @@ -TAG-$(CONFIG_SEABIOS_MASTER)=master +TAG-$(CONFIG_SEABIOS_MASTER)=origin/master TAG-$(CONFIG_SEABIOS_STABLE)=rel-0.6.1.3 all: seabios @@ -18,9 +18,9 @@ checkout: echo "Checking out SeaBIOS $(TAG-y)" - test -d seabios && ( cd seabios; git pull ) || \ + test -d seabios && ( cd seabios; git fetch ) || \ git clone git://git.linuxtogo.org/home/kevin/seabios.git seabios - cd seabios; git checkout $(TAG-y) + cd seabios; git checkout -m $(TAG-y) clean: test -d seabios && (cd seabios; $(MAKE) CC="$(CC)" LD="$(LD)" clean) || exit 0

2 1

[PATCH]Make LPT ports configurable on various i945/ich7 boards
by Georgi, Patrick 25 Jan '11

25 Jan '11

Hi, attached patch adds a new CMOS variable which triggers activation of the LPT port. With the CMOS variable set, LPT is found by SeaBIOS, with the variable reset, it's not. There's probably a better place for the code to end up in, but this has to do for now. Signed-off-by: Patrick Georgi <patrick.georgi(a)secunet.com>

2 1

[RFC]Hash based CMOS addressing scheme
by Patrick Georgi 25 Jan '11

25 Jan '11

Hi, been thinking about our use of CMOS for configuration lately, and finally came up with a scheme that might just work out. Currently, the CMOS layout is defined per-board making it cumbersome to add new fields for chipset drivers (you have to update all boards that use the component and CMOS, or suffer build errors). So, my scheme works like this: Define a family of up to 2^16 hash functions where each takes a string and calculates a number between 128 and 1023. The functions can be enumerated by a 16 bit number. On build time, look for a hash function which calculates addresses from each CMOS option name, so that the values do not overlap. Store this number in the coreboot binary, and precalculate the addresses of the options (they won't be neatly laid out as they tend to be now). How does that help us? First, we don't need to manually layout the CMOS memory space anymore, which means, we can build partial cmos.layout files for components, which are then concatenated. This should help with CMOS adoption in drivers. Second, updates become possible: If we store the number of the hash function in CMOS (16 bit well spent - let's call it 'salt') at a well known location, we can do in-place updates. We have to get through romstage somehow (which we can ensure by extending the get_option API a bit), at ramstage, coreboot can run an algorithm like: - check salt number in CMOS with salt number used in the build - if the same, check checksum, go on with boot. - if not the same: - for each cmos option do: - calculate the address with the old salt, read the value into RAM - for each cmos option do: - write to CMOS with the new addresses (as stored in coreboot binary or calculated with the new salt) - reboot (so romstage can pick up the CMOS values properly) The hash function should be a "perfect hash" (akin to gperf), in that it provides collision free values for a known set of inputs (where "collision free" also includes address ranges, not just output numbers). It can be computationally expensive at runtime, as it is not commonly used - usually, the precomputed values in the binary can be used. It can be computationally expensive at build time, as CMOS layout doesn't change _that_ often (or we could use some form of caching) The hard part will be to find such a hash function. The good thing is that it doesn't have to be a cryptographically strong hash function, a "normal" hash function is good enough. Opinions? Patrick

1 0

[PATCH] Use a tag for SeaBIOS stable checkouts.
by Kevin O'Connor 25 Jan '11

25 Jan '11

Use a tag (rel-0.6.1.3) for SeaBIOS stable checkouts instead of the stable branch. The tag is a little safer because it prevents an incorrect commit to the stable branch from being immiediately picked up by coreboot users. Note - rel-0.6.1.3 (and 0.6.1-stable) now have the CFLAGS build fix that was causing build failures for coreboot users. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- payloads/external/SeaBIOS/Makefile.inc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/payloads/external/SeaBIOS/Makefile.inc b/payloads/external/SeaBIOS/Makefile.inc index 120e796..faca57e 100644 --- a/payloads/external/SeaBIOS/Makefile.inc +++ b/payloads/external/SeaBIOS/Makefile.inc @@ -1,7 +1,7 @@ TAG-$(CONFIG_SEABIOS_MASTER)=master -TAG-$(CONFIG_SEABIOS_STABLE)=0.6.1-stable +TAG-$(CONFIG_SEABIOS_STABLE)=rel-0.6.1.3 all: seabios -- 1.7.3.4

3 10

[commit] r6297 - trunk/src/southbridge/amd/sb800
by repository service 25 Jan '11

25 Jan '11

Author: zbao Date: Tue Jan 25 07:06:58 2011 New Revision: 6297 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6297 Log: Set the SB800 SATA PHY correctly. Signed-off-by: Zheng Bao <zheng.bao(a)amd.com> Acked-by: Zheng Bao <zheng.bao(a)amd.com> Modified: trunk/src/southbridge/amd/sb800/sata.c Modified: trunk/src/southbridge/amd/sb800/sata.c ============================================================================== --- trunk/src/southbridge/amd/sb800/sata.c Mon Jan 24 22:27:22 2011 (r6296) +++ trunk/src/southbridge/amd/sb800/sata.c Tue Jan 25 07:06:58 2011 (r6297) @@ -53,6 +53,15 @@ return 0; } +static const u32 sata_phy[][3] = { + {0x0056A607, 0x00061400, 0x00061302}, /* port 0 */ + {0x0056A607, 0x00061400, 0x00061302}, /* port 1 */ + {0x0056A607, 0x00061402, 0x00064300}, /* port 2 */ + {0x0056A607, 0x00061402, 0x00064300}, /* port 3 */ + {0x0056A700, 0x00061502, 0x00064302}, /* port 4 */ + {0x0056A700, 0x00061502, 0x00064302} /* port 5 */ +}; + static void sata_init(struct device *dev) { u8 byte; @@ -139,14 +148,14 @@ pci_write_config8(dev, 0x46, 0x20); /* RPR8.4 */ - /* Port 0 */ + /* Port 0 - 5 */ for (i = 0; i < 6; i++) { pci_write_config16(dev, 0x84, 0x3006 | i << 9); - pci_write_config32(dev, 0x94, 0x0056A700); + pci_write_config32(dev, 0x94, sata_phy[i][0]); /* Gen 3 */ pci_write_config16(dev, 0x84, 0x2006 | i << 9); - pci_write_config32(dev, 0x94, 0x00061400); + pci_write_config32(dev, 0x94, sata_phy[i][1]); /* Gen 2 */ pci_write_config16(dev, 0x84, 0x1006 | i << 9); - pci_write_config32(dev, 0x94, 0x00061302); + pci_write_config32(dev, 0x94, sata_phy[i][2]); /* Gen 1 */ } /* Enable the I/O, MM, BusMaster access for SATA */

2 1

[commit] r6296 - trunk/util/nvramtool
by repository service 24 Jan '11

24 Jan '11

Author: stepan Date: Mon Jan 24 22:27:22 2011 New Revision: 6296 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6296 Log: If the tool has 64bit issues, we need to find and fix them. No papering over them. Signed-off-by: Stefan Reinauer <stepan(a)coreboot.org> Acked-by: Stefan Reinauer <stepan(a)coreboot.org> Modified: trunk/util/nvramtool/Makefile Modified: trunk/util/nvramtool/Makefile ============================================================================== --- trunk/util/nvramtool/Makefile Mon Jan 24 22:07:57 2011 (r6295) +++ trunk/util/nvramtool/Makefile Mon Jan 24 22:27:22 2011 (r6296) @@ -24,7 +24,7 @@ STRIP = strip INSTALL = /usr/bin/install PREFIX = /usr/local -CFLAGS = -O2 -g -Wall -W -m32 +CFLAGS = -O2 -g -Wall -W #CFLAGS = -Os -Wall OBJS = cmos_lowlevel.o cmos_ops.o common.o compute_ip_checksum.o \

1 0

Patch for coreboot_table.c
by Joseph Kellermann 24 Jan '11

24 Jan '11

This patch fixes an 'write_tables: coreboot table didn't fit (f0221)' issue. Signed-off-by: Josef Kellermann <Joseph.Kellermann(a)heitec.de><mailto:Joseph.Kellermann@heitec.de> ********************************************************************************************** IMPORTANT NOTICE / WICHTIGER HINWEIS This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us immediately by email or by telephone and then delete this email and any copies of it. Diese E-Mail koennte vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. HEITEC AG, Werner-von-Siemens-Str. 61, 91052 Erlangen, HRB 7754, RG Fuerth, Vorstandsvorsitzender: Richard Heindl, Vorstand: Harald Preiml, Finanzvorstand: Rene-Oliver Rosner, Aufsichtsratsvorsitzender: Dr. Lorenz M. Raith, WWW: http://www.heitec.de **********************************************************************************************

2 1

[commit] r6295 - trunk/src/arch/x86/boot
by repository service 24 Jan '11

24 Jan '11

Author: stepan Date: Mon Jan 24 22:07:57 2011 New Revision: 6295 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6295 Log: This patch fixes an 'write_tables: coreboot table didn't fit (f0221)' issue. Signed-off-by: Josef Kellermann <Joseph.Kellermann(a)heitec.de> Acked-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Modified: trunk/src/arch/x86/boot/coreboot_table.c Modified: trunk/src/arch/x86/boot/coreboot_table.c ============================================================================== --- trunk/src/arch/x86/boot/coreboot_table.c Mon Jan 24 22:05:53 2011 (r6294) +++ trunk/src/arch/x86/boot/coreboot_table.c Mon Jan 24 22:07:57 2011 (r6295) @@ -547,7 +547,7 @@ if (option_table) { struct lb_record *rec_dest = lb_new_record(head); /* Copy the option config table, it's already a lb_record... */ - memcpy(rec_dest, &option_table, option_table->size); + memcpy(rec_dest, option_table, option_table->size); /* Create cmos checksum entry in coreboot table */ lb_cmos_checksum(head); } else {

1 0

[commit] r6294 - trunk/util/nvramtool
by repository service 24 Jan '11

24 Jan '11

Author: ruik Date: Mon Jan 24 22:05:53 2011 New Revision: 6294 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6294 Log: Add CFLAGS when compiling resulting executable. It broke 64bit systems, because the rest uses -m32 now. Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz> Acked-by: Rudolf Marek <r.marek(a)assembler.cz> Modified: trunk/util/nvramtool/Makefile Modified: trunk/util/nvramtool/Makefile ============================================================================== --- trunk/util/nvramtool/Makefile Mon Jan 24 08:50:07 2011 (r6293) +++ trunk/util/nvramtool/Makefile Mon Jan 24 22:05:53 2011 (r6294) @@ -39,7 +39,7 @@ all: dep $(PROGRAM) $(PROGRAM): $(OBJS) - $(CC) -o $(PROGRAM) $(OBJS) $(LDFLAGS) + $(CC) -o $(PROGRAM) $(OBJS) $(LDFLAGS) $(CFLAGS) $(STRIP) $(STRIP_ARGS) $(PROGRAM) clean:

1 0

Some questions about Intel 815EG GMCH
by ali hagigat 24 Jan '11

24 Jan '11

I wonder if you can introduce some active forums or mailing lists to discuss Intel chips in details technically except the Intel forums because they are virtually inactive and no question is answered i have tried it out before. I have questions about Intel 82815EG north bridge(it is connected to Pentium III). It has a display cache interface and up to 4 MB memory can be plugged into its AGP port. I wonder if anybody knows how can i map this 4 mega bytes memory above my main RAM physical memory because I want to see and check the content of that local memory. Also the manual of the chip talks about 32/64MB memory(and also another 512K) configurable by some config registers. The display cache memory can be configured to reside inside this 64 MB? What is this 64M, is it the display cache virtually or it is a different memory? Also the manual says: "GMCH does not support VGA on local memory" What does it mean?

1 0

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