coreboot September 2008

coreboot@coreboot.org

59 participants
415 discussions

r237 - buildrom-devel/packages/filo
by svn＠coreboot.org 26 Sep '08

26 Sep '08

Author: jcrouse Date: 2008-09-27 00:24:05 +0200 (Sat, 27 Sep 2008) New Revision: 237 Modified: buildrom-devel/packages/filo/filo.mk Log: FILO wasn't looking in the correct location for the platform config file. Signed-off-by: Marc Jones <marc.jones(a)amd.com> Acked-by: Jordan Crouse <jordan.crouse(a)amd.com> Modified: buildrom-devel/packages/filo/filo.mk =================================================================== --- buildrom-devel/packages/filo/filo.mk 2008-09-24 14:15:45 UTC (rev 236) +++ buildrom-devel/packages/filo/filo.mk 2008-09-26 22:24:05 UTC (rev 237) @@ -19,7 +19,7 @@ FILO_TARBALL=filo-svn-$(FILO_TAG).tar.gz ifeq ($(shell if [ -f $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) - FILO_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + FILO_CONFIG = $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) else FILO_CONFIG = $(FILO_SRC_DIR)/configs/defconfig endif

1 0

libpayload: New memory allocator
by Jordan Crouse 26 Sep '08

26 Sep '08

Okay, get ready to pick those nits! Attached is a patch for a new memory allocator. Please review and tear it apart. If you hate what I have done, then please propose something different (preferably with patches!). Read on for my motivation and description of whats going on here. What was wrong with the old allocator you say? Glad you asked. The old memory allocator worked on a static region of memory set aside by the linker - in the case of libpayload it was 16k sightly above the .data segment of the payload. This was so that we didn't need to concern ourselves with figuring out how much system memory we had and other such concerns. Well, 16k goes quickly. We are outgrowing our little sandbox. As an example, I wanted to change the menu system in coreinfo to allow for more items. This would have involved a "popup" window that the user could navigate to select the next area to examine. Unfortunately, the current implementation uses a static allocation for windows, which limited us to 3 total windows, and guess what - we're already using them. If I allocate them dynamically, then that will reduce the amount of memory usable for other components, and like I said - 16k goes fast. So, this new allocator reads the memory tables, and sets up a block of allocateable memory at the top of system RAM. Right now we are hardcoding 8Mb of memory, but that will eventually be configurable through both Kconfig and at runtime. So here is how the allocator works - right below the allocated memory is room for an array of slots - each slot has an entry for an offset into memory and a size. It also has prev and next pointers for linked list purposes. The number of slots is currently hardcoded to 1024. There are three lists - the unallocated list contains all of the unused slots. At init time, there would are 1023 unused slots. The free list contains slots describing all of the free areas in the memory. At init time, this list contains a single entry with offset 0, and size of 8Mb. The final list is actually a hash of linked lists - this will contain the allocated pointers as they are created. So, we're set up - and the user calls malloc(). The free blocks are searched for a free block large enough for the allocation. The slot containing the former free block is re-adjusted for the allocated size, and a new slot is allocated on the free list containing the remainder of the previous free block. Put simply, if the original free block is 8Mb, and you allocate 1Mb, then a new 7Mb slot is put on to the free block list. And the 1Mb allocated slot is added to the allocated hash table. When the entry is free()d, it is added to the free list. We also run a consolidate function that merges consecutive free blocks and and returns the unused slots to the unallocated list. The advantage of this implementation is that it is pretty simple, easy to code, and interestingly enough, it allows us to maintain multiple chunks of dynamic memory. Why is this useful? One of the problems with reentrant payloads such as bayou is that if they need their memory to stick around, then they need to exclude it from the tables they pass to their children payloads. This is cool if you are running coreinfo, but not so cool if you are calling FILO and then the kernel, because the kernel won't return, and you've wasted memory. One of the solutions for this would be to use both the original static memory block _and_ the extended memory block, and then restrict bayou so that it only uses the static memory. This implementation lets us do that, and it will just work (TM). -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.

