[U-Boot-Users] cfi_flash is now working with 64 bit port width

[Tolunay Orkun <listmember@orkun.us>]

Wolfgang Denk wrote:
> In message <42C4592E.7080009@orkun.us> you wrote:
> 
>>>               __asm__ __volatile__ ("lfd 1, 0(%0)"::"r" (data));
>>>               __asm__ __volatile__ ("stfd 1, 0(%0)"::"r" (addr));
>>>         }
>>
>>This is probably not acceptable for cfi_flash.c. cfi_flash.c is used by 
>>multiple CPU architectures so PowerPC assembly cannot be used. You have 
>>to find a solution based on "C" only.
> 
> 
> ...which probably does not exist, so this  is  a  valid  and  working
> approach,  although  incomplete.  Appropriate  code  for other archi-
> tectures can be added later. At least for MIPS. Or is  there  an  ARM
> processor with 64 bit data bus?

Well, I really don't know if ARM has 64 bit data bus. Maybe there is 
maybe not.

>>How did you use "double" and it did not work? Please give example of the 
>>work you tried...
> 
> 
> It did not work in  the  intended  sense  as  the  compiler  did  not
> generate  any  FP  instructions  -  which  is  to  be  expected as we
> explicitely tell him to use -msoft-float.

Bummer! :(

I think in this case instead of bloating the cfi_flash.c we could allow 
user to define preprocessor macros in this board file for flash access 
so if those macros are defined, cfi_flash.c would use them and exclude 
its own built-in ones.

That way, any board with custom data bus (reversed lanes for example) or 
address bus (messed up address line) arrangements or specialized 
handling (need floating point) as in this case would override them 
easily and we would not end up blocks of #if/#elif/#else/#endif etc. in 
the cfi_flash.c. The board would also enable FP unit in its board file 
or within these functions if necessary as well.

What do you think?

I can submit a patch to do this while I am working on my other long 
pending patch this weekend. I promise I will get it done this time.

> 
> Best regards,
> 
> Wolfgang Denk
>