[Etherboot-developers] currticks function

[Fotis A. <fa...@te...>]

Dear all,

I tried to port the etherboot-5.0.6 to the Infineon's TriCore processor. 
I have faced some problems regarding the currticks() function. While I 
couldn't use the existing implementation of currticks (due to the 
assembly of the rdtsc() function and the different architecture), I 
tried to read a 55-bit timer that has 2ns resolution, and return its 
value. The best result that I acquired, derived by using something like 
the following:

    low = (*(volatile unsigned long *)0xF0000310);  // The low part of 
the 55-bit timer
    high = (*(volatile unsigned long *)0xF000032C);  // The high part of 
the 55-bit timer
    value = (low + high * 0x100000000LL);  // According to the existing 
currticks() function

    currticks = (( value ) * 182 / (50 * 1000000LL)); // 50 is the 
CPU_CLOCK [50MHz]
    return (unsigned)currticks;

With the above implementation the bootp process works fine. However, I 
have *many* problems with the tftp process. For example, the client 
starts downloading the kernel image after at least 2-3 requests. For the 
first requests (at least) the downloading fails due to timeouts. Many 
times, the kernel downloading (even if it starts), stops before finish 
succesfully (because the etherboot does not "read" a TFTP_DATA packet 
from the tftpd). Moving arround with different values into the currticks 
function, (especially with the value 182), I realized that the behaviour 
of the system *changes*. I didn't find any documentation on currticks() 
function and I don't know which has to be the value that it returns each 
time is called, the period, the resolution etc. Just from a comment that 
I found on cs89x0.c driver, I thought that it has a period of 55ms. Is 
this true ? Is the tftp process so sensitive in time functions such as 
currticks ? Thanks a lot.

Fotis Andritsopoulos

-- 
"Whom ever Controls your Perception of Reality Controls You"