Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Ok, I see the reason - kernel booting resets EMIFA setups. Is there any way to prevent it than?

What version of the kernel are you using?

2.6.34

Does anybody use DSP-EMIFA-FPGA communication with DSP using no OS?

I wrote that kernel resets EMIFA setups - I mean CCS debug starts to show 0's for EMIFA registers and for other peripherals' registers as well. I setup a test code - some registers periodical reading (SYSCFG0_REVID_REG, SYSCFG0_DEVIDR0_REG, EMIFA_MIDR_REG, PSC0_MDSTAT0_REG+3 (EMIFA status)). Before kernel booting all registers reading returns correct values. Starting from some point during kernel booting EMIFA_MIDR_REG reading starts to return a wrong value. And the same story with ARM-core.

Could it be related to caching?

u-Boot is the only software (as opposed to the kernel) that should be modifying the EMIFA registers if you are using 2.6.34 from Critical Link.

The EMIFA registers are not cached. The SYSCFG registers may be modified by the kernel when it boots.

The kernel might be altering the pin-mux settings for the CS4 pin (though it should not be if you are using the kernel provided by CL).

Do you have an FPGA loaded when you are running this test?

Michael, I have simplified the setup: as I wrote, now DSP-core reads just several registers and EMIFA_MIDR_REG which holds constant returns wrong value after kernel booting, but others are correct. So my problem is not related to FPGA. And yes, I do use CL's kernel.

Hmmm.

The MIDR is read only, it cannot be changed by any software. I haven't seen behavior like this before.

Are you reading this value using the JTAG debugger and code composer studio? How are you reading the value? It is possible that the JTAG connection is being reset when you allow the processor to boot?

We have not observed this issue here. Can you provide specific instructions to reproduce the problem?

E.G., is this what you are doing? Can you tell me if this is correct?

1) Reset Process and stop at u-boot.
2) Connect to DSP (or ARM?) with JTAG emulator via CCS
3) Load GEL file.
4) open memory window and look at MIDR register (0x68000000), observe 0x40000205
5) on u_boot, type "boot" allowing linux to load.
6) refresh memory window, MIDR is now changed from 0x40000205

Or are you running a DSP application?

-Mike

Mike, yes, I do like that and observe both - memory window and regs tab in CCS and my test program does an output via UART. CCS shows 0's after kernel is being booting but my program returns another value, different from 0 but not 0x40000205. That value is constant and doesn't change after power off - power on. The only difference with your scenario - I do not use any GEL-file, I don't think it is important because all the initialization is done after power on by UBL.

Hello!

I have found a root of the problem - EMIFA goes to Disable state during kernel booting. Previously I have being reading EMIFA MDSTAT3 reg, BUT I made a mistake and used wrong offset for the register's address, though I read another modules state and it was Enabled. That confused me.

Now I re-enable EMIFA from DSP-core application and everything is fine.

Thanks!