public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Mem maps and mmu for iq80310
@ 2001-03-29 18:09 Ashwin Kamath
  2001-03-30  5:05 ` Mark Salter
  0 siblings, 1 reply; 4+ messages in thread
From: Ashwin Kamath @ 2001-03-29 18:09 UTC (permalink / raw)
  To: ecos-discuss

The mlt_arm_iq80310_*.h files probably calculate the Heap sizes
incorrectly. Probably the caculations are based on the assumption that
RAM always starts at Address 0??
I was also wondering why the mmu page tables are being setup so that the
first 1MB of SDRAM is cached and not buffered, while the rest is cached
and buffered. I did not see any difference in the way the first 1MB is
used.

-Thanks
Ashwin.
begin:vcard 
n:Kamath;Ashwin
x-mozilla-html:FALSE
org:OmegaBand Inc
adr:;;;;;;
version:2.1
email;internet:kamath@OmegaBand.com
x-mozilla-cpt:;0
fn:Ashwin Kamath
end:vcard

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Mem maps and mmu for iq80310
  2001-03-29 18:09 [ECOS] Mem maps and mmu for iq80310 Ashwin Kamath
@ 2001-03-30  5:05 ` Mark Salter
  2001-04-02  9:07   ` Ashwin Kamath
  0 siblings, 1 reply; 4+ messages in thread
From: Mark Salter @ 2001-03-30  5:05 UTC (permalink / raw)
  To: kamath; +Cc: ecos-discuss

>>>>> Ashwin Kamath writes:

> This is a multi-part message in MIME format.
> --------------13D78EACDC6C11434E7ECEC6
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit

> The mlt_arm_iq80310_*.h files probably calculate the Heap sizes
> incorrectly. Probably the caculations are based on the assumption that
> RAM always starts at Address 0??

Yes, I ran across the same problem this week. Here is the patch:

Index: hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_ram.h
===================================================================
RCS file: /home/cvs/ecc/ecc/hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_ram.h,v
retrieving revision 1.1
diff -u -p -5 -r1.1 mlt_arm_iq80310_ram.h
--- hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_ram.h	2000/10/27 04:39:44	1.1
+++ hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_ram.h	2001/03/30 12:52:31
@@ -12,11 +12,10 @@
 #define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
 #ifndef __ASSEMBLER__
 extern char CYG_LABEL_NAME (__heap1) [];
 #endif
 #define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
-#define CYGMEM_SECTION_heap1_SIZE (0xf00000 - (size_t) CYG_LABEL_NAME (__heap1))
+#define CYGMEM_SECTION_heap1_SIZE (0xa2000000 - (size_t) CYG_LABEL_NAME (__heap1))
 #ifndef __ASSEMBLER__
 extern char CYG_LABEL_NAME (__pci_window) [];
 #endif
-//#define CYGMEM_SECTION_pci_window (CYG_LABEL_NAME (__pci_window))
-//#define CYGMEM_SECTION_pci_window_SIZE (0x100000)
+
Index: hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_rom.h
===================================================================
RCS file: /home/cvs/ecc/ecc/hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_rom.h,v
retrieving revision 1.1
diff -u -p -5 -r1.1 mlt_arm_iq80310_rom.h
--- hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_rom.h	2000/10/27 04:39:44	1.1
+++ hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_rom.h	2001/03/30 12:52:31
@@ -15,11 +15,7 @@
 #define CYGMEM_REGION_rom_ATTR (CYGMEM_REGION_ATTR_R)
 #ifndef __ASSEMBLER__
 extern char CYG_LABEL_NAME (__heap1) [];
 #endif
 #define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
-#define CYGMEM_SECTION_heap1_SIZE (0x1f00000 - (size_t) CYG_LABEL_NAME (__heap1))
-#ifndef __ASSEMBLER__
-extern char CYG_LABEL_NAME (__pci_window) [];
-#endif
-// #define CYGMEM_SECTION_pci_window (CYG_LABEL_NAME (__pci_window))
-// #define CYGMEM_SECTION_pci_window_SIZE (0x100000)
+#define CYGMEM_SECTION_heap1_SIZE (0xa2000000 - (size_t) CYG_LABEL_NAME (__heap1))
+


> I was also wondering why the mmu page tables are being setup so that the
> first 1MB of SDRAM is cached and not buffered, while the rest is cached
> and buffered. I did not see any difference in the way the first 1MB is
> used.

The first 1MB of SDRAM is cached and buffered. There is a comment in the code that
says otherwise, but the comment is wrong.

--Mark

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Mem maps and mmu for iq80310
  2001-03-30  5:05 ` Mark Salter
@ 2001-04-02  9:07   ` Ashwin Kamath
  2001-04-02 10:10     ` Jonathan Larmour
  0 siblings, 1 reply; 4+ messages in thread
From: Ashwin Kamath @ 2001-04-02  9:07 UTC (permalink / raw)
  To: Mark Salter; +Cc: ecos-discuss

