Re: [Etherboot-developers] currticks function

[<ebi...@ln...>]

Fotis Andritsopoulos <fa...@te...> writes:

> 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

Cool so you should generate a kernel image with valid physical
addresses...  This drives me nuts about the x86, and alpha ports.

> >>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.

Hmm.  At the protocol level.

Until an ack is seen a proper server will retransmit the DATA packet,
or until a maximum retry count is reached.

Until the next data packet is seen a proper client (-DCONGESTED) will
retransmit the ack until the next data packet is seen or until a maximum
retry count is reached.

> >>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 watch the network traffic and see what the actual
failure mode is.

> >>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! :(

So occasionally it just times out?
Hmm. I would really try this with another tftp client and verify that
this isn't a server bug.

Do you see retransmits from either the client or the server?
 
> >>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.

Sounds good.  Now that possibility can be ruled out :)

Eric