[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <465CC968.6090801 at atmel.com> you wrote:
>
> > I guess that you probably invented your own implementation, or did you
> > extend the "mtdparts" command for this purpose?
> 
> No, this is part of "drivers/dataflash.c" in the current trunk
> This was added to u-boot 11 Jun 2003 according to CHANGELOG
> The mtdparts command was added after 11 Jan 2005 according the CHANGELOG
> 
> The named partitions is a small extension of "drivers/dataflash.c"

OK, so we have here another area in the staflash support that shall be
cleaned up and merged into one, common implementation. Please move
this into the "mtdparts" support.

> > In the former case, please rewrite your code to fit into the existing
> > mtdparts framework. In the second case, please post your patches.
> 
> As you see above, I am extending existing code, which is not mtdparts

>From the maintenance point of view it is  better  to  avoid  multiple
different  and  incompatible  implementations of the same feature. As
your partition support cannot provide the fuctions that are addressed
by the "mtdparts" implementation, while "mtdparts" can replace yours,
both implementations should be merged into the "mtdparts" command.

> and since this extends the dataflash support you will reject it, so it is pointless
> to even try to submit a patch for inclusion in main trunk.

I do not reject dataflash support poer se. Please try  to  understand
that.  As  maintainer  of the whole project I just cannot accept that
each maintainer of  a  group  of  boards  comes  up  with  differeing
implementations  of  certain  functions  or  with  a diverging design
philosophy.

You know exactly what is wanted,  so  maybe  you  can  try  to  start
contributing  to  the  needed  new  parts instead of trying to extend
parts that have been declared to be candidates for replacement.  That
would be much more useful and less frustrating for everybody.

> The dataflash partitioning scheme is static, which is a disadvantage, but
> If I fix anything, I probably make the partition sizes a configurable item
> in my buildroot and generate the warning there, if the kernel size is non compliant.

If you fix anything, then please by making  it  compatible  with  the
poublic  U-Boot  source  tree,i. e. by using the mtdparts command for
this purpose.

> Anyway mtdparts seems to depend on JFFS2.
> That dependency needs to go away first.

Agreed. Patches are welcome.

> If you want to store EXT2 fs in the rootfs partition, you should not have to add JFFS2 code.

Agreed.

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
Our way is peace.
	-- Septimus, the Son Worshiper, "Bread and Circuses",
	   stardate 4040.7.