Re: [ECOS] PXA255 - Xscale - Peripheral access question

[Nirmal Prasad <prasad_nirmal at yahoo dot com>]

Hello Daniel,

Sorry I did not have access to the source for a couple
of days. The code I got from the vendor has a
structure that is a little bit different than the
stock builds. The MMU table is initialized from
platform_init [they don't have a hal_mmu_init] and is
provided below.

They also have an SMC Lan91C111 chip located at 0x2180
0000 but I am unable to find a mapping for it as well.
I will also try to contact the vendor and see if they
can point me in the right direction.

Thanks
Nirmal
 
------------------>>>
	.p2align 13
	// the following alignment creates the mmu table at
address 0x4000.
    mmu_table:

	// 1MB of FLASH with i80312 MMRs mapped in using 4K
small pages so we can
	// set the access permission on flash and
memory-mapped registers properly.
	FL_PT_ENTRY mmu_table_flashbase,0

	// Remaining 63MB of FLASH area (Static Chip select
0)
	//   rw, cacheable, non-bufferable
	.set	__base,1
	.rept	0x040-0x001
	FL_SECTION_ENTRY __base,0,3,0,0,1,0
	.set	__base,__base+1
	.endr	
	
	// nothing interesting here, static chip select area
1 (Address Translation)
	.rept	0x080 - 0x040
	FL_SECTION_ENTRY __base,0,3,0,0,0,0
	.set	__base,__base+1
	.endr

	// nothing interesting here, static chip select area
2 (Address Translation)
	.rept	0x0C0 - 0x080
	FL_SECTION_ENTRY __base,0,3,0,0,0,0
	.set	__base,__base+1
	.endr

	// nothing interesting here, static chip select area
3 (Address Translation)
	.rept	0x100 - 0x0C0
	FL_SECTION_ENTRY __base,0,3,0,0,0,0
	.set	__base,__base+1
	.endr

	// nothing interesting here, static chip select area
4 (Address Translation)
	.rept	0x140 - 0x100
	FL_SECTION_ENTRY __base,0,3,0,0,0,0
	.set	__base,__base+1
	.endr

	// nothing interesting here, static chip select area
5 (Address Translation)
	.rept	0x180 - 0x140
	FL_SECTION_ENTRY __base,0,3,0,0,0,0
	.set	__base,__base+1
	.endr

	// nothing interesting here (Address Translation)
	.rept	0xA00 - 0x180
	FL_SECTION_ENTRY __base,0,3,0,0,0,0
	.set	__base,__base+1
	.endr

	// up to 64MB SDRAM
	//   x=c=b=1
	// first 1MB mapped by second level table
	FL_PT_ENTRY mmu_table_rambase,0
	.set	__base,__base+1
	
	// remainder of SDRAM mapped 1-to-1
	.rept	0xC00 - 0xA01
	FL_SECTION_ENTRY __base,1,3,1,0,1,1
	.set	__base,__base+1
	.endr
	
	// Cache flush region.
	// Don't need physical memory, just a cached area.
	.rept	0xD00 - 0xC00
	FL_SECTION_ENTRY __base,0,3,0,0,1,1
	.set	__base,__base+1
	.endr
	
	// Invalid
	.rept	0x1000 - 0xD00
	.word 0
	.set	__base,__base+1
	.endr


	// Immediately after the above table (at 0x8000) is
the
	// second level page table which breaks up the lowest
1MB
	// of physical memory into 4KB sized virtual pages. 
    mmu_table_flashbase:
	// Virtual address 0 (Flash boot code).
	// Map 4k page at 0x00000000 virt --> 0xA0000000
physical
	// This allows us to have a writable vector table.
	//   Read-Write, cacheable, bufferable
	SL_XSMPAGE_ENTRY 0xa0000,1,3,1,1

	// Virtual address 0x1000 (Memory mapped registers)
	// Map 1-to-1, but don't cache or buffer
	//   Read-Write, non-cacheable, non-bufferable       
 
	.set	__base,1		   
	SL_SMPAGE_ENTRY __base,3,3,3,3,0,0
	.set	__base,__base+1

	// Virtual address 0x2000-0x100000 (remainder of
flash1)
	//   Read-Write, cacheable, non-bufferable
	.rept	0x100 - 0x2
	SL_SMPAGE_ENTRY __base,3,3,3,3,1,0
	.set	__base,__base+1
	.endr

	// Now is the second level table for the first
megabyte
	// of DRAM.
    mmu_table_rambase:
	// Map 4k page at 0xa0000000 virt --> 0x00000000
physical
	//   Read-Write, cacheable, non-bufferable
	SL_SMPAGE_ENTRY 0x00000,3,3,3,3,1,0
	.set	__base,__base+1		   

	// Map remainder of first meg of SDRAM
	//   Read-Write, cacheable, non-bufferable
	.set    __base,0xA0001
	.rept	0x100 - 0x1
	SL_XSMPAGE_ENTRY __base,1,3,1,1
	.set	__base,__base+1
	.endr
<<<-------------------
--- Daniel Schmidt <sc_da@gmx.de> wrote:

> > On Sun, 2005-01-02 at 09:22 -0800, Nirmal Prasad
> wrote:
> > > Hello,
> > > 
> > > I am using an xscale module that has redboot on
> it and
> > > I am trying to interface a peripheral at address
> > > 0x34000000 [Socket 1 reserved space]. The
> registers
> > > are supposed to be in this space.
> > > 
> > > When I do a x -b 0x34000000 -l 512 it returns
> 0x00's.
> > > Do I need to setup any kind of mapping for
> access to
> > > the socket 0,socket 1 address space?
> > 
> > Yes. The platform HALs are responsible for setting
> up these sorts of
> > mappings in the page table. Look at
> hal/arm/xscale/{uE250,mpc50}
> > for code that sets up the pxa2x0 pagetable
> (hal_mmu_init()). Neither
> > of those ports use the pcmcia slots and the pcmcia
> areas are not
> > mapped on them.
> > 
> > --Mark
> Hello,
> 
> I think he should get an "data abort" when this
> space is not mapped. 
> (normaly redboot displays this error)
> 
> Nirmal, could you send your memory mappings from
> your hal_platform_setup.h?
> 
> daniel
> 
> -- 
> +++ GMX - die erste Adresse für Mail, Message, More
> +++
> 1 GB Mailbox bereits in GMX FreeMail
> http://www.gmx.net/de/go/mail
> 



		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss