David Hendricks (dhendrix(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2862
-gerrit
commit dc6f2a701fae3291ae22043a3219bcd4aec6a793
Author: David Hendricks <dhendrix(a)chromium.org>
Date: Tue Mar 19 17:25:24 2013 -0700
armv7: allow build_lb_mem() to clean up memory ranges
Allow build_lb_mem() to clean up the memory ranges again now that
regions are allocated and we don't die.
This also removes an obsolete FIXME comment in build_lb_mem().
Change-Id: I8bda11915b1f1fe39683c20e8827ddbf53949dc7
Signed-off-by: David Hendricks <dhendrix(a)chromium.org>
---
src/arch/armv7/boot/coreboot_table.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/arch/armv7/boot/coreboot_table.c b/src/arch/armv7/boot/coreboot_table.c
index 47aad36..e2e732d 100644
--- a/src/arch/armv7/boot/coreboot_table.c
+++ b/src/arch/armv7/boot/coreboot_table.c
@@ -547,13 +547,11 @@ static struct lb_memory *build_lb_mem(struct lb_header *head)
mem = lb_memory(head);
mem_ranges = mem;
- /* FIXME: implement this */
/* Build the raw table of memory */
search_global_resources(
IORESOURCE_MEM | IORESOURCE_CACHEABLE, IORESOURCE_MEM | IORESOURCE_CACHEABLE,
build_lb_mem_range, mem);
- /* FIXME: things die in cleanup_memory_ranges(), skip for now */
-// lb_cleanup_memory_ranges(mem);
+ lb_cleanup_memory_ranges(mem);
return mem;
}
Marc Jones wrote:
> Mentoring isn't hard work, but it does take attention every week
..
> The lack of interest is is a bit ironic
Please don't confuse lack of time for lack of interest.
I am sure that quite a lot of people in the coreboot community are
interested in participating in GSoC, but I think it is clear to
everyone that in order to do so we would have to bring significantly
more to the table, and I guess that there simply isn't time for that.
> we have had more contributions to coreboot than ever before.
While that *is* true, the community landscape has also changed quite
drastically over the last few years. There are only very few code
contributors for the majority of the code. Economy of scale is
clearly in play, meaning much less margin all around.
> Honestly, I'm disappointed that we can't identify good projects and
> guidance for new firmware developers.
Most everyone is too busy even to rework their own code, and
coreboot.git is merely a public repository with a bit of
shared infrastructure.
There is next to no interaction in the community, so I'm not at all
surprised that we fail to identify projects and processes. When it
doesn't even work for the community, how could it work for us
bringing another community (students) into ours?
> Without good complete project ideas, applying for GSoC is pointless.
Certainly agreed.
> Please put forward coreboot, flashrom, and payload ideas.
None of the modern platform development in coreboot happens in
the open, so anything related to that is basically not doable.
The only doable coreboot project I can think of is to implement AGESA
for a new mainboard. It took Rudolf a few months to climb the AGESA
learning curve, and at the moment I believe he is the only community
member outside of AMD who has done that.
Doing an AGESA port would be quite educational for a student, but
obviously also immensely challenging, because unlike Rudolf the
student probably does not have years of experience with PC firmware.
A good student would continue to intelligently drive discussion about
how to integrate AGESA and coreboot better, while also keeping an eye
toward keeping AGESA code as pristine as possible in order to
facilitate inclusion of possible later code drops from AMD. (This is
part of the "Move configuration to Kconfig" Infrastructure Project.)
I don't expect qualified applicants. I would love to be proven wrong.
Other than that, there are various uninspiring infrastructure projects:
http://www.coreboot.org/Infrastructure_Projects
Payloads - a way to provide UEFI with Secure Boot support is the only
thing that mainstream industry has any interest in, since that's what
Microsoft requires for certification. David and Patrick were already
working on that, so there's not much for a student project to do..
Other payload ideas include a solution for chaining payloads, so that
coreboot starts one payload, but that payload can in turn start one
other payload after it has finished. This would be a simple
libpayload project. The code for this is already available in
SeaBIOS. A good use case would be for the nvramtool-like utility that
Patrick wrote, allowing a boot-time menu or in fact a more complex
sequence of payloads to be configured into coreboot Kconfig and maybe
built all at once while building coreboot - similar to how SeaBIOS
gets built.
//Peter
Stefan Reinauer (stefan.reinauer(a)coreboot.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2861
-gerrit
commit 7bfe3e9127f56214b9f1c7b3c77bba09849492c0
Author: Aaron Durbin <adurbin(a)chromium.org>
Date: Tue Mar 19 15:25:46 2013 -0500
wtm2: build-time dev and recovery settings
It's helpful to switch back and forth for developer and
recovery settings while testing boards. The wtm2 board
currently doesn't have gpios which dynamically seelect that.
Might as well make it easy to change the value for each
setting with one define. The original defaults are kept.
Change-Id: I7b928c592fd20a1b847e4733f4cdef09d6ddad4c
Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
---
src/mainboard/intel/wtm2/chromeos.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/mainboard/intel/wtm2/chromeos.c b/src/mainboard/intel/wtm2/chromeos.c
index c2386a8..7ef7458 100644
--- a/src/mainboard/intel/wtm2/chromeos.c
+++ b/src/mainboard/intel/wtm2/chromeos.c
@@ -28,6 +28,10 @@
#endif
#include <southbridge/intel/lynxpoint/pch.h>
+/* Compile-time settings for developer and recovery mode. */
+#define DEV_MODE_SETTING 1
+#define REC_MODE_SETTING 0
+
#ifndef __PRE_RAM__
#include <boot/coreboot_tables.h>
#include <arch/coreboot_tables.h>
@@ -58,8 +62,8 @@ void fill_lb_gpios(struct lb_gpios *gpios)
gpio = gpios->gpios;
fill_lb_gpio(gpio++, -1, ACTIVE_HIGH, "write protect", 0);
- fill_lb_gpio(gpio++, -1, ACTIVE_HIGH, "recovery", 0); // force off
- fill_lb_gpio(gpio++, -1, ACTIVE_HIGH, "developer", 1); // force on
+ fill_lb_gpio(gpio++, -1, ACTIVE_HIGH, "recovery", REC_MODE_SETTING);
+ fill_lb_gpio(gpio++, -1, ACTIVE_HIGH, "developer", DEV_MODE_SETTING);
fill_lb_gpio(gpio++, -1, ACTIVE_HIGH, "lid", 1); // force open
fill_lb_gpio(gpio++, -1, ACTIVE_HIGH, "power", 0);
fill_lb_gpio(gpio++, -1, ACTIVE_HIGH, "oprom", oprom_is_loaded);
@@ -68,12 +72,12 @@ void fill_lb_gpios(struct lb_gpios *gpios)
int get_developer_mode_switch(void)
{
- return 1; // force on
+ return DEV_MODE_SETTING;
}
int get_recovery_mode_switch(void)
{
- return 0; // force off
+ return REC_MODE_SETTING;
}
int get_write_protect_state(void)
Stefan Reinauer (stefan.reinauer(a)coreboot.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2860
-gerrit
commit 834dabbcaeb7aad16b57b5e50d6845eb528f6ef7
Author: Aaron Durbin <adurbin(a)chromium.org>
Date: Tue Mar 19 12:43:18 2013 -0500
vboot: pass correct coreboot include paths
The coreboot include were not being passed correctly when
building vboot_reference. The paths being included were of the
src/<dir> form. However, vboot_reference lives in
src/../vboot_reference. That coupled with the recursive make
call made vboot_reference not see coreboot's header files.
Fix this by appending ../ to coreboot's default include paths.
Change-Id: I73949c6f854ecfce77ac36bb995918d51f91445e
Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
---
src/vendorcode/google/chromeos/Makefile.inc | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/vendorcode/google/chromeos/Makefile.inc b/src/vendorcode/google/chromeos/Makefile.inc
index 9bc4d64..abcd429 100644
--- a/src/vendorcode/google/chromeos/Makefile.inc
+++ b/src/vendorcode/google/chromeos/Makefile.inc
@@ -53,9 +53,11 @@ VBOOT_STUB_DEPS += $(obj)/lib/memcmp.rmodules.o
VBOOT_STUB_DEPS += $(obj)/arch/x86/lib/memset.rmodules.o
VBOOT_STUB_DEPS += $(obj)/arch/x86/lib/memcpy.rmodules.o
VBOOT_STUB_DEPS += $(VB_LIB)
-# Remove the '-include' option since that will break vboot's build.
-VBOOT_CFLAGS += $(filter-out -include $(src)/include/kconfig.h, $(CFLAGS))
+# Remove the '-include' option since that will break vboot's build and ensure
+# vboot_reference can get to coreboot's include files.
+VBOOT_CFLAGS += $(patsubst -I%,-I../%,$(filter-out -include $(src)/include/kconfig.h, $(CFLAGS)))
VBOOT_CFLAGS += -DVBOOT_DEBUG
+$(warning $(VBOOT_CFLAGS))
$(VBOOT_STUB_DOTO): $(VBOOT_STUB_DEPS)
$(CC) $(LDFLAGS) -nostdlib -r -o $@ $^
Stefan Reinauer (stefan.reinauer(a)coreboot.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2859
-gerrit
commit 1424861aeb3f263365046410dbbc247aa62029d8
Author: Aaron Durbin <adurbin(a)chromium.org>
Date: Tue Mar 19 12:41:29 2013 -0500
x86: provide more C standard environment
There are some external libraries that are built within
coreboot's environment that expect a more common C standard
environment. That includes things like inttypes.h and UINTx_MAX
macros. This provides the minimal amount of #defines and files
to build vboot_reference.
Change-Id: I95b1f38368747af7b63eaca3650239bb8119bb13
Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
---
src/arch/x86/include/stdint.h | 14 ++++++++++++++
src/include/inttypes.h | 4 ++++
2 files changed, 18 insertions(+)
diff --git a/src/arch/x86/include/stdint.h b/src/arch/x86/include/stdint.h
index 07cae47..c491f4b 100644
--- a/src/arch/x86/include/stdint.h
+++ b/src/arch/x86/include/stdint.h
@@ -76,6 +76,20 @@ typedef int16_t s16;
typedef int32_t s32;
+#ifndef UINT32_MAX
+#define UINT32_MAX (4294967295U)
+#endif
+#ifndef UINT64_MAX
+# define UINT64_MAX (18446744073709551615ULL)
+#endif
+#ifndef UINT64_C
+#define UINT64_C(c) c ## ULL
+#endif
+#ifndef PRIu64
+#define PRIu64 "llu"
+#endif
+
+
#undef __HAVE_LONG_LONG__
#endif /* I386_STDINT_H */
diff --git a/src/include/inttypes.h b/src/include/inttypes.h
new file mode 100644
index 0000000..77c39c4
--- /dev/null
+++ b/src/include/inttypes.h
@@ -0,0 +1,4 @@
+#ifndef INTTYPES_H
+#define INTTYPES_H
+#include <stdint.h>
+#endif /* INTTYPES_H */