OpenBIOS December 2010

openbios@openbios.org

12 participants
64 discussions

[commit] r980 - trunk/openbios-devel/arch/ppc/qemu
by repository service 05 Dec '10

05 Dec '10

Author: afaerber Date: Sun Dec 5 15:16:13 2010 New Revision: 980 URL: http://tracker.coreboot.org/trac/openbios/changeset/980 Log: ppc: Simplify get_ram_bottom() Avoid a cast by adjusting the define. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sun Dec 5 02:15:57 2010 (r979) +++ trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sun Dec 5 15:16:13 2010 (r980) @@ -44,7 +44,7 @@ * */ -#define FREE_BASE 0x00004000 +#define FREE_BASE 0x00004000UL #define OF_CODE_START 0xfff00000UL #define OF_CODE_SIZE 0x00100000 #define IO_BASE 0x80000000 @@ -82,7 +82,7 @@ unsigned long get_ram_bottom(void) { - return (unsigned long)FREE_BASE; + return FREE_BASE; } static ucell get_heap_top(void)

1 0

[commit] r979 - trunk/openbios-devel/forth/lib
by repository service 05 Dec '10

05 Dec '10

Author: afaerber Date: Sun Dec 5 02:15:57 2010 New Revision: 979 URL: http://tracker.coreboot.org/trac/openbios/changeset/979 Log: forth: Fix ([IF]) to handle nested [IFDEF] as well Depending on the condition, either the [IFDEF] FOO or the [ELSE] would get compiled as an [IF], eating words until [ELSE] or [THEN] respectively. While doing so, [IFDEF] does not get compiled to [IF], so we need to handle nested [IFDEF] to account for its [ELSE] or [THEN]. This fixes [IFDEF] not disabling the full section of code. Thanks to Segher for pointing me in the right direction. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Signed-off-by: Segher Boessenkool <segher(a)kernel.crashing.org> Modified: trunk/openbios-devel/forth/lib/preprocessor.fs Modified: trunk/openbios-devel/forth/lib/preprocessor.fs ============================================================================== --- trunk/openbios-devel/forth/lib/preprocessor.fs Sun Nov 28 21:03:46 2010 (r978) +++ trunk/openbios-devel/forth/lib/preprocessor.fs Sun Dec 5 02:15:57 2010 (r979) @@ -19,6 +19,7 @@ repeat 2dup " [IF]" strcmp 0= if 1 throw then + 2dup " [IFDEF]" strcmp 0= if 1 throw then 2dup " [ELSE]" strcmp 0= if 2 throw then 2dup " [THEN]" strcmp 0= if 3 throw then " \\" strcmp 0= if linefeed parse 2drop then

1 0

Nested [IFDEF]s not working?
by Andreas Färber 04 Dec '10

04 Dec '10

Hello, A construct like: [IFDEF] CONFIG_PPC [IFDEF] CONFIG_PPC64 5 [ELSE] 4 [THEN] [ELSE] [IFDEF] CONFIG_SPARC64 6 [ELSE] 3 [THEN] [THEN] has been seen to return, e.g., 4 3 according to the debug word. Is this nesting forbidden in Forth? Easily fixable? A better way to do this? I do want a final catch-all since returning no value would have unexpected results, and we currently do not have a define CONFIG_PPC32 so that a concatenation of independent [IFDEF]...[THEN]s wouldn't work. TIA, Andreas

3 5

Reducing OpenBIOS memory footprint
by Mark Cave-Ayland 02 Dec '10

02 Dec '10

Hi folks, It's taken me a lot longer to get to grips with moving SPARC32 to OFMEM than expected, mostly due to problems with the increased BSS size of the resulting image causing several large headaches. Having spent some time looking at where the memory is currently being used, it strikes me that there are 2 main places where we can claim some back: i) Reduce (remove) the runtime memory allocated to the Forth machine One interesting aspect of the current design is that we have 2 memory allocation ranges - the Forth machine memory which is used for alloc-mem and free-mem, and also the OFMEM ranges. For example, in SPARC32 this is set to 256K which given the large I/O space requirements for the frame buffer, is about a quarter of the total memory. I'd like to suggest that we unify the memory management by removing the Forth implementations of alloc-mem/free-mem and replace them with wrappers to the internal ofmem_malloc() and ofmem_free() functions. This would then enable us to have one continuous pool of allocatable memory which could be used for everything. One slight issue with this is that there are a few references to alloc-mem/free-mem within the internal Forth code. These are mainly for allocating static buffers, and so I believe these could be removed and replaced by functions that simply allocate memory within the dictionary itself. ii) Avoid re-allocation of memory for the Forth dictionary At runtime we currently have two copies of the dictionary held within memory - the first is the actual static dictionary data, while the second is the relocated dictionary image within the BSS. In the case of SPARC32 this is responsible for just over 100K of the BSS image size. Rather than having to allocate a second copy of the dictionary, would it make sense to embed the fixed size dictionary directly within the OpenBIOS image? As an example SPARC32 specifies 256K for the total dictionary size. I think it should be possible to rewrite the relocation routine to relocate the dictionary 'in place' and then remove the relocation data so that the dictionary can extend normally up to its final limit. The downside of this is that the ROM images will be bigger on disk, but I don't feel that this should be too much of an issue. I realise that these two ideas are probably fairly controversial, but they should both help considerably reduce the size of the OpenBIOS runtime memory footprint. Thoughts/comments/criticisms? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

3 5