Dear Wolfgang,
Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090712120655.GA21713@game.jcrosoft.org you wrote:
It will hush up the current errors, but that's actually a bad thing here - the errors are an indication that Jean-Christophe's patch might not be working as it is supposed to.
They do fix what they are suppose to , fix FPU and EABI problem which was re-introduce by the 64 bit mtd support here the problem is different you try to div64 which is not supported on arm you do need to do_div
What do you mean - not supported by ARM? Of course ARM supports 64 bit division.
Compiling this little test code:
long long div(long long x, long long y) { return x / y; }
will result in a call to __aeabi_ldivmod using an EABI compliant version of GCC, resp. to __divdi3 using an older compiler. So GCC knows how to handle this, and it provides adequate functions to do it.
please apply this patch so I'll be able to send a pull request with the arm specific part and other patch be go in vacancy for one week this night
I really hesitate to do that. It seems that not using the compiler provided library is not such a clever thing to do. The compile writes probably know better what a specific version of GCC needs that anybody else.
Yes, you are basically right. But ;)
But, as Jean-Christophe mentioned above, it's a pain with the various ARM tool chains floating around. Some are older, some are newer, some are configured for EABI, some not, some are configured for software floating point, some for hardware floating point, etc., etc.
While I as developer might be able to find a recent tool chain with a libgcc compatible with U-Boot, I think we should avoid this pain for our users. Users which like to "just compile U-Boot" and then we tell them "well, your tool chain you seem to be happy with doesn't link U-Boot, for U-Boot you have to install an other one" I think wouldn't make them happy.
Regarding not using the compilers library and if this clever: No, it isn't clever, you are right again. The compiler's library version is most probably better optimized. But, we are dealing with a boot loader here. So for the topic we discuss here, I think avoiding some pain for us ("my tool chain doesn't compile U-Boot, help!" mails at this list) and our users (see above) is the stronger argument than some optimization/performance issues in some (seldom?) used math functions.
Best regards
Dirk