Anybody,
I ran into a peculiar issue, though it could be user error.
I am using U-boot to configure up the SDRAM and SRAM in our system before we
launch Linux. We have 32 Mb of SDRAM and 2 MB of SRAM in the system.
If I leave the SRAM mapped at higher addresses 0x10000000 and SDRAM at
0x00000000, like U-boot defaults to Linux works great. However, my goal is
to map SRAM <8ns speeds> down to the address 0x00000000, to map the vector
table, so I can achieve a very fast interrupt response time.
I hacked U-boot a little bit to remap these addresses, after all the init
code was finished. U-boot relocates itself to higher memory, i.e. the last
2MB's of SDRAM and all is well within U-boot. I ran a 14 hour test on the
memory area to proof it. Now we have 0x02200000 <34M> memory size being
reported to Linux, in the bd->memsize. However, now Linux crashes randomly
all over the place, mostly sig11's task: swapper. I know this is not an
issue with SDRAM stability, and I can't imagine SRAM having problems seeing
as its 8ns capable and we're running at 15ns at the moment (66mhz).
Linux reports BAT mappings as BAT2=32Mb, BAT3=2MB when all 34 Megs are
presented via U-boot.
Does anyone have any idea what would cause this instability? Physically all
memory seems to be great if used by itself. I know very little about how
Linux manages its pages, BATS, TBLs, etc... Are the limits on odd memory
sizes? Or certain configurations that it expects to see?
Thanks in advance.
-Russell McGuire
I am using U-boot to configure up the SDRAM and SRAM in our system before
we
launch Linux. We have 32 Mb of SDRAM and 2 MB of SRAM in the system.
If I leave the SRAM mapped at higher addresses 0x10000000 and SDRAM at
0x00000000, like U-boot defaults to Linux works great. However, my goal is
to map SRAM <8ns speeds> down to the address 0x00000000, to map the vector
table, so I can achieve a very fast interrupt response time.
Your core is probably running at about 400MHz, so 66MHz SRAM is still slow.
This is what cache is for. Maybe you should look into locking interrupt
code in
cache. Probably, however, you will find that messing with the overall
optimizations
of the kernel will be a net slowdown.
Mark Chambers
On Jul 11, 2005, at 6:38 AM, Absolut Hunter wrote:
..... However, my goal is
to map SRAM <8ns speeds> down to the address 0x00000000, to map the
vector
table, so I can achieve a very fast interrupt response time.
The things Linux does to cause interrupt latencies are going to ensure
you aren't going to see any differences to the "interrupt response
time." :-)
From a system perspective, you are going to be much better off using
your SRAM for CPM data buffering than for any general software use.
Does anyone have any idea what would cause this instability?
Yeah, I can't find a way to actually map the memory as you have
described. You actually have the SRAM and SDRAM multiply mapped
on top of one another, and depending upon which chip selects
are used and the values in their registers, you are selecting between
the two memories. Several cases exist. You are either mapping the
SRAM on top of the SDRAM, or vice versa. You really have only 32M
of memory available, so any access to the "upper" 2M is wrapping
around to the lower memory. Basically, you have a big mess ;-)
You need to map these memories to modulo their size, so to put
the 2M at low memory, you are going to have a hole up to a 32M
boundary before you can map the SDRAM. It's possible to do
this, but not without some custom Linux modifications.
Thanks.
-- Dan