[U-Boot-Users] cfi_flash is now working with 64 bit port width
Tolunay Orkun
listmember at orkun.us
Thu Jun 30 23:53:01 CEST 2005
Wolfgang Denk wrote:
> In message <42C4592E.7080009 at 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
>
More information about the U-Boot
mailing list