From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Tue, 19 May 2015 22:15:49 +0200 Subject: [U-Boot] [PATCH 04/12] sunxi: Update sunxi-common.h to deal with different DRAM base addr on sun9i In-Reply-To: <1421534659.13341.12.camel@hellion.org.uk> References: <1421333554-29822-1-git-send-email-hdegoede@redhat.com> <1421333554-29822-5-git-send-email-hdegoede@redhat.com> <1421534659.13341.12.camel@hellion.org.uk> Message-ID: <555B99F5.7000702@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Ian, On 01/17/2015 11:44 PM, Ian Campbell wrote: > On Thu, 2015-01-15 at 15:52 +0100, Hans de Goede wrote: >> The DRAM Base differs between sun9i and the others and we cannot use >> math in various places like the environment setting and linker scripts, >> so "simply" define everything which contains the SDRAM_BASE twice. > > Is it really not possible to use maths in linker scripts? How have I > never noticed that... > > Anyway, given that things only differ in the most significant nibble of > the RAM base address I think something like this might work: > > /* NB: find out if one of these is already available somewhere */ > #define __stringify(x) #x > #define stringify(x) __stringify(x) > > #define SDRAM_OFFSET(x) 0x2##x /* or 0x4 */ > #define CONFIG_SYS_SDRAM_BASE SDRAM_OFFSET(0000000) > > #define MEM_LAYOUT_ENV_SETTINGS \ > "kernel_addr_r=" stringify(SDRAM_OFFSET(200000)) "\0" > ... I've finally brushed of these patches and I'm working on cleaning them up now. Unfortunately a lot of the CONFIG_xxx variables with dram base address derived values get exported through cpp -E -dM which does not do macro expansion, and then used in Makefiles to pass to the linker and such. So I've been unable to get big of the #ifdef ... #else ... #endif block setting various defines for this. I've been able to make the environment block use the trick you suggested, so this does give a nice cleanup. Regards, Hans