[U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size

[Dirk Behme <dirk.behme@googlemail.com>]

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