In message 465CC968.6090801@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