On Mon, Nov 19, 2012 at 11:58:24PM +0100, Wolfgang Denk wrote:
Dear Wolfgang and All,
I'm glad my initial suspicions were right. Can you please post some hints / patches what needs to be fixed, and where?
Sorry for the late reply. I damaged a gpio port of the board and still re-soldering a better one for my tests.
Issues was related to my "board.h" only, and maybe related to mcf5307 support, that i am trying add to u-boot.
mcf5307 seems to have someway a special case for the cache. It has a 8KB unified instruction+data cache, that seems to be the same, and this is quite oddly, of V.2 mcf5249.
As a first point, my board.h was not configuring any sdram cache-enabled address area. This was probably causing a very slow non-cached code execution and non-cached data read/write. In this case execution is a bit faster changing -Os to -O2.
So i enabled the sdram cache with:
#define CONFIG_SYS_CACHELINE_SIZE 16
#define ICACHE_STATUS (CONFIG_SYS_INIT_RAM_ADDR + \ CONFIG_SYS_INIT_RAM_SIZE - 8) #define DCACHE_STATUS (CONFIG_SYS_INIT_RAM_ADDR + \ CONFIG_SYS_INIT_RAM_SIZE - 4) #define CONFIG_SYS_ICACHE_INV (CF_CACR_CINVA) #define CONFIG_SYS_CACHE_ACR0 (CF_ACR_CM_WT | CF_ACR_SM_ALL | \ CF_ACR_EN) #define CONFIG_SYS_CACHE_ICACR (CF_CACR_DCM_P | CF_CACR_ESB | \ CF_CACR_EC)
Still, had to use "write-through", becouse "copyback" need also a "flush" (m68k "cpushl") that is still not iplemented in u-boot for m68k (it seems to be a to-do).
Finally, i had to remove every mask from ACR (CF_ADDRMASK(x) macro) since was causing for my case a complete block after cache initialization. For this, i looked uClinu cache init, but still have to understand clearly why the mask setup block the boot. I will clarify this as soon i have a new board running and will post back.
Best Regards, Angelo Dureghello