From mboxrd@z Thu Jan 1 00:00:00 1970 From: Troy Kisky Date: Mon, 24 Sep 2012 14:18:31 -0700 Subject: [U-Boot] [PATCH V2 05/21] imximage: add expression evaluation In-Reply-To: <505F2301.4080306@denx.de> References: <1348012989-19674-1-git-send-email-troy.kisky@boundarydevices.com> <1348281558-19520-1-git-send-email-troy.kisky@boundarydevices.com> <1348281558-19520-6-git-send-email-troy.kisky@boundarydevices.com> <505F2301.4080306@denx.de> Message-ID: <5060CE27.5000404@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 9/23/2012 7:56 AM, Stefano Babic wrote: > On 22/09/2012 04:39, Troy Kisky wrote: >> Basic expressions with order precedence is >> now supported. >> ie. (----3 + ((1+2*3)/--2 + --5 *(8/4))) is 16. >> >> Signed-off-by: Troy Kisky >> --- > Hi Troy, > >> tools/imximage.c | 172 ++++++++++++++++++++++++++++++++++++++++++++++++++---- >> 1 file changed, 162 insertions(+), 10 deletions(-) >> >> diff --git a/tools/imximage.c b/tools/imximage.c >> index 1e120354..2c5a622 100644 > I have some general considerations. First, if you plan to add support > for expression evaluation, this feature should be available generally > for mkimage, that means also other processors / architecture can profit > of it. It should be moved away from imximage.c code. That makes sense. > > Then, you want also let that the preprocesso can parse the imximage > code. I can imagine that in such terms it could be then possible to > define in imximage.cfg something like: > > #define DDR_VAL (1 <<17 | 3 << 7) > #define ADDRESS 0x0x53something > > DATA 4 ADDRESS DDR_VAL > > Else, why do we need the power of C preprocessor ? > > If this is true, can you explain us which is the use case using the C > preprocessor and which is the one for the expression evaluator ? And why > do we need both ? > > > I want to easily switch from plugins back to the normal DCD list method. #ifdef 's and and #define's make this possible. Plus the cfg file is more readable with #define's. But if plugins are rejected, expressions aren't as important. I can still see a cfg file doing DATA 4, MMDC_P0 + MMDC_MPZQHWCTRL, 0xA1380003 DATA 4, MMDC_P1 + MMDC_MPZQHWCTRL, 0xA1380003 patch 09/21 mx6q_4x_mt41j128.cfg: use symbols instead of hardcoded constants has +#define MA(mx6q, mx6dl_solo, mx6sololite) ((mx6q / 4 & 0x3ff) | \ + ((mx6dl_solo / 4 & 0x3ff) * 0x400) | \ + ((mx6sololite / 4 & 0x3ff) * 0x100000)) + +#define IOM_DRAM_DQM0 MA(0x5ac, 0x470, 0x0) +#define IOMUX_ADDR(addr, div) (IOMUXC_BASE_ADDR + \ + ((((addr) / (div)) & 0x3ff) * 4)) +#define IOMUX_ENTRY1(addr, q) DATA 4, IOMUX_ADDR(addr, _FOR_DIV), q +#define WRITE_ENTRY1(addr, q) DATA 4, addr, q +#ifdef FOR_MX6Q +#define _FOR_DIV 1 +#define IOMUX_ENTRY2(addr, q, dl) IOMUX_ENTRY1(addr, q) +#define WRITE_ENTRY2(addr, q, dl) WRITE_ENTRY1(addr, q) to choose which offset for IOM_DRAM_DQM0 should be selected.