Monday, May 10, 2004
LAN91C111 Driver for XScale
Our XScale CPU based platform has engaged two LAN91C111 chips for the Ethernet function. We got the driver for LAN91C111 from SMSC, but it doesn't works very well. The speed is slow, sometime it will lock up while transfer data from a network share folder.
After debugging, we found the driver will get lots of RCV_OVERRUN_INTs (receiving overrun interrupts) while transferring data. It's means transferring data from LAN91C111 chip to system memory is not fast enough.
Since some developers ever mentioned utilizing XScale DMA channel to transfer data from LAN91C111 chip to system memory will solve such problem, we have tried using DMA to transfer the data.
Currently we have added DMA data transfer code in the driver, but so far it now works. we found when we transferring data from one memory loaction to another via DMA , it works fine. But if we transferring data from LAN91C111 Data port to system memory, the data is not correct. I'll try to figure out why that happened.
After debugging, we found the driver will get lots of RCV_OVERRUN_INTs (receiving overrun interrupts) while transferring data. It's means transferring data from LAN91C111 chip to system memory is not fast enough.
Since some developers ever mentioned utilizing XScale DMA channel to transfer data from LAN91C111 chip to system memory will solve such problem, we have tried using DMA to transfer the data.
Currently we have added DMA data transfer code in the driver, but so far it now works. we found when we transferring data from one memory loaction to another via DMA , it works fine. But if we transferring data from LAN91C111 Data port to system memory, the data is not correct. I'll try to figure out why that happened.
Saturday, May 01, 2004
StrongARM CPU with 64MB RAM
Hi All,
I got a very odd problem on my StrongARM CPU based WinCE 4.1 system. Originally the platform has 32MB RAM and the physical starting address of the RAM is 0xC000000 and it works fine. Later we changed the RAM chip to 64MB one, I have modified the config.bib and OEMAddressTable to reflect the changes, but the image that I build can't startup!
For the 32MB RAM , the physical address region is : 0xC0000000~0xC1FFFFFF;
For the 64MB RAM, the physical address region is : 0xC0000000~0xC3FFFFFF;
In the OEMAddressTable, I do mapped whole 64MB RAM, and in config.bib I changed RAM setting
from:
RAM 8C140000 01EC0000 RAM
To:
RAM 8C140000 03EC0000 RAM
But it just not works. I can't imagine why that happened.
I can guarantee in the OEMAddressTable, there's no overlapping after I do the 64MB RAM mapping. And the hardware also don't have a problem. Because if I only modified OEMAddressTable and not made any change to config.bib , the image will still running, just we can only see 32MB RAM available. And if at this time we are using following code to map additional 32MB RAM to a virtual address, we can do read/write with the additional 32MB RAM without a problem.
void* pRAMBase = (void*)VirtualAlloc(0, 0x01000000, MEM_RESERVE, PAGE_NOACCESS);
VirtualCopy((PVOID)pRAMBase , (LPVOID)(0xC2000000>>8), x01000000,PAGE_READWRITE|PAGE_NOCACHE|PAGE_PHYSICAL)
BTW. I've ever do the similar thing on a XScale platform and everything works fine after I extented the memory setting.
Anyone can tell me which part that I missed regarding this issue?
Thanks a lot!
Xu Jun
---------------------------------------------------------------------------------
Sounds to me like the RAM is not configured correctly in hardware. I'd double check the RAM is operating with a simple test from the boot loader before the MMU is turned on.
--
Steve Maillet (eMVP)
EmbeddedFusion
smaillet_AT_EmbeddedFusion_DOT_com
--------------------------------------------------------------------------------
Thanks Steve. I solved the problem. YES, It's the memory controller register setting issue that cause the problem.
Since we only replaced 32MB DRAM chip with a 64MB one, and I thought the current hardware setting should works. But the fact is the 64MB RAM has different internal structure than the 32MB one. Inside SA1110 DRAM configuration register (MDCNFG), there are three bits DRAC0<2:0> used to set DRAM row address bit count. Different size DRAM , need different setting. After changing settings for those bits then we can see the whole 64MB RAM in the system
Xu Jun
I got a very odd problem on my StrongARM CPU based WinCE 4.1 system. Originally the platform has 32MB RAM and the physical starting address of the RAM is 0xC000000 and it works fine. Later we changed the RAM chip to 64MB one, I have modified the config.bib and OEMAddressTable to reflect the changes, but the image that I build can't startup!
For the 32MB RAM , the physical address region is : 0xC0000000~0xC1FFFFFF;
For the 64MB RAM, the physical address region is : 0xC0000000~0xC3FFFFFF;
In the OEMAddressTable, I do mapped whole 64MB RAM, and in config.bib I changed RAM setting
from:
RAM 8C140000 01EC0000 RAM
To:
RAM 8C140000 03EC0000 RAM
But it just not works. I can't imagine why that happened.
I can guarantee in the OEMAddressTable, there's no overlapping after I do the 64MB RAM mapping. And the hardware also don't have a problem. Because if I only modified OEMAddressTable and not made any change to config.bib , the image will still running, just we can only see 32MB RAM available. And if at this time we are using following code to map additional 32MB RAM to a virtual address, we can do read/write with the additional 32MB RAM without a problem.
void* pRAMBase = (void*)VirtualAlloc(0, 0x01000000, MEM_RESERVE, PAGE_NOACCESS);
VirtualCopy((PVOID)pRAMBase , (LPVOID)(0xC2000000>>8), x01000000,PAGE_READWRITE|PAGE_NOCACHE|PAGE_PHYSICAL)
BTW. I've ever do the similar thing on a XScale platform and everything works fine after I extented the memory setting.
Anyone can tell me which part that I missed regarding this issue?
Thanks a lot!
Xu Jun
---------------------------------------------------------------------------------
Sounds to me like the RAM is not configured correctly in hardware. I'd double check the RAM is operating with a simple test from the boot loader before the MMU is turned on.
--
Steve Maillet (eMVP)
EmbeddedFusion
smaillet_AT_EmbeddedFusion_DOT_com
--------------------------------------------------------------------------------
Thanks Steve. I solved the problem. YES, It's the memory controller register setting issue that cause the problem.
Since we only replaced 32MB DRAM chip with a 64MB one, and I thought the current hardware setting should works. But the fact is the 64MB RAM has different internal structure than the 32MB one. Inside SA1110 DRAM configuration register (MDCNFG), there are three bits DRAC0<2:0> used to set DRAM row address bit count. Different size DRAM , need different setting. After changing settings for those bits then we can see the whole 64MB RAM in the system
Xu Jun
