[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[openrisc] FW: [ECOS] Harvard architecture MLT files
I thought I'd better forward this here too, as someone on the eCos mailing
list has usefully pointed out that GCC ports needs to be aware of the
Harvard architecture to prevent putting constant data in the code space.
So that's the question - does the GCC port (either the OpenRISC port or UC's
port) fully take into account the Harvard architecture? I realise the ORP
version doesn't have this problem as it uses the 'traffic cop' and caches
but that's overkill for what we want.
On the same note, whilst it's good to see the efforts done by Carlos and the
University of Cantabria, surely it would be better to put effort into
maintaining the GCC 3.2.3 port as opposed to the old 2.95.3 port? I have
just compiled the latest eCos successfully on GCC 3.2.3 port (not run it yet
though) but I'm wondering if UC's efforts need to be included as well. Can
anyone give me the status on this?
Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
http://www.jennic.com Tel: +44 (0) 114 281 2655
_______________________________________________________________
-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Robert Cragie
Sent: 02 July 2003 12:01
To: ECOS
Subject: [ECOS] Harvard architecture MLT files
I have an implementation of the OpenRISC core which is pure Harvard, i.e. no
caches/mmus, separate instruction bus and memory, separate data bus and
memory. The memories are dual-ported which means I can load them externally
without needing the processor running. So my ultimate aim is to create two
image files for the instruction and data memories respectively.
This brings up a few questions:
1) How do I now layout the MLT files? It's no longer ROM and RAM, it's more
like ROM(inst), ROM(data), RAM(data). Here is a stab at the .ldi file:
// eCos memory layout
#include <cyg/infra/cyg_type.inc>
MEMORY
{
inst : ORIGIN = 0x00000000, LENGTH = 0x00020000
data : ORIGIN = 0x01000000, LENGTH = 0x00020000
}
SECTIONS
{
SECTIONS_BEGIN
SECTION_vectors (inst, 0x00000100, LMA_EQ_VMA)
SECTION_ROMISC (inst, ALIGN (0x8), LMA_EQ_VMA)
SECTION_RELOCS (inst, ALIGN (0x8), LMA_EQ_VMA)
SECTION_init (inst, ALIGN (0x8), LMA_EQ_VMA)
SECTION_text (inst, ALIGN (0x4), LMA_EQ_VMA)
SECTION_fini (inst, ALIGN (0x4), LMA_EQ_VMA)
SECTION_rodata1 (data, 0x01000000, LMA_EQ_VMA)
SECTION_rodata (data, ALIGN (0x8), LMA_EQ_VMA)
SECTION_fixup (data, ALIGN (0x4), LMA_EQ_VMA)
SECTION_gcc_except_table (data, ALIGN (0x4), LMA_EQ_VMA)
SECTION_data (data, ALIGN (0x8), FOLLOWING (.gcc_except_table))
SECTION_eh_frame (data, ALIGN (0x8), FOLLOWING (.data))
SECTION_ctors (data, ALIGN (0x8), FOLLOWING (.eh_frame))
SECTION_dtors (data, ALIGN (0x8), FOLLOWING (.ctors))
SECTION_devtab (data, ALIGN (0x8), FOLLOWING (.dtors))
SECTION_got (data, ALIGN (0x8), FOLLOWING (.devtab))
SECTION_dynamic (data, ALIGN (0x8), FOLLOWING (.got))
SECTION_sdata (data, ALIGN (0x8), FOLLOWING (.dynamic))
SECTION_lit8 (data, ALIGN (0x8), FOLLOWING (.sdata))
SECTION_lit4 (data, ALIGN (0x8), FOLLOWING (.lit8))
SECTION_sbss (data, ALIGN (0x8), LMA_EQ_VMA)
SECTION_bss (data, ALIGN (0x10), LMA_EQ_VMA)
CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
SECTIONS_END
}
Am I anywhere close?
And for the image files, is it a case of taking the literal values from
0x00000000 to 0x00020000 and writing them into the instruction memory and
taking the literal values from 0x01000000 to 0x01020000 and writing them
into the data memory? (I'm not too bothered about repeating data space in
the rodata and data sections at the moment but would like to know how to
avoid it if possible).
Any help would be much appreciated.
Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
http://www.jennic.com Tel: +44 (0) 114 281 2655
_______________________________________________________________
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml