Hi folks,
The attached patch changes OFMEM so that instead of allocating new space
within the Forth dictionary every time the /memory and /virtual-memory
available/translations nodes are updated, we simply change the property
to point directly to a static buffer. This has the effect of saving
substantial amounts of memory during OpenSolaris 10 boot (in fact the
final dictionary size after boot is now < 256K once again).
Blue/Andreas: please could you take a look at this patch and make sure
it doesn't break anything in your SPARC64/PPC tests?
On the plus side, with this patch applied Milax gets to the end of its
natural boot without crashing giving the following output:
OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
kernel cmdline
CPUs: 1 x SUNW,UltraSPARC-IIi
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on Oct 14 2010 20:18
Type 'help' for detailed information
Trying cdrom:f...
Not a bootable ELF image
Not a bootable a.out image
Loading FCode image...
Loaded 7084 bytes
entry point is 0x4000
Ignoring failed claim for va 1000000 memsz bf34e!
Ignoring failed claim for va 1402000 memsz 303b3!
Ignoring failed claim for va 1800000 memsz 60a30!
Jumping to entry point 00000000010071d8 for type 0000000000000001...
switching to new context: entry point 0x10071d8 stack 0x00000000ffe06b49
warning:interpret: exception -13 caught
SunOS Release 5.11 Version MilaX_0.3.2 64-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
spacex@:interpret: exception -13 caught
kdbg-words:interpret: exception -13 caught
cb-r/w:interpret: exception -13 caught
(Can't load tod module) EXIT
-1 >
Does anyone know what the tod modules does? Is it Time Of Day (i.e. we
are missing some kind of hardware clock emulation?)
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
Display one MMU translation per row for .properties command.
Signed-off-by: Andreas Färber <andreas.faerber(a)web.de>
---
forth/admin/devices.fs | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs
index 7a5b693..00b4f55 100644
--- a/forth/admin/devices.fs
+++ b/forth/admin/devices.fs
@@ -326,6 +326,30 @@
3drop drop
;
+\ Print the value of the MMU translations property
+: .p-translations ( data len -- )
+ 2dup + -rot ( data+len data len )
+ >r >r [IFDEF] CONFIG_PPC
+ [IFDEF] CONFIG_PPC64 5 [ELSE] 4 [THEN]
+ [ELSE]
+ 3
+ [THEN] 4 * dup ( data+len #bytes #bytes R: len data ) r> r>
+ bounds ( data+len #bytes #bytes data+len data ) ?do
+ 2dup <> if \ non-first byte in row
+ dup 3 and 0= if space then \ make numbers more readable
+ then
+ i c@ 2 0.r \ print byte
+ 1- dup 0= if \ end of row
+ 2 pick i 1+ > if \ non-last byte
+ cr \ start new line
+ d# 26 spaces \ indentation
+ then
+ drop dup \ update counter
+ then
+ loop
+ 2drop drop
+;
+
\ This function hardwires data formats to particular node properties
: (.property-by-name) ( name-str name-len data len -- )
2over " reg" strcmp 0= if
@@ -346,6 +370,10 @@
1 1 2swap .p-reg
2drop exit
then
+ 2over " translations" strcmp 0= if
+ .p-translations
+ 2drop exit
+ then
then
then
then
--
1.7.3
Hi all,
Here is my first attempt at switching over OFMEM to use phys_addr_t for
physical addresses. It was mainly a case of going through all of the
OFMEM APIs by hand and then updating the definitions used to hold
physical addresses, along with swapping over range_t to use phys_addr_t
on the assumption that sizeof(phys_addr_t) >= sizeof(ucell).
Andreas - note I've not touched anything in ppc64 as I figure this is
still experimental and I don't really have anything to test it with.
This patch seems to work on my SPARC64/PPC tests here, but since it
touches a core part of OpenBIOS I'd like to get a little more feedback
before committing it.
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
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
Author: afaerber
Date: Sun Nov 28 14:13:38 2010
New Revision: 977
URL: http://tracker.coreboot.org/trac/openbios/changeset/977
Log:
ppc: Create some more function descriptors for ppc64
Fix an error in generic ppc code as well. Reported by Blue.
Signed-off-by: Andreas Färber <andreas.faerber(a)web.de>
Acked-by: Blue Swirl <blauwirbel(a)gmail.com>
Modified:
trunk/openbios-devel/arch/ppc/timebase.S
Modified: trunk/openbios-devel/arch/ppc/timebase.S
==============================================================================
--- trunk/openbios-devel/arch/ppc/timebase.S Sun Nov 28 12:40:42 2010 (r976)
+++ trunk/openbios-devel/arch/ppc/timebase.S Sun Nov 28 14:13:38 2010 (r977)
@@ -4,7 +4,7 @@
/*
* unsigned long long _get_ticks(void);
*/
-GLOBL(_get_ticks):
+_GLOBAL(_get_ticks):
1: mftbu r3
mftb r4
mftbu r5
@@ -15,16 +15,16 @@
/*
* Delay for a number of ticks
*/
-GLOBL(_wait_ticks):
+_GLOBAL(_wait_ticks):
mflr r8 /* save link register */
mr r7, r3 /* save tick count */
- bl _get_ticks /* Get start time */
+ bl BRANCH_LABEL(_get_ticks) /* Get start time */
/* Calculate end time */
addc r7, r4, r7 /* Compute end time lower */
addze r6, r3 /* and end time upper */
-1: bl _get_ticks /* Get current time */
+1: bl BRANCH_LABEL(_get_ticks) /* Get current time */
subfc r4, r4, r7 /* Subtract current time from end time */
subfe. r3, r3, r6
bge 1b /* Loop until time expired */