1 0

r3607 build service
by coreboot information 26 Sep '08

26 Sep '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "stepan" checked in revision 3607 to the coreboot source repository and caused the following changes: Change Log: Use a block cursor on VGA console :-) Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Jordan Crouse <jordan.crouse(a)amd.com> Build Log: Compilation of jetway:j7f24 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3607&device=j7f24&vendor=j… Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3607&device=epia-cn&vendor… 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

r3606 build service
by coreboot information 26 Sep '08

26 Sep '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "stepan" checked in revision 3606 to the coreboot source repository and caused the following changes: Change Log: fix option handling in libpayload Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Jordan Crouse <jordan.crouse(a)amd.com> Build Log: Compilation of jetway:j7f24 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3606&device=j7f24&vendor=j… Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3606&device=epia-cn&vendor… 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

r3605 build service
by coreboot information 26 Sep '08

26 Sep '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "stepan" checked in revision 3605 to the coreboot source repository and caused the following changes: Change Log: * add keyboard layout support to libpayload * add a reset handler mechanism (CTRL-ALT-DEL) Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Jordan Crouse <jordan.crouse(a)amd.com> Build Log: Compilation of jetway:j7f24 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3605&device=j7f24&vendor=j… Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3605&device=epia-cn&vendor… 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

Re: [coreboot] r3604 - in trunk/payloads/libpayload: curses drivers include
by Ulf Jordan 26 Sep '08

26 Sep '08

Hello! This revision introduced a regression, see below. On Fri, 26 Sep 2008, svn(a)coreboot.org wrote: > Modified: trunk/payloads/libpayload/curses/tinycurses.c > =================================================================== > --- trunk/payloads/libpayload/curses/tinycurses.c 2008-09-26 17:41:34 UTC (rev 3603) > +++ trunk/payloads/libpayload/curses/tinycurses.c 2008-09-26 18:36:26 UTC (rev 3604) > @@ -77,7 +77,7 @@ > > /* Globals */ > int COLORS; /* Currently unused? */ > -int COLOR_PAIRS; > +int COLOR_PAIRS = 255; > WINDOW *stdscr; > WINDOW *curscr; > WINDOW *newscr; > @@ -111,6 +111,7 @@ > '|', '<', '>', '*', '!', 'f', 'o', ' ', > }; > > +#ifdef CONFIG_SERIAL_CONSOLE > #ifdef CONFIG_SERIAL_ACS_FALLBACK > chtype serial_acs_map[128]; > #else > @@ -135,7 +136,9 @@ > 'x', 'y', 'z', '{', '|', '}', '~', 0, > }; > #endif > +#endif > > +#ifdef CONFIG_VIDEO_CONSOLE > /* See acsc of linux. */ > chtype console_acs_map[128] = > { > @@ -156,6 +159,7 @@ > '\304', '\304', '\304', '_', '\303', '\264', '\301', '\302', > '\263', '\363', '\362', '\343', '\330', '\234', '\376', 0, > }; > +#endif > > // FIXME: Ugly (and insecure!) hack! > char sprintf_tmp[1024]; > @@ -196,13 +200,16 @@ > // int color_content(short color, short *r, short *g, short *b) {} > int curs_set(int on) > { > +#ifdef CONFIG_SERIAL_CONSOLE > if (curses_flags & F_ENABLE_SERIAL) { > - // TODO > + serial_cursor_enable(on); > } > - > +#endif > +#ifdef CONFIG_VIDEO_CONSOLE > if (curses_flags & F_ENABLE_CONSOLE) { > video_console_cursor_enable(on); > } > +#endif > > return OK; > } > @@ -284,7 +291,7 @@ > // int flash(void) {} > int flushinp(void) { /* TODO */ return 0; } > // WINDOW *getwin (FILE *) {} > -bool has_colors (void) { /* TODO */ return(*(bool *)0); } > +bool has_colors (void) { return(TRUE); } > // bool has_ic (void) {} > // bool has_il (void) {} > // void idcok (WINDOW *, bool) {} > @@ -300,21 +307,23 @@ > > for (i = 0; i < 128; i++) > acs_map[i] = (chtype) i | A_ALTCHARSET; > - > +#ifdef CONFIG_SERIAL_CONSOLE > if (curses_flags & F_ENABLE_SERIAL) { > serial_clear(); > } > - > +#endif > +#ifdef CONFIG_VIDEO_CONSOLE > if (curses_flags & F_ENABLE_CONSOLE) { > /* Clear the screen and kill the cursor */ > > video_console_clear(); > video_console_cursor_enable(0); > } > +#endif > > // Speaker init? > > - stdscr = newwin(SCREEN_Y, SCREEN_X, 0, 0); > + stdscr = newwin(SCREEN_Y, SCREEN_X + 1, 0, 0); This last line accidentally reverts r3598, please change it back. /ulf

