"Schneider, Kolja" Kolja.Schneider@men.de wrote on 2012/05/03 10:46:55:
If you mean the BDI is trying to initialize things rather than leave the system in its default state, don't do that.
Yes, trying to get there.
Easily done, just throw out everything in the [init] section. Or is this really just about BDI presence, as Scott suggested?
I found the problem, u-boot is somewhat flawed, it requires CONFIG_SYS_MONITOR_BASE to be "base 2 even", must land on a 256K or 512K or 1024K address. I had it to be 400K as I don't want burn >112 KB padding each time we burn an image, debugging takes time as it is. Will be extra fun when u-boot size is bigger than 512K :(
ehh, that should be on a 4MB boundary instead, meaning that CONFIG_SYS_MONITOR_BASE 0xeff80000 works but 0xeff8c000 don't
Being able to separate the bootpg and the rest is one step to avoid burning useless padding.
It is this this code: #if !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SECURE_BOOT) /* create a temp mapping in AS=1 to the 4M boot window */ lis r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@h ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@l
lis r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE, (MAS2_I|MAS2_G))@h ori r8,r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE, (MAS2_I|MAS2_G))@l
/* The 85xx has the default boot window 0xff800000 - 0xffffffff */ lis r9,FSL_BOOKE_MAS3(0xffc00000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@h ori r9,r9,FSL_BOOKE_MAS3(0xffc00000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l
Notice the hardcoded 0xffc00000, that is the culprit here.
On a related matter, I believe that one should be able to have a minimal emulator config that allows you to both program flash efficiently and debug u-boot via BDI/gdb. I have always managed to do this before with our earlier freescale CPUs but now seems hard(impossible?) with the current u-boot design. It is a major pain to change emul config each time you do the burn flash/debug cycle.
Jocke
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot