Because the sizes of cells and pointers do not match on PPC64, relocations of an ucell array using the address of the array itself can't be computed by the linker.
Use a fixed address on PPC64 for the array, so we can use a fixed ucell sized constant for the relocation offset.
Signed-off-by: Blue Swirl blauwirbel@gmail.com --- arch/ppc/build.xml | 6 +----- arch/ppc/qemu/kernel.c | 23 ++++++++++++++++++----- arch/ppc/qemu/ofmem.c | 2 +- arch/ppc64/qemu/ldscript | 7 +++++++ 4 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/arch/ppc/build.xml b/arch/ppc/build.xml index 4aec62f..8468799 100644 --- a/arch/ppc/build.xml +++ b/arch/ppc/build.xml @@ -60,11 +60,7 @@
<executable name="target/include/qemu-dict.h" target="target" condition="QEMU"> <rule><![CDATA[ - $(call quiet-command,true, " GEN $(TARGET_DIR)$@") - @echo "static const char forth_dictionary[] = {" > $@ - @cat $< | hexdump -ve '1/0 "\t" 8/1 "0x%02x, " 1/0 "\n"' \ - | sed 's/0x ,//g' >> $@ - @echo "};" >> $@]]></rule> + $(call quiet-command,$(ODIR)/forthstrap -x -D $@ -d $< </dev/null, " GEN $(TARGET_DIR)$@")]]></rule> <external-object source="openbios-qemu.dict"/> </executable>
diff --git a/arch/ppc/qemu/kernel.c b/arch/ppc/qemu/kernel.c index 4cae525..b26fba5 100644 --- a/arch/ppc/qemu/kernel.c +++ b/arch/ppc/qemu/kernel.c @@ -17,7 +17,6 @@ * */
-#include "qemu-dict.h" #include "config.h" #include "dict.h" #include "libopenbios/bindings.h" @@ -27,7 +26,19 @@ #include "kernel.h"
#define MEMORY_SIZE (256*1024) /* 256K ram for hosted system */ -#define DICTIONARY_SIZE (512*1024) /* 512K for the dictionary */ +/* 512K for the dictionary */ +#define DICTIONARY_SIZE (512 * 1024 / sizeof(ucell)) +#ifdef __powerpc64__ +#define DICTIONARY_BASE 0xfff08000 /* this must match the value in ldscript! */ +#define DICTIONARY_SECTION __attribute__((section(".data.dict"))) +#else +#define DICTIONARY_BASE ((ucell)((char *)&forth_dictionary)) +#define DICTIONARY_SECTION +#endif + +static ucell forth_dictionary[DICTIONARY_SIZE] DICTIONARY_SECTION = { +#include "qemu-dict.h" +};
static ucell *memory;
@@ -82,10 +93,12 @@ init_memory( void ) int initialize_forth( void ) { - dict = malloc(DICTIONARY_SIZE); - dictlimit = DICTIONARY_SIZE; + dict = (unsigned char *)forth_dictionary; + dicthead = (ucell)FORTH_DICTIONARY_END; + last = (ucell *)((unsigned char *)forth_dictionary + + FORTH_DICTIONARY_LAST); + dictlimit = sizeof(forth_dictionary);
- load_dictionary( forth_dictionary, sizeof(forth_dictionary) ); forth_init();
PUSH_xt( bind_noname_func(arch_of_init) ); diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c index 4c6825e..f6cf8cd 100644 --- a/arch/ppc/qemu/ofmem.c +++ b/arch/ppc/qemu/ofmem.c @@ -55,7 +55,7 @@ extern void setup_mmu(unsigned long code_base); #define HASH_BITS 15 #endif #define HASH_SIZE (2 << HASH_BITS) -#define OFMEM_SIZE (2 * 1024 * 1024) +#define OFMEM_SIZE (1 * 1024 * 1024 + 512 * 1024)
#define SEGR_USER BIT(2) #define SEGR_BASE 0x0400 diff --git a/arch/ppc64/qemu/ldscript b/arch/ppc64/qemu/ldscript index 7a22903..fbbcc54 100644 --- a/arch/ppc64/qemu/ldscript +++ b/arch/ppc64/qemu/ldscript @@ -6,6 +6,7 @@ OUTPUT_ARCH(powerpc:common64) BASE_ADDR = 0xfff00000;
/* As NVRAM is at 0xfff04000, the .text needs to be after that + * The value in arch/ppc/qemu/kernel.c must match this value! */ TEXT_ADDR = 0xfff08000;
@@ -26,6 +27,12 @@ SECTIONS
. = TEXT_ADDR; /* Normal sections */ + .data.dict ALIGN(4096): { + _dict_start = .; + *(.data.dict) + _dict_end = .; + } + .text ALIGN(4096): { *(.text) *(.text.*)
Because the sizes of cells and pointers do not match on PPC64,
So fix that. Most OF implementations on 64-bit PowerPC use 64-bit cells; you pretty much need it for things like device access, esp. if running in real mode.
The Forth standard does not define pointers that do not fit in a cell; OF-specific words like rl@ take a cell-sized "address" as well.
Segher
On 23/01/11 17:42, Segher Boessenkool wrote:
Because the sizes of cells and pointers do not match on PPC64,
So fix that. Most OF implementations on 64-bit PowerPC use 64-bit cells; you pretty much need it for things like device access, esp. if running in real mode.
The Forth standard does not define pointers that do not fit in a cell; OF-specific words like rl@ take a cell-sized "address" as well.
I'm fairly sure that Andreas is aware of this (for example, one of the patches I posted earlier for SPARC32 fixes the generation of memory properties but will truncate the maximum address to 32-bits on PPC64 since the code assumes that a single cell can hold a virtual address).
Andreas - are you happy for these two patchsets to be applied? We'd like to hope they won't break PPC64 too badly until you can find some time to continue work on it.
ATB,
Mark.
Hi,
Am 26.01.2011 um 15:14 schrieb Mark Cave-Ayland:
On 23/01/11 17:42, Segher Boessenkool wrote:
Because the sizes of cells and pointers do not match on PPC64,
So fix that. Most OF implementations on 64-bit PowerPC use 64-bit cells; you pretty much need it for things like device access, esp. if running in real mode.
The Forth standard does not define pointers that do not fit in a cell; OF-specific words like rl@ take a cell-sized "address" as well.
I'm fairly sure that Andreas is aware of this (for example, one of the patches I posted earlier for SPARC32 fixes the generation of memory properties but will truncate the maximum address to 32-bits on PPC64 since the code assumes that a single cell can hold a virtual address).
Andreas - are you happy for these two patchsets to be applied? We'd like to hope they won't break PPC64 too badly until you can find some time to continue work on it.
My (our) requirement is that the guest-visible parts remain compatible with Apple OpenFirmware (the hardware we emulate today), and I'd prefer to share a common code base for ppc and ppc64.
My understanding is that if we enlarge the internal cell size as suggested by Segher, encode-int and other Forth words will start widening their output, too, so that property values will start to differ, no? Currently, everything except for the MMU is designed to be 32-bit compatible.
Mark/Blue, if you've tested your patches with ppc64 and it still boots, feel free to commit.
Andreas
On 2011-1-29 7:26 AM, Andreas Färber wrote:
[...] My (our) requirement is that the guest-visible parts remain compatible with Apple OpenFirmware (the hardware we emulate today), and I'd prefer to share a common code base for ppc and ppc64.
My understanding is that if we enlarge the internal cell size as suggested by Segher, encode-int and other Forth words will start widening their output, too, so that property values will start to differ, no?
Shouldn't. Encode-int is defined to encode 32-bit integers, not full cells. A property "cell" is always 32-bits, even on 64-bit machines.
A 64-bit forth engine must still be capable of running 32-bit FCode version2.
Because the sizes of cells and pointers do not match on PPC64,
So fix that. Most OF implementations on 64-bit PowerPC use 64-bit cells; you pretty much need it for things like device access, esp. if running in real mode.
The Forth standard does not define pointers that do not fit in a cell; OF-specific words like rl@ take a cell-sized "address" as well.
I'm fairly sure that Andreas is aware of this (for example, one of the patches I posted earlier for SPARC32 fixes the generation of memory properties but will truncate the maximum address to 32-bits on PPC64 since the code assumes that a single cell can hold a virtual address).
Andreas - are you happy for these two patchsets to be applied? We'd like to hope they won't break PPC64 too badly until you can find some time to continue work on it.
My (our) requirement is that the guest-visible parts remain compatible with Apple OpenFirmware (the hardware we emulate today), and I'd prefer to share a common code base for ppc and ppc64.
You can do both with a 64-bit OF; you can provide a 32-bit client interface.
Apple's OF on the G5 machines is a 32-bit OF, and they do a lot of very much non-standard things (including a lot that are not correct).
It is possible that the Linux kernel will not work with certain 64-bit device tree things, because of bugs in the kernel. I recommend you fix such bugs, or avoid them. But you really want to have #address-cells = #size-cells = 2 in the root node; without it, for example, you cannot have 4GB or more of memory.
My understanding is that if we enlarge the internal cell size as suggested by Segher, encode-int and other Forth words will start widening their output, too, so that property values will start to differ, no?
No. encode-int will encode a 32-bit integer, always. All of the device tree data is completely independent of word size and endianness, etc.
"#address-cells" in the device tree actually means "number of 32-bit integers per address". It's historical...
Segher
On 29/01/11 13:26, Andreas Färber wrote:
Mark/Blue, if you've tested your patches with ppc64 and it still boots, feel free to commit.
Is it possible to build a ppc cross-compiler that does both PPC64 and PPC32? I only ask because disk space is a little tight on my workstation.
My main concern was that in order to fix up the memory properties, I had to truncate the memory available properties to 32-bit (4GB). However since Segher points out that you won't be able to allocate memory past 4GB until you finally bump the cell size, I don't see that this is a reason not to commit.
ATB,
Mark.
-
Andreas Färber -
Blue Swirl -
Mark Cave-Ayland -
Segher Boessenkool -
Tarl Neustaedter