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

Yusuf Ibrahim Ozkok yozkok at aselsan.com.tr
Fri Jul 1 18:09:44 CEST 2005


Tolunay Orkun wrote:
>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.
I think the best is to keep cfi_flash.c as is, and to copy it into 
/board/flash.c and made the changes for custom needs in that file, for the 
sake of  keeping simplicity of generic drivers. But some descriptive 
warnings and comments may be added at the beggining of cfi_flash for 
possible non standart designs.

Tolunay Orkun wrote:
> How did you use "double" and it did not work? Please give example of the
> work you tried...
    First I had simply tried to cast data to double just before had been 
writing to the bus.

   in cfi_flash.c on line850 (in flash_write_cmd())
        -        *addr.llp = cword.ll;
        +        *addr.llp = (double) cword.ll;

But it caused a very strange think.  While compiling it passed all the make 
steps (compiled, linked ...) but at the lines to generate srec and bin 
formatted files

(ppc_82xx-objcopy --gap-fill=0xff -O srec u-boot u-boot.srec,
ppc_82xx-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin)

the host machine(the redhat WS 3.0 machine where I made the compilation) is 
locked. than I exclude these lines from the makefile planning to do the work 
from command prompth.

When I run the first line, It worked for a few minutes and produced an srec 
file of about 2 gigabytes length. (It might be bigger but stopped with an 
out of space error.) (ppc_82xx-objcopy --gap-fill=0xff -O srec u-boot 
u-boot.srec)

Then running the second line was completely locked the machine. I had had to 
hard reset it.

I couldn't find a resonable explanation for that circumstance.

Secondly I made some trials;
    Here is the code;

    double doubleVar is defined.

    doubleVar = 8245;
    printf("yio: size of double: %d, doubleVar1=%d:\n", sizeof(double), 
doubleVar);
    doubleVar = 1.25;
    printf("yio: doubleVar2=%f, %d:\n", sizeof(double), doubleVar, 
doubleVar);
    memcpy(&doubleVar, &cword.ll, 8);
    printf("yio: doubleVar3=%f, %d, 0x%08x:\n", sizeof(double), doubleVar, 
doubleVar, doubleVar);

    printf("yio: Before bus write: 0x%08x, 0x%08x, 0x%08x, 0x%08x\n", 
*addr.dp, cword.d, *addr.llp, cword.ll);
    *addr.dp = cword.d;
    printf("yio: After Bus write: 0x%08x, 0x%08x, 0x%08x, 0x%08x\n", 
*addr.dp, cword.d, *addr.llp, cword.ll);

and here is the console output.

    fwrite addr ff040000 cmd 50 0050005000500050 64 bit x 16 bit
    yio: size of double: 8, doubleVar1=1086331520:
    yio: doubleVar2=%f, 8:
    yio: doubleVar3=%f, 8, 0x00500050:
    yio: Before bus write: 0x0000000a, 0x008000a2, 0x008000a2, 0x00500050
    yio: After Bus write: 0x0000000a, 0xffff5678, 0xffff5678, 0x00500050


But I think, as Wolfgang mentioned, the problem is that; I ignored or
frankly speaking didn't recognized -msoft-float option given to gcc.
since -msoft-float is used, floating point instructions are not compiled as
expected by gcc. (an example "%f" in printf is printed onto console as
exactly "%f" :-) )

Tolunay Orkun wrote:
>You can copy
> your intended data to the double variable via memcpy() or use a union of
> "long long" and "double", assign to "long long" member and use "double"
>   one for storing.

Using double in a union  is also a kind of casting. So it produced similar 
results. memcpy copies the data to where the double pointer points. But 
writing to the bus with double pointer will not change the result, because 
with -msoft-float option gcc will never use floating point asm instructions 
which are needed for single 64 bit bus transactions.

Tolunay Orkun wrote:
>Please get this crap out of mails sent to public mailing lists. By
> sending to public lists you cannot make any claim confidentiality... If
> you have anything truely confidential do not expect others to protect
> it. Just do not send it to the public lists...

I'm really sorry but have nothing to do with these nonsense words at the end 
of my e-mails. They are automatically added by our mail monitor program. I 
have told to our network managers to define some rules not to add these 
words while sending to the public lists. But they told me that it's a 
company decision and they can't define such special exceptional rules in the 
system. And I have also no chance to use any other mail account, because all 
are prohibited and blocked. :-(

So, unfortunately I have to continue in that way :-( and want you to excuse 
me. List admins are always free to clip that part, before publishing the 
mail.


Regards.
Yusuf.



######################################################################
Dikkat:

Bu elektronik posta mesaji kisisel ve ozeldir. Eger size 
gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz. 
Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte, 
guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki 
gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi 
gorusu olmak zorunda degildir.

######################################################################
Attention: 

This e-mail message is privileged and confidential. If you are 
not the intended recipient please delete the message and notify 
the sender. E-mails to and from the company are monitored for 
operational reasons and in accordance with lawful business practices. 
Any views or opinions presented are solely those of the author and 
do not necessarily represent the views of the company.

######################################################################




More information about the U-Boot mailing list