Re: [Etherboot-developers] problems inside the await_reply

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

Yannis Mitsos <gm...@te...> writes:

> Hi all,
> 
> It seems that the porting is moving smoothly, I have managed to configure the
> processor and fire-up a second serial port to act as console. Thus, I managed to
> 
> configure the cs8900A device without a configuration ROM.
> 
> The problem I faced is the following:
> After sending the bootp request, I get a reply and I enter in the await_reply
> function with the corresponding parameters. There, in line 1068 of main.c
> (Etherboot version 5.0.8) you set the pointer "bootpreply" to point in the
> nic.packet at the position : ETH_HLEN + sizeof(struct iphdr) + sizeof(struct
> udphdr).

This is fixed in the 5.1.x development versions.  Which are a much better
candidate for a port.  The packet structure is offset by 2 bytes deliberately
to align the data.

> The value (sizeof(struct iphdr) + sizeof(struct udphdr)) is word aligned but the
> 
> ETH_HLEN which is set to 14 makes the aforementioned position NON word aligned.
> 
> So the value (bootpreply->bp_xid) returns wrong values. If you wish I can send
> you details with addresses e.t.c.
> 
> To overcome the problem I allocate in the stack a structure of type bootp_t
> instead of a pointer to a structure and I copy the data from the nic.packet to
> the bootpreply structure. Now, since the bootpreply structure is allocated in
> the stack is word alligned and I do not have a problem.

But this explodes the stack size, and etherboot tends to run with
a small stack.

Also fixed in 5.1.x is handling of IP options which can also misalign
the data.
 
> Any comments on this ?

Yes, please work against the development version where:
(a) all of the alignment issues have been fixed (except possibly in the drivers)
(b) There is a good infrastructure for handling porting issues.

Please check the development version out of cvs, or grab the recent 5.1.6 snapshot.
 
> Regards
> 
> Yannis
> 
> P.S: If I understand correctly the current_tick increments by one value every
> 55.555 ms ?

Roughly that is a define.   A couple of impolite drivers depend on it.
For the rest as long as TICKS_PER_SEC is defined properly they will be o.k.

Eric