[ixp1200] core locks using IXA SDK
Johnson, Erik J
erik.j.johnson at intel.com
Tue Apr 20 13:17:03 EDT 2004
Hi Tim
Without actually trying it, I suspect you can read from the 0xf5000000 range to issue the read lock. However, that does not guarantee the lock was obtained (see the next 12 lines of code in the same example from the book). For that you will need to poll (and update) the SRAM CSR _without any other process doing the same_. This will require mapping this CSRs physical address into the virtual address space of your application as well as finding some way of making this polling code execute in a system-wide critical section. In the end, you may find that doing this work in the kernel and providing some ioctl/syscall/whatever is easier because of these reasons.
erik
~~~~~~~~~~~~~~~~~~~~~~~~
Erik J. Johnson
erik.j.johnson at intel.com
Not speaking for Intel
~~~~~~~~~~~~~~~~~~~~~~~~
-----Original Message-----
From: ixp1200-bounces at lists.cs.princeton.edu [mailto:ixp1200-bounces at lists.cs.princeton.edu] On Behalf Of Tim Stevens
Sent: Tuesday, April 20, 2004 7:35 AM
To: IXP1200 Developer's List
Subject: RE: [ixp1200] core locks using IXA SDK
Thanks David,
You are right, I was confusing virtual and physical address space.
Meanwhile, I have found the following lines in hardware.h:
#define SRAM_READ_LOCK UNSIGNED(0xf5000000)
#define SRAM_READ_LOCK_SIZE UNSIGNED(0x00800000)
#define SRAM_WRITE_UNLOCK UNSIGNED(0xf5800000)
#define SRAM_WRITE_UNLOCK_SIZE UNSIGNED(0x00800000)
#define SRAM_CAM_UNLOCK UNSIGNED(0xf6000000)
#define SRAM_CAM_UNLOCK_SIZE UNSIGNED(0x00800000)
#define SRAM_CLEAR_BITS UNSIGNED(0xf6800000)
#define SRAM_CLEAR_BITS_SIZE UNSIGNED(0x00800000)
#define SRAM_SET_BITS UNSIGNED(0xf7000000)
#define SRAM_SET_BITS_SIZE UNSIGNED(0x00800000)
#define SRAM_TEST_CLEAR_BITS UNSIGNED(0xf7800000)
#define SRAM_TEST_CLEAR_BITS_SIZE UNSIGNED(0x00800000)
#define SRAM_TEST_SET_BITS UNSIGNED(0xf8000000)
#define SRAM_TEST_SET_BITS_SIZE UNSIGNED(0x00800000)
and the following in board.h:
#define SRAM_BASE UNSIGNED(0xf4000000)
#define RM_SRAM_BASE SRAM_BASE
When an SRAM address is allocated using RmMalloc(...), an address in the 0xf4000000 range is returned (e.g. 0xf400feea). Now I wonder whether it's possible to read from the corresponding 0xf5000000 range (e.g. 0xf500feea) to issue a read-lock. Or would this cause a memory violation, since the malloc allocated memory in the 0xf4000000 range?
If this is not possible, how should one use the presented constants in hardware.h?
Thanks again.
Kind regards,
Tim
At 15:15 20/04/2004, you wrote:
>Hello Tim,
>
>I hope I have understood your issue correctly:
>
> > From: Tim Stevens [mailto:tim.stevens at intec.ugent.be]
> > Sent: Tuesday, April 20, 2004 2:42 PM
>
> > Chapter 7 (p 167) of the IXP1200 programming book states that an
> > SRAM memory read-lock can be obtained by the following command:
> > *(unsigned int *)(SRAM_READ_LOCK + (sramLWAddr << 2)); where
> > sramLWAddr is the physical address in longwords and SRAM_READ_LOCK
> > is defined as follows:
> > #define SRAM_READ_LOCK 0x12000000
> >
> > Quite obviously, this results in a memory violation because the
> > memory was not previously allocated (in the 0x12000000 range).
>
>Your are confusing Physical and Virtual addresses. I don't have the
>IXP1200 book at hand but as far as I can guess, the 0x12000000 is a
>physical one. So you need to open a window, i.e. a virtual address to
>physical address translation, from a virtual address range of your user
>linux program to the 0x12000000 physical address range.
>
>The simplest way, in my humble opinion, is to mmap(2) the /dev/mem
>device that corresponds to physical address space. You'll find an
>example of such a program at:
>http://www.lart.tudelft.nl/lartware/port/devmem2.c
>
> > A related problem we face is that our addresses allocated in SRAM
> > (by
> > RmMalloc) seem to have a virtual address starting with 0xf400....,
> > which does not correspond to the 10000000-->107fffff range presented
> > in the "StrongARM Core Memory Map" (appendix C) from the "Microcode
> > Programmer's Reference Manual".
>
>I think that once again your are confusing physical and virtual addresses.
>
>
>Yours,
>david
>--
>David Mentré <mentre at tcl.ite.mee.com> - Research engineer (Ph.D.)
>Mitsubishi Electric ITE-TCL / European Telecommunication Research Lab
>Phone: +33 2 23 45 58 29 / Fax: +33 2 23 45 58 59
>http://www.mitsubishi-electric-itce.fr
>_______________________________________________
>ixp1200 mailing list
>ixp1200 at lists.cs.princeton.edu
>https://lists.cs.princeton.edu/mailman/listinfo/ixp1200
_______________________________________________
ixp1200 mailing list
ixp1200 at lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/ixp1200
More information about the ixp1200
mailing list