[U-Boot] [PATCH] ftsmc020: enhance for features and asm support.

[Wolfgang Denk]

Dear Macpaul Lin,

Please keep the mailing list on Cc: (re-added)

In message <AANLkTinYJhoGrA7ZAVUQxwByrkWNqomCBFWiJG_+3+0e at mail.gmail.com> 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.