Mark Salter wrote:
> 
> >>>>> Ashwin Kamath writes:
> 
> > This is a multi-part message in MIME format.
> > --------------13D78EACDC6C11434E7ECEC6
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> 
> > The mlt_arm_iq80310_*.h files probably calculate the Heap sizes
> > incorrectly. Probably the caculations are based on the assumption that
> > RAM always starts at Address 0??
> 
> Yes, I ran across the same problem this week. Here is the patch:
> 
> Index: hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_ram.h
> ===================================================================
> RCS file: /home/cvs/ecc/ecc/hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_ram.h,v
> retrieving revision 1.1
> diff -u -p -5 -r1.1 mlt_arm_iq80310_ram.h
> --- hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_ram.h       2000/10/27 04:39:44     1.1
> +++ hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_ram.h       2001/03/30 12:52:31
> @@ -12,11 +12,10 @@
>  #define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
>  #ifndef __ASSEMBLER__
>  extern char CYG_LABEL_NAME (__heap1) [];
>  #endif
>  #define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
> -#define CYGMEM_SECTION_heap1_SIZE (0xf00000 - (size_t) CYG_LABEL_NAME (__heap1))
> +#define CYGMEM_SECTION_heap1_SIZE (0xa2000000 - (size_t) CYG_LABEL_NAME (__heap1))
>  #ifndef __ASSEMBLER__
>  extern char CYG_LABEL_NAME (__pci_window) [];
>  #endif
> -//#define CYGMEM_SECTION_pci_window (CYG_LABEL_NAME (__pci_window))
> -//#define CYGMEM_SECTION_pci_window_SIZE (0x100000)
> +
> Index: hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_rom.h
Gee thanks Mark. This solved my problems. Is there a mechanism to change
the HEAP END without having to touch the ecos sources? The patch that
you gave changes the heap end to the last location of SDRAM. I might
want to change this, so that I can allocate large buffers for sharing
with devices and I have to change the page tables for this. This also
means that the heap needs to end well short of SDRAM. ecos.db did not
have this option as far as I could see. Does having such a mechanism
seem valuable?

-Ashwin.


> ===================================================================
> RCS file: /home/cvs/ecc/ecc/hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_rom.h,v
> retrieving revision 1.1
> diff -u -p -5 -r1.1 mlt_arm_iq80310_rom.h
> --- hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_rom.h       2000/10/27 04:39:44     1.1
> +++ hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_rom.h       2001/03/30 12:52:31
> @@ -15,11 +15,7 @@
>  #define CYGMEM_REGION_rom_ATTR (CYGMEM_REGION_ATTR_R)
>  #ifndef __ASSEMBLER__
>  extern char CYG_LABEL_NAME (__heap1) [];
>  #endif
>  #define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
> -#define CYGMEM_SECTION_heap1_SIZE (0x1f00000 - (size_t) CYG_LABEL_NAME (__heap1))
> -#ifndef __ASSEMBLER__
> -extern char CYG_LABEL_NAME (__pci_window) [];
> -#endif
> -// #define CYGMEM_SECTION_pci_window (CYG_LABEL_NAME (__pci_window))
> -// #define CYGMEM_SECTION_pci_window_SIZE (0x100000)
> +#define CYGMEM_SECTION_heap1_SIZE (0xa2000000 - (size_t) CYG_LABEL_NAME (__heap1))
> +
> 
> > I was also wondering why the mmu page tables are being setup so that the
> > first 1MB of SDRAM is cached and not buffered, while the rest is cached
> > and buffered. I did not see any difference in the way the first 1MB is
> > used.
> 
> The first 1MB of SDRAM is cached and buffered. There is a comment in the code that
> says otherwise, but the comment is wrong.
> 
> --Mark
begin:vcard 
n:Kamath;Ashwin
x-mozilla-html:FALSE
org:OmegaBand Inc
adr:;;;;;;
version:2.1
email;internet:kamath@OmegaBand.com
x-mozilla-cpt:;0
fn:Ashwin Kamath
end:vcard

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Mem maps and mmu for iq80310
  2001-04-02  9:07   ` Ashwin Kamath
@ 2001-04-02 10:10     ` Jonathan Larmour
  0 siblings, 0 replies; 4+ messages in thread
From: Jonathan Larmour @ 2001-04-02 10:10 UTC (permalink / raw)
  To: Ashwin Kamath; +Cc: Mark Salter, ecos-discuss

Ashwin Kamath wrote:
> 
> > Index: hal/arm/iq80310/current/include/pkgconf/mlt_arm_iq80310_rom.h
> Gee thanks Mark. This solved my problems. Is there a mechanism to change
> the HEAP END without having to touch the ecos sources? The patch that
> you gave changes the heap end to the last location of SDRAM. I might
> want to change this, so that I can allocate large buffers for sharing
> with devices and I have to change the page tables for this. This also
> means that the heap needs to end well short of SDRAM. ecos.db did not
> have this option as far as I could see. Does having such a mechanism
> seem valuable?

You need to change the memory layout from within the configuration tool.
The problem Mark fixed was just that the .h file generated was not in sync
with the real memory layout information. So if you just regenerate the
memory layout that should be fine, and does not involve changing the eCos
sources.

If you then need to change the size of the heap to allow for device
buffers, you can do this in the memory layout tool as well.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-04-02 10:10 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-03-29 18:09 [ECOS] Mem maps and mmu for iq80310 Ashwin Kamath
2001-03-30  5:05 ` Mark Salter
2001-04-02  9:07   ` Ashwin Kamath
2001-04-02 10:10     ` Jonathan Larmour

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).