Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Hi Dirk, On Sunday 28 June 2009 07:47:31 Dirk Behme wrote: Anyway, I would vote for moving these two commits as soon as possible into mainline to fix mainline, too. But there was some discussion about how to deal with Makefile changes to the patches Jean-Christophe sent to the list. Maybe we can find a solution for the Makefile issues of these patches discussed on this list and then move the fixes asap into mainline? Yes, I would really like to see those changes in mainline soon as well. I have to admit that I'm not a real Makefile expert, so I don't have a real expertise to get involved in this discussion. But I'll try to take another look at this thread tomorrow. Sorry, I know, the first week after vacation is always quite busy ;) But any news on this? Yes. News is that I forgot to review this patch. ;) I'll put it on my list for this week. Thanks for reminding me. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dear Stefan, Stefan Roese wrote: On Monday 22 June 2009 20:10:23 Dirk Behme wrote: This is because it's a copy from the Linux code. Not sure if we should change the coding style here. I really prefer to be in sync with the Linux version. This makes future updates easier. You have to discuss this with Wolfgang, but he wasn't happy about it. Enjoy the time while he is on vacation ;) Yes, will do. ;) 3. The major one: By the new 64bit variables, depending on tool chain, there are now calls to libgcc introduced. Depending on tool chain, this might work, or fail. As it does with one of my tool chains, which worked totally fine until here. It was my understanding that U-Boot shall not rely on libgcc, i.e. proper tool chain libraries. Having CONFIG_SYS_64BIT_VSPRINTF not defined, the linker needs _lshrdi3, which comes from nand_base.o and nand_bbt.o. E.g. from len = mtd-size (this-bbt_erase_shift + 2); from nand_bbt.c. Having CONFIG_SYS_64BIT_VSPRINTF enabled, the linker requests _lshrdi3, _udivdi3, _umoddi3 and _clz from libgcc. Looking into U-Boot's lib_arm/ directory, we have already some low level math functions there to avoid libgcc. E.g. nand_bbt.c has references to _ashrdi3, too, but this is resolved by lib_arm's version what is fine. I'd like that NAND code is modified that only math is used which U-Boot provides and no libgcc is needed. this is a already known problem by Stefan and I and solved two patchs was send to the ML Thanks for the hint! Do you kindly have the subjects or better links to mailing list archive? http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=cf96e690cb9840b4a5 dc7e750be863228550b5ce and http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=c5ae538c9bd359c137 d306e431b2589ba91fbc08 both available in the testing branch of u-boot-arm. Yes, I found them. I was confused because I understood Jean-Christophe that they were posted to the list already in the past, and not while we were discussing about it ;) Jean-Christophe did post those patches a few days ago. From you comments on the list I see that you found those patches here too. :) Do these patches fix the building problem for you? testing branch of u-boot-arm compiled fine for me, but I'm not sure if the NAND changes are in testing branch of u-boot-arm, too. I'm pretty sure they are, since Jean-Christophe used these patches exactly to fix this NAND related problem on ARM. But it should be easy to check if the patches are in here. git is your friend... ;) Anyway, I would vote for moving these two commits as soon as possible into mainline to fix mainline, too. But there was some discussion about how to deal with Makefile changes to the patches Jean-Christophe sent to the list. Maybe we can find a solution for the Makefile issues of these patches discussed on this list and then move the fixes asap into mainline? Yes, I would really like to see those changes in mainline soon as well. I have to admit that I'm not a real Makefile expert, so I don't have a real expertise to get involved in this discussion. But I'll try to take another look at this thread tomorrow. Sorry, I know, the first week after vacation is always quite busy ;) But any news on this? Many thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Hi Dirk, On Saturday 20 June 2009 19:45:40 Dirk Behme wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: 2. C++ style comment. Found by Wolfgang ;) This is because it's a copy from the Linux code. Not sure if we should change the coding style here. I really prefer to be in sync with the Linux version. This makes future updates easier. 3. The major one: By the new 64bit variables, depending on tool chain, there are now calls to libgcc introduced. Depending on tool chain, this might work, or fail. As it does with one of my tool chains, which worked totally fine until here. It was my understanding that U-Boot shall not rely on libgcc, i.e. proper tool chain libraries. Having CONFIG_SYS_64BIT_VSPRINTF not defined, the linker needs _lshrdi3, which comes from nand_base.o and nand_bbt.o. E.g. from len = mtd-size (this-bbt_erase_shift + 2); from nand_bbt.c. Having CONFIG_SYS_64BIT_VSPRINTF enabled, the linker requests _lshrdi3, _udivdi3, _umoddi3 and _clz from libgcc. Looking into U-Boot's lib_arm/ directory, we have already some low level math functions there to avoid libgcc. E.g. nand_bbt.c has references to _ashrdi3, too, but this is resolved by lib_arm's version what is fine. I'd like that NAND code is modified that only math is used which U-Boot provides and no libgcc is needed. this is a already known problem by Stefan and I and solved two patchs was send to the ML Thanks for the hint! Do you kindly have the subjects or better links to mailing list archive? http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=cf96e690cb9840b4a5dc7e750be863228550b5ce and http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=c5ae538c9bd359c137d306e431b2589ba91fbc08 both available in the testing branch of u-boot-arm. From you comments on the list I see that you found those patches here too. :) Do these patches fix the building problem for you? Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Hi Dirk, I forgot to address your first issue. Please see below: snip +#if !defined(CONFIG_SYS_64BIT_VSPRINTF) +#warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! +#endif + 1. This preprocessor warning is annoying. Why not enable it in all configs where needed and then remove this warning here? I could have done that, but this would not have been so easy. Especially with so many new board ports pending in the u-boot-arch/next branches at that time. And upcoming board ports would probably fallen through the crack as well. So I decided to do it this way. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Stefan Roese wrote: Hi Dirk, I forgot to address your first issue. Please see below: snip +#if !defined(CONFIG_SYS_64BIT_VSPRINTF) +#warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! +#endif + 1. This preprocessor warning is annoying. Why not enable it in all configs where needed and then remove this warning here? I could have done that, but this would not have been so easy. Especially with so many new board ports pending in the u-boot-arch/next branches at that time. And upcoming board ports would probably fallen through the crack as well. So I decided to do it this way. Is this a long term solution or only waiting for all u-boot-arch/next branches to be merged? For a long term solution this would be annoying. Maybe we can change this after merge window closed? Thanks and best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Stefan Roese wrote: On Monday 22 June 2009 20:12:11 Dirk Behme wrote: 1. This preprocessor warning is annoying. Why not enable it in all configs where needed and then remove this warning here? I could have done that, but this would not have been so easy. Especially with so many new board ports pending in the u-boot-arch/next branches at that time. And upcoming board ports would probably fallen through the crack as well. So I decided to do it this way. Is this a long term solution or only waiting for all u-boot-arch/next branches to be merged? I don't understand this question. The current code with this check is available in mainline. Or not? Sorry, yes, but you mentioned above pending boards and not merged next branches. So my question was if you plan to change the warning after all pending boards and next branches are merged. For a long term solution this would be annoying. Maybe we can change this after merge window closed? Why? There could still be new board ports using this NAND code without defining this 64bit printf format option. I don't think this check really hurts. Because every non-U-Boot expert who just downloads recent git and compiles it will get the warning and will wonder if something is wrong or not. So yes, the check doesn't hurt, but the warning might confuse the users, which are non-experts. It's similar to the WARNING - bad CRC or NAND, using default environment. runtime warning. There are tons on questions on various mailing lists if this is an error or not ;) We could get rid of it of course if we would enable this 64bit printf format on all platforms and removed this option completely. This would cost a bit of image size but would make things easier/simpler. Just my 0.02$... For OMAP3 I would enabled this option, independent of image size, just to get rid of the warning. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dirk Behme wrote: Because every non-U-Boot expert who just downloads recent git and compiles it will get the warning and will wonder if something is wrong or not. So yes, the check doesn't hurt, but the warning might confuse the users, which are non-experts. And the answer to that user is that something *is* wrong, and should be reported to the board maintainer so they can enable 64-bit printf. We could get rid of it of course if we would enable this 64bit printf format on all platforms and removed this option completely. This would cost a bit of image size but would make things easier/simpler. Just my 0.02$... Agreed. Or once we get kconfig we can have it be selected by any code that requires it. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
On Monday 22 June 2009 20:50:30 Scott Wood wrote: Dirk Behme wrote: Because every non-U-Boot expert who just downloads recent git and compiles it will get the warning and will wonder if something is wrong or not. So yes, the check doesn't hurt, but the warning might confuse the users, which are non-experts. And the answer to that user is that something *is* wrong, and should be reported to the board maintainer so they can enable 64-bit printf. Ack. We could get rid of it of course if we would enable this 64bit printf format on all platforms and removed this option completely. This would cost a bit of image size but would make things easier/simpler. Just my 0.02$... Agreed. Or once we get kconfig we can have it be selected by any code that requires it. Good idea. Thanks Scott. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Stefan Roese wrote: On Monday 22 June 2009 20:50:30 Scott Wood wrote: Dirk Behme wrote: Because every non-U-Boot expert who just downloads recent git and compiles it will get the warning and will wonder if something is wrong or not. So yes, the check doesn't hurt, but the warning might confuse the users, which are non-experts. And the answer to that user is that something *is* wrong, and should be reported to the board maintainer so they can enable 64-bit printf. Ack. Ok. So you tell me we shall enable 64-bit printf for all OMAP3 boards that show this warning? What I still miss: If this warning indicates that something *is* wrong, why not run MAKEALL and enable it in config for all boards that show this warning? What's the advantage of having all maintainers sending patches for their boards? Best regards Dirk We could get rid of it of course if we would enable this 64bit printf format on all platforms and removed this option completely. This would cost a bit of image size but would make things easier/simpler. Just my 0.02$... Agreed. Or once we get kconfig we can have it be selected by any code that requires it. Good idea. Thanks Scott. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dirk Behme wrote: What I still miss: If this warning indicates that something *is* wrong, why not run MAKEALL and enable it in config for all boards that show this warning? What's the advantage of having all maintainers sending patches for their boards? 1. That requires having all toolchains installed, and 2. That does nothing to prevent future boards from being added that are missing the dependency. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Scott Wood wrote: Dirk Behme wrote: What I still miss: If this warning indicates that something *is* wrong, why not run MAKEALL and enable it in config for all boards that show this warning? What's the advantage of having all maintainers sending patches for their boards? 1. That requires having all toolchains installed, and Hmm? In nand_util.c we have #if !defined(CONFIG_SYS_64BIT_VSPRINTF) #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! #endif and in Makefile we have ifdef CONFIG_CMD_NAND ifndef CONFIG_NAND_LEGACY ... COBJS-y += nand_util.o endif So I would assume that this warning appears for all boards having CONFIG_CMD_NAND enabled and no CONFIG_NAND_LEGACY and no CONFIG_SYS_64BIT_VSPRINTF? Independent of tool chain? 2. That does nothing to prevent future boards from being added that are missing the dependency. Ok, for future boards this warning is fine. But I talk about all the existing boards. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dirk Behme wrote: Scott Wood wrote: Dirk Behme wrote: What I still miss: If this warning indicates that something *is* wrong, why not run MAKEALL and enable it in config for all boards that show this warning? What's the advantage of having all maintainers sending patches for their boards? 1. That requires having all toolchains installed, and Hmm? In nand_util.c we have #if !defined(CONFIG_SYS_64BIT_VSPRINTF) #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! #endif and in Makefile we have ifdef CONFIG_CMD_NAND ifndef CONFIG_NAND_LEGACY ... COBJS-y += nand_util.o endif So I would assume that this warning appears for all boards having CONFIG_CMD_NAND enabled and no CONFIG_NAND_LEGACY and no CONFIG_SYS_64BIT_VSPRINTF? Independent of tool chain? I don't mean different versions, I mean toolchains that cover all architectures. If I don't have a superh or blackfin compiler installed, I'm not going to see any warnings on those boards because they won't build at all. I agree though that it would be nice to grep for existing NAND users and try to cover the obvious ones. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Scott Wood wrote: Dirk Behme wrote: Scott Wood wrote: Dirk Behme wrote: What I still miss: If this warning indicates that something *is* wrong, why not run MAKEALL and enable it in config for all boards that show this warning? What's the advantage of having all maintainers sending patches for their boards? 1. That requires having all toolchains installed, and Hmm? In nand_util.c we have #if !defined(CONFIG_SYS_64BIT_VSPRINTF) #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! #endif and in Makefile we have ifdef CONFIG_CMD_NAND ifndef CONFIG_NAND_LEGACY ... COBJS-y += nand_util.o endif So I would assume that this warning appears for all boards having CONFIG_CMD_NAND enabled and no CONFIG_NAND_LEGACY and no CONFIG_SYS_64BIT_VSPRINTF? Independent of tool chain? I don't mean different versions, I mean toolchains that cover all architectures. If I don't have a superh or blackfin compiler installed, I'm not going to see any warnings on those boards because they won't build at all. I agree though that it would be nice to grep for existing NAND users and try to cover the obvious ones. Ack, this is exactly what I meant :) Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
2. C++ style comment. Found by Wolfgang ;) 3. The major one: By the new 64bit variables, depending on tool chain, there are now calls to libgcc introduced. Depending on tool chain, this might work, or fail. As it does with one of my tool chains, which worked totally fine until here. It was my understanding that U-Boot shall not rely on libgcc, i.e. proper tool chain libraries. Having CONFIG_SYS_64BIT_VSPRINTF not defined, the linker needs _lshrdi3, which comes from nand_base.o and nand_bbt.o. E.g. from len = mtd-size (this-bbt_erase_shift + 2); from nand_bbt.c. Having CONFIG_SYS_64BIT_VSPRINTF enabled, the linker requests _lshrdi3, _udivdi3, _umoddi3 and _clz from libgcc. Looking into U-Boot's lib_arm/ directory, we have already some low level math functions there to avoid libgcc. E.g. nand_bbt.c has references to _ashrdi3, too, but this is resolved by lib_arm's version what is fine. I'd like that NAND code is modified that only math is used which U-Boot provides and no libgcc is needed. this is a already known problem by Stefan and I and solved two patchs was send to the ML and now we are independant of the libgcc please test the testing branch of the u-boot-arm tree Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Jean-Christophe PLAGNIOL-VILLARD wrote: 2. C++ style comment. Found by Wolfgang ;) 3. The major one: By the new 64bit variables, depending on tool chain, there are now calls to libgcc introduced. Depending on tool chain, this might work, or fail. As it does with one of my tool chains, which worked totally fine until here. It was my understanding that U-Boot shall not rely on libgcc, i.e. proper tool chain libraries. Having CONFIG_SYS_64BIT_VSPRINTF not defined, the linker needs _lshrdi3, which comes from nand_base.o and nand_bbt.o. E.g. from len = mtd-size (this-bbt_erase_shift + 2); from nand_bbt.c. Having CONFIG_SYS_64BIT_VSPRINTF enabled, the linker requests _lshrdi3, _udivdi3, _umoddi3 and _clz from libgcc. Looking into U-Boot's lib_arm/ directory, we have already some low level math functions there to avoid libgcc. E.g. nand_bbt.c has references to _ashrdi3, too, but this is resolved by lib_arm's version what is fine. I'd like that NAND code is modified that only math is used which U-Boot provides and no libgcc is needed. this is a already known problem by Stefan and I and solved two patchs was send to the ML Thanks for the hint! Do you kindly have the subjects or better links to mailing list archive? Many thanks Dirk and now we are independant of the libgcc please test the testing branch of the u-boot-arm tree Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dear Stefan,
having this patch in mainline [1] now, I have some issues with it. I
use omap3_beagle_config (ARM). There was already a short discussion
with Wolfgang on IRC regarding this, he directed my to you ;) I
identified three topics, two minor and one major one:
Stefan Roese wrote:
This patch brings the U-Boot MTD infrastructure in sync with the current
Linux MTD version (2.6.30-rc3). Biggest change is the 64bit device size
support and a resync of the mtdpart.c file which has seen multiple fixes
meanwhile.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Scott Wood scottw...@freescale.com
Cc: Kyungmin Park kmp...@infradead.org
---
common/cmd_onenand.c |6 +-
common/env_onenand.c |2 +-
drivers/mtd/cfi_mtd.c|4 +-
drivers/mtd/mtdpart.c| 488
+++---
drivers/mtd/nand/nand_util.c | 11 +-
include/linux/mtd/mtd.h | 29 ++-
6 files changed, 256 insertions(+), 284 deletions(-)
diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c
index 5832ff8..e8f06d7 100644
--- a/common/cmd_onenand.c
+++ b/common/cmd_onenand.c
@@ -19,6 +19,10 @@
#include asm/io.h
+#if !defined(CONFIG_SYS_64BIT_VSPRINTF)
+#warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
+#endif
+
1. This preprocessor warning is annoying. Why not enable it in all
configs where needed and then remove this warning here?
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 354e3a0..c884567 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -8,6 +8,7 @@
#define __MTD_MTD_H__
#include linux/types.h
+#include div64.h
#include linux/mtd/mtd-abi.h
#define MTD_CHAR_MAJOR 90
@@ -20,6 +21,8 @@
#define MTD_ERASE_DONE 0x08
#define MTD_ERASE_FAILED0x10
+#define MTD_FAIL_ADDR_UNKNOWN-1LL
+
/*
* Enumeration for NAND/OneNAND flash chip state
*/
@@ -37,13 +40,13 @@ enum {
};
/* If the erase fails, fail_addr might indicate exactly which block failed.
If
- fail_addr = 0x, the failure was not at the device level or was not
+ fail_addr = MTD_FAIL_ADDR_UNKNOWN, the failure was not at the device
level or was not
specific to any particular block. */
struct erase_info {
struct mtd_info *mtd;
- u_int32_t addr;
- u_int32_t len;
- u_int32_t fail_addr;
+ uint64_t addr;
+ uint64_t len;
+ uint64_t fail_addr;
u_long time;
u_long retries;
u_int dev;
@@ -55,7 +58,7 @@ struct erase_info {
};
struct mtd_erase_region_info {
- u_int32_t offset; /* At which this region starts,
from the beginning of the MTD */
+ uint64_t offset;/* At which this region starts,
from the beginning of the MTD */
u_int32_t erasesize;/* For this region */
u_int32_t numblocks;/* Number of blocks of erasesize in
this region */
unsigned long *lockmap; /* If keeping bitmap of locks */
@@ -110,7 +113,7 @@ struct mtd_oob_ops {
struct mtd_info {
u_char type;
u_int32_t flags;
- u_int32_t size; /* Total size of the MTD */
+ uint64_t size; // Total size of the MTD
2. C++ style comment. Found by Wolfgang ;)
3. The major one: By the new 64bit variables, depending on tool chain,
there are now calls to libgcc introduced. Depending on tool chain,
this might work, or fail. As it does with one of my tool chains, which
worked totally fine until here. It was my understanding that U-Boot
shall not rely on libgcc, i.e. proper tool chain libraries.
Having CONFIG_SYS_64BIT_VSPRINTF not defined, the linker needs
_lshrdi3, which comes from nand_base.o and nand_bbt.o. E.g. from
len = mtd-size (this-bbt_erase_shift + 2); from nand_bbt.c.
Having CONFIG_SYS_64BIT_VSPRINTF enabled, the linker requests
_lshrdi3, _udivdi3, _umoddi3 and _clz from libgcc.
Looking into U-Boot's lib_arm/ directory, we have already some low
level math functions there to avoid libgcc. E.g. nand_bbt.c has
references to _ashrdi3, too, but this is resolved by lib_arm's version
what is fine.
I'd like that NAND code is modified that only math is used which
U-Boot provides and no libgcc is needed.
Best regards
Dirk
[1]
http://git.denx.de/?p=u-boot.git;a=commit;h=8d2effea23e938631126a7888008a0637e13b389
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dear Stefan Roese, In message 1242050635-7152-1-git-send-email...@denx.de you wrote: --===0052372897== This patch brings the U-Boot MTD infrastructure in sync with the current Linux MTD version (2.6.30-rc3). Biggest change is the 64bit device size support and a resync of the mtdpart.c file which has seen multiple fixes meanwhile. Signed-off-by: Stefan Roese s...@denx.de Cc: Scott Wood scottw...@freescale.com Cc: Kyungmin Park kmp...@infradead.org --- common/cmd_onenand.c |6 +- common/env_onenand.c |2 +- drivers/mtd/cfi_mtd.c|4 +- drivers/mtd/mtdpart.c| 488 +++--- drivers/mtd/nand/nand_util.c | 11 +- include/linux/mtd/mtd.h | 29 ++- 6 files changed, 256 insertions(+), 284 deletions(-) Applied to next, thanks. 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: w...@denx.de Nearly everyone is in favor of going to heaven but too many are hoping they'll live long enough to see an easing of the entrance requirements. Never appeal to a man's better nature. he might not have one. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dear Stefan Roese, In message 200905120639.24172...@denx.de you wrote: OK, here we go: Canyonlands (using NAND) without this patch: textdata bss dec hex filename 339324 20044 336384 695752 a9dc8 ./u-boot and with this patch: textdata bss dec hex filename 339796 20044 336384 696224 a9fa0 ./u-boot So it's 472 bytes on this platform. Thanks - that's indeed not much. Is my understanding correct that the effect on NOR-only systems is even smaller, it at all visible? 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: w...@denx.de Many aligators will be slain, but the swamp will remain. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
On Monday 11 May 2009 10:03:55 Stefan Roese wrote: This patch brings the U-Boot MTD infrastructure in sync with the current Linux MTD version (2.6.30-rc3). Biggest change is the 64bit device size support and a resync of the mtdpart.c file which has seen multiple fixes meanwhile. really wish there was a define to control this. large devices are fine, but it sucks when majority of people dont hit this limit. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
On Monday 11 May 2009 18:27:02 Mike Frysinger wrote: On Monday 11 May 2009 10:03:55 Stefan Roese wrote: This patch brings the U-Boot MTD infrastructure in sync with the current Linux MTD version (2.6.30-rc3). Biggest change is the 64bit device size support and a resync of the mtdpart.c file which has seen multiple fixes meanwhile. really wish there was a define to control this. large devices are fine, but it sucks when majority of people dont hit this limit. What is the drawback of this code version? I have to admit that I didn't compare code size, but this is the only possible drawback coming to my mind. And the advantages are big enough from my point of view. Being in sync with Linux once again not only brings 64bit device size support but removes quite a lot of bugs from the mtd infrastructure (for example used by UBI). And frankly, cluttering the files with another set of #ifdef's doesn't really sound promising. Additionally this would make future sync's with the Linux version more troublesome. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
On Monday 11 May 2009 12:38:45 Stefan Roese wrote: On Monday 11 May 2009 18:27:02 Mike Frysinger wrote: On Monday 11 May 2009 10:03:55 Stefan Roese wrote: This patch brings the U-Boot MTD infrastructure in sync with the current Linux MTD version (2.6.30-rc3). Biggest change is the 64bit device size support and a resync of the mtdpart.c file which has seen multiple fixes meanwhile. really wish there was a define to control this. large devices are fine, but it sucks when majority of people dont hit this limit. What is the drawback of this code version? I have to admit that I didn't compare code size, but this is the only possible drawback coming to my mind. And the advantages are big enough from my point of view. Being in sync with Linux once again not only brings 64bit device size support but removes quite a lot of bugs from the mtd infrastructure (for example used by UBI). And frankly, cluttering the files with another set of #ifdef's doesn't really sound promising. Additionally this would make future sync's with the Linux version more troublesome. i'd see most of the changes be via a typedef and thus there are no ifdefs cluttering up the code -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dear Stefan Roese, In message 200905111838.45552...@denx.de you wrote: really wish there was a define to control this. large devices are fine, but it sucks when majority of people dont hit this limit. What is the drawback of this code version? I have to admit that I didn't compare code size, but this is the only possible drawback coming to my mind. Can you please make such a comparison? I, too, would like to know how much of a difference that makes - I share Mike's concerns. And the advantages are big enough from my point of view. Being in sync with Linux once again not only brings 64bit device size support but removes quite a lot of bugs from the mtd infrastructure (for example used by UBI). I do understand this - but then, we're a boot loader, and code size is still a top priority here. 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: w...@denx.de A good aphorism is too hard for the tooth of time, and is not worn away by all the centuries, although it serves as food for every epoch. - Friedrich Wilhelm Nietzsche _Miscellaneous Maxims and Opinions_ no. 168 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
On Mon, May 11, 2009 at 12:57:52PM -0400, Mike Frysinger wrote: On Monday 11 May 2009 12:38:45 Stefan Roese wrote: On Monday 11 May 2009 18:27:02 Mike Frysinger wrote: On Monday 11 May 2009 10:03:55 Stefan Roese wrote: This patch brings the U-Boot MTD infrastructure in sync with the current Linux MTD version (2.6.30-rc3). Biggest change is the 64bit device size support and a resync of the mtdpart.c file which has seen multiple fixes meanwhile. ACK i'd see most of the changes be via a typedef and thus there are no ifdefs cluttering up the code If you make the size a typedef, then all the printf formats that reference size will need casts (and will still need 64-bit printf), or some #defined format string. We could do it if makes a big difference (looks like about 500 bytes in the NAND code on powerpc), but I suspect there are better places to save space in mtd, such as not building in default functions that are just going to be overridden (or not selected in the first place). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
On Monday 11 May 2009 19:59:10 Wolfgang Denk wrote: really wish there was a define to control this. large devices are fine, but it sucks when majority of people dont hit this limit. What is the drawback of this code version? I have to admit that I didn't compare code size, but this is the only possible drawback coming to my mind. Can you please make such a comparison? I, too, would like to know how much of a difference that makes - I share Mike's concerns. OK, here we go: Canyonlands (using NAND) without this patch: textdata bss dec hex filename 339324 20044 336384 695752 a9dc8 ./u-boot and with this patch: textdata bss dec hex filename 339796 20044 336384 696224 a9fa0 ./u-boot So it's 472 bytes on this platform. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
On Tuesday 12 May 2009 00:39:24 Stefan Roese wrote: On Monday 11 May 2009 19:59:10 Wolfgang Denk wrote: really wish there was a define to control this. large devices are fine, but it sucks when majority of people dont hit this limit. What is the drawback of this code version? I have to admit that I didn't compare code size, but this is the only possible drawback coming to my mind. Can you please make such a comparison? I, too, would like to know how much of a difference that makes - I share Mike's concerns. OK, here we go: Canyonlands (using NAND) without this patch: textdata bss dec hex filename 339324 20044 336384 695752 a9dc8 ./u-boot and with this patch: textdata bss dec hex filename 339796 20044 336384 696224 a9fa0 ./u-boot So it's 472 bytes on this platform. doesnt sound like it's worth the hassle to me. thanks for testing a bit. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
