Hi, Josh:
I have double checked, mmap64 doesn't work either. This is the piece of
code which does re-mapping:
unsigned long long StartAddressL = 0x100000000ULL | StartAddress;
mmap_addr = (unsigned int) mmap64(NULL,
size,
PROT_READ | PROT_WRITE,
MAP_SHARED,
dev_mem_fd,
StartAddressL);
While in GDB I can see variables' values:
(gdb) p/x mmap_addr
$1 = 0x30028000
(gdb) p/x StartAddressL
No symbol "StartAddressL" in current context.
(gdb) p/x StartAddress
$2 = 0xfc240000
(gdb) p/x size
$3 = 0x60000
(gdb)
This call returns successfully, but when I stop the board and dump TLB
entries (I have BDI2000 connected) on BDI2000 screen, there is no entry
with this physical address.
However when I also do re-mapping (using ioremap64()) in kernel driver
(physical address is different - 0xea000000), this is the code:
if((mcfp_ebi_baseptr = ioremap64 (0x1ea000000ULL, 512)) == NULL) {
...
When I stop in debugger right after remapping, TLB entry shows up but
somewhat non-completed yet:
10 : 00 00000000 1KB -0 -> 1_ea000000 U:0000 -I-G- XWRXWR
Later, when I stop board right BEFORE actual accessing memory, the entry
is
present:
23 : 00 d1050000 4KB V0 -> 1_ea000000 U:0000 -IMG- ----WR
And kernel driver is working.
So something is definitely wrong with mmap/mmap64 call itself. Should I
use different parameters?
Thanks,
Leonid.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Leonid
Sent: Wednesday, April 02, 2008 3:51 PM
To: Josh Boyer
Cc: [email protected]
Subject: RE: Access physical memory via mmap() on ppc440epx.
Hi, Josh:
I have resolved my kernel driver problem, it was my own bug, didn't have
anything to do with memory remapping itself. Your suggestion to move to
ioremap64() did resolve problem completely.
I still need investigate mmap() crash. Apparently switch to mmap64()
didn't help, but it could be some another bug, I'll double check.
Thanks,
Leonid.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Leonid
Sent: Tuesday, April 01, 2008 9:30 PM
To: Josh Boyer
Cc: [email protected]
Subject: RE: Access physical memory via mmap() on ppc440epx.
Hi, Josh:
Thank you for your suggestion. Somehow it didn't work with mmap (may be,
my mistake, I'll double check), however it partially helped me with my
another problem.
I have kernel driver where I need read/write some HW device, connected
on address 0xea000000, chip select 4. This chip select configured
properly, here are EBC registers:
440EPx>rd ebc0_b4cr
ebc0_b4cr: 0xea01a000 -368992256
440EPx>rd ebc0_b4ap
ebc0_b4ap: 0x03037000 50556928
>From u-boot I can read/write this address with no problem (I use md/mw
commands).
In my driver I tried to ioremap() this address and any attempt to access
led to crash, same as with mmap().
When, following your suggestion, I used address 0x1ea00000 and
ioremap64(), crashes disappeared!
I even can write, but when I read data back I see least significant byte
of each 16 bits word only (bus is configured 16 bits width).
What can it be?
Thanks,
Leonid.
-----Original Message-----
From: Josh Boyer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 6:44 PM
To: Leonid
Cc: [email protected]
Subject: Re: Access physical memory via mmap() on ppc440epx.
On Tue, 2008-04-01 at 14:12 -0700, Leonid wrote:
> Hi:
>
> I am trying to read from NOR flash, located on address 0xfc000000, on
my
It's at 0x1fc000000 IIRC.
> TLB entries look strange though. That what it was on u-boot stage:
>
> 440EPx>tlb 0 10
> IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
> 0 : 00 40000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 2 : 00 c0000000 256MB V0 -> 1_c0000000 U:0000 -I-G- XWRXWR
> 3 : 00 f0000000 256MB V0 -> 1_f0000000 U:0000 WI-G- XWRXWR
See. Virtual is 0xf0000000, physical is 0x1f0000000.
> On Linux stage it looks rather different:
I don't even see your entry in here. Likely because the TLB is small
and it's gone by the time you do the dump
> Probably under MMU it should look this way? How to use mmap() then?
Try mmap64 on the real physical address and see if that helps.
josh
_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
