From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Thu, 31 Mar 2011 11:02:21 +0200 Subject: [U-Boot] [PATCH] ftsmc020: enhance for features and asm support. In-Reply-To: References: <50FD90C65C53FB45BADEEBCD84FF07F202EC05C3@ATCPCS06.andestech.com> <20110325090315.1FFE41537B0@gemini.denx.de> <20110331064828.73467EDFFD7@gemini.denx.de> <20110331082428.1816DEDFFD7@gemini.denx.de> Message-ID: <20110331090221.9C932EDFFD7@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Macpaul Lin, Please keep the mailing list on Cc: (re-added) In message you wrote: > > > I repeat again: I consider this manual unrolling of the nested structs > > a Bad Thing. You should have separate offsets for each of the nested > > structs. > > The above code is really a rework for a nested structs. > The origin code looks like, > Moreover, the structure of ftsmc020 was nested like > struct ftsmc020 { > struct { > unsigned int cr; /* 0x00, 0x08, 0x10, 0x18 */ > unsigned int tpr; /* 0x04, 0x0c, 0x14, 0x1c */ > } bank[4]; > unsigned int pad[8]; /* 0x20 - 0x3c */ > unsigned int ssr; /* 0x40 */ > } > > After rewrote it becomes > struct ftsmc020 { > unsigned int bank0_cr; > unsigned int bank0_tpr; > unsigned int bank1_cr; > unsigned int bank1_tpr; > unsigned int bank2_cr; > unsigned int bank2_tpr; > unsigned int bank3_cr; > unsigned int bank3_tpr; > unsigned int pad[8]; > unsigned int ssr; > } > > Did I misunderstand what you exactly meant? Yes, indeed. Unnesting means to move the inner struct declaration outside, like that: struct ftsmc020_bank { unsigned int cr; unsigned int tpr; }; struct ftsmc020 { struct ftsmc020_bank bank[4]; unsigned int pad[8]; unsigned int ssr; }; > > Again: if you need larger numbers of such entries you are doing > > something fundamentally wrong. Reconsider your coding style. What > > exactly enforces you to use assembly? > This is because writing assembly code (lowlevel_init) is really a > necessity for setting the timing > and power outpur correctly to these registers (SMC, SDMC, PMU). What exactly prevents you from writing the very same code in C? > It is required to give a correct setting to PMU and SMC to make the > onboard DRAM works correctly > before the code is loaded from ROM to DRAM and then set up stack for C > environemnt. We take care to provide global data and an initial stack very, very early in the initialization sequence. You canuse C code long before you can access the system RAM. > Hence assembly code to setting SMC and PMU in lowlevel_init is a necessity I seriously doubt that. Just because many boards are writen that way does not mean that's how it must be done - actualy many just copied existing bad examples without thinking. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The man on tops walks a lonely street; the "chain" of command is often a noose.