MCF54450, SDRAM signals are switched, workaround?

[KyleFromBullex]

Hello everyone,

My coworkers and I have a custom-made PCB with two 54450 processors on it, each with its own SDRAM chip. However, there was a mistake in designing the PCB, and the SDRAM's DM signals are switched (DM3 on the processor goes to DM2 on the RAM, and vice versa.) As a result, all byte writes to the RAM are swapped. For example, writing 0x12 to location 0x40000000 and 0x34 to 0x40000001 swaps these two values, meaning 0x40000000 returns 0x34 and 0x40000001 returns 0x12. Word and longword writes still work correctly.

This is obviously not suitable for running code that does anything useful. The mistake will obviously be fixed in the next revision of the board, but that could be months from now, meaning our project could be dead in the water for months. I've been asked to find a workaround in the meantime. Using only the internal SRAM is not an option, because we are running a full-blown Linux operating system, and the SRAM is only 32KB, nowhere near enough to support the kernel and all of our applications. So, I have to find a way to make this hostile RAM environment work.

We've tried manually re-soldering the connections on the PCB, but this has created other problems with the RAM, so I have to find a way to do it in software. Is there a configuration register somewhere that will cause the processor to swap addresses whenever it tries to do a byte write to the SDRAM? I'm starting to think this is an impossible problem to solve without fixing the DM signals the way they should be, but I was hoping somebody might have a solution. Thanks.

Kyle

[TomE]

> and the SDRAM's DM signals are switched

Someone didn't understand "big endian" then?

> As a result, all byte writes to the RAM are swapped.

I'm surprised. Swapping the DQM signals swaps which LANE of the 16 bits gets written.

If you're seeing true byte-swaps then when you write a byte to the memory it must be putting the same data on both lanes.

> but I was hoping somebody might have a solution

You could program the ACR that covers the SDRAM to make the memory read-only and then trap and emulate every write. Might slow it down slightly...

There's an easier way. Just don't ever have the memory controller write bytes to the memory.

For accesses from the CPU that's simple. Just enable the cache in "Cacheable Copyback" mode. When you do that the CPU only ever reads full cache lines from the memory and (importantly for you) only ever WRITES full cache lines too.

If anything in the Linux startup or running code enables "Cache Inhibited" or "Cacheable Write-through" mode so some or all of the DRAM it will write the wrong bytes. So find all code in the whole distribution that writes to the CACR and ACRn registers and make sure it uses this mode. I would expect Linux should run "Copyback" and flush/purge DMA buffers when required.

Your next problem involves the DMA controllers. They read and write the memory directly, so any of them set up to perform byte writes are going to cause you problems. You may want to try to rewrite any problematic drivers to use programmed I/O for now.

If you have DMA peripherals you have to run and can't force not to perform byte writes, then put their buffers in your SRAM. If the FEC gives you problems, put its ring/control structures in SRAM.

Your main problem is probably going to be whatever bootstrap you are using. It may run with caches disabled and do byte writes. You should be able to find those, or work out how to enable the cache during the boot.

Tom

> We've tried manually re-soldering the connections on the PCB, but this has created other problems

Like what? I can't imagine what would go wrong with this. Find someone who is REALLY GOOD at this and let them try. It is amazing what some people can do with a soldering iron.

If you're getting timing errors with  the pins swapped, then just slow down the memory bus for now. Running slower avoids a lot of problems.