"Schneider, Kolja" <kolja.schnei...@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 :(
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
