Re: [Etherboot-developers] currticks function

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

Eric W. Biederman wrote:

>>So congratulations on the first non-x86 port ar in order.
>>
Actually, it is not a port of the whole etherboot to TriCore :) We tried 
to "hack" the code in order to get a working version of etherboot for 
our needs. Our main task is to port the Linux kernel for the TriCore 
architecture. Now we want a fast way to download the kernel and debug it 
because the JTAG is very slow. Thus, we have ported only the part of the 
etherboot that refers to the ELF and the cs89x0 driver (because our 
development board has this chip). I noticed that there is a mistake in 
the cs89x0.h file. You have defined

#define TX_AFTER_ALL    0x0060       /*  Tx packet after all bytes copied */

but I think that it should be

#define TX_AFTER_ALL    0x00c0

>>Beyond this, it could be that there is a driver bug.  Drivers being
>>more susceptible than the core to differences in the hardware.
>>
Why you decided to use poll instead of interrupts ? The cs89x0 drivers 
uses poll but I didn't check the rest of the drivers.

>>With respect to currticks you will run into problems if it rolls over.
>>overflows.  Though it looks like you are probably o.k.
>>
Exactly.

>>The load_timer2  logic is also suspect.  I don't suppose you
>>have an x86 compatiable timer do you?
>>
The original cs89x0 from the etherboot distribution does not use the 
load_timer2 so we don't use it. For the currticks we use a 55-bit timer 
with period of 2ns.

>>Beyond that my best suggestion is to use tcpdump and get a packet
>>trace from another machine on the same network segment.  That and to
>>verify that the tftp transfer works from another client machine,
>>plugged into the same network port. 
>>
All the transactions over the network seem to be fine. The problem is 
that sometimes the tftp process of the etherboot does not "read" the 
data of one block and the tftp server fails, because it never receives 
an ACK. Notice that the block that the process fails is not the same for 
all the times.

>>If you are timing out I would suggest defing CONGESTED and see if
>>retransmissions help.  It could be just that your network loses
>>some packets.
>>
I tried to use -DCONGESTED but the result remains the same. Also, I 
tried to connect through a hub *only* the PC that runs the tftpd server 
and the development board with the tricore but the problem persists.

>>Alternatively it could be a driver bug where it either drops packets
>>being transmitted or received.
>>
How can I checked this ?

>>My best guess is that playing with the timeout simply varies when
>>another problem is detected.
>>
>>Anyway if you can pinpoint where in a tftp transfer the code is
>>failing we may be able to point you in some productive directions.
>>
It just not recognize a block of data and the server timeouts. Nothing 
more! :(

>>Another possibility is that the image you are loading is overwriting
>>part of etherboot. 
>>
No. Because the GNU tools that we use are not support the PIC option, 
the executables that are produced are not rellocatable. Thus, we build 
the etherboot binary in such way and it is loaded "near at the end" of 
the SDRAM while the kernel image has been built for an address at the 
start of the SDRAM. If the tftp transfers the whole kernel the Linux 
works fine (we use a serial console for debugging purposes). I'm sure 
that there are no such conflicts.

Fotis Andritsopoulos

>>
>>
>>Eric
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Etherboot-developers mailing list
>>Eth...@li...
>>https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>>


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