LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Advertise
  • Mirrors
  • Logos
  • Contact us
  • Find Resources
  • Job Opportunity
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Openrisc > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: Carlos Sánchez de La Lama <csanchez@t...>
    Date: 02 Jul 2003 18:12:03 +0200
    Subject: Re: [openrisc] FW: [ECOS] Harvard architecture MLT files
    Top

    Hi!
    
    > 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.
    
    UC's gcc-2.95.3 puts constant data in a separate section (.rodata), so
    it can be used with a Harvard architecture.
    
    I have also tested OpenCores versions for this matter, and I have found
    out that gcc-2.95.2 puts constantd data and code together in .text
    section. However, newer versions (OpenCores gcc-3.x) put constants in
    .rodata.
     
    > 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?
    
    As Matjaz has pointed, I need gcc-2.95.3. But it's almost finished now,
    and we will join efforts to develop a gcc-3.4 port with the best of each
    branch.
    
    Regards,
    
    	Carlos
     
    > 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@s...
    > [mailto:ecos-discuss-owner@s...]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
    > 
    > 
    > 
    > 
    
    

    Esta parte del mensaje esta firmada digitalmente

    ReferenceAuthor
    [openrisc] FW: [ECOS] Harvard architecture MLT filesRobert Cragie

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.