2 1

r3611 - trunk/payloads/libpayload/curses
by svn＠coreboot.org 26 Sep '08

26 Sep '08

Author: stepan Date: 2008-09-26 21:37:16 +0200 (Fri, 26 Sep 2008) New Revision: 3611 Modified: trunk/payloads/libpayload/curses/tinycurses.c Log: accidently backed out r3598. Sorry Ulf, will pay more attention next time. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/payloads/libpayload/curses/tinycurses.c =================================================================== --- trunk/payloads/libpayload/curses/tinycurses.c 2008-09-26 19:15:38 UTC (rev 3610) +++ trunk/payloads/libpayload/curses/tinycurses.c 2008-09-26 19:37:16 UTC (rev 3611) @@ -323,7 +323,7 @@ // Speaker init? - stdscr = newwin(SCREEN_Y, SCREEN_X + 1, 0, 0); + stdscr = newwin(SCREEN_Y, SCREEN_X, 0, 0); // TODO: curscr, newscr? werase(stdscr);

1 0

[FILO] #4: specifying 'initrd' multiple times appends extra initrd parameters
by FILO 26 Sep '08

26 Sep '08

#4: specifying 'initrd' multiple times appends extra initrd parameters ------------------------------------+--------------------------------------- Reporter: hawke(a)hawkesnest.net | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: component1 | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ------------------------------------+--------------------------------------- If the 'initrd' command is issued several times, the values are appended as extra initrd= parameters, instead of replacing the existing initrd= value from the kernel string. -- Ticket URL: </trac/ticket/4> FILO <http://www.coreboot.org/FILO>

1 2

[FILO] #3: re-specifying 'root' command doesn't replace the root value
by FILO 26 Sep '08

26 Sep '08

#3: re-specifying 'root' command doesn't replace the root value ------------------------------------+--------------------------------------- Reporter: hawke(a)hawkesnest.net | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: component1 | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ------------------------------------+--------------------------------------- When the 'root' command is run from the grub-style interface, the first value provided cannot subsequently be changed. e.g. if the command 'root hde1' is entered by mistake, it should be possible to later specify 'root hde1:' and have it update the root value. -- Ticket URL: </trac/ticket/3> FILO <http://www.coreboot.org/FILO>

1 2

[FILO] #2: root command is not validated
by FILO 26 Sep '08

26 Sep '08

#2: root command is not validated ------------------------------------+--------------------------------------- Reporter: hawke(a)hawkesnest.net | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ------------------------------------+--------------------------------------- When the 'root' command is run from the grub-style interface, filo does no validation of the specified value. It would be nice if it would ensure that the value corresponded with whatever filo uses for a device specification. (in particular, it's easy to expect it to accept 'hde1' instead of, or as well as, 'hde1:') -- Ticket URL: </trac/ticket/2> FILO <http://www.coreboot.org/FILO>

1 2

← Newer
1
...
11
12
13
14
15
16
17
...
42
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 September 2008