public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Dan Conti" <danc@iobjects.com>
To: <ecos-discuss@sources.redhat.com>
Subject: RE: [ECOS] ROM startup + MMU tables
Date: Tue, 07 Aug 2001 10:48:00 -0000	[thread overview]
Message-ID: <D8DFF0AFE792914996F997E68FEC3A48F312@bunker.iobjects.com> (raw)

Yeah, the static mmu table support on the edb7xxx platform is kinda
broken. I was able to get it working with only the onchip sram (which i
mapped to 0), but my solution isn't really clean enough to make a patch
out of. i did this a long time ago, and some of the code i've put in
these files doesn't relate, so please excuse me if i botch any of the
details.

the basics are as follows:

1) my goal was to make the on chip sram show up as dram, so in
hal_platform_setup.h, i made DRAM_PA_START be 0x6000:0000 if
CYGHWR_HAL_ARM_EDB7XXX_DRAM_SIZE==0. additionally you have to define
MMU_TABLE_SIZE and DRAM_LA_END, but i dont think these values pertain
when using the static tables. 
2) in edb7xxx/include/hal_platform_extras.h, at the top, it generates
the level 2 pagetable based on the DRAM_SIZE. you need to add a case in
there for DRAM_SIZE==0. i didn't have any flash constraints on my board,
the following snippet should suffice:

	.set    PTE,(DRAM_PA_START)|MMU_L2_TYPE_Small\
	            |MMU_AP_Any|MMU_Bufferable|MMU_Cacheable
	.rept   (0x800000)/0x1000
	NEXT_PAGE
	.endr

Note that this generates a larger L2 page table than is actually
appropriate, since there is only 37.5k of sram on the 72xx chips.

3) the flash isn't mapped in correctly, the page table entries are
miscalculated. i think you're limited to only the first 1mb of flash,
after which the calculation breaks down. i'm sorry i dont remember the
exact flaw here, but the fix is to generate an alternate set of FILL
macros for the flash regions. instead of doing

	.long	base+(OFF*(seg+0x00));

your 16M_SEGMENT rom fill macro should do:

	.long	base+(MMU_SECTION_SIZE*(seg+0x00));

and your 256M_SEGMENT rom fill macro should just call your 16M_SEGMENT
rom fill macro repetitively.

4) flash should have the cacheable bit set. so it should be:

	ROM0_PA|MMU_L1_TYPE_Section|MMU_AP_ANY|MMU_Cacheable

5) not all the chip selects are mapped in. if you attempt to do any i/o,
you should verify that the memory is mapped in correctly in the static
tables.


please feel free to mail me if i left out any of the important details.
:) good luck,

-Dan

> -----Original Message-----
> From: Nicola Bergamin [BW] [ mailto:nicola.bergamin@bluewind.it ]
> Sent: Tuesday, August 07, 2001 9:48 AM
> To: ecos-discuss@sources.redhat.com
> Subject: [ECOS] ROM startup + MMU tables
> 
> 
> Hi,
> Does anybody know about this ROM startup issue?
> 
> i'm trying to use a predefined arm/edb7xxx platform to arrange 
> eCos for my board. (no DRAM, only ROM and internal on-chip 
> SRAM, Cirrus Logic EP7209 derivative)
> 
> I configured with ROM startup, static MMU tables and NO DRAM
> (macro CYGHWR_HAL_ARM_EDB7XXX_DRAM_SIZE==0).
> This macro is used in the vectors.S module, and in 
> hal_platform_extras.h as well.The apparent cause seems to be that 
> putting DRAM size to zero causes MMU_TABLES_SIZE to be 
> undefined!!, thus causing errors in compilation.
> 
> I tried to configure to 16M DRAM size, but memory mapping 
> seems not working in that case.
> 
> Many thanks Nicola
> 
> 
> 
> 
>  
> ------------------------------------------
>  Nicola Bergamin
>  BlueWind Embedded Systems Design
>  Via Steffani, 7/B
>  I-31033 Castelfranco Veneto (TV)
> 
>  Office: +39 0 423 723431
>  Fax   : +39 0 423 744738
>  GSM   : +39 335 7556736
>  mailto:nicola.bergamin@bluewind.it
>  http://www.bluewind.it
> ------------------------------------------
> 
> 

             reply	other threads:[~2001-08-07 10:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-07 10:48 Dan Conti [this message]
2001-08-09  2:41 ` [ECOS] Again: " Nicola Bergamin [BW]
  -- strict thread matches above, loose matches on Subject: below --
2001-08-07  9:46 [ECOS] " Nicola Bergamin [BW]
2001-08-07 10:23 ` Jonathan Larmour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D8DFF0AFE792914996F997E68FEC3A48F312@bunker.iobjects.com \
    --to=danc@iobjects.com \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).