Hi Andreas, On Fri, 06 Jul 2012 12:25:00 +0200, "Andreas Bießmann" <andreas.de...@googlemail.com> wrote: > Dear Yann Vernier, > > On 06.07.2012 11:14, Yann Vernier wrote: > > On Friday 06 July 2012 10:43:40 you wrote: > >>>>> =((CONFIG_SYS_SDRAM_BASE+CONFIG_SYS_SDRAM_SIZE-0x10000)<<(22-16) | \ + > >>>>> (CONFIG_SYS_SDRAM_BASE>>(16-12) | 0x00e)) > >>>> > >>>> ugh ... magic. Will it work for every possible setting? > >>>> How about one setting CONFIG_SYS_SDRAM_BASE != 0x0? I the base address > >>>> related to register content in any way? > >>> > >>> It's not a guarded secret, although it is far from obvious where to find > >>> it. One way is micrel.com - Products - Ethernet ICs / ARM based SOC's - > >>> HW Design Kit. Within that zip file, > >>> KS8695X_EVAL_HW_RV4.0_DP/RegDescription/KS8695X Register Description > >>> v1.1.pdf > >> > >> With this information I understand your equation. I think you should not > >> do it that way. You may solve the current state (all devices have 8 > >> column, 4 bank and 32 bit). But one adding (well, if that will ever come > >> ;) another board with different setting will get in trouble here and > >> need to find another solution. Maybe more sophisticated by doing another > >> equation. > >> > >> I think a straight forward solution here would be to add another special > >> define in the board config, write the magic number down there and maybe > >> describe what the number stands for. You can then just use the > >> previously defined value in start.S. > >> You may have a look for at91 lowlevel_init, there it is done that way. > > > > I shall. In fact, I may already have this problem as I need to verify the > > timing on the flash memory (I have the demo board, not a cm4xxx), and the > > reason I work on this is that we may design another board soon. > > > > I'm a little hesitant about how to fit these changes together, though; for > > now > > I have three barely separated patches, but overhauling all those magic > > numbers > > changes them all yet again. These three patches are all necessary to make > > my > > u-boot work in the first place, while fixing the magic values is a code > > cleanup > > change - probably editing arch/arm/include/asm/arch-ks8695/platform.h which > > currently contains a few meaningless constants like KS8695_SDRAM_START and > > a > > consistent misspelling of definitions. > > > > Could I save the value decoding and corresponding configuration changes for > > a > > fourth patch? > > I'm fine with this suggestion. > So the next question is who would pull it in mainline? Since this is arm > related I guess Albert is the one in question.
Ah, board-related patches. :) > I think these three patches are all fixes to get a board already in > mainline working. So I think we should try to get these in -rc1. > Albert, can you please comment? If the cm4008/cm41xx board maintainer (as per MAINTAINERS, this is Greg Ungerer, Cc:) green-lights it, then I'm ok for pulling it in. > Best regards > > Andreas Bießmann Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
